一、数据入湖的外围挑战

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

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 痛点一：数据变更和回溯艰难

  1. 不提供 ACID 语义。在产生数据改变时，很难隔离对剖析工作的影响。典型操作如：INSERT OVERWRITE；批改数据分区；批改 Schema；
  2. 无奈解决多个数据改变，造成抵触问题；
  3. 无奈无效回溯历史版本。

1.2 痛点二：替换 HDFS 为 S3 艰难

  1. 数据拜访接口间接依赖 HDFS API；
  2. 依赖 RENAME 接口的原子性，这在相似 S3 这样的对象存储上很难实现同样的语义；
  3. 大量依赖文件目录的 list 接口，这在对象存储系统上很低效。

1.3 痛点三：太多细节问题

  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

上方为一个规范的 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 解决更简单的技术问题。
  • 第四个阶段是把这一套从单纯的技术计划，到面向更欠缺的产品计划角度去做。