分布式日志系统类比

背景
Google、Facebook、Amazon等互联网巨头对于数据的创造性使用,创造出了很多辉煌的商业产品。如Amazon创造出的新的推荐模式:”查询此商品的顾客也查询了。。。。。”、“看过此商品的后的顾客买的其他商品有。。。。。。”、“购买了您最近浏览过的商品的顾客同时购买了。。。。。。”,还有LinkedIn公司创造的“你可能认识的人”。这些机制无不是建立在大量数据分析的基础上。
 
分布式日志方案

作为互联网公司,每天庞大的日志数据将是一笔宝贵的财富,对大规模日志数据进行采集、追踪、处理将是非常有收益的。一些开源项目的出现,也极快地促进了这个方面工作的进展。

本文针对据目前流行的日志框架,主要根据互联网的一些资料,结合自己的一些了解,对一些关键因素进行横向的对比,比便对技术选型提供参考。

关键要素

配置(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,那么在一个星期内,这个消费者如果重启,它能够衔接上原来的顺序接着消费。


Flume

Flume是一个分布式、可靠、高可用的海量日志聚合系统,支持在系统中定制各类数据发送方,用于收集数据;同时,Flume提供对数据的简单处理,并写到各种数据接收方的能力。
Flume 在0.9.x and 1.x之间有较大的架构调整,1.x版本之后的改称Flume NG,0.9.x的称为Flume OG。New和Old的分界岭如下。

体系架构:
 
 

                           Flume NG 体系架构
 
 

                           Flume OG 体系架构

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。


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:负责数据的展示。


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中。
 

0 个评论

要回复文章请先登录注册