大数据处理基础（下）详解

学习笔记

继续巩固蔡老师的课程知识点～

Index

• Workflow设计模式
• 发布／订阅模式
• CAP定理
• Lambda架构
• Kappa架构

Workflow设计模式

工作流系统（Workflow System）是将多个不同的处理模块连接在一起，通过有向无环图（Directed Acyclic Graph/DAG）得到所需结果的系统。

4种 Workflow System的设计模式

• 复制模式（Copier Pattern）：将单个数据处理模块中的数据完整复制到两个或多个数据处理模块中，用于对同一数据集进行多种不同的数据处理转换。
• 过滤模式（Filter Pattern）：过滤掉不符合条件的数据，用于针对数据集中的特定数据进行处理。
• 分离模式（Splitter Pattern）：对数据集中的不同数据分别进行处理，分组但不过滤数据，同一数据可划分到不同处理模块。
• 合并模式（Joiner Pattern）：将多个不同的数据集转换集中在一起，形成一个总数据集，并在工作流中处理。

发布/订阅模式（Publish/Subscribe Pattern）

这是在流数据处理中非常流行的设计模式，也被称为 Pub/Sub。

消息与消息队列

• 消息：在分布式架构中，各组件（如后台数据库、前端浏览器）通过消息进行通讯，消息格式任意。
• 消息队列：在 Pub/Sub 中，消息队列作为持久化缓冲（Durable Buffer），保存消息直到接收方确认收到。

发布／订阅模式基础概念

发布／订阅模式允许消息发送方异步发送消息给系统中的不同组件，无需知道接收方是谁。发送方称为发布者（Publisher），接收方称为订阅者（Subscriber）。

优点

• 松耦合（Loose Coupling）：发布者与订阅者在开发时无需事先知道对方的存在，可以独立开发。
• 高伸缩性（High Scalability）：消息队列可以独立作为数据存储中心存在，适合分布式环境。
• 组件间通信更简洁：只需定义好消息格式，订阅者即可按此格式接收消息。

缺点

• 不能保证发布者发送的数据一定会送达订阅者，需开发者实现响应机制。

适用场景

• 发送方需要向大量接收方广播消息。
• 组件需要与多个独立开发的组件或服务通信，这些组件或服务使用不同编程语言和通信协议。
• 发送方在发送消息后无需接收方实时响应。
• 对数据一致性的要求只需最终一致性（Eventual Consistency）。

CAP定理

简单来说，CAP定理证明了以下三属性：

• C属性（一致性）：所有分布式操作都像在单机上完成一样。
• A属性（可用性）：在分布式系统中，任意非故障服务器都必须对客户请求产生响应。
• P属性（分区容错性）：即使部分节点之间无法连通，系统也必须能够返回消息。

衍生的系统

• CP系统：Google BigTable、Hbase、MongoDB、Redis、MemCacheDB
• AP系统：Amazon Dynamo、Apache Cassandra、Voldemort
• CA系统：Apache Kafka

放弃了P属性的Kafka

Kafka0.8版本引入了Replication，通过将数据复制到不同节点增强数据的持久性（Durability）和可用性（Availability）。所有数据日志存储在同一个数据中心，网络分区错误可能性小。

在Kafka数据副本（Data Replication）设计中，通过Zookeeper选举出领导者节点（Leader），负责维护同步数据副本（In-sync-replica）。数据写入在领导者节点记录，通知副本存储并回复用户写入成功。如果领导者节点挂了，Zookeeper会重新选举健康节点作为新的领导者节点。

Lambda架构

Lambda架构帮助开发人员构建大规模分布式数据处理系统，具有灵活性和可扩展性，对硬件故障和人为失误有很好的容错性。

Lambda架构由三层系统组成：批处理层（Batch Layer）、速度处理层（Speed Layer）、服务层（Serving Layer）。

不同的系统层职责

• 批处理层：存储管理主数据集和预先批处理计算好的视图，计算历史数据，准确性高但实效性低。
• 速度处理层：实时处理新的大数据，提供实时视图，速度快但数据不是全量，参考价值有限。
• 服务层：接收批处理层和速度处理层的处理结果，响应用户查询。

案例分析

• 批处理层：使用停车场历史数据或每半小时获取的停车位数据，构建预测模型，预测剩余车位。
• 速度处理层：聚集用户GPS数据，建立预测模型，预测附近停车场拥挤程度。
• 服务层：结合批处理层和速度处理层的预测分数，将最高分数的停车场推荐给用户，提高推荐准确率。

Kappa架构

Kappa架构因Lambda架构维护复杂而存在，因为Lambda架构有两个完全不同的分布式系统（批处理和流处理），语法不同但逻辑需相同。

Kappa架构改进了某一层的架构，使其具有另一层的特性。

以Apache Kafka流处理平台为例：

由于Apache Kafka具有永久保存数据日志的功能，可以删除批处理层，仅保留流处理层。

步骤

• Step1：部署Apache Kafka，设置数据日志保留期（Retention Period）为Forever。
• Step2：重新启动Apache Kafka作业实例，从头开始计算保存的历史数据，将结果输出到新数据视图中。
• Step3：当新数据视图处理进度赶上旧数据视图时，应用切换到从新数据视图读取。
• Step4：停止旧版本作业实例，删除旧数据视图。

其架构如下图所示：