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

一、数据入湖的核心挑战

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

数据变更
当发生数据变更的情况时，会给整条链路带来较大的压力和挑战。以下图为例，原先是一个表定义了两个字段，分别是 ID 和 NAME。此时，业务方面的同学表示需要将地址加上，以方便更好地挖掘用户的价值。
首先，我们需要把 Source 表加上一个列 Address，然后再把到 Kafka 中间的链路加上链，然后修改作业并重启。接着整条链路得一路改过去，添加新列，修改作业并重启，最后把数据湖（数仓）里的所有数据全部更新，从而实现新增列。这个过程的操作不仅耗时，而且会引入一个问题，就是如何保证数据的隔离性，在变更的过程中不会对分析作业的读取造成影响。

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

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

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

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

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

大家调研 Hadoop 里各种各样的系统，发现整个链路需要跑得又快又好又稳定，并且有好的并发，这并不容易。

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

Netflix 做 Iceberg 最关键的原因是想解决 Hive 上云的痛点，痛点主要分为以下三个方面：

上方为一个标准的 Iceberg 的 TableFormat 结构，核心分为两部分，一部分是 Data，一部分是 Metadata，无论哪部分都是维护在 S3 或者是 HDFS 之上的。

上图为 Iceberg 的写入跟读取的大致流程。

可以看到这里面分三层：

每次写入都会产生一批文件，一个或多个 Manifest，还有快照。

比如第一次形成了快照 Snap-0，第二次形成快照 Snap-1，以此类推。但是在维护原数据的时候，都是增量一步一步做追加维护的。

这样的话可以帮助用户在一个统一的存储上做批量的数据分析，也可以基于存储之上去做快照之间的增量分析，这也是 Iceberg 在流跟批的读写上能够做到一些支持的原因。

上图为目前在使用 Apache Iceberg 的部分公司，国内的例子大家都较为熟悉，这里大致介绍一下国外公司的使用情况。

NetFlix 现在是有数百PB的数据规模放到 Apache Iceberg 之上，Flink 每天的数据增量是上百T的数据规模。
Adobe 每天的数据新增量规模为数T，数据总规模在几十PB左右。
AWS 把 Iceberg 作为数据湖的底座。
Cloudera 基于 Iceberg 构建自己整个公有云平台，像 Hadoop 这种 HDFS 私有化部署的趋势在减弱，上云的趋势逐步上升，Iceberg 在 Cloudera 数据架构上云的阶段中起到关键作用。
苹果有两个团队在使用：
- 一是整个 iCloud 数据平台基于 Iceberg 构建；
- 二是人工智能语音服务 Siri，也是基于 Flink 跟 Iceberg 来构建整个数据库的生态。