Flink 和 Iceberg 如何解决数据入湖面临的挑战

简介： 4.17 上海站 Meetup 胡争老师分享内容：数据入湖的挑战有哪些，以及如何用 Flink + Iceberg 解决此类问题。

一、数据入湖的核心挑战

数据实时入湖可以分成三个部分，分别是数据源、数据管道和数据湖（数仓），本文的内容将围绕这三部分展开。

1. Case #1：程序 BUG 导致数据传输中断

• 首先，当数据源通过数据管道传到数据湖（数仓）时，很有可能会遇到作业有 BUG 的情况，导致数据传到一半，对业务造成影响；
• 第二个问题是当遇到这种情况的时候，如何重起作业，并保证数据不重复也不缺失，完整地同步到数据湖（数仓）中。

2. Case #2：数据变更太痛苦

• 数据变更

  当发生数据变更的情况时，会给整条链路带来较大的压力和挑战。以下图为例，原先是一个表定义了两个字段，分别是 ID 和 NAME。此时，业务方面的同学表示需要将地址加上，以方便更好地挖掘用户的价值。

  首先，我们需要把 Source 表加上一个列 Address，然后再把到 Kafka 中间的链路加上链，然后修改作业并重启。接着整条链路得一路改过去，添加新列，修改作业并重启，最后把数据湖（数仓）里的所有数据全部更新，从而实现新增列。这个过程的操作不仅耗时，而且会引入一个问题，就是如何保证数据的隔离性，在变更的过程中不会对分析作业的读取造成影响。

  

• 分区变更

  如下图所示，数仓里面的表是以 “月” 为单位进行分区，现在希望改成以 “天” 为单位做分区，这可能就需要将很多系统的数据全部更新一遍，然后再用新的策略进行分区，这个过程十分耗时。

  

3. Case #3：越来越慢的近实时报表？

当业务需要更加近实时的报表时，需要将数据的导入周期，从 “天” 改到 “小时”，甚至 “分钟” 级别，这可能会带来一系列问题。

如上图所示，首先带来的第一个问题是：文件数以肉眼可见的速度增长，这将对外面的系统造成越来越大的压力。压力主要体现在两个方面：

• 第一个压力是，启动分析作业越来越慢，Hive Metastore 面临扩展难题，如下图所示。

  

  • 随着小文件越来越多，使用中心化的 Metastore 的瓶颈会越来越严重，这会造成启动分析作业越来越慢，因为启动作业的时候，