大数据时代，数据湖技术Apache Iceberg的前世今生

一种技术，从出现到广泛的使用，有着他与生俱来的天性，同样有后天物竞天择适者生存的妥协。

大数据时代，数据湖技术的广泛应运，有不同技术流派的剧烈碰撞，也有不同技术流派的相互学习。当下，数据湖技术天下三分，各有侧重，但它来自哪里，要去往何处，优势在哪里，需要补强的又是什么？

其他的姑且不说，数据湖技术代表之一Apache Iceberg，已经在很多企业落地应用，从数据分析到数据治理，再到AI模型训练等场景，切实发挥着中流砥柱的作用。那么，iceberg的前世今生，又是怎样呢？

Apache Iceberg is an open table format for huge analytic datasets. Iceberg adds tables to Presto and Spark that use a high-performance format that works just like a sql table.

Iceberg官网定义：Iceberg是一个通用的表格式（数据组织格式），它可以适配Presto，Spark等引擎提供高性能的读写和元数据管理功能。

从Iceberg的定义中不难看出，这类技术它的定位是在计算引擎之下，又在存储之上。同时，它也是一种数据存储格式，Iceberg则称其为"table format"。因此，这类技术可以看作介于计算引擎和数据存储格式中间的数据组织格式，通过特定的方式将数据和元数据组织起来，所以称之为数据组织格式更为合理，而Iceberg将其定义为表格式也直观地反映出了它的定位和功能。

大数据时代，数据的组织方式为其技术发展的掣肘

---

从Hadoop诞生到现在，数据的存储格式经历了几代的发展，从最初的txt file，到后来的sequence file，rcfile，再到现在的ORC，Parquet等列式存储文件，数据的存储格式发生了翻天覆地的变化，更好的性能、更高的压缩比。然而数据组织方式的发展却相当缓慢。

Hive提出了分区的概念，利用某几个column作为分区值来组织数据，能够有效地过滤掉无需读取的数据，这种分区在物理存储上反映出来的就是按照文件夹进行分区（组织）数据。利用文件夹来组织与HDFS的文件系统结构有天然的亲和性，因此这一方式也一直被沿用下来，但是这种数据的组织方式真的没有改进的空间了吗？

随着大数据和云计算的结合，越来越多的底层存储系统从HDFS这样的分布式文件系统换成了云上的对象存储系统，而这种利用文件夹来组织数据的方式在对象存储上遇到了极大的挑战。

1. 利用对象存储来模拟文件系统从而提供文件夹遍历的方式非常低效，而传统的分区计算中又大量地依赖遍历操作。
2. 基于文件、文件夹的rename来保证原子性的语义在某些对象存储上是有问题的（如S3)。同时有的对象存储对于rename的实现有巨大的开销。

那么是否能有一种新的数据组织方式对于对象存储等云存储有更好的亲和性呢？

元数据的存取，同样困难重重

---

也是从Hive开始在大数据领域提出了metastore的集中式服务来来提供元数据管理的能力，集中式的元数据服务能够更好地管理整个数仓的元数据信息，但也带来了几个问题：

1. 元数据和数据的分离式存储容易造成不一致性。比如在HDFS上对数据进行了某些删除、改动，但是metastore并不能感知到数据的变化从而造成两边的不一致。

2. 集中式的元数据管理对于大规模的企业级应用容易形成单点瓶颈。所以的元数据都需要通过metastore来存取，极易造成metastore的压力，从而极大地延长query plan的时间。

为此，是否能够将数据和元数据有效地组织在一起来避免上面的问题呢？

为什么 Iceberg?

---

首先，数据湖相比传统数仓而言，最明显的便是优秀的T+0能力，这个解决了Hadoop时代数据分析的顽疾。传统的数据处理流程从数据入库到数据处理通常需要一个较长的环节、涉及许多复杂的逻辑来保证数据的一致性，由于架构的复杂性使得整个流水线具有明显的延迟。

Iceberg 的 ACID 能力可以简化整个流水线的设计，降低整个流水线的延迟。降低数据修正的成本。传统 Hive/Spark 在修正数据时需要将数据读取出来，修改后再写入，有极大的修正成本。Iceberg 所具有的修改、删除能力能够有效地降低开销，提升效率。

1 ACID能力，无缝贴合流批一体数据存储最后一块版图

随着flink等技术的不断发展，流批一体生态不断完善，但在流批一体数据存储方面一直是个空白，直到Iceberg等数据湖技术的出现，这片空白被慢慢填补。

Iceberg 提供 ACID 事务能力，上游数据写入即可见，不影响当前数据处理任务，这大大简化了 ETL；

Iceberg 提供了 upsert、merge into 能力，可以极大地缩小数据入库延迟；

Iceberg支持in-place table evolution，用户可以像sql那样修改表的schema，或者修改分区方式。Iceberg无需用户重写表数据或者是迁移到新表上。

Iceberg提供了锁的机制来提供ACID的能力，在每次元数据更新时它会从Hive metastore中获取锁并进行更新。同时Iceberg保证了线性一致性（Serializable isolation），确保表的修改操作是原子性的，读操作永远不会读到部分或是没有commit的数据。Iceberg提供了乐观锁的机制降低锁的影响，并且使用冲突回退和重试机制来解决并发写所造成的冲突问题。

2 统一数据存储，无缝衔接计算引擎和数据存储

Iceberg提供了基于流式的增量计算模型和基于批处理的全量表计算模型。批处理和流任务可以使用相同的存储模型，数据不再孤立；Iceberg 支持隐藏分区和分区进化，方便业务进行数据分区策略更新。

Iceberg屏蔽了底层数据存储格式的差异，提供对于Parquet，ORC和Avro格式的支持。Iceberg起到了中间桥梁的能力，将上层引擎的能力传导到下层的存储格式。

3 开放架构设计，开发维护成本相对可控：

Iceberg 的架构和实现并未绑定于某一特定引擎，它实现了通用的数据组织格式，利用此格式可以方便地与不同引擎对接，目前 Iceberg 支持的计算引擎有 Spark、Flink、Presto 以及 Hive。

相比于 Hudi、Delta Lake，Iceberg 的架构实现更为优雅，同时对于数据格式、类型系统有完备的定义和可进化的设计；面向对象存储的优化。Iceberg 在数据组织方式上充分考虑了对象存储的特性，避免耗时的 listing 和 rename 操作，使其在基于对象存储的数据湖架构适配上更有优势。

4 快照读写分离，数据组织管理更为完善

元数据组织主要用来记录表结构、分区信息、数据存放位置等信息；跟踪旧快照，并对其生命周期进行管理。表的元数据是不可修改的，并且始终向前迭代。同时，当前的快照可以回退。

数据读取仅使用当前已经生成的快照，写操作会生成新的快照隔离，并在完成数据写入后原子性提交，以及对于文件列表的所有修改都是原子操作。

首先，每次写操作都会产生一个新的快照（snapshot），快照始终是往后线性递增，确保了线性一致性。而读操作只会读取已经存在了的快照，对于正在生成的快照读操作是不可见的。

每一个快照拥有表在那一时刻所有的数据和元数据，因此提供了用户回溯（time travel）表数据的能力。利用Iceberg的time travel能力，用户可以读取那一时刻的数据，同时也提供了用户快照回滚和数据重放的能力

5 增量数据读取，实时计算的一把利剑

Iceberg 支持通过流式方式读取增量数据，支持 Structed Streaming 以及 Flink table Source。

当然，Iceberg还有很多问题需要解决，诸如量拉取 CDC 数据的能力、更多上游计算分析引擎的适配以及统一的索引层来加速数据的检索等特性功能需要添加，但他以“表格式”这种技术，在大数据领域应用和推广，本身是对大数据技术一种全新的推动和发展，而Iceberg作为一种优秀的实践也必会被大量采用。