对于一堆时刻在增长的数据，如果要统计，可以采取什么方法呢？
- 等数据增长到一定程度的时候，跑一个统计程序进行统计。适用于实时性要求不高的场景。
如将数据导到HDFS，再运行一个MAP REDUCE JOB。
- 如果实时性要求高的，上面的方法就不行了。因此就带来第二种方法。
在数据每次增长一笔的时候，就进行统计JOB，结果放到DB或搜索引擎的INDEX中。
STORM就是完成这种工作的。
HADOOP与STORM比较
- 数据来源：HADOOP是HDFS上某个文件夹下的可能是成TB的数据，STORM是实时新增的某一笔数据
- 处理过程：HADOOP是分MAP阶段到REDUCE阶段，STORM是由用户定义处理流程，
流程中可以包含多个步骤，每个步骤可以是数据源(SPOUT)或处理逻辑(BOLT) - 是否结束：HADOOP最后是要结束的，STORM是没有结束状态，到最后一步时，就停在那，直到有新
数据进入时再从头开始 - 处理速度：HADOOP是以处理HDFS上大量数据为目的，速度慢，STORM是只要处理新增的某一笔数据即可
可以做到很快。 - 适用场景：HADOOP是在要处理一批数据时用的，不讲究时效性，要处理就提交一个JOB，STORM是要处理
某一新增数据时用的，要讲时效性
- 与MQ对比：HADOOP没有对比性，STORM可以看作是有N个步骤，每个步骤处理完就向下一个MQ发送消息，
监听这个MQ的消费者继续处理
首先要明白Storm和Hadoop的应用领域，注意加粗、标红的关键字。
Hadoop是基于Map/Reduce模型的，处理海量数据的离线分析工具。
Storm是分布式的、实时数据流分析工具，数据是源源不断产生的，例如Twitter的Timeline。
再回到你说的速度问题，只能说Storm更适用于实时数据流，Map/Reduce模型在实时领域很难有所发挥，不能简单粗暴的说谁快谁慢。
这里的快主要是指的时延。
storm的网络直传、内存计算，其时延必然比hadoop的通过hdfs传输低得多；当计算模型比较适合流式时，storm的流式处理，省去了批处理的收集数据的时间；因为storm是服务型的作业，也省去了作业调度的时延。所以从时延上来看，storm要快于hadoop。
说一个典型的场景，几千个日志生产方产生日志文件，需要进行一些ETL操作存入一个数据库。
假设利用hadoop，则需要先存入hdfs，按每一分钟切一个文件的粒度来算（这个粒度已经极端的细了，再小的话hdfs上会一堆小文件），hadoop开始计算时，1分钟已经过去了，然后再开始调度任务又花了一分钟，然后作业运行起来，假设机器特别多，几钞钟就算完了，然后写数据库假设也花了很少的时间，这样，从数据产生到最后可以使用已经过去了至少两分多钟。
而流式计算则是数据产生时，则有一个程序去一直监控日志的产生，产生一行就通过一个传输系统发给流式计算系统，然后流式计算系统直接处理，处理完之后直接写入数据库，每条数据从产生到写入数据库，在资源充足时可以在毫秒级别完成。
当然，跑一个大文件的wordcount，本来就是一个批处理计算的模型，你非要把它放到storm上进行流式的处理，然后又非要让等所有已有数据处理完才让storm输出结果，这时候，你再把它和hadoop比较快慢，这时，其实比较的不是时延，而是比较的吞吐了。
Hadoop M/R基于HDFS，需要切分输入数据、产生中间数据文件、排序、数据压缩、多份复制等，效率较低。
Storm 基于ZeroMQ这个高性能的消息通讯库，不持久化数据。
kafka是一种高吞吐量的分布式发布订阅消息系统，她有如下特性：
通过O(1)的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。
高吞吐量：即使是非常普通的硬件kafka也可以支持每秒数十万的消息。
支持通过kafka服务器和消费机集群来分区消息。
支持Hadoop并行数据加载。
设计侧重高吞吐量，用于好友动态，相关性统计，排行统计，访问频率控制，批处理等系统。大部分的消息中间件能够处理实时性要求高的消息/数据，但是对于队列中大量未处理的消息/数据在持久性方面比较弱。
kakfa的consumer使用拉的方式工作。
安装kafka下载：http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating/kafka-0.7.0-incubating-src.tar.gz
> tar xzf kafka-.tgz
> cd kafka-
> ./sbt update
> ./sbt package
启动zkserver:
bin/zookeeper-server-start.sh config/zookeeper.properties
启动server:
bin/kafka-server-start.sh config/server.properties
就是这么简单。
使用kafka
import java.util.Arrays;
import java.util.List;
import java.util.Properties;
import kafka.javaapi.producer.SyncProducer;
import kafka.javaapi.message.ByteBufferMessageSet;
import kafka.message.Message;
import kafka.producer.SyncProducerConfig;
Properties props =
new Properties();
props.put(“zk.connect”, “127.0.0.1:2181”);
props.put("serializer.class", "kafka.serializer.StringEncoder");
ProducerConfig config =
new ProducerConfig(props);
Producer<String, String> producer =
new Producer<String, String>(config);
Send a single message
// The message is sent to a randomly selected partition registered in ZK
ProducerData<String, String> data =
new ProducerData<String, String>("test-topic", "test-message");
producer.send(data);
producer.close();
这样就是一个标准的producer。
consumer的代码
// specify some consumer properties
Properties props = new Properties();
props.put("zk.connect", "localhost:2181");
props.put("zk.connectiontimeout.ms", "1000000");
props.put("groupid", "test_group");
// Create the connection to the cluster
ConsumerConfig consumerConfig = new ConsumerConfig(props);
ConsumerConnector consumerConnector = Consumer.createJavaConsumerConnector(consumerConfig);
// create 4 partitions of the stream for topic “test”, to allow 4 threads to consume
Map<String, List<KafkaMessageStream<Message>>> topicMessageStreams =
consumerConnector.createMessageStreams(ImmutableMap.of("test", 4));
List<KafkaMessageStream<Message>> streams = topicMessageStreams.get("test");
// create list of 4 threads to consume from each of the partitions
ExecutorService executor = Executors.newFixedThreadPool(4);
// consume the messages in the threads
for(final KafkaMessageStream<Message> stream: streams) {
executor.submit(new Runnable() {
public void run() {
for(Message message: stream) {
// process message
}
}
});
}
日志抓取端：
apache kafka在数据处理中特别是日志和消息的处理上会有很多出色的表现，这里写个索引，关于kafka的文章暂时就更新到这里，最近利用空闲时间在对kafka做一些功能性增强，并java化，虽然现在已经有很多这样的版本，但是根据实际需求来改变才是最适合的。
首先当然推荐的是kafka的官网 http://kafka.apache.org/
在官网最值得参考的文章就是kafka design：http://kafka.apache.org/design.html，我的文章也基本都是参照这里的说明，大家要特别重视这篇文章，里面有好多理念都特别好，推荐多读几遍。
在OSC的翻译频道有kafka design全中文的翻译，翻得挺好的，推荐一下：http://www.oschina.net/translate/kafka-design
kafka的wiki是很不错的学习文档：https://cwiki.apache.org/confluence/display/KAFKA/Index
——————————————————————————————————
接下来就是我写的一系列文章，文章都是循序渐进的方式带你了解kafka：
关于kafka的基本知识，分布式的基础：《分布式消息系统Kafka初步》
kafka的分布式搭建，quick start：《kafka分布式环境搭建》
关于kafka的实现细节，这主要就是讲design的部分：《细节上》、《细节下》
关于kafka开发环境，scala环境的搭建：《开发环境搭建》
数据生产者，producer的用法：《producer的用法》、《producer使用注意》
数据消费者，consumer的用法：《consumer的用法》
还有些零碎的，关于通信段的源码解读：《net包源码解读》、《broker配置》
——————————————————————————————————
扩展的阅读还有下面这些：
我的好友写的关于kafka和jafka的相关博客，特别好，我有很多问题也都找他解决的，大神一般的存在：http://rockybean.github.com/ @rockybean
kafka的java化版本jafka：https://github.com/adyliu/jafka
淘宝的metaQ：https://github.com/killme2008/Metamorphosis
我最近在写的inforQ，刚开始写，我也纯粹是为了读下源码，不定期更新哈：https://github.com/ielts0909/inforq
后面一阶段可能更新点儿关于cas的东西吧，具体也没想好，最近一直出差，写代码的时间都很少
--------------------------------------------------------------------------------
0.8版本的相关更新如下：
0.8更新内容介绍：《kafka0.8版本的一些更新》
如果简单地比较Redis与Memcached的区别，大多数都会得到以下观点：
1 Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，hash等数据结构的存储。
2 Redis支持数据的备份，即master-slave模式的数据备份。
3 Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
在Redis中，并不是所有的数据都一直存储在内存中的。这是和Memcached相比一个最大的区别（我个人是这么认为的）。
Redis只会缓存所有的key的信息，如果Redis发现内存的使用量超过了某一个阀值，将触发swap的操作，Redis根据“swappability = age*log(size_in_memory)”计算出哪些key对应的value需要swap到磁盘。然后再将这些key对应的value持久化到磁盘中，同时在内存中清除。这种特性使得Redis可以保持超过其机器本身内存大小的数据。当然，机器本身的内存必须要能够保持所有的key，毕竟这些数据是不会进行swap操作的。
同时由于Redis将内存中的数据swap到磁盘中的时候，提供服务的主线程和进行swap操作的子线程会共享这部分内存，所以如果更新需要swap的数据，Redis将阻塞这个操作，直到子线程完成swap操作后才可以进行修改。
可以参考使用Redis特有内存模型前后的情况对比：
VM off: 300k keys, 4096 bytes values: 1.3G used
VM on: 300k keys, 4096 bytes values: 73M used
VM off: 1 million keys, 256 bytes values: 430.12M used
VM on: 1 million keys, 256 bytes values: 160.09M used
VM on: 1 million keys, values as large as you want, still: 160.09M used
当从Redis中读取数据的时候，如果读取的key对应的value不在内存中，那么Redis就需要从swap文件中加载相应数据，然后再返回给请求方。这里就存在一个I/O线程池的问题。在默认的情况下，Redis会出现阻塞，即完成所有的swap文件加载后才会相应。这种策略在客户端的数量较小，进行批量操作的时候比较合适。但是如果将Redis应用在一个大型的网站应用程序中，这显然是无法满足大并发的情况的。所以Redis运行我们设置I/O线程池的大小，对需要从swap文件中加载相应数据的读取请求进行并发操作，减少阻塞的时间。
redis、memcache、mongoDB 对比
从以下几个维度，对redis、memcache、mongoDB 做了对比，欢迎拍砖
1、性能
都比较高，性能对我们来说应该都不是瓶颈
总体来讲，TPS方面redis和memcache差不多，要大于mongodb
2、操作的便利性
memcache数据结构单一
redis丰富一些，数据操作方面，redis更好一些，较少的网络IO次数
mongodb支持丰富的数据表达，索引，最类似关系型数据库，支持的查询语言非常丰富
3、内存空间的大小和数据量的大小
redis在2.0版本后增加了自己的VM特性，突破物理内存的限制；可以对key value设置过期时间（类似memcache）
memcache可以修改最大可用内存,采用LRU算法
mongoDB适合大数据量的存储，依赖操作系统VM做内存管理，吃内存也比较厉害，服务不要和别的服务在一起
4、可用性（单点问题）
对于单点问题，
redis，依赖客户端来实现分布式读写；主从复制时，每次从节点重新连接主节点都要依赖整个快照,无增量复制，因性能和效率问题，
所以单点问题比较复杂；不支持自动sharding,需要依赖程序设定一致hash 机制。
一种替代方案是，不用redis本身的复制机制，采用自己做主动复制（多份存储），或者改成增量复制的方式（需要自己实现），一致性问题和性能的权衡
Memcache本身没有数据冗余机制，也没必要；对于故障预防，采用依赖成熟的hash或者环状的算法，解决单点故障引起的抖动问题。
mongoDB支持master-slave,replicaset（内部采用paxos选举算法，自动故障恢复）,auto sharding机制，对客户端屏蔽了故障转移和切分机制。
5、可靠性（持久化）
对于数据持久化和数据恢复，
redis支持（快照、AOF）：依赖快照进行持久化，aof增强了可靠性的同时，对性能有所影响
memcache不支持，通常用在做缓存,提升性能；
MongoDB从1.8版本开始采用binlog方式支持持久化的可靠性
6、数据一致性（事务支持）
Memcache 在并发场景下，用cas保证一致性
redis事务支持比较弱，只能保证事务中的每个操作连续执行
mongoDB不支持事务
7、数据分析
mongoDB内置了数据分析的功能(mapreduce),其他不支持
8、应用场景
redis：数据量较小的更性能操作和运算上
memcache：用于在动态系统中减少数据库负载，提升性能;做缓存，提高性能（适合读多写少，对于数据量比较大，可以采用sharding）
MongoDB:主要解决海量数据的访问效率问题