前言
接着上一章 构建大数据开发知识体系图谱，本次继续分享邦中老师的《离线和实时大数据开发实战》读书笔记 。到底什么样的平台才能算是大数据平台呢？带着这个问题，我们开始今天的内容 ( •̀ ω •́ )✧
什么是数据平台呢？或者更时髦点，什么是大数据平台呢？目前业界并没有对数据平台的精确定义，但通常所说的数据平台主要包含以下三部分：
- 数据相关的工具、产品和技术：比如批量数据采集传输的 Sqoop 、离线数据处理 Hadoop 和 Hive 、实时流处理的 Storm、Spark 以及数据分析的 R 等；
- 数据资产：不仅包含公司业务本身产生和沉淀的数据，还包括公司运作产生的数（如财务、行政），以及从外界购买、交换或者爬虫等而来的数据等；
- 数据管理：有了数据工具，也有了数据资产，但是还必须对它们进行管理才能让数据产生最大价值并最小化风险，因此数据平台通常还包括数据管理的相关概念和技术，如数据仓库、数据建模、数据质量、数据规范、数据安全和元数据管理等。
上面是对数据平台逻辑范畴上的一个划分，实际上数据平台从数据处理的时效性角度，通常还是分为 离线数据平台 和 实时数据平台。
-
离线数据平台通常以天为典型的数据处理周期，数据延迟也是以天为单位。离线数据平台的数据应用主要以“看”为主，就目前业界的数据现状来看，离线数据平台还是数据平台的主战场。
-
但是随着大数据应用的日益深入以及人工智能浪潮的兴起，产品的智能化趋势越来越明显，数据的实时化、在线化也对数据平台的实时性提出了越来越高的要求，从刚开始分钟级别延迟到目前的秒级甚至毫秒级延迟，实时数据平台越来越得到重视，挑战也越越大，当然也变得越来越主流，随着 Spark、Flink、Beam 技术的发展，未来有一天也许将会颠覆离线数据平台的技术和架构。
接下来就是介绍数据平台，出于逻辑清晰以及技术相关性考虑，将主要从 离线数据平台、实时数据平台以及数据管理 三个方面来对数据平台相关的概念和技术进行介绍。
一、离线数据平台的架构、技术和设计
对于公司的管理者、一线业务人员来说，经常需要回答的问题是：当前和过去 个季度或者一个月的销售趋势如何？哪些商品热销？哪些商品销售不佳？哪些客户在买我们的产品？管理者和业务人员需要不停地监控这些业务指标，并有针对性地根据这些指标调整业务策略和打法，如此反复，形成闭环，这就是数据化运营的基本思路。
而这类分析和“看”的需求正是离线数据平台所擅长的，这类分析性的需求，数据的时效性并不是强需求，当天的数据有了也好，即使没有，影响也不大，离线的数据技术和工具已经发展很多年了，开源的解决方案和商业性的解决方案也有很多，已经能够很成熟地解决此类问题。
离线数据平台是构建公司和企业数据平台的根本和基础，也是目前数据平台的主战场。
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 数据一般只需要处理数据查询请求，数据都是批量导入的，因此通过列存储、列压缩和位图索引等技术可以大大加快响应请求的速度。
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 维度建模的主题以星形架构为主，主题和主题之间则用一致性维度和企业总线体系架构来保证数据仓库的集成和一致性。
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 的数字加上“.”组成的。
准确性：准确性是指数据记录的信息是否存在异常或错误，是否符合业务预期。
及时性：及时性是指数据的产出时间是否及时 准时，符合预期。
3.4 数据屏蔽
数据仓库存储了企业的所有数据，其中有些数据是非常敏感的，比如用户的信用卡信息、身份证信息等 。这些信息如果泄露，将会给企业或者公司带来灾难性的后果；但是这些信息如果完全排除，又会对开发测试和分析统计等带来影响。
数据屏蔽（ data masking ）就是关于对数据如何进行不可逆的处理，使得处理后的数据既能被开发测试和分析统计使用，又不会泄露任何信息的过程。常用的办法如：加密、替换、删除／加扰 等。
四、小结
今天主要介绍了数据平台的内容范畴，我们分别从离线和实时两方面学习数据平台的架构、主要概念和技术。
离线数据平台是目前数据平台的主战场，相关的概念技术（如数据仓库、维度建模、逻辑分层、 Hadoop 和 Hive 等）都比较成熟并已广泛应用于各个公司。
实时数据平台随着数据时效性和人工智能的兴起，越来越得到重视并被放在战略地位，实时数据平台的有关技术也在不停地发展和完善，如 Storm 、Flink 和 Beam 等，我们需要对这些反面保持一定的关注并积极拥抱这些技术。
生命不是要超越别人，而是要超越自己。
我是云祁，我们下期再见。
