一、摘要
impala作為實時資料分析引擎，其源資料時效性要求不同，主要分為離線資料分析和實時資料分析。離線資料分析應用場景下，可以利用hive離線載入資料。實時資料分析則依靠kafka（高吞吐量的訊息發布訂閱系統）。
二、kafka介紹
kafka是一種高吞吐量的分布式發布訂閱訊息系統，它可以處理消費者規模的**中的所有動作流資料。這種動作（網頁瀏覽，搜尋和其他使用者的行動）是在現代網路上的許多社會功能的乙個關鍵因素。這些資料通常是由於吞吐量的要求而通過處理日誌和日誌聚合來解決。
元件：每個訊息（也叫作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的所有訊息，那就只提供乙個分割槽。
1 騰訊 實時資料流推薦實踐
tecentrec real time stream recommendation in practice 解決問題 主要解決問題 資料量大 實時 準確性 實時計算平台選取 1 支援實時資料統計計算 2 集群擴充套件性好 3 失敗恢復快 4 活躍度較高的開源工具 5 簡單程式設計模式，支援多種國語言...
實時資料流計算引擎Flink和Spark剖析
在過去幾年，業界的主流流計算引擎大多採用spark streaming，隨著近兩年flink的快速發展，flink的使用也越來越廣泛。與此同時，spark針對spark streaming的不足，也繼而推出了新的流計算元件。本文旨在深入分析不同的流計算引擎的內在機制和功能特點，為流處理場景的選型提供...
從實時資料流中搜尋資料 演算法2
專案需要從實時單向資料流中讀取和篩選資料，即當遇到標誌資料時，執行某些操作。所有資料只能讀一次，不能回溯。我們的場景是監聽串列埠，然後根據監聽結果，讀取後續資料。上午寫了個演算法程式 從實時資料流中搜尋資料，監控實時資料流中的資料，發現資料時立即做出應對。然後，寫完了之後，總覺得效能有缺陷。仔細考慮...