实时计算

• 2016-01-20 storm笔记：Storm+Kafka简单应用

  这几天工作需要使用storm+kafka，基本场景是应用出现错误，发送日志到kafka的某个topic，storm订阅该topic，然后进行后续处理。场景非常简单，但是在学习过程中，遇到一个奇怪的异常情况：使用KafkaSpout读取topic数据时，没有向ZK写offset数据，致使每次都从头开始读取。纠结了两天，终于碰巧找到原因：应该使用BaseBasicBolt作为bolt的父类，而不是BaseRichBolt。

  通过本文记录一下这种情况，后文中根据上述场景提供几个简单的例子。基础理论查看storm笔记：storm基本概念，或查看Storm 简介。

• 2017-06-08 storm笔记：Trident状态

  在storm笔记：Trident应用中说了下Trident的使用，这里说下Trident几种状态的变化及其对应API的使用。

• 2017-03-31 storm笔记：Trident应用

  本文内容部分来自Trident Tutorial。

  Trident是基于Storm的实时计算模型的高级抽象。它可以实现高吞吐（每秒数百万条消息）的有状态流处理和低延迟分布式查询。如果以前使用过高级批处理工具（比如Pig或Cascading），则对Trident的概念会非常熟悉，比如连接、聚合、分组、功能处理和过滤等。除此之外，Trident还增加了用于在数据库或持久化存储上进行有状态的增量处理的原语。Trident具有一致性、一次性语义，所以很容易就能够推导出Trident拓扑结构。

  Trident的出现算是程序猿非常懒的又一个铁证。Strom是一个实时流处理工具，有很高的吞吐。在实际应用场景中，很多场景是借助这种实时处理能力，对实时数据进行统计，然后将统计结果实时推送到大屏或者其他可以实时浏览的地方，这样领导或者活动运营就可以实时查看销售或活动情况，比如，双十一时候的大屏，就可以使用Storm来做（我们现在就是这样做的，把全渠道的销售情况进行实时统计，然后显示在大屏上，据说领导会看）。然后，程序猿们就发现，很多统计功能非常类似，所以进行抽象，使用更加高级的功能代替一个一个的Spout、Bolt（当然，Trident拓扑结构运行的时候也是解析成Spout和Bolt运行）。

  然后又有人发现，Trident这种方式也是比较麻烦，即使程序猿们通过高级抽先的Trident省去了很多麻烦，但是还是架不住运维、运营、产品等不断改变的需求，所以就有很多SQL方式解析为Trident或普通Topology的工具产生。既然运维、运营、产品等不断修改需求，那就简单的通过SQL查询（不同的SQL解析为不同的拓扑结构，在Storm中运行，可以得出不同的结果）。比如：squall。

  这些都是题外话，下面继续说Trident。