京东零售数仓：从离线、实时到流批一体的演进之路

最新推荐文章于 2022-08-30 10:11:05 发布

智慧化智能化数字化方案

最新推荐文章于 2022-08-30 10:11:05 发布

阅读量921

点赞数

文章标签：零售 big data 数据仓库

原文链接：https://mp.weixin.qq.com/s/3ECg_KRL-SC49o55Nx0TYg

版权

第一阶段

21世纪的第一个10年，企业级数据仓库从萌芽到发展，“IOTteradata” 占据了大部分市场，提供数据仓库建设从硬件、软件到实施的整体方案。

第二阶段

2010年-2020年，大数据平台阶段，移动互联网的飞速发展，带动大数据的发展，其中Hadoop生态技术开始大规模使用，基于Hadoop 分布式计算框架，使用相对廉价的PC服务器就能搭建大数据集群。

第三阶段

就是我们当前所处的阶段，经过前10年不断的积累，大数据在方法和组织的变革上也有了新的沉淀，主要体现在：

1）数据资产化

通过数据地图与数据血缘实现360°数据全链路追踪。

2）数据服务化

提供标准的数据服务，支持数据产品的灵活调用。

3）工具组件化

数据在采、存、算过程中涉及多业务线条、多场景，将这些场景与工具进行组件化沉淀，避免重复建设。

4）数据智能化

通过人工智能实现大数据的智能化应用。

在行业中，数据中台有非常多的开源技术可供选择，尤其是Hadoop生态圈，从数据整体流向来看各大层级的选型：

传输层

原始数据的抽取，Scribe和Flume作为非结构化日志接入，DataX作为结构化数据离线抽取，Kafka作为流式数据总线。

存储层

Hadoop文件系统HDFS，Alluxio基于内存的分布式文件系统。

计算层

离线计算主要是Hive、Spark、MR：多维分析引擎一般基于现有Clickhouse、Doris和ES：实时计算前些年Storm、Spark Streaming比较流行，现在基本都转到Flink。

调度

基于Airflow、Oozie或者开源的Dolphin-scheduler。

平台层

包括数据开发的基本运行环境和各类工具的组合，如ETL工具，模型设计工具，脚本开发工具，线上日志工具等等。

服务层

主要将公共数仓的公共模型数据对外包装并提供服务，包括数据服务平台，多维分析平台，即席查询平台。

应用层

基于数据服务的数据产品，另外数据安全、数据质量和数据治理总是贯穿始终。

二、京东零售大数据的发展过程

1、发展阶段

京东零售大数据发展的几个阶段如下：

1）第一阶段

业务驱动数据技术发展，业务野蛮生长，以解决业务痛点为核心，导致烟囱式诞生了一些小数据平台。

2）第二阶段

业务精细化运营，数据平台将多业务线条、多场景的能力进行沉淀，形成数据资产。

3）第三阶段

数据中台化建设已完成，数据驱动业务，通过数据挖掘、分析和人工智能，规模化的赋能业务，经过3个阶段的发展，百家争鸣的数据平台也逐步过渡到百花齐放的数据中台。

2、业务场景

京东有最全的线上零售全链路业务场景：

始于用户，平台提供订单、营销、流量场、财务结算、供应链及商品管理，后端有仓储和配送。

基于整个零售业务，构建全域的数据资产体系，使业务数据化，数据业务化，沉淀业务模型资产，反哺于业务。

3、面临的挑战

数仓建设过程中面临如下挑战：

烟囱式的开发，各自顾各自的业务，模型重复建设，口径不统一，给业务造成困扰也浪费了资源；

数据爆炸式的增长，硬件成本增长的边际效应越来越低；

海量数据，如何评估数据的价值，如何治理海量数据；

业务复杂度高，全渠道多业态带来的数据拓展的新挑战；

实时数据需求多，实时开发门槛高周期长；

数据时效性保障，数据指数级增长，但是时效不能增长。

4、核心需求

解决以上的挑战，我们需要有以下4个维度构建数仓核心能力：

1）数仓架构

从烟囱式的数据开发到统一的数仓分层架构，将烟囱式的通用数据模型层按职责重新划分为:维度层、基础数据层和公共数据层。

维度层

用户来分析数据的窗口，维度表中包含事实表中记录的特性。

基础数据层

数仓的核心层，负责统一的数据清洗、整合，实现各主题模型标准化，屏蔽业务系统干扰，保障基础数据的高可用。

公共数据层

数仓中使用率最高的：

-D：统一口径封装，提供各主题统一维度和指标的明细数据；
-S：统一口径封装，提供各主题统一维度和指标的聚合数据。

2）数据建模

提供统一的数据建模方法论和工具，规范建模过程，统一维度和指标管理。

数仓建模分两类视角，包括业务域视角和主题视角；

数据业务域根据零售的具体业务进行划分，层次和分类相对灵活，数据主题也就是咱们经常提到的数仓主题，如商品、流量、交易、用户等等；

基于统一维度市场选取模型维度，标准化的描述指标及派生指标逻辑，消除指标口径的二义性，从开放式的数据开发到规范建模。

3）数据资产管理

我们的思路是，围绕数据的全生命周期，去构建丰富的元数据，基于元数据进行数据治理、并提供资产化的服务。整个过程链接了数据生产者和数据消费者两端，我们涵盖了从数据资产的规划、建设、采集、盘点、评估、应用、销毁等环节。

元数据分类上，我们切分了两个维度，一方面包括了元数据的范围，比如模型元数据、指标元数据、标签元数据等，尽可能的丰富，另一方面从类型上，也划分成技术元数据、业务元数据、管理元数据等。

基于元数据的治理方面，我们从数据生命周期管理，数据质量、数据安全共享、数据地图、数据百科、数据血缘这几个方面为数据治理提供更多的抓手，来保证数据资产的高质量，最后再将这些高质量的数据资产，通过服务化的方式提供给数据消费者，降低数据消费门槛。

4）数据质量保障

主要包括3个角度，准确性、及时性和一致性。

事前预警：按照标准化的开发流程，生产与开发隔离，对打包、预发和上线流程进行检查和验证。

事中监控：全链路监控，任务运行时效告警监控,出现问题能快速发现。

事后恢复：快速定位快速恢复，时效性高的任务可通过快跑通道一键快跑。并且自动对事故进行记录、分类，便于复盘。

三、京东零售数仓核心能力和场景实践

1、离线：海量数据快速更新实践

1）场景

举一个刷岗的场景，什么是刷岗?就是将发生在该SKU的历史事实数据变更，需要按照最新的SKU岗位等维度信息，进行历史数据回溯，刷岗面临的挑战：

数据量级大；

维度组合爆炸，刷完明细模型还要刷汇总模型；

刷新的频率高，SKU的维度信息每天都会更新。

2）解决方案

我们的解决方案如下：

全量刷新，数据量小的场景适用；

增量刷新，数据量大的场景，只处理变更的字段，关联最新的维表分区，相较于全量，效率高一些；

借助OLAP，基于Clickhouse，在CK中刷岗，事实明细、字典维表按同一字段分片，更新增量变动分片数据，效率高，成本较低；

融合数据刷新服务，融合OLAP+Spark预计算方案，基于Iceberg的增量更新，成本低，效率高。

2、实时：基于Flink的实时数仓架构演进

实时数仓，传统的建模方式与离线类似，按贴源层、明细层、汇总层等分层模式进行建模，但这样会造成数据链路长，降低了数据的实时性，同时实时中没有用到的指标也需要计算，导致资源开销大吞吐增加、时延增加。

因此我们通过解耦逻辑模型构建和物理执行过程，通过逻辑模型搭建实时数仓体系，同时通过智能物化缩短物理执行链路，节约计算存储资源。

3、批流一体：基于Iceberg的实时数据湖架构

1）Lambda架构痛点

Lambda本来是为了在处理大规模数据时，同时发挥流处理和批处理的优势，但是lambda架构也有痛点，如：

需要维护实时、离线两套引擎；

需要维护两套业务逻辑相同的代码；

因为两条不同的数据链路，容易造成数据不一致；

数据更新成本高，需要重跑两个链路；

实时数据受限于消息队列的存储，回溯能力弱。

因为lambda架构有显而易见的缺点，所以我们也在尝试基于flink+iceberg 的实时数据湖批流一体的方案。

我们调研了 Delta、Hudi、Iceberg 三个开源项目，Delta 和 Hudi 跟 Spark 绑定太深，而Iceberg支持更多的分析引擎：不绑定特定的计算引擎，目前支持的计算引擎有 Spark、Flink、Presto 以及 Hive。

Iceberg 正在朝着流批一体的数据湖存储层发展，而我们知道 Flink 已经是一个流批一体的计算引擎，可以说这二者的长远规划完美匹配，未来二者将合力打造流批一体的数据湖架构。相较于数据仓库，数据湖有如下特征：

ACID 语义保证；

支持数据更新，提供了upsert能力，可以极大地缩小数据入库延迟；

高效 Table Schema 的变更；

同时支持流批读写，不会出现脏读等现象。

实时的数据通过 Flink 写入 Iceberg 表中，近实时链路可以通过Flink/Spark 计算增量数据，离线链路也可以通过 Flink/Spark批计算读取某个快照做全局分析，得到对应的分析结果，供不同场景下的用户读取和分析。经过这种改进之后，我们把计算引擎统一成 Flink/Spark，把存储组件统一成了 Iceberg，整个系统的维护开发成本大大降低。

四、未来展望