共计 1986 个字符,预计需要花费 5 分钟才能阅读完成。
本文首发于泊浮目标简书: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
总的来说,这些数据湖都提供了这样的一些能力:
- 构建于存储格局之上的 数据组织形式
- 提供 ACID 能力,提供肯定的* 事务个性和并发能力8
- 提供 行级别的数据批改能力
- 确保 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 是能够胜任的。
正文完