“数据驱动”时代,企业为什么需要实时湖仓?

当谈到数据湖的时候,大家都在说,可以把所有数据(结构化/半结构化/非结构化)一股脑都丢进去,进行统一的元数据管理。然后上层计算对接,进行流批计算/OLAP 分析/算法分析。

这个没问题,数据湖确实能承接底层的这部分能力,但是同时出现的问题也是不容忽视的。

本文将关注讨论,利用湖仓架构,统一结构化/半结构化数据的流批计算,和大家聊聊为什么企业需要实时湖仓。非结构化的视频/图片/文本等数据的存储和计算不在本文的讨论范围内。

当前的企业困境

下图是一个经典的 Lambda 架构,虽然这套架构的优点很明显:技术方案成熟、应用实践广泛,适用于企业发展过程中各阶段、各场景下的大数据开发需求。

但是,随着业务对数据时效性要求的提高,许多企业的实时任务体量,正在逐步接近存量离线任务。在数据开发和运维资源有限的情况下,这套架构的问题正在逐渐暴露出来:

· 离线开发链路中的数据更新问题,在当前技术环境下显得越来越难以容忍

· 实时开发链路中的数据不落地问题,无法支持历史数据回溯、查询分析等场景

· 多种计算引擎,造成数据开发学习成本和运维管理成本的居高不下

· 多种存储介质,造成数据存储冗余、批/流数据不一致

· ……

解决之道:实时湖仓

下图是一种实时湖仓解决方案,利用湖存储的特性和 Flink 的流批计算能力,统一存储和计算,解决 Lambda 架构的问题。

本文以 Paimon 为例,Paimon 是 Flink 内部基于 Flink Tablestore 孵化的一款湖存储产品。和 Hudi/Iceberg 相比,Paimon 和 Flink 引擎有着更完整的兼容能力。

下面将就袋鼠云的实践经验,展开说说如何使用“Flink+数据湖”三步构建实时湖仓。

● Step1:搭建实时 ODS 层

不管是通过 Flink 消费 Kafka,还是通过 FlinkCDC 采集日志,都可以将源库数据实时同步至 Paimon 中。

这样,无论上层是要做批计算还是流计算,都有份统一的实时 ODS 数据做基础,避免了数据不一致和存储冗余的问题。

● Step2:加工湖仓中间层

关于实时湖仓的层级设计,可以参考成熟的离线数仓划分方案

从上面的架构图中可以看出,Paimon 存储将文件分为 DataFile 和 LogFile:

· DataFile 用于存量数据的批计算

· LogFile 用于增量数据的流计算,但毕竟是一种文件存储格式,其实时性只能做到分钟级别。如果业务场景对实时性有秒级/毫秒级要求,Paimon 也支持将 Kafka 外挂为 LogFile 使用,同时对上层应用暴露的,仍然只有一张 Paimon 表。

基于上面的特性,如何在实际应用体现出流/批一体能力,可以参考如下几种开发场景:

01 流、批独立任务

根据实际业务场景需要,使用 Flink+Paimon 的统一技术栈,进行离线任务和实时任务的独立开发。

02 批流一体任务

在很多实时统计类的数据开发场景下,往往需要在完成存量数据统计的基础上,再衔接实时增量计算。传统的 Lambda 架构要完成这种场景,实现上相对比较复杂,而使用 Flink+Paimon,一个任务即可满足。

03 流批一体任务

传统的 Lambda 架构中,为了保障 Flink+Kafka 实时计算的准确性,往往需要将 Kafka 数据双写一份到离线存储中,然后通过离线定时任务对实时计算结果做一次覆盖修正。而使用 Flink+Paimon,一个任务即可满足。

● Step3:湖仓分析应用层

这层有两种不同的落地方案,可以根据企业技术栈自由选型:

· ADS 层数据也在数据湖加工落地,然后使用 OLAP 引擎如 Trino、StarRocks 直接对接数据湖,向上层提供数据分析能力。这样做可以实现存储的完全统一,但是在查询分析性能上会有一定的牺牲。

· 将 DWS 层数据加工后打入 StarRocks 或者 ClickHouse 这类存储+分析的统一引擎。该方案可以充分利用这类引擎的查询加速能力,对于 OLAP 场景有较高要求的企业,是个比较合适的方案。

企业的其他选择?

目前业内比较热门的探索实践,不依赖 Hadoop 体系,仅利用 StarRocks/Doris 构建实时数仓的方式,大致的架构图如下:

理论上,该方案确实可行。StarRocks/Doris 本身作为计算+存储一体的引擎,具备向量化、MPP 架构、CBO、智能物化视图、可实时更新等能力,在一定程度上可以满足构建实时数仓的要求。

但是,在我们接触过的一些金融客户的实际应用中发现,当数据体量较大、视图逻辑较复杂时,该方案存在明显的性能瓶颈。

而根据 StarRocks/Doris 官网对自己高性能分析型数仓的定位,将它作为企业 OLAP 的选型,完全没有问题,但是寄希望于它承担全链路的大数据计算,目前来看还有很长的路要走。

所以,将实时湖仓部分层级的计算,前移至“Flink+数据湖”的架构中,仍然是当前技术方案中最优的选择。

本文根据《实时湖仓实践五讲第一期》直播内容总结而来,感兴趣的朋友们可免费获取直播课件:

直播课件:

https://www.dtstack.com/resources/1050?src=szsm

《数栈产品白皮书》:https://www.dtstack.com/resources/1004?src=szsm

《数据治理行业实践白皮书》下载地址:https://www.dtstack.com/resources/1001?src=szsm

想了解或咨询更多有关袋鼠云大数据产品、行业解决方案、客户案例的朋友,浏览袋鼠云官网:https://www.dtstack.com/?src=szbky

同时,欢迎对大数据开源项目有兴趣的同学加入「袋鼠云开源框架钉钉技术qun」,交流最新开源技术信息,qun号码:30537511,项目地址:https://github.com/DTStack

热门相关:落地一把98K   观察者   回来吃饭的男性朋友   我就允许你插入了   名门盛婚:首席,别来无恙!