分布计算系统框架，按照数据集的特点来说，主要分为data-flow和streaming两种。data-flow主要是以数据块为数据源来处理数据，代表有：MR、Spark等，我称作它们为大数据，而streaming主要是处理单位内得到的数据，这种方式，更注重于实时性，主要包括Strom、JStorm和Samza等，我称作它们为快数据。

在这篇文章中，我主要谈论streaming相关的框架。

第一个是Storm，一个实时计算系统，它假定数据源是动态的，可以向流水一样处理数据。

它的特点是：低延迟、高性能、分布式、可扩展和容错性。

架构如下图所示。

Storm的具体概念可以参照：http://blog.csdn.net/hljlzc2007/article/details/12976211，这里不做具体介绍。

Storm目前算是最最稳定的开源流式处理框架，但是个人认为它有两个问题。

1. Storm虽然支持多个语言编写spout和bolt端的代码，但是它的主要技术实现是clojure，这给玩大数据、开源的朋友带来了极大的不变，因为大家会的语言不是以java和C++等大众语言为主，这样的话，变得不可控了，难以深入了解、修改其细节。

2. Storm可以支持在Yarn(Hadoop 2.0)上，可以和其他开源框架共享Hadoop集群的资源，但是性能不佳，这个有待Storm改善

当然无论如何，Storm依然是目前开源流式处理框架的王者。

第二个我想说的是JStorm，这个是阿里做的，算是Storm的另一个实现，它用的语言是Java.

特点：

1. 客户端的API与Storm基本上是一致的，如果从Storm迁移过来，不需要修改bolt和spout的代码

2. Jstrom比Strom稳定，速度更快

3. 提供了一些新的特性

大家有兴趣可以去玩玩，项目地址https://github.com/alibaba/jstorm 

第三个是Samza

Samza是由LinkedIn开源的一个技术，它是一个开源的分布式流处理系统，非常类似于Storm。不同的是它运行在Hadoop之上，并且使用了自己开发的Kafka分布式消息处理系统。

这是Linkin开发的一个小而美的项目，如何美呢？

1. 只有几千行代码，完成的功能就可以和Storm媲美，当然目前还有很多的不足

2. 和Kafka结合紧密，更方便的处理数据

3. 运行在Yarn上

之前我做过的一个项目，是Kafka + Storm + ElasticSearch，将来完全可以将Storm替换成Samza，这样的话，还可以利用Hadoop集群的资源，做一些存储、离线分析的功能。将实时处理和离线分析都运行在Hadoop上，不得不说Samza是一个伟大的项目，这样可以减少项目的增长复杂度，利于维护，还是那句话，小而美的东西，更受欢迎一些。

架构：

Samza主要包含三层，

1. 流处理层 --> Kafka

2. 执行层     --> YARN

3. 处理层    --> Samza API

Samza的流处理层和执行层都是可插拔式的，开发人员可以使用其他框架来替代，不局限于上述两种技术。

Samza提供了一个YARN ApplicationMaster，和YARN job，运行在集群之外，下图中不同颜色代表不同的主机。

Samza客户端告诉YARN的Resouce Manager，它想启动一个Samza job， YARN RM 告诉YARN Node manager，分配空间给YARN ApplicationMaster，NM指定完空间后，YARN container会运行Samza Task Runner。

Samza状态管理

流式处理数据对状态的管理是很难的，由于数据是流动的，本身没有状态，这样就需要靠历史数据来记录应用的场合，Samza提供了一个内部的key-value数据库，它是基于LevelDB，运行的JVM之外的，使用它来存储历史数据。这样的做的好处是：

1. 减少JVM的开销

2. 使用内部存储，极大提高的吞吐率

3. 减少并发操作

Samza处理流程.

下图是Samza官方给的一例子，根据Member ID分组，计算页面访问次数。入口消息分别来自Machine1、2，出口是Machine3，我们可以这样理解，消息分散在不同的消息系统中（Kafka），Samza从不同的Kafka中读取topic，在将topic进行处理后，发送到Machine3，这里不做过多分解，具体可以参照官方文档。

项目地址：https://github.com/apache/incubator-samza

官方文件：http://samza.incubator.apache.org/

以上给了我们无限遐想，Storm是否会保持领先地位，Samza能否取而代之呢，无论如何，作为开发者来说，几千行代码，我都迫不及待去要读一下了。

1. 可自定义消息处理的步骤
   
   
2. 可自定义每种类型的消息需要多少个进程来处理
   
   
3. 每个步骤里的消息是在某个进程里的线程来做处理的
   
   
4. 可自定义每个步骤里的消息的线程数
   
   
5. 可以增加和删除要处理的消息类型

1. 定义数据来源组件(SPOUT)
   
   
2. 定义处理步骤(BOLT)
   
   
3. 组合成一个消息处理流程框架TOPOLOGY
   
   
4. 定义处理消息的进程的数量、定义每个步骤并发时可用的线程数
   
   
5. 部署TOPOLOGY

1. TOPOLOGY_WORKERS (set with setNumWorkers) specifies how many processes you want allocated around the cluster to execute the topology. Each component in the topology will execute as many threads. The number of threads allocated to a given component is configured through the setBolt and setSpout methods. Those threadsexist within worker processes. Each worker process contains within it some number of threads for some number of components. For instance, you may have 300 threads specified across all your components and 50 worker processes specified in your config. Each worker process will execute 6 threads, each of which of could belong to a different component. You tune the performance of Storm topologies by tweaking the parallelism for each component and the number of worker processes those threads should run within.
2. TOPOLOGY_DEBUG (set with setDebug), when set to true, tells Storm to log every message every emitted by a component. This is useful in local mode when testing topologies, but you probably want to keep this turned off when running topologies on the cluster.

There's many other configurations you can set for the topology. The various configurations are detailed on the Javadoc for Config.

Common configurations

There are a variety of configurations you can set per topology. A list of all the configurations you can set can be found here. The ones prefixed with "TOPOLOGY" can be overridden on a topology-specific basis (the other ones are cluster configurations and cannot be overridden). Here are some common ones that are set for a topology:

1. Config.TOPOLOGY_WORKERS: This sets the number of worker processes to use to execute the topology. For example, if you set this to 25, there will be 25 Java processes across the cluster executing all the tasks. If you had a combined 150 parallelism across all components in the topology, each worker process will have 6 tasks running within it as threads.
2. Config.TOPOLOGY_ACKERS: This sets the number of tasks that will track tuple trees and detect when a spout tuple has been fully processed. Ackers are an integral part of Storm's reliability model and you can read more about them onGuaranteeing message processing.
3. Config.TOPOLOGY_MAX_SPOUT_PENDING: This sets the maximum number of spout tuples that can be pending on a single spout task at once (pending means the tuple has not been acked or failed yet). It is highly recommended you set this config to prevent queue explosion.
4. Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS: This is the maximum amount of time a spout tuple has to be fully completed before it is considered failed. This value defaults to 30 seconds, which is sufficient for most topologies. SeeGuaranteeing message processing for more information on how Storm's reliability model works.
5. Config.TOPOLOGY_SERIALIZATIONS: You can register more serializers to Storm using this config so that you can use custom types within tuples.
   
   

1. 等数据增长到一定程度的时候，跑一个统计程序进行统计。适用于实时性要求不高的场景。
   如将数据导到HDFS，再运行一个MAP REDUCE JOB。
   
2. 如果实时性要求高的，上面的方法就不行了。因此就带来第二种方法。
   在数据每次增长一笔的时候，就进行统计JOB，结果放到DB或搜索引擎的INDEX中。
   STORM就是完成这种工作的。

1. 数据来源：HADOOP是HDFS上某个文件夹下的可能是成TB的数据，STORM是实时新增的某一笔数据
2. 处理过程：HADOOP是分MAP阶段到REDUCE阶段，STORM是由用户定义处理流程，
   流程中可以包含多个步骤，每个步骤可以是数据源(SPOUT)或处理逻辑(BOLT)
3. 是否结束：HADOOP最后是要结束的，STORM是没有结束状态，到最后一步时，就停在那，直到有新
   数据进入时再从头开始
4. 处理速度：HADOOP是以处理HDFS上大量数据为目的，速度慢，STORM是只要处理新增的某一笔数据即可
   可以做到很快。
5. 适用场景：HADOOP是在要处理一批数据时用的，不讲究时效性，要处理就提交一个JOB，STORM是要处理
   某一新增数据时用的，要讲时效性
   
6. 与MQ对比：HADOOP没有对比性，STORM可以看作是有N个步骤，每个步骤处理完就向下一个MQ发送消息，
   监听这个MQ的消费者继续处理