开源日志系统比较【转载+整理】

转载自 董的博客

原文地址 http://dongxicheng.org/search-engine/log-systems/

本文内容

• 概述
• Facebook 日志系统 Scribe
• Apache 日志系统 Chukwa
• Linkedin 日志系统 Kafka
• Cloudera 日志系统 Flume
• 总结
• 参考资料

本文转载自原文地址，同时整理了一下。其实，我不太理解这个网站，姑且不说，页面无法点击右键复制，连微软、Google、Sina  都开放源代码和自己的研究论文，只要地球人知道你辛苦收集的就可以了，至于吗。你所谓的“版权”可以理解，别的文章没看，但至少这篇应该不算原创吧，东拼西凑，只是提了些技术，再说，博主的文笔真是不敢恭维。要是不冲着文章技术，我实在不想看。如此封闭，你也配搞技术？

概述

---

        许多软件平台每天都会产生大量的日志（一般为流数据，如搜索引擎 page view，淘宝等），处理这些日志需要特定的日志系统，一般地，这些日志系统需要具有如下特征：

1. 构建应用系统和分析系统的桥梁，并将它们之间的关系解耦。
2. 支持接近实时在线分析系统，以及类似 Hadoop 之类的离线分析系统。
3. 具有高可扩展性，即当数据量增加时，可以通过增加节点进行横向扩展。

        本文从设计架构、负载均衡、可扩展性和容错性等方面对比目前开源的日志系统，包括 Facebook 日志系统 Scribe ，Apache 日志系统 Chukwa，Linkedin 日志系统 Kafka 和 Cloudera 日志系统 Flume 等。

Facebook 日志系统 Scribe

---

        Scribe 是 Facebook 开源日志系统，在 Facebook 内部已得到大量的应用。它能够从各种日志源上收集日志，再存储到一个中央存储系统（可以使用 NFS、分布式文件系统等），以便进行集中统计分析处理。Scribe 为日志的“分布式收集，统一处理”提供了一个可扩展的、高容错的方案。

        Scribe 最重要的特点是容错性好。当后端的存储系统 Crash 时，Scribe 会将数据写到本地磁盘。当存储系统恢复正常后，Scribe 将日志重新加载到存储系统中。

        Scribe 架构设计比较简单，包括三个部分：Agent、Scribe 和存储系统。

1）Agent。Scribe Agent 实际上是一个 Thrift Client。向 Scribe 发送数据的唯一方法是使用 Thrift Client，Scribe 内部定义了一个 Thrift 接口，用户 Client 使用该接口将数据发送给 Server。所谓 Thrift 是跨语言，Server 和 Client 通信的一个框架，支持多种协议，二进制，文本 Http 或 Json 等方式，提供高效的数据传输方式。

2）Scribe 接收到 Thrift Client 发送过来的数据，根据配置文件，将不同 topic 数据发送给不同对象。Scribe 提供了各种各样的存储方式，如 File、HDFS 等，Scribe 可以将数据加载到这些存储中。

3）存储系统。存储系统实际上是 Scribe 中的 Store，目前 Scribe 支持很多 Store，包括 File（文件），Buffer（双层存储，一个主存储，一个副存储），network（另一个 Scribe 服务器），bucket（多个 Store 的集合，通过 hash 将数据存储到不同 Store），null（忽略），thriftfile（写到一个 Thrift Tfile transport 文件）和 multi（把数据同时存储到不同的 Store）。

Apache 日志系统 Chukwa

---

        Chukwa 是一个非常新的开源项目，由于其属于 Hadoop 系列产品，因而使用了很多 Hadoop 组件（用 HDFS 存储，用 mapreduce 处理数据），它提供很多模块以支持 Hadoop 集群日志分析。

特点：

1）灵活性，动态可控的数据源。

2）高性能、高可扩展的存储系统。

3）合适的架构，用于对收集到的大规模数据进行分析。

        Chukwa 架构设计，主要有三个角色：Adaptor、Agent 和 Collector。

1）Adaptor 数据源

可封装其他数据源，如 file、Unix 命令行工具等。

目前可用的数据源有：Hadoop Logs，应用程序度量数据，系统参数数据（如 Linux CPU 使用流率）。

2）HDFS 存储系统

Chukwa 采用了 HDFS 作为存储系统。HDFS 的设计初衷是支持大文件存储、小并发高速写的场景，而日志系统的特点恰好相反，它需要支持高并发、低速率写和大量小文件的存储。需要注意的是，直接写到 HDFS 上的小文件是不可见的，直到关闭文件，另外，HDFS 不支持文件重新打开。

3）Agent 和 Collector

为了克服 2）中的问题，增加了 Agent 和 Collector 阶段。

Agent 作用是给 Adaptor 提供各种服务，包括启动和关闭 Adaptor，将数据通过 HTTP 传递给 Collector ；定期记录 Adaptor 状态，以便 Crash 后恢复。

Collector 作用是对多个数据源发送过来的数据进行合并，然后加载到 HDFS 中；隐藏 HDFS 的实现细节，如 HDFS 版本更换后，只需修改 Collector 即可。

4）demux 和 archieving

直接支持利用 mapreduce 处理数据。它内置了两个 mapreduce 作业，分别用于获得数据和将数据转换成结构化的日志，存储到 data store（可以是数据库或 HDFS 等）中。

Linkedin 日志系统 kafka

---

        Kafka 是 2010 年 12 月的开源项目，采用 Scala 语言编写，使用了多种效率优化机制，架构比较新颖（push/pull），更适合异构集群。

特点：

1）数据在磁盘上的存区代价为 O(1)。

2）高吞吐率，在普通服务器上每秒也能处理几十万条信息。

3）分布式架构，能够对消息分区。

4）支持将数据并行加载到 Hadoop。

        Kafka 架构实际上是一个消息发布订阅系统。producer 向某个 topic 发布消息，而 consumer 订阅某个 topic 消息，一旦有新的关于某个 topic 消息，broker 会发送给订阅它的所有 consumer。在 Kafka 中，消息是按 topic 组织，每个 topic 又会分为多个 partition，便于管理数据和进行负载均衡。另外，它使用 zookeeper 进行负载均衡。Kafka 有三个主要角色：producer、broker 和 consumer。

1）producer

producer 的任务是向 broker 发送数据。Kafka 提供两种 producer 接口：low-level 接口，向特定 broker 的某个 topic 下的某个 partition 发送数据；high-level 接口，该接口支持同步/异步发送数据，基于 zookeeper 的 broker 自动识别和负载均衡（基于 partition）。

值得一提的是，基于 zookeeper 的 broker 自动识别，producer 可以通过 zookeeper 获取可以的 broker 列表，也可以在 zookeeper 中注册 listener，该 listener 在一下情况会被唤醒：

a，添加一个 broker

b，删除一个 broker

c，注册新的 topic

d，注册已存在的 topic

当 producer 得知以上事件时，根据需要采取一定动作。

2）broker

broker 采取多种策略提高数据处理效率，包括 sendfile 和 zero-copy 等技术。

3）consumer

consumer 作用是将日志信息加载到中央存储系统。Kafka 提供两种接口：low-level 接口，维护到某个 broker 连接，并且这个连接是无状态的，即每次从 broker 上 pull 数据时，都要告诉 broker 数据的偏移量；high-level 接口，隐藏了 broker 细节，允许 consumer 从 broker 上 push 数据，而不必关心网络拓扑结构。更重要的是，对于大部分日志系统而言，consumer 已经获取的数据都由 broker 保存，而在 Kafka 中，由 consumer 自动维护所取数据信息。

Cloudera 日志系统 flume

---

        Flume 是 Cloudera 于 2009 年7月开源的日志系统。它内置的组件非常齐全，用户几乎不必进行任何额外的开发即可使用。

特点：

1）可靠性。当节点出现故障时，日志能够被传送到其他节点。flume 提供了三种级别的可靠性保障，从强到弱依次为：

• end-to-end，收到数据 Agent 首先将 Event 写到磁盘上，当数据发送成功后，再删除；如果数据发送失败，可以重新发送。
• store on failure，这也是 Scribe采用的策略，当数据接收方 Crash时，将数据写到本地，恢复后继续发送。
• best effor，数据发送到接收方后，不会进行确认。

2）可扩展性。Flume 采用三层架构，分别为 Agent、Collector 和 Storeage，每层均可横向扩展。其中，所有 Agent 和 Collector 由 master 统一管理，这使系统容易监控和维护，并且允许有多个 master（使用 zookeeper 进行管理和负载均衡），这就避免了单点故障问题。

3）可管理性。所有 Agent 和 Collector 由 master 统一管理，便于系统维护。用户可以在 master 上查看各个数据源或数据流执行情况，且可以对各个数据源配置和动态加载。Flume 提供了 Web 和 Shell Script Command 两种方式对数据流进行管理。

4）功能可扩展性。用户可以根据需要添加 Agent、Collector 或 Storeage。此外，Flume 自带了很多组件，包括各种 Agent（file、syslog 等），Collector 和 Storeage（file，HDFS 等）。

        Flume 采用三层架构：Agent、Collector 和 Storage。其中，Agent 和 Collector 均有两部分组成：Source 和 Sink，Source 是数据来源，Sink是数据去向。

1）Agent

agent 作用是，将数据源的数据发送给 Collector ，Flume 自带很多直接可用的数据源（Source ），如：

text("filename") - 将文件filename作为数据源，按行发送

tail("filename") - 探测filename新产生的数据，按行发送

fsyslogTcp(5140) - 监听 TPC 5140 端口，发送接收的数据

同时，提供了很多sink，如：

console[("format")] - 直接将数据显示在终端

text("txtfile") - 将数据写到 txtfile 文件

dfs("dfsfile") - 将数据写道 HDFS 上的 dfsfile 文件

syslogTcp("host",port) - 将数据通过 TCP 用指定端口发给 host 节点

2）Collector

Collector 作用是将多个 Agent 的数据汇总后，加载到storage中，它的 Source 和 Sink 跟 Agent 类似。

下面例子，Agent 监听 TCP 5140 端口，接收数据，并发送给 Collector ，由 Collector 将数据加载到 HDFS 上。

host : syslogTcp(5140) | agentSink("localhost", 35853);

collector : collectorSource(35853) | collectorSink("hdfs://namenode/user/flume/","syslog");

        下面是一个更复杂的例子。有 6 个 Agent，3 个 Collector，所有 Collector 均将数据导入 HDFS 中。Agent A、Agent B 将数据发送给 Collector A，Agent C、Agent D 将数据发送给 Collector B ，Agent C、Agent D 就爱那个数据发送给 Collector B。同时，为每个 Agent 添加 end-to-end 可靠性保障（Flume 的三种可靠性保障，分别有 agentE2EChain，agentDFOChain 和 agentBEChain实现），如当 Collector A 出现故障，Agent A 和 Agent B 将数据分别发送给 Collector B 和 Collector C。

下面是简写的配置文件片段：

agentA : src | agentE2EChain("collectorA:35853", "collectorB:35853);

agentB : src | agentE2EChain("collectorA:35853", "collectorC:35853);

agentC : src | agentE2EChain("collectorB:35853", "collectorA:35853);

agentD : src | agentE2EChain("collectorB:35853", "collectorC:35853);

agentE : src | agentE2EChain("collectorC:35853", "collectorA:35853);

agentF : src | agentE2EChain("collectorC:35853", "collectorB:35853);

collectorA : collectorSource(35853) | collectorSink("hdfs://...", "src");

collectorB : collectorSource(35853) | collectorSink("hdfs://...", "src");

collectorC : collectorSource(35853) | collectorSink("hdfs://...", "src");

此外，使用 autoE2EChain，当某个collector 出现故障，Flume 会自动探测一个可用的 Collector，并将数据定向到这个新的可用的 Collector 上。

3）Storage

Storage 是存储系统，可以是一个普通的file，也可以是 HDFS、HIVE、HBase 等。

总结

---

        根据这四个系统的架构，可以总结出典型的日志系统具备三个基本组件：Agent（封装数据源，将数据源中的数据发送给 Collector），Collector（接收多个 Agent 的数据，并进行汇总后导入后端的 Store中），Store（中央存储系统，应该具有可扩展性和可靠性，应该支持当前非常流行的 HDFS）。

	Scrib	Chukwa	Kafka	Flume
公司	Fackbook	Apach/Yahoo	LinkedIn	Cloudera
开源时间	2008年10月	2009年11月	2010年12月	2009年7月
实现语言	C/C++	Java	Scala	Java
架构	Push/Push	Push/Push	Push/Pull	Push/Push
容错性	Collector和store之间有容错机制，而Agent和collector之间的容错需用户自己实现	Agent定期记录发送给collector的数据偏移量，一旦出现故障，根据偏移量继续发送数据	Agent可以通过collector自动识别机制获取可用collector，store自己保存已获取数据的偏移量，一旦collector出现故障，可以根据偏移量继续发送	Agent与Collector，Collector与store之间都有容错机制，且提供一种级别的可靠性保证
均衡负载	无	无	使用 Zookeeper	使用 Zookeeper
可扩展性	好	好	好	好
Agent	Thrift Client，需要自己实现	自带一些 Agent，如获取 Hadoop Logs 的Agent	用户需要根据 Kafka 提供的 low-level和 high-level API 自己实现	提供丰富的 Agent
Collector	实际上是一个 Thrift Client		使用 sendfile、zero-copy 等技术提高性能	系统提供很多 Collector，可直接使用
Store	直接支持 HDFS	直接支持 HDFS	直接支持 HDFS	直接支持 HDFS
评价	设计简单，易于使用，但容错和均衡负载不够好，且资料较少	属于 Hadoop 系列产品，直接支持 Hadoop，目前版本升级较快，有待进一步完善	架构巧妙，非常适合异构集群，但系统较新，其稳定性有待验证	非常优秀

参考资料

---

• Scribe https://github.com/facebook/scribe
• Chukwa http://incubator.apache.org/chukwa/
• Kafka http://sna-projects.com/kafka/
• Flume https://github.com/cloudera/flume/
• TimeTunnel http://code.taobao.org/p/TimeTunnel/src/