0、前言1 Hive挑战2、Iceberg的解决方案 0、前言
Iceberg是为了解决Hive上云诞生的一个工具。
原理是一种用于跟踪超大规模表的新格式，是专门为对象存储（如 S3）而设计的。
核心思想：在时间轴上跟踪表的所有变化。
强烈推荐看下这篇学习日志，看下iceberg如何读写，实际如何使用？同时，了解下Hive的架构
Apache Iceberg 学习日志 https://xie.infoq.cn/article/61a82b983ef97c3e05a6e7d82
Hive架构，metadata-store是什么？ 存储了哪些信息? 有什么优化点？
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、数据变更
数据访问不用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