大数据处理系统架构特征

鲁棒性和容错性
低延迟读取和更新能力
横向扩容
通用性
延展性
即席查询能力
最少维护能力
可调试性

Lambda架构

Lambda架构由 Storm 的作者 Nathan Marz提出，
其设计目的在于提供一个能满足大数据系统关键特性的架构，包括高容错、低延迟、可扩展等。
其整合 离线计算 与 实时计算，融合不可变性、读写分离和复杂性隔离等原则，
可集成 Hadoop、Kafka、Spark、Storm等各类大数据组件。
Lambda 是用于同时处理 离线 和 实时数据的，可容错的，可扩展的分布式系统。
它具备强鲁棒性，提供低延迟和持续更新。

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中的结果数据集到最终数据集。

Lambda架构实现

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

Lambda架构优缺点

优点

• (1) 容错性好。 Lambda 架构为大数据系统提供了更友好的容错能力，一旦发生错误，我们可以修复算法或从头开始重新计算视图。
• (2) 查询灵活度高。批处理层允许针对任何数据进行临时查询。
• (3) 易伸缩。所有的批处理层、加速层和服务层都很容易扩展。因为它们都是完全分布式的系统，我们可以通过增加新机器来轻松地扩大规模。
• (4) 易扩展。添加视图是容易的，只是给主数据集添加几个新的函数。

缺点

• (1) 全场景覆盖带来的编码开销。
• (2) 针对具体场景重新离线训练一遍益处不大。
• (3) 重新部署和迁移成本很高。

Lambda架构与其他架构模式对比

• 事件溯源 - 数据集的存储：存储所有数据，支持根据历史数据 重新计算 恢复正确状态（容错性）
• CQRS - 读写分离，通过流、批处理进行写，通过view进行读

Kappa架构

数据系统=数据+查询
数据的特性：When（时间点）、What（不可变、CRUD变成CR添加和读取）
数据的存储：数据不可变、存储所有数据

Kappa架构介绍

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

Kappa架构实现

Kappa架构优缺点

优点

• 在于将实时和离线代码 统一 起来，方便维护而且统一了数据口径的问题，
• 避免了 Lambda架构中与离线 数据合并 的问题，查询历史数据的时候只需要重放存储的历史数据即可。

缺点

• (1) 消息中间件缓存的数据量和回溯数据有性能瓶颈。通常算法需要过去180天的数据，如果都存在消息中间件，无疑有非常大的压力。同时，一次性回溯订正180天级别的数据，对实时计算的资源消耗也非常大。
• (2) 在实时数据处理时，遇到大量不同的实时流进行关联时，非常依赖实时计算系统的能力，很可能因为数据流先后顺序问题，导致数据丢失。
• (3) Kappa 在抛弃了离线数据处理模块的时候，同时抛弃了离线计算更加稳定可靠的特点。Lambda 虽然保证了离线计算的稳定性，但双系统的维护成本高且两套代码带来后期运维困难。

对于以上Kappa框架存在的几个问题，目前也存在一些解决方案，

• 对于消息队列缓存数据性能的问题， Kappa+框架 提出使用HDFS来存储中间数据。
• 针对 Kappa 框架展示层能力不足的问题，也有人提出了 混合分析系统 的解决方案。

常见Kappa架构变形（Kappa+、混合分析系统）

Kappa+架构

Kappa+是 Uber提出流式数据处理架构，
它的核心思想是让流计算框架 直接读 HDFS里的数据仓库数据，
一并实现实时计算和历史数据 backfll 计算，不需要为 backfll 作业长期保存日志或者把数据拷贝回消息队列。

Kappa+ 将数据任务分为 无状态任务和 时间窗口任务。

Uber开发了 Apache hudi 框架 来存储数据仓库数据，
hudi 支持更新、删除已有parquet数据，
也支持增量消费数据更新部分，
从而系统性解决了问题2存储的问题。

图19-11是完整的Uber大数据处理平台，其中Hadoop→ Spark →用户查询 的流程涵盖了Kappa+数据处理架构。

将不同来源的数据通过 Kafka 导入到Hadoop 中，
通过HDFS来存储中间数据，
再通过 spark对数据进行分析处理，
最后交由上层业务进行查询。

混合分析系统的Kappa架构

Lambda和 Kappa架构都还有展示层的困难点，结果视图如何支持热点数据查询分析，
一个解决方案是在 Kappa基础上衍生数据分析流程。

如图19-12所示，在基于使用 Kafka +Flink 构 建 Kappa 流计算数据架构， 针对Kappa架构分析能力不足的问题，
再利用 Kafka对接组合 Elastic-Search 实时分析引擎，部分弥补其数据分析能力。
但是 ElasticSearch 也只适合对合理数源数量级的热点数据进行索引，无法覆盖所有批处理相关的分析需求，
这种混合架构某种意义上属于 Kappa和 Lambda间的折中方案。

Lambda与Kappa架构对比

Lambda架构

• 批处理：Hadoop -> Hbase
• 流处理：Spark、Storm -> Redis

Kappa架构

• Kafka作为消息中间件，将数据保持在消息队列中
• 流式计算：Flink，其作为新兴的流处理框架，以数据并行和流水线方式执行任意流数据程序，且同时支持批处理和流处理。

Spark	Flink
微批处理	流处理（无界流）
批处理	有界流

Lambda与Kappa架构选型

考虑因素	详细说明
业务需求 与 技术需求	- 用户需要根据自己的业务需求来选择架构， - 如果业务对于 Hadoop、Spark、Strom 等关键技术有强制性依赖，选择 Lambda 架构可能较为合适； - 如果处理数据偏好于流式计算，又依赖Flink 计算引擎，那么选择 Kappa架构可能更为合适。
复杂度	- 频繁修改， Lambda 架构需要反复修改两套代码，则显然不如 Kappa架构简单方便。 - 同时支持批处理和流式计算，或者希望用一份代码进行数据处理，那么可以选择Kappa 架构。 - 实时处理和离线处理的结果不能统一，比如某些机器学习的预测模型，需要先通过离线批处理得到训练模型，再交由实时流式处理进行验证测试，那么这种情况下，批处理层和流处理层不能进行合并，因此应该选择Lambda架构。
开发维护成本	- Lambda架构需要有一定程度的开发维护成本，包括两套系统的开发、部署、测试、维护，适合有足够经济、技术和人力资源的开发者。 - 而Kappa 架构只需要维护一套系统，适合不希望在开发维护上投入过多成本的开发者。
历史数据处理能力	- 频繁接触海量数据集进行分析，比如过往十年内的地区降水数据等，这种数据适合批处理系统进行分析，应该选择Lambda架构。 - 如果始终使用小规模数据集，流处理系统完全可以使用，则应该选择 Kappa架构。

案例分析

---

---

---

术语

即席查询(Ad Hoc)
即席查询（Ad Hoc）是用户根据自己的需求，灵活的选择查询条件，系统能够根据用户的选择生成相应的统计报表。即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的，而即席查询是由用户自定义查询条件的。

AD-HOC ：以单独的SQL语句的形式执行的查询就是即席查询，比如说：在C#程序里嵌入的SQL语句，或者在SSMS里的新建查询窗口自己键入的SQL代码就是即席查询。

而将SQL代码放入存储过程里面，以存储过程或者函数或者触发器来执行的查询就不是即席查询，即席：当场，就是当场去查询。

即席查询是指那些用户在使用系统时，根据自己当时的需求定义的查询。即席查询生成的方式很多，最常见的就是使用即席查询工具。一般的数据展现工具都会提供即席查询的功能。通常的方式是，将数据仓库中的维度表和事实表映射到语义层，用户可以通过语义层选择表，建立表间的关联，最终生成SQL语句。即席查询与通常查询从SQL语句上来说，并没有本质的差别。它们之间的差别在于，通常的查询在系统设计和实施时是已知的，所有我们可以在系统实施时通过建立索引、分区等技术来优化这些查询，使这些查询的效率很高。而即席查询是用户在使用时临时生产的，是一种松散类型的命令/查询，其值取决于某个变量，每次执行命令时，结果都不同，这取决于变量的值。它不能预先确定，通常属于动态编程SQL查询。临时查询是短期的，并且是在运行时创建的。系统无法预先优化这些查询，所以即席查询也是评估数据仓库的一个重要指标。

即席查询的位置通常是在关系型的数据仓库中，即在EDW或者ROLAP中。多维数据库有自己的存储方式，对即席查询和通常查询没有区别。在一个数据仓库系统中，即席查询使用的越多，对数据仓库的要求就越高，对数据模型的对称性的要求也越高。对称性的数据模型对所有的查询都是相同的，这也是维度建模的一个优点。

资料来源：
Ad Hoc Query https://www.techopedia.com/definition/30581/ad-hoc-query-sql-programming
What is an Ad Hoc Query? https://www.wisegeek.com/what-is-an-ad-hoc-query.htm