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

 GitHub 地址 

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

• 首先，当数据源通过数据管道传到数据湖（数仓）时，很有可能会遇到作业有 BUG 的情况，导致数据传到一半，对业务造成影响；

  
  

• 第二个问题是当遇到这种情况的时候，如何重起作业，并保证数据不重复也不缺失，完整地同步到数据湖（数仓）中。

  
  

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

• 数据变更

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

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

• 分区变更

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

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

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

• 随着小文件越来越多，使用中心化的 Metastore 的瓶颈会越来越严重，这会造成启动分析作业越来越慢，因为启动作业的时候，会把所有的小文件原数据都扫一遍。
• 第二是因为 Metastore 是中心化的系统，很容易碰到 Metastore 扩展难题。例如 Hive，可能就要想办法扩后面的 MySQL，造成较大的维护成本和开销。

• 第二个压力是扫描分析作业越来越慢。

随着小文件增加，在分析作业起来之后，会发现扫描的过程越来越慢。本质是因为小文件大量增加，导致扫描作业在很多个 Datanode 之间频繁切换。

4. Case #4：实时地分析 CDC 数据很困难

• 首先从源端来看，比如要将 MySQL 的数据同步到数据湖进行分析，可能会面临一个问题，就是 MySQL 里面有存量数据，后面如果不断产生增量数据，如何完美地同步全量和增量数据到数据湖中，保证数据不多也不少。

• 此外，假设解决了源头的全量跟增量切换，如果在同步过程中遇到异常，如上游的 Schema 变更导致作业中断，如何保证 CDC 数据一行不少地同步到下游。

• 整条链路的搭建，需要涉及源头全量跟同步的切换，包括中间数据流的串通，还有写入到数据湖（数仓）的流程，搭建整个链路需要写很多代码，开发门槛较高。

• 最后一个问题，也是关键的一个问题，就是我们发现在开源的生态和系统中，很难找到高效、高并发分析 CDC 这种变更性质的数据。

5. 数据入湖面临的核心挑战

• 数据同步任务中断

• 无法有效隔离写入对分析的影响；
• 同步任务不保证 exactly-once 语义。

• 端到端数据变更

• DDL 导致全链路更新升级复杂；
• 修改湖/仓中存量数据困难。

• 越来越慢的近实时报表




• 频繁写入产生大量小文件；
• Metadata 系统压力大, 启动作业慢；
• 大量小文件导致数据扫描慢。

• 无法近实时分析 CDC 数据




• 难以完成全量到增量同步的切换；
• 涉及端到端的代码开发，门槛高；
• 开源界缺乏高效的存储系统。

1. Netflix：Hive 上云痛点总结

■ 痛点一：数据变更和回溯困难

1. 不提供 ACID 语义。在发生数据改动时，很难隔离对分析任务的影响。典型操作如：INSERT OVERWRITE；修改数据分区；修改 Schema；

   
   

2. 无法处理多个数据改动，造成冲突问题；

   
   

3. 无法有效回溯历史版本。

■ 痛点二：替换 HDFS 为 S3 困难

1. 数据访问接口直接依赖 HDFS API；

   
   

2. 依赖 RENAME 接口的原子性，这在类似 S3 这样的对象存储上很难实现同样的语义；

   
   

3. 大量依赖文件目录的 list 接口，这在对象存储系统上很低效。

■ 痛点三：太多细节问题

1. Schema 变更时，不同文件格式行为不一致。不同 FileFormat 甚至连数据类型的支持都不一致；

   
   

2. Metastore 仅维护 partition 级别的统计信息，造成不 task plan 开销；Hive Metastore 难以扩展；

   
   

3. 非 partition 字段不能做 partition prune。

2. Apache Iceberg 核心特性

• 通用化标准设计

• 完美解耦计算引擎
• Schema 标准化
• 开放的数据格式
• 支持 Java 和 Python

  
  

• 完善的 Table 语义

• Schema 定义与变更
• 灵活的 Partition 策略
• ACID 语义
  Snapshot 语义

  
  

• 丰富的数据管理

• 存储的流批统一
• 可扩展的 META 设计支持
• 批更新和 CDC
• 支持文件加密

  
  

• 性价比

• 计算下推设计
• 低成本的元数据管理
• 向量化计算
• 轻量级索引

3. Apache Iceberg File Layout

4. Apache Iceberg Snapshot View

• 最上面黄色的是快照；

• 中间蓝色的是 Manifest；

• 最下面是文件。

5. 选择 Apache Iceberg 的公司

• NetFlix 现在是有数百PB的数据规模放到 Apache Iceberg 之上，Flink 每天的数据增量是上百T的数据规模。

  
  

• Adobe 每天的数据新增量规模为数T，数据总规模在几十PB左右。

  
  

• AWS 把 Iceberg 作为数据湖的底座。

  
  

• Cloudera 基于 Iceberg 构建自己整个公有云平台，像 Hadoop 这种 HDFS 私有化部署的趋势在减弱，上云的趋势逐步上升，Iceberg 在 Cloudera 数据架构上云的阶段中起到关键作用。

  
  

• 苹果有两个团队在使用：

• 一是整个 iCloud 数据平台基于 Iceberg 构建；
• 二是人工智能语音服务 Siri，也是基于 Flink 跟 Iceberg 来构建整个数据库的生态。

回到最关键的内容，下面阐述 Flink 和 Iceberg 如何解决第一部分所遇到的一系列问题。

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

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

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

• 第一个方案是在写入的时候优化小文件的问题，按照 Bucket 来 Shuffle 方式写入，因为 Shuffle 这个小文件，写入的文件就自然而然的小。

  
  

• 第二个方案是批作业定期合并小文件。

  
  

• 第三个方案相对智能，就是自动增量地合并小文件。

4. Case #4：实时地分析CDC数据很困难

• 首先是是全量跟增量数据同步的问题，社区其实已有 Flink CDC Connected 方案，就是说 Connected 能够自动做全量跟增量的无缝衔接。

• 第二个问题是在同步过程中，如何保证 Binlog 一行不少地同步到湖中， 即使中间碰到异常。

对于这个问题，Flink 在 Engine 层面能够很好地识别不同类型的事件，然后借助 Flink 的 exactly once 的语义，即使碰到故障，它也能自动做恢复跟处理。

• 第三个问题是搭建整条链路需要做不少代码开发，门槛太高。

在用了 Flink 和 Data Lake 方案后，只需要写一个 source 表和 sink 表，然后一条 INSERT INTO，整个链路就可以打通，无需写任何业务代码。

• 最后是存储层面如何支持近实时的 CDC 数据分析。

• 第一个阶段是 Flink 与 Iceberg 建立连接。

  
  

• 第二阶段是 Iceberg 替换 Hive 场景。在这个场景下，有很多公司已经开始上线，落地自己的场景。

  
  

• 第三个阶段是通过 Flink 与 Iceberg 解决更复杂的技术问题。

  
  

• 第四个阶段是把这一套从单纯的技术方案，到面向更完善的产品方案角度去做。

   戳我，查看作者原文视频～