1. 程式人生 > >六大主流大資料採集平臺架構分析

六大主流大資料採集平臺架構分析

大資料

  作者:HollyMike

  隨著大資料越來越被重視,資料採集的挑戰變的尤為突出。今天為大家介紹幾款資料採集平臺:

  Apache Flume、 Fluentd、 Logstash、 Chukwa 、Scribe、 Splunk Forwarder

  大資料平臺與資料採集

  任何完整的大資料平臺,一般包括以下的幾個過程:

  資料採集–>資料儲存–>資料處理–>資料展現(視覺化,報表和監控)

大資料

  其中,資料採集是所有資料系統必不可少的,隨著大資料越來越被重視,資料採集的挑戰也變的尤為突出。這其中包括:

  資料來源多種多樣

  資料量大

  變化快

  如何保證資料採集的可靠性的效能

  如何避免重複資料

  如何保證資料的質量

  我們今天就來看看當前可用的六款資料採集的產品,重點關注它們是如何做到高可靠,高效能和高擴充套件。

  1、Apache Flume

  Flume 是Apache旗下的一款開源、高可靠、高擴充套件、容易管理、支援客戶擴充套件的資料採集系統。 Flume使用JRuby來構建,所以依賴Java執行環境。

  Flume最初是由Cloudera的工程師設計用於合併日誌資料的系統,後來逐漸發展用於處理流資料事件。

大資料

  Flume設計成一個分散式的管道架構,可以看作在資料來源和目的地之間有一個Agent的網路,支援資料路由。

大資料

  每一個agent都由Source,Channel和Sink組成。

  Source

  Source負責接收輸入資料,並將資料寫入管道。Flume的Source支援HTTP,JMS,RPC,NetCat,Exec,Spooling Directory。其中Spooling支援監視一個目錄或者檔案,解析其中新生成的事件。

  Channel

  Channel 儲存,快取從source到Sink的中間資料。可使用不同的配置來做Channel,例如記憶體,檔案,JDBC等。使用記憶體效能高但不持久,有可能丟資料。使用檔案更可靠,但效能不如記憶體。

  Sink

  Sink負責從管道中讀出資料併發給下一個Agent或者最終的目的地。Sink支援的不同目的地種類包括:HDFS,HBASE,Solr,ElasticSearch,File,Logger或者其它的Flume Agent。

大資料

  Flume在source和sink端都使用了transaction機制保證在資料傳輸中沒有資料丟失。

大資料

  Source上的資料可以複製到不同的通道上。每一個Channel也可以連線不同數量的Sink。這樣連線不同配置的Agent就可以組成一個複雜的資料收集網路。通過對agent的配置,可以組成一個路由複雜的資料傳輸網路。

大資料

  配置如上圖所示的agent結構,Flume支援設定sink的Failover和Load Balance,這樣就可以保證即使有一個agent失效的情況下,整個系統仍能正常收集資料。

大資料

  Flume中傳輸的內容定義為事件(Event),事件由Headers(包含元資料,Meta Data)和Payload組成。

  Flume提供SDK,可以支援使用者定製開發:

  Flume客戶端負責在事件產生的源頭把事件傳送給Flume的Agent。客戶端通常和產生資料來源的應用在同一個程序空間。常見的Flume 客戶端有Avro,log4J,syslog和HTTP Post。另外ExecSource支援指定一個本地程序的輸出作為Flume的輸入。當然很有可能,以上的這些客戶端都不能滿足需求,使用者可以定製的客戶端,和已有的FLume的Source進行通訊,或者定製實現一種新的Source型別。

  同時,使用者可以使用Flume的SDK定製Source和Sink。似乎不支援定製的Channel。

  2、Fluentd

  Fluentd是另一個開源的資料收集框架。Fluentd使用C/Ruby開發,使用JSON檔案來統一日誌資料。它的可插拔架構,支援各種不同種類和格式的資料來源和資料輸出。最後它也同時提供了高可靠和很好的擴充套件性。Treasure Data, Inc 對該產品提供支援和維護。

大資料

  Fluentd的部署和Flume非常相似:

大資料

  Fluentd的架構設計和Flume如出一轍:

大資料

  Fluentd的Input/Buffer/Output非常類似於Flume的Source/Channel/Sink。

  Input

  Input負責接收資料或者主動抓取資料。支援syslog,http,file tail等。

  Buffer

  Buffer負責資料獲取的效能和可靠性,也有檔案或記憶體等不同型別的Buffer可以配置。

  Output

  Output負責輸出資料到目的地例如檔案,AWS S3或者其它的Fluentd。

  Fluentd的配置非常方便,如下圖:

大資料

  Fluentd的技術棧如下圖:

大資料

  FLuentd和其外掛都是由Ruby開發,MessgaePack提供了JSON的序列化和非同步的並行通訊RPC機制。

大資料

  Cool.io是基於libev的事件驅動框架。

  FLuentd的擴充套件性非常好,客戶可以自己定製(Ruby)Input/Buffer/Output。

  Fluentd從各方面看都很像Flume,區別是使用Ruby開發,Footprint會小一些,但是也帶來了跨平臺的問題,並不能支援Windows平臺。另外採用JSON統一資料/日誌格式是它的另一個特點。相對去Flumed,配置也相對簡單一些。

  3、Logstash

  Logstash是著名的開源資料棧ELK (ElasticSearch, Logstash, Kibana)中的那個L。

  Logstash用JRuby開發,所有執行時依賴JVM。

  Logstash的部署架構如下圖,當然這只是一種部署的選項。

大資料

  一個典型的Logstash的配置如下,包括了Input,filter的Output的設定。

大資料

  幾乎在大部分的情況下ELK作為一個棧是被同時使用的。所有當你的資料系統使用ElasticSearch的情況下,logstash是首選。

  4、Chukwa

  Apache Chukwa是apache旗下另一個開源的資料收集平臺,它遠沒有其他幾個有名。Chukwa基於Hadoop的HDFS和Map Reduce來構建(顯而易見,它用Java來實現),提供擴充套件性和可靠性。Chukwa同時提供對資料的展示,分析和監視。很奇怪的是它的上一次 github的更新事7年前。可見該專案應該已經不活躍了。

  Chukwa的部署架構如下:

大資料

  Chukwa的主要單元有:Agent,Collector,DataSink,ArchiveBuilder,Demux等等,看上去相當複雜。由於該專案已經不活躍,我們就不細看了。

  5、Scribe

  Scribe是Facebook開發的資料(日誌)收集系統。已經多年不維護,同樣的,就不多說了。

大資料

  6、Splunk Forwarder

  以上的所有系統都是開源的。在商業化的大資料平臺產品中,Splunk提供完整的資料採金,資料儲存,資料分析和處理,以及資料展現的能力。

  Splunk是一個分散式的機器資料平臺,主要有三個角色:Search Head負責資料的搜尋和處理,提供搜尋時的資訊抽取;Indexer負責資料的儲存和索引;Forwarder,負責資料的收集,清洗,變形,併發送給Indexer

大資料

  Splunk內建了對Syslog,TCP/UDP,Spooling的支援,同時,使用者可以通過開發 Input和Modular Input的方式來獲取特定的資料。在Splunk提供的軟體倉庫裡有很多成熟的資料採集應用,例如AWS,資料庫(DBConnect)等等,可以方便的從雲或者是資料庫中獲取資料進入Splunk的資料平臺做分析。

  這裡要注意的是,Search Head和Indexer都支援Cluster的配置,也就是高可用,高擴充套件的,但是Splunk現在還沒有針對Farwarder的Cluster的功能。也就是說如果有一臺Farwarder的機器出了故障,資料收集也會隨之中斷,並不能把正在執行的資料採集任務Failover到其它的 Farwarder上。

  總結

  我們簡單討論了幾種流行的資料收集平臺,它們大都提供高可靠和高擴充套件的資料收集。大多平臺都抽象出了輸入,輸出和中間的緩衝的架構。利用分散式的網路連線,大多數平臺都能實現一定程度的擴充套件性和高可靠性。

  其中Flume,Fluentd是兩個被使用較多的產品。如果你用ElasticSearch,Logstash也許是首選,因為ELK棧提供了很好的整合。Chukwa和Scribe由於專案的不活躍,不推薦使用。

  Splunk作為一個優秀的商業產品,它的資料採集還存在一定的限制,相信Splunk很快會開發出更好的資料收集的解決方案。