使用Kafka和Flink構建實時資料處理系統

引言

關於Kafka

• 作為訊息佇列。由於 Kafka 擁有高吞吐量，並且內建訊息主題分割槽，備份，容錯等特性，使得它更適合使用在大規模，高強度的訊息資料處理的系統中。
• 流計算系統的資料來源。流資料產生系統作為 Kafka 訊息資料的生產者將資料流分發給 Kafka 訊息主題，流資料計算系統 (Flink，Storm,Spark Streaming等) 實時消費並計算資料。這也是本文將要介紹的應用場景。
• 系統使用者行為資料來源。這種場景下，系統將使用者的行為資料，如訪問頁面，停留時間，搜尋日誌，感興趣的話題等資料實時或者週期性的釋出到 Kafka 訊息主題，作為對接系統資料的來源。
• 日誌聚集。Kafka 可以作為一個日誌收集系統的替代解決方案，我們可以將系統日誌資料按類別彙集到不同的 Kafka 訊息主題中。
• 事件源。在基於事件驅動的系統中，我們可以將事件設計成合理的格式，作為 Kafka 訊息資料儲存起來，以便相應系統模組做實時或者定期處理。由於 Kafka 支援大資料量儲存，並且有備份和容錯機制，所以可以讓事件驅動型系統更加健壯和高效。

關於Flink

• 最底層級的抽象僅僅提供了有狀態流。它將通過過程函式（Process Function）嵌入到DataStream API中。它允許使用者可以自由地處理來自一個或多個流資料的事件，並使用一致、容錯的狀態。除此之外，使用者可以註冊事件時間和處理事件回撥，從而使程式可以實現複雜的計算。
• 實際上，大多數應用並不需要上述的低層級抽象，而是針對 核心API（Core APIs） 進行程式設計，比如DataStream API（有界或無界流資料）以及DataSet API（有界資料集）。這些流暢的API為資料處理提供了通用的構建模組，比如由使用者定義的多種形式的轉換（transformations），連線（joins），聚合（aggregations），視窗操作（windows），狀態（state）等等。這些API處理的資料型別以類（classes）的形式由各自的程式語言所表示。

• Table API 是以 表 為中心的宣告式DSL，其中表可能會動態變化（在表達流資料時）。Table API遵循（擴充套件的）關係模型：表具有附加的模式（類似於關聯式資料庫中的表），同時API提供可比較的操作，例如select、project、join、group-by、aggregate等。Table API程式宣告式地定義了 什麼邏輯操作應該執行 而不是準確地確定 這些操作程式碼的看上去如何 。 儘管Table API可以通過多種型別的使用者定義的函式進行擴充套件，其仍不如 核心API 更具表達能力，但是使用起來卻更加簡潔（程式碼量更少）。除此之外，Table API程式還可以在執行之前通過應用優化規則的優化器。

• Flink提供的最高層級的抽象是 SQL 。這一層抽象在語法與表達能力上與 Table API 類似，但是是以SQL查詢表示式的形式表現程式。SQL抽象與Table API互動密切，同時SQL查詢可以直接在Table API定義的表上執行。

案例介紹與Flink SQL程式設計實現

1.案例介紹

2.案例分析

3.生產行為資料資訊

4.編寫Flink SQL編寫程式實時處理資料

• 建立源表和結果表
• 建立子查詢，使用 ROW_NUMBER() 視窗函式來對資料根據排序列進行排序並標上排名
• 外層查詢中，對排名進行過濾，只取前N條，如N=5，那麼就是取 Top 5 的資料，即網頁熱度排名

-- Kafka源表
create table input（
id             varchar,
count          bigint,
timegap        bigint,
positive       boolean,
firsttime      timestamp,
WATERMARK wk FOR firsttime as withOffset(firsttime, 2000)
)with(
type=`kafka`
endpoint=`xxx`
......
);
-- Hbase儲存表
create table output(
window_start  TIMESTAMP,
window_end    TIMESTAMP,
id            bigint,
contribution  double
)with(
type=`ALIHBASE`
endpoint=`xxx`
......
);
-- 5秒鐘視窗貢獻度統計
CREATE VIEW group_view AS
SELECT id,
      TUMBLE_START(firsttime, INTERVAL `5` SECOND) AS start_time,
      (0.8*count+0.8*timegap+positive) as contribution
FROM input
GROUP BY id, TUMBLE(firsttime, INTERVAL `1` MINUTE);

-- 統計每5秒 top5 貢獻值ID，並輸出
insert into output
select
(
   SELECT
   id, firsttime, contribution,
   ROW_NUMBER() OVER (PARTITION BY firsttime ORDER BY contribution DESC) as rownum,
   FROM
   group_view
)
WHERE rownum <= 5;

注意事項

• 需要合理的設定時間視窗，即需要保證Flink的計算視窗合理地統計到熱度最高的話題，理論上Flink的視窗可以是無界的，也可以是很小的時間視窗，但是合理的視窗大小設計對業務邏輯的影響。
• 雖然本文案例中，我們只是把 (近) 實時計算結果列印出來，但是實際上很多時候這些結果會被儲存到資料庫,HDFS, 或者傳送回 Kafka, 以供其他系統利用這些資料做進一步的業務處理，Flink可以直接實現這些功能。
• 由於流計算對實時性要求很高，所以任何由於 JVM Full GC 引起的系統暫停都是不可接受的。Flink 採用類似 DBMS 的 sort 和 join 演算法，直接操作二進位制資料，從而使序列化/反序列化帶來的開銷達到最小。所以 Flink 的內部實現更像 C/C++ 而非 Java。如果需要處理的資料超出了記憶體限制，則會將部分資料儲存到硬碟上。如果要操作多塊MemorySegment就像操作一塊大的連續記憶體一樣，Flink會使用邏輯檢視（AbstractPagedInputView）來方便操作。
• Flink內部支援exactly-once，要想達到端到端（Soruce到Sink）的exactly-once，需要Blink外部Soruce和Sink的支援，比如Source要支援精準的offset，Sink要支援兩階段提交，也就是繼承TwoPhaseCommitSinkFunction。
• Flink中當所有輸入的barrier沒有完全到來的時候，早到來的event在exactly-once的情況向會進行快取（不進行處理），而at-least-once的模式下即使所有輸入的barrier沒有完全到來的時候，早到來的event也會進行處理。也就是說對於at-least-once模式下，對於下游節點而言，本來資料屬於checkpoint n的資料在checkpoint n-1裡面也可能處理過了。所以我們建議，Flink的checkpoint模式設定為exactl-once模式。

結束語