0. 前言

Iceberg是为了解决Hive上云诞生的一个工具。
原理是一种用于跟踪超大规模表的新格式，是专门为对象存储（如 S3）而设计的。
核心思想：在时间轴上跟踪表的所有变化。

强烈推荐看下这篇学习日志，看下iceberg如何读写，实际如何使用？同时，了解下Hive的架构

Apache Iceberg 学习日志 https://xie.infoq.cn/article/61a82b983ef97c3e05a6e7d82
Hive架构，Metadata-store是什么？存储了哪些信息? 有什么优化点？

1 Hive挑战

上云
- HMS依赖Mysql，Mysql做分布式不方便；
- HMS抽象不清晰，Schema/表统计信息/分区信息等边界不清晰;
- 读读mysql获取分区信息，再跨shard去list，成本太高 (LIST指令成本高，GET成本低)
- 写？这块没太听懂，GET不到点
- 要求1.支持多种存储格式(弹性低廉稳定) 2. 统一Table语义(支持对象存储) 3. 计算引擎互通
近实时数仓
- 入仓，无法接受分钟级，对HMS是一种压力
- 出仓，不支持增量数据查询
- 要求: 1.分钟级别入仓 2. 更高效索引加速数据分析，查询响应要快 3. 增量出湖出仓，下游ETL响应更快
变更
- 字段变更对读端影响
- 分区字段变更: 月粒度转日粒度，hive是把数据重新insert一遍
- 要求:1. schema变更 2. 分区变更 3. 数据变更

在这里插入图片描述

2. Iceberg的解决方案

挑战1：上云
- 数据访问不用list，都是get；扩展性 (? 对象存储，不是HMS那种mysql)
- ACID不依赖RENAME (我理解RENAME就是先把数据写到一个临时区域，写入完成再将数据置位有效，这个置位有效的过程就是RENAME) 另外，这个锁服务很解耦，可以放到适配任何一个锁服务
挑战2: 近实时数仓
- 去中心化可拓展的metadata (托管给一个分布式系统)
- 丰富的metadata-index的加速 (用的get 不是list)
- 增量出入湖 (通过新的metadata去获取增量部分)
挑战3: 变更
- 快速实现Schema变更(多版本变更，1s完成，它也提供了完成ACID语义，可以优雅变更，用户永远看到的一致的结果)
- 轻量级分区变更（老的不变，新的用新的分区）
- V2支持Merge-On-Read方法更新数据（读的时候进行一个处理，写入性能高，读受些影响. 学习资料https://blog.csdn.net/wuleidaren/article/details/114037442）

Row-Level Delete 是指根据一个条件从一个数据集里面删除指定行。它实现方式可以分为Copy on Write模式和Merge on Read模式，其中Copy on Write模式可以保证下游的数据读具有最大的性能，而Merge on Read模式保证上游数据插入、更新、和删除的性能，减少传统Copy on Write模式下写放大问题。本次我们只讨论基于 Merge on Read 模式的实现方式。

sequence number 的生成是与 snapshot 强相关的，可以这样理解，在每次生成新的 snapshot 时（即每一次 commit success 时），会为本次新生成的 data-file 、delete-file 以及对应的 manifest 分配一个递增的序列号。
————————————————
版权声明：本文为CSDN博主「corleone_lw」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/wuleidaren/article/details/114037442

在这里插入图片描述