大數據系統數據採集產品的架構分析

任何完整的大數據平臺，通常包括如下的幾個過程：

1. 數據採集

2. 數據存儲

3. 數據處理

4. 數據展示（可視化，報表和監控）

其中，數據採集是全部數據系統必不可少的，隨着大數據愈來愈被重視，數據採集的挑戰也變的尤其突出。這其中包括：

• 數據源多種多樣

• 數據量大，變化快

• 如何保證數據採集的可靠性的性能

• 如何避免重複數據

• 如何保證數據的質量

咱們今天就來看看當前可用的一些數據採集的產品，重點關注一些它們是如何作到高可靠，高性能和高擴展。

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。

Fluentd

Fluentd （Github 地址）是另外一個開源的數據收集框架。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，配置也相對簡單一些。

Logstash

Logstash是著名的開源數據棧ELK（ElasticSearch，Logstash，Kibana）中的那個L。

Logstash用JRuby開發，全部運行時依賴JVM。

Logstash的部署架構以下圖，固然這只是一種部署的選項。

一個典型的Logstash的配置以下，包括了Input，filter的Output的設置。

input {
  file {
    type => "apache-access"
    path => "/var/log/apache2/other_vhosts_access.log"
  }

  file {
    type => "apache-error"
    path => "/var/log/apache2/error.log"
  }
}

filter {
  grok {
    match => { "message" => "%{COMBINEDAPACHELOG}" }
  }
  date {
  match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss Z" ]
  }
}

output {
  stdout { }
  redis {
    host => "192.168.1.200"
    data_type => "list"
    key => "logstash"
  }
}

幾乎在大部分的狀況下ELK做爲一個棧是被同時使用的。全部當你的數據系統使用ElasticSearch的狀況下，logstash是首選。

Chukwa

Apache Chukwa （github）是apache旗下另外一個開源的數據收集平臺，它遠沒有其餘幾個有名。Chukwa基於Hadoop的HDFS和Map Reduce來構建（顯而易見，它用Java來實現），提供擴展性和可靠性。Chukwa同時提供對數據的展現，分析和監視。很奇怪的是它的上一次github的更新事7年前。可見該項目應該已經不活躍了。

Chukwa的部署架構以下。

Chukwa的主要單元有：Agent，Collector，DataSink，ArchiveBuilder，Demux等等，看上去至關複雜。

因爲該項目已經不活躍，咱們就不細看了。

Scribe

Scribe是Facebook開發的數據（日誌）收集系統。已經多年不維護，一樣的，就很少說了。

Splunk Forwarder

以上的全部系統都是開源的，在商業化的大數據平臺產品中，Splunk提供完整的數據採金，數據存儲，數據分析和處理，以及數據展示的能力。

Splunk是一個分佈式的機器數據平臺，主要有三個角色：

• Search Head負責數據的搜索和處理，提供搜索時的信息抽取。

• Indexer負責數據的存儲和索引

• Forwarder，負責數據的收集，清洗，變形，併發送給Indexer

Splunk內置了對Syslog，TCP/UDP，Spooling的支持，同時，用戶能夠經過開發Script 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很快會開發出更好的數據收集的解決方案。

 

轉自 naughty的博客