京东零售数仓的发展过程以及建设框架

参考：地址

1.1 发展过程

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

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

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

1.2 面临问题

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

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

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

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

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

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

1.3 4个维度构建数仓核心能力

1）数仓架构

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

不是简单地根据GDM进行开发，而是由GDM形成的DIM共同形成ADM来完成业务需求

2）数据建模

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

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

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

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

3）数据资产管理

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

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

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

4）数据质量保障

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

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

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

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

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

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

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

• 数据量级大；

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

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

解决方案：

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

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

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

OLAP 的定义与特点（Online Analytical Processing，联机分析处理）

1. 多维数据模型： OLAP 允许用户从多个维度来查看和分析数据。这些维度可以包括时间、地点、产品、客户等。例如，销售数据可以按时间（月、季度、年）、地点（地区、城市）、产品（类别、品牌）等维度进行分析。

2. 快速查询和分析： OLAP 系统通过预计算、索引和其他优化技术，能够实现对大量数据的快速查询和响应，因此适用于需要快速分析和实时反馈的数据应用场景。

3. 切片（Slice）、切块（Dice）、钻取（Drill down）、旋转（Pivot）等操作：

   • 切片（Slice）：在一个维度上选取一个子集的数据，例如查看某一特定月份的销售数据。

   • 切块（Dice）：在多个维度上选取子集的数据，例如查看某个地区在特定月份的销售数据。

   • 钻取（Drill down）：在一个维度的层次结构上逐级下钻查看更详细的数据，例如从年度销售数据钻取到季度再到月度数据。

   • 旋转（Pivot）：重新排列数据的维度，以便从不同的视角查看数据，例如将行列维度互换

Apache Iceberg 是一个开源的高性能表格式库，专为大数据分析优化，能够高效管理大规模数据集的读取和写入操作。Iceberg 旨在解决传统 Hadoop 和 Spark 数据湖（data lakes）在结构化数据管理中的一些核心问题，如数据一致性、事务处理、性能优化等。以下是对 Iceberg 的详细介绍：

主要特点

1. 表格式适配：

   • Iceberg 引入了灵活的表格式，将表视为一组文件和快照，能够高效地管理表的元数据和版本控制。

   • 支持多种文件格式如 Parquet 和 Avro，使得它可以与现有的数据存储格式兼容并提升性能。

2. 事务支持：

   • Iceberg 提供了 ACID 事务支持，让并发操作（比如写操作）不会导致数据不一致。

   • 支持原子提交和回滚操作，确保数据写入的原子性和一致性。

3. Schema 演变：

   • 允许对表的 schema 进行灵活的修改，如增加、删除或者重命名字段，而不会影响现有数据。

   • 支持向后兼容和向前兼容的 schema 演变策略，简化了数据管理。

4. 时间旅行（Time Travel）：

   • 支持基于时间戳或快照 ID 的数据版本回溯（time travel），让用户可以查看表在某一时间点或某一版本的状态。

   • 有效支持数据审计和历史数据分析。

举例说明

假设我们有一个电商平台，需要管理和分析每天产生的海量订单数据。使用 Iceberg，我们可以进行以下操作：

1. 创建和管理表：

   • 定义订单表的结构（schema），包括订单ID、用户ID、商品ID、数量、价格、下单时间等字段。

   • 对订单表进行分区（例如按日期分区），提高查询性能。

2. 写入数据：

   • 实时将每天的订单数据写入 Iceberg 表中，利用 ACID 事务保证数据一致性。

3. 查询和分析数据：

   • 通过 SQL 查询分析每日销售总额、订单数、各分类商品的销售情况等。

   • 基于时间旅行功能，查询历史数据，例如上月某天的订单详细信息。

4. Schema 演变：

   • 若业务需求变化，如需新增一个“优惠券代码”字段，Iceberg 支持在线修改表结构而不会影响已有数据。

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

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

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

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

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

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

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

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

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

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

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

因为lambda架构有显而易见的缺点，所以京东也在尝试基于flink+iceberg 的实时数据湖批流一体的方案。实时的数据通过 Flink 写入 Iceberg 表中，近实时链路可以通过Flink/Spark 计算增量数据，离线链路也可以通过 Flink/Spark批计算读取某个快照做全局 分析，得到对应的分析结果，供不同场景下的用户读取和分析。经过这种改进之后，京东把计算引擎统一成 Flink/Spark，把存储组件统一成 了 Iceberg，整个系统的维护开发成本大大降低。

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

• ACID 事务保证；

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

• 高效 Table Schema 的变更；

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

数据湖和数据仓库之间的主要区别：

1. 数据存储方式

数据湖：

• 原始数据存储：数据湖存储原始格式的数据，不需要预处理或结构化。

• 多样性：支持结构化数据、半结构化数据和非结构化数据（如JSON、XML、文本文件、图像、视频等）。

数据仓库：

• 结构化数据：数据仓库主要存储结构化数据，即在存入之前需要经过处理、转换和清洗的数据。

• 预处理和ETL：数据在进入数据仓库之前，通常需要通过 ETL（Extract, Transform, Load）流程进行预处理。

2. 数据处理和访问

数据湖：

• 灵活性高：可以直接存储和访问不同格式和来源的数据，支持多种数据处理和分析工具。

• Schema-on-Read：数据存储时不需要定义模式，数据读取时才应用结构和格式。

• 实时性：适用于实时数据处理和流分析，因为可以存储和处理大规模的实时数据流。

数据仓库：

• 结构化和优化：数据按照预定义的模式进行存储和优化，支持高效的报表和分析查询。

• Schema-on-Write：数据存入之前必须定义模式，确保一致性和数据质量。

• 批处理：通常用于批量数据分析和历史数据查询，支持一次性的大量数据处理。