流批一体的四块拼图

流批一体是数据范畴的热门话题，随着实时数据处理需求的不停涌现和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从社区参与者的角度看，相对更有优势。
一家之言，且从行业视角出发，难免有偏颇之处，欢迎留言批评指正。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。