流批一体的四块拼图

流批一体是数据领域的热门话题,随着实时数据处理需求的不断涌现和Flink等新兴流计算技术的持续发展,流批一体正从技术愿景向具体的、适配不同行业特点的解决方案过渡。

个人认为,流批一体解决方案的重点分为四个方面,数据集成、存储引擎、计算引擎、元数据管理

  • 数据集成

传统的批量数据集成方式是每日一次的批量数据传输,其载体是文件。实时数据集成方式则是通过CDC工具或者调用API接口推送的方式实时进行数据传输,载体是消息,依赖Kafka等消息队列。在Lambda架构中,这两者是同时存在的,是批量和实时两条数据加工链条的起点。

从时效性上,实时方式有着显著优势,数据延迟最快可以达到秒级甚至毫秒级,所以Kappa架构倡导将两者合一,全面采用实时数据集成方式。

在Kappa架构提出多年后,这一设想并未被普遍采纳,我认为其中部分原因是,实时数据集成的稳定性不足,以CDC工具和Kafka组成数据传输链路存在一定的数据丢失及重复的可能性。所以,在数据准确性有严苛要求的场景并不适用,金融行业尤其如此。当然,这种数据的偏差在其他行业或许无关紧要,比如统计实时交通情况,个别车辆信息的丢失并不会影响对道路拥堵情况的判断。

除了准确性,第二点是数据边界问题。实时数据是以流的概念来看待数据,数据就像河水一样源源不断,不存在明显的数据边界。但在金融场景中,因为业务原因,数据是存在边界的。比较容易理解的例子是存款计息,总要有一个时点决定是否为用户多计算1天的利息,这是所谓的业务日期翻牌。两种对数据的不同理解,这有点像波粒二相性。

虽然有准确性和数据边界问题,但不代表我们只能停留在Lambda架构阶段。

实时数据集成链路的技术在不断发展,例如Kafka在0.11版本后增加了幂等性的支持,可以避免网络抖动导致的消息重复写入。应用层面也可以进行弥补,比如在生产者一侧对一段数据流增加数据摘要信息,这样就可以在目标端判断数据完整性并做后续处理。我对实时链路的技术发展持乐观态度,数据丢失和重复的问题是可以被解决的,而且不需要太久。第二点,在金融行业数据边界问题虽然存在,但仍然有大量数据可以被看作流的形态。

如果对幂等性和数据摘要技术感兴趣,可以翻看下我公众号之前的文章。

小结一下,基于金融行业特点,阶段性目标是实时数据集成将会占据主导地位,批量集成模式因为数据边界问题暂时还会存在,但可以压缩到较低的占比。在达到这一目标后,数据边界问题也有机会用技术手段实现,完全实时数据集成。

  • 存储引擎

存储引擎可以展开为三个层面,底层存储、文件格式和表格式。

大数据架构下HDFS仍然是主要的存储方式,其设计目标是为了适应海量数据处理,默认数据文件较大。例如,HDFS数据块默认大小是128M,显著高于普通的文件系统。随着,海量数据的真正到来,基于本地磁盘的HDFS也有显著的成本压力,而对象存储因为成本优势和对小文件的友好性,成为各个企业的重要选项。当然,对象存储在性能上的衰减还非常明显的,所以现阶段大多还是存储容量上的补充手段。随着冷热数据自动迁移技术的成熟,对象存储的应用将更加广泛。同时,对象存储也是存算分离议题的主角,值得探讨的内容很多,这里不再展开,后续单独讨论。

文件格式层面,按照技术特征分为列式存储和行式存储两种,前者的代表是Parquet和ORC,后者的代表是Avro,实时链路中数据是按照产生的次序进行推送,所以在传输过程中多采用行式存储格式进行序列化(Avro也是一种序列化框架),而落地数据往往采用Parquet等列式存储更能提升处理性能。

在Hudi/Iceberg等技术出现后,表格式(table format)成为存储引擎中的新成员,基于Hudi/Iceberg可以进行数据update和delete操作,相对于之前只能采用全量覆盖方式(overwrite),极大的改善了Hadoop体系下增量数据的处理效率,使得那些在MPP数据库上积累的数据建模方法,可以更多的迁移到Hadoop体系。

小结一下,存储引擎侧的重要变革是表格式的引入,提供更高效的update和delete操作能力,所以无论是对实时数据处理还批量数据处理,都有显著的帮助。

  • 计算引擎

Hadoop生态体系中,Hive/Spark/Flink都是占有重要地位的计算引擎。严格来讲Hive并不是计算引擎,通常是指代Hive+MapReduce,其中MapReduce才是Hadoop的初代计算引擎。但随着技术发展,尤其是Hadoop主要供应商Cloudera将产品升级到CDP后,默认引擎从MapReduce切换为Tez,MapReduce已经逐渐退出舞台,只是作为遗留技术存在。Spark社区有着强大的生命力和广泛的影响,在性能上较MapReduce有显著优势,还适用于批量、流计算、AI等多种场景。Flink作为新兴计算引擎,在产生之初就以实时计算为目标场景,而后展露出更大的野心,将目标锁定为流批一体的计算引擎。同时,还衍生出配套的存储开源组件Paimon。

小结一下,Spark和Flink都有可能实现计算引擎层面的流批一体,而国内程序员对Flink社区的参与度更高,这或许将成为Flink的一种优势,影响未来流批一体计算引擎的市场占有率。

  • 元数据管理

元数据一直是数据领域必不可少,但又不温不火的话题。元数据对于打造自动化数据流水线至关重要。同时,元数据也是衔接流式数据和批量数据的重要纽带。

Hadoop体系下,HMS(HiveMetaStore)是元数据管理的事实标准,虽然HMS诞生之初仅是Hive的附属组件,但由于Hive曾经巨大市场占有率,其他计算引擎要融入生态必须主动适配HMS,得益于开源的独特优势,HMS也没有禁止这种适配。由此,HMS逐渐被视为一种中立的元数据管理组件。所以,即使Hive会伴随着MapReduce退出而逐渐衰落,但HMS仍然具有强大的、独立的生命力。

流批一体的愿景下,元数据管理的提升目标是弥补批量数据集成链路的天生缺陷,提升流批一体的自动化能力和集成能力。传统的批量数据集成,仅仅集成了数据本身,并没有附带元数据(如表结构信息),元数据在源端和目标端的一致性,完全依靠人工的线下沟通而后分别投产。这种人工机制的风险性不言而喻,在海量数据的背景下,引发问题的绝对数量不会太小。

依托CDC工具的实时数据集成链路,有机会实现系统间的元数据自动对接。事实上,OGG(Oracle Golden Gate)等工具已经提供了实时推送表结构变更的能力,可以通过SR(Schema Registry)接收,但SR与HMS之间的协同还需要进一步处理。由此看来,HMS现阶段提供的还是以批量场景为主的元数据管理能力。

基于我们在数据集成部分的结论,批量数据和流数据在相当长时间内仍会并存,而这两者在使用场景上又不是完全割裂的,所以元数据管理模块要同时兼容这两种形态的数据。

小结一下,HMS是元数据管理的事实标准,具有支撑流批一体架构的能力,但在自动化能力和集成能力等方面仍有提升空间,特别是对实时数据的元数据管理能力有待进一步加强。或许,其他元数据管理组件也会借此挑战HMS的地位,比如Databricks今年开源的Unity Catalog。

最后总结一下,本文中我们将流批一体分为数据集成、存储引擎、计算引擎和元数据管理四个方面,其中元数据管理和存储引擎的统一规范是强约束,技术产品是排他的;数据集成层面以实时链路为主,批量链路为辅;计算引擎则是可分可合,不一定是单一计算引擎通吃的局面,而Flink从社区参与者的角度看,相对更有优势。

一家之言,且从行业视角出发,难免有偏颇之处,欢迎留言批评指正。