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，其中考虑的原因有以下几方面：

• iceberg深度集成flink

  前面讲到，我们的绝大部分任务都是flink任务，包括批处理任务和流处理任务，目前这三个数据湖框架，iceberg是集成flink做的最完善的，如果采用iceberg替代hive之后，迁移的成本非常小，对用户几乎是无感知的，

  比如我们原来的sql是这样的，

  INSERT INTO hive_catalog.db.hive_table SELECT * FROM kafka_table

  迁移到iceberg以后，只需要修改catalog就行了.
  INSERT INTO iceberg_catalog.db.iceberg_table SELECT * FROM kafka_table

  presto查询也是和这个类似，只需要修改catalog就行了。