于汝国-京东流量资产基于湖仓架构的落地实践(1).pdf

1、京东零售-集团数据计算平台于汝国/技术专家京东流量资产基于湖仓架构的落地实京东流量资产基于湖仓架构的落地实践践背景与痛点01挑战与优化02收益与表现03总结与展望04目 录01 背景与痛点Lambda架构湖仓一体架构离线与实时异构 链路冗余，成本较高 数据口径不一致数据重复问题离线T+1数据时效，SLA压力较大统一数据口径，减少存储成本基于Hudi事务能力，实现EOS（Exactly-Once Semantics）Flink+Hudi为下游提供分钟级数据02 挑战与优化多模IO能力挑战：挑战：某些HDFS集群在热点时段繁忙度较高。此时Flink流写Hudi会出现timeout重试甚至异常重启，

2、导致写入性能均值吞吐受限，且扩Flink资源对性能提升效果不明显解决方案：解决方案：自研湖表多模IO能力，将湖表物理存储划分为缓冲层和持久层，流量数据先写高性能缓冲层，极大提升写入性能与任务稳定性，且吞吐能够横向扩展可 插 拔 存 储 介 质统一 IO 抽象层落地场景逻辑表视图02 挑战与优化多模IO能力数 据 可 见 性与 数 据 时 效数据写入缓冲层并commit后即对下游可见，无论后续“搬运工作”何时开始与结束都不影响数据可见性与时效数 据 流 转 过 程热数据先写到数据缓冲层，后续再通过Clustering/Compaction等表服务“搬运”至数据持久层，满足性能、稳定性诉求一 致

3、性 语 义复用了湖表Compaction和Clustering表服务能力，来实现缓冲层到持久层的数据搬运工作，该行为同样遵循湖表的commit机制与MVCC快照隔离设计，因此湖表开启数据缓冲层后，同样具有原子性、事务性保障以及EOS语义 02 挑战与优化多模IO能力普通湖表读写流程湖表数据缓冲层读写流程02 挑战与优化多模IO能力湖表数据缓冲层 读 写 流 程开启湖表缓冲层Flink任务入湖速率监控:开启湖表缓冲层后，入湖任务写入均值速率和稳定性有所改善 未开启湖表缓冲层相同资源 开启缓冲层后：更快、更稳定 Hudi写入吞吐提升100%CP时长减少95%稳定性提升97%02 挑战与优化湖表动态

4、分区策略挑战：挑战：业务分区倾斜严重，最大分区与最小分区数据量相差730万倍，需解决数据倾斜导致的写入性能和小文件问题解决方案：解决方案：在Flink流写Hudi的核心拓扑链路上，新增自定义Partitioner策略，根据湖表数据特征来路由数据，从而缓解数据倾斜，控制文件数量File File numnum =表分区数*Sink并行度eg：表分区数54，Sink并行度2000，一次commit产生文件数至少为10.8w个02 挑战与优化湖表动态分区策略优化：优化：根据各个分区的大小来设计动态分区策略，数据量较大的分区(如S、P)，单独路由到特定的subtask集合，集合的大小根据该分区对应的数

5、据量大小确定，S分区占据了近一半的数据，因此它的subtask集合占据了Sink算子并行度的一半，而其他非常小的分区则三两成队路由到单独的subtask（尽量减少单个subtask写分区数量，减少写入句柄切换）。效果：效果：按此方式优化后，一次commit写入的文件约为6000+，减少了94%，写入性能提升了1倍多。02 挑战与优化多写并发Append挑战：挑战：随着流量数据量的持续提升以及大促场景下的骤增，受Flink机房资源限制，且单个Flink集群即使扩容后性能也会出现瓶颈，如何提升实时入湖任务的写入性能成为一大挑战解决方案解决方案：将入湖任务拆分成多个，通过扩展湖的多写能力并发Appe

6、nd同一张流量湖表检查点元数据冲突Hive元数据冲突任务任务1 1 分区S、分区P任务任务2 2 非分区S、分区P02 挑战与优化反序列化优化挑战：挑战：新架构仍旧以JSON为数据格式，但是比旧架构多了120+字段，行级的反序列化成本很高，尤其数据量级增大之后，往往成为整个任务的性能瓶颈解决方案：解决方案：将source读取消息后的反序列化操作拆解到单独的算子中，通过扩并行度提升任务性能 解析Headers过滤不需要的业务域数据，而非通过Deser整个消息后来过滤优化优化1 1：将Deser操作从Source算子中抽出来，Source算子只负责从Topi