共计 4392 个字符，预计需要花费 11 分钟才能阅读完成。
一、数据入湖的外围挑战
数据实时入湖能够分成三个局部，别离是数据源、数据管道和数据湖（数仓），本文的内容将围绕这三局部开展。
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 数据很艰难
大家调研 Hadoop 里各种各样的零碎，发现整个链路须要跑得又快又好又稳固，并且有好的并发，这并不容易。
首先从源端来看，比方要将 MySQL 的数据同步到数据湖进行剖析，可能会面临一个问题，就是 MySQL 外面有存量数据，前面如果一直产生增量数据，如何完满地同步全量和增量数据到数据湖中，保证数据不多也不少。
此外，假如解决了源头的全量跟增量切换，如果在同步过程中遇到异样，如上游的 Schema 变更导致作业中断，如何保障 CDC 数据一行不少地同步到上游。
整条链路的搭建，须要波及源头全量跟同步的切换，包含两头数据流的串通，还有写入到数据湖（数仓）的流程，搭建整个链路须要写很多代码，开发门槛较高。
最初一个问题，也是要害的一个问题，就是咱们发现在开源的生态和零碎中，很难找到高效、高并发剖析 CDC 这种变更性质的数据。
5. 数据入湖面临的外围挑战
数据同步工作中断
- 无奈无效隔离写入对剖析的影响；
- 同步工作不保障 exactly-once 语义。
端到端数据变更
- DDL 导致全链路更新降级简单；
- 批改湖 / 仓中存量数据艰难。
越来越慢的近实时报表
- 频繁写入产生大量小文件；
- Metadata 零碎压力大, 启动作业慢；
- 大量小文件导致数据扫描慢。
无奈近实时剖析 CDC 数据
- 难以完成全量到增量同步的切换；
- 波及端到端的代码开发，门槛高；
- 开源界不足高效的存储系统。
二、Apache Iceberg 介绍
1. Netflix：Hive 上云痛点总结
Netflix 做 Iceberg 最要害的起因是想解决 Hive 上云的痛点，痛点次要分为以下三个方面：
1.1 痛点一：数据变更和回溯艰难
- 不提供 ACID 语义。在产生数据改变时，很难隔离对剖析工作的影响。典型操作如：INSERT OVERWRITE；批改数据分区；批改 Schema；
- 无奈解决多个数据改变，造成抵触问题；
- 无奈无效回溯历史版本。
1.2 痛点二：替换 HDFS 为 S3 艰难
- 数据拜访接口间接依赖 HDFS API；
- 依赖 RENAME 接口的原子性，这在相似 S3 这样的对象存储上很难实现同样的语义；
- 大量依赖文件目录的 list 接口，这在对象存储系统上很低效。
1.3 痛点三：太多细节问题
- Schema 变更时，不同文件格式行为不统一。不同 FileFormat 甚至连数据类型的反对都不统一；
- Metastore 仅保护 partition 级别的统计信息，造成不 task plan 开销；Hive Metastore 难以扩大；
- 非 partition 字段不能做 partition prune。
2. Apache Iceberg 外围个性
通用化规范设计
- 完满解耦计算引擎
- Schema 标准化
- 凋谢的数据格式
- 反对 Java 和 Python
欠缺的 Table 语义
- Schema 定义与变更
- 灵便的 Partition 策略
- ACID 语义
- Snapshot 语义
丰盛的数据管理
- 存储的流批对立
- 可扩大的 META 设计反对
- 批更新和 CDC
- 反对文件加密
性价比
- 计算下推设计
- 低成本的元数据管理
- 向量化计算
- 轻量级索引
3. Apache Iceberg File Layout
上方为一个规范的 Iceberg 的 TableFormat 构造，外围分为两局部，一部分是 Data，一部分是 Metadata，无论哪局部都是保护在 S3 或者是 HDFS 之上的。
4. Apache Iceberg Snapshot View
上图为 Iceberg 的写入跟读取的大抵流程。
能够看到这外面分三层：
- 最下面黄色的是快照；
- 两头蓝色的是 Manifest；
- 最上面是文件。
每次写入都会产生一批文件，一个或多个 Manifest，还有快照。
比方第一次造成了快照 Snap-0，第二次造成快照 Snap-1，以此类推。然而在保护原数据的时候，都是增量一步一步做追加保护的。
这样的话能够帮忙用户在一个对立的存储上做批量的数据分析，也能够基于存储之下来做快照之间的增量剖析，这也是 Iceberg 在流跟批的读写上可能做到一些反对的起因。
5. 抉择 Apache 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 来构建整个数据库的生态。
三、Flink 和 Iceberg 如何解决问题
回到最要害的内容，上面论述 Flink 和 Iceberg 如何解决第一局部所遇到的一系列问题。
1. Case #1：程序 BUG 导致数据传输中断
首先，同步链路用 Flink，能够保障 exactly once 的语义，当作业呈现故障时，可能做严格的复原，保证数据的一致性。
第二个是 Iceberg，它提供谨严的 ACID 语义，能够帮用户轻松隔离写入对剖析工作的不利影响。
2. Case #2：数据变更太苦楚
如上所示，当产生数据变更时，用 Flink 和 Iceberg 能够解决这个问题。
Flink 能够捕捉到上游 Schema 变更的事件，而后把这个事件同步到上游，同步之后上游的 Flink 间接把数据往下转发，转发之后到存储，Iceberg 能够霎时把 Schema 给变更掉。
当做 Schema 这种 DDL 的时候，Iceberg 间接保护了多个版本的 Schema，而后老的数据源齐全不动，新的数据写新的 Schema，实现一键 Schema 隔离。
另外一个例子是分区变更的问题，Iceberg 做法如上图所示。
之前按“月”做分区（上方黄色数据块），如果心愿改成按“天”做分区，能够间接一键把 Partition 变更，原来的数据不变，新的数据全副按“天”进行分区，语义做到 ACID 隔离。
3. Case #3：越来越慢的近实时报表？
第三个问题是小文件对 Metastore 造成的压力。
首先对于 Metastore 而言，Iceberg 是把原数据对立存到文件系统里，而后用 metadata 的形式保护。整个过程其实是去掉了中心化的 Metastore，只依赖文件系统扩大，所以扩展性较好。
另一个问题是小文件越来越多，导致数据扫描会越来越慢。在这个问题上，Flink 和 Iceberg 提供了一系列解决方案：
- 第一个计划是在写入的时候优化小文件的问题，依照 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 数据分析。
四、社区 Roadmap
上图为 Iceberg 的 Roadmap，能够看到 Iceberg 在 2019 年只发了一个版本，却在 2020 年间接发了三个版本，并在 0.9.0 版本就成为顶级我的项目。
上图为 Flink 与 Iceberg 的 Roadmap，能够分为 4 个阶段。
- 第一个阶段是 Flink 与 Iceberg 建设连贯。
- 第二阶段是 Iceberg 替换 Hive 场景。在这个场景下，有很多公司曾经开始上线，落地本人的场景。
- 第三个阶段是通过 Flink 与 Iceberg 解决更简单的技术问题。
- 第四个阶段是把这一套从单纯的技术计划，到面向更欠缺的产品计划角度去做。
