随笔分类 -  Apache Storm

摘要：自从建了Spark交流的QQ群之后，热情加入的同学不少，大家不仅对Spark很热衷对于Storm也是充满好奇。大家都提到一个问题就是有关storm内部实现机理的资料比较少,理解起来非常费劲。 尽管自己也陆续对storm的源码走读发表了一些博文，当时写的时候比较匆忙，有时候衔接的不是太好，此番做了一些整理，主要是针对TridentTopology部分，修改过的内容采用pdf格式发布，方便打印。 文章中有些内容的理解得益于徐明明和fxjwind两位的指点，非常感谢。 阅读全文

摘要：或许谈起storm是大数据实时计算框架已经让你不明觉厉，如果说storm还可以跟机器学习算法(ml)有机的结合在一起，是不是更加觉着高大尚呢。trident-ml就是一个这样让人无限遐想的产品。 阅读全文

摘要：storm是一个近似于实时的计算框架，甩开hadoop上的原生mapreduce计算框架不只一条街。如果能将storm引入到hadoop中，对存储于hdfs的数据进行分析必然极大的提高处理性能。storm-yarn就是这样一个项目，由yahoo实现，目前已经开源。 阅读全文

摘要：从用户层面来看TridentTopology，有两个重要的概念一是Stream,另一个是作用于Stream上的各种Operation。在实现层面来看，无论是stream，还是后续的operation都会转变成为各个Node，这些Node之间的关系通过重要的数据结构图来维护。具体到TridentTopology，实现图的各种操作的组件是jgrapht。 说到图，两个基本的概念会闪现出来，一是结点，二是描述结点之间关系的边。要想很好的理解TridentTopology就需要紧盯图中结点和边的变化。 TridentTopology在转换成为普通的StormTopology时，需要将原始的图分成各个group，每个group将运行于一个独立的bolt中。TridentTopology又是如何知道哪些node应该在同一个group,哪些应该处在另一个group中的呢；如何来确定每个group的并发度(parallismHint)的呢。这些问题的解决都与jgrapht分不开。 阅读全文

摘要：介绍TridentTopology的使用，重点分析newDRPCStream和stateQuery的实现机理。 使用TridentTopology进行数据处理的时候，经常会使用State来保存一些状态，这些保存起来的State通过stateQuery来进行查询。问题恰恰在这里产生，即对state进行更新的Stream和尔后进行stateQuery的Stream并非同一个，那么它们之间是如何关联起来的呢。 在TridentTopology中，有一些Processor可能会同处于一个Bolt中，这些Processor形成一个processing chain, 那么Tuple又是如何在这些Processor之间进行传递的呢。 阅读全文

摘要：本文通过BasicDRPCTopology的实例来分析DRPCTopology在提交的时候, Topology中究竟含有哪些内容? 阅读全文

摘要：“源码走读系列”从代码层面分析了storm的具体实现，接下来通过具体的实例来说明storm的使用。因为目前storm已经正式迁移到Apache，文章系列也由twitter storm转为apache storm. WordCountTopology 使用storm来统计文件中的每个单词的出现次数。 阅读全文

摘要：本文详细分析TridentTopology的可靠性实现, TridentTopology通过transactional spout与transactional state相结合，能够做到tuple“只被处理一次，不多也不少”。也就是做到事务性处理exactly-once,要么成功，要么失败。 而一般的storm topology是无法保证eactly-once的处理的，它们要么是at-least-once(至少被处理一次，有可能被处理多次)；要么是at-most-once（最多被处理一次，这样就存在遗漏的可能). TridentTopology在设计中借鉴和保留了目前已经过期的transactional topology的设计思想。 阅读全文

摘要：TridentTopology是storm提供的高层使用接口，常见的一些SQL中的操作在tridenttopology提供的api中都有类似的影射。关于TridentTopology的使用及运行原理，当前进行详细分析的文章不多。 从TridentTopology到vanilla topology(普通的topology)由三个层次组成： 面向最终用户的概念stream, operation 利用planner将tridenttopology转换成vanilla topology 执行vanilla topology 本文尝试TridentTopology是如何先一步步转换成普通的storm Topology(即vanila topology), 转换后的topology的执行中有哪些区别？ 阅读全文

摘要：本文从外部消息在worker进程内部的转化，传递及处理过程入手，一步步分析在worker-data中的数据项存在的原因和意义。试图从代码实现的角度来回答，如果是从头开始实现worker的话，该如何来定义消息接口，如何实现各自接口上的消息处理。 阅读全文

摘要：本文重点分析storm的worker进程在正常启动之后有哪些类型的线程，针对每种类型的线程，剖析其用途及消息的接收与发送流程。 阅读全文

摘要：storm cluster可以想像成为一个工厂，nimbus主要负责从外部接收订单和任务分配。除了从外部接单，nimbus还要将这些外部订单转换成为内部工作分配，这个时候nimbus充当了调度室的角色。supervisor作为中层干部，职责就是生产车间的主任，他的日常工作就是时刻等待着调度到给他下达新的工作。作为车间主任，supervisor领到的活是不用自己亲力亲为去作的，他手下有着一班的普通工人。supervisor对这些工人只会喊两句话，开工，收工。注意，讲收工的时候并不意味着worker手上的活已经干完了，只是进入休息状态而已。 阅读全文

摘要：本文尝试分析tuple发送时的两个问题，一是消息在线程间的传递过程及利用zeromq向外部进程发送细节，另一个是tuple的分发策略grouping是如何起作用的，本博的另一篇文章《bolt消息传递路径之源码解读》主要从消息接收方面来阐述问题，两篇文章互为补充。 阅读全文

摘要：本文详细介绍了twitter storm中的nimbus节点的启动场景，分析nimbus是如何一步步实现定义于storm.thrift中的service，以及如何利用curator来和zookeeper server建立通讯。 阅读全文

摘要：本文详细描述如何在archlinux上搭建twitter storm cluster,转载请注明出处，谢谢。 阅读全文

摘要：Bolt作为task被executor执行，而executor是一个个的线程，所以executor必须存在于具体的process之中，而这个process就是worker。至于worker是如何被supervisor创建，尔后worker又如何创建executor线程，这些暂且按下不表。 阅读全文