二、实时数据平台的架构、技术和设计
离线数据平台产出数据的周期一般是天，也就是说，今天看到的是昨天的数据，对于大部分的分析和“看”数据的场景来说，这种 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 等，我们需要对这些反面保持一定的关注并积极拥抱这些技术。
生命不是要超越别人，而是要超越自己。
