数据湖 iceberg 在小米的应用场景.pdf

《数据湖 iceberg 在小米的应用场景.pdf》由会员分享，可在线阅读，更多相关《数据湖 iceberg 在小米的应用场景.pdf（28页珍藏版）》请在三个皮匠报告上搜索。

1、演讲人：李培殿小米数据湖研发负责人 2023 Iceberg 核心特性Iceberg 在小米的应用场景未来规划Iceberg简介Iceberg 是什么？Iceberg Is an open standard for tables with SQL behavior.-Ryan Blue事务性、Schema EvolutionAviod unpleasant suprisesAviod unpleasant suprisesFull Schema Evolution 字段类型提升 增加列 删除列 重命名列 调整列顺序字段类型提升：int-longfloat-doubledecimal(P,S)-

2、decimal(P,S),P P事务性事务性 原子性操作 多快照读写分离隐式分区-灵活的分区CREATE TABLE prod.db.sample(id bigint,data string,category string,ts timestamp)USING icebergPARTITIONED BY(bucket(16,id),days(ts),category)(bucket(16,id),days(ts),category)多种分区函数可供选择隐式分区-与Hive分区的区别写入写入分区由 Iceberg 根据数据自动转换生成，不需要用户管理数据正确分区查询查询用户查询时不需要考虑分区的

3、物理结构目录结构目录结构分区的物理结构(目录结构)和逻辑结构分离，便于 Partition Evolution行级更新(Format Version=2)Merge On Read 模式Iceberg 在小米的应用场景1.日志集成入湖特点：At Least Once 语义，数据可能重复按照上报时间分区，存在分区漂移问题Hive 的 Schema 和文件 Schema 不匹配Talos/KafkaSpark StreamingClientHive旧架构：旧架构：无无 SchemaSchema On Read1.日志集成入湖特点：Exactly Once 语义，数据不丢不重数据正确分区Schema

4、 On Write 保证数据正确性缺点：流程上的不规范（MQ 的 Schema 更新不及时）导致数据丢失Talos/KafkaFlink SQLClientIceberg新架构：新架构：Schema On ReadSchema On Write2.近实时数仓设备打点数据延迟上报问题数据延迟上报问题非常严重，延迟数据需要重新存储和计算凌晨离线指标拆分，资源紧张，数据产出延迟风险大数据产出延迟风险大2.近实时数仓的优点隐式分区保证延迟数据正确分区延迟数据正确分区二级隐式分区，数据扫描量减少数据扫描量减少 10 倍倍，计算资源节约 25%近实时计算替换离线计算，降低产数延时风险（凌晨风险分摊至全天）

5、3.离线场景分区完备性校验分区完备性校验分区完备性校验：校验上游表分区何时完备，下游作业可以启动离线写入的表：离线写入的表：无 SUCCESS 文件，无法使用校验文件list partition 分区比较慢，无法校验分区实时写入的表：实时写入的表：数据写入即生成分区，无法校验分区数据可能延迟到达 引入任务依赖，依赖上游任务 引入 iceberg watermark，校验 watermark3.离线场景的优化:page column index+local sort ETL 链路中整个分区执行z-order 有较大的代价 local sort+page column index 进行有效的 da

6、ta skipping3.离线场景的优化:page column index+local sortbenchmark结果:查询排序列，数据扫描量可大大减少查询非排序列基本无优化3.隐式分区在离线场景的问题 dynamic overwrite+隐式分区带来不确定性-期望覆盖 date=20230101 分区，-但实际只覆盖 date=20230101/hour=1 和-date=20230101/hour=2 分区，-不会覆盖 date=20230101/hour=3 的分区insert overwrite catalog.db.table_testval