读构建可扩展分布式系统：方法与实践14流处理系统

1. 流处理系统

1.1. 时间就是金钱

• 1.1.1. 从数据中提取有价值的知识和获得洞见的速度越快，就能越快地响应系统所观察的世界的变化

• 1.1.2. 信用卡欺诈检测

• 1.1.3. 网络安全中异常网络流量的捕获

• 1.1.4. 在支持GPS的驾驶应用程序中进行的实时路线规划

• 1.1.5. 社交媒体网站上的热门话题识别

1.2. 需要对最近的一组观察结果进行计算

• 1.2.1. 此类计算对时间很敏感，需要访问最近的相关数据

1.3. 传统上，可以通过将外部提供的数据保存到数据库并设计可提取所需信息的查询来构建此类应用程序

1.4. 需要从数据库和索引中获得快速、可扩展的写入性能，来实现低延迟聚合读取和最近数据点的连接

• 1.4.1. 有时“终于”是在漫长的等待之后到来的，在当今世界，迟到的结果（即使迟到几秒钟）与根本没有结果一样糟糕

1.5. 面对来自传感器、设备和用户的海量数据源的数量不断增加，我们出现了一种被称为流处理系统的新技术

• 1.5.1. 流处理系统旨在提供在内存中处理数据流的能力，而无须通过持久化数据来获得所需的结果

• 1.5.2. 动态数据或实时分析

1.6. 流处理平台正在成为可扩展系统的常见部分

1.7. 流系统产生实时相关结果的能力在许多应用领域都极具吸引力

• 1.7.1. 可以实时转换、聚合和分析传入的数据

• 1.7.2. 应用程序可以根据时间窗口或消息量对有限批次的数据执行分析

• 1.7.3. 使得识别数据趋势并根据最新数据窗口中的值计算指标成为可能

1.8. 利用许多流平台来构建可容错、可扩展的应用程序

• 1.8.1. 可扩展性是通过将逻辑数据流应用程序架构转换为一个集群中与之物理等价的跨计算资源分布和连接的处理节点来实现的

• 1.8.2. 容错机制持久保存处理节点的状态并跟踪哪些消息已通过完整的数据流应用程序成功处理

• 1.8.2.1. 当发生故障时，可以从第一个未完成的消息重新启动流

2. 流处理简介

2.1. 自从软件系统问世以来，批处理就在处理新的可用数据方面发挥了重要作用

• 2.1.1. 批处理是大型系统的一个可靠有效的重要组成部分

• 2.1.2. 缺点是新数据从到达到可用于查询和分析存在时间差

2.2. 在批处理系统中，代表新的和更新后的对象的原始数据会被累积到文件中

2.3. 一个被称为批处理数据加载任务的软件组件会定期处理这些新的可用数据，并将其插入应用程序的数据库中

• 2.3.1. 称为ETL（提取、转换、加载）流程

• 2.3.2. ETL的意思是处理包含新数据的批处理文件，将数据聚合并转换为适合插入存储层的格式

2.4. 流系统可以实时处理新数据和事件

• 2.4.1. 使用支持向量机等快速统计模型预测技术来评估交易是否具有潜在欺诈性

• 2.4.2. “实时”高度依赖于应用程序，处理延迟可能从不到一秒至几秒不等

• 2.4.3. 流系统也可以对一批批的或一个个窗口的新数据进行处理

• 2.4.3.1. 微批次

2.5. 批处理和流处理架构，以及像Lambda架构这样的混合架构在现代可扩展系统中都有自己的地位

2.6. Lambda架构

• 2.6.1. 诞生于2011年左右，作为一种结合了传统批处理和新兴流处理方法的混合体

• 2.6.2. 批处理层

• 2.6.2.1. 该层定期处理大量新事件数据并更新应用程序的数据库

• 2.6.2.2. 在Lambda刚出现时，用于可扩展批处理的主导技术是Apache Hadoop

• 2.6.2.3. 与任何批处理系统一样，数据库更新频率大约为几分钟到几小时，具体取决于批处理的频率

• 2.6.3. 速度层

• 2.6.3.1. 该层通过处理新到达的事件以提供低延迟结果来补充批处理层

• 2.6.3.2. 定期批处理的数据正在累积时，速度层会处理相关事件，从而能快速了解最新的数据

• 2.6.3.3. 将速度层视为处理新数据和服务层更新造成的高延迟补偿

• 2.6.3.4. Apache Storm是一种广泛用于速度层的技术

• 2.6.4. 服务层

• 2.6.4.1. 该层是批处理层和速度层存储结果的地方，它负责处理查询和生成结果

• 2.6.4.2. 结果可以基于批处理层或速度层的输出，或基于将两者结合的计算结果

3. 流处理平台

3.1. 数据通常是队列或者分布式存储系统中的文件

3.2. 流处理节点从数据源中提取数据对象并执行转换、聚合和特定于应用的业务逻辑

• 3.2.1. 节点被组织为有向无环图(DAG)

• 3.2.2. 来自数据源的数据对象作为流来处理

• 3.2.3. 数据流是单个数据对象的无限序列

3.3. 在概念上，数据对象是在处理节点之间传递或流动的，因此流应用程序也被称为数据流系统

3.4. 流处理系统为处理节点提供了将一个节点处的输入流转换为由一个或多个下游节点处理的新流的能力

3.5. 流处理应用程序有两种常见的风格

• 3.5.1. 简单地处理和转换流中的单个事件，不需要每个事件的任何上下文或状态

• 3.5.2. 有些流应用程序需要维护在处理流中各个数据对象的过程中持续存在的状态

• 3.5.2.1. 有状态流应用程序

3.6. 流处理平台需要能够使应用程序扩展处理能力以及具备故障快速恢复的能力

• 3.6.1. 通常通过跨计算资源集群执行多个处理节点实例，并实现状态检查点机制以支持故障恢复来实现

3.7. Apache Storm是一个功能强大且可扩展的流处理平台

4. Apache Flink

4.1. 诞生于2014年，基于European Union Stratosphere项目中的原始研究

4.2. Flink的核心是一个分布式流处理系统，专为高吞吐量和低延迟而设计

• 4.2.1. Flink提供了一组操作，用于过滤、聚合、映射和连接来自数据源的数据流

• 4.2.2. 与明确定义的Apache Storm拓扑不同，Flink程序被编译并自动转换为可以部署在集群计算环境中的数据流程序

4.3. Flink还支持两种基于关系概念的API，即Table和SQL API

4.4. Data Stream API

• 4.4.1. Flink DataStream API为Java和Scala系统提供流处理功能

• 4.4.2. 可以利用丰富的流处理操作来拆分、过滤、聚合和转换事件流，并使用有界时间窗口创建周期性的批处理流事件

• 4.4.3. 在Flink中，数据流是类型化事件流的逻辑表示，即Java中的DataStream＜T＞

• 4.4.4. Flink支持包括文件在内的多种本地数据源，并具有用于各种外部技术的连接器

• 4.4.5. 窗口操作定义了有限的事件集合的边界并对这组事件执行操作

4.5. 可扩展性

• 4.5.1. Flink程序会被转换成一个逻辑DAG（有向无环图）​

• 4.5.2. 数据流通过代码中定义的转换从源移动到接收器

• 4.5.3. 可以使用执行环境对象为程序中的所有算子、数据源和数据接收器指定默认的并行度级别

• 4.5.4. 常见的策略是分配与每个任务管理器节点上可用CPU内核相同数量的插槽

• 4.5.5. Flink实现了一个复杂的转换算法，将逻辑DAG映射到可用的物理资源

• 4.5.5.1. 包括了算子链的优化，将算子并置在单个任务槽中，最大限度地减少数据通信成本

4.6. 数据安全

• 4.6.1. 故障处理是任何流处理系统都需要考虑的问题

• 4.6.2. 如果部署的一部分流应用程序由于某个节点崩溃、网络故障或应用程序异常而发生故障，保存在内存中的任何状态都会丢失

• 4.6.3. 两种支持数据安全的机制

• 4.6.3.1. 持久化状态存储和定期为完整流调用检查点

• 4.6.4. 需要配置有状态的算子以定期将其状态保存为键值对

• 4.6.4.1. 所有算子的快照都是基于对来自流源的完全相同的输入事件的处理

• 4.6.5. 持久存储使得在流处理失败的情况下可以从快照恢复状态

• 4.6.6. Flink使用流屏障(stream barrier)确保快照是一致的

• 4.6.6.1. 一旦屏障在所有输入上传递到流接收器，检查点就被标记为完成

• 4.6.6.2. 检查点可以有效提高Flink应用程序的容错能力

• 4.6.7. Flink通过配置各种参数来控制何时触发检查点

• 4.6.7.1. 一个经常使用的参数是检查点之间的最短时间间隔