海量日志处理系统.docx
- 文档编号:12246882
- 上传时间:2023-04-17
- 格式:DOCX
- 页数:5
- 大小:18.94KB
海量日志处理系统.docx
《海量日志处理系统.docx》由会员分享,可在线阅读,更多相关《海量日志处理系统.docx(5页珍藏版)》请在冰豆网上搜索。
海量日志处理系统
海量日志处理系统
转载自董的博客http:
//dongxicheng.org/search-engine/log-systems/1.背景介绍许多公司的平台每天会产生大量的日志(一般为流式数据,如,搜索引擎的pv,查询等),处理这些日志需要特定的日志系统,一般而言,这些系统需要具有以下特征:
(1)构建应用系统和分析系统的桥梁,并将它们之间的关联解耦;
(2)支持近实时的在线分析系统和类似于Hadoop之类的离线分析系统;(3)具有高可扩展性。
即:
当数据量增加时,可以通过增加节点进行水平扩展。
本文从设计架构,负载均衡,可扩展性和容错性等方面对比了当今开源的日志系统,包括facebook的scribe,apache的chukwa,linkedin的kafka和cloudera的flume等。
2.FaceBook的ScribeScribe是facebook开源的日志收集系统,在facebook内部已经得到大量的应用。
它能够从各种日志源上收集日志,存储到一个中央存储系统(可以是NFS,分布式文件系统等)上,以便于进行集中统计分析处理。
它为日志的“分布式收集,统一处理”提供了一个可扩展的,高容错的方案。
它最重要的特点是容错性好。
当后端的存储系统crash时,scribe会将数据写到本地磁盘上,当存储系统恢复正常后,scribe将日志重新加载到存储系统中。
架构:
scribe的架构比较简单,主要包括三部分,分别为scribeagent,scribe和存储系统。
(1)scribeagentscribeagent实际上是一个thriftclient。
向scribe发送数据的唯一方法是使用thriftclient,scribe内部定义了一个thrift接口,用户使用该接口将数据发送给server。
(2)scribescribe接收到thriftclient发送过来的数据,根据配置文件,将不同topic的数据发送给不同的对象。
scribe提供了各种各样的store,如file,HDFS等,scribe可将数据加载到这些store中。
(3)存储系统存储系统实际上就是scribe中的store,当前scribe支持非常多的store,包括file(文件),buffer(双层存储,一个主储存,一个副存储),network(另一个scribe服务器),bucket(包含多个store,通过hash的将数据存到不同store中),null(忽略数据),thriftfile(写到一个ThriftTFileTransport文件中)和multi(把数据同时存放到不同store中)。
3.Apache的Chukwachukwa是一个非常新的开源项目,由于其属于hadoop系列产品,因而使用了很多hadoop的组件(用HDFS存储,用mapreduce处理数据),它提供了很多模块以支持hadoop集群日志分析。
需求:
(1)灵活的,动态可控的数据源
(2)高性能,高可扩展的存储系统(3)合适的框架,用于对收集到的大规模数据进行分析框架:
Chukwa中主要有3种角色,分别为:
adaptor,agent,collector。
(1)Adaptor数据源可封装其他数据源,如file,unix命令行工具等目前可用的数据源有:
hadooplogs,应用程序度量数据,系统参数数据(如linuxcpu使用流率)。
(2)HDFS存储系统Chukwa采用了HDFS作为存储系统。
HDFS的设计初衷是支持大文件存储和小并发高速写的应用场景,而日志系统的特点恰好相反,它需支持高并发低速率的写和大量小文件的存储。
需要注意的是,直接写到HDFS上的小文件是不可见的,直到关闭文件,另外,HDFS不支持文件重新打开。
(3)Collector和Agent为了克服
(2)中的问题,增加了agent和collector阶段。
Agent的作用:
给adaptor提供各种服务,包括:
启动和关闭adaptor,将数据通过HTTP传递给Collector;定期记录adaptor状态,以便crash后恢复。
Collector的作用:
对多个数据源发过来的数据进行合并,然后加载到HDFS中;隐藏HDFS实现的细节,如,HDFS版本更换后,只需修改collector即可。
(4)Demux和achieving直接支持利用MapReduce处理数据。
它内置了两个mapreduce作业,分别用于获取data和将data转化为结构化的log。
存储到datastore(可以是数据库或者HDFS等)中。
4.LinkedIn的KafkaKafka是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)ProducerProducer的任务是向broker发送数据。
Kafka提供了两种producer接口,一种是low_level接口,使用该接口会向特定的broker的某个topic下的某个partition发送数据;另一种那个是highlevel接口,该接口支持同步/异步发送数据,基于zookeeper的broker自动识别和负载均衡(基于Partitioner)。
其中,基于zookeeper的broker自动识别值得一说。
producer可以通过zookeeper获取可用的broker列表,也可以在zookeeper中注册listener,该listener在以下情况下会被唤醒:
a.添加一个broker
b.删除一个broker
c.注册新的topic
d.broker注册已存在的topic
当producer得知以上时间时,可根据需要采取一定的行动。
(2)BrokerBroker采取了多种策略提高数据处理效率,包括sendfile和zerocopy等技术。
(3)Consumerconsumer的作用是将日志信息加载到中央存储系统上。
kafka提供了两种consumer接口,一种是lowlevel的,它维护到某一个broker的连接,并且这个连接是无状态的,即,每次从broker上pull数据时,都要告诉broker数据的偏移量。
另一种是high-level接口,它隐藏了broker的细节,允许consumer从broker上push数据而不必关心网络拓扑结构。
更重要的是,对于大部分日志系统而言,consumer已经获取的数据信息都由broker保存,而在kafka中,由consumer自己维护所取数据信息。
5.Cloudera的FlumeFlume是cloudera于2009年7月开源的日志系统。
它内置的各种组件非常齐全,用户几乎不必进行任何额外开发即可使用。
设计目标:
(1)可靠性当节点出现故障时,日志能够被传送到其他节点上而不会丢失。
Flume提供了三种级别的可靠性保障,从强到弱依次分别为:
end-to-end(收到数据agent首先将event写到磁盘上,当数据传送成功后,再删除;如果数据发送失败,可以重新发送。
),Storeonfailure(这也是scribe采用的策略,当数据接收方crash时,将数据写到本地,待恢复后,继续发送),Besteffort(数据发送到接收方后,不会进行确认)。
(2)可扩展性Flume采用了三层架构,分别问agent,collector和storage,每一层均可以水平扩展。
其中,所有agent和collector由master统一管理,这使得系统容易监控和维护,且master允许有多个(使用ZooKeeper进行管理和负载均衡),这就避免了单点故障问题。
(3)可管理性所有agent和colletor由master统一管理,这使得系统便于维护。
用户可以在master上查看各个数据源或者数据流执行情况,且可以对各个数据源配置和动态加载。
Flume提供了web和shellscriptcommand两种形式对数据流进行管理。
(4)功能可扩展性用户可以根据需要添加自己的agent,colletor或者storage。
此外,Flume自带了很多组件,包括各种agent(file,syslog等),collector和storage(file,HDFS等)。
架构:
正如前面提到的,Flume采用了分层架构,由三层组成,分别为agent,collector和storage。
其中,agent和collector均由两部分组成:
source和sink,source是数据来源,sink是数据去向。
(1)agentagent的作用是将数据源的数据发送给collector,Flume自带了很多直接可用的数据源(source),如:
text(“filename”):
将文件filename作为数据源,按行发送tail(“filename”):
探测filename新产生的数据,按行发送出去fsyslogTcp(5140):
监听TCP的5140端口,并且接收到的数据发送出去同时提供了很多sink,如:
console[("format")]:
直接将将数据显示在桌面上text(“txtfile”):
将数据写到文件txtfile中dfs(“dfsfile”):
将数据写到HDFS上的dfsfile文件中syslogTcp(“host”,port):
将数据通过TCP传递给host节点
(2)collectorcollector的作用是将多个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中。
agentA,B将数据发送给collectorA,agentC,D将数据发送给collectorB,agentE,F将数据发送给collectorC。
同时,为每个agent添加end-to-end可靠性保障(Flume的三种可靠性保障分别由agentE2EChain,agentDFOChain,andagentBEChain实现),如,当collectorA出现故障时,agentA和agentB会将数据分别发给collectorB和collectorC。
下面是简写的配置文件片段:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
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");
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 海量 日志 处理 系统