基於Flume、Kafka、Storm搭建海量資料採集應用
大資料時代，海量資料採集應用是企業大資料平臺關鍵技術之一。尤其是對來自於智慧化裝置、多感測器、原生日誌等實時性高、體量大、多源異構的大量資料，如何搭建一套先進、高效、穩定和靈活的實時大資料採集技術架構體系呢？本文提出一種基於Flume、Kafka、Storm、Zookeeper技術搭建實時大資料採集的技術架構，包括Flume採集、Kafka叢集、Storm叢集。
Kafka叢集： Kafka是一種高吞吐量的分散式釋出訂閱訊息系統，它可以處理消費者規模的網站中的所有動作流資料。Kafka的目的是通過Hadoop的並行載入機制來統一線上和離線的訊息處理，也是為了通過叢集來提供實時的訊息。
Zookeeper叢集： 是一個為Kafka的分散式應用提供一致性服務的軟體，提供的功能包括：配置維護、域名服務、分散式同步、組服務等。Zookeeper可以實現封裝好複雜易出錯的關鍵服務，將簡單易用的介面和效能高效、功能穩定的系統提供給使用者。
Flume： 用於收集資料到Kafka。Flume的意義在於：當收集資料的速度超過將寫入資料的時候，也就是當收集資訊遇到峰值時，這時候收集的資訊非常大，甚至超過了系統的寫入資料能力，這時候，Flume會在資料生產者和資料收容器間做出調整，保證其能夠在兩者之間提供平穩的資料。
資料採集應用技術架構圖如下：
技術架構
採用Flume收集智慧裝置、感測器、原生日誌等資料來源實時產生的資料，並將實時資料推送至Kafka訊息佇列中，繼而由Storm線上實時處理。最後，根據業務應用要求，將資料儲存在Redis、MySQL、MongoDB等媒介。
同時，由Zookeeper叢集管理，這樣即使Kafka宕機重啟後也能找到上次的消費記錄，接著從上次宕機點繼續從Kafka的Broker中進行消費。但是由於存在先消費後記錄日誌或者先記錄後消費的非原子操作，如果出現剛好消費完一條訊息並還沒將資訊記錄到Zookeeper的時候就宕機的類似問題，或多或少都會存在少量資料丟失或重複消費的問題, 其中一個解決方案就是Kafka的Broker和Zookeeper都部署在同一臺機子上。接下來就是使用使用者定義好的Storm Topology去進行資料的分析並輸出到Redis快取資料庫中(也可以進行持久化)。之所以在Flume和Storm中間加入一層Kafka訊息系統，就是因為在高併發的條件下, 資料會井噴式增長，如果Storm的消費速度(Storm的實時計算能力那是最快之一,但是也有例外, 而且據說現在Twitter的開源實時計算框架Heron比Storm還要快)慢於資料的產生速度，加上Flume自身的侷限性，必然會導致大量資料滯後並丟失，所以加了Kafka訊息系統作為資料緩衝區，而且Kafka是基於log File的訊息系統，也就是說訊息能夠持久化在硬碟中，再加上其充分利用Linux的I/O特性,提供了可觀的吞吐量。架構中使用Redis作為資料庫也是因為在實時的環境下，Redis具有很高的讀寫速度。