随着大資料越來越被重視，資料采集的挑戰變的尤為突出。今天為大家介紹幾款資料采集平台：
apache flume fluentd logstash chukwa scribe splunk forwarder
大資料平台與資料采集
任何完整的大資料平台，一般包括以下的幾個過程：
資料采集–>資料存儲–>資料處理–>資料展現(可視化，報表和監控)
其中，資料采集是所有資料系統必不可少的，随着大資料越來越被重視，資料采集的挑戰也變的尤為突出。這其中包括：
資料源多種多樣
資料量大
變化快
如何保證資料采集的可靠性的性能
如何避免重複資料
如何保證資料的品質
我們今天就來看看目前可用的六款資料采集的産品，重點關注它們是如何做到高可靠，高性能和高擴充。
1、apache flume
官網：https://flume.apache.org/
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
官網：http://docs.fluentd.org/articles/quickstart
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
https://github.com/elastic/logstash
logstash是著名的開源資料棧elk (elasticsearch, logstash, kibana)中的那個l。
logstash用jruby開發，所有運作時依賴jvm。
logstash的部署架構如下圖，當然這隻是一種部署的選項。
一個典型的logstash的配置如下，包括了input，filter的output的設定。
幾乎在大部分的情況下elk作為一個棧是被同時使用的。所有當你的資料系統使用elasticsearch的情況下，logstash是首選。
4、chukwa
官網：https://chukwa.apache.org/
apache chukwa是apache旗下另一個開源的資料收集平台，它遠沒有其他幾個有名。chukwa基于hadoop的hdfs和map reduce來建構(顯而易見，它用java來實作)，提供擴充性和可靠性。chukwa同時提供對資料的展示，分析和監視。很奇怪的是它的上一次 github的更新事7年前。可見該項目應該已經不活躍了。
chukwa的部署架構如下：
chukwa的主要單元有：agent，collector，datasink，archivebuilder，demux等等，看上去相當複雜。由于該項目已經不活躍，我們就不細看了。
5、scribe
代碼托管：https://github.com/facebookarchive/scribe
scribe是facebook開發的資料(日志)收集系統。已經多年不維護，同樣的，就不多說了。
6、splunk forwarder
官網：http://www.splunk.com/
以上的所有系統都是開源的。在商業化的大資料平台産品中，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很快會開發出更好的資料收集的解決方案。
本文作者：hollymike
來源：51cto