本文轉(zhuǎn)自：https://www.pianshen.com/article/82411282368/

StreamTableEnvironment用于流計算場景，流計算的對象是DataStream。相比 TableEnvironment，StreamTableEnvironment 提供了 DataStream 和 Table 之間相互轉(zhuǎn)換的接口，如果用戶的程序除了使用 Table API & SQL 編寫外，還需要使用到 DataStream API，則需要使用 StreamTableEnvironment。

一、數(shù)據(jù)流上的關(guān)系查詢

Relational Algebra / SQLStream Processing

關(guān)系（或表）是有界（多）元組集	流是元組的無限序列
對批處理數(shù)據(jù)（如關(guān)系數(shù)據(jù)庫中的表）執(zhí)行的查詢可以訪問完整的輸入數(shù)據(jù)	流式查詢在啟動時無法訪問所有數(shù)據(jù)，必須“等待”數(shù)據(jù)流式輸入
批處理查詢在生成固定大小的結(jié)果后終止	流式查詢根據(jù)接收到的記錄不斷更新其結(jié)果，但從未完成

盡管存在這些差異，使用關(guān)系查詢和SQL處理流并非不可能。高級關(guān)系數(shù)據(jù)庫系統(tǒng)提供了一個稱為物化視圖的特性。物化視圖被定義為SQL查詢，就像普通的虛擬視圖一樣。與虛擬視圖不同，物化視圖緩存查詢的結(jié)果，這樣在訪問視圖時就不需要計算查詢。緩存的一個常見挑戰(zhàn)是防止緩存提供過時的結(jié)果。物化視圖在其定義查詢的基表被修改時變得過時。Eager View Maintenance是一種在更新基表后立即更新物化視圖的技術(shù)。

如果我們考慮以下幾點，那么Eager View Maintenance和對流的SQL查詢之間的聯(lián)系將變得顯而易見：

• 1、數(shù)據(jù)庫表是INSERT，UPDATE和DELETEDML語句的一個結(jié)果流，通常被稱為更新日志流。
• 2、物化視圖定義為SQL查詢。為了更新視圖，查詢會持續(xù)處理視圖基本關(guān)系的更改日志流。
• 3、物化視圖是流式SQL查詢的結(jié)果。

二、動態(tài)表是Flink對流數(shù)據(jù)的表API和SQL支持的核心概念。

與表示批處理數(shù)據(jù)的靜態(tài)表不同，動態(tài)表是隨時間變化的。它們可以像靜態(tài)批處理表一樣進(jìn)行查詢。查詢動態(tài)表會產(chǎn)生連續(xù)查詢。連續(xù)查詢永遠(yuǎn)不會終止，并因此生成動態(tài)表。查詢不斷更新其（動態(tài)）結(jié)果表，以反映其（動態(tài)）輸入表上的更改。實際上，動態(tài)表上的連續(xù)查詢與定義物化視圖的查詢非常相似。

需要注意的是，連續(xù)查詢的結(jié)果在語義上始終等同于在輸入表的快照上以批處理模式執(zhí)行的同一查詢的結(jié)果。
下圖顯示了流、動態(tài)表和連續(xù)查詢的關(guān)系：

• 1、流被轉(zhuǎn)換為動態(tài)表。
• 2、對動態(tài)表計算連續(xù)查詢，生成新的動態(tài)表。
• 3、生成的動態(tài)表被轉(zhuǎn)換回流。

注：動態(tài)表首先是一個邏輯概念。在查詢執(zhí)行期間，動態(tài)表不一定（完全）具體化。

三、查詢限制

許多（但不是所有）語義有效的查詢可以作為流上的連續(xù)查詢進(jìn)行計算。有些查詢的計算成本太高，要么是因為它們需要維護(hù)的狀態(tài)的大小，要么是因為計算更新的成本太高。

• 1、狀態(tài)大小：連續(xù)查詢是在無邊界的流上計算的，通常應(yīng)該運行數(shù)周或數(shù)月。因此，連續(xù)查詢處理的數(shù)據(jù)總量可能非常大。必須更新先前發(fā)出的結(jié)果的查詢需要維護(hù)所有發(fā)出的行才能更新它們。例如，查詢需要存儲每個用戶的URL計數(shù)，以便在輸入表收到新行時增加計數(shù)并發(fā)送新結(jié)果。如果只跟蹤注冊用戶，則要維護(hù)的計數(shù)可能不會太高。但是，如果未注冊的用戶分配了唯一的用戶名，則要維護(hù)的計數(shù)將隨著時間的推移而增加，并可能最終導(dǎo)致查詢失敗。

SELECT user, COUNT(url) FROM clicks GROUP BY user;

• 2、計算更新：一些查詢需要重新計算和更新大部分發(fā)出的結(jié)果行，即使只添加或更新了一個輸入記錄。顯然，這種查詢不太適合作為連續(xù)查詢執(zhí)行。下面的查詢就是一個例子，它根據(jù)最后一次單擊的時間為每個用戶計算一個排名。一旦clicks表接收到一個新行，用戶的lastAction就會更新，并且必須計算一個新的排名。但是，由于兩行不能具有相同的排名，所以所有排名較低的行也需要更新

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

四、表到流到轉(zhuǎn)換

與常規(guī)數(shù)據(jù)庫表一樣，動態(tài)表可以通過插入、更新和刪除更改進(jìn)行連續(xù)修改。它可能是一個只有一行的表，該行是不斷更新的，也可能是一個只插入而不更新和刪除修改的表，或者介于兩者之間的任何內(nèi)容。將動態(tài)表轉(zhuǎn)換為流或?qū)⑵鋵懭胪獠肯到y(tǒng)時，需要對這些更改進(jìn)行編碼。Flink的表API和SQL支持三種方式對動態(tài)表的更改進(jìn)行編碼：

• 1、僅追加流（Append-only stream）：僅通過插入更改修改的動態(tài)表可以通過發(fā)出插入的行轉(zhuǎn)換為流。
• 2、回收流（Retract stream）：回收流是包含兩類消息的流，添加消息和收回消息。動態(tài)表通過將INSERT change編碼為add消息、DELETE change編碼為retract消息、UPDATE change編碼為updated（previous）行的retract消息和UPDATE（new）行的add消息轉(zhuǎn)換為retract流。下圖顯示了將動態(tài)表轉(zhuǎn)換為收縮流的過程。
  
• 3、更新插入流(Upsert stream):upsert流是一種包含兩種類型消息的流，包括Upsert消息和刪除消息。 轉(zhuǎn)換為upsert流的動態(tài)表需要（可能是復(fù)合的）唯一鍵。 通過將INSERT和UPDATE更改編碼為upsert消息并將DELETE更改編碼為刪除消息，將具有唯一鍵的動態(tài)表轉(zhuǎn)換為流。 流消耗運算符需要知道唯一鍵屬性才能正確應(yīng)用消息。 與回收流的主要區(qū)別在于UPDATE更改使用單個消息進(jìn)行編碼，因此更有效。 下圖顯示了動態(tài)表到upsert流的轉(zhuǎn)換。
  

總結(jié)

以上是生活随笔為你收集整理的Flink-Table StreamTableEnvironment基础知识的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。