简介:基于RocketMQ和Hudi零代码构建Lakehouse架构,以及RocketMQ Connector & RocketMQ Stream助力ETL数据分析,为大家提供快速构建Lakehouse的技术方案和低运维成本实现实时计算的解决方案。
本文目录
- 背景知识
- 大数据时代的构架演进
- RocketMQ Connector&Stream
- Apache Hudi
- 构建Lakehouse实操
本文标题包含三个关键词:Lakehouse、RocketMQ、Hudi。我们先从整体Lakehouse架构入手,随后逐步分析架构产生的原因、架构组件特点以及构建Lakehouse架构的实操部分。
背景知识
1、Lakehouse架构
Lakehouse最初由Databrick提出,并对Lakehouse架构特征有如下要求:
(1)事务支持
企业内部许多数据管道通常会并发读写数据。对ACID事务的支持确保了多方并发读写数据时的一致性问题;
(2)Schema enforcement and governance
Lakehouse应该有一种方式可以支持模式执行和演进、支持DW schema的范式(如星星或雪花模型),能够对数据完整性进行推理,并且具有健壮的治理和审计机制;
(3)开放性
使用的存储格式是开放式和标准化的(如parquet),并且为各类工具和引擎,包括机器学习和Python/R库,提供API,以便它们可以直接有效地访问数据;
(4)BI支持
Lakehouse可以直接在源数据上使用BI工具。这样可以提高数据新鲜度、减少延迟,并且降低了在数据池和数据仓库中操作两个数据副本的成本;
(5)存储与计算分离
在实践中,这意味着存储和计算使用单独的集群,因此这些系统能够扩展到支持更大的用户并发和数据量。一些现代数仓也具有此属性;
(6)支持从非结构化数据到结构化数据的多种数据类型
Lakehouse可用于存储、优化、分析和访问许多数据应用所需的包括image、video、audio、text以及半结构化数据;
(7)支持各种工作负载
包括数据科学、机器学习以及SQL和分析。可能需要多种工具来支持这些工作负载,但它们底层都依赖同一数据存储库;
(8)端到端流
实时报表是许多企业中的标准应用。对流的支持消除了需要构建单独系统来专门用于服务实时数据应用的需求。
从上述对Lakehouse架构的特点描述我们可以看出,针对单一功能,我们可以利用某些开源产品组合构建出一套解决方案。但对于全部功能的支持,目前好像没有一个通用的解决方案。接下来,我们先了解大数据时代主流的数据处理架构是怎样的。
大数据时代的架构演进
1、大数据时代的开源产品
大数据时代的开源产品种类繁多,消息领域的RocketMQ、Kafka;计算领域的flink、spark、storm;存储领域的HDFS、Hbase、Redis、ElasticSearch、Hudi、DeltaLake等等。
为什么会产生这么多开源产品呢?首先在大数据时代数据量越来越大,而且每个业务的需求也各不相同,因此就产生出各种类型的产品供架构师选择,用于支持各类场景。然而众多的品类产品也给架构师们带来一些困扰,比如选型困难、试错成本高、学习成本高、架构复杂等等。
2、当前主流的多层架构
大数据领域的处理处理场景包含数据分析、BI、科学计算、机器学习、指标监控等场景,针对不同场景,业务方会根据业务特点选择不同的计算引擎和存储引擎;例如交易指标可以采用binlog + CDC+ RocketMQ + Flink + Hbase + ELK组合,用于BI和Metric可视化。
(1)多层架构的优点:支持广泛的业务场景;
(2)多层架构的缺点:
- 处理链路长,延迟高;
- 数据副本多,成本翻倍;
- 学习成本高;
造成多层架构缺点主要原因是存储链路和计算链路太长。
- 我们真的需要如此多的解决方案来支持广泛的业务场景吗?Lakehouse架构是否可以统一解决方案?
- 多层架构的存储层是否可以合并?Hudi产品是否能够支持多种存储需求?
- 多层架构的计算层是否可以合并?RocketMQ stream是否能够融合消息层和计算层?
当前主流的多层架构
3、Lakehouse架构产生
Lakehouse架构是多层架构的升级版本,将存储层复杂度继续降低到一层。再进一步压缩计算层,将消息层和计算层融合,RocketMQ stream充当计算的角色。我们得到如下图所示的新架构。新架构中,消息出入口通过RocketMQ connector实现,消息计算层由RocketMQ stream实现,在RocketMQ内部完成消息计算中间态的流转;计算结果通过RocketMQ-Hudi-connector收口落库Hudi,Hudi支持多种索引,并提供统一的API输出给不同产品。