隨著大數(shù)據(jù)越來越被重視,數(shù)據(jù)采集的挑戰(zhàn)變的尤為突出。今天為大家介紹幾款數(shù)據(jù)采集平臺:
·Apache Flume
·Fluentd
·Logstash
·Chukwa
·Scribe
·Splunk Forwarder
大數(shù)據(jù)平臺與數(shù)據(jù)采集
任何完整的大數(shù)據(jù)平臺,一般包括以下的幾個過程:
數(shù)據(jù)采集-->數(shù)據(jù)存儲-->數(shù)據(jù)處理-->數(shù)據(jù)展現(xiàn)(可視化,報表和監(jiān)控)
圖1 數(shù)據(jù)采集
其中,數(shù)據(jù)采集是所有數(shù)據(jù)系統(tǒng)必不可少的,隨著大數(shù)據(jù)越來越被重視,數(shù)據(jù)采集的挑戰(zhàn)也變的尤為突出。這其中包括:
·數(shù)據(jù)源多種多樣
·數(shù)據(jù)量大
·變化快
·如何保證數(shù)據(jù)采集的可靠性的性能
·如何避免重復(fù)數(shù)據(jù)
·如何保證數(shù)據(jù)的質(zhì)量
我們今天就來看看當前可用的六款數(shù)據(jù)采集的產(chǎn)品,重點關(guān)注它們是如何做到高可靠,高性能和高擴展。
1、Apache Flume
Flume 是Apache旗下的一款開源、高可靠、高擴展、容易管理、支持客戶擴展的數(shù)據(jù)采集系統(tǒng)。 Flume使用JRuby來構(gòu)建,所以依賴Java運行環(huán)境。
Flume最初是由Cloudera的工程師設(shè)計用于合并日志數(shù)據(jù)的系統(tǒng),后來逐漸發(fā)展用于處理流數(shù)據(jù)事件。
圖2 Apache Flume
Flume設(shè)計成一個分布式的管道架構(gòu),可以看作在數(shù)據(jù)源和目的地之間有一個Agent的網(wǎng)絡(luò),支持數(shù)據(jù)路由。
圖3 Flume
每一個agent都由Source,Channel和Sink組成。
Source
Source負責(zé)接收輸入數(shù)據(jù),并將數(shù)據(jù)寫入管道。Flume的Source支持HTTP,JMS,RPC,NetCat,Exec,Spooling Directory。其中Spooling支持監(jiān)視一個目錄或者文件,解析其中新生成的事件。
Channel
Channel 存儲,緩存從source到Sink的中間數(shù)據(jù)?墒褂貌煌呐渲脕碜鯟hannel,例如內(nèi)存,文件,JDBC等。使用內(nèi)存性能高但不持久,有可能丟數(shù)據(jù)。使用文件更可靠,但性能不如內(nèi)存。
Sink
Sink負責(zé)從管道中讀出數(shù)據(jù)并發(fā)給下一個Agent或者最終的目的地。Sink支持的不同目的地種類包括:HDFS,HBASE,Solr,ElasticSearch,F(xiàn)ile,Logger或者其它的Flume Agent。
圖4 Sink
Flume在source和sink端都使用了transaction機制保證在數(shù)據(jù)傳輸中沒有數(shù)據(jù)丟失。
圖5 Flume
Source上的數(shù)據(jù)可以復(fù)制到不同的通道上。每一個Channel也可以連接不同數(shù)量的Sink。這樣連接不同配置的Agent就可以組成一個復(fù)雜的數(shù)據(jù)收集網(wǎng)絡(luò)。通過對agent的配置,可以組成一個路由復(fù)雜的數(shù)據(jù)傳輸網(wǎng)絡(luò)。
圖6 Source
配置如上圖所示的agent結(jié)構(gòu),F(xiàn)lume支持設(shè)置sink的Failover和LOAd Balance,這樣就可以保證即使有一個agent失效的情況下,整個系統(tǒng)仍能正常收集數(shù)據(jù)。
圖7 Flume
Flume中傳輸?shù)膬?nèi)容定義為事件(Event),事件由Headers(包含元數(shù)據(jù),Meta Data)和Payload組成。
Flume提供SDK,可以支持用戶定制開發(fā):
Flume客戶端負責(zé)在事件產(chǎn)生的源頭把事件發(fā)送給Flume的Agent?蛻舳送ǔ:彤a(chǎn)生數(shù)據(jù)源的應(yīng)用在同一個進程空間。常見的Flume 客戶端有Avro,log4J,syslog和HTTP Post。另外ExecSource支持指定一個本地進程的輸出作為Flume的輸入。當然很有可能,以上的這些客戶端都不能滿足需求,用戶可以定制的客戶端,和已有的FLume的Source進行通信,或者定制實現(xiàn)一種新的Source類型。
同時,用戶可以使用Flume的SDK定制Source和Sink。似乎不支持定制的Channel。
2、Fluentd
Fluentd是另一個開源的數(shù)據(jù)收集框架。Fluentd使用C/Ruby開發(fā),使用JSON文件來統(tǒng)一日志數(shù)據(jù)。它的可插拔架構(gòu),支持各種不同種類和格式的數(shù)據(jù)源和數(shù)據(jù)輸出。最后它也同時提供了高可靠和很好的擴展性。Treasure Data,Inc 對該產(chǎn)品提供支持和維護。
圖8 Fluentd
Fluentd的部署和Flume非常相似:
圖9 Fluentd
Fluentd的架構(gòu)設(shè)計和Flume如出一轍:
圖10 Fluentd
Fluentd的Input/Buffer/Output非常類似于Flume的Source/Channel/Sink。
Input
Input負責(zé)接收數(shù)據(jù)或者主動抓取數(shù)據(jù)。支持syslog,http,file tail等。
Buffer
Buffer負責(zé)數(shù)據(jù)獲取的性能和可靠性,也有文件或內(nèi)存等不同類型的Buffer可以配置。
Output
Output負責(zé)輸出數(shù)據(jù)到目的地例如文件,AWS S3或者其它的Fluentd。
Fluentd的配置非常方便,如下圖:
圖11 Fluentd的配置
Fluentd的技術(shù)棧如下圖:
圖12 Fluentd的技術(shù)棧
FLuentd和其插件都是由Ruby開發(fā),MessgaePack提供了JSON的序列化和異步的并行通信RPC機制。
圖13 FLuentd
Cool.io是基于libev的事件驅(qū)動框架。
FLuentd的擴展性非常好,客戶可以自己定制(Ruby)Input/Buffer/Output。
Fluentd從各方面看都很像Flume,區(qū)別是使用Ruby開發(fā),F(xiàn)ootprint會小一些,但是也帶來了跨平臺的問題,并不能支持Windows平臺。另外采用JSON統(tǒng)一數(shù)據(jù)/日志格式是它的另一個特點。相對去Flumed,配置也相對簡單一些。
3、Logstash
https://github.com/elastic/logstash
Logstash是著名的開源數(shù)據(jù)棧ELK (ElasticSearch,Logstash,Kibana)中的那個L。
Logstash用JRuby開發(fā),所有運行時依賴JVM。
Logstash的部署架構(gòu)如下圖,當然這只是一種部署的選項。
圖14 Logstash
一個典型的Logstash的配置如下,包括了Input,filter的Output的設(shè)置。
圖15 Logstash
幾乎在大部分的情況下ELK作為一個棧是被同時使用的。所有當你的數(shù)據(jù)系統(tǒng)使用ElasticSearch的情況下,logstash是首選。
4、Chukwa
Apache Chukwa是apache旗下另一個開源的數(shù)據(jù)收集平臺,它遠沒有其他幾個有名。Chukwa基于Hadoop的HDFS和Map Reduce來構(gòu)建(顯而易見,它用Java來實現(xiàn)),提供擴展性和可靠性。Chukwa同時提供對數(shù)據(jù)的展示,分析和監(jiān)視。很奇怪的是它的上一次 github的更新事7年前?梢娫擁椖繎(yīng)該已經(jīng)不活躍了。
Chukwa的部署架構(gòu)如下:
圖16 Chukwa
Chukwa的主要單元有:Agent,Collector,DataSink,ArchiveBuilder,Demux等等,看上去相當復(fù)雜。由于該項目已經(jīng)不活躍,我們就不細看了。
5、Scribe
Scribe是Facebook開發(fā)的數(shù)據(jù)(日志)收集系統(tǒng)。已經(jīng)多年不維護,同樣的,就不多說了。
圖17 Scribe
6、Splunk Forwarder
以上的所有系統(tǒng)都是開源的。在商業(yè)化的大數(shù)據(jù)平臺產(chǎn)品中,Splunk提供完整的數(shù)據(jù)采金,數(shù)據(jù)存儲,數(shù)據(jù)分析和處理,以及數(shù)據(jù)展現(xiàn)的能力。
Splunk是一個分布式的機器數(shù)據(jù)平臺,主要有三個角色:
·Search Head負責(zé)數(shù)據(jù)的搜索和處理,提供搜索時的信息抽取。
·Indexer負責(zé)數(shù)據(jù)的存儲和索引
·Forwarder,負責(zé)數(shù)據(jù)的收集,清洗,變形,并發(fā)送給Indexer
圖18 Splunk Forwarder
Splunk內(nèi)置了對Syslog,TCP/UDP,Spooling的支持,同時,用戶可以通過開發(fā) Input和Modular Input的方式來獲取特定的數(shù)據(jù)。在Splunk提供的軟件倉庫里有很多成熟的數(shù)據(jù)采集應(yīng)用,例如AWS,數(shù)據(jù)庫(DBConnect)等等,可以方便的從云或者是數(shù)據(jù)庫中獲取數(shù)據(jù)進入Splunk的數(shù)據(jù)平臺做分析。
這里要注意的是,Search Head和Indexer都支持Cluster的配置,也就是高可用,高擴展的,但是Splunk現(xiàn)在還沒有針對Farwarder的Cluster的功能。也就是說如果有一臺Farwarder的機器出了故障,數(shù)據(jù)收集也會隨之中斷,并不能把正在運行的數(shù)據(jù)采集任務(wù)Failover到其它的 Farwarder上。
總結(jié)
我們簡單討論了幾種流行的數(shù)據(jù)收集平臺,它們大都提供高可靠和高擴展的數(shù)據(jù)收集。大多平臺都抽象出了輸入,輸出和中間的緩沖的架構(gòu)。利用分布式的網(wǎng)絡(luò)連接,大多數(shù)平臺都能實現(xiàn)一定程度的擴展性和高可靠性。
其中Flume,F(xiàn)luentd是兩個被使用較多的產(chǎn)品。如果你用ElasticSearch,Logstash也許是首選,因為ELK棧提供了很好的集成。Chukwa和Scribe由于項目的不活躍,不推薦使用。
Splunk作為一個優(yōu)秀的商業(yè)產(chǎn)品,它的數(shù)據(jù)采集還存在一定的限制,相信Splunk很快會開發(fā)出更好的數(shù)據(jù)收集的解決方案。
核心關(guān)注:拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用,蘊涵了豐富的ERP管理思想,集成了ERP軟件業(yè)務(wù)管理理念,功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理,全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域,是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處:拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標題:六大主流大數(shù)據(jù)采集平臺架構(gòu)分析
本文網(wǎng)址:http://www.ezxoed.cn/html/support/11121819169.html