数据湖技术 Iceberg 的探索与实践

本文资料来自2020年9月5日由快手技术团队主办的快手大数据平台架构技术交流会，分享者邵赛赛，腾讯数据平台部数据湖内核技术负责人，资深大数据工程师，Apache Spark PMC member & committer, Apache Livy PMC member，曾就职于 Hortonworks，Intel 。

随着大数据存储和处理需求的多样化，如何构建一个统一的数据湖存储，并在其上进行多种形式的数据分析成了企业构建大数据生态的一个重要方向。Netflix 发起的 Apache Iceberg 项目具备 ACID 能力的表格式中间件成为了大数据、数据湖领域炙手可热的方向。本次演讲将会具体介绍 Iceberg 的设计初衷、优点和能力，通过本次分享您将会对表格式这一领域有充分的了解，并深入了解 Iceberg 的设计、实现、优势以及使用方式。

本文分享主要包括四部分：

• 数据湖技术 
  

• Iceberg 原理介绍

• Iceberg 应用落地

• 后续的规划

数据湖技术

当前大数据发展的三大趋势：

• 数据仓库往数据湖方向发展

• 批处理往流式处理发展

• 本地部署往云模式发展

本文要讲的是如何构建数据湖？并且在湖上如何分析？

一般而言，数据湖技术需要具备的能力主要包括以下几项：

• 同时支持流批处理
  

• 支持数据更新
  

• 支持事务（ACID）
  

• 可扩展的元数据
  

• 数据质量保障
  

• 支持多种存储引擎
  

• 支持多种计算引擎
  

今天市面上存在三种数据湖技术：Apache Iceberg、Apache Hudi 以及 Delta Lake。他们都是：

• 构建于存储格式之上的数据组织方式

• 提供 ACID 能力，提供一定的事务特性和并发能力
  

• 提供行级别的数据修改能力
  

• 确保 Schema 的准确性，提供一定的 Schema 扩展能力。

上面表格在十三个维度对这些数据湖分析对比，过往记忆大数据之前的 《一篇文章掌握 delta、iceberg 和 hudi 三大开源数据湖方案》、《Delta Lake、Iceberg 和 Hudi 三大开源数据湖不知道如何选？那是因为你没看这篇文章》以及《Delta Lake 和 Apache Hudi 两种数据湖产品全方面对比》文章也有这方面的比较，感兴趣的同学可以去看看。

上面的比较中可以看出，不同数据湖产品各有千秋，不同公司根据不同需求选择了不同的数据湖产品，比如阿里云的 DLA 团队选择 Apache Hudi 作为其底层数据湖存储引擎；腾讯选择了 Apache Iceberg 作为他们的数据湖存储引擎。

Apache Iceberg 原理介绍

Apache Iceberg 是一种用于跟踪超大规模表的新格式，是专门为对象存储（如S3）而设计的。其核心思想：在时间轴上跟踪表的所有变化。

• 快照（snapshot）表示表数据文件的一个完整集合
  

• 每次更新操作会生成一个新的快照。

前面说了腾讯选择了 Apache Iceberg 作为其数据湖底层存储，主要原因如下四点：

• 优化数据入库流程：Iceberg 提供 ACID 事务能力，上游数据写入即可见，不影响当前数据处理任务，这大大简化了 ETL；Iceberg 提供了 upsert、merge into 能力，可以极大地缩小数据入库延迟；

• 支持更多的分析引擎：优秀的内核抽象使之不绑定特定的计算引擎，目前 Iceberg 支持的计算引擎有 Spark、Flink、Presto 以及 Hive。

• 统一数据存储和灵活的文件组织：提供了基于流式的增量计算模型和基于批处理的全量表计算模型。批处理和流任务可以使用相同的存储模型，数据不再孤立；Iceberg 支持隐藏分区和分区进化，方便业务进行数据分区策略更新。支持 Parquet、Avro 以及 ORC 等存储格式。

• 增量读取处理能力：Iceberg 支持通过流式方式读取增量数据，支持 Structed Streaming 以及 Flink table Source。

Iceberg 的快照设计方式，主要包括快照隔离以及对于文件列表的所有修改都是原子操作。

元数据组织包括：

• 实现基于快照的跟踪方式；

• 表的元数据是不可修改的，并且始终向前迭代；
  

• 当前的快照可以回退。
  

Iceberg 应用落地

没有使用数据湖技术，我们需要很多组件来保证 exactly-once 语义。并且利用 HDFS 的 rename 操作的原子性和复杂的命名规则来保证一致性、可见性。利用调度引擎来构建依赖关系，从而避免读写冲突。

上面架构存在的问题：架构比较复杂，需要不同组件之间的协调；架构的复杂会进一步导致数据的延迟。exactly-once 语义保证比较复杂，增加了运维的难度。

有了 Iceberg 之后，整体架构简单了，而且通过简单的架构即可实现原子语义。Iceberg 格式的数据直接可以使用 Hive、Spark 来读取；同时，Iceberg 支持读写分区，写入并且 commit 的数据下游系统立即可以使用，降低系统的整体延迟。

同时，Iceberg 技术还催生了新的架构，也就是 CDC 架构。其相比传统的架构而言整体系统架构更加简洁，端到端的延迟大大降低，而且支持 ACID 事务能力。

后续规划

猜你喜欢

1、滴滴ElasticSearch千万级TPS写入性能翻倍技术剖析

2、

3、PB级大规模Elasticsearch集群运维与调优实践

4、Presto on Spark：扩展 Presto 以支持大规模 ETL

过往记忆大数据微信群，请添加微信：fangzhen0219,备注【进群】