> 作者：幻好
> 來源：[恆生LIGHT雲社群](https://developer.hs.net/thread/post?type=1&operating=edit&threadId=1265)
>

> 大資料的價值在於把資料變成某一行為的結論，這一重要的過程成為資料分析。提到資料分析，大部分人首先想到的都是 Hadoop、流計算、機器學習等資料加工的方式。具體從整個過程來看，資料分析其實可以大致分為四個步驟：資料採集，資料儲存，資料計算，資料視覺化。
>
> 其中大資料的資料採集這一過程是最基礎，也是最重要的部分。針對具體的場景使用合適的採集工具，可以大大提高效率和可靠性，並降低資源成本。常用的開源工具 Flume、Logstash 和 Fluentd 等都是可以作為日誌採集的工具，本文將對常用資料採集工具使用場景優缺點等進行介紹分析。

## Flume

> Flume 是由 cloudera 軟體公司產出的可分散式日誌收集系統，後與2009年被捐贈了apache軟體基金會，為 Hadoop 相關元件之一。尤其近幾年隨著 flume 的不斷被完善以及升級版本的逐一推出，特別是flume-ng;同時flume內部的各種元件不斷豐富，使用者在開發的過程中使用的便利性得到很大的改善，現已成為apache top專案之一。

### 基本概念

Flume 是一種具備分散式、可靠性和可用性的服務，可以有效地收集、聚合和遷移大量日誌資料，是一個簡單和靈活基於流資料流架構。它具有較好的健壯性和容錯性，具有可調的可靠性機制和許多故障轉移和恢復機制。透過一個簡單的可擴充套件資料模型，允許線上分析應用程式。

![539316-20160710192411655-1258050429.jpg](https://developer.hs.net/storage/attachments/2021/08/01/7YqfNRNeSB8alYgsBLgFRZfzaQuRLYzJw03fVFhE_thumb.jpg "2420")

### 框架特性

1. **可靠性**

* 當節點出現故障時，日誌能夠被傳送到其他節點上而不會丟失。Flume 提供了三種級別的可靠性保障，從強到弱依次分別為：`end-to-end`（收到資料agent首先將 event 寫到磁碟上，當資料傳送成功後，再刪除；如果資料傳送失敗，可以重新傳送。），`Store on failure`（這也是scribe採用的策略，當資料接收方crash時，將資料寫到本地，待恢復後，繼續傳送），`Best effort`（資料傳送到接收方後，不會進行確認）。

2. **可擴充套件性**

* Flume 採用了三層架構，分別問`agent`，`collector` 和`storage` ，每一層均可以水平擴充套件。其中，所有`agent` 和`collector` 由`master` 統一管理，這使得系統容易監控和維護，且`master` 允許有多個（使用 ZooKeeper 進行管理和負載均衡），這就避免了單點故障問題。

3. **可管理性**

* 所有`agent` 和`colletor` 由`master` 統一管理，這使得系統便於維護。使用者可以在`master` 上檢視各個資料來源或者資料流執行情況，且可以對各個資料來源配置和動態載入。Flume提供了web 和shell script command兩種形式對資料流進行管理。

4. **功能可擴充套件性**

* 使用者可以根據需要新增自己的 agent ，colletor 或者 storage 。此外，Flume 自帶了很多元件，包括各種 agent（ file， syslog 等），collector 和 storage（file，HDFS 等）。

### 技術架構

Flume採用了分層架構，由三層組成，分別為 `agent` ，`collector` 和 `storage` 。其中，`agent` 和 `collector` 均由兩部分組成：`source` 和 `sink` ，`source` 是資料來源，`sink` 是資料去向。

![DevGuide_image00.png](https://developer.hs.net/storage/attachments/2021/08/01/nkLlkRtecdvRhFfFAcRUTFOYkhZsvgoAN4CkUOLz_thumb.png "2421")

1. **agent**

* 系統中最核心的角色是`agent` ，Flume 採集系統就是由一個個`agent` 所連線起來形成。
* 每一個`agent` 相當於一個資料傳遞員，內部有三個元件：
  * **source**: 採集源，用於跟資料來源對接，以獲取資料
  * **sink**：傳送資料的目的地，用於往下一級`agent` 或者最終儲存系統傳遞資料
  * **channel**：`agent` 內部的資料傳輸通道，用於從`source` 傳輸資料到`sink`

![539316-20160710201913405-993590950.jpg](https://developer.hs.net/storage/attachments/2021/08/01/jnUQ7NltNUepDjotE6bDClF3C1mvPIsSAs3LZf9v_thumb.jpg "2423")

* `agent` 的作用是將資料來源的資料傳送給`collector` ，Flume 自帶了很多直接可用的資料來源（source），如：
  * `text(“filename”)`：將檔案 filename 作為資料來源，按行傳送
  * `tail(“filename”)`：探測 filename 新產生的資料，按行傳送出去
  * `fsyslogTcp(5140)`：監聽 TCP 的5140埠，並且接收到的資料傳送出去
* Flume 自帶了很多`sink` ，如：
  * `console[("format")]`：直接將將資料顯示在桌面上
  * `text(“txtfile”)`：將資料寫到檔案 txtfile 中
  * `dfs(“dfsfile”)`：將資料寫到 HDFS 上的 dfsfile 檔案中
  * `syslogTcp(“host”,port)`：將資料透過 TCP 傳遞給 host 節點

2. **collector**
   * `collector` 的作用是將多個`agent` 的資料彙總後，載入到`storage` 中。它的`source` 和`sink` 與`agent` 類似。
   * 例項：
     * `agent` 監聽 TCP 的5140埠接收到的資料，併傳送給`collector` ，由`collector` 將資料載入到 HDFS 上。
     * ![051606433243093.jpg](https://developer.hs.net/storage/attachments/2021/08/01/whXFYzSiEImjvflhcxUztxVZNaXw7U1lCrsj2Y42_thumb.jpg "2424")

### 應用場景

在大資料時代，平臺會透過收集使用者的在平臺上操作，分析使用者的具體行為，然後推送個性化的資訊。比如我們在電商平臺上搜尋一些商品後 ，首頁會給使用者推送相應品類的商品。而 Flume 在其中充當了一個資料採集的角色，透過快速採集使用者的資訊，傳送給資料計算平臺分析後，實現個性化推送。

## Logstash

> Logstash 是一個具有實時流水線功能的開源資料收集引擎。Logstash 可以動態地統一來自不同來源的資料，並將資料規範化到我們選擇的目的地。為各種高階下游分析和視覺化用例清理和普及所有資料。任何型別的事件都可以透過大量的輸入、過濾和輸出外掛來豐富和轉換，許多本機編解碼器進一步簡化了輸入過程。

### 基本概念

Logstash 是基於 pipeline 方式進行資料處理的，pipeline 可以理解為資料處理流程的抽象。在一條 pipeline 資料經過上游資料來源彙總到**訊息佇列**中，然後由多個工作執行緒進行資料的轉換處理，最後輸出到下游元件。一個 Logstash 中可以包含多個 pipeline。

![logstash.png](https://developer.hs.net/storage/attachments/2021/08/01/ivvyMoUJMs0DOhK2HtmCtHeIrWxg4ibuGuXsvnQ3_thumb.png "2425")

### 框架特性

* 為 Elasticsearch 和更多的攝取工作的主力
  * 具有強大的 Elasticsearch 和 Kibana 協同功能的水平可擴充套件的資料處理管道
* 可拔插管道架構
  * 混合、匹配和協調不同的輸入、過濾器和輸出，在管道中和諧地發揮作用
* 良好的社群生態系統
  * 開發社群超過200個外掛可用，可以擴充套件建立自定義的外掛

### 工作原理

1. 處理過程

![7367005a46890c48d27e8518a14a1772.png](https://developer.hs.net/storage/attachments/2021/08/01/GtMd7tcKjGGZERRAhpwcA5yJSL2wTxBSQVMsWwz1_thumb.png "2426")

如上圖，Logstash的資料處理過程主要包括：**Inputs**, **Filters**, **Outputs** 三部分， 另外在Inputs和Outputs中可以使用**Codecs**對資料格式進行處理。這四個部分均以外掛形式存在，使用者透過定義pipeline配置檔案，設定需要使用的input，filter，output, codec外掛，以實現特定的資料採集，資料處理，資料輸出等功能

* **Inputs**：用於從資料來源獲取資料，常見的外掛如 file, syslog, redis, beats 等[[詳細參考](https://www.elastic.co/guide/en/logstash/5.6/input-plugins.html)]
* **Filters**：用於處理資料如格式轉換，資料派生等，常見的外掛如 grok, mutate, drop,  clone, geoip 等[[詳細參考](https://www.elastic.co/guide/en/logstash/5.6/output-plugins.html)]
* **Outputs**：用於資料輸出，常見的外掛如 elastcisearch，file, graphite, statsd 等[[詳細參考](https://www.elastic.co/guide/en/logstash/5.6/filter-plugins.html)]
* **Codecs**：Codecs 不是一個單獨的流程，而是在輸入和輸出等外掛中用於資料轉換的模組，用於對資料進行編碼處理，常見的外掛如json，multiline[[詳細參考](https://www.elastic.co/guide/en/logstash/5.6/codec-plugins.html)]

2.執行模型：

* 每個Input啟動一個執行緒，從對應資料來源獲取資料
* Input會將資料寫入一個佇列：預設為記憶體中的有界佇列（意外停止會導致資料丟失）。為了防止數丟失Logstash提供了兩個特性：[Persistent Queues](https://www.elastic.co/guide/en/logstash/current/persistent-queues.html)：透過磁碟上的queue來防止資料丟失[Dead Letter Queues](https://www.elastic.co/guide/en/logstash/current/dead-letter-queues.html)：儲存無法處理的event（僅支援Elasticsearch作為輸出源）
* Logstash會有多個 pipeline worker ，每一個 pipeline worker 會從佇列中取一批資料，然後執行 filter 和 output（worker數目及每次處理的資料量均由配置確定）

### 應用場景

**Elasticsearch**是當前主流的分散式大資料儲存和搜尋引擎，可以為使用者提供強大的全文字檢索能力，廣泛應用於日誌檢索，全站搜尋等領域。**Logstash**作為Elasicsearch常用的實時資料採集引擎，可以採集來自不同資料來源的資料，並對資料進行處理後輸出到多種輸出源，是Elastic Stack 的重要組成部分。

## Fluentd

### 基本概念

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

![v2-c37fbcf618cef081c071111ea1f61adf_720w.jpg](https://developer.hs.net/storage/attachments/2021/08/01/vmw5oDhD42GUs0RFYi64OGu25j7V9hmRFK28Drv0_thumb.jpg "2427")

### 框架特性

FLuentd 的擴充套件性非常好，客戶可以自己定製（Ruby）Input／Buffer／Output。 Fluentd從各方面看都很像Flume，區別是使用Ruby開發，Footprint 會小一些，但是也帶來了跨平臺的問題，並不能支援 Windows 平臺。另外採用 JSON 統一資料／日誌格式是它的另一個特點。相對於 Flumed ，配置也相對簡單一些。

Fluentd 的優點：

* 安裝方便
* 佔用空間小
* 半結構化資料日誌記錄
* 靈活的外掛機制
* 可靠的緩衝
* 日誌轉發

![v2-1d09d268a95c5a8835ddb56cf7f71e16_720w.jpg](https://developer.hs.net/storage/attachments/2021/08/01/n55KUQaFkVLzMBXBRjWy3slj9sm1gMbAYLEoySzV_thumb.jpg "2428")

### 技術架構

Fluentd 的架構設計和Flume如出一轍，Fluentd 的 Input／Buffer／Output 非常類似於 Flume 的 Source／Channel／Sink 。

![v2-ad29bdfffebabc8526595436c0004c98_720w.jpg](https://developer.hs.net/storage/attachments/2021/08/01/5tmxjHTslcjB7t896pU7v4g0DYAEgOFkIwbhHD3Q_thumb.jpg "2429")

* **Input**
  * Input 負責接收資料或者主動抓取資料。支援 syslog，http，file tail 等。
* **Buffer**
  * Buffer 負責資料獲取的效能和可靠性，也有檔案或記憶體等不同型別的 Buffer 可以配置。
* **Output**
  * Output 負責輸出資料到目的地例如檔案，AWS S3 或者其它的 Fluentd 。

## 總結

框架間的優劣對比：

| 維度     | Flume  | Logstash     | Fluentd       |
| -------- | ------ | ------------ | ------------- |
| 記憶體佔用 | 大     | 大           | 小            |
| 框架重量 | 重量級 | 重量級       | 輕量級        |
| 語言     | Java   | JRuby        | C和Ruby       |
| 效能     | 高效能 | 高效能       | 高效能        |
| 支援平臺 | 全平臺 | 全平臺       | 不支援windows |
| 外掛支援 | 多     | 較多         | 多            |
| 擴充套件性   | 一般   | 社群活躍度高 | 一般          |
| 叢集     | 分散式 | 單節點       | 單節點        |

* Flume 更注重於資料的傳輸，對於資料的預處理不如 Logstash 。
* 在傳輸上 Flume 比 Logstash 更可靠一些，因為資料會持久化在 channel 中。
* 資料只有儲存在sink 端中，才會從 channel 中刪除，這個過程是透過事物來控制的，保證了資料的可靠性。
* Logstash 是ELK元件中的一個，一般都是同 ELK 其它元件一起使用，更注重於資料的預處理，Logstash 有比 Flume 豐富的外掛可選，所以在擴充套件功能上比 Flume 全面。
* Logstash 內部沒有 persist queue，所以在異常情況下會出現資料丟失的問題
* Fluentd 的宣傳裡有高效能這一項，可能相對於 logstash 的確好很多，但還是不太夠。在實際使用中，解析 -> 轉換 -> 入庫 整個過程效能並不理想。
* Fluentd 的效能既因為 Ruby 消耗過多計算和記憶體資源，又因為 Ruby 難以受益與多核。對資料吞吐量大的業務來說它是很昂貴的。
* Fluentd 的外掛質量也不夠好，第三方外掛大多是使用者根據自己業務需要編寫，只為實現特定需求，沒有足夠的泛化，也沒有足夠的測試和效能評估。

大資料工程師入門系列—常用資料採集工具（Flume、Logstash 和 Fluentd）

相關文章