CxCo的专栏

Storm拥有多种配置来调整nimbus,supervisors的行为以及运行topologies。其中有些属于系统配置，我们无法在topology层面上进行更改(就是说有些系统配置我们是不能通过代码来改的)，其他的一些配置我们则可以通过在每个topology中调用相应的接口来设置。每个配置通过defaults.yaml设置默认值。我们可以通过在Nimbus以及supervisors中的cla

关于Storm中的并行度的问题，建议大家看看Storm的官网：http://storm.apache.org/documentation/Understanding-the-parallelism-of-a-Storm-topology.html （当然，我在博客中也翻译了这一篇文章）在storm中负责运行topology，主要用到了3个东西：worker（进程）、executor（线程）、t

本次在storm中进行jdbc批量insert的时候，jdbc使用了executebatch进行批量插入，老是报statement cancelled due to timeout or client request错误，因为插入的数据量比较大。（默认超时为30s）但是在本地自己测试往耗时是8秒。。。。最后，找到了问题所在。jdbc url配置的时候需要设置rewriteBatch

Trident是一个用来在storm上进行实时计算的高层抽象。它将使我们能够以延迟极低的分布式查询无缝的融合超大流量以及状态流处理。如果你对Pig或者Cascading这种的高层批处理工具很熟悉，那么Trident的概念就很容易理解了----Tridet拥有joins（连接）、aggregations（汇聚）、grouping（分组）、functions（函数）以及filters（过滤器）。除了这

Storm JDBC包含了核心的bolts以及trident states可以使storm topology即能对一个数据库表插入storm tuples又能对数据库进行查询操作，并且丰富了tuple的作用。注意：在下面的例子中，我们使用了 com.google.common.collect.Lists和com.google.common.collect.Maps.对数据库进行插入操作

运行时topology的组成：worker processes、executors(执行者线程)以及tasksStorm区分了以下三个主要的实体并用来在Storm集群上运行起一个topology:1.Worker processes2.Executors(线程)3.Tasks下面是这3者关系的一个简单示例:一个worker process负责执行topology的部

DRPC的主要作用就是利用Storm来完成那些计算密集型函数（CPU密集型函数）的实时并行计算。对于每一次函数调用，Storm topology将函数的参数当成是输入流，并且将函数运行的结果作为输出流。总体概览DRPC通过一个"DRPC server"来进行协调均衡。（Storm整合了DRPC server的一个实现）。DRPC server接受一个RPC请求，发送该请求给Storm to

Storm保证spout发出来的每条消息都会被完全的处理。这篇文章描述了Storm是如何实现这一保证机制的以及作为一个storm的使用者我们如何从storm的这种可靠性中获益。消息被"完整处理"的含义由spout发出来的一个tuple（元组）会触发下游更多的tuple的生成。让我们看你这个流单词计数的topology:TopologyBuilder builder = new

Storm集群的组成strom集群与hadoop集群表面上看还是很相似的。例如：在hadoop上你运行"MapReduce jobs",而在storm上运行的是"topologies"。"Jobs"和"topologies"是不一样的--一个主要的差别就是MapReduce job最终会运行完成并结束，而topology将会不停的运转来处理源源不断的流数据。（除非我们手动的kill进程，否则t

简介Storm有4个调度器(defaultScheduler/IsolationScheduler/MultitenantScheduler/RAS),Jstorm只有一个调度器，但是其拥有4种模式(defaultScheduler/IsolationScheduler/User-defined Scheduler/The last Scheduler)。默认调度算法（Defaul