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

最新推荐文章于 2024-05-21 11:40:29 发布

2401_84185626

最新推荐文章于 2024-05-21 11:40:29 发布

阅读量557

点赞数 18

分类专栏：程序员文章标签：大数据架构

本文链接：https://blog.csdn.net/2401_84185626/article/details/138264750

版权

程序员专栏收录该内容

112 篇文章 0 订阅

订阅专栏

接下来就是介绍数据平台，出于逻辑清晰以及技术相关性考虑，将主要从 离线数据平台、实时数据平台以及数据管理 三个方面来对数据平台相关的概念和技术进行介绍。

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

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

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

离线数据平台是构建公司和企业数据平台的根本和基础，也是目前数据平台的主战场。

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

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

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

离线数据平台的整体架构大图

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. 分析型数据库

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

此外， OLAP 数据库一般采用列式存储，而 OLTP 通常采用行式存储。

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

3. Hadoop 数据仓库

随着随着这些年 Hadoop 的完善和 Hadoop 生态系统的崛起，短短几年间，基于 Hadoop 数据仓库已经完全占据了主赛道，尤其是在互联网公司内，基于 Hadoop 的数据仓库基本是标配。

Hadoop 的内在技术基因决定了基于 Hadoop 的数据仓库方案（目前主要是 Hive 非常容易扩展（可以很容易地增加节点，把数据处理能力从 GB、TB 扩展 PB 甚至 EB ），成本也非常低廉（不用商业昂贵的服务器和存储，只需要普通的硬件即可， Hadoop 框架会进行容错处理），这两点也是 Hadoop 在互联网公司内日益流行的关键因素。

基于 Hadoop 的数据仓库解决方案，尤其是 Hive ，面临最大的挑战是数据查询延迟（Hive 的延迟一般是在分钟级，取决于 Hive SQL 的复杂度和要处理的工作量，很多时候甚至需要运行几个小时。当然，对于简单的以及小数据量的 Hive SQL ，也可能几秒钟就返回结果）。

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

1.3 数据仓库建模技术

从数据仓库概念诞生以来，在数据仓库领域，存在两种得到广泛认可的方法来构建数据仓库。这两派的代表人物分别是 Bill Inmon 和 Ralph Kimball, Bill Inmon 被称为“数据仓库之父”，而 Ralph Kimball 被称为“商业智能之父”。

从这两种观点诞生以来，围绕“哪种架构最佳”的争论一致没有休止，人们各抒己见，但是一直无法形成统的结论，就像“哪种编程语言是最佳的编程语言”一样，这可以称为数据仓库领域的“宗教战争” 。

1. Ralph Kimball 建模方法论

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

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

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

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

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

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

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

2. Bill Inmon 建模方法论

在数据仓库领域， Bill Inmon 是第一个提出来 OLAP 和数据仓库概念的人，所以被称为数据仓库之父” 。Bill Inmon 撰写了大量介绍其数据仓库方法的文章，他认为数据仓库是 “在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合”。

与其他数据库应用不同的是，数据仓库更像一种过程，对分布在企业内部各处的业务数据的整合加工和分析的过程，而不是一种可以购买的产品，这就是他所说的“企业信息化工厂”。

采用 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 ）等。