共计 7145 个字符，预计需要花费 18 分钟才能阅读完成。
作者 | 蔡芳芳
采访嘉宾 | 王峰（莫问）
维基百科的“Apache Flink”词条下，有这么一句形容：“Flink 并不提供本人的数据存储系统，但为 Amazon Kinesis、Apache Kafka、Alluxio、HDFS、Apache Cassandra 和 Elasticsearch 等零碎提供了数据源和接收器”，很快，这句话的前半句或者将不再实用。
残缺视频：https://developer.aliyun.com/…
2021 年初，在 InfoQ 编辑部策动的全年技术趋势瞻望中，咱们提到大数据畛域将减速拥抱“交融”（或“一体化”）演进的新方向。实质是为了升高大数据分析的技术复杂度和老本，同时满足对性能和易用性的更高要求。现在，咱们看到风行的流解决引擎 Apache Flink（下称 Flink）沿着这个趋势又迈出了新的一步。
1 月 8 日上午，Flink Forward Asia 2021 以线上会议的模式拉开帷幕。往年是 Flink Forward Asia（下文简称 FFA）落地中国的第四个年头，也是 Flink 成为 Apache 软件基金会顶级我的项目的第七年。随同着实时化浪潮的倒退和深入，Flink 已逐渐演进为流解决的领军角色和事实标准。回顾其演进历程，Flink 一方面继续优化其流计算外围能力，一直进步整个行业的流计算解决规范，另一方面沿着流批一体的思路逐步推进架构革新和利用场景落地。但在这些之外，Flink 长期倒退还须要一个新的突破口。
在 Flink Forward Asia 2021 的主题演讲中，Apache Flink 中文社区发起人、阿里巴巴开源大数据平台负责人王峰（花名莫问）重点介绍了 Flink 在流批一体架构演进和落地方面的最新进展，并提出了 Flink 下一步的倒退方向——流式数仓（Streaming Warehouse，简称 Streamhouse）。正如主题演讲题目“Flink Next, Beyond Stream Processing”所言，Flink 要从 Stream Processing 走向 Streaming Warehouse 去笼罩更大的场景，帮忙开发者解决更多问题。而要实现流式数仓的指标，就意味着 Flink 社区要拓展适宜流批一体的数据存储，这是 Flink 往年在技术方面的一个翻新，社区相干工作曾经在 10 月份启动，接下来这会作为 Flink 社区将来一年的一个重点方向来推动。
那么，如何了解流式数仓？它想解决现有数据架构的哪些问题？为什么 Flink 要抉择这个方向？流式数仓的实现门路会是怎么的？带着这些问题，InfoQ 独家专访了莫问，进一步理解流式数仓背地的思考门路。
Flink 这几年始终在反复强调流批一体，即：应用同一套 API、同一套开发范式来实现大数据的流计算和批计算，进而保障处理过程与后果的一致性。莫问示意，流批一体更多是一种技术理念和能力，它自身不解决用户的任何问题，只有当它真正落到理论业务场景中，才可能体现出开发效率和运行效率上的价值。而流式数仓能够了解为流批一体大方向下对落地解决方案的思考。
流批一体的两个利用场景
在去年的 FFA 上，咱们曾经看到 Flink 流批一体在天猫双十一的落地利用，那是阿里首次在外围数据业务上真正规模化落地流批一体。现在一年过来了，Flink 流批一体在技术架构演进和落地利用两方面都有了新进展。
技术演进层面，Flink 流批一体 API 和架构革新曾经实现，在原先的流批一体 SQL 根底上，进一步整合了 DataStream 和 DataSet 两套 API，实现了残缺的 Java 语义层面的流批一体 API，架构上做到了一套代码可同时承接流存储与批存储。
在往年 10 月公布的 Flink 1.14 版本中，曾经能够反对在 同一个利用中混合应用有界流和无界流 ：Flink 当初反对对局部运行、局部完结的利用（局部算子已解决到有界输出数据流的末端）做 Checkpoint。此外，Flink 在 解决到有界数据流末端时会触发最终 Checkpoint，以确保所有计算结果顺利提交到 Sink。
而批执行模式当初反对在同一利用中混合应用 DataStream API 和 SQL/Table API（此前仅反对独自应用 DataStream API 或 SQL/Table API）。
此外，Flink 更新了对立的 Source 和 Sink API，开始 围绕对立的 API 整合连接器生态。新增的混合 Source 可在多个存储系统间过渡，实现诸如先从 Amazon S3 中读取旧的数据再无缝切换到 Apache Kafka 这样的操作。
在落地利用层面，也呈现了两个比拟重要的利用场景。
第一个是基于 Flink CDC 的全增量一体化数据集成。
数据集成、不同数据源之间的数据同步对于很多团队来说是刚需，但传统计划往往复杂度太高且时效性不好。传统的数据集成计划通常是离线数据集成和实时数据集成别离采纳两套技术栈，其中波及很多数据同步工具，比方 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，即具备流表二象性的存储计划。
流批一体存储：Flink Dynamic Table
Flink Dynamic Table（社区探讨详见 FLIP-188）能够了解为一套流批一体的存储，并无缝对接 Flink SQL。原来 Flink 只能读写像 Kafka、HBase 这样的内部表，当初用同一套 Flink SQL 语法就能够像原来创立源表和指标表一样，创立一个 Dynamic Table。流式数仓的分层数据能够全副放到 Flink Dynamic Table 中，通过 Flink SQL 就能实时地串联起整个数仓的分层，既能够对 Dynamic Table 中不同明细层的数据做实时查问和剖析，也能够对不同分层做批量 ETL 解决。
从数据结构上看，Dynamic Table 外部有两个外围存储组件，别离是 File Store 和 Log Store。顾名思义，Flie Store 存储 Table 的文件存储模式，采纳经典的 LSM 架构，反对流式的更新、删除、减少等；同时，采纳凋谢的列存构造，反对压缩等优化；它对应 Flink SQL 的批模式，反对全量批式读取。而 Log Store 存储的是 Table 的操作记录，是一个不可变更序列，对应 Flink SQL 的流模式，能够通过 Flink SQL 订阅 Dynamic Table 的增量变动做实时剖析，目前反对插件化实现。
对 Flie Store 的写入被封装在内置的 Sink 中，屏蔽了写入的复杂性。同时 Flink 的 Checkpoint 机制和 Exactly Once 机制可能保证数据的一致性。
目前 Dynamic Table 第一个阶段的实现计划曾经实现，社区也在围绕这个方向开展更多探讨。依据社区的布局，将来的终态会实现 Dynamic Table 的服务化，真正造成一套 Dynamic Table 的 Service，实现齐全实时化的流批一体存储。同时，Flink 社区也正在探讨将 Dynamic Table 作为 Flink 独立子项目经营和公布，不排除后续将其齐全独立成为流批一体通用存储我的项目倒退。最终，利用 Flink CDC、Flink SQL、Flink Dynamic Table 就能够构建一套残缺的流式数仓，实现实时离线一体化的体验。整个流程及成果参见以下 demo 视频展现。
https://www.bilibili.com/vide…
尽管整个流程初步走通，但真正要实现全实时链路且足够稳固，社区还须要逐渐晋升实现计划的品质，这其中包含 Flink SQL 在 OLAP 交互式场景下的优化、动静表存储性能和一致性的优化以及构建动静表服务化能力等诸多工作。流式数仓这个方向只是刚刚启动，并有了初步尝试，在莫问看来，设计没有问题，但后续还须要解决一系列工程问题。这就像设计一个先进制程芯片或 ARM 架构，很多人都能设计进去，但在要保障良品率的前提下把芯片生产进去，其实是很难的。流式数仓会是接下来 Flink 在大数据分析场景下最重要的一个方向，社区也会在这个方向上鼎力投入。
Flink 不止于计算
在大数据实时化转型大趋势之下，Flink 不只能做一件事件，它还能做更多。
业界原先对于 Flink 的定位更多是一个流处理器或流计算引擎，理论并非如此。莫问示意，Flink 原生也不只是计算，大家可能广义上认为 Flink 是计算，但狭义来说，Flink 原本就有存储。“Flink 可能靠流计算冲出重围，靠的就是有状态的存储，这是绝对 Storm 来说更大的劣势。”
当初 Flink 心愿更进一步，实现一个笼罩更大范畴实时化问题的解决方案，原有的存储就不够用了。而内部的存储系统或其余引擎体系跟 Flink 的指标和个性又不完全一致，无奈跟 Flink 做很好的集成。比方 Flink 跟数据湖包含 Hudi、Iceberg 都做了集成，反对实时入湖、入湖实时增量剖析，但这些场景依然无奈齐全施展出 Flink 全实时的劣势，因为数据湖存储格局实质还是 Mini-Batch，Flink 在其中也会进化到 Mini-Batch 模式。这不是 Flink 最心愿看到或最适宜 Flink 的架构，所以它天然就须要本人再拓展出一套与 Flink 流批一体理念相配套的存储系统。
在莫问看来，对于一套大数据计算剖析引擎，如果没有一套与其理念配套的存储技术体系撑持，是无奈提供一套极致体验的数据分析解决方案的。这就相似于，任何优良的算法都须要有相应的数据结构与其配套，能力以最佳效率解决问题。
为什么说 Flink 做流式数仓更适合？这是由 Flink 的理念决定的，Flink 的核心理念是以 Streaming 优先来解决数据处理的问题，而要让整个数仓的数据实时流动起来，Streaming 是必不可少的。在数据都流动起来之后，汇合数据的流表二象性，以及 Flink 的流批一体剖析能力，就能够对流动中的任何一个环节的数据进行剖析，不论是短查问的秒级剖析，还是离线的 ETL 剖析，Flink 都具备相应能力。莫问示意，Flink 流批一体原来受到最大的限度就是两头没有能配套的存储数据结构，会让场景不好落地，只有把存储和数据结构补上，很多流批一体的化学反应天然就会呈现。
那 Flink 自建数据存储系统，是否会对大数据生态中现有的数据存储类我的项目带来肯定的冲击呢？对此莫问解释道，Flink 社区推出新的流批一体存储技术，是为了更好地配合本身流批一体计算的需要，会放弃存储和数据的凋谢协定、凋谢的 API 和 SDK，后续也有打算将此我的项目独立倒退。此外，Flink 也仍然会踊跃对接业界支流存储我的项目，放弃对外生态的兼容和凋谢。
大数据生态不同组件之间的边界正变得越来越含糊，莫问认为，当下的趋势是从繁多组件能力走向一体化解决方案。“大家其实都在顺着这个趋势走，比方你能够看到很多数据库我的项目，原来是 OLTP 起初加上了 OLAP，最初都叫 HTAP，实际上就是交融了行存和列存，既反对 Serving，又反对剖析，都是为了给用户提供一套残缺的数据分析体验。”莫问进一步补充示意：“目前很多零碎都开始一直拓展边界，从实时走向离线，或从离线走向实时，互相浸透。否则，用户就须要本人手动去组合各种技术组件，还要面对各种复杂性，门槛越来越高。所以，一体化的交融趋势是非常明显的。到底谁组合谁其实没有对错，要害是能不能用一种很好的交融形式，给用户提供最好的体验。谁做到了，谁就能博得最初的用户。社区要有生命力、继续倒退，仅仅把本人最善于的畛域做到极致是不够的，还要一直基于用户需要和场景去翻新和冲破边界，大部分用户的需要不肯定在繁多能力从 95 分到 100 分的差距上。”
据莫问预计，大概还须要一年左右的工夫能够造成一个绝对成熟的流式数仓计划。对于曾经采纳 Flink 作为实时计算引擎的用户，人造就适宜去尝试新的流式数仓计划，用户接口齐全兼容 Flink SQL。据走漏，在最新的 Flink 1.15 版本就会收回第一个 Preview 版本，正在应用 Flink 的用户都能够先试一试。莫问示意，基于 Flink 的流式数仓刚刚启动，技术计划还须要进一步迭代，间隔成熟还须要肯定工夫打磨，心愿能有更多企业和开发者带着本人的需要参加进来一起建设，这才是开源社区的价值。
结语
大数据开源生态组件泛滥、架构复杂度高的问题曾经被诟病了很多年，现在业界仿佛曾经在肯定水平上达成共识，即通过交融、一体化来推动数据架构往简化的方向演进，只管不同企业有不同的说法和实现门路。
在莫问看来，开源生态百花齐放很失常，每个技术社区都有本人善于的畛域，但真正要解决业务场景问题的话，还是须要一套一站式的解决方案，能力为用户提供简略易用的体验。因而他也认同总体趋势会往整合和交融的方向走，但可能性并不惟一，将来有可能专门有一个零碎来负责整合所有组件，也有可能每个零碎都逐步演变成一体化。哪一种可能性才是终局，或者只能等工夫给咱们答案了。
FFA 2021 视频回放 & 演讲 PDF 获取
关注「Apache Flink」公众号，回复 FFA2021
更多 Flink 相干技术问题，可扫码退出社区钉钉交换群
第一工夫获取最新技术文章和社区动静，请关注公众号～
