2.1 离线数据平台的架构、技术和设计

对于公司的管理者、一线业务人员来说，经常需要回答的问题是：当前和过去一个季度或者一个月的销售趋势如何？哪些商品热销？哪些商品销售不佳？哪些客户在买我们的产品？管理者和业务人员需要不停地监控这些业务指标，并有针对性地根据这些指标调整业务策略和打法，如此反复，形成闭环，这就是数据化运营的基本思路。

数据化运营的思想不仅体现在业务分析上，产品开发中数据驱动的思想也日益普及。通过埋点技术，用户的各种行为和路径等都能被捕获并保存下来，数据分析工程师和产品经理会多维度地分析用户的各种行为和路径，从而对产品的功能效果进行数据量化，并做出产品决策。

这类分析和“看”的需求正是离线数据平台所擅长的，这类分析性的需求，数据的时效性并不是强需求，当天的数据有了也好，即使没有，影响也不大，离线的数据技术和工具已经发展很多年了，开源的解决方案和商业性的解决方案也有很多，已经能够很成熟地解决此类问题。

离线数据平台是构建公司和企业数据平台的根本和基础，也是目前数据平台的主战场，因此先来介绍离线数据平台的有关核心概念和技术。

2.1.1 离线数据平台的整体架构

首先给出离线数据平台的整体架构大图（见图2-1），使读者对离线数据平台有全局性的认识。

离线数据平台通常和Hadoop、Hive、数据仓库、ETL、维度建模、数据公共层等联系在一起。

在大数据以及Hadoop没有出现之前，离线数据平台就是数据仓库，数据部门也就是数据仓库部门。即使在今天，在很多对数据相关概念和技术没有较多了解的人看来，数据部门还是数据仓库部门。

Hadoop出现之前，数据仓库的主要处理技术是商业化数据库，比如微软的SQL Server、甲骨文的Oracle、IBM的DB2等。随着大数据的兴起以及数据量的持续爆炸和指数级别增长，Hadoop以及MapReduce、Hive等大数据处理技术才得到越来越广泛的应用和接受。

其实上面大图中的Hadoop模块也可以用商业化的工具替代，比如微软的SQL Server、甲骨文的Oracle等关系数据库，也可以用MPP架构的Teradata、HP Vertica、EMC Greenplum等分析性数据库（MPP架构也是分布式的分析型数据库，但是和Hadoop相比，通常基于昂贵硬件而且不可线性扩展），实际上目前很多公司出于各种原因也正是采用这样的方案，但是从当前的技术现状以及未来的技术发展来看，笔者认为可线性扩展Hadoop或者类Hadoop方案将会是主流和发展方向，因此本文主要基于Hadoop来介绍离线数据平台。

离线数据平台的另一个关键技术是数据的建模，目前采用最为广泛也最为大家认同的是维度建模技术。

此外，离线数据内容建设出于最佳实践，通常还会对精心加工后的数据进行分层（ODS原始数据层、DWD明细数据层、DWS汇总层、ADS集市数据层等），本章也将对此进行介绍。

2.1.2 数据仓库技术

离线数据平台是和数据仓库的产生和发展紧密联系在一起的，因此首先介绍数据仓库的有关概念。

1．OLTP和OLAP

数据仓库是随着数据分析的需求逐渐发展起来的，最初的数据分析和报表都是基于业务系统的数据库完成的，也就是OLTP数据库，如商业性的Oracle、MS SQL Server和开源的MySQL等关系数据库。

OLTP的全称是Online Transaction Processing，顾名思义，OLTP数据库主要用来进行事务处理，比如新增一个订单、修改一个订单、查询一个订单和作废一个订单等。OLTP数据库最核心的需求是单条记录的高效快速处理，索引技术、分库分表等最根本的诉求就是解决此问题。

而这个和数据分析的需求是天然相反的，数据分析通常需要访问大量的数据，单条数据的分析没有任何意义。数据分析不仅需要访问大量的数据，还要对其进行频繁的统计和查询，很快数据库管理员发现这些统计分析请求占用了大量数据库的资源，已经严重到影响生产系统的性能。于是隔离这些数据分析请求到单独的备库或者完全复制一个新的数据库供数据分析人员使用是自然而然的选择。

解决了对生产库的影响问题后，OLTP数据库管理员很快发现备库和复制库还是不能满足数据分析人员的需求，尤其是在性能方面。大量的数据访问通常需要全表扫描，频繁而且通常又是并发地全表扫描会造成OLTP数据库响应异常缓慢甚至宕机，必须有新的理论支撑和技术突破才能够满足这些分析请求。

于是OLAP数据库应运而生，它是专门的分析型数据库，是为了满足分析人员的统计分析需求而发展起来的。

OLAP数据库本身就能够处理和统计大量的数据，而且不像OLTP数据库需要考虑数据的增删改查和并发锁控制等。OLAP数据一般只需要处理数据查询请求，数据都是批量导入的，因此通过列存储、列压缩和位图索引等技术可以大大加快响应请求的速度。

OLTP和OLAP数据库的简单对比见表2-1，最核心的还是OLTP专注于单条记录的处理，而OLAP专注于满足分析人员大量数据的分析和统计。

2．分析型数据库

专门分析型数据库的出现标志着数据仓库由学术和概念阶段正式进入工业实用阶段。国际大厂也纷纷推出了商业性的MPP或者类MPP架构的数据仓库产品，有代表性的为Oracle Exadata、天睿公司的Teradata、IBM收购的Netezza、EMC公司的Greenplum、惠普公司的HP Vertica等。其中的领导者为Teradata, Teradata数据仓库在企业级数据仓库市场尤其金融、电信等中占有绝对的优势，也是最为高端、稳定和成熟的数据仓库产品。

这些国际大厂不仅仅提供数据仓库软件和数据库，随着企业对数据和数据分析的日益重视，相关的IT预算越来越大，一站式解决方案和产品“一体机”应运而生。一体机不仅包含数据仓库软件，还包含配套的服务器、存储设备、操作系统和高速网络交换设备等。一体机是软硬件一体化的解决方案型产品，可以做到开箱即用和一键部署。

数据仓库产品面对的主要是分析师和业务分析人员对大数据集的统计和聚合操作，其架构、设计和原理和传统数据库产品（OLTP数据库）截然不同。通常来说，数据仓库产品一定是分布式的，但是其和OLTP数据库的分布式要解决的问题有着明显的不同。OLTP数据库的分布式（如分库分表等技术）主要是为了解决海量单条数据请求的压力，其主要目的是把所有用户请求均匀分布到每个节点上，而OLAP的分布式是将用户单次对大数据集的请求任务分配到各个节点上独立计算然后再进行汇总返回给用户。

此外，OLAP数据库一般采用列式存储，而OLTP通常采用行式存储。所谓列式存储就是将表的每列一列一列地存储在一起，而不是像行存储一样按行把所有字段存储在一起。对于数据库表来说，列的类型是固定的，所以列存储可以很容易采用高压缩比的算法进行压缩和解压缩，磁盘的I/O会大大减少。列存储非常适合大数据量统计查询的应用场景，因为分析统计常常是针对某列或某些列的，列存储的数据库产品只需读出对应列并处理即可，而不是读出整个表的所有行进行处理。

3．Hadoop数据仓库

在Hadoop出现以前及其还不太成熟和完善的阶段，商业性的数据仓库产品（如Oracle Exadata、天睿公司的Teradata、微软的SQL Server、IBM的Netezza、EMC公司的Greenplum、惠普公司的HP Vertica等）在企业数据分析和数据仓库领域占据了主导地位。但是随着这些年Hadoop的完善和Hadoop生态系统的崛起，短短几年间，基于Hadoop的数据仓库已经完全占据了主赛道，尤其是在互联网公司内，基于Hadoop的数据仓库基本是标配。

Hadoop的内在技术基因决定了基于Hadoop的数据仓库方案（目前主要是Hive）非常容易扩展（可以很容易地增加节点，把数据处理能力从GB、TB扩展PB甚至EB），成本也非常低廉（不用商业昂贵的服务器和存储，只需要普通的硬件即可，Hadoop框架会进行容错处理），这两点也是Hadoop在互联网公司内日益流行的关键因素。试想一下，如果腾讯、阿里巴巴、百度把它们海量的数据存储在商业性的数据仓库产品（如Teradata、Oracle、MS SQL Server）内，首先不论这些商业性的数据仓库产品技术上是否能够支持，但是费用和成本就是一笔非常大的开销，还不论因数据量增大需要商业数据产品增加节点所带来的管理和维护开销。实际上，国外的Facebook和国内的BAT初始也是基于商业的数据仓库解决方案来建设数据仓库的，后来它们无一不转向了基于Hadoop和类Hadoop的数据仓库解决方案。

基于Hadoop的数据仓库解决方案，尤其是Hive，面临最大的挑战是数据查询延迟（Hive的延迟一般是在分钟级，取决于Hive SQL的复杂度和要处理的工作量，很多时候甚至需要运行几个小时。当然，对于简单的以及小数据量的Hive SQL，也可能几秒钟就返回结果）。由于Hive是翻译为MapReduce任务后在Hadoop集群执行的，而Hadoop是一个批处理系统，所以Hive SQL是高延迟的，不但翻译成的MapReduce任务执行延迟高，任务提交和处理过程中也会消耗时间。因此，即使Hive处理的数据集非常小（比如几MB），在执行时也会出现延迟现象。但是相比其根植于Hadoop的近似线性的可扩展性、低廉的成本和内在容错等特性，这些都不是问题，都是随着技术的发展可以完善和解决的，或者业务可以承受的。

大数据和云计算是未来，未来的业务系统也都会执行在云端，不管是私有云、公有云或者混合云。云端也决定了未来的架构肯定是分布式的，能够近似线性扩展的，基于此，笔者认为基于Hadoop和类Hadoop的数据仓库解决方案未来将会成为主流和标配，不管是对于互联网公司来说，还是传统企业来说。

2.1.3 数据仓库建模技术

上一节介绍了搭建数据仓库的三种主要方式：在传统OLTP数据库中搭建（如Oracle、MS SQL Server等）、在商业性数据仓库产品中搭建（如MPP架构的Teradata等）还有基于Hadoop来搭建等，但是不管在哪里搭建都面临这样的问题，例如，怎么组织数据仓库中的数据？怎么组织才能使得数据的使用最为方便和便捷？怎么组织才能使得数据仓库具有良好的可扩展性和可维护性？

从数据仓库概念诞生以来，在数据仓库领域，存在两种得到广泛认可的方法来构建数据仓库。这两派的代表人物分别是Bill Inmon和Ralph Kimball, Bill Inmon被称为“数据仓库之父”，而Ralph Kimball被称为“商业智能之父”，他们的观点主要公开发表于以下两本经典著作《The Data Warehouse Toolkit》（由Ralph Kimball和Margy Ross合著）和《Corporate Information Factory》（由Bill Inmon、Claudia Imhoff和Ryan Sousa合著）。

从这两种观点诞生以来，围绕“哪种架构最佳”的争论一致没有休止，人们各抒己见，但是一直无法形成统一的结论，就像“哪种编程语言是最佳的编程语言”一样，这可以称为数据仓库领域的“宗教战争”。本书并不打算给出一个结论，但是将会详细介绍这两种架构并进行对比，供用户在不同的场合、针对不同的应用场景选择某个方法或者采用混合两者的方法。

1．Ralph Kimball建模方法论

Kimball对数据仓库的理论贡献都与维度设计和建模有关。维度建模将客观世界分为度量和上下文。度量是由机构的业务过程以及支持它们的源系统来捕捉的，常以数值形式（如订单金额、库存数量等）出现，维度建模理论称它为事实；事实由大量文本形式的上下文包围着，而且这些上下文常被直观地分割成多个独立的逻辑块，维度建模称之为维，维描述了度量的5个W（When、Where、What、Who和Why）信息，比如什么时间下单、何种方式下单、买的什么、客户是谁等。

利用维度建模理论建模的Kimball数据仓库常以星形架构来呈现，如图2-2所示，在星形架构中间的是事实表，事实表周围的则是各个角度的维度表。

在维度建模中，由于星形模式紧贴业务过程，非常直观和符合业务人员的视角，因此被广泛和大量使用，星形模式也是Kimball对数据仓库建模的一大贡献。

Kimball对数据仓库建模理论的第二大贡献是基于维度的“总线体系架构”。实际项目中，企业的业务过程通常是多样性和复杂的，存在于多个业务主题，总线体系架构和一致性维度一起保证了多个主题的事实表和维度表能够最终集成在一起，提供一致和唯一的口径给业务人员。

采用Kimball建模理论的数据仓库体系架构如图2-3所示。

可以看出，Kimball维度建模的主题以星形架构为主，主题和主题之间则用一致性维度和企业总线体系架构来保证数据仓库的集成和一致性。

2．Bill Inmon建模方法论

在数据仓库领域，Bill Inmon是第一个提出来OLAP和数据仓库概念的人，所以被称为“数据仓库之父”。Bill Inmon撰写了大量介绍其数据仓库方法的文章，他认为数据仓库是“在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合”，与其他数据库应用不同的是，数据仓库更像一种过程，对分布在企业内部各处的业务数据的整合、加工和分析的过程，而不是一种可以购买的产品，这就是他所说的“企业信息化工厂”。

图2-4描述了Bill Inmon建模理论的企业级数据仓库体系架构。

Inmon的企业信息化工厂包括源头系统、准备区、ETL、企业数据仓库、数据集市等，而企业数据仓库是企业信息化工厂的枢纽。不同于Kimball, Inmon认为企业数据仓库应为原子数据的集成仓库，应该用第三范式和ER理论而非维度建模的事实表和维度表来建模。

Inmon的企业信息化工厂涉及了“数据集市”的概念，所谓“集市”，就是部门级的数据仓库。对于数据集市来说，Inmon主张从企业数据仓库中提取所需要的数据，从而保证数据的一致性。这样带来的问题是必须先有企业数据仓库才可能开始建立部门级的数据集市，这是Inmon数据仓库架构和Kimball数据仓库架构的第二个主要不同。同时，Inmon也认为应该用Kimball的维度建模理论来构建数据集市。

3．数据仓库建模实践

从上述对两者数据架构的介绍可以看出，Inmon的方法是一种由上而下（top-down）的数据仓库构建方法，其主张首先要对企业数据仓库进行总体规划，并将不同的OLTP数据集中到面向主题、集成的、不易失的和时间变化的企业数据仓库中。数据集市应该是数据仓库的子集，每个数据集市都是为独立部门专门设计的。

Kimball方法则相反，其是自下向上的（down-top）。Kimball认为数据仓库是一系列数据集市的集合，企业可以通过一致性的维度表和“企业总线架构”来递增式集成各个数据集市，从而构建整个企业的数据仓库。

一句话总结它们的区别。

Kimball：let people build what they want when they want it, we will integrate them it all when and if we need to.

Inmon：don't do anything until you have designed everything.

Inmon的方法部署和开发周期较长，但是容易维护而且高度集成；而Kimball的方法可以迅速响应业务需求，快速构建一个数据仓库，但是后期集成和维护较为麻烦。

没有绝对的对与错，只有不同阶段和不同场景下的利弊权衡。一般来说，在项目早期和互联网领域，Kimball的方法更为实用和接地气，因为需求变化快，成效要求快，投资回报快。如果使用Inmon的方法，也许永远设计不出一个企业数据仓库，因为业务一直在变，系统一直在变，数据一直在变，这种情况下，可以用Kimball的方法先建立数据集市，而后根据业务的进展再沉淀出企业数据仓库。而对于项目中后期或者其业务基本不变、不需要对短期投资回报率有很高要求的情况下，可以先设计企业数据仓库，而后建立各个业务部门的数据集市。

2.1.4 数据仓库逻辑架构设计

离线数据仓库通常基于维度建模理论来构建，但是除此之外，离线数据仓库通常还会从逻辑上进行分层。数据仓库的逻辑分层也是业界的最佳实践。

离线数据仓库的逻辑分层主要是出于如下考虑。

❏ 隔离性：用户使用的应该是数据团队精心加工后的数据，而不是来自于业务系统的原始数据。这样做的好处之一是，用户使用的是精心准备过的、规范的、干净的、从业务视角的数据，非常容易理解和使用。好处之二是，如果上游业务系统发生变更甚至重构（比如表结构、字段、业务含义等），数据团队会负责处理所有这些变化，最小化对下游用户的影响。

❏ 性能和可维护性：专业的人做专业的事，数据分层使得数据的加工基本都在数据团队，从而相同的业务逻辑不用重复执行，节省了相应的存储和计算开销，毕竟大数据也不是没有代价的。此外，数据的分层也使得数据仓库的维护变得清晰和便捷，每层只负责各自的任务，某层的数据加工出现问题，只需修复该层即可。

❏ 规范性：对于一个公司和组织来说，数据的口径非常重要，大家谈论一个指标的时候，必须基于一个明确的、公认的口径，此外表、字段以及指标等也必须进行规范。

数据仓库一般分为如下几层。

❏ ODS层：数据仓库源头系统的数据表通常会原封不动地存储一份，这称为ODS（Operation Data Store）层，ODS层也经常会被称为准备区（staging area），它们是后续数据仓库层（即基于Kimball维度建模生成的事实表和维度表层，以及基于这些事实表和明细表加工的汇总层数据）加工数据的来源，同时ODS层也存储着历史的增量数量或者全量数据。

❏ DWD和DWS层：数据仓库明细层（Data Warehouse Detail, DWD）和数据仓库汇总层（Data Warehouse Summary, DWS）是数据平台的主体内容。DWD和DWS层的数据是ODS层数据经过ETL清洗、转换、加载生成的，而且它们通常都是基于Kimball的维度建模理论来构建的，并通过一致性维度和数据总线来保证各个子主题的维度一致性。

❏ 应用层（ADS）：应用层主要是各个业务方或者部门基于DWD和DWS建立的数据集市（Data Mart，以下简称DM），数据集市DM是相对于DWD和DWS的数据仓库（Data Warehouse，以下简称DW）来说的。一般来说，应用层的数据来源于DW层，但原则上不允许直接访问ODS层的。此外，相比DW层，应用层只包含部门或者业务方自己关心的明细层和汇总层数据。

采用上述ODS层→DW层→应用层的数据仓库逻辑分层架构如图2-5所示。