flink動態(tài)表的思路

這篇文章主要介紹“flink動態(tài)表的思路”，在日常操作中，相信很多人在flink動態(tài)表的思路問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”flink動態(tài)表的思路”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

傳統(tǒng)的數(shù)據(jù)庫SQL和實(shí)時SQL處理的差別還是很大的，這里簡單列出一些區(qū)別：

盡管存在這些差異，但使用關(guān)系查詢和SQL處理流并非不可能。高級關(guān)系數(shù)據(jù)庫系統(tǒng)提供稱為物化視圖的功能。物化視圖定義為SQL查詢，就像常規(guī)虛擬視圖一樣。與虛擬視圖相比，物化視圖緩存查詢的結(jié)果，使得在訪問視圖時不需要執(zhí)行查詢。緩存的一個常見挑戰(zhàn)是避免緩存提供過時的結(jié)果。物化視圖在修改其定義查詢的基表時會過時。Eager View Maintenance是一種在更新基表后立即更新實(shí)例化視圖的技術(shù)。

如果我們考慮以下內(nèi)容，Eager View Maintenance和流上的SQL查詢之間的聯(lián)系就變得很明顯：

• 數(shù)據(jù)庫表是INSERT，UPDATE和DELETEDML語句流的結(jié)果，通常被稱為更新日志流。

• 物化視圖定義為SQL查詢。為了更新視圖，查詢需要持續(xù)處理視圖源表的更改日志流。

• 物化視圖是流式SQL查詢的結(jié)果。

有了上面的基礎(chǔ)，下面可以介紹一下動態(tài)表的概念了。

動態(tài)表和持續(xù)不斷查詢

動態(tài)表flink table api和SQL處理流數(shù)據(jù)的核心概念。與靜態(tài)表相比，動態(tài)表隨時間而變化，但可以像靜態(tài)表一樣查詢動態(tài)表，只不過查詢動態(tài)表需要產(chǎn)生連續(xù)查詢。連續(xù)查詢永遠(yuǎn)不會終止，會生成動態(tài)表作為結(jié)果表。查詢不斷更新其（動態(tài)）結(jié)果表以反映其（動態(tài)）輸入表的更改。最終，動態(tài)表上的連續(xù)查詢與定義物化視圖的查詢非常相似。

值得注意的是，連續(xù)查詢的結(jié)果始終在語義上等同于在輸入表的快照上執(zhí)行批處理的到的相同查詢結(jié)果。

下圖顯示了流，動態(tài)表和連續(xù)查詢的關(guān)系：

1. 數(shù)據(jù)流被轉(zhuǎn)化為動態(tài)表

2. 在產(chǎn)生的動態(tài)表上執(zhí)行連續(xù)不斷的查詢，產(chǎn)生一個動態(tài)結(jié)果表。

3. 結(jié)果動態(tài)表再次被轉(zhuǎn)化為數(shù)據(jù)流。

注意：動態(tài)表最重要的是邏輯概念。在查詢執(zhí)行期間，動態(tài)表不一定（完全）物化。

在下文中，會以schema如下的點(diǎn)擊事件流來解釋動態(tài)表和連續(xù)不斷的查詢。

[ user:  VARCHAR,   // the name of the user cTime: TIMESTAMP, // the time when the URL was accessed url:   VARCHAR    // the URL that was accessed by the user]

stream轉(zhuǎn)化成表

當(dāng)然，想要用經(jīng)典的sql去分析流數(shù)據(jù)，肯定要先將其轉(zhuǎn)化為表。從概念上講，流的每個新增記錄都被解釋為對結(jié)果表的Insert操作。最終，可以理解為是在從一個INSERT-only changelog流上構(gòu)建一個表。

下圖顯示了click事件流（左側(cè)）如何轉(zhuǎn)換為表（右側(cè)）。隨著更多點(diǎn)擊流記錄的插入，生成的表不斷增長。

注意：stream轉(zhuǎn)化的表內(nèi)部并沒有被物化。

連續(xù)查詢

在動態(tài)表上執(zhí)行連續(xù)查詢，并生成新的動態(tài)表作為結(jié)果表。與批處理查詢不同，連續(xù)查詢絕不會終止，而且會根據(jù)輸入表的更新來更新它的結(jié)果表。在任何時間點(diǎn)，連續(xù)查詢的結(jié)果在語義上等同于在輸入表的快照上以批處理模式得到的查詢的結(jié)果。

在下文中，我們將在用點(diǎn)擊事件流定義的clicks表上展示兩個示例查詢。

第一個查詢是一個簡單的GROUP-BY COUNT聚合查詢。主要是對clicks表按照user分組，然后統(tǒng)計(jì)url得到訪問次數(shù)。下圖展示了clicks表在數(shù)據(jù)增加期間查詢是如何執(zhí)行的。

假設(shè)當(dāng)查詢啟動的事以后，clicks表為空。當(dāng)?shù)谝恍袛?shù)據(jù)插入clicks表的時候，查詢開始計(jì)算產(chǎn)生結(jié)果表。當(dāng)[Mary, ./home]插入的時候，查詢會在結(jié)果表上產(chǎn)生一行[Mary, 1]。當(dāng)[Bob, ./cart]插入clicks表之后，查詢會再次更新結(jié)果表，增加一行[Bob, 1]。當(dāng)?shù)谌?，[Mary, ./prod?id=1]插入clicks表后，查詢會更新結(jié)果表的[Mary, 1]為[Mary, 2]。最后，第四行數(shù)據(jù)插入clicks后，查詢會給結(jié)果表增加一行[Liz, 1].

第二個查詢僅僅是在上個查詢的基礎(chǔ)上增加了一個1小時的滾動窗口。下圖展示了整個流水過程。

這個就類似批處理了，每個小時產(chǎn)生一次計(jì)算結(jié)果然后更新結(jié)果表。cTime的時間范圍在12:00:00 ～12:59:59的時候總共有四行數(shù)據(jù)，查詢計(jì)算出了兩行結(jié)果，并將其追加到結(jié)果表。Ctime窗口在13:00:00 and 13:59:59的時候，總共有三行數(shù)據(jù)，查詢再次產(chǎn)生兩行結(jié)果追加到結(jié)果表。隨著時間的推移，click數(shù)據(jù)會被追加到clicks表，結(jié)果表也會不斷有新的結(jié)果產(chǎn)生。

Update 和 append 查詢

盡管兩個示例查詢看起來非常相似（都計(jì)算了分組計(jì)數(shù)聚合），但是內(nèi)部邏輯還是區(qū)別較大：

• 第一個查詢更新以前發(fā)出的結(jié)果，即結(jié)果表的更改日志流包含INSERT和UPDATE更改。

• 第二個查詢僅append到結(jié)果表，即結(jié)果表的更改日志流僅包含INSERT更改。

查詢是生成僅append表還是update表有一些區(qū)別：

• 產(chǎn)生update變化的查詢通常必須維護(hù)更多狀態(tài)。

• 將僅append表轉(zhuǎn)換為流與將update表的轉(zhuǎn)換為流，方式不同。

查詢限制

并不是所有的查詢都能以流查詢的格式執(zhí)行的。因?yàn)橛行┎樵冇?jì)算起來成本比較高，要么就是要維護(hù)的狀態(tài)比較大，要么就是計(jì)算更新成本高。

1. 狀態(tài)大?。?/strong>連續(xù)查詢在無界流上執(zhí)行，通常應(yīng)該運(yùn)行數(shù)周或數(shù)月，甚至7*24小時。因此，連續(xù)查詢處理的數(shù)據(jù)總量可能非常大。為了更新先前生成的結(jié)果，可能需要維護(hù)所有輸出的行。例如，第一個示例查詢需要存儲每個用戶的URL計(jì)數(shù)，以便能夠增加計(jì)數(shù)，并在輸入表收到新行時發(fā)出新結(jié)果。如果僅統(tǒng)計(jì)注冊用戶，則要維護(hù)的計(jì)數(shù)可能不會太高。但是，如果未注冊的用戶分配了唯一的用戶名，則要維護(hù)的計(jì)數(shù)數(shù)將隨著時間的推移而增長，最終可能導(dǎo)致查詢失敗。

SELECT user, COUNT(url)FROM clicksGROUP BY user;

1. 計(jì)算更新：有時即使只添加或更新了單個輸入記錄，某些查詢也需要重新計(jì)算和更新大部分發(fā)出的結(jié)果行。顯然，這樣的查詢不適合作為連續(xù)查詢執(zhí)行。下面sql是一個示例查詢，該查詢基于最后一次點(diǎn)擊的時間為每個用戶計(jì)算RANK 。一旦clicks表接收到新增行，用戶的lastAction就會更新，并且必須計(jì)算新的排名。但是，由于兩行不能具有相同的排名，因此所有排名較低的行也需要更新。

SELECT user, RANK() OVER (ORDER BY lastLogin)FROM ( SELECT user, MAX(cTime) AS lastAction FROM clicks GROUP BY user);

表轉(zhuǎn)化為流

可以像傳統(tǒng)數(shù)據(jù)庫表一樣使用INSERT, UPDATE, 和DELETE修改動態(tài)表。當(dāng)將動態(tài)表轉(zhuǎn)化為stream或者寫入外部系統(tǒng)的時候，需要對修改進(jìn)行編碼。Flink的Table API和SQL支持三種方式來編碼動態(tài)表的變化。

Append-only stream：假如動態(tài)表的更改操作僅僅是insert ，那么變?yōu)閟tream就僅僅需要將插入的行發(fā)送出去即可。

Retract stream: retract(回撤)流是包含兩種類型的消息的流，增加消息和回撤消息。通過將INSERT編碼為增加消息，DELETE編碼為回撤消息，將UPDATE編碼為對先前行的回撤消息和對新增行的增加消息，來完成將動態(tài)表轉(zhuǎn)換為收回流。下圖顯示了動態(tài)表到回收流的轉(zhuǎn)換。

Upsert流： upsert流是一種包含兩種消息，upsert消息和刪除消息的流。轉(zhuǎn)換為upsert流的動態(tài)表需要唯一鍵。具有唯一鍵的動態(tài)表通過將INSERT和UPDATE編碼為upsert消息，DELETE編碼為刪除消息來完成動態(tài)表轉(zhuǎn)化為流。流算符需要知道唯一鍵屬性才能正確處理消息。與回撤流的主要區(qū)別在于，UPDATE使用單個消息對update進(jìn)行編碼，因此更有效。下圖顯示了動態(tài)表到upsert流的轉(zhuǎn)換。

到此，關(guān)于“flink動態(tài)表的思路”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！