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

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

   数栈君   发表于 2023-09-05 17:42  685  0

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


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


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


当前的企业困境


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

http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user166259/article/5fe146a9969a1fa810a39296f178e70c..png


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

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

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

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

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

· ……


解决之道:实时湖仓


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

http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user166259/article/0d3090a86b5520c8ced9bf5364eccd5a..png


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


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


● Step1:搭建实时 ODS 层

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


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

http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user166259/article/44c819bd1635cde1605eae5ad839ded2..png


● Step2:加工湖仓中间层

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

http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user166259/article/24f1fcf6ba06f9ebd682053c6232e785..png


从上面的架构图中可以看出,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 直接对接数据湖,向上层提供数据分析能力。这样做可以实现存储的完全统一,但是在查询分析性能上会有一定的牺牲。

http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user166259/article/617d22b7107dfb48aeafdb5e2837dee8..png


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

http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user166259/article/3aa14b2a82feaad7e233923c16fa8872..png


企业的其他选择?


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

http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user166259/article/bcfa1c836b1949d5f08131ab873d836d..png


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


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


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


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


本文根据《实时湖仓实践五讲第一期》直播内容总结而来,感兴趣的朋友们可点击链接观看直播回放视频及免费获取直播课件:


直播课件:

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




《数据治理行业实践白皮书》下载地址:https://fs80.cn/4w2atu

《数栈V6.0产品白皮书》下载地址:
https://fs80.cn/cw0iw1

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

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

0条评论
上一篇:实时湖仓校验
社区公告
  • 大数据领域最专业的产品&技术交流社区,专注于探讨与分享大数据领域有趣又火热的信息,专业又专注的数据人园地

最新活动更多
微信扫码获取数字化转型资料
钉钉扫码加入技术交流群