Streaming的关键特性介绍

Nimbus HA：

图：Nimbus HA架构

• 使用Zookeeper分布式锁：

  Nimbus HA的实现是使用Zookeeper分布式锁，通过主备间争抢模式完成的Leader选举和主备切换。

• 主备间元数据同步：

  主备Nimbus之间会周期性的同步元数据，保证在发生主备切换后拓扑数据不丢失，业务不受损。

容灾能力：

图：容灾示意图

容灾能力：节点失效，自动迁移到正常节点，业务不中断。

整个过程无需人工干预！

消息可靠性：

在Streaming里面一个Tuple被完全处理的意思是：这个Tuple所派生的所有tuple都被成功处理。如果这个消息在Timeout所指定的时间内没有成功处理，这个tuple就被认为处理失败了。

可靠性级别设置：

如果并不要求每个消息必须被处理（允许在处理过程中丢失一些信息），那么可以关闭消息的可靠性处理机制，从而可以获得较好的性能。关闭消息的可靠性机制一位着系统中的消息数会减半。

有三种方法可以关闭消息的可靠性处理机制：

1. 将参数Config.TOPOLGY_ACKERS设置为0.
2. Spout发送一个消息时，使用不指定消息message ID的接口进行发送。
3. Blot发送消息时使用Unanchor方式发送，使Tuple树不往下延伸，从而关闭派生消息的可靠性。

ACK机制：

图：Ack机制

• 一个Spout发送一个Tuple时，会通知Acker一个新的根消息产生了，Acker会创建一个新的Tuple tree，并初始化校验和为0.
• Bolt发送消息时间向Acker发送anchor tuple，刷新tuple tree，并在发送成功后向Acker反馈结果。如果成功则重新刷新校验和，如果失败则Acker会立即通知Spout处理失败。
• 当Tuple tree被完成吹了（校验和为0），Acker会通知Spout处理成功。
• Spout提供ack（）和Fail（）接口方法用户处理Acker的反馈结果，需要用户实现。一般在fail（）方法中实现消息重发逻辑。

Streaming与其他组件：

整合HDFS/HBase等外部组件，将实时结构提供给其他组件，进程离线分析。

Spark Streaming

Spark Streaming设计：

Spark Streaming可整合多种输入数据源，如Kafka、Flume、 HDFS，甚至是普通的TCP套接字。经处理后的数据可存储至文件 系统、数据库，或显示在仪表盘里。

图：SPark Streaming支持的输入、输出数据源

Spark Streaming的基本原理是将实时输入数据流以时间片（秒级）为单位进行拆分，然后经Spark引擎以类似批处理的方式处理每个时间片数据。

图：Spark Streaming执行流程

Spark Streaming最主要的抽象是DStream（Discretized Stream，离散化数据流），表示连续不断的数据流。在内部实现上，Spark Streaming的输入数据按照时间片（如1秒）分成一段一段的DStream，每一段数据转换为Spark中的RDD，并且对DStream的操作都最终转变为对相应的RDD的操作。

图：DStream操作示意图

Spark Streaming 与 Storm的对比：

• Spark Streaming和Storm最大的区别在于，Spark Streaming无法实现毫秒级的流计算，而Storm可以实现毫秒级响应。
• Spark Streaming构建在Spark上，一方面是因为Spark的低延迟执行引擎（100ms+）可以用于实时计算，另一方面，相比于Storm，RDD数据集更容易做高效的容错处理。
• Spark Streaming采用的小批量处理的方式使得它可以同时兼容批量和实时数据处理的逻辑和算法，因此，方便了一些需要历史数据和实时数据联合分析的特定应用场合。

Samza技术原理

基本概念：

（1）作业：一个作业（Job）是对一组输入流进行处理转化成输出流的程序。

（2）分区：

• Samza的流数据单位既不是Storm中的元组，也不是Spark Streaming中的DStream，而是一条条消息。
• Samza中的每个流都被分割成一个或多个分区，对于流里的每一个分区而言，都是一个有序的消息序列，后续到达的消息会根据一定规则被追加到其中一个分区里。

（3）任务：

• 一个作业会被进一步分割成多个任务（Task）来执行，其中，每个任务负责处理作业中的一个分区。
• 分区之间没有定义顺序，从而允许每一个任务独立执行。
• YARN调度器负责把任务分发给各个机器，最终，一个工作中的多个任务会被分发到多个机器进行分布式并行处理。

（4）数据流图：

• 一个数据流图是由多个作业构成的，其中，图中的每个节点表示包含数据的流，每条边表示数据传输。
• 多个作业串联起来就完成了流式的数据处理流程。
• 由于采用了异步的消息订阅分发机制，不同任务之间可以独立运行。

图：数据流图

Samza的系统架构：

Samza系统架构主要包括：

1. 流数据层（Kafka）
2. 执行层（YARN）
3. 处理层（Samza API）

流处理层和执行层都被设计成可插拔的，开发人员可以使用其他框架来替代YARN和Kafka。

图：MapReduce批处理架构和Samza流处理架构对比

处理分析过程：

图：处理分析过程图

处理分析过程如下：

1. Samza客户端需要执行一个Samza作业时，它会向YARN的ResouceManager提交作业请求。
2. ResouceManager通过与NodeManager沟通为该作业分配容器（包含了CPU、内存等资源）来运行Samza ApplicationMaster。
3. Samza ApplicationMaster进一步向ResourceManager申请运行任务的容器。
4. 获得容器后，Samza ApplicationMaster与容器所在的NodeManager沟通，启动该容器，并在其中运行Samza Task Runner。
5. Samza Task Runner负责执行具体的Samza任务，完成流数据处理分析。

Storm、Spark Streaming和Samza的应用场景

从编程的灵活性来讲，Storm是比较理想的选择，它使用Apache Thrift，可以用任何编程语言来编写拓扑结构（Topology）。

当需要在一个集群中把流计算和图计算、机器学习、SQL查询分析等进行结合时，可以选择Spark Streaming，因为，在Spark上可以统一部署Spark SQL，Spark Streaming、MLlib，GraphX等组件，提供便捷的一体化编程模型。

当有大量的状态需要处理时，比如每个分区都有数十亿个元组，则可以选择Samza。当应用场景需要毫秒级响应时，可以选择Storm和Samza，因为Spark Streaming无法实现毫秒级的流计算。