京东零售海量数据处理实践总结
01 京东零售流量数仓架构介绍
京东零售-流量简介
流量是指用户作用于页面上产生的一系列行为数据的集合，来源包括微信/手Q/小程序、IOS/Android H5、智能设备传感器、网页客户端、服务日志等。
京东零售-流量数据处理架构
京东零售-流量数仓分层介绍
- 数据缓冲层（BDM）：源业务系统数据的快照，按天保存原始明细数据。
- 贴源数据层（FDM）：保存源业务系统数据快照，一般不开放使用。
- 基础数据层（GDM）：统一数据清洗、整合，实现各主题数据标准化，屏蔽生产系统干扰。
- 公共数据层（ADM）：
- ADM-S：提供各主题统一维度和指标的聚合数据，为业务方提供统一口径的共享数据服务。
- ADM-D：负责统一的数据口径封装，提供各主题统一维度和指标的最细粒度数据。
- 应用数据层（APP）：根据不同业务需求设计构建展示层数据。
- 维度层（DIM）：对具体分析对象的分析角度，具备丰富的属性，以及通用维表要保证一致性。
京东零售-流量离线数仓架构
- 面向实体的模型建设：按照日志类型分渠道、分表，提供整合后的流量基础数据。
- 面向业务过程模型建设：明细层整合不同渠道数据，汇总层提供各主题统一维度和指标的聚合数据。
- 面向数据看板模型建设：按产品端使用情况，重点解决数据引擎查询效率问题，高频维度提供预计算。
- 面向多维分析数据服务建设：根据不同业务场景，提供多维数据分析和查询能力，以及统一的服务接口。
- 统一服务指标市场维度管理：统一数据服务。
京东零售-流量实时数仓架构
- 数据源包括原始数据数据库binlog、原始日志、应用消息队列等。
- 应用场景包括渠道维表、实时数仓指标、市场维度管理等。
- 计算层使用Flink进行实时指标计算，存储层使用HBase、Jimdb等。
02 京东零售场景的数据处理
京东零售-流量挑战
- 数据爆炸式增长：服务器增长的边际效应低，资源开销大。
- 业务复杂度高：全渠道、多业态带来的数据灵活性和拓展新挑战。
- 时效要求高：指数级数据增长下，高时效性需求。
- 数据处理效率低：复杂业务场景、多维数据组合+海量数据表，导致数据建设效率低。
海量数据更新实践-刷岗
- 什么是刷岗：将发生在该SKU的历史事实数据，按照最新的SKU对应运营人员、岗位、部门等维度信息，进行历史数据回刷。
- 数据量级大挑战：刷岗涉及百亿数据量级，存在数据倾斜和刷新频率高等问题。
基于数据湖+OLAP流量刷岗
- 使用Iceberg特性：基于MVCC，支持ACID事务语义，支持增量数据导入和更新删除能力，深度集成数据模式，更强的索引支持。
数据倾斜治理方案
- 什么是数据倾斜：数据分布不均，出现热点KEY，导致大量数据集中到一点上。
- 数据倾斜的表现形式：HIVE：map阶段早就跑完了，reduce阶段一直卡在99%；SPARK：大部分task执行都很快，部分task执行很慢。
- 数据倾斜出现的原因：GROUP BY KEY、JOIN关联、COUNT DISTINCT等。
- 治理方案：
- 利用实时数据进行热点监测，倾斜阈值动态监测，调度配置管理。
- 热点key范围圈定：根据特定指标（PV）进行异常值检测，对热key聚合图观测，求二阶段离群点。
- 调度任务由整体串联执行和固化并发，调整为按资源健康度动态扩展。
03 数据处理架构未来探索
未来探索方向
- 预期收益：同一套代码，两种计算模式，计算口径一致，研发效率提升；流、批同一套计算+存储，开发、维护成本大幅降低。
- 挑战：开发模式改变。
- 架构方案：基于FlinkSQL和数据湖存储的流批一体Kappa架构，传统Lambda数据架构痛点在于同时维护实时平台和离线平台两套计算链路，运维成本高，开发成本高，数据一致性难保证。
