小米科技|Apache Flink不止于计算，数仓架构或兴起新一轮变革( 二 ) 小米MIX|高通骁龙|vivo NEX

数据集成、不同数据源之间的数据同步对于很多团队来说是刚需，但传统方案往往复杂度太高且时效性不好。传统的数据集成方案通常是离线数据集成和实时数据集成分别采用两套技术栈，其中涉及很多数据同步工具，比如 Sqoop、DataX 等，这些工具要么只能做全量要么只能做增量，开发者需要自己控制全增量的切换，配合起来比较复杂。基于 Flink 的流批一体能力和 Flink CDC ，只需要写一条 SQL ，就可以做到先全量同步历史数据，再自动断点续传增量数据，实现一站式数据集成。全程无需用户判断和干预， Flink 能自动完成批流之间的切换并保证数据的一致性。 Flink CDC Connectors 作为一个独立的开源项目，从去年 7 月份开源以来，一直保持相当高速的发展，平均两个月一个版本。目前 Flink CDC 版本已经更新到2.1版本，并完成了很多主流数据库的适配，比如 MySQL、PostgreSQL、MongoDB、Oracle 等，更多数据库如 TiDB、DB2 等的对接工作也在进行中。可以看到已经有越来越多企业在自己的业务场景中使用 Flink CDC ， InfoQ 前不久采访过的 XTransfer 就是其中之一。第二个应用场景则是大数据领域最核心的数仓场景。目前主流的实时离线一体化数仓架构通常如下图所示。

绝大部分场景都会使用 Flink+Kafka 来做实时数据流的处理，也就是实时数仓的部分，并将最终分析结果写入到一个在线服务层，用来展示或做进一步的分析。同时后台一定会有一个异步的离线数仓架构对实时数据作补充，每天定期运行大规模批量甚至是全量分析，或进行历史数据的定期修正等。但这个经典架构存在一些显而易见的问题：首先，实时链路和离线链路使用的技术栈不同，必定会有两套 API ，那么就需要两套开发流程，增加了开发成本；其次，实时离线技术栈不同，无法保证数据口径的一致性；再次，实时链路的中间队列数据不利于分析。如果用户想要分析实时链路中一个明细层的数据，其实非常不方便，很多用户目前采用的办法可能是先把这个明细层中的数据导出来，比如导到 Hive 做离线分析，但这个时效性会大幅下降，或者为了加速查询，把数据导入到其他 OLAP 引擎中，但这又会增加系统复杂度，且数据一致性同样很难保证。 Flink 流批一体的理念可以在上述场景下得到充分应用。在莫问看来， Flink 可以让当前业界主流数仓架构再进阶一层，实现真正端到端全链路的实时化分析能力，即：当数据在源头发生变化时就能捕捉到这一变化，并支持对它做逐层分析，让所有数据实时流动起来，并且对所有流动中的数据都可以实时查询。再借助 Flink 完备的流批一体能力，使用同一套 API 就可以同时支持灵活的离线分析。这样一来，实时、离线以及交互式查询分析、短查询分析等，就可以统一成一整套解决方案，成为理想中的“流式数仓（Streaming Warehouse）” 。
理解流式数仓

流式数仓（Streaming Warehouse）更准确地说，其实是“make data warehouse streaming” ，就是让整个数仓的数据全实时地流动起来，且是以纯流的方式而不是微批（mini-batch）的方式流动。目标是实现一个具备端到端实时性的纯流服务（Streaming Service），用一套 API 分析所有流动中的数据，当源头数据发生变化，比如捕捉到在线服务的 Log 或数据库的 Binlog 以后，就按照提前定义好的 Query 逻辑或数据处理逻辑，对数据进行分析，分析后的数据落到数仓的某一个分层，再从第一个分层向下一个分层流动，然后数仓所有分层会全部流动起来，最终流到一个在线系统里，用户可以看到整个数仓的全实时流动效果。在这个过程中，数据是主动的，而查询是被动的，分析由数据的变化来驱动。同时在垂直方向上，对每一个数据明细层，用户都可以执行 Query 进行主动查询，并且能实时获得查询结果。此外，它还能兼容离线分析场景， API 依然是同一套，实现真正的一体化。目前业界还没有这样一个端到端全流式链路的成熟解决方案，虽然有纯流的方案和纯交互式查询的方案，但需要用户自己把两套方案加起来，必然会增加系统的复杂性，如果要再把离线数仓方案也加进来，系统复杂性问题就更大了。流式数仓要做的是在实现高时效性的同时，不进一步提高系统复杂性，让整个架构对于开发和运维人员来说都是非常简洁的。当然，流式数仓是终态，要达成这个目标， Flink 需要一个配套的流批一体存储支持。其实 Flink 本身有内置的分布式 RocksDB 作为 State 存储，但这个存储只能解决任务内部流数据状态的存储问题。流式数仓需要一个计算任务之间的表存储服务：第一个任务将数据写进去，第二个任务就能从它实时地再读出来，第三个任务还能对它执行用户的 Query 分析。因此 Flink 需要再扩展出一个跟自身理念配套的存储，从 State 存储走出来，继续向外走。为此， Flink 社区提出了新的 Dynamic Table Storage ，即具备流表二象性的存储方案。