位置:编程技术网 > 区块链 > 正文 >

Flink集成Iceberg在同程艺龙的实践

2021年03月27日 05:30来源:未知手机版

心意兑换券,刺客信条1中文补丁,幻浪动漫


>

策划 | 蔡芳芳

过去几年,数据仓库和数据湖方案在快速演进和弥补自身缺陷的同时,二者之间的边界也逐渐淡化。云原生的新一代数据架构不再遵循数据湖或数据仓库的单一经典架构,而是在一定程度上结合二者的优势重新构建。在云厂商和开源技术方案的共同推动之下,2021 年我们将会看到更多“湖仓一体”的实际落地案例。InfoQ 希望通过选题的方式对数据湖和数仓融合架构在不同企业的落地情况、实践过程、改进优化方案等内容进行呈现。本文将分享同程艺龙将 Flink 与 Iceberg 深度集成的落地经验和思考。

背景及痛点

业务背景

同程艺龙是一个提供机票、住宿、交通等服务的在线旅游服务平台,目前我所在的部门属于公司的研发部门,主要职责是为公司内其他业务部门提供一些基础服务,我们的大数据系统主要承接的业务是部门内的一些大数据相关的数据统计、分析工作等。数据来源有网关日志数据、服务器监控数据、K8s 容器的相关日志数据,App 的打点日志, MySQL 的 binlog 日志等。我们主要的大数据任务是基于上述日志构建实时报表,提供基于 Presto 的报表展示和即时查询服务,同时也会基于 Flink 开发一些实时、批处理任务,为业务方提供准确及时的数据支撑。

原架构方案

由于我们所有的原始数据都是存储在 Kafka 的,所以原来的技术架构就是首先是 Flink 任务消费 Kafka 的数据,经过 Flink SQL 或者 Flink jar 的各种处理之后实时写入 Hive,其中绝大部分任务都是 Flink SQL 任务,因为我认为 SQL 开发相对代码要简单的多,并且维护方便、好理解,所以能用 SQL 写的都尽量用 SQL 来写。

提交 Flink 的平台使用的是 Zeppelin,其中提交 Flink SQL 任务是 Zeppelin 自带的功能,提交 jar 包任务是我自己基于 Application 模式开发的 Zeppelin 插件。

对于落地到 Hive 的数据,使用开源的报表系统 metabase (底层使用 Presto) 提供实时报表展示、定时发送邮件报表,以及自定义 SQL 查询服务。由于业务对数据的实时性要求比较高,希望数据能尽快的展示出来,所以我们很多的 Flink 流式任务的 checkpoint 设置为 1 分钟,数据格式采用的是 orc 格式。

痛点

由于采用的是列式存储格式 ORC,无法像行式存储格式那样进行追加操作,所以不可避免的产生了一个大数据领域非常常见且非常棘手的问题,即 HDFS 小文件问题。

开始的时候我们的小文件解决方案是自己写的一个小文件压缩工具,定期去合并,我们的 Hive 分区一般都是天级别的,所以这个工具的原理就是每天凌晨启动一个定时任务去压缩昨天的数据,首先把昨天的数据写入一个临时文件夹,压缩完,和原来的数据进行记录数的比对检验,数据条数一致之后,用压缩后的数据覆盖原来的数据,但是由于无法保证事务,所以出现了很多问题:

压缩的同时由于延迟数据的到来导致昨天的 Hive 分区又有数据写入了,检验就会失败,导致合并小文件失败。

替换旧数据的操作是没有事务保证的,如果替换的过程中旧分区有新的数据写入,就会覆盖新写入的数据,造成数据丢失。

没有事务的支持,无法实时合并当前分区的数据,只能合并压缩前一个分区的,最新的分区数据仍然有小文件的问题,导致最新数据查询性能提高不了。

Flink+Iceberg 的落地

Iceberg 技术调研

所以基于以上的 HDFS 小文件、查询慢等问题,结合我们的现状,我调研了目前市面上的数据湖技术:Delta、Apache Iceberg 和 Apache Hudi,考虑了目前数据湖框架支持的功能和以后的社区规划,最终我们是选择了 Iceberg,其中考虑的原因有以下几方面:

本文地址:http://www.reviewcode.cn/qukuailian/202444.html 转载请注明出处!

今日热点资讯