第一阶段
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，整个系统的维护开发成本大大降低。
四、未来展望
站在当下看未来，在数据湖的发展过程中，湖仓一体数据架构被推上了风口浪尖。湖仓一体架构的出现结合了传统数据仓库和数据湖的优势，将数据仓库和数据湖进行了打通，兼具灵活存储的同时极大地降低了数据管理、计算和存储成本。
湖仓一体有一些关键特性，如事务支持，Schema支持，端到端的流式支持，计算存储分离等。使得数据的存储变得更加廉价和具有弹性，并且在提升数据质量上有长足的进步。
再往前看一步，云原生数仓已破茧而出，支持批量计算与交互分析的MPP高性能分析型能力，实时数据处理能力和在线交互查询能力，可视化数据建模，规范化指标构建能力，基于这些能力之上的业务价值和商业价值，就如同云原生架构将重构整个IT基础设施一样，云原生数仓必将在数仓领域带来一场巨变。