本文首发于泊浮目标简书：https://www.jianshu.com/u/204...
版本日期备注
1.02021.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能力，提供肯定的*事务个性和并发能力8
  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是能够胜任的。