Datafun-SmartNews-戢清雨.pdf

《Datafun-SmartNews-戢清雨.pdf》由会员分享，可在线阅读，更多相关《Datafun-SmartNews-戢清雨.pdf（31页珍藏版）》请在三个皮匠报告上搜索。

1、DataFunSummitDataFunSummit#20242024SmartNews SmartNews 基于基于FlinkFlink的的IcebergIceberg实时数据湖实践实时数据湖实践戢清雨-SmartNews-数据平台架构师SmartNewsSmartNews数据湖介绍数据湖介绍基于基于Iceberg v1Iceberg v1格式的数据湖实践格式的数据湖实践基于基于FlinkFlink实时更新的数据湖实时更新的数据湖（Iceberg v2Iceberg v2）解决方案）解决方案实时更新小文件问题的优化实时更新小文件问题的优化目录目录 CONTENTCONTENTDataFunS

2、ummitDataFunSummit#202420240101SmartNewsSmartNews数据湖介绍数据湖介绍公司介绍创立于东京2012纽约/旧金山/帕托办公室成立2014上海/北京 办公室成立2019东京办公室成立广告数据湖 广告数据点击/转化信息存储在Hive/Kafka实时更新 维表信息广告主信息/统计信息存储在MySql/Hive实时/小时更新挑战 需要按广告主键去重 需要更新点击/转化时间戳 下游进实时读取DataFunSummitDataFunSummit#202420240202基于基于Iceberg v1Iceberg v1格式的数据湖实践格式的数据湖实践Iceberg

3、介绍 开放数据湖表格式 支持ACID语义 历史版本回溯 Schema变更Iceberg MetadataIceberg v1实践解决挑战 在Spark作业中按照主键去重并且更新时间戳 通过Iceberg方案解决上下游同时读写问题 小时级别更新数据方案不足 占用Infra资源太多 计算资源浪费-需要更新的行只占总体的1%左右 存储资源浪费-每次Overwrite都需要重写所有数据 并行提交到Iceberg的锁问题DataFunSummitDataFunSummit#202420240303基于基于FlinkFlink实时更新的数据湖实时更新的数据湖(Iceberg v2)(Iceberg v2)

4、解决方案解决方案Iceberg v2 解决方案解决方案对比Spark+Iceberg v1Spark+Iceberg v1Flink+Iceberg v2Flink+Iceberg v2写入方式OverwriteUpsert输出文件数量文件大小平均，数量可控小文件数量巨大计算方式全部重新计算Merge on Read，仅计算更新数据实效性小时级别分钟级别DataFunSummitDataFunSummit#202420240404实时更新小文件问题的优化实时更新小文件问题的优化实时更新小文件优化 每次插入数据会生成两条Record-Delete/Insert 存储空间浪费 下游Writer造成

5、CPU压力Flink Generated RowDataFlink Iceberg SinkEqualityFieldKeySelectorEqualityFieldKeySelector 按照Record主键shuffle到下游writer 在同一个partition路径下面会有多个writer同时写入EqualityFieldKeySelectorEqualityFieldKeySelectorPartitionPartitionRecordRecord数量数量每小时文件生成数量每小时文件生成数量ts=2022-10-01-23xxx M3(checkpoint interval)*10(

6、writer)*3 files(data file/equality delete/position delete)ts=2022-10-01-22xx M90ts=2022-09-27-00 x K90假设checkpoint的间隔为20分钟，使用10个writer去写文件 PartitionKeySelectorPartitionKeySelector 按照Record的partition信息shuffle到下游writer 在同一个partition路径下面只会有1个writer写入PartitionKeySelectorPartitionKeyS