FROM:http://go-on.iteye.com/blog/1789466
背景
分布式日志方案
作为互联网公司，每天庞大的日志数据将是一笔宝贵的财富，对大规模日志数据进行采集、追踪、处理将是非常有收益的。一些开源项目的出现，也极快地促进了这个方面工作的进展。
本文针对据目前流行的日志框架，主要根据互联网的一些资料，结合自己的一些了解，对一些关键因素进行横向的对比，比便对技术选型提供参考。
关键要素
配置（Configuration）
客服端如何发现服务端？（不好的方式：固定配置。好的方式：基于zookeeper的pub-sub） 怎么配置消息路由？（点对点；广播；通过brokers路由消息（kafka））
容错（Failure and Recovery）
当集群中的一个节点出错，系统是如何什么方式进行buffer的？ 系统是否保证数据传输过程的高可用，一旦发送，即保证到达。 系统是否支持树状集群。
维护管理（Maintenance）
本地的日志是否可以被配置成持久化，都提供了哪些支持？ 如果日志数据被发送，消息是否是有序的？
Kafka
Kafka是一个大型分布式日志框架，实际更是消息中间件（类似RabbitMQ,ActiveMQ,etc）。但是他不同于一般的消息中间件，不遵从消息队列的协议，一般消息中间件的协议里面消息是不能被消费者删除掉的（或者标记成删除）。 体系架构：
Kafka设计的目标：高吞吐量
数据被存储在OS pagecache，这使得消息的数据存储不能可能造成out of memory。Kafka
宣称他们改进了Varnish的pagecache-centric design。消息在brokers上被保存在文件上并建索引。消息根据到达的时间戳是有序的, 不产生二次索引,这样就可以很容易进行顺序文件访问和高效的磁盘扫描，即便是在数据量很大的情况下。文件通过Java中的 FileChannel.transferTo发送，操作系统层面是sendFile（），这样避免了额外的数据考虑。这个号称“Zero-copy”的机制比直接存内存的消息队列性能好上很多，具体原因可以看主创团队如何解释。
消息的状态维护是消费者自己负责的，通过Zookeeper来协调一致性。负载均衡和分布式消息的分区也是Zookeeper来实现的。这意味着，所有消息随机的分布在各个broker上，每个broker都注册到Zooker上。每个消息的生产者可以通过broker列表来选择一个broker去发送消息。Kafka在producer和broker层都不提供保障机制。消费端负责保存消息状态。但是Broker可以保留缓存一个固定时间段的消息。比如LinkderIn保留一个星期的数据在每个broker上，这意味着如果消费者fail，那么在一个星期内，这个消费者如果重启，它能够衔接上原来的顺序接着消费。
Pros
• 支持发布/订阅机制
• 通过OS pagecache + sendfile()，JVM内存占用低
• 客户端API支持多语言
• Brokers不保存状态，有助于吞吐量的提升
• 使用ZooKeeper来做配置管理和容错
Cons
• 用Scala开发实行，必须跑在JVM上
• 没有消息可靠性保证，必须自己去监控消息数据丢失
• 没有像Flume数据流的概念，必须通过订阅消息的方式
See Also
• Kafka Design Document
• Why is Kafka faster than other Message Queues?
• Really good presentation from LinkedIn on Kafka's architecture.
• Kafka whitepaper
Flume
Flume是一个分布式、可靠、高可用的海量日志聚合系统，支持在系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据的简单处理，并写到各种数据接收方的能力。
Flume 在0.9.x and 1.x之间有较大的架构调整，1.x版本之后的改称Flume NG，0.9.x的称为Flume OG。New和Old的分界岭如下。
体系架构：
Flume NG 体系架构
Flume NG在之前版本的基础上进行了重构和精简，去除了Zookeeper对于集中式配置管理、负载均衡和集群管理的支持，而专注于对数据流的采集和传输。对于每个服务器Node的配置，都需要自行在Node上配置。没法说这样的简化是好是坏，需求不一样，评价自然不同。因为Flume OG已经不再进行版本更新，所以后面讨论的Flume都是指Flume NG。
Flume Age是一个运行在JVM中的进程，主要任务是把Event（消息）从外部的一个source开始流向到下一个结点。Flune NG 有一个“数据流”的概念。
数据源（source）：消费Events消息，并把消息传递出去。比如一个Avro的source能够接收来自Avro客户端采集到的或者其他Agent的sink发送过来的Event消息。当source接收到Event，它把消息保存到一个或者多个channel中，直到消费者通过sink来消费Event。sink把消息从channel中移出，并放到外部的存储（如HDFS，通过HDFS sink）或者是把消息推向另外一个Flume Agent的source。
Flume提供了各种source的实现，包括Avro Source、Exce Source、Spooling Directory Source、NetCat Source、Syslog Source、Syslog TCP Source、Syslog UDP Source、HTTP Source、HDFS Source，etc。
Flume也提供了各种sink的实现，包括HDFS sink、Logger sink、Avro sink、File Roll sink、Null sink、HBase sink，etc。
Flume对于Channel，则提供了Memory Channel、JDBC Chanel、File Channel，etc。
Pros
可靠，多层消息容错保障机制。
由Cloudera支持，已经有整套的log到HDFS实现
基于配置部署即可，不需要额外的开发工作
source、sink、channel有丰富的协议、门类实现
Cons
Java实现，必须运行在JVM上
如果sink堵塞，会产生大量的备份日志
没有publish/subscribe机制
Flume已经停止开发，Flume NG的版本正在逐渐稳定中
负载均衡、集群管理、配置管理需要自己集成其他例如Zookeeper等框架实现
See Also
• Flume User Guide.
• Flume Cookbook.
• Issues to be aware of when using Flume in production.
• blog post about production trouble with Flume. (This guy might not know what he was doing though.)
• publish/subscribe upcoming in Flume-NG
Chuwa
Chukwa是Hadoop的一个子项目，致力于大规模日志收集和分析。Chukwa是建立在Hadoop分布式文件系统（HDFS）和MapReduce框架之上，并继承了Hadoop的可扩展性和鲁棒性。Chukwa还包括一个灵活，功能强大的工具包，用于显示监测和分析结果，以充分利用此收集的数据。
体系架构：
其中主要的部件为: 1. Agent：负责采集最原始的数据,并发送给collectors。Agent添加了“watchdog”机制，一旦agent出现故障，会自动重启终止的数据采集进程，防止数据源的数据丢失。 2. Adaptor： 直接采集数据的接口和工具，chukwa对以下常见的数据来源包括命令行输出、log 文件和 httpSender等提供了实现。一个 agent 可以管理多个 adaptor 的数据采集。 3. Collectors：负责收集 agents 收送来的数据,并定时写入集群中。Collector负责把大量小文件合并成少量大文件，再写入集群，以发挥hadoop在处理少量大文件上的优势。Collertor层实现了负载均衡，agent随机从列表中选择collertor来发送数据。 4. map/reduce jobs：定时启动,负责把集群中的数据分类、排序、去重和合并 5. HICC：负责数据的展示。
Pros
hadoop的子项目，有一套统一的大数据支持的生态环境 yahoo推动，版本更新较快 有监测和分析结果显示的web-portal工具 有对于大量少文件合并成少量大文件的处理，能够最大化hadoop威力 对于数据分类、排查，去重、合并，现成的方案实现 内置了两个mapreduce作业，分别用于获取data和将data转化为结构化的log。存储到datastore（可以是数据库或者HDFS等）中
Conns
数据收集和处理的实时性要求不高 Java实现，运行在JVM上 可供个性化实现的接口不多，除了Storage端 比较重量级的一套方案，适用于大型的集群
See Also
• Hadoop Wiki Chukwa
Scribe
Scribe是facebook开源的日志收集系统，在facebook内部已经得到大量的应用。 Scribe是基于一个使用非阻断C++服务器的thrift服务的实现。它能够从各种日志源上收集日志，存储到 一个中央存储系统 （可以是NFS，分布式文件系统等）上，以便于进行集中统计分析处理。它为日志的“分布式收集，统一处理”提供了一个可扩展的，高容错的方案。
体系架构：
Scribe从各种数据源上收集数据，放到一个共享队列上，然后push到后端的中央存储系上。当中央存储系统出现故障时，scribe可以暂时把日志写到本地文件中，待中央存储系统恢复性能后，scribe把本地日志续传到中央存储系统上。
(1) scribe agent scribe agent实际上是一个thrift client。 向scribe发送数据的唯一方法是使用thrift client，scribe内部定义了一个thrift接口，用户使用该接口将数据发送给server。 (2) scribe scribe接收到thrift client发送过来的数据，根据配置文件，将不同topic的数据发送给不同的对象。scribe提供了各种各样的store，如 file， HDFS等，scribe可将数据加载到这些store中。 (3) 存储系统 存储系统实际上就是scribe中的store，当前scribe支持非常多的store，包括file（文件），buffer（双层存储，一个主储存，一个副存储），network（另一个scribe服务器），bucket（包含多个 store，通过hash的将数据存到不同store中），null(忽略数据)，thriftfile（写到一个Thrift TFileTransport文件中）和multi（把数据同时存放到不同store中）。
Pros
多客户端语言支持（Thrift提供支持） C++实现 支持日志分类和自动切分（按照文件大小和时间切分） 配置简单、灵活
Conns
不再是一个活跃项目，Facebook正在逐渐冷落它 有可能会有单点故障（中心服务器、本地服务器、收集日志的客户端程序） 日志切换可能导致日志丢失
See Also
• Why did Facebook develop a new logging service?.
In particular check out Sam Rash's answer and presentation on Calligraphus and Facebook's data freeway.
• What's Up Scribe? - Otto's blog post on Scribe packaging and summary of Calligraphus.
概括
总的特性比对，可以用一张表概括之。比对表格
国内一些大型的互联网公司都各自在大数据的采集和分析上开始发力，同时也根据各自的情况“因地制宜”地发展了一些自己的日志系统，其实声势较大的首推淘宝的TimeTunnel。 TimeTunnel是一个基于thrift通讯框架搭建的实时数据传输平台，具有高性能、实时性、顺序性、高可靠性、高可用性、可扩展性等特点。TimeTunnel的设计和Kafka有一些类似，但是在不少地方都进行了改进。TimeTunnel在更新多个版本之后也已经开源，有兴趣的可以看看。