《离线和实时大数据开发实战》（二）大数据平台架构 &amp； 技术概览_数据平台开发技术(1)

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

1. Ralph Kimball 建模方法论

Kimball 对数据仓库的理论贡献都与维度设计和建模有关。维度建模将客观世界分为度量和上下文。

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

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

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

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

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

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

2. Bill Inmon 建模方法论

在数据仓库领域， Bill Inmon 是第一个提出来 OLAP 和数据仓库概念的人，所以被称为数据仓库之父” 。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 的方法可以迅速响应业务需求，快速构建一个数据仓库，但是后期集成和维护较为麻烦。两者没有绝对的对与错，只有不同阶段和不同场景下的利弊权衡。

4. 数据仓库逻辑架构设计

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

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

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

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

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

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

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

OWD 和 DWS 层： 数据仓库明细层（ Data Warehouse Detail, D WD ）和数据仓库汇总层（ 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 层→应用层的数据仓库逻辑分层架构如图所示：

二、实时数据平台的架构、技术和设计

离线数据平台产出数据的周期一般是天，也就是说，今天看到的是昨天的数据，对于大部分的分析和“看”数据的场景来说，这种 T+1 的离线数据可以满足业务分析的需求，但是随着业务运营日渐精细化，对数据的时效性要求越来越高，越来越多的业务场景需要马上看到业务效果，尤其是在业务促销活动等（典型的如双 11 大促、 618 大促等）场景下。

更重要的是，随着人工智能浪潮的兴起，实时的数据已经不是最好，而是必须。数据也不仅仅在分析和“看”，而是和算法一起成为生产业务系统的一部分。

2.1 实时数据平台的整体架构

实时数据平台的支撑技术主要包含四个方面：实时数据采集（如 Flume ），消息中间（如 Kafka ）、流计算框架（如 Strom 、Spark、 Flink、 Beam 等），以及实时数据存储（如列族存储的 HBase）。 目前主流的实时数据平台也都是基于这四个方面相关的技术搭建的。

实时数据平台首先要保证数据来源的实时性。数据来源通常可以分为两类：数据库和日志文件。对于前者，业界的最佳实践并不是直接访问数据库抽取数据，而是会直接采集数据库变更日志。

对于 MySQL 来说就是 binlog ，它是 MySQL 的数据库变更日志，包括数据变化前和变化的状态。

数据采集工具（如 Flume ）采集的 binlog 事件，其产生速度和频率通常取决于源头系统。它和下游的实时数据处理工具（比如 Storm、Spark、Flink 等流计算框架和平台）处理数据的速度通常是不匹配的。另外，实时数据处理通常还会有从某历史时间点重启以及个实时任务都要使用同一源头数据的需求，因此通常还会引人消息中间件来作为缓冲，从而达到实时数据采集和处理的适配。

实时数据存储根据下游数据使用的不同方式通常放在不同的数据存储内，对于数据在服务（即数据使用方传入某个业务 ID ，然后获取到所有此 ID 的相关字段），通常放在 HBase ；对于实时数据大屏，通常放在某种关系数据库（如 MySQL ）内，有时为了提高能并减轻对底层数据库的压力，还会使用缓存数据库（如 Redis ）等。

2.2 流计算技术

流计算的开始流行和被大家所接受始于 2011 年左右诞生的 Storm ，Stοrm 作为“实时的Hadoop ”迅速被大家所知并接受。

那么，什么是流计算呢？它和离线批量处理又有哪些区别呢？不同于离线批处理（如 Hadoop Map Reduce ），流计算有着下面典型的特征：

无边界：流计算的数据源头是源源不断的，就像河水一样不停地流过来，相应地，流计算任务也需要始终运行。

触发：不同于 Hadoop 离线任务是定时调度触发，流计算任务的每次计算是由源头数据触发的 。触发是流计算一个非常重要的概念，在某些业务场景下，触发消息的逻辑比较复杂，对流计算挑战很大。

延迟：很显然，流计算必须能够高效地、迅速地处理数据。 不同于离线 Hadoop 任务至少以分钟甚至小时计的处理延迟，流计算的延迟通常在秒甚至毫秒级，分钟级别的延迟只在有些特殊情况下才被接受。

历史数据：Hadoop 离线任务如果发现历史某天的数据有问题，通常很容易修复问题而且重运行任务，但是对于流计算任务来说基本不可能或者代价非常大，因为首先实时流消息通常不会保存很久（一般几天）， 而且保存历史的完全现场基本不可能，所以实时流计算一般只能从问题发现的时刻修复数据，历史数据是无法通过流式方式来补的。

从根源上讲，流计算的实现机制目前有两种处理方式：一种是模仿离线的批处理方式，也就是采用微批处理（即 mini batch)。微批处理带来了吞吐量的提升，但是相应的数据延迟也会增大，基本在秒级和分钟级，典型的技术是 Spark Streaming 。另一种是原生的消息数据，即处理单位是单条数据，早期原生的流计算技术延迟低（一般在几十毫秒），但是数据吞吐量有限，典型的是原生的 Storm 框架，但是随着 Flink 等技术的产生和发展， 吞吐量也不再是问题。

2.3 主要流计算开源框架

三、数据管理

对于一个公司和组织来说，仅有数据的技术是不够的，还必须对数据进行管理。数据管理的范畴很广，但是具体主要包含数据探查、数据集成、数据质量、元数据管理和数据屏蔽等数据管理技术 。

3.1 数据探查

数据探查，顾名思义，就是对数据的内容本身和关联关系等进行分析，包括但不限于需要的数据是否有、都有哪些字段、字段含义是否规范明确以及字段的分布和质量如何等。数据探查常用的分析技术手段包括主外键、字段类型、字段长度、 null 值占比、枚举值分布、最小值、最大值、平均值等。

数据探查分为战略性的和战术性的。

• 战略性的数据探查是指在使用数据之前首先对数据源进行轻量级的数据分析，确定其是否可用，数据稳定性如何，以决定是否可以纳入数据平台使用。战略性的数据探查是构建数据平台前首先要进行的任务，不合格的数据源头必须尽快剔除，如果到了后期才发现数据源头不合格，将会对数据平台的构建造成重大影响。
• 战术性的数据探查则指用技术手段对数据进行详尽的分析，发现尽可能多的数据质量问题并反馈给业务人员或者通知源头系统进行改进。

3.2 数据集成

数据仓库的数据集成也叫 ETL （抽取： extract 、转换： transform 、加载： load ），是数据平台构建的核心，也是数据平台构建过程中花费时间最多、花费精力最多的阶段 。

ETL 泛指将数据从数据源头抽取、经过清洗、转换、关联等转换，并最终按照预先设计的数据模型将数据加载到数据仓库的过程。

对数据平台使用者和业务人员来说，他们通常并不知道也不关心所使用的数据（如订单） 源头有几个，都在哪些数据库里、字段定义是否一致（如订单系统 1 代表下单成功，0 代表下单失败，而系统2用 sucess 代表下单成功、用 fail 代表下单失败）、相关的数据表有哪些（如订单顾客的画像信息、商品的类目），数据使用者希望最终看到的是一个汇规的、规范，包含所有相关订单信息的宽表，这个宽表包含了所有能够使用的订单信息，而这些所有后台的抽取、清洗、转换和关联以及最终的汇总、关联等复杂过程都由 ETL 来完成，这也是数据仓库能够给数据使用者带来的重要价值之一。

3.3 数据质量

数据质量主要从以下四个方面来衡量：

完整性：完整性是指数据信息是否存在缺失的状况，数据缺失的情况可能是整个数据记录缺失，也可能是数据中某个字段信息的记录缺失。不完整的数据所能借鉴的价值就会大大降低，也是数据质量最为基础的一项评估标准。

一致性：：一致性是指数据是否遵循了统 的规范，数据集合是否保持了统一的格式。数据质量的一致性主要体现在数据记录的规范和数据是否符合逻辑，比如IP 地址一定是由4个 0 ~ 255 的数字加上“.”组成的。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

4983363747)]
[外链图片转存中…(img-9pbUEG2k-1714983363748)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！