乐趣区

关于sql:Flink-和-Iceberg-如何解决数据入湖面临的挑战

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

GitHub 地址
https://github.com/apache/flink
欢送大家给 Flink 点赞送 star~

一、数据入湖的外围挑战

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

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

版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

退出移动版