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

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

GitHub 地址
https://github.com/apache/flink
欢迎你们给 Flink 点赞送 star~

1、数据入湖的核心挑战

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

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 数据

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

2、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 来构建整个数据库的生态。

3、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 数据分析。

4、社区 Roadmap

上图为 Iceberg 的 Roadmap，能够看到 Iceberg 在 2019 年只发了一个版本， 却在 2020 年直接发了三个版本，并在 0.9.0 版本就成为顶级项目。

上图为 Flink 与 Iceberg 的 Roadmap，能够分为 4 个阶段。

• 第一个阶段是 Flink 与 Iceberg 创建链接。
• 第二阶段是 Iceberg 替换 Hive 场景。在这个场景下，有不少公司已经开始上线，落地本身的场景。
• 第三个阶段是经过 Flink 与 Iceberg 解决更复杂的技术问题。
• 第四个阶段是把这一套从单纯的技术方案，到面向更完善的产品方案角度去作。

本文内容由阿里云实名注册用户自发贡献，版权归原做者全部，阿里云开发者社区不拥有其著做权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。若是您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将马上删除涉嫌侵权内容。