流批一体是数据领域的热门话题，随着实时数据处理需求的不断涌现和Flink等新兴流计算技术的持续发展，流批一体正从技术愿景向具体的、适配不同行业特点的解决方案过渡。 个人认为，流批一体解决方案的重点分为四个方面，数据集成、存储引擎、计算引擎、元数据管理。 数据集成 传统的批量数据集成方式是每日一次的批
流批一体是数据领域的热门话题，随着实时数据处理需求的不断涌现和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从社区参与者的角度看，相对更有优势。
一家之言，且从行业视角出发，难免有偏颇之处，欢迎留言批评指正。
小编推荐阅读
