Streaming的介绍

Streaming
1.Streaming简介
1.1.Streaming基于开源Storm，是一个分布式、实时计算框架。
1.2.Streaming具有以下几种特点：
1.3.实时响应，低延迟。
1.4.数据不存储，先计算。
1.5.连续查询。
1.6.事件驱动。
2.Streaming应用场景
2.1.主要应用于以下几种场景:
2.2.实时分析：如实时日志处理、交通流量分析等。
2.3.实时统计：如网站的实时访问统计、排序等。
2.4.实时推荐：如实时广告定位、事件营销等。
3.Streaming在FusionInsight中的位置
3.1.Steaming是一个实时的分布式的实时计算框架，在实时业务中有广泛的应用。
5.适用场景比较
5.1.Streaming适用于对响应时间有严格要求的场景，通常为毫秒级。
5.2.Spark Streaming适用于对响应时间要求不高的场景，通常为秒级。
5.3.要求毫秒级建议使用streaming，秒级建议sparkstreaming。
6.基本概念 (1)
6.1.Topology：Streaming中运行的一个实时应用程序。
6.2.Nimbus：负责资源分配和任务调度。
6.3.Supervisor：负责接受Nimbus分配的任务,启动和停止属于自己管理的worker进程。
6.4.Worker：Topology运行时的物理进程。每个Worker是一个JVM进程。
6.5.Spout：在一个Topology中产生源数据流的组件。
6.6.Bolt：在一个Topology中接受数据然后执行处理的组件
7.基本概念 (2)
7.1.Task：Worker中每一个Spout/Bolt的线程称为一个task。
7.2.Tuple： Streaming的核心数据结构，是消息传递的基本单元，不可变Key-Value对，这些Tuple会以一种分布式的方式进行创建和处理。
7.3.Stream ：一个无边界的连续Tuple序列。
7.4.ZooKeeper：为Streaming服务中各进程提供分布式协作服务。主备Nimbus、Supervisor、Worker将自己的信息注册到ZooKeeper中，Nimbus据此感知各个角色的健康状态。
8.系统架构
8.1.Client客户端向Nimbus提交业务拓扑。
8.2.Nimbus负责接收客户端提交任务，并在集群中分发任务给Supervisor；同时监听状态等。
8.3.Supervisor负责监听并接受Nimbus分配的任务，根据需要启动和停止属于自己管理的Worker进程。
8.4.Worker进程是运行具体处理组件逻辑的进程。每个Worker是一个JVM进程。其中，每个exacutor为一个线程，处理具体业务逻辑。
8.5.ZooKeeper为服务中各进程提供分布式协作服务。Nimbus、Supervisor、Worker将自己的信息注册到ZooKeeper中，Nimbus据此感知各个角色的健康状态。
9.Topology介绍
9.1.一个Topology是由一组Spout组件（数据源）和Bolt组件（逻辑处理）通过Stream Groupings进行连接的有向无环图(DAG)。
9.2.业务处理逻辑被封装进Streaming中的Topology中。
9.3.一个Topology会一直运行，直到你kill它。
9.4.Spout是Streaming的消息源，它是Topology的消息生产者，一般来说消息源会从一个外部源读取数据并向Topology中发送消息（Tuple）。比如一个spout可能从Kafka队列里面读取消息并且把这些消息发射成一个流。
9.5.bolt可以接收任意多个输入stream， 作一些处理， 有些bolt可能还会发射新的stream。一些复杂的流转换， 比如从微博消息里面计算出热门话题， 需要多个步骤， 从而也就需要多个bolt。 Bolt可以做任何事情: 运行函数， 过滤tuple, 做聚合， 做合并以及访问数据库等等。
9.6.Stream groupings声明每个Bolt接受怎样的流作为输入，Stream grouping定义一个Stream应该如何分配给该Bolt上面的多个Task。
10.Worker介绍
10.1.Worker：一个Worker是一个JVM进程，
10.2. 所有的Topology都是在一个或者多个
10.3. Worker中运行的。Worker启动后是长
10.4. 期运行的，除非人工停止。Worker进
10.5. 程的个数取决于Topology的设置，且
10.6. 无设置上限，具体可获得调度并启动
10.7. 的Worker个数则取决于Supervisor配
10.8. 置的slot个数。
10.9.Executor：在一个单独的Worker进程中会运行一个或多个Executor线程。每个Executor只能运行Spout或者Bolt中的一个或多个task实例。
10.10.Task：是最终完成数据处理的实体单元。
10.11.在Streaming中，一个slot对应的是一个端口号，slot的定义及开放个数由Supervisor决定。
10.12.每一个Worker进程启动时需要一个端口号，即slot，因此每启动一个Worker就消耗掉一个slot。

12.Nimbus HA
12.1.使用ZooKeeper分布式锁
12.2.Nimbus HA的实现是使用ZooKeeper分布式锁，通过主备间争抢模式完成的Leader选举和主备切换。
12.3.主备间元数据同步
12.4.主备Nimbus之间会周期性的同步元数据，保证在发生主备切换后拓扑数据不丢失，业务不受损。
12.5.解决Nimbus单点问题，支持主从热切换。
13.容灾能力
13.1.容灾能力：节点失效，自动迁移到正常节点，业务不中断。
14.消息可靠性
14.1.在streaming里面一个tuple被完全处理的意思是：这个tuple以及由这个tuple所派生的所有的tuple都被成功处理。如果这个消息在Timeout所指定的时间内没有成功处理,这个tuple就被认为处理失败了。
14.2.Streaming里面有一类特殊的task称为：acker， 他们负责跟踪spout发出的每一个tuple的tuple树。当acker发现一个tuple树已经处理完成了。它会发送一个消息给产生这个tuple 的那个task。在spout中发射一个新的源tuple时为其指定一个64位的message id,acker跟踪这个消息ID。
14.3.acker所参与的工作流程：
14.4.1. Spout创建一个新的Tuple时，会发一个消息通知acker去跟踪。
14.5.2. Bolt在处理Tuple成功或失败后，也会发一个消息通知acker。
14.6.3. acker会找到发射该Tuple的Spout，回调其ack或fail方法。
14.7.图示：假设消息D和E是由消息C派生出来的，这里演示了消息C被应答时，tuple tree是如何变化的。
14.8.Timetout可以通过Config.Topology_MESSAGE_TIMEOUT_SECS 来指定。
15.ACK机制
15.1.Spout发送一个Tuple时，会通知Acker一
15.2. 个新的根消息产生了，Acker会创建一个
15.3. 新的tuple tree，并初始 化校验和为0。
15.4.Bolt发送消息时向Acker发送anchor
15.5. tuple，刷新tuple tree，并在发送成功
15.6. 后向Acker反馈结果。如果成功则重新刷
15.7. 新校验和，如果失败则Acker会立即通知
15.8. Spout处理失败。
15.9.当tuple tree被完全处理（校验和为0），Acker会通知Spout处理成功。
15.10.Spout提供ack()和fail()接口方法用于处理Acker的反馈结果，需要用户实现。一般在fail()方法中实现消息重发逻辑。
15.11.Spout提供ack()和fail()接口方法用于处理Acker的反馈结果，需要用户实现。一般在fail()方法中实现消息重发逻辑。
15.12.Streaming就是通过这个acker的机制来保证数据不丢失。
15.13.简单的说就是伴随tuple有个id，在整个Topology中每个处理步骤都会生产新的id。原始id与新id做异或，如果为0则成功，不为0则调用fail函数处理。
15.14.Spout在初始化时会产生一个tasksId。
15.15.Spout中创建新的Tuple，其id是一个64位的随机数。
15.16.Spout将新建的Tuple发送出去(给出了messageId来开启Tuple的追踪), 同时会发送一个消息到某个acker，要求acker进行追踪。该消息包含两部分：
15.17.Spout的taskId：用户acker在整个Tuple树被完全处理后找到原始的Spout进行回调ack或fail。
15.18.一个64位的ack val值： 标志该tuple是否被完全处理。初始值为0。
15.19.Spout发送一个Tuple时，会通知Acker一
15.20. 个新的根消息产生了，Acker会创建一个
15.21. 新的tuple tree，并初始 化校验和为0。
15.22.Bolt发送消息时向Acker发送anchor
15.23. tuple，刷新tuple tree，并在发送成功
15.24. 后向Acker反馈结果。如果成功则重新刷
15.25. 新校验和，如果失败则Acker会立即通知
15.26. Spout处理失败。
15.27.当tuple tree被完全处理（校验和为0），Acker会通知Spout处理成功。
15.28.Spout提供ack()和fail()接口方法用于处理Acker的反馈结果，需要用户实现。一般在fail()方法中实现消息重发逻辑
15.29. 一个Bolt在处理完Tuple后，如果发射了一个新的anchor tuple，Streaming会维护anchor tuple的列表。
15.30.该Bolt调用OutputCollector.ack()时，Streaming会做如下操作：
15.31.将anchor tuple列表中每个已经ack过的和新创建的Tuple的id做异或(XOR)。假定Spout发出的TupleID是tuple-id-0，该Bolt新生成的TupleID为tuple-id-1，那么，tuple-id-0XORtuple-id-0XOR tuple-id-1。
15.32.Streaming根据该原始TupleID进行一致性hash算法，找到最开始Spout发送的那个acker，然后把上面异或后得出的ack val值发送给acker。
15.33.acker收到新的ack val值后，与保存的原始的Tuple的id进行异或，如果为0，表示该Tuple已被完全处理，则根据其taskId找到原始的Spout，回调其ack()方法。
15.34.fail的机制类似，在发现fail后直接回调Spout的fail方法。
16.可靠性级别设置
16.1.如果并不要求每个消息必须被处理（允许在处理过程中丢失一些信息），那么可以关闭消息的可靠处理机制，从而可以获取较好的性能。
16.2.有三种方法可以关闭消息的可靠处理机制：
16.3.将参数Config.Topology_ACKERS设置为0。
16.4.Spout发送一个消息时，使用不指定消息messageID的接口进行发送。
16.5.Bolt发送消息时使用Unanchor方式发送，使Tuple树不往下延伸，从而关闭派生消息的可靠性。
16.6.Acker任务是轻量级的，所以在拓扑中并不需要太多的acker存在。可以通过Streaming UI来观察acker任务的吞吐量，如果看上去吞吐量不够的话，说明需要添加额外的acker。
16.7.如果你并不要求每个消息必须被处理（你允许在处理过程中丢失一些信息），那么可以关闭消息的可靠处理机制，从而可以获取较好的性能。关闭消息的可靠处理机制意味着系统中的消息数会减半（每个消息不需要应答了）。另外，关闭消息的可靠处理可以减少消息的大小（不需要每个tuple记录它的根id了），从而节省带宽。
17.Streaming与其他组件
17.1.整合HDFS/Hbase等外部组件，将实时结果提供给其他组件，进行离线分析。
17.2.Streaming作为流处理平台，支持从外部数据源读取流式数据并将处理后的结果实时发送到外部组件。
18.StreamCQL简介
18.1.StreamCQL(Stream Continuous Query Language)是建立在分布式流处理平台基础上的查询语言(CQL)，架构支持构建在多种流处理引擎之上，目前主要适配Streaming 。
18.2.StreamCQL提供了较丰富的分布式流计算功能，除了具有过滤、转换等传统的SQL基本能力之外, StreamCQL引入基于流的时间窗口的计算，提供窗口数据的统计、关联等能力，以及流数据的拆分、合并等功能。
18.3.窗口就是一个有限范围内、任意一个时间点的数据状态快照。
18.4.CQL功能简介
18.5.类SQL接口，提高开发效率。
18.6.内置非富算子
18.7.过滤、转换。
18.8.窗口计算。
18.9.JOIN。
18.10.内置多种函数
18.11.字符串处理。
18.12.时间处理。
18.13.灵活的业务能力
18.14.自定义算子：用户特定功能。
18.15.自定义输入/输出方式。
18.16.自定义序列化/反序列化方式。
18.17.自定义功能函数。
18.18.
19.StreamCQL易开发
19.1.StreamCQL使用类SQL语言开发业务，语法基本通用。开发方式上比原生API更加简练，且不依赖任何编程工具。
20.StreamCQL与流处理平台
20.1.底层引擎指的是流处理平台，比如Streaming。
20.2.Stream和Window是建立在流处理引擎之上的概念，是整个SteamCQL所有功能的基础。
20.3.在Stream和Window之上是一系列的功能性算法集合，如Jion、Split、Merge等。
20.4.最上层是开放的语言接口，如CQL。
21.Task介绍
21.1.Topology里面的每一个Component（Spout/Bolt）节点都是并行运行的。 在Topology里面，可以指定每个节点的并发度，Streaming则会在集群里面分配相应的Task来同时计算，以增强系统的处理能力。
21.2.一个Topology可以包含一个或多个worker(并行的跑在不同的machine上), 所以worker process就是执行一个Topology的子集, 并且worker只能对应于一个Topology。
21.3.一个worker可用包含一个或多个executor, 每个component (spout或bolt)至少对应于一个executor, 所以可以说executor执行一个compenent的子集, 同时一个executor只能对应于一个component。
21.4.Task就是具体的处理逻辑对象, 一个executor线程可以执行一个或多个tasks，但一般默认每个executor只执行一个task, 所以我们往往认为task就是执行线程, 其实不然，task代表最大并发度, 一个component的task数是不会改变的, 但是一个componet的executer数目是会发生变化的，当task数大于executor数时, executor数代表实际并发数。
21.5.Spout和Bolt的并发度，指的是Spout和Bolt中的Task个数，如上图中的Spout就包含两个Task。