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清洗转换-->数据仓库--->数据集市--->数据分析
如果没有非结构化数据,也可以直接数仓