storm3

storm3

电信项目中flume的作用是什么？列出常见的flume的操作

​ Flume是一个分布式，可扩展，可靠，高可用的海量日志有效聚合及移动的框架。它通常用于log数据的收集，支持在系统中定制各类数据发送方，用于收集数据。它具有可靠性和容错可调机制和许多故障转移和恢复机制。

​ flume的运行核心是agent。它是一个完整的数据收集工具，含有三个核心组件，分别是source、channel、sink。通过这些组件，event可以从一个地方流向另一个地方。为了保证输送一定成功，在送到目的地之前，会先缓存数据，待数据真正到达目的地后，删除自己缓存的数据。

​ Source:

​ 从Client收集数据，传递给Channel。可以接受外部源发送过来的数据，不同的Source可以接受不同格式的数据。

​ 比如有目录池(spooling directoy)数据源，可以监控指定文件夹中的新文件变化，如果有文件产生，就立刻读取其内容。

​ Channel:

​ 是一个存储池，接收Source的输出，直到有Sink消费掉channel中的数据或者channel中的数据到下一个channel中或者进入终端才会被删除，当sink写入失败后，可以自动重启，不会造成数据丢失，因此很可靠。

​ Sink:

​ Sink是用来输出的

设计目标：
​ (1) 可靠性

​ 当节点出现故障时，日志能够被传送到其他节点上而不会丢失。Flume提供了三种级别的可靠性保障，从强到弱依次分别为：end-to-end（收到数据agent首先将event写到磁盘上，当数据传送成功后，再删除；如果数据发送失败，可以重新发送。），Store on failure（这也是scribe采用的策略，当数据接收方crash时，将数据写到本地，待恢复后，继续发送），Best effort（数据发送到接收方后，不会进行确认）。

​ (2) 可扩展性

​ 采用了三层架构，分别为agent，collector和storage，每一层均可以水平扩展。其中，所有agent和collector由master统一管理，这使得系统容易监控和维护，且master允许有多个（使用ZooKeeper进行管理和负载均衡），这就避免了单点故障问题。

​ (3) 可管理性

​ 所有agent和colletor由master统一管理，这使得系统便于维护。多master情况，Flume利用ZooKeeper和gossip，保证动态配置数据的一致性。用户可以在master上查看各个数据源或者数据流执行情况，且可以对各个数据源配置和动态加载。Flume提供了web 和shell script command两种形式对数据流进行管理。

​ (4) 功能可扩展性

​ 用户可以根据需要添加自己的agent，collector或者storage。此外，Flume自带了很多组件，包括各种agent（file， syslog等），collector和storage（file，HDFS等）。

flume常用作服务器端logs文件收集
bin/flume-ng help 显示帮助
bin/flume-ng agent 运行Flume代理
bin/flume-ng avro-client 运行一个avro Flume客户端
bin/flume-ng version 显示Flume版本

列出常见的kafka的操作

创建topic
kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test
查看所有topic
kafka-topics.sh  --zookeeper localhost:2181 --list
查看指定topic的描述
bin/kafka-topics.sh --zookeeper node06:2181,node07:2181,node08:2181 --describe --topic test
创建生产者
bin/kafka-console-producer.sh --broker-list node06:9092,node07:9092,node08:9092 --topic test
创建消费者
bin/kafka-console-consumer.sh --zookeeper node06:2181,node07:2181,node08:2181 --from-beginning --topic tes

什么是storm事务？

storm事务主要是保证storm的spout及bolt之前的tuple数据的处理结果有且仅有一次被成功接收并处理.

storm事务主要有三种：
1、单tuple强顺序流实现(普通事务)
2、创建batch强顺序流实现(分区事务)
3、将bolt功能区分,将commitbolt单独区分出来,业务逻辑处理节点可并行处理,通过commitbolt提交时,只能一个个提交.(不透明分区事务)

storm是如何保证消息仅被处理一次的？

​ storm运行过程中，每个传递的tuple都会关联一个transaction id,Transaction id从1开始，每个tuple会按照顺序+1。在处理tuple时，处理成功的tuple结果以及transaction id同时写入数据库中进行存储.由此tuple传入至数据库时会出现两种情况：
​ 1、当前transaction id与数据库中的transaction id不一致,storm再次发送对应的tuple进行计算,然后计算再往数据库存入.
​ 2、两个transaction id相同,则说明tuple已经被成功处理,无法继续往数据库写入.
​ 缺点：
​ 一次只能处理一个tuple，无法实现分布式计算

详细介绍storm事务中每个组件的作用

storm事务处理中，把一个批次的tuple的处理分为两个阶段processing和commit阶段。

• processing阶段运行多个批次的tuple并行处理。
• commit阶段各批次之间需强制按照顺序进行提交。

事务Topologies

在Transactional Topologies内部主要管理以下事情：

1. 管理状态: 把所有实现Transactional Topologies所必须的状态保存在zookeeper里面，包括当前transaction id及定义每个batch的一些元数据。
2. 协调事务: 决定在任何一个时间点是该proccessing还是该committing。
3. 错误检测: 利用acking框架来高效地检测什么时候一个batch被成功处理了，被成功提交了，或者失败了。Storm然后会相应地replay对应的batch。不需要手动做任何acking或者anchoring (emit时发生的动作)。
4. 中间数据清理：决定什么时候一个bolt接收到一个特定transaction的所有tuple。Storm同时也会自动清理每个transaction所产生的中间数据。

事务Topologies的实现

Spout

​ 事务性的spout需要实现TransactionalSpout，这个接口包含两个内部接口类Coordinator和Emitter。在topology运行的时候，事务性的spout内部包含一个子Topology.这里面有两种类型的tuple，一种是事务性的tuple，一种是batch中的tuple.

​ coordinator用于开启一个事务，并在准备进入一个事务的processing阶段时，发射一个事务性 tuple到”batch emit”流,coordinator只有一个，emitter根据并行度可以有多个实例.

​ Emitter以all grouping(广播)的方式订阅coordinator的”batch emit”流，负责为每个batch实际发射tuple。发送的tuple都必须以TransactionlAttempt作为第一个field，storm根据这个field来判断tuple属于哪一个batch。

TransactionAttempt

​ TransactionAttempt中包含两个值：一个transaction id，一个attempt id。transaction id的作用就是我们上面介绍的对于每个batch中的tuple是唯一的，而且不管这个batch replay多少次都是一样的。

​ attempt id是对于每个batch唯一的一个id， 但是对于同一个batch，它replay之后的attempt id跟replay之前就不一样了,storm利用这个id来区别一个batch发射的tuple的不同版本。

事务性Bolt

BaseTransactionalBolt

• 处理batch在一起的tuples，对于每一个tuple调用execute方 法，而在整个batch处理(processing)完成的时候调用finishBatch方法。如果BatchBolt被标记成committer，则 只能在commit阶段调用finishBatch方法。一个batch的commit阶段由storm保证只在前一个batch成功提交之后才会执行。并且它会重试直到topology里面的所有bolt在commit完成提交。那么如何知道batch的processing完成了，也就是bolt是否接收处理了batch里面所有的tuple，在bolt内部有一个 CoordinatedBolt的模型。
• 被标记成committer的BatchBolt需要实现Committer接口或者通过TransactionalTopologyBuilder的setCommitterBolt方法把BatchBolt添加到topology。

CoordinateBolt

• 每个CoordinateBolt记录两个值：有哪些task给我发送了tuple（根据topology的grouping信息）；我要给哪些task发送信息（同样根据groping信息）。
• 等所有的tuple都发送完了之后，CoordinateBolt通过另外一个特殊的stream以emitDirect的方式告诉所有它发送过 tuple的task，它发送了多少tuple给这个task。下游task会将这个数字和自己已经接收到的tuple数量做对比，如果相等，则说明处理 完了所有的tuple。
• 下游CoordinateBolt会重复上面的步骤，通知其下游。