爱奇艺在 Iceberg 落地相关性能优化与实践

演讲人：林豪-爱奇艺-助理研究员 爱奇艺OLAP团队 目录 为什么要数据湖 数据湖技术加速数据流通 适用场景 优缺点 Iceberg定义–新型表格式 Iceberg：一种新设计的开源表格式用于大规模数据集分析 -不是存储引擎：支持HDFS、对象存储-不是文件格式：使用Parquet存储数据-不是查询引擎：支持Spark/Flink/Presto/Hive 表格式–Hive及其缺陷 设计核心 SELECTcount(1)FROMhuge_tableWHEREdt>='2021-11-01’ANS dt<='2021-11-07’ANDmetric ='metric-name’; ●用目录树组织数据●Metastore记录元数据 优点：分区级过滤 如每天240分区，100文件/分区，7天命中24K个分区 缺点 ●元数据库容易成为瓶颈，与HDFS不一致 ●元信息不包含文件信息 ●执行计划需列举目录●O(N)次调用，N为命中的分区数●无法用文件级统计进行过滤 ●原子操作：仅添加分区是原子操作，且依赖文件系统移动为原子性 ●不支持修改：分区覆盖、分区重算 表格式–Iceberg 核心：记录表的所有文件 -快照：表文件的完整列表-写入：每次写入创建并提交一个新的快照 快照概念优点 ●读写分离：写不影响读行为●操作原子：跨分区修改，合并/重写文件 表格式–HiveVSIceberg 数据湖平台建设 平台总览 流式入湖 三步即可入湖 1.配置读取Kafka2.配置处理逻辑3.配置写Iceberg 出湖查询 查询入口 ●Pilot：智能SQL引擎提供统一入口●魔镜：交互式查询平台 查询引擎 ●Trino：支持V1格式●SparkSQL：支持V2格式 指标 ●每天34K查询，耗时P9042秒 性能优化 小文件–生命周期 配置策略 ●建表时分区表必须指定清理策略 清理优化 ●Sp a rk常驻模式：避免申请Ya rn耗时●天级目录删除：递归删除孤儿文件慢/分区目录不被清理●回收站：添加回收机制、避免误操作●对于大表接入TTL：原先为一次性删除所有过期的分区，遇到任务执行过久一直失败，改为每次删除固定数量的分区 清理效果 ●每个表：4文件/commi t*1 co mmi t/1分钟*6 0*2 4*7分钟=4 0 K文件●日志库从2亿Inode稳定在4千万 小文件–智能合并 定时合并 ●合并任务参数复杂，配置困难●合并时机、合并范围：譬如3小时后合并小时分区，一天后合并天分区●如合并范围过小：则小文件过多，查询性能下降●如合并范围过大：则有重复合并，写放大 智能合并 ●基于分区下文件大小均方差自动选择待合并分区●𝑀𝑆𝐸=∑!"#$𝑇𝑎𝑟𝑔𝑒𝑡𝑖−𝐴𝑐𝑡𝑢𝑎𝑙𝑖2÷𝑁●微调：业务设置权重、执行失败权重降级●业务无需任何配置 参考：Netfilx-Optimizing data warehouse storage 小文件–智能合并 定时合并 ●合并任务参数复杂，配置困难●合并时机、合并范围：譬如3小时后合并小时分区，一天后合并天分区●如合并范围过小：则小文件过多，查询性能下降●如合并范围过大：则有重复合并，写放大 智能合并 ●基于分区下文件大小均方差自动选择待合并分区●𝑀𝑆𝐸=∑!"#$𝑇𝑎𝑟𝑔𝑒𝑡𝑖−𝐴𝑐𝑡𝑢𝑎𝑙𝑖2÷𝑁●微调：业务设置权重、执行失败权重降级●业务无需任何配置 参考：Netfilx-Optimizing data warehouse storage 小文件–合并性能优化 D e l e teF i l e合 并 后 没 有 被 删 除 ●背 景 ：I S S U E 1 0 2 8， 最 终 在I S S U E 2 2 9 4修 复 如 果D e l e te之 后 紧 跟Re w r i te D a t a F i l e， 相 应 的D e l e teF i l e不 会 被 删 除 ●背 景：I S S U E 4 1 2 7， 目 前 仍 未 修 复 ，I S S U E 6 1 2 6在跟 进 大 表 合 并 任 务 经 常 失 败 ●B u c ke t分 区 ： 减 少 单 次 合 并 的数 据 量●B i n Pa c k合 并 ： 控 制 合 并 文 件 大 小 范 围 小 文 件 合 并 任 务 经 常 因 冲 突 而 失 败 现象：Cannot commit, found new position delete for replaced data file原因：ISSUE5404：判断待合并的DataFile没有新的DeleteFile时，Upper和Lower被截取了16bit，从而错误的判定datafile被引用修复：alter tableiceberg_tablesettblproperties( 'write.metadata.metrics.default'='full’ ); 小文件–写入参数控制 假设：任务并行度=100，hour分区跨度=1默认策略：100个文件，小文件过多Hash策略：1个文件，容易写入阻塞 Hash策略+bucket分区： ●通过bucket数量控制文件数●建议文件大小在百MB 查询优化–ID查询慢 示例：指定订单ID查询明细 指定ID明细查询慢 ●Impala+Kudu：3秒●Spark+Iceberg：948秒 SELECT*FROMorder_tableWHEREorder_id='555'; 原因 ●Kudu对列有构建索引●IcebergMinMax、字典等索引对此不生效，几乎是全表扫描 思考 ●能否为Iceberg引入BloomFilter过滤能力？●背景：Parquet Support Bloom Filter Since 1.12 查询优化–开启BloomFilter SELECT*FROMorder_tableWHEREorder_id='555'; Iceberg表参数开启 ●write.parquet.bloom-filter-enabled.column.col1 Spark/Trino读取应用 ●可过滤：equals、in●不可过滤：notequals、notin、lessthan等 贡献给社区 ISSUE-4831:Add Parquet Row Group Bloom FilterSupport 查询优化-BloomFilter效果 查询速度提升 ●SparkSQL：订单ID查询由948秒降低到10秒，整体性能接近于Impala查询Kudu●Trino：开启BF之后，文件过滤98.5%，总执行时间为40%，峰值内存为25%，CPU时间为5% 存储空间增加 ●原先884G，开启BF后913G，3%额外空间 查询优化–Alluxio缓存 查询加速-混布Alluxio ●目的：屏蔽底层HDFS性能抖动●成本：混布复用SSD，0成本查询提速 落地效果 ●Venus日志查询P90从18秒降低到1秒 查询优化–Trino元数据读取 背景：Trino读取5MB元数据近3秒 排查：火焰图+Arthas定位代码片段 异常：read方法被调用百万次 ●父类：默认实现read(byte[], int off, intlen)批量读取会循环调用read()，即逐字节读取●Trino未实现read(byte[], int off, intlen) 修复：实现对应方法，批量读取 效果：由3秒缩短至0.5秒 业务落地 业务落地–广告流批一体 流批一体 •原先：离线：HDFS、实时：Kudu•现在：统一写入Iceberg表 任务统一 •原先：离线HiveSQL，实时SparkJar包开发•现在：统一为SQL开发 查询统一 •原先：基于进度拆分查询并UNION•现在：统一查询Iceberg表 时效提升 •全链路由35分钟缩短到7-10分钟，减少超成本赔付 业务落地–Venus日志入湖 成本下降 •无需独立ES集群•复用HDFS和Trino集群•大幅节省成本 稳定提升 •ES因成本仅1副本，经常写入失败，日志缺失•HDFS3副本，单磁盘/结点故障无影响•写入带宽近乎无限，无需考虑容量规划•入湖后Venus报障降低80% 业务落地–审核 实时报表 提高人效 •审核团队人效统计•风险监控实时报警 •导数更快减少0.25人力 降低风险 查询统一 •数据导出原先需MongoDB导出为CSV，Shell脚本处理•统一为SQL查询 •降低漏审/误审带来的内容安全风险 业务落地–CDC订单入湖 提升时效 实时入湖：分钟级延迟 离线导出：需天级延迟 降低成本 机器成本：无需Kudu独立节点运维成本：消费BinlogMySQL压力低；写入带宽大，不会因写入压力阻塞MySQLIO同步 业务落地 会员订单：已导入数据，用于近实时报表广告：同步由全量改为增量，延时从20分钟降低到秒级 未来规划 ●业务 ●流批一体：更多场景应用，如广告全面使用，BIPingback场景●特征生产：分钟级延迟、支持晚到数据、支持样本修正 ●技术 ●Puffin统计信息，用于查询加速●Branch和Tag调研与应用 感谢观看！