大数据学习笔记2：现代数据湖之Iceberg

本文首发于泊浮目的简书：https://www.jianshu.com/u/204...

版本	日期	备注
1.0	2021.6.20	文章首发

最近Iceberg有点小火，在这里也是根据自己看到的资料做个笔记输出一下。

数据湖的定义就不说了，不了解的小伙伴可以看我之前做的笔记大数据学习笔记1：数仓、数据湖、数据中台。

1. 数据湖发展现状

• 从广义上来说数据湖系统主要包括数据湖村处和数据湖分析

• 现有数据湖技术主要由云厂商推动，包括基于对象存储的数据湖存储及在其之上的分析套件

  • 基于对象存储（S3，WASB）的数据湖存储技术，如Azure ADLS，AWS Lake Formation等
  • 以及运行在其上的分析工具，如AWS EMR，Azure HDinsight，RStudio等等

2. 业界趋势

• 构建统一、高效的数据存储以满足不同数据处理场景的需求已成为趋势

  • ETL作业和OLAP分析——高性能的结构化存储，分布式能力
  • 机器学习训练和推理——海量的非结构存储，容器挂载能力
• 通用数仓（Hive、Spark）在向数据湖分析泛化，而数仓则向高性能架构演进

3. 现代数据湖的能力要求

• 支持流批计算
• Data Mutation
• 支持事务
• 计算引擎抽象
• 存储引擎抽象
• 数据质量
• 元数据支持扩展

4.常见现代数据湖技术

• Iceberg
• Apache Hudi
• Delta Lake

总的来说，这些数据湖都提供了这样的一些能力：

1. 构建于存储格式之上的数据组织方式
2. 提供ACID能力，提供一定的事务特性和并发能力
3. 提供行级别的数据修改能力
4. 确保schema的准确性，提供一定的schema修改能力

一些具体的对比可以看这张图：

5. Iceberg

我们先看看Iceberg的官网是如何介绍它的：

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

我的理解是，Iceberg以表的形式来组织底层数据，并对上面提供了高性能的表级别计算能力。

它的核心思想就是在时间轴上跟踪表的所有变化：

• 快照表示表数据文件的一个完整集合
• 每次更新操作会生成一个新的快照

目前已知在用的Iceberg的大厂：

• 国外：Netflix、Apple、Linkined、Adobe、Dremio
• 国内：腾讯、网易、阿里云

5.1 Iceberg的优势

• 写入：支持事务，写入即可见；并提供upset/merge into的能力
• 读取：支持以流的方式读取增量数据：Flink Table Source以及Spark Struct streaming都支持；不惧怕Schema的变更
• 计算：通过抽象不绑定任何引擎。提供原生的Java Native API，生态上来说，目前支持Spark、Flink、Presto、Hive
• 存储：对底层存储进行了抽象，不绑定于任何底层存储；支持隐藏分区和分区进化，方便业务进行数据分区策略；支持Parquet，ORC，Avro等格式来兼容行存储和列存储

5.2 特性

5.2.1 快照设计方式

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

  • 记录表的结构，分区信息，参数等
  • 跟踪老的快照以确保能够最终回收
• 表的元数据是不可修改的，并始终向前迭代
• 当前的快照可以回退

5.2.2 元数据组织

• 写操作必须：

  • 记录当前元数据的版本-Base Version
  • 创建新的元数据以及mainfest文件
  • 原子性地将base version替换为新的版本
• 原子性替换保证了线性的历史

• 原子性的替换需要依靠以下操作来保证

  • 元数据管理器所提供的能力
  • HDFS或是本地文件系统所提供的原子化的rename能力

• 冲突解决——乐观锁

  • 假定当前没有其他的写操作
  • 遇到冲突则基于当前最新的元数据进行重试

5.2.2 事务性提交

• 写操作必须

  • 记录当前元数据的版本-base version
  • 创建新的元数据以及mainfest文件
  • 原子性地将base version替换成新的版本
• 原子性替换保证了线形的历史

• 原子性替换需要依靠以下操作来保证

  • 元数据管理器提供的能力
  • HDFS或是本地文件系统所提供的原子化的rename能力

• 冲突解决-乐观锁

  • 假定当前没有其他的写操作
  • 遇到冲突则基于当前的最新元数据进行重试

5.3场景

5.3.1 CDC数据实时摄入摄出

这里要讨论的是关系型数据库的binlog如何去做分析。在hadoop生态里，对这个场景一般是不怎么友好的。

最常见的方式是写到hive里，标记这是binlog，并声明它的类型（I,U,D），然后再跑个批量任务到存量表里。但hive只能做到小时级别的分区，但iceberg可以做到1分钟内。

5.3.2 近实时场景的流批一体

在lambda架构中，会分为实时链路和离线链路。主要技术栈非常复杂，如果能够接受准实时（30s~1min）的延迟，iceberg是可以胜任的。