第19章大数据架构设计理论与实践

19.1 传统数据处理系统存在的问题

海量数据的，数据库过载，增加消息队列、甚至数据分区、读写分离、以及备份以及传统架构的性能的压榨式提升，都没有太明显的效果，帮助处理海量数据的新技术和新架构开发被提上日程。

19.2 大数据处理系统架构分析

19.2.1 大数据处理系统面临挑战

1.如何利用信息技术等手段处理非结构化和半结构化数据

结构化数据只占15??右，其余的85??是非结构化的数据，也许有90??数据来自开源数据，其余的被存储在数据库中。

如果把通过数据挖掘提取“粗糙知识”的过程称为“一次挖掘”过程，那么将粗糙知识与被量化后主观知识，包括具体的经验、常识、本能、情境知识和用户偏好，相结合而产生“智能知识”过程就叫作“二次挖掘”。从“一次挖掘”到“二次挖掘”,就类似于事物由“量”到“质”的飞跃。

由于大数据所具有的半结构化和非结构化特点，基于大数据的数据挖掘所产生的结构化的“粗糙知识”(潜在模式)也伴有一些新的特征。这些结构化的粗糙知识可以被主观知识加工处理并转化，生成半结构化和非结构化的智能知识。寻求“智能知识”反映了大数据研究的核心价值。

2.如何探索大数据复杂性、不确定性特征描述的刻画方法及大数据的系统建模

这一问题的突破是实现大数据知识发现的前提和关键。大数据的复杂形式导致许多对“粗糙知识”的度量和评估相关的研究问题。已知的最优化、数据包络分析、期望理论、管理科学中的效用理论可以被应用到研究如何将主观知识融合到数据挖掘产生的粗糙知识的“二次挖掘”过程中。这里人机交互将起到至关重要的作用。

3.数据异构性与决策异构性的关系对大数据知识发现与管理决策的影响

"数据异构性” 和“决策异构性”。通过寻找“二次挖掘”产生的“智能知识”来作为数据异构性和决策异构性之间的桥梁是十分必要的。

19.2.2 大数据处理系统架构特征

1.鲁棒性和容错性(Robust and Fault-tolerant)

对于大规模的分布式系统来说，人和机器的错误每天都可能会发生，如何应对人和机器的错误，让系统能够从错误中快速恢复尤其重要。

2.低延迟读取和更新能力(Low Latency Reads and Updates)

许多应用程序要求数据系统拥有几毫秒到几百毫秒的低延迟读取和更新能力。有的应用程序允许几个小时的延迟更新，但是只要有低延迟读取与更新的需求，系统就应该在保证鲁棒性的前提下实现。

3.横向扩容(Scalable)

当数据量/负载增大时，可扩展性的系统通过增加更多的机器资源来维持性能。也就是常说的系统需要线性可扩展，通常采用scale out(通过增加机器的个数)而不是scale up(通过增强机器的性能)。

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架构由Storm的作者Nathan Marz提出，其设计目的在于提供一个能满足大数据系统关键特性的架构，包括高容错、低延迟、可扩展等。其整合离线计算与实时计算，融合不可变性、读写分离和复杂性隔离等原则，可集成Hadoop、Kafka、Spark、Storm等各类大数据组件。

Lambda是用于同时处理离线和实时数据的，可容错的，可扩展的分布式系统。

它具备强鲁棒性，提供低延迟和持续更新。

19.3.2 Lambda架构应用场景

1.机器学习中的Lambda架构

在机器学习领域，数据量无疑是多多益善的。但是，对于机器学习应用算法、检测模式而言，它们需要以一种有意义的方式去接收数据。因此，机器学习可以受益于由Lambda架构构建的数据系统、所处理的各类数据。据此，机器学习算法可以提出各种问题，并逐渐对输入到系统中的数据进行模式识别。

2.物联网的Lambda架构

如果说机器学习利用的是Lambda架构的输出，那么物联网则更多地作为数据系统的输入。

设想一下，一个拥有数百万辆汽车的城市，每辆汽车都装有传感器，并能够发送有关天气、空气质量、交通状况、位置信息以及司机驾驶习惯等数据。这些海量数据流，会被实时馈入Lambda体系架构的批处理层和速度层，进行后续处理。可以说，物联网设备是适合作为大数据源的绝佳示例。

3.流处理和Lambda架构挑战

速度层也被称为“流处理层”。其目的是提供最新数据的低延迟实时视图。虽说，速度层仅关心自完成最后一组批处理视图以来导入的数据，但事实上它不会存储这些小部分的数据。这些数据在流入时就会被立即处理，且在完成后被立即丢弃。因此，我们可以认为这些数据是尚未被批处理视图所计入的数据。

Lambda体系架构在其原始理论中，提到了最终精度(eventual accuracy)的概念。它是指：

批处理层更关注精确计算，而速度层则关注近似计算。此类近似计算最终将由下一组视图所取

代，以便系统向“最终精度”迈进。

在实际应用中，由于实时处理流以毫秒为单位，持续产生用于更新视图的数据流，是一个非常复杂的过程。因此，将基于文档的数据库、索引以及查询系统配合在一起使用，是一种比较好的选择。

19.3.3 Lambda架构介绍

如图19-4所示，Lambda架构可分解为三层，即批处理层、加速层和服务层。

(1)批处理层(Batch Layer):存储数据集，Batch Layer在数据集上预先计算查询函数，并构建查询所对应的View。Batch Layer可以很好地处理离线数据，但有很多场景数据是不断实时生成且需要实时查询处理，对于这种情况，Speed Layer更为适合。
(2)加速层(Speed Layer):Batch Layer处理的是全体数据集，而Speed Layer处理的是最近的增量数据流。Speed Layer为了效率，在接收到新的数据后会不断更新Real-time View,而Batch Layer是根据全体离线数据集直接得到Batch View。
(3)服务层(Serving Layer):Serving Layer用于合并Batch View和Real-time View中的结果数据集到最终数据集。

1.批处理层

该层负责管理主数据集。Batch Layer有两个核心功能：存储数据集和生成Batch View。Batch Layer可以很好地处理离线数据。

主数据集中的数据必须具有以下三个属性：

(1)数据是原始的。

(2)数据是不可变的。

(3)数据永远是真实的。

monoid（定义：一个类型，具有二元操作（满足结合律），具有一个单位元元素）。Monoid特性的函数应用非常广泛，其一个重要特性是满足结合律。

Monoid的结合律特性在分布式计算中极其重要，满足Monoid特性意味着我们可以将计算分解到多台机器并行运算，然后再结合各自的部分运算结果得到最终结果。同时也意味着部分运算结果可以储存下来被别的运算共享利用(如果该运算也包含相同的部分子运算),从而减少重复运算的工作量。图19-5展示了Monoid特性。

如果预先在数据集上计算并保存查询函数的结果，查询的时候就可以直接返回结果(或通过简单的加工运算就可得到结果)而无需重新进行完整费时的计算了。 这里可以把Batch Layer看成是一个数据预处理的过程，如图19-6所示。我们把针对查询预先计算并保存的结果称为View,View是Lamba架构的一个核心概念，它是针对查询的优化，通过View即可以快速得到查询结果。

Batch Layer需要做的一件重要的工作就是根据业务的需求，考察可能需要的各种查询，根据查询定义其在数据集上对应的Views。

2.加速层

对加速层批处理视图建立索引，便于能快速进行即席查询(Ad Hoc Queries)。它存储实时视图并处理传入的数据流，以便更新这些视图。

Batch Layer可以很好地处理离线数据，但有很多场景数据不断实时生成，并且需要实时查询处理。Speed Layer正是用来处理增量的实时数据。

Speed Layer和Batch Layer比较类似。如图19-7所示，Speed Layer对数据进行计算并生成 Realtime View,其主要区别在于：

(1)Speed Layer处理的数据是最近的增量数据流，Batch Layer处理的全体数据集。

(2)Speed Layer为了效率，接收到新数据时不断更新Realtime View,而Batch Layer根据全体离线数据集直接得到Batch View。

Lambda架构将数据处理分解为Batch Layer和Speed Layer有如下优点：

●容错性。Speed Layer中处理的数据也不断写入Batch Layer,当Batch Layer中重新计算的数据集包含Speed Layer处理的数据集后，当前的Real-time View就可以丢弃，这也就意味着Speed Layer处理中引入的错误，在Batch Layer重新计算时都可以得到修正。这一点也可以看成是CAP理论中的最终一致性(Eventual Consistency)的体现。

●复杂性隔离。Batch Layer处理的是离线数据，可以很好地掌控。Speed Layer采用增量算法处理实时数据，复杂性比Batch Layer要高很多。通过分开Batch Layer和Speed Layer,把复杂性隔离到Speed Layer,可以很好地提高整个系统的鲁棒性和可靠性。

● Scalable(横向扩容):当数据量/负载增大时，可扩展性的系统通过增加更多的机器资源来维持性能。也就是常说的系统需要线性可扩展，通常采用scale out(通过增加机器的个数)而不是scaleup(通过增强机器的性能)。

CAP理论，指的是在一个分布式系统中，Consistency(一致性)、Availability(可用性)、Partition Tolerance(分区容错性)，不能同时成立.

3.服务层

Lambda架构的Serving Layer用于响应用户的查询请求，合并Batch View和Real-time View中的结果数据集到最终的数据集。该层提供了主数据集上执行的计算结果的低延迟访问。读取速度可以通过数据附加的索引来加速。与加速层类似，该层也必须满足以下要求，例如随机读取，批量写入，可伸缩性和容错能力。

这涉及数据如何合并的问题。前面我们讨论了查询函数的Monoid性质，如果查询函数满足Monoid性质，即满足结合率，只需要简单地合并Batch View和Real-time View中的结果数据集即可。否则，可以把查询函数转换成多个满足Monoid性质的查询函数的运算，单独对每个满足Monoid性质的查询函数进行Batch View和Real-time View中的结果数据集合并，然后再计算得到最终的结果数据集。另外也可以根据业务自身的特性，运用业务自身的规则来对Batch View和Real-time View中的结果数据集合并，如图19-8所示。

19.3.4 Lambda架构的实现

如图19-9所示，在这种Lambda架构实现中，Hadoop(HDFS)用于存储主数据集，Spark(或Storm)可构成速度层(Speed Layer),HBase(或Cassandra)作为服务层，由Hive创建可查询的视图。

Hadoop是被设计成适合运行在通用硬件上的分布式文件系统(Distributed File System)。它和现有的分布式文件系统有很多共同点。但同时，它和其他分布式文件系统的区别也很明显。HDFS是一个具有高度容错性的系统，能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一些约束，以达到流式读取文件系统数据的目的。

Apache Spark是专为大规模数据处理而设计的快速通用的计算引擎。Spark是UC Berkeley AMP lab所开源的类Hadoop Map Reduce的通用并行处理框架，Spark拥有Hadoop Map Reduce所具有的优点；但不同于Map Reduce的是——Job中间输出结果可以保存在内存中，从而不再需要读写HDFS,因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的Map Reduce算法。

HBase-Hadoop Database,是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。

19.3.5 Lambda架构优缺点

1.优点

(1)容错性好。Lambda架构为大数据系统提供了更友好的容错能力，一旦发生错误，我们可以修复算法或从头开始重新计算视图。

(2)查询灵活度高。批处理层允许针对任何数据进行临时查询。

(3)易伸缩。所有的批处理层、加速层和服务层都很容易扩展。因为它们都是完全分布式的系统，我们可以通过增加新机器来轻松地扩大规模。

(4)易扩展。添加视图是容易的，只是给主数据集添加几个新的函数。

2.缺点

(1)全场景覆盖带来的编码开销。

(2)针对具体场景重新离线训练一遍益处不大。

(3)重新部署和迁移成本很高。

19.3.6 Lambda与其他架构模式对比

Lambda架构的诞生离不开很多现有设计思想和架构的铺垫，如事件溯源(Event Sourcing)

架构和命令查询分离(Command Query Responsibility Segregation,CQRS)架构，Lambda架构

的设计思想和这两者有一定程度的相似。

1.事件溯源(Event Sourcing)与Lambda架构

Event Sourcing架构模式由Thought Works的首席科学家Martin Flower提出。Event Sourcing本质上是一种数据持久化的方式，其由三个核心观点构成：

(1)整个系统以事件为驱动，所有业务都由事件驱动来完成。
(2)事件是核心，系统的数据以事件为基础，事件要保存在某种存储上。
(3)业务数据只是一些由事件产生的视图，不一定要保存到数据库中。

Lambda架构中数据集的存储使用的概念与Event Sourcing中的思想完全一致，二者都是在使用统一的数据模型对数据处理事件本身进行定义。这样在发生错误的时候，能够通过模型找到错误发生的原因，对这一事件进行重新计算以丢弃错误信息，恢复到系统应该的正确状态，以此实现了系统的容错性。

2.CQRS与Lambda架构

CQRS架构分离了对于数据进行的读操作(查询)和写(修改)操作。其将能够改变数据模型状态的命令和对于模型状态的查询操作实现了分离。这是领域驱动设计(Domain-Driven Design,DDD)的一个架构模式，主要用来解决数据库报表的输出处理方式。

Lambda架构中，数据的修改通过批处理和流处理实现，通过写操作将数据转换成查询时所对应的View。在Lambda架构中，对数据进行查询时，实际上是通过读取View直接得到结果，读出所需的内容。这实际上是一种形式的读写分离。

进行读写分离设计的原因是，读操作实际上比写操作要省时得多，如果将读和写操作放在一起，实际处理大量数据时会因为写操作的时长问题影响整体业务的处理效率。在大数据系统中经常处理海量数据，进行读写分离重要性不言而喻。

19.4 Kappa架构

19.4.1 Kappa架构下对大数据处理系统的理解

为了设计出能满足前述的大数据关键特性的系统，我们需要对数据系统有本质性的理解。

我们可将数据系统简单理解为： 数据系统=数据+查询

进而从数据和查询两方面来认识大数据系统的本质。

1.数据的特性

我们先从数据的特性谈起。数据是一个不可分割的单位，数据有两个关键的性质：When和What。

(1)When。

When是指数据是与时间相关的，数据一定是在某个时间点产生的。

数据的时间性质决定了数据的全局发生先后，也就决定了数据的结果。

(2)What。

hat是指数据的本身。由于数据跟某个时间点相关，所以数据的本身是不可变的(Immutable),过往的数据已经成为事实(Fact),你不可能回到过去的某个时间点去改变数据事实。这也就意味着对数据的操作其实只有两种：读取已存在的数据和添加更多的新数据。采用数据库的记法，CRUD就变成了CR,Update和Delete本质上其实是新产生的数据信息，用C来记录。

2.数据的存储

根据上述对数据本质特性的分析，Lamba架构中对数据的存储采用的方式是：数据不可变，存储所有数据。

通过采用不可变方式存储所有的数据，可以有如下好处：

(1)简单。

(2)应对人为和机器的错误。

19.4.2 Kappa架构介绍

Kappa架构由Jay Kreps提出，不同于Lambda同时计算流计算和批计算并合并视图，Kappa只会通过流计算一条的数据链路计算并产生视图。Kappa同样采用了重新处理事件的原则，对于历史数据分析类的需求，Kappa要求数据的长期存储能够以有序日志流的方式重新流入流计算引擎，重新产生历史数据的视图。本质上是通过改进Lambda架构中的Speed Layer,使它既能够进行实时数据处理，同时也有能力在业务逻辑更新的情况下重新处理以前处理过的历史数据。

Kappa架构的原理就是：

在Lambda的基础上进行了优化，删除了Batch Layer的架构，将数据通道以消息队列进行替代。因此对于Kappa架构来说，依旧以流处理为主，但是数据却在数据湖层面进行了存储，当需要进行离线分析或者再次计算的时候，则将数据湖的数据再次经过消息队列重播一次则可。

Kappa数据处理架构如图19-10所示。

如图19-10所示，输入数据直接由实时层的实时数据处理引擎对源源不断的源数据进行处理，再由服务层的服务后端进一步处理以提供上层的业务查询。而中间结果的数据都是需要存储的，这些数据包括历史数据与结果数据，统一存储在存储介质中。

Kappa方案的优缺点：

Kappa方案通过精简链路解决了数据写入和计算逻辑复杂的问题，但它依然没有解决存储和展示的问题，特别是在存储上，使用类似Kafka的消息队列存储长期日志数据，数据无法压缩，存储成本很大，绕过方案是使用支持数据分层存储的消息系统(如Pulsar,支持将历史消息存储到云上存储系统),但是分层存储的历史日志数据仅能用于Kappa backfil作业，数据的利用率依然很低。

从使用场景上来看，Kappa架构与Lambda相比，主要有两点区别：

(1)Kappa不是Lambda的替代架构，而是其简化版本，Kappa放弃了对批处理的支持，更擅长业务本身为增量数据写入场景的分析需求，例如各种时序数据场景，天然存在时间窗口的概念，流式计算直接满足其实时计算和历史补偿任务需求；

(2)Lambda直接支持批处理，因此更适合对历史数据分析查询的场景，比如数据分析师需要按任意条件组合对历史数据进行探索性的分析，并且有一定的实时性需求，期望尽快得到分析结果，批处理可以更直接高效地满足这些需求。