kafka實時數據流寫入HDFS

 

 

一、摘要

　　impala作為實時數據分析引擎，其源數據時效性要求不同，主要分為離線數據分析和實時數據分析。離線數據分析應用場景下，可以利用hive離線加載數據。實時數據分析則依靠kafka（高吞吐量的消息發布訂閱系統）。

二、kafka介紹

　　 kafka是一種高吞吐量的分布式發布訂閱消息系統，它可以處理消費者規模的網站中的所有動作流數據。這種動作（網頁瀏覽，搜索和其他用戶的行動）是在現代網絡上的許多社會功能的一個關鍵因素。這些數據通常是由於吞吐量的要求而通過處理日志和日志聚合來解決。

　　組件：

• producer：生產者。
• consumer：消費者。
• topic: 消息以topic為類別記錄,Kafka將消息種子(Feed)分門別類,每一類的消息稱之為一個主題(Topic)。
• broker：以集群的方式運行,可以由一個或多個服務組成，每個服務叫做一個broker;消費者可以訂閱一個或多個主題(topic),並從Broker拉數據,從而消費這些已發布的消息。

      每個消息（也叫作record記錄,也被稱為消息）是由一個key，一個value和時間戳構成。

 主題和日志

Topic是發布的消息的類別或者種子Feed名。對於每一個Topic，Kafka集群維護這一個分區的log，就像下圖中的示例：

 

每一個分區都是一個順序的、不可變的消息隊列， 並且可以持續的添加。分區中的消息都被分了一個序列號，稱之為偏移量(offset)，在每個分區中此偏移量都是唯一的。

Kafka集群保持所有的消息，直到它們過期， 無論消息是否被消費了。 實際上消費者所持有的僅有的元數據就是這個偏移量，也就是消費者在這個log中的位置。 這個偏移量由消費者控制：正常情況當消費者消費消息的時候，偏移量也線性的的增加。但是實際偏移量由消費者控制，消費者可以將偏移量重置為更老的一個偏移量，重新讀取消息。 可以看到這種設計對消費者來說操作自如， 一個消費者的操作不會影響其它消費者對此log的處理。 再說說分區。Kafka中采用分區的設計有幾個目的。一是可以處理更多的消息，不受單台服務器的限制。Topic擁有多個分區意味着它可以不受限的處理更多的數據。第二，分區可以作為並行處理的單元

 

 分布式（Distributed）

 

Log的分區被分布到集群中的多個服務器上。每個服務器處理它分到的分區。 根據配置每個分區還可以復制到其它服務器作為備份容錯。 每個分區有一個leader，零或多個follower。Leader處理此分區的所有的讀寫請求，而follower被動的復制數據。如果leader宕機，其它的一個follower會被推舉為新的leader。 一台服務器可能同時是一個分區的leader，另一個分區的follower。 這樣可以平衡負載，避免所有的請求都只讓一台或者某幾台服務器處理。

Geo-replication（異地數據同步技術）

 

Kafka MirrorMaker為群集提供 geo-replication支持。借助 MirrorMaker，消息可以跨多個數據中心或雲區域進行復制。 您可以在active/passive場景中用於備份和恢復; 或者在active/passive方案中將數據置於更接近用戶的位置，或數據本地化。

生產者(producer)

 

生產者往某個Topic上發布消息。生產者也負責選擇發布到Topic上的哪一個分區。最簡單的方式從分區列表中輪流選擇。也可以根據某種算法依照權重選擇分區。開發者負責如何選擇分區的算法。

消費者（consumer）

 

通常來講，消息模型可以分為兩種， 隊列和發布-訂閱式。 隊列的處理方式是 一組消費者從服務器讀取消息，一條消息只有其中的一個消費者來處理。在發布-訂閱模型中，消息被廣播給所有的消費者，接收到消息的消費者都可以處理此消息。Kafka為這兩種模型提供了單一的消費者抽象模型： 消費者組 （consumer group）。 消費者用一個消費者組名標記自己。 一個發布在Topic上消息被分發給此消費者組中的一個消費者。 假如所有的消費者都在一個組中，那么這就變成了queue模型。 假如所有的消費者都在不同的組中，那么就完全變成了發布-訂閱模型。 更通用的， 我們可以創建一些消費者組作為邏輯上的訂閱者。每個組包含數目不等的消費者， 一個組內多個消費者可以用來擴展性能和容錯。正如下圖所示：

 

2個kafka集群托管4個分區（P0-P3），2個消費者組，消費組A有2個消費者實例，消費組B有4個。

正像傳統的消息系統一樣，Kafka保證消息的順序不變。 再詳細扯幾句。傳統的隊列模型保持消息，並且保證它們的先后順序不變。但是， 盡管服務器保證了消息的順序，消息還是異步的發送給各個消費者，消費者收到消息的先后順序不能保證了。這也意味着並行消費將不能保證消息的先后順序。用過傳統的消息系統的同學肯定清楚，消息的順序處理很讓人頭痛。如果只讓一個消費者處理消息，又違背了並行處理的初衷。 在這一點上Kafka做的更好，盡管並沒有完全解決上述問題。 Kafka采用了一種分而治之的策略：分區。 因為Topic分區中消息只能由消費者組中的唯一一個消費者處理，所以消息肯定是按照先后順序進行處理的。但是它也僅僅是保證Topic的一個分區順序處理，不能保證跨分區的消息先后處理順序。 所以，如果你想要順序的處理Topic的所有消息，那就只提供一個分區。