文章目录
19.1 传统数据处理系统存在的问题
1.传统数据库的数据过载问题
传统应用的数据系统架构设计时，应用直接访问数据库系统。当用户访问量增加时，数据库无法支撑日益增长的用户请求的负载，从而导致数据库服务器无法及时响应用户请求，出现超时的错误。关于这个问题的常用解决方法如下:
- (1)
增加异步处理队列，通过工作处理层批量处理异步处理队列中的数据修改请求。 - (2)
建立数据库水平分区，通常建立 Key 分区，以主键/唯一键 Hash 值作为 Key。 - (3)
建立数据库分片或重新分片，通常专门编写脚本来自动完成，且要进行充分测试。 - (4)
引入读写分离技术，主数据库处理写请求，通过复制机制分发至从数据库。 - (5)
引入分库分表技术，按照业务上下文边界拆分数据组织结构，拆分单数据库压力。
2.大数据的特点
大数据具有体量大、时效性强的特点，并非构造单调，而是类型多样; 处理大数据时，传统数据处理系统因数据过载，来源复杂，类型多样等诸多原因性能低下，需要采用以新式计算架构和智能算法为代表的新技术;大数据的应用重在发掘数据间的相关性，而非传统逻辑上的因果关系; 因 此，大数据的目的和价值就在于 发现新的知识，洞悉并进行科学决策。现代大数据处理技术，主要分为以下几种:
- (1)基于分布式文件系统 Hadoop。
- (2)使用 Map/Reduce 或 Spark 数据处理技术。
- (3)使用 Kafka 数据传输消息队列及 Avro 二进制格式。
3.大数据利用过程
大数据的利用过程分为: 采集、清洗、统计和挖掘 4 个过程。
19.2 大数据处理系统架构分析
19.2.1 大数据处理系统面临挑战
大数据处理系统面临的挑战主要有:
- 1)如何利用信息技术等手段处理非结构化和半结构化数据。
- 2)如何探索大数据复杂性、不确定性特征描述的刻画方法及大数据的系统建模。
- 3)数据异构性与决策异构性的关系对大数据知识发现与管理决策的影响。
19.2.2 大数据处理系统架构特征
大数据处理系统应具有的属性和特征包括: 鲁棒性和容错性、低延迟、横向扩展(通过增强机器性能扩展)、通用、可扩展、即席查询(用户按照自己的要求进行查询)、最少维护和可调试。
1.鲁棒性和容错性 (Robust and Fault-tolerant)：对于大规模的分布式系统来说，人和机器的错误每天都可能会 发生，如何应对人和机器的错误，让系统能够从错误中快速恢复尤其重要。
2.低延迟读取和更新能力 (Low Latency Reads and Updates)：许多应用程序要求数据系统拥有几毫秒到几百毫秒的低延迟读取和更新能力。有的应用程序允许几个小时的延迟更新，但是只要有低延迟读取与更新的需求，系统就应该在保证鲁棒性 的前提下实现。
3.横向扩容 (Scalable)：当数据量/负载增大时，可扩展性的系统通过增加更多的机器资源来维持性能。也就是常说的系统需要线性可扩展，通常采用scaleout(通过增加机器的个数)而不是scaleup(通过增 强机器的性能)。
4.通用性 (General) 系统需要支持绝大多数应用程序，包括金融领域、社交网络、电子商务数据分析等。
5.延展性 (Extensible) 在新的功能需求出现时，系统需要能够将新功能添加到系统中。同时，系统的大规模迁移能力是设计者需要考虑的因素之一，这也是可延展性的体现。
6.即席查询能力 (Allows Ad Hoc Queries) 用户在使用系统时，应当可以按照自己的要求进行即席查询 (Ad Hoc)。 这使用户可以通过系统多样化数据处理，产生更高的应用价值。
7.最少维护能力 (Minimal Maintenance) 系统需要在大多数时间下保持平稳运行。使用机制简单的组件和算法让系统底层拥有低复 杂度，是减少系统维护次数的重要途径。 Marz认为大数据系统设计不能再基于传统架构的增量 更新设计，要通过减少复杂性以减少发生错误的几率、避免繁重操作。
8.可调试性 (Debuggable)系统在运行中产生的每一个值，需要有可用途径进行追踪，并且要能够明确这些值是如何 产生的。
19.3 Lambda架构
19.3.1 Lambda架构对大数据处理系统的理解
Lambda 架构是 一种用于同时处理离线和实时数据的、可容错的、可扩展的分布式系统，它 具备强鲁棒性，提供低延迟和持续更新。
19.3.2 Lambda架构应用场景
1.机器学习中的Lambda架构
机器学习可以受益于由 Lambda架构构 建的数据系统、所处理的各类数据。据此，机器学习算法可以提出各种问题，并逐渐对输入到 系统中的数据进行模式识别。
2.物联网的 Lambda架构
如果说机器学习利用的是 Lambda 架构的输出，那么物联网则更多地作为数据系统的输入。
3.流处理和Lambda架构挑战
在实际应用中，由于实时处理流以毫秒为单位，持续产生用于更新视图的数据流，是一个 非常复杂的过程。因此，将基于文档的数据库、索引以及查询系统配合在一起使用，是一种比较好的选择。
19.3.3 Lambda架构介绍
Lambda 架构如图:
Lambda 架构分为以下 3 层:
- (1)
批处理层。该层核心功能是 存储主数据集，主数据集数据具有 原始、不可变、真实 的特征。批处理层周期性地将增量数据转储至主数据集，并在主数据集上执行批处理，生成批视图。架构实现方面可以使用 Hadoop HDFS 或 HBase 存储主数据集，再利用 Spark 或 MapReduce 执行周期批处理，之后使用 MapReduce 创建批视图。 - (2)
加速层。该层的核心功能是 处理增量实时数据，生成实时视图，快速执行即席查询。架构实现方面可以使用 Hadoop HDFS 或 HBase 存储实时数据，利用 Spark 或 Storm 实现实时数据处理和实时视图。 - (3)
服务层。该层的核心功能是 响应用户请求，合并批视图和实时视图中的结果数据集得到最终数据集。具体来说就是接收用户请求，通过索引加速访问批视图，直接访问实时视图，然后合并两个视图的结果数据集生成最终数据集，响应用户请求。架构实现方面可以使用 HBase 或 Cassandra 作为服务层，通过 Hive 创建可查询的视图。
19.3.4 Lambda架构的实现
如图，在这种Lambda架构实现中，Hadoop(HDFS) 用于存储主数据集，Spark(或 Storm) 可构成速度层 (Speed Layer)，HBase (或Cassandra) 作为服务层，由Hive创建可查询的视图。
Hadoop是被设计成适合运行在通用硬件上的分布式文件系统 (Distributed File System)。Apache Spark是专为大规模数据处理而设计的快速通用的计算引擎。HBase-Hadoop Database, 是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价 PCServer上搭建起大规模结构化存储集群。
19.3.5 Lambda架构优缺点
Lambda 架构的优点: 容错性好，查询灵活度高，弹性伸缩，易于扩展。
Lambda 架构的缺点: 编码量大，持续处理成本高，重新部署和迁移成本高。
19.3.6 Lambda与其他架构模式对比
Lambda架构的诞生离不开很多现有设计思想和架构的铺垫，如事件溯源 (Event Sourcing) 架构和命令查询职责分离 (Command Query Responsibility Segregation,CQRS) 架构， Lambda架构的设计思想和这两者有一定程度的相似。
1.事件溯源(Event Sourcing)本质上是一种数据持久化的方式，其由三个核心观点构成:
- (1)整个系统以事件为驱动，所有业务都由事件驱动来完成。
- (2)事件是核心，系统的数据以事件为基础，事件要保存在某种存储上。
- (3)业务数据只是一些由事件产生的视图，不一定要保存到数据库中。
Lambda架构中数据集的存储使用的概念与事件溯源中的思想完全一致，二者都是在使用统一的数据模型对数据处理事件本身进行定义。
2.CQRS架构分离了对于数据进行的读操作(查询)和写(修改)操作。其将能够改变数据模型状态的命令和对于模型状态的查询操作实现了分离。这是领域驱动设计 (Domain-Driven Design,DDD) 的一个架构模式，主要用来解决 数据库报表的输出处理方式。Lambda 架构中，数据的修改通过批处理和流处理实现，通过写操作将数据转换成查询时所对应的View。
19.4 Kappa架构
19.4.1 Kappa架构下对大数据处理系统的理解
为了设计出能满足前述的大数据关键特性的系统，我们需要对数据系统有本质性的理解。 我们可将数据系统简单理解为: 数据系统=数据+查询 进而从 数据和查询 两方面来认识大数据系统的本质。
1.数据的特性
数据是一个不可分割的单位，数据有两个关键的性质: When和 What。
- (1)When。When是指数据是与时间相关的，数据一定是在某个时间点产生的。
- (2)What。What 是指数据的本身。由于数据跟某个时间点相关，所以数据的本身是不可变的 (Immutable), 过往的数据已经成为事实 (Fact), 你不可能回到过去的某个时间点去改变数据事实。
2.数据的存储
Lamba架构中对数据的存储采用的方式是: 数据不可变， 存储所有数据。
19.4.2 Kappa架构介绍
Kappa 架构是在 Lambda 架构的基础上进行了优化，删除了 Batch Layer 的架构，将数据通道以消息队列进行替代。Kappa 架构本质上是 通过改进 Lambda 架构中的加速层，使它既能够进行实时数据处理， 同时也有能力在业务逻辑更新的情况下重新处理以前处理过的历史数据，如图：
Kappa 架构分为如下 2 层:
- (1)
实时层。该层核心功能是处理输入数据，生成实时视图。具体来说是采用流式处理引擎 逐条处理输入数据，生成实时视图。架构实现方式是采用 Apache Kafka 回访数据，然后采用 Flink 或 Spark Streaming 进行处理。 - (2)
服务层。该层核心功能是使用实时视图中的结果数据集响应用户请求。实践中使用数据 湖中的存储作为服务层。
19.4.3 Kappa架构的实现
下面以Apache Kafka为例来讲述整个全新架构的过程：部署 Apache Kafka, 并设置数据日志的保留期 (Retention Period)。 这里的保留期指的是你希望能够重新处理的历史数据的时间区间。例如：
- 如果你希望重新处理最多一年的历史数据， 那就可以把Apache Kafka中的保留期设置为365天。
- 如果你希望能够处理所有的历史数据，那就可以把 Apache Kafka 中的保留期设置为“永久 (Forever)”。
- 如果我们需要改进现有的逻辑算法，那就表示我们需要对历史数据进行重新处理。
19.4.4 Kappa架构的优缺点
Kappa 架构的优点是 将离线和实时处理代码进行了统一，方便维护。避免了 Lambda架构中与离线数据合并的问题，查询历史数据的时候只需要重放存储的历史数据即可 。
缺点是 消息中间件有性能瓶颈、数据关联时处理开销大、抛弃了离线计算的可靠性。
19.4.5 常见Kappa架构变形
Kappa 架构常见变形是
1、Kappa+架构，如图 ：
Kappa+是Uber提出流式数据处理架构，它的核心思想是 让流计算框架直接读HDFS里的数据仓库数据，一并实现实时计算和历史数据backfll计算，不需要为backfll作业长期保存日志或者把数据拷贝回消息队列。
2、混合分析系统 Kappa 架构，如图：
在基于使用Kafka +Flink构建Kappa流计算数据架构，针对Kappa架构分析能力不足的问题，再利用Kafka对接组合 Elastic- Search 实时分析引擎，部分弥补其数据分析能力。但是ElasticSearch也只适合对合理数据量级的热点数据进行索引，无法覆盖所有批处理相关的分析需求，这种混合架构某种意义上属于Kappa和Lambda间的折中方案。
19.5 Lambda架构与Kappa架构的对比和设计选择
19.5.1 Lambda架构与Kappa架构的特性对比
Lambda 架构与 Kappa 架构的对比，见表：
| 对比内容 | Lambda 架构 | Kappa 架构 |
|---|---|---|
| 复杂度与开发维护成本 | 维护两套系统(引擎)，复杂度高，成本高 | 维护一套系统(引擎)，复杂度低，成本低 |
| 计算开销 | 周期性批处理计算，持续实时计算计算开销大 | 必要时进行全量计算，计算开销相对较小 |
| 实时性 | 满足实时性 | 满足实时性 |
| 历史数据处理能力 | 批式全量处理，吞吐量大；历史数据处理能力强；批视图与实时视图存在冲突可能 | 流式全量处理，吞吐量相对较低 历史数据处理能力相对较弱 |
对于两种架构设计的选择可以从以下 4 个方面考虑，见表
19.5.2 Lambda架构与Kappa架构的设计选择
对于两种架构设计的选择可以从以下 4 个方面考虑，见表
| 设计考虑 | Lambda 架构 | Kappa 架构 |
|---|---|---|
| 业务需求与技术要求 | 依赖 Hadoop、Spark、Storm 技术 | 依赖 Flink 计算引擎，偏流式计算 |
| 复杂度 | 实时处理和离线处理结果可能不一致 | 频繁修改算法模型参数 |
| 开发维护成本 | 成本预算充足 | 成本预算有限 |
| 历史数据处理能力 | 频繁使用海量历史数据 | 仅使用小规模数据集 |
19.6 大数据架构设计案例分析
19.6.1 Lambda架构在某网奥运中的大数据应用
某网采用以 Lambda 架构搭建的大数据平台处理里约奥运会大规模视频网络观看数据，具体平台架构设计如图 ：
对于图中的数据计算层可以分为 离线计算、实时计算、合并计算 3 个部分。
- (1)
离线计算部分: 用于存储持续增长的批量离线数据，并且会周期性地使用 Spark 和 Map/Reduce 进行批处理，将批处理结果更新到批视图之后使用 Impala 或者 Hive 建立数据仓库， 将结果写入 HDFS 中。 - (2)
实时计算部分: 采用 Spark Streaming，只处理实时增量数据，将处理后的结果更新到实时视图。 - (3)
合并计算部分: 合并批视图和实时视图中的结果，生成最终数据集，将最终数据集写入 HBase 据库中用于响应用户的查询请求。
19.6.2 Lambda架构在某网广告平台的应用与演进
某网基于 Lambda 架构的广告平台，分为 批处理层(Batch Layer)、加速层(Speed Layer)、服 务层(Serving Layer)，某网广告平台 Lambda 架构如图：
实时处理过程如下:
(1)批处理层: 每天凌晨将 Kafka 中浏览、下单等消息同步到 HDFS 中，将 HDFS 中数据解析为 Hive 表，然后使用 HQL 或 Spark SQL 计算分区统计结果 Hive 表，将 Hive 表转储到 MySQL 中作为批视图。
(2)加速层: 使用 Spark Streaming 实时监听 Kafka 下单、付款等消息，计算每个追踪链接维度的实时数据，将实时计算结果存储在 Redis 中作为实时视图。
(3)服务层: 采用 Java Web 服务，对外提供 HTTP 接口，Java Web 服务读取 MySQL 批视图表和 Redis 实时视图表。
19.6.3 某证券公司大数据系统
某证券公司智能决策大数据系统是一个基于 Kappa 架构的实时日志分析平台，如图：
具体的实时处理过程如下:
(1)日志采集: 用统一的数据处理引擎 Filebeat 实时采集日志并推送给 Kafka 缓存。
(2)日志清洗解析: 利用基于大数据计算集群的 Flink 计算框架实时读取 Kafka 消息并进行清洗，解析日志文本转换成指标。
(3)日志存储: 日志转储到 ElasticSearch 日志库，指标转储到 OpenTSDB 指标库。
(4)日志监控: 单独设置告警消息队列，保持监控消息时序管理和实时推送。
19.6.4 某电商智能决策大数据系统
该智能决策大数据平台基于 Kappa 架构，使用统一的数据处理引擎 Funk 可实时处理流数据，并将其存储到数据仓库工具 Hive 与分布式缓存 Tair 中，以供后续决策服务的使用。如图：
实时处理的过程如下:
(1)数据采集: B 端实时采集用户点击、下单、广告曝光、出价等数据然后推送给 Kafka 缓存。
(2)数据清洗聚合: 由 Flink 实时读取 Kafka 消息，按需过滤参与业务需求的指标，将聚合时间段的数据转换成指标。
(3)数据存储: Flink 将计算结果转储至 Hive 日志库，将模型需要的参数转储至实时计算数据库 Tair 缓存，然后后续决策服务从 Tair 中获取数据进行模型训练。
