2024峰会-京东零售数据湖应用与实践.pdf

《2024峰会-京东零售数据湖应用与实践.pdf》由会员分享，可在线阅读，更多相关《2024峰会-京东零售数据湖应用与实践.pdf（20页珍藏版）》请在三个皮匠报告上搜索。

1、DataFunSummitDataFunSummit#20242024京东零售数据湖应用与实践京东零售数据湖应用与实践陈洪健-京东-大数据架构师背景和痛点背景和痛点迭代和优化迭代和优化效果和收益效果和收益未来展望和规划未来展望和规划目录目录 CONTENTCONTENTDataFunSummitDataFunSummit#202420240101背景和痛点背景和痛点数据实时性和完整性矛盾在线分析和在线训练场景需要数据具备实时性（T+0）和一定的历史数据。但当前数仓采用Lambda架构，实时数据和历史数据分别存储在不同介质中，使得在需要同时具备实时性和完整性的数据应用场景下，用户需要分别对接不同

2、的系统，使用不同的API实现需求，并且需要接受口径差异问题，这样的设计低效且不友好。架构维护成本高1、当前的埋点日志入仓采用自运维的Plumber任务，对物理机资源有强依赖，日常需求达到百台，大促期间更需数百台。但集团正处于减少物理机资源阶段，可能无法满足未来扩容需求。2、当前实时数据通过秒级数据实现，整体计算和存储资源较高，对于低优先级或对时效无强要求的场景，存在资源浪费的情况。3、离线链路冗长，T+1批处理时数据量级波动大，导致任务时效性受影响。波动时GDM资产完成时间可能超过4:00，可能引发雪崩，任务集中抢占资源，导致大量任务延迟时效性问题。状态数据的更新和存储问题 在当前的传统数据仓

3、库架构中，数据状态的更新是一种重量级操作，它的操作方式是将分区内全部数据重写，即使其中的大部分数据没有发生变化。这不仅浪费了大量的计算资源，也降低了系统的效率。另外，为了能快速查询到历史时刻的数据快照，我们每天或每小时都要存储全量数据，这同样消耗了大量的存储资源。典型案例：商品价格表-小时粒度（目前只包含10%活跃商品）商品全量表-天粒度：每天数据量数千亿，以每天数亿的速度增长DataFunSummitDataFunSummit#202420240202迭代和优化迭代和优化技术方案1.流量涉及的生产库写实时Topic；2.将处理的离线MR作业改为流处理的Flink作业，提升数据时效；3.将数据

4、通过Flink作业写入Hudi表；4.对数据进行逻辑加工和不同表的JOIN，生成GDM/RDDM 对外开放模型表；多流合并存储模型存储模型:分区表+MOR+Bucket 性能性能提升提升:降低list操作频次、Bucket2GB 非分区表-分区表 限定保留版本数200(版本数*平均提交周期)，定时clean、Archive 异步Compaction操作 降低成本降低成本 多表资源复用(资源成本)可视化和自动建表(人力成本)数据一致性数据一致性:数据保序:表主键Hash分组传输 数据完整性:心跳机制和业务的时间窗去判断数据的完整性，Precombine可持续性可持续性 健壮性(数据积压、任务异常

5、、数据时延等)元数据更新，业务变更带来的分析库结构变更 稳定性(资源隔离、上游集中刷数、定时跑批)外键关联每10min一批次，执行以下a)sku增量数据关联维表(spu)全量数据b)spu增量数据关联sku fdm全量数据c)union后写入m03表关联复杂降低策略关联复杂降低策略:维度建模、分层存储、临时表 过载控制过载控制:记录级限流，资源配置模型 开发方式开发方式:FlinkSQL+SparkSQL 能力增强能力增强:Hudi维度表的能力，维表lookup MOR表增量读优化，优先读取 Log 文件 Spark与Flink混写一致性优化(索引、数据格式等)状态后端表TTL设定，表级别 T

6、TL.持续稳定持续稳定:异常恢复、监控告警增强(数据积压、限流、checkpoint失败、处理流量等)查询优化1.数据缓存（1）Hudi 元数据缓存（2）Block级文件缓存：通过将外部存储系统的原始数据按照一定策略切分成多个 block 后，缓存至 StarRocks 的本地 BE 节点，从而避免重复的远端数据拉取开销，实现热点数据查询分析性能的进一步提升。2.异步物化视图物化视图是特殊的物理表，能够存储基于基表的预计算结果。当对基表执行复杂查询时，StarRocks 可以自动复用物化视图中的预计算结果，实现查询