任何完整的大數據平台，一般包括以下的幾個過程：數據采集–>數據存儲–>數據處理–>數據展現(可視化，報表和監控)。
其中，「數據采集」是所有數據系統必不可少的，隨着大數據越來越被重視，「數據采集」的挑戰也變的尤為突出。這其中包括：
- 數據源多種多樣
- 數據量大
- 變化快
- 如何保證數據采集的可靠性的性能
- 如何避免重復數據
- 如何保證數據的質量
今天我們也來看看主流的幾個數據采集平台，重點關注它們是如何做到高可靠，高性能和高擴展。
Apache Flume
Flume 是 Apache 旗下的一款開源、高可靠、高擴展、容易管理、支持客戶擴展的數據采集系統。 Flume 使用 JRuby 來構建，所以依賴 Java 運行環境。
Flume 最初是由 Cloudera 的工程師設計，用於合並日志數據的系統，后來逐漸發展用於處理流數據事件。
Flume 設計成一個分布式的管道架構，可以看作在數據源和目的地之間有一個 Agent 的網絡，支持數據路由。
每一個 agent 都由 Source，Channel 和 Sink 組成。
Source
Source 負責接收輸入數據，並將數據寫入管道。它支持 HTTP、JMS、RPC、NetCat、Exec、Spooling Directory。其中 Spooling 支持監視一個目錄或者文件，解析其中新生成的事件。
Channel
Channel 存儲，緩存從 source 到 Sink 的中間數據。可使用不同的配置來做 Channel，例如內存、文件、JDBC等。使用內存性能高但不持久，有可能丟數據。使用文件更可靠，但性能不如內存。
Sink
Sink 負責從管道中讀出數據並發給下一個 Agent 或者最終的目的地。它支持的不同目的地種類包括：HDFS、HBASE、Solr、ElasticSearch、File、Logger 或者其它的 Flume Agent。
Flume 在 source 和 sink 端都使用了 transaction 機制保證在數據傳輸中沒有數據丟失。
Source 上的數據可以復制到不同的通道上。每一個 Channel 也可以連接不同數量的 Sink。這樣連接不同配置的 Agent 就可以組成一個復雜的數據收集網絡。通過對 agent 的配置，可以組成一個路由復雜的數據傳輸網絡。
配置如上圖所示。Flume 支持設置 sink 的 Failover 和 Load Balance，這樣就可以保證，即使有一個 agent 失效的情況下，整個系統仍能正常收集數據。
Flume 中傳輸的內容定義為事件(Event)，事件由 Headers(包含元數據，Meta Data)和 Payload 組成。
它提供 SDK，可以支持用戶定制開發。
其客戶端負責在事件產生的源頭把事件發送給 Flume 的 Agent。客戶端通常和產生數據源的應用在同一個進程空間。
常見的 Flume 客戶端有 Avro、log4J、syslog 和 HTTP Post。另外 ExecSource 支持指定一個本地進程的輸出作為 Flume 的輸入。
當然很有可能，以上的這些客戶端都不能滿足需求，用戶可以定制的客戶端，和已有的 FLume 的 Source 進行通信，或者定制實現一種新的 Source 類型。
同時，用戶可以使用 Flume 的 SDK 定制 Source 和 Sink。不過它似乎不支持定制的 Channel。
Fluentd
Fluentd 是另一個開源數據收集框架。它使用 C/Ruby 開發，用 JSON 文件來統一日志數據。它的可插拔架構，支持各種不同種類和格式的數據源和數據輸出。
它同時也提供高可靠和很好的擴展性。Treasure Data, Inc 對該產品提供支持和維護。
Fluentd 的部署和 Flume 非常相似：
其 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 機制。
FLuentd 的擴展性非常好，客戶可以自己定制 (Ruby)Input/Buffer/Output。
Fluentd 從各方面看都很像 Flume，區別是使用 Ruby 開發，Footprint 會小一些，但是也帶來了跨平台的問題，並不能支持 Windows 平台。
采用 JSON 統一數據/日志格式也是它的另一個特點。相對於 Flumed，配置也簡單一些。
Logstash
Logstash 是著名的開源數據棧 ELK (ElasticSearch, Logstash, Kibana) 中的那個 L。
它用 JRuby 開發，所有運行時依賴 JVM。
Logstash 的部署架構如下圖，當然這只是一種部署的選項。
一個典型的 Logstash 配置如下，包括了 Input、filter、Output 的設置。
幾乎在大部分的情況下，ELK 作為一個棧是被同時使用的。所以當你的數據系統使用 ElasticSearch 的情況下，logstash 是首選。
Chukwa
Apache Chukwa 是 apache 旗下另一個開源的數據收集平台，它遠沒有其他幾個有名。
Chukwa 基於 Hadoop 的 HDFS 和 Map Reduce 來構建(顯而易見，它用Java來實現)，提供擴展性和可靠性。它同時提供對數據的展示、分析和監視。奇怪的是，它的上一次 github 更新是7年前，可見該項目應該已經不活躍了。
Chukwa 的部署架構如下：
Chukwa 的主要單元有：Agent、Collector、DataSink、ArchiveBuilder、Demux 等等，看上去相當復雜。由於該項目已經不活躍，我們就不細看了。
Scribe
Scribe 是 Facebook 開發的數據(日志)收集系統。已經多年不維護，同樣的，就不多說了。
Splunk Forwarder
在商業化的大數據平台產品中，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 很快會開發出更好的數據收集的解決方案。
————————————————
版權聲明：本文為CSDN博主「o.o滄海一粟」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/weixin_43892898/article/details/89135175