trident原理及编程指南

trident原理及编程指南

@(STORM)[storm, 大数据]

一、理论介绍

（一）trident是什么？

Trident is a high-level abstraction for doing realtime computing on top of Storm. It allows you to seamlessly intermix high throughput (millions of messages per second), stateful stream processing with low latency distributed querying. If you’re familiar with high level batch processing tools like Pig or Cascading, the concepts of Trident will be very familiar – Trident has joins, aggregations, grouping, functions, and filters. In addition to these, Trident adds primitives for doing stateful, incremental processing on top of any database or persistence store. Trident has consistent, exactly-once semantics, so it is easy to reason about Trident topologies.
简单的说，trident是storm的更高层次抽象，相对storm，它主要提供了3个方面的好处：
（1）提供了更高层次的抽象，将常用的count,sum等封装成了方法，可以直接调用，不需要自己实现。
（2）以批次代替单个元组，每次处理一个批次的数据。
（3）提供了事务支持，可以保证数据均处理且只处理了一次。

（二）trident处理单位

trident每次处理消息均为batch为单位，即一次处理多个元组。

（三）事务类型

关于事务类型，有2个比较容易混淆的概念：spout的事务类型以及事务状态。
它们都有3种类型，分别为：事务型、非事务型和透明事务型。

1、spout类型

spout的类型指定了由于下游出现问题（fail被调用，或者超时无回复）导致元组需要重放时，应该怎么发送元组。
事务型spout:重放时能保证同一个批次发送同一批元组。可以保证每一个元组都被发送且只发送一个，且同一个批次所发送的元组是一样的。
非事务型spout：没有任何保障，发完就算。
透明事务型spout：同一个批次发送的元组有可能不同的，它可以保证每一个元组都被发送且只发送一次，但不能保证重放时同一个批次的数据是一样的。这对于部分失效的情况尤其有用，假如以kafka作为spout，当一个topic的某个分区失效时，可以用其它分区的数据先形成一个批次发送出去，如果是事务型spout，则必须等待那个分区恢复后才能继续发送。
这三种类型可以分别通过实现ITransactionalSpout、ITridentSpout、IOpaquePartitionedTridentSpout接口来定义。

2、state类型

state的类型指定了如果将storm的中间输出或者最终输出持久化到某个地方（如内存），当某个批次的数据重放时应该如果更新状态。state对于下游出现错误的情况尤其有用。
事务型状态：同一批次tuple提供的结果是相同的。
非事务型状态：没有回滚能力，更新操作是永久的。
透明事务型状态：更新操作基于先前的值，这样由于这批数据发生变化，对应的结果也会发生变化。透明事务型状态除了保存当前数据外，还要保存上一批数据，当数据重放时，可以基于上一批数据作更新。
注意，此处的状态应该是原子性的，比如将状态写入hbase，则应该全部写入，或者全部没写入，不能说写入一半，另一半没写入，这连事务型也无法保证恰好一次了。比如说写入本地磁盘，就有可能导致这种情况，如果写到一半出错，则无法保证恰好一次了，因为磁盘没有类似于数据库的commit、rollback操作。

3、实现恰好一次的spout与state组合类型

由上表可以看出：
（1）当spout与state均为t