数据湖之iceberg系列(一)iceberg能做什么

1 前言 HIVE的缺陷

Hive的元数据依赖一个外部的MySQL和HDFS文件系统，通过MySQL找到相关的parition之后，需要为每个partition去HDFS文件系统上按照分区做目录的list操作。在文件量大的情况下，这是一个非常耗时的操作。

同时，由于元数据分属MySQL和HDFS管理，写入操作本身的原子性难以保证。即使在开启Hive ACID情况下，仍有很多细小场景无法保证原子性。另外，Hive Metastore没有文件级别的统计信息，这使得filter只能下推到partition级别，而无法下推到文件级别，对上层分析性能损耗无可避免。

在处理数据的时候 hive对数据的变化没有相应的管理, 数据的合并的抽取需要使用拉链表操作,操作相对比较复杂 !

虽然目前从功能上看不如前面两者丰富，但由于它牢固坚实的底层设计，一旦功能补齐，将成为一个非常有潜力的开源数据湖方案。

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

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

• 批处理往流式处理发展

• 本地部署往云模式发展

数据湖简介

数据湖应该具备以下功能

• 同时支持流批处理

• 支持数据更新

• 支持事务（ACID）

• 可扩展的元数据

• 数据质量保障

• 支持多种存储引擎

• 支持多种计算引擎

Apache Iceberg 原理介绍

 

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

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

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

Iceberg的优点

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

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

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

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

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

元数据组织包括：

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

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

• 当前的快照可以回退。

• 

 

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

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

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

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