《2、刘迪珊-美团基于流批一体构建增量数仓生产实践.pdf》由会员分享,可在线阅读,更多相关《2、刘迪珊-美团基于流批一体构建增量数仓生产实践.pdf(39页珍藏版)》请在三个皮匠报告上搜索。
1、刘迪珊美团基于流批一体构建增量数仓生产实践The Production Practice of Building Incremental Data Warehouse based on Unified Architecture at Meituan项目目标核心设计与实现计算能力优化未来展望#1#2#3#4#1项目目标数仓生产面临的问题#1离线实时两套计算逻辑,口径难统一:离线实时数据生产,采用两套技术栈,产出两套数据海量数据就绪时间难保证:对于天级海量数据,离线生产性能优化的空间近乎达到瓶颈实时生产准确性依赖状态容量:状态越大、快照制作和恢复的成本越高,时效性和准确性间权衡#2#345本期目标
2、:1)数仓生产时效性提升:T+1-分钟级,特征生产主流程落地2)建立同时支持批量和增量读写的存储引擎3)Flink支持对上述存储引擎的增量读写4)提升Flink在百万QPS/10TB状态下,流计算任务的处理能力和稳定性KafkaKafka事件服务Flink集成Flink实时增量存储SparkFlink增量增量存储Flink导出OLAP数仓增量生产目标离线数仓增量数仓#2核心设计与实现6需求背景7图片来自社区分享:https:/ Flink作为增量生产的计算引擎 Flink流批统一架构,一套代码、统一计算口径需求背景8明细层2 增量读写的必要性增量存储Flink增量存储Flink聚合层Flink
3、增量存储标签层增量读增量写 离线数仓分层划分,目标增量化表的上游链路上的所有节点也必须增量化需求背景93 批读的必要性Flink增量存储标签层Flink导出线上存储HDFS/HIVE增量读批读Spark线上特征生产增量化原BI下游保持批处理不变 终极目标:增量生产架构替换原有离线生产架构 增量生产架构:不是所有节点都一定是增量化的,而是这套架构能同时支持增量和批计算需求背景104 批写的必要性Flink增量存储标签层HDFS/HIVE增量写增量存储Flink批写存量数据增量数据 存量数据,批写初始化 数据修复,批量更新需求背景115 Upsert的必要性增量数据idvalue110022003
4、30044001001000idvalue10100存量数据idvalue0440010110100最新数据 增量数据需要与全量数据进行merge 增量数据远少于全量数据,若不支持Upsert,读取全量数据效率低6 before/after的必要性+100,1,0,1+101,1,0,2-101,1,0,2+101,1,1,2changelog流KafkaFlink集成增量存储Flink增量增量存储idpay_status delivery_status poi2UPDATE,100,1,0,1UPDATE,101,1,0,2U
5、PDATE,101,1,1,2CDC变更数据(binlog)输出:更新外存 id,pay_status,delivery_status,poiSELECT COUNT(id)AS cnt FROM orders WHERE pay_status=1 AND delivery_status!=1 GROUP BY poi;poicnt1120orders表(主键:id)poi表(主键:poi)UPDATE 1,1UPDATE 2,1UPDATE 2,0输出:更新外存 poi,cnt 增量生产的表既会作为结果查询,又会作为作为下游增量生产的输入 对于一个增量任务,为了保证结果数据的准确性,需要依赖
6、before/after进行回撤12需求背景需求背景137 事务的必要性(Exactly once)+100,1,0,1+101,1,0,2-101,1,0,2+101,1,1,2changelog流KafkaFlink集成增量存储Flink增量增量存储idpay_status delivery_status poi2UPDATE,100,1,0,1UPDATE,101,1,0,2UPDATE,101,1,1,2CDC变更数据(binlog)输出:更新外存 id,pay_status,delivery_status,poiSELECT COUNT(id)AS cnt FR
7、OM orders WHERE pay_status=1 AND delivery_status!=1 GROUP BY poi;poicnt1120orders表(主键:id)poi表(主键:poi)UPDATE 1,1UPDATE 2,1UPDATE 2,0输出:更新外存 poi,cnt 存储与计算联动回滚,否则会出现重复计算 存储层要支持事务提交,并与计算checkpoint保持一致设计假设与权衡141 表存储均有主键idvalue044001001000自增主键sessionseqNovalue2200233005001001100复合主键F
8、link增量SELECT COUNT(id)AS cnt FROM orders_detail WHERE pay_status=1 AND delivery_status!=1 GROUP BY type;+100,1,0,1+101,1,0,2-101,1,0,2+101,1,1,2changelog流增量存储idpay_status delivery_status poi2orders表(主键:id)计算模块产生变更数据需要依赖Flink状态,会增加计算/运维成本,增加故障恢复时间 若只由计算产生变更数据,随着计算深度的增加,数据会呈指数放大。下游计算压力变大,资源
9、消耗增加15设计假设与权衡2 存储具备产生before/after的能力Flink增量SELECT o.id,o.pay_status,o.delivery_status,p.type FROM orders AS o JOIN poi FOR SYSTEM_TIME AS OF o.proc_time AS p ON o.poi=p.id;增量存储idpay_status delivery_status type110orders_detail表(主键:id)+100,1,0,10+101,1,0,10-101,1,0,10+101,1,1,10changelog流设计
10、假设与权衡163 单表由一个任务写入Flink增量SELECT o.id,o.pay_status,o.delivery_status,p.type FROM orders AS o JOIN poi FOR SYSTEM_TIME AS OF o.proc_time AS p ON o.poi=p.id;增量存储idpay_status delivery_status type110orders_detail表(主键:id)+100,1,0,10+101,1,0,10-101,1,0,10+101,1,1,10changelog流 多个任务同时更新同key数据,会出现数
11、据一致性问题。除非存储层进行排序 一个任务出现故障回滚时,还需要其他任务进行事务的协调设计假设与权衡174 计算任务保证消息按主键的有序性增量存储keyBy(主键)stream write 不同实例写同key数据,同样会有顺序性问题,产生的before/after可能会不一致,造成计算结果不一致 顺序性要求与计算场景更为紧密,排序前置灵活性更好18设计假设与权衡5 存储负责产生和提供事务IDJob1Job2增量存储idf1f2f3f412n 可扩展性,考虑未来支持多任务更新单表不同列子集 存储产生递增事务ID更直接和统一,能避免跨任务间的事务协调196 计算顺序提交,并负责对失败的事务进行回滚
12、设计假设与权衡Job1增量存储Max(cid)=5cid5 status=INITEDApply cid6 事务ID是递增的 客户端顺序申请和提交,并对故障的事务进行回滚 当前最大事务ID对应状态不是终态时(已提交或已回滚),不允许客户端申请新的事务ID增量存储关键能力与设计权衡总结批写(初始化)增量插入/更新/删除写能力对齐批读接口增量读变更(before/after)读能力具备分钟级事务提交能力对于未成功提交的事务,具备回滚能力事务性201.所有表均有主键2.存储具备产生before/after的能力3.单表由一个任务写入4.计算保证消息按主键的有序性5.存储负责产生和提供事务ID6.计算
13、顺序提交,并负责对失败的事务进行回滚设计假设与权衡:数据湖存储 普遍支持批量和增量读写 普遍支持多版本与事务性 多种底层存储,数据表逻辑组织结构21增量存储Beluga整体架构 客户端API:面向应用程序,提供读写接口、事务接口 KV层:基于HBase改造。支持按主键插入、更新和删除数据;负责生成before/after数据 Storage层:基于Hudi改造。集成成熟读写接口和设计,支持增量读写和批量读写FlinkBelugaKV整表PartitionPartition增量数据时间序增量读批读/写增量写22Beluga 客户端APIHDFSBeluga ClientHudi ClientCo
14、mmit(cid)Write(cid)Buffer&BatchApply CommitIdRollback(cid)HBase ClientPut/Delete(cid)PutAll/DeleteAll(cid)Commit(cid)Apply CommitIdRollback(cid)HBase 客户端对外接口与Hudi类似,保留嵌入式设计 增量写时,为生成全表快照(获取before/after),由原先直接写HDFS,改为先调用HBase接口 增量和批读取,复用Hudi能力23Beluga 增量写-KV层数据1 HBase提交状态表(Commit Status Table),维护事务当前的
15、状态,用于事务提交与回滚 表region级别的commit信息(第一阶段)表级别的commit信息(第二阶段),表当前最大的commitidRowKeyColumn Family detailColumn Family cftablename+cid1cf:status=“committed”tablenamecf:max=“cid1”tablename+cid1+regionid2 detail:status=“committed”tablename+cid1+regionid1 detail:status=“committed”tablename+cid2cf:status=“inited
16、”提交状态表(Commit Status Table)24Beluga 增量写-KV层数据2 HBase原始数据全量表(Original Data Table),支持同主键在一个事务中更新多次 commitid保存到元数据tag中,支持一个事务中同key多次写入 多版本保留时间为天级(7天),按写入时间超过版本保留时间,进行压缩 使用TimeStamp+SeqNo,保证同一个事务内同key多次写入的顺序RowKeyTagTmeStampColumn Family cfkey1cid1t4cf:value=“”key2cid1t3cf:value=“”key1cid1t2cf:value=“”k
17、ey1cid2t1cf:value=“”原始数据全量表(Original Data Table)25Beluga 增量写-整体流程26Beluga 增量写-事务开启27 tablename,max commitid+tablename+cid,status=INITEDBeluga 增量写-数据写入28Beluga 增量写-文件合并 自定义合并策略,优先对commit内文件数量超过阈值的文件进行合并 越旧的commit,合并跨度越大;越新的commit保持独立性,方便快速回滚29Beluga 增量写-事务提交30Beluga 增量写-事务提交31Beluga 增量写-事务回滚32Beluga
18、Storage层持久化33#3计算能力优化大作业与状态稳定性优化35HDFSBlobServerJobManagerBlobCacheTaskManagerTaskTaskJarBlobCacheTaskManagerTaskTaskJarHDFSBlobServerJobManagerBlobCacheTaskManagerTaskTaskJarBlobCacheTaskManagerTaskTask美团Flink大作业部署与状态稳定性优化实践生产实践 01月08日 17:20-18:00 冯斐 王非凡Join算子优化36Flink Join算子优化核心技术 01月08日 17:20-18:00 孙梦瑶#4未来展望未来展望1)Beluga优化:kv与storage层存储整合,减少存储冗余/IO和rpc交互2)降低数据可见性延迟3)Beluga支持点读4)Flink计算状态容量扩展,利用增量存储进行冷数据的访问更新38