京东零售数据湖应用与实践

背景和痛点

1. 数据实时性和完整性的矛盾

2. 架构维护成本高

• 离线批处理的 ETL 任务繁重，当前的埋点日志入仓采用自运维的 Plumber 任务，对物理机资源有强依赖，日常需求达到百台，大促期间更需大量扩容。但整个互联网的趋势是降本增效，如何在减少物理机使用的情况下满足业务需求成为我们需要解决的问题。
• 实时数据为达到秒级处理，通常采用 Kafka+Flink 的架构实现，整体计算和存储资源消耗较高。实际业务中存在着低优先级或者实时性要求不高的场景，在目前的架构下无法灵活实现，存在资源浪费的情况。
• 离线处理的链路冗长，不含中间表的情况下，也需要至少四层的计算。另外，T+1 批处理的时间集中，如果遇到数据量级波动，网络堵塞，或者机器故障等情况，都会严重影响任务产出。比如波动时 GDM 资产完成时间可能超过 4:00，任务爆发雪崩并开始集中抢占资源，导致大量任务延迟。

3. 状态数据的更新和存储问题

迭代和优化

1. 架构变更

• 流量涉及的生产库写实时 Topic：原先埋点数据采集过后写入 CFS，HDFS 接入 CFS 数据开始入仓，改造后 CFS 上的数据成为实质上的 Topic。

• 将处理的离线 MR 作业改为流处理的 Flink 作业：使用 Flink 任务采集 CFS 的 Topic 数据，来代替数仓中使用 MR 做引擎的 ETL 任务，提升数据时效。

• 将数据通过 Flink 作业写入 Hudi 表：Hudi 旨在将流处理和批处理的优势结合起来，允许处理增量数据，这意味着可以仅处理自上次查询以来发生变化的数据，而不是每次都加载整个数据集；同时提供了索引和事务的支持，如 Bloom Filter 索引和列值索引有助于查询加速，对事务的支持可以保证多并发写入下的数据一致性。

• 对数据进行逻辑加工和不同表的 JOIN，生成 GDM/RDDM 对外开放模型表。

2. 多流合并

• 降低list 操作频次、计算离线往期分区大小，Bucket 不超过 2GB

• 为了减少小文件，将非分区表改为了分区表

• 限定保留版本数 288/分钟、25/小时（版本数*平均提交周期），定时 clean、Archive

• Flink fdm 层'compaction.async.enabled' = 'false'，spark 层创建合并任务进行异步 Compaction 操作

• Flink 切换到 Spark 引擎 eventtime.field=ts 保持数据更新规则一致

• 多表资源复用，把原本分散在各个业务形态中的数据进行了合并处理，从而降低资源成本

• 建设 DMS 系统自动建表，表增删改统一管控收口，创建相关任务，并实现了对任务状态和异常的可视化，使异常定位和处理变得非常便捷，从而降低了人力成本

• 数据保序：表主键 Hash 分组传输

• 数据完整性：根据 Hudi 的心跳机制和业务的时间窗去判断数据的完整性， Precombine=业务时间，多个时间编写多时间 payload 函数进行更新

• 健壮性，对数据积压、任务异常、数据时延等创建监控策略进行监控

• 元数据更新，业务变更带来的分析库结构变更

• 稳定性，实现了资源隔离，保证上游集中刷数、定时跑批时的稳定性

3. 外键关联

• SKU 增量数据关联维表（SPU）全量数据

• SPU 增量数据关联 SKU FDM 全量数据

• union 后写入 m03 表

• Hudi 维度表的能力，维表 lookup

• MOR 表增量读优化，优先读取 Log 文件

• Spark 与 Flink 混写一致性优化（索引、数据格式、eventtime 等）。spark 任务 compaction 数据 call run_compaction(op => 'run', path => '{path}');

• 状态后端表 TTL 设定，表级别 TTL

• 持续稳定：异常恢复、监控告警增强，对数据积压、限流、checkpoint 失败、处理流量等问题及时处理。

4. 查询优化

• Hudi 元数据缓存

• Block 级文件缓存：通过将外部存储系统的原始数据按照一定策略切分成多个 block 后，缓存至 StarRocks 的本地 BE 节点，从而避免重复的远端数据拉取开销，实现热点数据查询分析性能的进一步提升。

• 本地存储加速：物化视图可以利用 StarRocks 的本地存储加速优势，如索引、分区分桶和 Colocate Group，从而相较直接从数据湖查询数据具有更好的查询性能。

• 无需维护加载任务：物化视图通过自动刷新任务透明地更新数据，无需维护导入任务。此外，基于 Hive、Iceberg 和 Paimon Catalog 的物化视图可以检测数据更改并在分区级别执行增量刷新。

• 智能查询改写：查询可以被透明改写至物化视图，无需修改应用使用的查询语句即可加速查询。

效果和收益

1. 时效提升

2. 作业效率提升

3. 存储节约

4. 统一口径和 API

5. 查询分层

未来展望和规划

• 容灾措施（机房宕机、任务重启、数据修复等）。

• 与批任务的资源隔离，实现弹性伸缩能力，优化资源消耗。

• 针对 Hudi 流式写入带来的小文件问题，我们尝试了通过定时的 compaction，以及分桶、分区等方式，进一步将开发一些插件使问题得到自动的解决。

• 数据免疫系统建设。

• 提升 Hudi 表的自管理能力，降低维护成本。