大数据之流批一体化

1、流批一体的理念

随着互联网和移动互联网的不停发展，各行各业都积累海量的业务数据。而企业为了改善用户体验，提拔产物在市场上的竞争力，都接纳了及时化方式来处理大数据。交际媒体的及时大屏、电商的及时保举、都会大脑的及时交通预测、金融行业的及时反欺诈，这些产物的成功都在说明大数据处理的及时化已经成为一个势不可挡的潮流。
在及时化的大趋势下，Flink 已经成为及时盘算行业的究竟标准。国内外各个范畴的头部厂商，都把 Flink 做为及时盘算的技术底座，国内有字节跳动、腾讯、华为，国外有 Netflix、Uber 等等。
而业务及时化只是一个出发点，Flink 的目标之一就是给用户提供及时离线一体化的用户体验。着实很多用户不但需要及时的数据统计，为了确认运营或产物的策略的结果，用户同时还需要和历史（昨天，以致是去年的同期）数据比较。而从用户的角度来看，原有的流、批独立方案存在一些痛点：

• 人力本钱比较高。由于流和批是两套体系，相同的逻辑需要两个团队开发两遍。
  
• 数据链路冗余。在很多的场景下，流和批盘算内容着实是一致，但是由于是两套体系，以是相同逻辑照旧需要运行两遍，产生一定的资源浪费。
  
• 数据口径不一致。这个是用户遇到的最紧张的问题。两套体系、两套算子，两套 UDF，一定会产生差别水平的误差，这些误差给业务方带来了非常大的困扰。这些误差不是简单依赖人力或者资源的投入就可以解决的。
  

2020年，阿里巴巴及时盘算团队提出“流批一体”的理念，盼望依托Flink框架解决企业数据分析的3个核心问题，理念中包含三个着力点，分别是一套班子、一套体系、一个逻辑。

• 一套班子：同一开发人员脚色，现阶段企业数据分析有两个团队，一个团队负责及时开发，一个团队负责离线开发，在流批一体的理念中，盼望促进两个团队的融合。
  
• 一套体系：同一数据处理技术，不管及时开发，照旧离线开发都是用Flink框架举行，如非须要，尽大概少用其它体系。
  
• 一个逻辑：当前企业数据分析，有两套班子，两套技术体系，两套盘算模式，导致及时数据和离线数据常常对不上，盼望通过Flink SQL的方式，让离线和及时盘算逻辑保持一致。
  

简言之，流批一体的理念即：

使用同一套 API、同一套开发范式来实现大数据的流盘算和批盘算，进而保证处理过程与结果的一致性。

但是，之前Flink不停夸大的仅仅是盘算层的流批一体，至于流批一体，还有哪些层面呢？

• 数据集成流批一体：离线与及时是否使用同一数据采集方式；如同一通过 CDC 或者 OGG 将数据及时捕获推送到 kafka，批与流在从 kafka 中消费数据，载入明细层。
  
• 数据存储流批一体：离线与及时数据是否同一分层、同一存储；兼容数据的一致性和及时性。
  
• 处理逻辑流批一体：流与批处理是否使用同一 SQL 语法或者 ETL 组件，再通过底层分别适配流与批盘算引擎，保证数据口径的一致性。
  
• 盘算引擎流批一体：流与批使用同一套盘算引擎，从根本上制止同一个处理逻辑流批两套代码问题。
  

着实，在解决了盘算层的问题之后，掣肘的便是数据存储。如今，很多及时数仓中，及时链路采用kafka之类的消息队列，但是中间消息队列数据倒霉于分析。假如用户想要分析及时链路中一个明细层的数据，着实非常不方便，很多用户如今采用的办法大概是先把这个明细层中的数据导出来，比如导到 Hive 做离线分析，但这个时效性会大幅降落，或者为了加快查询，把数据导入到其他 OLAP 引擎中，但这又会增加体系复杂度，且数据一致性同样很难保证。
截止到如今，整个行业还没有完整的一站式解决盘算引擎和数据存储流批一体的技术方案，这对当前流式盘算引擎提出了更高的要求和挑战，不外庆幸的是，flink已经在这方面结构，在下一个迭代版本flink1.5中，被定义为流批一体的数据存储体系的Flink Dynamic Table即将面世。
毫无疑问，这对整个行业是巨大的创新。
2、及时数仓的演进

提到flink发展存储体系，我们不得不先回顾传统大数据架构的演化过程，以史为镜，才气发现存储盘算的一体的紧张性和紧急性。
及时数仓的架构，从经典的主题建模，到维度建模，再到hadoop体系，后面的lamda架构，kappa架构，在渐渐美满，但不停没有形成完整的解决方案。
2.1 离线数仓

使用hadoop平台的hive做数据仓库，报表层数据保存在mysql中，使用tableau做报表体系，这样不消担心存储问题、盘算速度也大大加快了。在此根本上，提供hue给各个部分使用，这样简单的取数工作可以由运营本身来利用，使用presto可以做mysql、hive的跨库查询，大大提拔了查询效率。
2.2 Lambda架构

为了盘算一些及时指标，就在原来离线数仓的根本上增加了一个及时盘算的链路，并对数据源做流式改造（即把数据发送到消息队列），及时盘算去订阅消息队列，直接完成指标增量的盘算，推送到下游的数据服务中去，由数据服务层完成离线&及时结果的归并。
需要注意的是流处理盘算的指标批处理依然盘算，最终以批处理为准，即每次批处理盘算后会覆盖流处理的结果（这仅仅是流处理引擎不美满做的折中）。
Lambda架构整合离线盘算和及时盘算，融合不可变性（Immunability），读写分离和复杂性隔离等一系列架构原则，可集成Hadoop，Kafka，Storm，Spark，Hbase等各类大数据组件。
同样的需求需要开发两套一样的代码，这是Lambda架构最大的问题，两套代码不但仅意味着开发困难（同样的需求，一个在批处理引擎上实现，一个在流处理引擎上实现，还要分别构造数据测试保证两者结果一致），后期维护更加困难，比如需求变更后需要分别更改两套代码，独立测试结果，且两个作业需要同步上线。
此外，同样的逻辑盘算两次，团体资源占用会增多（多出及时盘算这部分）。下游需要整合及时和离线处理结果，处理比较复杂，
2.3 Kappa架构

再厥后，及时的业务越来越多，事件化的数据源也越来越多，及时处理从次要部分变成了主要部分，架构也做了相应调解，出现了以及时事件处理为核心的Kappa架构。固然这不要实现这一变革，还需要技术本身的革新——Flink，Flink 的出现使得Exactly-Once 和状态盘算成为大概，这个时候及时盘算的结果保证最终结果的正确性。
Lambda架构固然满意了及时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不美满，流处理的结果只作为暂时的、近似的值提供参考。厥后随着Flink等流处理引擎的出现，流处理技术很成熟了，这时为了解决两套代码的问题，LickedIn 的Jay Kreps提出了Kappa架构。
Kappa架构可以以为是Lambda架构的简化版（只要移除lambda架构中的批处理部分即可）。在Kappa架构中，需求修改或历史数据重新处理都通过上游重放完成。
存在的问题：Kappa架构最大的问题是流式重新处理历史的吞吐本领会低于批处理，但这个可以通过增加盘算资源来弥补。
2.4 混合架构

在真实的场景中，很多时候并不是完全规范的Lambda架构或Kappa架构，可以是两者的混合，比如大部分及时指标使用Kappa架构完成盘算，少量关键指标（比如金额相干）使用Lambda架构用批处理重新盘算，增加一次校对过程。
Kappa架构并不是中间结果完全不落地，如今很多大数据体系都需要支持呆板学习（离线练习），以是及时中间结果需要落地对应的存储引擎供呆板学习使用，别的偶然候还需要对明细数据查询，这种场景也需要把及时明细层写出到对应的引擎中。
还有就是Kappa这种以及时为主的架构计划，除了增加了盘算难度，对资源提出了更改的要求之外，还增加了开发的难度，以是才有了下面的混合架构，可以看出这个架构的出现，美满是出于需求和现状思量的。
混合架构在解决了部分业务问题的同时，也带了架构的复杂性，在盘算引擎及存储介质上，存在多元性，那么不管是学习本钱照旧开发本钱以及后期的维护本钱，都是指数级的增长，未必是一种最优的选择。
同样，混合架构支持及时入湖、入湖及时增量分析，但这些场景的及时性大打扣头，由于数据湖存储格式本质照旧 Mini-Batch，及时盘算在混合架构中退化到 Mini-Batch 模式。毫无疑问，这对及时性要求很高的业务是很大的劫难。
3、流式数仓

数据集成、差别数据源之间的数据同步对于很多团队来说是刚需，但传统方案每每复杂度太高且时效性欠好。传统的数据集成方案通常是离线数据集成和及时数据集因素别采用两套技术栈，其中涉及很多数据同步工具，比如 Sqoop、DataX 等，这些工具要么只能做全量要么只能做增量，开发者需要本身控制全增量的切换，共同起来比较复杂。
这个时候，Flink cdc粉墨登场，对变更数据及时捕获。基于 Flink 的流批一体本领和 Flink CDC，只需要写一条 SQL，就可以做到先全量同步历史数据，再主动断点续传增量数据，实现一站式数据集成。全程无需用户判定和干预，Flink 能主动完成批流之间的切换并保证数据的一致性。
Flink 可以让当前业界主流数仓架构再进阶一层，实现真正端到端全链路的及时化分析本领，即：当数据在源头发生变革时就能捕获到这一变革，并支持对它做逐层分析，让所有数据及时活动起来，而且对所有活动中的数据都可以及时查询。再借助 Flink 完备的流批一体本领，使用同一套 API 就可以同时支持机动的离线分析。这样一来，及时、离线以及交互式查询分析、短查询分析等，就可以同一成一整套解决方案，成为抱负中的“流式数仓（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 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 的增量变革做及时分析，如今支持插件化实现。
未来，使用 Flink CDC、Flink SQL、Flink Dynamic Table 就可以构建一套完整的流式数仓，实实际时离线一体化及对应盘算存储一体化的体验。那便是大数据技术，flink技术发展的又一个精进高度。