什么是数据仓库

所有的数据工作都围绕着数据展开，存储规范、含义明确、可高效使用的数据库是所有数据应用的基础。企业想要让数据发挥价值，第一个障碍往往就是无数可用：不知道是否有相关数据，不知道相关数据由谁管理、存储于什么介质中，不知道数据的具体含义，不能快速安全地提取数据。此问题由来已久却历久弥新，一个久经考验的解决方案就是企业级数据仓库。不夸张地说，不管是哪一种数据职业，从业人员如果对数据仓库没有基础的了解，没有使用过数据仓库里的数据，他们的数据应用大概率仍然是“原始”的、孤立的、一次性的、前信息时代的。当然采用了数据仓库并不保证数据应用的最终价值，“原始”的、前信息时代的数据应用仍然能够具备明显的价值。

任性的友情提示：
数据仓库产业的历史远长于笔者的年龄，笔者也仅是因工作原因略有涉猎。所以，本篇旨在于提纲挈领，主要内容都摘录自各处的学习材料，尝试给出一个 MVP 级别的小型方案，并提供相关的文献索引。数据仓库，作为一种实践性质、工程性质大于技术性质的 IT 技术，亲自下场 get hands dirty 远比单纯钻研理论知识学得更有效。忘记是哪一位前辈说的了：数据仓库的一个特点就是重实践，方法论本身不足以完全撑起整个领域，需要在实际业务中，根据实际需求，设计数据模型，不断调整衍化这个模型。适当参考同行业、其他行业的案例。但还是得靠自己去思考应用。

数据仓库的概念

Data Warehouse 可能存在多种理解，本篇采用最广为使用的概念，数据仓库之父比尔·恩门（Bill Inmon）在1991年出版的《Building the Data Warehouse》中如此定义：数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，它用于支持管理决策。

面向主题的（Subject Oriented）

  • 业务数据库中的数据都是面向事务处理进行组织的，但数据仓库是面向主题存放，目的是为了更好的组织数据，方便数据查询分析。常见的主题如：电商的订单、用户、流量等。

  • 主题是基于业务理解对业务进行的很自然的划分。企业所有的数据最终都会被归入到某一个主题中，从而实现清晰的管理。但对主题的划分很难做到像生物物种那样精确。网站流量的明细数据同时包含内容和用户，它既可以归入内容主题，又可以归入用户主题，当然最常见的做法还是单独作为一个主题。而当流量明细数据汇总到用户-内容层级时，主题问题又一次出现。所以主题的划分，更多的还是一个数据管理的问题，这正说明了数据仓库的建设不是一蹴而就的建设性工程，而是一边建设一边维护的维护性工程。

    集成的（Integrate）

  • 数据仓库最重要的特性。数据仓库的数据抽取自不同的数据源，故需要对数据进行清洗转换（编码统一、属性度量统一、描述统一、关键字统一），得到原始表与数据仓库表的映射结果。

  • 数据仓库项目最早凸显的价值就在于数据的集成。企业采购的各种业务系统，数据往往只存在于系统内部，简单地讲数据集成到一处，不同业务领域的数据可以交叉使用，新的分析和应用才成为可能。最差的情况下，数据仓库相对于业务系统更易于查询数据的优点，也让单一业务系统的数据分析和应用变得更加高效了。

    相对稳定的（Non-Volatile）

  • 数据仓库的数据通常是批量的方式更新，相对于即时变动的业务数据库，数据仓库中只保存着更新时的数据。比如会员信息表，每日每次新增会员，业务数据库都会新增一条记录，数据信息随时发生改变，而数据仓库中的会员信息，如果是按天存储的，每天只有一种状态。这样，在分析时，不会受当前数据变动的影响，导致每次查询结果的差异。

    • 业务数据库和数据仓库的差异，见后文的“OLTP & OLAP”

      反映历史变化的（Time Variant）

  • 数据仓库显著特点。业务系统的数据都是随着具体流程变化而实时更新，有的业务数据仅仅保留当前状态，数据进入数据仓库后，都会加上时间关键字加以标记，存储历史状态。当我们需要对数据进行历史变化分析时，这一特性价值就凸显出来。

数据仓库技术概要

OLTP & OLAP

  • 因数据库的服务目标和技术特性不同，曾经被分为 OLTP（On-Line Transaction Processing，联机事务处理过程）和 OLAP（On-Line analytical processing，联机分析处理）两种。OLTP 型数据库用于支持日常业务，关心的是业务数据的读写性能，操作的数据往往具有短时间内多查询且每次数据量小的特点，比如支持电子商务的海量订单。OLAP 型数据库用于支持数据分析，关心的是如何快速高性能地处理大量历史数据，操作的数据往往查询次数较少，但每次查询数据量很大，比如统计历史几年的电商订单数据。
  • OLAP 和 OLTP 的详细区别如下图：

数据仓库在数据架构的中心地位

  • 数据仓库和上游的源数据、下游的数据应用组成企业数据应用的典型架构：
    • 源数据来自于各类业务系统
    • 数据仓库作为企业所有数据的集散地、加工厂、存储仓库、管理工具而存在。
    • 数据仓库通过各类 ETL 工具从源系统抽取（Extract）数据，按实际需要处理（Transfrom）数据，再将处理好的数据加载（Load）回到数据仓库中。
      • 在早期，ETL 工具可能独立于数据仓库存在，且需要单独购买和部署，比如 kettle、talend、informatica。在 2020 年前后，类 sql 的数据处理工具可能已经在数据仓库中提供，也得到广泛的应用，比如 Hive。
    • 数据仓库还需通过数据接口等方式，为 BI、数据查询等各类数据应用提供数据查询、数据处理的能力。
    • 元数据管理的方式则取决于企业信息团队的选择，是在各个数据系统内部分开管理，还是通过一个统一的元数据管理平台管理。
  • 在这种架构下，数据仓库在企业数据管理和应用中具备了某种中心的地位。业务系统可能随着业务发展而增减变化，数据应用也可能被更新替换。数据仓库反而一直存储着宝贵的数据资产，伺机发挥价值。
  • 这种中心地位，意味着数据仓库或者承担同类职责的数据系统是企业数据建设绕不开的一环，也意味着它极有可能成为某些企业的负担。

image.png

数据仓库的选型

（不够专业，仅供参考）

  • 传统 RDBMS：Oracle、SQL Server 等都具备数据仓库版本。
  • 专门用于数据仓库的：Greenplum 等。
  • 自建集群的：Hive 等。
  • 云数据仓库：Redshift、Snowflake、Dataworks 等。
  • 实时数据仓库：flink 等。

  • 一些强大的技术组件：Kylin、Clickhouse 等。

    数据仓库的价值

  • 和生产数据库隔离，避免数据分析相关的大规模查询影响生产数据库的性能。

  • 整合、组织并加工企业内散布于各系统中的数据，便于企业进行各类数据为基础的应用。
  • 是数据资产化的重要一步。

数据仓库的潜在问题

  • 维护的开销不比建设小。数据仓库的重大开销在于日常的维护、数据质量的管理等。
    • 常见数据错误：源头错误，抽取错误、计算错误等等。
  • 难以随业务模式的变更灵活变更。比如，因管理需要，数据仓库的最初的主题划分会参考业务部门的划分情况，当组织架构出现较大规模变动时，数据仓库的基础动摇，重构成本极高。
    • 同理，如果数据仓库最初的建设团队未能设计一个足够优秀的数据仓库模型，数据仓库项目最终无法充足发挥价值、乃至需要推倒重来的风险极高。
  • 数据血缘管理困难。跨表汇总、跨主题汇总、跨部门汇总正是数据仓库的价值点，同时也带来导致数据管理复杂度的挑战。
  • 随着使用的深入，低价值的数据处理脚本无法清理，始终占用宝贵的计算资源，导致数据仓库整体效率变慢。很多数据仓库项目缺少后期的维护，很多数据仓库产品也不提供足够优质的性能管理工具。
  • 数据仓库模型的规范要求所有数据仓库中的数据都要按一些规则得到妥善处理，在数据量爆炸的当下，这些工作仍然需要人工参与。

数据仓库 vs 数据集市

  • 区分数据集市和数据仓库是非常重要的，这源于数据仓库先驱Bill Inmon和Ralph Kimball提出的两种截然不同的数据建模方法之间的争论。
  • Ralph Kimball认为，最好的方法是从最重要的业务方面或部门入手，从这些方面可以产生面向特定业务线的数据集市。随着时间的推移，企业可以根据需要合并其数据集市以形成数据仓库。Kimball的方法被称为自下而上（bottom-up）。
  • Bill Inmon认为仅仅将数据集市结合起来是不够的。他提倡创建数据仓库，作为企业数据模型的物理表示，可以根据需要为特定的业务单元创建数据集市。
  • 每种方法都有各自的优点，许多因素会影响你的决定。应该从数据集市入手，还是从数据仓库入手，要基于你从事的行业考虑。

    数据仓库 vs 数据中台

    作为难得的国产技术概念，数据中台完美地经历了一轮技术名词泡沫。在一开始“什么是中台”都没有彻底定义清楚时，已经有一堆阿里系创业公司入场了；当“数据中台”概念刚刚人尽皆知时，泡沫随之开始破灭。乐观的创业者投资者热心地鼓吹，有经验的数据从业人员在质疑中台和数据仓库的区别，却也有人想要借助这个新奇的概念给自己立几个项目。一时间，锣鼓喧天，好不热闹。（各大公司的中台概念见 中台）

而在肇始者自己的文章《数据中台的前世今生》中，中台的特点显露了出来：
“在2014年以前，阿里巴巴有很多条业务线，都有自己的ETL团队，每个ETL团队建设和维护自己的数据体系。…… 不同部门、不同业务、不同系统之间都有自己单独的ETL处理体系，每个ETL体系只关注与自己垂直业务相关的需求，并从底向上完整支撑业务体系。…… 这种分散数据处理体系带来了很多问题。以日志采集数据为例，就同时存在若干份数据：淘宝数据基础层、广告数据基础层、搜索数据基础层各有一份日志数据，不仅直接耗费了非常多的存储资源，更重要的是扼杀了数据中间层和数据应用层等复用的可能性。”

简单粗暴地总结一下。阿里巴巴一条单独业务线本身的数据体量和数据应用情况，就相当于一个独立的大企业。而作为一家互联网公司，阿里巴巴天然地需要尽可能地使用数据，所以各业务线的数据系统在技术层面上存在着重复建设的情况。出于研发效率和成本的考虑，“阿里巴巴内部开始进行数据公共层的建设，数据公共层旨在可持续地建设阿里巴巴智能大数据体系”。这一个“数据公共层”就是所谓的数据中台。类似的概念，还有阿里巴巴的业务中台。
image.png
换言之，数据中台和数据仓库最初是两个概念，数据中台本质上是去数据仓库的，但在理念上是大量借鉴数据仓库的，毕竟目的和效果是一样的，只是数据中台要应对的数据体量、业务复杂度要大于数据仓库。所以在部分数据从业人看来，《大数据之路》缺乏理论创新。如果要将数据中台作为一种数据产品出售给条件完全不同的企业，就像把汽车出售给无油世界的人，买家只能拆掉车头，套上马具，当作新式马车来用。累人累马，别无所得。

数据仓库 vs 数据湖

（数据湖目前的应用并不广泛，所以暂略。感兴趣的可参考文末的参考文献“4万字全面掌握数据库, 数据仓库, 数据集市,数据湖,数据中台”）

数据仓库建模范式类型

  • 从纯技术角度上讲，数据仓库的建设本质上就是数据库的建设，只不过习惯上一直将业务系统的数据库建设和数据仓库的建设分为两类工作。

  • 目前业界最为常用的就是维度建模，以至于在讲数仓建模时默认就是讲维度建模。

    • 所以从维度建模这一流派开始学习数据仓库的 ROI 最高。如无强烈需求，甚至可以弃其他流派的方法不管。

      实体关系（ER）模型

  • 数据仓库之父Immon的方法从全企业的高度设计一个3NF模型，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF，它与OLTP系统中的3NF的区别，在于数据仓库中的3NF上站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系抽象，它更多的是面向数据的整合和一致性治理，正如Immon所希望达到的：“single version of the truth”。但是要采用此方法进行构建，也有其挑战：

    • 需要全面了解企业业务和数据
    • 实施周期非常长
    • 对建模人员的能力要求也非常高
  • 目标是从全局的高度来设计一个满足3NF的模型，并不针对某个具体的业务流程。E-R模型的优点有如下几种：规范好、冗余小、集成度高、一致性强，适用于大型银行这一类的大型企业总体层面上的规划。但E-R模型的缺点就是优点的反面，因为太过于全面和复杂，因而对项目实施的时间和人员的要求非常高。

维度模型

  • 维度模型是数据仓库领域另一位大师Ralph Kimall所倡导，它的《The DataWarehouse Toolkit-The Complete Guide to Dimensona Modeling》是数据仓库工程领域最流行的数仓建模经典。
  • 维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。典型的代表是我们比较熟知的星形模型，以及在一些特殊场景下适用的雪花模型。
  • 目标是从分析决策的层面出发构建模型，针对大规模复杂业务场景的响应性能有较好的表现。典型的代表是我们比较熟知的星形模型、雪花模型等。维度建模理解起来比较容易，上手比较快，但由于冗余了很多信息，修改起来灵活性就不太理解。在PB及以上数量级的数据仓库中，一般情况下以性能为优先，庞大的集群对于数据的冗余是可以接受的，并且因为DWS中间层的建设减少了非一致性的问题，因而多采用维度模型来构建数据仓库。

DataVault 模型

  • DataVault是Dan Linstedt发起创建的一种模型方法论，它是在ER关系模型上的衍生，同时设计的出发点也是为了实现数据的整合，并非为数据决策分析直接使用。它强调建立一个可审计的基础数据层，也就是强调数据的历史性可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合；同时也基于主题概念将企业数据进行结构化组织，并引入了更进一步的范式处理来优化模型应对源系统变更的扩展性。它主要由：Hub（关键核心业务实体）、Link（关系）、Satellite（实体属性）三部分组成 。

image.png

Anchor模型

Anchor模型是由Lars. Rönnbäck设计的，初衷是设计一个高度可扩展的模型，核心思想：所有的扩展只是添加而不是修改，因此它将模型规范到6NF，基本变成了K-V结构模型。Anchor模型由：Anchors 、Attributes 、Ties 、Knots 组成，相关细节可以参考《Anchor Modeling-Agile Information Modeling in Evolving Data Environments》。
image.png

数据模型的评价

  • 数据模型建设的怎么样，极度依赖规范，如果代码风格是“千人前面”，那么恐怕半年下来，业务系统就没法看了。规范体系不仅能保障数据建设的一致性，也能够应对业务交接的情况，更能够为自动化奠定基础。
    • 业务过程清晰。例如，ODS就是原始信息，不修改；DWD面向基础业务过程；DIM描述维度信息；DWS针对最小场景做指标计算；ADS也要分层，面向跨域的建设，和面向应用的建设；
    • 指标可理解：按照一定业务事务过程进行业务划分，明细层粒度明确、历史数据可获取，汇总层维度和指标同名同义，能客观反映业务不同角度下的量化程度；
    • 核心模型相对稳定：如果业务过程运行的比较久，过程相对固定，就要尽快下沉到公共层，形成可复用的核心模型；
    • 高内聚低耦合：各主题内数据模型要业务高内聚，避免在一个模型耦合其他业务的指标，造成该模型主题不清晰和性价比低。

维度建模

需要提前指出的是，数据仓库项目的突出特点就是实践性强于技术性，下面提及的维度建模方法论仅是多种数据仓库建模范式中最广为使用的一种，且该方法论的实施部分仅能起到笼统的参考价值。不同行业的维度建模模型有各自的特点，业界各厂家也发展总结了自己的项目实施方案，如有资源，掌握基础概念后即可转向借鉴哪些更有行业针对性的建模案例。

基本概念解析

维度建模的一大优势就是基础概念易于理解。概念的具体解释见《数据仓库工具箱-维度建模权威指南》的第二章。

业务过程 Business Process

  • 组织完成的操作型活动，都可以认为是业务过程。业务过程是技术人员对组织活动的抽象理解，是企业信息化中一个较为基础和重要的概念。

  • 业务过程定义了特定的设计目标以及对粒度、维度、事实的定义。这些定义对于数据仓库的建设是基础性的。

    事实 Fact

  • 事实涉及来自业务过程事件的度量。

  • 一个事实表行与按照事实表粒度描述的度量事件之间存在一对一关系。

    维度 Dimension

  • 我们理解、观察、拆分事实的角度，对应到数据库中的字段一般是分类类型或序数类型。例如：

    • 时间。按日、周、月、年等查看汇总数据的趋势。
    • 地域。按省份等行政区划或按自然地理区块查看数据的空间分布。
    • 组织。按部门、小组查看绩效的达成情况。
    • 产品。对比查看近似商品的销售情况，为下一步的产品结构调整提供参考。
    • 等等

      度量 Measure

  • 可以定量衡量某一事实的字段，一般是数值类型，或是单纯对事实行的计数。例如

    • 事件发生的次数。当每次事件都记录且仅记录一行事实数据时，对事实行的计数可以得到事件的次数。
    • 消费会员数。因会员可能多次消费，所有消费记录的事实表中的会员信息必然存在重复，其中会员ID字段和会员昵称字段都可用于度量消费会员数，即会员ID字段和会员昵称字段都是可用于度量消费会员数量大小的字段。
    • 对度量字段进行明确的计数操作，则形成指标。

      指标 Metrics

  • 对度量字段进行明确的计数操作，则形成指标。常见的操作有：计数、去重计数、求和等。

  • 初始指标：仅定义了对度量的计算方式得到的指标。
    • 有些厂商会将其称作原子指标，但实际上计算得到的结果并不是原子粒度的，所以我称之为初始指标。英文名可以是 Initial Metrics 或 Preliminary Metrics，可以体现指标含义的初步性和不完整。初始指标的仅定义了聚合的方式，不具备准确的业务含义，数据分析师并不会直接使用初始指标的结果。出于沟通的便利，分析师们习惯性地省略指标的前缀，使用初始指标作为指标名称而已。
    • 对应到 BI 系统中，大多数 BI 在新建聚合计算字段时，本质上就是在定义一个未被执行的初始指标。
  • 衍生指标/派生指标：对初始指标加以准确的取数条件约束，即在自然语言中表现为不断变长的前缀，可以获得含义清晰的指标，我借用“派生词”的含义将其称为衍生指标/派生指标，英文是 Derived Metrics。
    • 销售额是初始指标，定义了 SUM(amount) 这个聚合方式。年销售额则是衍生指标，SUM(amount) WHERE Year = this.year。日常沟通中，则会说“某年销售额是XXX”，不会直接说“销售额是XXX”，除非有明确的上下文语境。
    • 对应到 BI 系统中，将某个定义好的聚合计算字段载入绘图区时，可能会默认聚合所有数据，而报表发布后则一般会被分析师限定到具体的筛选条件范围内，即成为衍生指标。
  • 复合指标 Compound Metrics：通过对两个及以上衍生指标的计算得到的新指标。
    • 客单价就是典型的复合指标 SUM(amount) / COUNT_DISTINCT(order_id)。
    • 对应到 BI 系统中，通过计算字段新建的计算字段一般都是复合指标。

  • 通过指标构成将指标分成 3 类可能有助于报表系统的计算性能优化，但目前大部分 BI 报表底层都基于类 SQL 的查询，数据库查询层自带了这种优化，所以此处的分类方法也沦为书面之谈了。

    细粒度 Granularity

  • 在具体的维度值下，同一个度量字段可以形成不同的指标，它们之间的区别就是细粒度的区别。

    • 年销售额相对于月销售额而言，具有更粗的粒度。

      星型模型

  • 一张事实表居中，多张维度表直接关联到该事实表上。

    雪花模型

  • 一张事实表居中，部分维度表直接关联到事实表上，剩下的维度表先关联到维度表上再被关联到事实表上。

    数据立方体 Data Cube

    数据集市 Data Mart

    • 数据仓库的一个子集，仅包含和具体某个子部门有关的数据，而不包含不归属于改部门的数据。

      ETL & ELT

  • Extract 抽取、Transform 转换、Load 加载，数据仓库实施中进行的数据操作可以归纳为这三个步骤，相应的软件工具也被称作 ETL 工具。也有按照 ELT 操作顺序进行的，先将大量的数据载入数据仓库中，再借助数据仓库更大的数据处理能力来完成 Transform。

    维度建模经典四步骤

  • Kimball 的经典教材《数据仓库工具箱-维度建模权威指南》中“3.1 模型维度设计的步骤”详细阐述了维度建模的四步骤。

    • （1）选择业务过程
    • （2）声明粒度
    • （3）确认维度
    • （4）确认事实

数据仓库生命周期

  • 数据仓库的具体实现中，实践性、工程性强于技术性。所以哪怕都采用维度建模的方式，不同数据仓库项目采取的项目管理机制也不尽相同。不考虑具体的项目管理方式，所有数据仓库建设流程和下图都不会有太大差异：
    • image.png
  • 如无条件向有经验的数据仓库团队、个人学习，建议反复学习《数据仓库工具箱-维度建模权威指南》中的“第17章 Kimball DW/BI 生命周期”和“第18章 C18 维度建模过程与任务”，再结合自己的项目经验、工程经验提炼一套属于自己的数据仓库方法论。

数据仓库建模设计三步走

  • 按照我自己的经验，结合 Kimball 的指导，数据仓库建模设计大体上可以分为三步：

    Step 1: 业务理解（价值链/业务流程）

    （1）区分企业部门架构、部门与岗位职责；
    （2）梳理企业关键业务流程（价值链）；
    （3）识别具体的企业业务过程，并且找到支持的业务系统。
    在该阶段，最好可以产出这些文档：

  • 企业商业模式架构图

  • 企业组织架构图与项目相关部门对接人员清单
  • 企业全盘的业务流程图
  • 企业各部门 KPI 等信息
  • 企业 IT 战略和数据战略文档
  • 企业现有信息系统与 IT 资产目录
  • 企业信息安全要求文档（如有）

  • 各部门的数据需求文档

    Step 2: 企业数据仓库总线架构/矩阵

    （1）文档化整理企业数据仓库总线矩阵 与 业务过程相关方矩阵，识别公共维度与需要沟通的部门
    （2）确定设计范围，并且识别粒度。
    在该阶段，可以完成这些工作：

  • 主题域的划分和各主体域下核心事实表的确定

  • 数据归属权和数据质量责任人的确认
  • 公共维度的识别、域内维度的识别
  • 公共指标的识别和跨部门初步共识

    Step 3: 详细维度模型设计

    （1）选择业务过程
    （2）声明粒度
    （3）确认维度
    （4）确认事实

数据仓库建设的几个要点

  • 业务理解、主题划分与维度建模：如前所述。
  • 项目规范：
    • 表命名规范、字段命名、代码开发规范、任务调度规范等。
    • 良好的项目规范对开发、协作、维护都有极大的好处。
  • 开发实施的两个难点：
    • 代码
    • 调度
  • 项目管理和人员组织
    • 数据仓库建设周期长，涉及业务部门多，人事挑战也不容小觑。

可供参考的学习材料

经典教材