系列文章目录

系统架构设计高级技能 · 软件架构概念、架构风格、ABSD、架构复用、DSSA（一）【系统架构设计师】
系统架构设计高级技能 · 系统质量属性与架构评估（二）【系统架构设计师】
系统架构设计高级技能 · 软件可靠性分析与设计（三）【系统架构设计师】

现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.

一、传统数据处理系统的问题

1.1 传统数据库的数据过载问题

传统应用的数据系统架构设计时，应用直接访问数据库系统。当用户访问量增加时，数据库无法支撑日益增长的用户请求的负载，从而导致数据库服务器无法及时响应用户请求，出现超时的错误。

关于这个问题的常用解决方法如下：
（1）增加异步处理队列
（2）建立数据库水平分区
（3）建立数据库分片或重新分片
（4）引入读写分离技术
（5）引入分库分表技术

1.2 大数据的特点

大数据具有体量大、失效性强的特点，并非构造单调，二是类型多样；处理大数据时，传统数据处理系统因数据过载，来源复杂，类型多样等诸多原因性能低下，需要采用以新式计算架构和智能算法为代表的新技术；大数据的应用重在发掘数据间的相关性，而非传统逻辑上的因果关系；因此，大数据的目的和价值就在于发现新的知识，洞悉并进行科学决策。

现代大数据处理技术，主要分为以下几种：

（1）基于分布式文件系统Hadoop。
（2）使用Map/Reduce或Spark数据处理技术。
（3）使用Kafaka数据传输消息队列及Avro二进制格式。

1.3 大数据的利用过程

大数据的利用过程分为：采集、清洗、统计和挖掘 4个过程。

二、大数据处理系统架构分析

2.1 大数据处理系统面临的挑战

大数据处理系统面临的挑战主要有：
（1）如何利用信息技术等手段处理非结构化和半结构化数据。
（2）如何探索大数据的复杂性、不确定性特征描述的刻画方法及大数据的系统建模。
（3）数据异构性与决策异构性的关系对大数据知识发现与管理决策的影响。

2.2 大数据处理系统的特征

大数据处理系统应具有的属性和特征包括：
鲁棒性和容错性、低延迟性、横向扩展（通过增强机器性能扩展）、通用、可扩展、即席查询（用户按照自己的要求进行查询）、最少维护和可调试。

三、典型的大数据架构

2.1 Lambda架构

Lambda架构是一种用于同时处理离线和实时数据的、可容错性、可扩展性的分布式系统。

如图，Lambda架构：

Lambda架构分为以下3层：
（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架构优缺点：

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

缺点
（1）全场景覆盖带来的编码开销。
（2）针对具体场景重新离线训练一遍益

2.2 Kappa架构

Kappa架构是在Lamada架构的基础上进行了优化、删除了Batch Layer的架构，将数据通道以消息队列进行替代。

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

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

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

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

而Kappa的缺点也很明显：

（1）消息中间件缓存的数据量和回溯数据有性能瓶颈。通常算法需要过去180天的数据，如果都存在消息中间件，无疑有非常大的压力。同时，一次性回溯订正180天级别的数据，对实时计算的资源消耗也非常大。

（2）在实时数据处理时，遇到大量不同的实时流进行关联时，非常依赖实时计算系统的能力，很可能因为数据流先后顺序问题，导致数据丢失。

（3）Kappa 在抛弃了离线数据处理模块的时候，同时抛弃了离线计算更加稳定可靠的特点。Lambda虽然保证了离线计算的稳定性，但双系统的维护成本高且两套代码带来后期运维困难。对于以上Kappa框架存在的几个问题，目前也存在一些解决方案，对于消息队列缓存数据性能的问题， Kappa+框架提出使用 HDFS来存储中间数据。针对 Kappa框架展示层能力不足的问题，也有人提出了混合分析系统的解决方案。

2.3 Lambda架构与Kappa架构对比

Lambda架构和Kappa 架构对比

对比内容	Lambda架构	Kappa架构
复杂度与开发、维护成本	需要维护两套系统(引擎),复杂度 高，开发、维护成本高	只需要维护一套系统(引擎),复杂度低，开发、维护成本低
计算开销	需要一直运行批处理和实时计算，计算开销大	必要时进行全量计算，计算开销相对较小
实时性	满足实时性	满足实时性
历史数据处理能力	批式全量处理，吞吐量大，历史据处理能力强	流式全量处理，吞吐量相对较低，历史数据处理能力相对较弱

Lambda架构与Kappa架构的设计选择

根据两种架构对比分析，将业务需求、技术要求、系统复杂度、开发维护成本和历史数据处理能力作为选择考虑因素。而计算开销虽然存在一定差别，但是相差不是很大，所以不作为考虑因素。

（1）业务需求与技术要求
用户需要根据自己的业务需求来选择架构，如果业务对于 Hadoop、Spark、Strom 等关键技术有强制性依赖，选择 Lambda架构可能较为合适；如果处理数据偏好于流式计算，又依赖Flink计算引擎，那么选择Kappa架构可能更为合适。

（2）复杂度
如果项目中需要频繁地对算法模型参数进行修改， Lambda架构需要反复修改两套代码，则显然不如 Kappa架构简单方便。同时，如果算法模型支持同时执行批处理和流式计算，或者希望用一份代码进行数据处理，那么可以选择Kappa 架构。在某些复杂的案例中，其实时处理和离线处理的结果不能统一，比如某些机器学习的预测模型，需要先通过离线批处理得到训练模型，再交由实时流式处理进行验证测试，那么这种情况下，批处理层和流处理层不能进行合并，因此应该选择Lambda架构。

（3）开发维护成本
Lambda架构需要有一定程度的开发维护成本，包括两套系统的开发、部署、测试、维护，适合有足够经济、技术和人力资源的开发者。而Kappa 架构只需要维护一套系统，适合不希望在开发维护上投入过多成本的开发者。

（4）历史数据处理能力
有些情况下，项目会频繁接触海量数据集进行分析，比如过往十年内的地区降水数据等，这种数据适合批处理系统进行分析，应该选择Lambda架构。如果始终使用小规模数据集，流处理系统完全可以使用，则应该选择Kappa架构。

四、大数据架构的实践

4.1 大规模视频网络

如图，某网奥运中的Lambda架构：

4.2 广告平台

如图，某网广告平台中的Lambda架构：

如图，某证券大数据系统架构：

4.3 电商智能决策大数据系统

如图，某电商智能决策大数据系统架构：