数据中台详解

Posted 2023-04-01 noworldling

文章目录

• 什么是数据中台
• • 数据中台 VS 数据仓库
  • 数据中台的业务价值与技术价值
• 数据中台建设与架构
• • 数据中台建设方法论
  • 数据中台架构
• 数据汇聚联通：打破企业数据孤岛
• • 数据采集、汇聚的方法和工具
  • 数据交换
• 数据体系建设
• • 数据体系规划
  • 统一数仓层建设——标准化的数据底座
  • • 相关概念
    • 指标设计
    • 维度表设计
    • 事实表设计

什么是数据中台

各种信息系统大多是独立建设的，无法做到信息的互联互通，导致形成了多个数据孤岛。数据中台的作用是融合新老信息，整合各个孤岛上的信息，快速形成数据服务能力，为企业经营决策、精细化运营提供支持。

数据中台和业务中台的区别： 业务中台是抽象业务流程的共性形成通用业务服务能力，数据中泰是抽象数据能力的共性形成通用数据服务能力。

数据中台 VS 数据仓库

数据仓库的主要场景是支持管理决策和业务分析，而数据中台则是将数据服务化之后提供给业务系统，目标是将数据能力渗透到各个业务环节，不限于决策分析类场景。

数据中台的建设包含数据仓库的完整内容，数据中台将企业数据仓库建设的投入价值进行最大化，以加快数据赋能业务的速度，为业务提供速度更快、更多样的数据服务。数据中台也可以将已建好的数据仓库当成数据源，对接已有数据建设成果，避免重复建设。当然也可以基于数据中台提供的能力，通过汇聚、加工、治理各类数据源，构建全新的离线或实时数据仓库。

数据中台的业务价值与技术价值

业务价值：从洞察走向赋能业务创新，形成核心壁垒
1.以客户为中心，用洞察驱动企业稳健行动
数据中台极大提升数据的应用能力，将海量数据转化为高质量数据资产，为企业提供更深层的客户洞察，从而为客户提供更具个性化和智能化的产品和服务。

2.以数据为基础，支持大规模商业模式创新
依托数据和算法，将由海量数据提炼的洞察转化为行动，才能推动大规模的商业创新。将数据变成业务人员可阅读、易理解的内容，这样才能更好地支撑商业模式的创新。

3.盘活全量数据，构筑坚实壁垒以持续领先
数据中台的突出优势在于能充分利用内外部数据，打破数据孤岛的现状，能够降低使用数据服务的门槛，繁荣数据服务的生态，实现数据“越用越多”的价值闭环。

技术价值：能力多、成本低、应用广
针对不同的数据应用场景，需要能够快速应对多数据处理需求
比如：
要保持原来的报表需求，仍需要保持批量离线计算的能力（Hadoop、Oracle RAC）；
针对准实时的指标统计和实时推荐，需要实时流式计算的能力（Storm、Spark Streaming、Flink）；
针对决策类业务如海量人群的圈人需求和ad-hoc需求，需要即席计算能力（Greenplum、Elasticsearch、Impala）；
针对高并发业务场景（如用户画像），需要在线计算能力（mysql、Redis、Oracle）。

数据中台建设与架构

数据中台作为整个企业各个业务所需数据服务的提供方，通过自身的平台能力和业务对数据的不断滋养（业务数据化），会形成一套高效可靠的数据资产体系和数据服务能力（数据资产化和资产服务化）。这样一来，当出现新的市场变化，需要构建新的前台应用时，数据中台可以迅速提供数据服务（服务业务化），从而敏捷地响应企业的创新。

数据中台建设方法论

1种战略行动： 把用数据中台驱动业务发展定位为企业级战略，全局谋划。
2项保障条件： 通过宣导统一组织间的数据认知，通过流程加速组织变革。
3条目标准则： 将数据的可见、可用、可运营3个核心准则始终贯穿于中台建设的全过程，保障建设在正确轨道上。
4套建设内容： 通过技术体系、数据体系、服务体系、运营体系建设保证中台建设的全面性和可持续性。
5个关键步骤： 通过理现状、立架构、建资产、用数据、做运营5个关键行动控制中台建设关键节点的质量。

数据中台架构

1.数据汇聚
数据汇聚是数据中台数据接入的入口。所有数据来自于业务系统、日志、文件、网络等，这些数据分散在不同的网络环境和存储平台中，数据汇聚把各种异构网络、异构数据源的数据方便地采集到数据中台中进行集中存储，为后续的加工建模做准备。
数据汇聚方式一般有数据库同步、埋点、网络爬虫、消息队列等；从汇聚的时效性来分，有离线批量汇聚和实时采集。

2.数据开发
数据开发是一整套数据加工以及加工过程管控的工具，有经验的数据开发、算法建模人员利用数据加工模块提供的功能，可以快速把数据加工成对业务有价值的形式，提供给业务使用。

3.数据体系
有了数据汇聚、数据开发模块，中台已经具备传统数据仓库（后面简称：数仓）平台的基本能力。大数据时代，必须考虑数据的一致性和可复用性，垂直的、烟囱式的数据和数据服务的建设方式注定不能长久存在。建议数据按照贴源数据、统一数仓、标签数据、应用数据的标准统一建设。

4.数据资产管理
数据资产管理包括对数据资产目录、元数据、数据质量、数据血缘、数据生命周期等进行管理和展示，以一种更直观的方式展现企业的数据资产，提升企业的数据意识。

5.数据服务体系
数据服务体系就是把数据变为一种服务能力，通过数据服务让数据参与到业务，激活整个数据中台，数据服务体系是数据中台存在的价值所在。

6.运营体系和安全管理
通过前面的数据汇聚、数据开发、数据体系、数据资产管理、数据服务体系，已经完成了整个数据中台的搭建和建设，也已经在业务中发挥一定的价值。运营体系和安全管理是数据中台得以健康、持续运转的基础，如果没有它们，数据中台很可能像个一般项目一样，会在搭建起平台、建设部分数据、尝试一两个应用场景之后而止步，无法正常地持续运营，不能持续发挥数据的应用价值。这也就完全达不到建设数据中台的目标。

数据汇聚联通：打破企业数据孤岛

要构建企业级的数据中台，第一步就是要让企业内部各个业务系统的数据实现互联互通，从物理上打破数据孤岛，这主要通过数据汇聚和交换的能力来实现。

数据采集、汇聚的方法和工具

从空间维度来看，用户行为可以分为线上行为和线下行为两类。

1.线上行为采集
线上行为的主要载体可以分为传统互联网和移动互联网两种。在技术上，数据采集主要有客户端SDK埋点和服务端SDK埋点等方式。其中客户端SDK埋点主要是通过在终端设备内嵌入埋点功能模块，通过模块提供的能力采集客户端的用户行为，并上传回行为采集服务端。
（1）客户端埋点
常见的客户端埋点方式有三种：全埋点、可视化埋点和代码埋点。
全埋点：将终端设备上用户的所有操作和内容都记录并保存下来，只需要对内嵌SDK做一些初始配置就可以实现收集全部行为的目的。这也经常被称为无痕埋点、无埋点等。
可视化埋点：将终端设备上用户的一部分操作，通过服务端配置的方式有选择性地记录并保存。
代码埋点：根据需求来定制每次的收集内容，需要对相应的终端模块进行升级。

（2）服务端埋点
除了前面介绍的客户端埋点，常见的线上埋点还有服务端埋点，通过在系统服务器端部署相应的数据采集模块，将这部分数据作为行为数据进行处理和分析。服务端埋点常见的形态有HTTP服务器中的access_log，即所有的Web服务的日志数据。

2.线下行为采集
线下行为数据主要通过一些硬件来采集，如常见的Wi-Fi探针、摄像头、传感器等。常见的主要有Wi-Fi信号采集、信令数据采集、图像视频采集以及传感器探测等。

3.互联网数据采集
网络爬虫又称为网页蜘蛛，是一种按照既定规则自动抓取互联网信息的程序或者脚本，常用来做网站的自动化测试和行为模拟。网络爬虫有多种实现方式，目前有较多的开源框架可以使用，如Apache Nutch 2、WebMagic、Scrapy、phpCrawl等。

4.内部数据汇聚
数据汇聚不同于数据采集，数据采集有一定的数据生产属性，将终端的用户行为信息通过特定的方法记录后，通过中间系统的流转写入目标存储中。
从数据组织形式来分，数据主要分成三类：
结构化数据： 规则、完整，能够通过二维逻辑来表现的数据，严格遵循数据格式与长度规范，常见的有数据库表、Excel等二维表。
半结构化数据： 数据规则、完整，同样严格遵循数据格式与长度规范，但无法通过二维关系来表现，常见如JSON、XML等形式表达的复杂结构。
非结构化数据： 数据结构不规则或不完整，不方便用二维逻辑表来表现，需要经过复杂的逻辑处理才能提取其中的信息内容，如办公文档、图片、图像和音视频等。

从时效性和应用场景来分，数据汇聚可以分成离线和实时两类：
离线： 主要用于大批量数据的周期性迁移，对时效性要求不高，一般采用分布式批量数据同步的方式，通过连接读取数据，读取数据过程中可以有全量、增量的方式，经过统一处理后写入到目标存储。
实时： 主要面向低时延的数据应用场景，一般通过增量日志或通知消息的方式实现，如通过读取数据库的操作日志（RedoLog、BinLog）来实现相应的实时处理，业界常见的Canal、MaxWell、StreamSets、NiFi等框架和组件都有较多的实际应用。

在数据建设过程中有ETL（Extract-Transform-Load，抽取–转换–存储）的操作，即在数据抽取过程中进行数据的加工转换，然后加载至存储中。
但在大规模数据场景下，一般不建议采用ETL的方式，建议采用ELT（Extract-Load-Transform，抽取–存储–转换）的模式，即将数据抽取后直接加载到存储中，再通过大数据和人工智能相关技术对数据进行清洗和处理。
如果采用ETL的模式在传输过程中进行复杂的清洗，会因为数据体量过大和清洗逻辑的复杂性导致数据传输的效率大大降低。另一方面，ETL模式在清洗过程中只提取有价值的信息进行存储，而是否有价值是基于当前对数据的认知来判断的，由于数据价值会随着我们对数据的认知以及数据智能相关技术的发展而不断被挖掘，因此ETL模式很容易出现一些有价值的数据被清洗掉，导致当某一天需要用这些数据时，又需要重新处理，甚至数据丢失无法找回。

在数据能力建设过程中，很多企业结合自身的场景和最佳实践也开源了一些优秀的汇聚工具，如Sqoop、DataX、Canal等，适用场景不同，也各有优缺点。
(1).Canal
Canal Server模拟MySQL Slave的交互协议，伪装自己为MySQL的Slave向Master发送dump协议，Master收到请求后开始推送binary log，Canal解析byte流产出解析后的增量数据。主要优点是流程架构非常清晰，部署和配置等相对简单，同时可以额外做一些配置管理、开发改造的工作。 Canal的 主要缺点是Server中的Instance和Client之间是一对一的消费，不太适用于多消费和数据分发的场景。

(2).Sqoop
Sqoop是目前市面上相对通用的一种解决方案，是在结构化数据和HDFS之间进行批量数据迁移的工具。整体框架以Hadoop为核心，底层使用MapReduce程序实现，MapReduce天生的特性保证了并行化和高容错率，任务运行在Hadoop集群上，减少了服务器资源的使用情况。其主要优势是，在特定场景下，数据交换过程会有很大的性能提升。主要缺点是，处理过程定制程度较高，目前主要通过在命令行中配置参数来调整数据同步操作行为，在用户的一些自定义逻辑和数据同步链路监控方面比较薄弱。除此之外，任务运行完全依赖于MapReduce，功能扩展性方面受到比较明显的约束和限制。

(3).DataX
DataX是阿里巴巴开源的一套插件式离线数据交换工具，以实现各种异构数据源之间的高效数据交换为目标而设计，提供数据交换作业全链路的流量监控，将作业本身的状态、数据流量、数据速度、执行进度等信息进行展示，提供脏数据探测功能，支持传输过程中对传输报错（如类型转换错误）进行策略化处理。由于它是基于进程内读写直连的方式，高并发数据交换场景下对机器内存要求比较高。除此之外，DataX不支持非结构化数据的同步，目前支持结构化数据源、半结构化数据源、非结构化数据源，但是非结构化数据源中需要存储的是一张逻辑意义上的二维表，例如CSV格式的文本信息，本质上还是结构化数据。

数据交换

从数据类型来看，有结构化数据和非结构化数据；
从实效性来看，有实时数据交换和离线数据交换。

数据交换中心的首要目的是屏蔽底层工具的复杂性，以可视化配置的方式提供给企业用户；其次需要考虑，为了解决数据孤岛，需要满足异构存储、异构数据类型的交换需求；同时，还要考虑不同时效要求下的数据互通。

数据体系建设

数据体系规划

中台数据体系应具备以下特征：
覆盖全域数据： 数据集中建设，覆盖所有业务过程数据，业务在中台数据体系中总能找到需要的数据。
结构层次清晰： 纵向的数据分层，横向主题域、业务过程划分，让整个层次结构清晰易理解。
数据准确一致： 定义一致性指标，统一命名、统一业务含义、统一计算口径，并有专业团队负责建模，保证数据的准确一致。
性能提升： 统一的规划设计，选用合理的数据模型，清晰地定义并统一规范，并且考虑使用场景，使整体性能更好。
降低成本： 数据体系的建设使得数据能被业务共享，这避免了大量烟囱式的重复建设，节约了计算、存储和人力成本。
方便易用： 易用的总体原则是越往后越能方便地直接使用数据，把一些复杂的处理尽可能前置，必要时做适当的冗余处理。

统一数仓层建设——标准化的数据底座

建模方法有范式建模、维度建模、实体建模等。维度建模更适合大数据时代数据量巨大的特点。
维度建模是实现统一数仓层建设目标的一种推荐建模方式，它用事实表、维度表来组织数据。模型简单易理解：仅有维度、事实两种类型数据。 维度建模具备以下特点：

性能好： 维度建模使用的是可预测的标准框架，允许数据库系统和最终用户通过查询工具在数据方面生成强大的假设条件，这些数据主要在表现和性能方面起作用。
可扩展性好： 具有非常好的可扩展性，可以在不改变模型粒度的情况下，很方便地增加新的分析维度和事实，不需要重载数据，也不需要为了适应新的改变而重新编码。良好的可扩展性意味着以前的所有应用都可以继续运行，并不会产生不同的结果。
数据冗余： 由于在构建事实表星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些预处理过程中，往往会导致大量的数据冗余。

相关概念

统一数仓层建设过程以维度建模为理论基础，构建总线矩阵，划分业务板块，定义数据域、业务过程、维度、原子指标、修饰类型、修饰词、时间周期、派生指标，进而确定维度表、事实表的模型设计。统一数仓层建设过程如图所示：

**原子指标：**原子指标是针对某一业务事件行为的度量，是一种不可拆分的指标，具有明确业务含义，比如支付金额。原子指标有确定的字段名称、数据类型、算法说明、所属数据域和业务过程。
派生指标： 派生指标可以理解为对原子指标业务统计范围的圈定，比如最近1天北京买家支付金额（“最近1天”是时间周期，“北京”是修饰词，修饰词“买家”是维度）。派生指标=1个原子指标+多个修饰词+时间修饰词。

维度表： 维度是观察事物的角度，提供某一业务过程事件所涉及的用于过滤及分类事实的描述性属性，用于描述与“谁、什么、哪里、何时、为什么、如何”（5W1H）有关的事件。**比如“早上小王在小卖部花费5元钱购买了一个面包”，以购买为业务过程进行分析，可从这段信息中提取三个维度，即时间维度（早上）、地点维度（小卖部）和商品维度（面包）。**维度表是统一设计的，在整个数据仓库中共享，所有数据域、业务过程都需要用到维度，都可以在公共维度表中获取相关维度属性。

事实表： 事实是观察事物得到的事实数据，事实涉及来自业务过程事件的度量，基本都是以数量值表示，比如一次购买行为就可以理解为是一个事实，5元就是事实信息。 事实表不跨数据域，根据需要，一个事实表可能对应同数据域下一个或者多个业务过程。事实表又分为明细事实表和汇总事实表。明细事实表记录事务层面的事实，保存的是原子数据，数据的粒度通常是每个事务一条记录，明细事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。汇总事实表是把明细事实聚合形成的事实表，包括以具有规律性的、可预见的时间间隔来记录事实的周期快照事实表和以不确定的周期来记录事实的累计快照事实表。

指标设计

指标就是在企业业务运转过程中产生的度量事实，一致性指标设计是为了在企业内外部使指标的命名、计算方法、业务理解达到一致，避免不同部门同一个指标的数据对不上或者对同一个指标的数据理解不一致。
一致性指标的定义为，描述原子指标、修饰词、时间周期和派生指标的含义、类型、命名、算法，被用于模型设计，是建模的基础。

维度表设计

维度表包含了事实表所记录的业务过程度量的上下文和环境，它们除了记录5W等信息外，通常还包含了很多描述属性字段。每个维度表都包含单一的主键列。
1）选择维度： 维度作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。维度一般用于查询约束条件、分组、排序的关键属性。
2）确定主维表： 主维表一般直接从业务系统同步而来，是分析事实时所需环境描述的最基础、最频繁的维度属性集合。比如用户维表从业务系统的用户基本信息表中产出。
3）梳理关联维表： 根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。如商品与类目、SPU、卖家、店铺等维度存在关联关系。
4）定义维度属性： 从主维表或关联维表中选择维度属性或生成新的维度属性，并维护和描述维度属性的层次及关联关系。如商品维表，商品属于类目，类目属于行业。

事实表设计

事实表是统一数仓层建设的主要产出物，统一数仓层绝大部分表都是事实表。一般来说事实表由两部分组成：一部分是由主键和外键组成的键值部分，另一部分是用来描述业务过程的事实度量。

在Kimball的维度建模理论中主要定义了事务事实表、周期快照事实表、累积快照事实表三种类型的事实表。
事务事实表： 事务事实表描述业务过程事务层面的事实，每条记录代表一个事务事件，保留事务事件活动的原始内容，其更新方式为增量更新。事务事实表相对其他事实表保存的数据粒度更细，可以通过事务事实表对事务行为进行详细分析。
周期快照事实表： 周期快照事实表以具有规律性、可预见的时间间隔产生快照来记录事实，每行代表某个时间周期的一条记录，记录的事实是时间周期内的聚集事实值或状态度量，更新方式为增量更新。周期快照事实表一般是建立在事务事实表之上的聚集，维度比事务事实表少，粒度比事务事实表粗，但是一般事实会比事务事实表多。
累计快照事实表： 累积快照事实表覆盖一个事务从开始到结束之间所有的关键事件，覆盖事务的整个生命周期，通常具有多个日期字段来记录关键事件时间点。 周期快速事实表涉及的多个事件中任意一个的产生都要做记录，由于周期快照事实表涉及的多个事件的首次加载和后续更新时间是不确定的，因此在首次加载后允许对记录进行更新，一般采用全量刷新的方式更新。

万字详解数据仓库数据湖数据中台和湖仓一体

本文目录：

一、前言
二、概念解析

1. 数据仓库
2. 数据湖
3. 数据中台

三、具体区别

1. 数据仓库 VS 数据湖
2. 数据仓库 VS 数据中台
3. 总结

四、湖仓一体

1. 目前数据存储方案
2. Data Lakehouse（湖仓一体）

一、前言

数字化转型浪潮卷起各种新老概念满天飞，数据湖、数据仓库、数据中台轮番在朋友圈刷屏，有人说“数据中台算个啥，数据湖才是趋势”，有人说“再见了数据湖、数据仓库，数据中台已成气候”……
.

50000字详解数仓建设保姆级教程，涵盖离线和实时
.

企业还没推开数字化大门，先被各种概念绊了一脚。那么它们 3 者究竟有啥区别？别急，先跟大家分享两个有趣的比喻。

1、图书馆VS地摊

如果把数据仓库比喻成“图书馆”，那么数据湖就是“地摊”。去图书馆借书（数据），书籍质量有保障，但你得等，等什么？等管理员先查到这本书属于哪个类目、在哪个架子上，你才能精准拿到自己想要的书；而地摊上没有人会给你把关，什么书都有，你自己翻找、随用随取，流程上比图书馆便捷多了，但大家找书的过程是没有经验可复用的，偶尔多拿少拿咱们可能也不知道。

2、升级版银行

假定数据仓库、数据湖、数据中台都是银行，可以提供现金、黄金等多种服务。过去大家进银行前都得先问门卫，里面每个门牌上的数字对应哪个服务呢？是现金还是黄金呢？然后推开对应的门把东西取出来。而有了“数据中台”这个银行，大家一进来就能看到标着“现金”、“黄金”汉字的窗口，一目了然，你只需要走到窗口前，就有专人帮你办理。

以上两个例子不一定全面，但基本能解释三者的优劣势。数据仓库具备规范性，但取数用数流程长；数据湖取数用数更实时、存储量大，但数据质量难以保障；数据中台能精准快速地响应业务需求，离业务侧最近。

为了更清晰地区别三者，接下来咱们再来看看它们各自的定义以及应用区别。

二、概念解析

1. 数据仓库

数据仓库诞生于 1990 年，绝对算得上是“老前辈”了，它是一个相对具体的功能概念。目前对数据仓库的主流定义是位于多个数据库上的大容量存储库，它的作用在于存储大量的结构化数据，并能进行频繁和可重复的分析，帮助企业构建商业智能（BI）。

具体定义：

数据仓库(Data Warehouse)是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化的（Time Variant）数据集合，用于支持管理决策和信息的全局共享。其主要功能是将组织透过资讯系统之联机事务处理(OLTP)经年累月所累积的大量资料，透过数据仓库理论所特有的资料储存架构，分析出有价值的资讯。

• 所谓主题：是指用户使用数据仓库进行决策时所关心的重点方面，如：收入、客户、销售渠道等；所谓面向主题，是指数据仓库内的信息是按主题进行组织的，而不是像业务支撑系统那样是按照业务功能进行组织的。

• 所谓集成：是指数据仓库中的信息不是从各个业务系统中简单抽取出来的，而是经过一系列加工、整理和汇总的过程，因此数据仓库中的信息是关于整个企业的一致的全局信息。

• 所谓随时间变化：是指数据仓库内的信息并不只是反映企业当前的状态，而是记录了从过去某一时点到当前各个阶段的信息。通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。

数据仓库的作用：

数据仓库系统的作用能实现跨业务条线、跨系统的数据整合，为管理分析和业务决策提供统一的数据支持。数据仓库能够从根本上帮助你把公司的运营数据转化成为高价值的可以获取的信息（或知识），并且在恰当的时候通过恰当的方式把恰当的信息传递给恰当的人。

• 是面向企业中、高级管理进行业务分析和绩效考核的数据整合、分析和展现的工具；

• 是主要用于历史性、综合性和深层次数据分析；

• 数据来源是ERP（例:SAP）系统或其他业务系统；

• 能够提供灵活、直观、简洁和易于操作的多维查询分析;

• 不是日常交易操作系统，不能直接产生交易数据；

实时数仓

实时数仓和离线数仓非常的像，诞生的背景主要是近几年企业对于数据服务的实时性需求日益增多。里面的数据模型也会像中台一样分好几层：ODS 、CDM、ADS。但整体对于实时性要求极高，因此一般存储会考虑采用Kafka这种log base的MQ，而计算引擎会采用Flink这种流计算引擎。

2. 数据湖

数据湖是一种不断演进中、可扩展的大数据存储、处理、分析的基础设施，它就像一个大型仓库存储企业多样化原始数据以数据为导向，实现任意来源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式处理与全生命周期管理。拥有强大的信息处理能力和处理几乎无限的并发任务或工作的能力。

数据湖从企业的多个数据源获取原始数据，数据可能是任意类型的信息，从结构化数据到完全非结构化数据，并通过与各类外部异构数据源的交互集成，支持各类企业级应用。结合先进的数据科学与机器学习技术，能帮助企业构建更多优化后的运营模型，也能为企业提供其他能力，如预测分析、推荐模型等，这些模型能刺激企业能力的后续增长。

进入互联网时代，有两个最重要的变化。

一个是数据规模前所未有，一个成功的互联网产品日活可以过亿，就像你熟知的头条、抖音、快手、网易云音乐，每天产生几千亿的用户行为。传统数据仓库难于扩展，根本无法承载如此规模的海量数据。

另一个是数据类型变得异构化，互联网时代的数据除了来自业务数据库的结构化数据，还有来自 App、Web 的前端埋点数据，或者业务服务器的后端埋点日志，这些数据一般都是半结构化，甚至无结构的。传统数据仓库对数据模型有严格的要求，在数据导入到数据仓库前，数据模型就必须事先定义好，数据必须按照模型设计存储。

所以，数据规模和数据类型的限制，导致传统数据仓库无法支撑互联网时代的商业智能。

05年的时候，Hadoop诞生了。 Hadoop 相比传统数据仓库主要有两个优势：

• 完全分布式，易于扩展，可以使用价格低廉的机器堆出一个计算、存储能力很强的集群，满足海量数据的处理要求；

• 弱化数据格式，数据被集成到 Hadoop 之后，可以不保留任何数据格式，数据模型与数据存储分离，数据（包含了原始数据）在被使用的时候，可以按照不同的模型读取，满足异构数据灵活分析的需求。而数仓更加关注可以作为事实依据的数据。

随着Hadoop与对象存储的成熟，数据湖的概念在10年被提出：数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统（这意味着数据湖的底层不应该与任何存储耦合）。

对应的来说，如果数据湖没有被治理好（缺乏元数据、定义数据源、制定数据访问策略和安全策略，并移动数据、编制数据目录），则会变成数据沼泽。

而从产品形态上来说，数仓往往是独立标准化的产品。而数据湖更像是一种架构指导——需要配合一系列的周边工具，来实现业务需要的数据湖。

3. 数据中台

大规模数据的应用，也逐渐暴露出现一些问题。

业务发展前期，为了快速实现业务的需求，烟囱式的开发导致企业不同业务线，甚至相同业务线的不同应用之间，数据都是割裂的。两个数据应用的相同指标，展示的结果不一致，导致运营对数据的信任度下降。如果你是运营，当你想看一下商品的销售额，发现两个报表上，都叫销售额的指标出现了两个值，你的感受如何? 你第一反应肯定是数据算错了，你不敢继续使用这个数据了。

数据割裂的另外一个问题，就是大量的重复计算、开发，导致的研发效率的浪费，计算、存储资源的浪费，大数据的应用成本越来越高。

• 如果你是运营，当你想要一个数据的时候，开发告诉你至少需要一周，你肯定想是不是太慢了，能不能再快一点儿？

• 如果你是数据开发，当面对大量的需求的时候，你肯定是在抱怨，需求太多，人太少，活干不完。

• 如果你是一个企业的老板，当你看到每个月的账单成指数级增长的时候，你肯定觉得这也太贵了，能不能再省一点，要不吃不消了。

这些问题的根源在于，数据无法共享。2016 年，阿里巴巴率先提出了“数据中台”的口号。数据中台的核心，是避免数据的重复计算，通过数据服务化，提高数据的共享能力，赋能数据应用。之前，数据是要啥没啥，中间数据难于共享，无法积累。现在建设数据中台之后，要啥有啥，数据应用的研发速度不再受限于数据开发的速度，一夜之间，我们就可以根据场景，孵化出很多数据应用，这些应用让数据产生价值。

数据中台样板

在建设中台的过程中，一般强调这样几个重点：

• 效率、质量和成本是决定数据能否支撑好业务的关键，构建数据中台的目标就是要实现高效率、高质量、低成本。

• 数据只加工一次是建设数据中台的核心，本质上是要实现公共计算逻辑的下沉和复用。

• 如果你的企业拥有 3 个以上的数据应用场景，数据产品还在不断研发和更新，你必须要认真考虑建设数据中台。

那么接下来就看一下阿里巴巴对于数据中台的实践。

正如上述提到的数据只加工一次是建设数据中台的核心，本质上是要实现公共计算逻辑的下沉和复用。阿里数据中台提到了各种one思想，如：

• OneData：公共数据只保存一份
• OneService：通过一个服务接口进行暴露

三、具体区别

1. 数据仓库 VS 数据湖

相较而言，数据湖是较新的技术，拥有不断演变的架构。数据湖存储任何形式（包括结构化和非结构化）和任何格式（包括文本、音频、视频和图像）的原始数据。根据定义，数据湖不会接受数据治理，但专家们一致认为良好的数据管理对预防数据湖转变为数据沼泽不可或缺。数据湖在数据读取期间创建模式。与数据仓库相比，数据湖缺乏结构性，而且更灵活，并且提供了更高的敏捷性。值得一提的是，数据湖非常适合使用机器学习和深度学习来执行各种任务，比如数据挖掘和数据分析，以及提取非结构化数据等。

2. 数据仓库 VS 数据中台

数据仓库和传统的数据平台，其出发点为一个支撑性的技术系统，即一定要先考虑我具有什么数据，然后我才能干什么，因此特别强调数据质量和元数据管理；而数据中台的第一出发点不是数据而是业务，一开始不用看你系统里面有什么数据，而是去解决你的业务问题需要什么样的数据服务。

在具体的技术处理环节，二者也有明显不同，数据的预处理流程正在从传统的ETL结构向ELT结构转变。传统的数据仓库集成处理架构是ETL结构，这是构建数据仓库的重要一环，即用户从数据源抽取出所需的数据，经过数据清洗，将数据加载到数据仓库中去。而大数据背景下的架构体系是ELT结构，其根据上层的应用需求，随时从数据中台中抽取想要的原始数据进行建模分析。

3. 总结

根据以上数据仓库、数据湖和数据中台的概念论述和对比，我们进行如下总结：

• 数据中台、数据仓库和数据湖没有直接的关系；

• 数据中台、数据仓库和数据湖在某个维度上为业务产生价值的形式有不同的侧重；

• 数据中台是企业级的逻辑概念，体现企业数据向业务价值转化的能力，为业务提供服务的主要方式是数据 API；

• 数据仓库是一个相对具体的功能概念，是存储和管理一个或多个主题数据的集合，为业务提供服务的方式主要是分析报表；

• 数据中台距离业务更近，能够更快速的响应业务和应用开发需求，从而为业务提供速度更快的服务；

• 数据仓库是为了支持管理决策分析，而数据中台则是将数据服务化之后提供给业务系统，不仅限于分析型场景，也适用于交易型场景；

• 数据中台可以建立在数据仓库和数据平台之上，是加速企业从数据到业务价值的过程的中间层。

四、湖仓一体

有人说“湖仓一体成为下一站灯塔，数仓、数据湖架构即将退出群聊”。

2020年，大数据DataBricks公司首次提出了湖仓一体（Data Lakehouse）概念，希望将数据湖和数据仓库技术合而为一，此概念一出各路云厂商纷纷跟进。

Data Lakehouse（湖仓一体）是新出现的一种数据架构，它同时吸收了数据仓库和数据湖的优势，数据分析师和数据科学家可以在同一个数据存储中对数据进行操作，同时它也能为公司进行数据治理带来更多的便利性。

1. 目前数据存储的方案

一直以来，我们都在使用两种数据存储方式来架构数据：

• 数据仓库：主要存储的是以关系型数据库组织起来的结构化数据。数据通过转换、整合以及清理，并导入到目标表中。在数仓中，数据存储的结构与其定义的schema是强匹配的。

• 数据湖：存储任何类型的数据，包括像图片、文档这样的非结构化数据。数据湖通常更大，其存储成本也更为廉价。存储其中的数据不需要满足特定的schema，数据湖也不会尝试去将特定的schema施行其上。相反的是，数据的拥有者通常会在读取数据的时候解析schema（schema-on-read），当处理相应的数据时，将转换施加其上。

现在许多的公司往往同时会搭建数仓、数据湖这两种存储架构，一个大的数仓和多个小的数据湖。这样，数据在这两种存储中就会有一定的冗余。

2. Data Lakehouse（湖仓一体）

Data Lakehouse的出现试图去融合数仓和数据湖这两者之间的差异，通过将数仓构建在数据湖上，使得存储变得更为廉价和弹性，同时lakehouse能够有效地提升数据质量，减小数据冗余。在lakehouse的构建中，ETL起了非常重要的作用，它能够将未经规整的数据湖层数据转换成数仓层结构化的数据。

下面详细解释下：

湖仓一体（Data Lakehouse）：

依据DataBricks公司对Lakehouse 的定义：一种结合了数据湖和数据仓库优势的新范式，解决了数据湖的局限性。Lakehouse 使用新的系统设计：直接在用于数据湖的低成本存储上实现与数据仓库中类似的数据结构和数据管理功能。

解释拓展：

湖仓一体，简单理解就是把面向企业的数据仓库技术与数据湖存储技术相结合，为企业提供一个统一的、可共享的数据底座。

避免传统的数据湖、数据仓库之间的数据移动，将原始数据、加工清洗数据、模型化数据，共同存储于一体化的“湖仓”中，既能面向业务实现高并发、精准化、高性能的历史数据、实时数据的查询服务，又能承载分析报表、批处理、数据挖掘等分析型业务。

湖仓一体方案的出现，帮助企业构建起全新的、融合的数据平台。通过对机器学习和AI算法的支持，实现数据湖+数据仓库的闭环，提升业务的效率。数据湖和数据仓库的能力充分结合，形成互补，同时对接上层多样化的计算生态。

Lakehouse有如下关键特性：

• 事物支持：Lakehouse 在企业级应用中，许多数据管道通常会同时读取和写入数据。通常多方同时使用 SQL 读取或写入数据，Lakehouse 保证支持ACID事务的一致性。

• 模式实施和治理：Lakehouse 应该有一种支持模式实施和演变的方法，支持 DW 模式规范，例如 star /snowflake-schemas。该系统应该能够推理数据完整性，并且应该具有健壮的治理和审核机制。

• BI支持：Lakehouse 可以直接在源数据上使用BI工具。这样可以减少陈旧度和等待时间，提高新近度，并且降低必须在数据湖和仓库中操作两个数据副本的成本。

• 存储与计算分离：事实上，这意味着存储和计算使用单独的群集，因此这些系统能够扩展到更多并发用户和更大数据量。一些现代数据仓库也具有这种属性。

• 兼容性：Lakehouse 使用的存储格式是开放式和标准化的，例如 Parquet，并且它提供了多种 API，包括机器学习和 Python/R 库，因此各种工具和引擎都可以直接有效地访问数据。

• 支持从非结构化数据到结构化数据的多种数据类型：Lakehouse 可用于存储，优化，分析和访问许多新数据应用程序所需的数据类型，包括图像，视频，音频，半结构化数据和文本。

• 支持各种工作场景：包括数据科学，机器学习和 SQL 分析。这些可能依赖于多种工具来支持的工作场景，它们都依赖于相同的数据存储库。

• 端到端流式任务：实时报告是许多企业的日常需要。对流处理的支持消除了对专门服务于实时数据应用程序的单独系统的需求。

上面这张图是DataBricks给出的架构演化参考图。

我们可以看到，传统的数仓目标非常明确，适用于将各业务数据源合并后，进行商务BI分析和报表。随着企业需要处理的数据类型越来越多，包括客户行为，IoT，图片，视频等， 数据规模也成指数增加。

数据湖技术被引入，并用于承担通用数据存储和处理平台的作用，数据湖由于其分布式存储和计算能力的特点，也可以更好的支持机器学习计算， 在数据湖时代，我们通常可以看到DataLake和Data Warehouse还是会同时存在的。

随着大数据时代的到来，是不是有可能让大数据技术可以取代传统数仓，形成一个统一的数据处理架构，湖仓一体的概念被提出，并由DataBricks和云厂商们在进行快速的推演和实践。

参考

1. 最强最全面的数仓建设规范指南
2. 美团数据平台及数仓建设实践，超十万字总结
3. 数仓建设保姆级教程