Iceberg核心思想
在时间轴上根据快照跟踪表数据的修改
特性：
优化数据入库流程可以merge
与上层引擎解耦，不绑定spark
统一数据存储，灵活文件组织
增量读取能力
实现细节：
快照设计:
每次读写更新生成快照，写会生成新的隔离快照，并在写完后原子性提交
对文件列表的所有修改都是原子操作
在分区中追加数据
合并或者重写分区
元数据组织方式（metadata都是json结尾的元数据文件，每次修改生成一个json，json中有快照）
实现基于快照的跟踪方式
1：记录表结构，分区信息，参数等
2：跟踪老的快照以确保能最终回收
表的元数据不可修改并且始终向前迭代
当前快照可回退
事务性提交
写操作
记录当前元数据的版本 base version
创建新的元数据文件以及manifest文件
原子性的将baseversion替换为新版本
原子性替换保证了线性历史
原子性替换保证了需要依赖以下操作保证
元数据管理器提供的能力
HDFS或者是本地文件系统提供的原子化rename能力
冲突解决：乐观锁（因为数据湖读多写少） 冲突：另一个人等待
假定当前没有其他的写操作
遇到冲突则基于当前最新的元数据进行重试
Iceberg结合Flink
场景一：构建近实时的datapipeline
数据-flink-iceberg(原始表)-flink-iceberg(提取后的数据)-flink-iceberg(聚合数据)
hive新数据写入会写入新的分区（一般是天），但是iceberg能分钟级别拉取
场景二：CDC数据实时摄入摄出
场景三：近实时场景的流批统一
原有的lamda架构
改造成iceberg+flink，不同层用flink计算
场景四：从Iceberg历史数据启动Flink任务
1：flink实时聚合结果导入habase
2：Flink实时写入库iceberg，iceberg保留所有历史数据
3：通过iceberg历史数据订正实时计算结果
新作业结合历史，跑到当前对接
checkpont定期分批次提交数据到iceberg
场景五：通过iceberg数据订正实时聚合结果
Flink如何集成Iceberg
对齐Flink和Iceberg的Schema
Flink数据类型罗列和Iceberg的罗列，然后比对
Flink记录如何写入Iceberg表的AVRO文件
Flink表字段设计类型，然后写入avro
如何设计iceberg sink的operator
flink的checkpoint，exactly-once
实时数仓架构演化催生新技术
lambda：无法解决实时和离线数据不一致问题
kappa：消息中间件缓存问题(kafka往往不能存储永久的数据。Pulsar目前算是正在解决这个问题的队列)，可能丢数据
CDC：完全基于数据湖，批流一体，不依赖kafka
CDC
kafka(plausar)-flink-数据湖(数据治理，去重，修正，增量分析flink(sparkstreaming)，全量更新(Spark3新特性，catalog和CURD能力),BI分析)
数据入湖用的Flink+Iceberg(问题：快照的变化越来越多，元数据越来越多，要删除)
湖上分析：增量分析flink(sparkstreaming)，全量更新(Spark3新特性，catalog和CURD能力)
问题：快照多，元数据问题
孤儿文件问题：任务被终止掉（还没被提交的commit）
何时用数据湖数据仓库，处理二者关系
数据湖做ODS清洗转换-->数据仓库--->数据集市--->数据分析
如果没有非结构化数据，也可以直接数仓