實時數倉來勢兇猛，FlinkSQL已成必殺技。五千字長文帶大家快速入門FlinkSQL，占據技術棧優勢，升職加薪加特！
二、FlinkSQL出現的背景
Flink SQL 是 Flink 實時計算為簡化計算模型，降低使用者使用實時計算門檻而設計的一套符合标準 SQL 語義的開發語言。
自 2015 年開始，阿裡巴巴開始調研開源流計算引擎，最終決定基于 Flink 打造新一代計算引擎，針對 Flink 存在的不足進行優化和改進，并且在 2019 年初将最終代碼開源，也就是我們熟知的 Blink。Blink 在原來的 Flink 基礎上最顯著的一個貢獻就是 Flink SQL 的實作。
Flink SQL 是面向使用者的 API 層，在我們傳統的流式計算領域，比如 Storm、Spark Streaming 都會提供一些 Function 或者 Datastream API，使用者通過 Java 或 Scala 寫業務邏輯，這種方式雖然靈活，但有一些不足，比如具備一定門檻且調優較難，随着版本的不斷更新，API 也出現了很多不相容的地方。
在這個背景下，毫無疑問，SQL 就成了我們最佳選擇，之是以選擇将 SQL 作為核心 API，是因為其具有幾個非常重要的特點：
- SQL 屬于設定式語言，使用者隻要表達清楚需求即可，不需要了解具體做法；
- SQL 可優化，内置多種查詢優化器，這些查詢優化器可為 SQL 翻譯出最優執行計劃；
- SQL 易于了解，不同行業和領域的人都懂，學習成本較低；
- SQL 非常穩定，在資料庫 30 多年的曆史中，SQL 本身變化較少；
- 流與批的統一，Flink 底層 Runtime 本身就是一個流與批統一的引擎，而 SQL 可以做到 API 層的流與批統一。
三、整體介紹
3.1 什麼是 Table API 和 Flink SQL?
Flink本身是批流統一的處理架構，是以Table API和SQL，就是批流統一的上層處理API。目前功能尚未完善，處于活躍的開發階段。
Table API是一套内嵌在Java和Scala語言中的查詢API，它允許我們以非常直覺的方式，組合來自一些關系運算符的查詢（比如select、filter和join）。而對于Flink SQL，就是直接可以在代碼中寫SQL，來實作一些查詢（Query）操作。Flink的SQL支援，基于實作了SQL标準的Apache Calcite（Apache開源SQL解析工具）。
無論輸入是批輸入還是流式輸入，在這兩套API中，指定的查詢都具有相同的語義，得到相同的結果。
3.2 需要引入的依賴
Table API 和 SQL 需要引入的依賴有兩個：
planner
和
bridge
<dependency>
<groupId>org.apache.flink</groupId>
<artifactId>flink-table-planner_2.11</artifactId>
<version>1.10.0</version>
</dependency>
<dependency>
<groupId>org.apache.flink</groupId>
<artifactId>flink-table-api-scala-bridge_2.11</artifactId>
<version>1.10.0</version>
</dependency>
其中：
flink-table-planner：planner計劃器，是table API最主要的部分，提供了運作時環境和生成程式執行計劃的planner；
flink-table-api-scala-bridge：bridge橋接器，主要負責table API和 DataStream/DataSet API的連接配接支援，按照語言分java和scala；
這裡的兩個依賴，是IDE環境下運作需要添加的；如果是生産環境，lib目錄下預設已經有了planner，就隻需要有bridge就可以了。
當然，如果想使用使用者自定義函數，或是跟 kafka 做連接配接，需要有一個SQL client，這個包含在
flink-table-common
裡。
3.3 兩種planner（old & blink）的差別
1、批流統一：Blink将批處理作業，視為流式處理的特殊情況。是以，blink不支援表和DataSet之間的轉換，批處理作業将不轉換為DataSet應用程式，而是跟流處理一樣，轉換為DataStream程式來處理。
2、因為批流統一，Blink planner也不支援BatchTableSource，而使用有界的StreamTableSource代替。
3、Blink planner隻支援全新的目錄，不支援已棄用的ExternalCatalog。
4、舊 planner 和 Blink planner 的FilterableTableSource實作不相容。舊的planner會把PlannerExpressions下推到filterableTableSource中，而blink planner則會把Expressions下推。
5、基于字元串的鍵值配置選項僅适用于Blink planner。
6、PlannerConfig在兩個planner中的實作不同。
7、Blink planner會将多個sink優化在一個DAG中（僅在TableEnvironment上受支援，而在StreamTableEnvironment上不受支援）。而舊 planner 的優化總是将每一個sink放在一個新的DAG中，其中所有DAG彼此獨立。
8、舊的planner不支援目錄統計，而Blink planner支援。
四、API 調用
4.1 基本程式結構
Table API 和 SQL 的程式結構，與流式處理的程式結構類似；也可以近似地認為有這麼幾步：首先建立執行環境，然後定義source、transform和sink。
具體操作流程如下：
val tableEnv = ... // 建立表的執行環境
// 建立一張表，用于讀取資料
tableEnv.connect(...).createTemporaryTable("inputTable")
// 注冊一張表，用于把計算結果輸出
tableEnv.connect(...).createTemporaryTable("outputTable")
// 通過 Table API 查詢算子，得到一張結果表
val result = tableEnv.from("inputTable").select(...)
// 通過 SQL查詢語句，得到一張結果表
val sqlResult = tableEnv.sqlQuery("SELECT ... FROM inputTable ...")
// 将結果表寫入輸出表中
result.insertInto("outputTable")
4.2 建立表環境
建立表環境最簡單的方式，就是基于流處理執行環境，調create方法直接建立：
val tableEnv = StreamTableEnvironment.create(env)
表環境（TableEnvironment）是flink中內建 Table API & SQL 的核心概念。它負責:
- 注冊catalog
- 在内部 catalog 中系統資料庫
- 執行 SQL 查詢
- 注冊使用者自定義函數
- 将 DataStream 或 DataSet 轉換為表
- 儲存對 ExecutionEnvironment 或 StreamExecutionEnvironment 的引用
在建立TableEnv的時候，可以多傳入一個EnvironmentSettings 或者 TableConfig 參數，可以用來配置 TableEnvironment 的一些特性。
比如，配置老版本的流式查詢（Flink-Streaming-Query）：
val settings = EnvironmentSettings.newInstance()
.useOldPlanner() // 使用老版本planner
.inStreamingMode() // 流處理模式
.build()
val tableEnv = StreamTableEnvironment.create(env, settings)
基于老版本的批處理環境（Flink-Batch-Query）：
val batchEnv = ExecutionEnvironment.getExecutionEnvironment
val batchTableEnv = BatchTableEnvironment.create(batchEnv)
基于 blink 版本的流處理環境（Blink-Streaming-Query）：
val bsSettings = EnvironmentSettings.newInstance()
.useBlinkPlanner()
.inStreamingMode().build()
val bsTableEnv = StreamTableEnvironment.create(env, bsSettings)
基于blink版本的批處理環境（Blink-Batch-Query）：
val bbSettings = EnvironmentSettings.newInstance()
.useBlinkPlanner()
.inBatchMode().build()
val bbTableEnv = TableEnvironment.create(bbSettings)
4.3 在Catalog中系統資料庫
4.3.1 表(Table)的概念
TableEnvironment 可以注冊目錄 Catalog ，并可以基于Catalog系統資料庫。它會維護一個 Catalog-Table 表之間的map。
表（Table）是由一個“辨別符”來指定的，由3部分組成：Catalog名、資料庫（database）名和對象名（表名）。如果沒有指定目錄或資料庫，就使用目前的預設值。
表可以是正常的（Table，表），或者虛拟的（View，視圖）。正常表（Table）一般可以用來描述外部資料，比如檔案、資料庫表或消息隊列的資料，也可以直接從 DataStream轉換而來。視圖可以從現有的表中建立，通常是 table API 或者SQL查詢的一個結果。
4.3.2 連接配接到檔案系統（Csv格式）
連接配接外部系統在Catalog中系統資料庫，直接調用 tableEnv.connect() 就可以，裡面參數要傳入一個 ConnectorDescriptor ，也就是connector描述器。對于檔案系統的 connector 而言，flink内部已經提供了，就叫做FileSystem()。
代碼如下：
tableEnv
.connect( new FileSystem().path("sensor.txt")) // 定義表資料來源，外部連接配接
.withFormat(new OldCsv()) // 定義從外部系統讀取資料之後的格式化方法
.withSchema( new Schema()
.field("id", DataTypes.STRING())
.field("timestamp", DataTypes.BIGINT())
.field("temperature", DataTypes.DOUBLE())
) // 定義表結構
.createTemporaryTable("inputTable") // 建立臨時表
這是舊版本的csv格式描述器。由于它是非标的，跟外部系統對接并不通用，是以将被棄用，以後會被一個符合RFC-4180标準的新format描述器取代。新的描述器就叫Csv()，但flink沒有直接提供，需要引入依賴flink-csv：
<dependency>
<groupId>org.apache.flink</groupId>
<artifactId>flink-csv</artifactId>
<version>1.10.0</version>
</dependency>
代碼非常類似，隻需要把 withFormat 裡的 OldCsv 改成Csv就可以了。
4.3.3 連接配接到Kafka
kafka的連接配接器 flink-kafka-connector 中，1.10 版本的已經提供了 Table API 的支援。我們可以在 connect方法中直接傳入一個叫做Kafka的類，這就是kafka連接配接器的描述器ConnectorDescriptor。
tableEnv.connect(
new Kafka()
.version("0.11") // 定義kafka的版本
.topic("sensor") // 定義主題
.property("zookeeper.connect", "localhost:2181")
.property("bootstrap.servers", "localhost:9092")
)
.withFormat(new Csv())
.withSchema(new Schema()
.field("id", DataTypes.STRING())
.field("timestamp", DataTypes.BIGINT())
.field("temperature", DataTypes.DOUBLE())
)
.createTemporaryTable("kafkaInputTable")
當然也可以連接配接到 ElasticSearch、MySql、HBase、Hive等外部系統，實作方式基本上是類似的。感興趣的 小夥伴可以自行去研究，這裡就不詳細贅述了。
4.4 表的查詢
通過上面的學習，我們已經利用外部系統的連接配接器connector，我們可以讀寫資料，并在環境的Catalog中系統資料庫。接下來就可以對表做查詢轉換了。
Flink給我們提供了兩種查詢方式：Table API和 SQL。
4.4.1 Table API的調用
Table API是內建在Scala和Java語言内的查詢API。與SQL不同，Table API的查詢不會用字元串表示，而是在宿主語言中一步一步調用完成的。
Table API基于代表一張“表”的Table類，并提供一整套操作處理的方法API。這些方法會傳回一個新的Table對象，這個對象就表示對輸入表應用轉換操作的結果。有些關系型轉換操作，可以由多個方法調用組成，構成鍊式調用結構。例如
table.select(…).filter(…)
，其中 select（…）表示選擇表中指定的字段，filter(…)表示篩選條件。
代碼中的實作如下：
val sensorTable: Table = tableEnv.from("inputTable")
val resultTable: Table = senorTable
.select("id, temperature")
.filter("id ='sensor_1'")
4.4.2 SQL查詢
Flink的SQL內建，基于的是ApacheCalcite，它實作了SQL标準。在Flink中，用正常字元串來定義SQL查詢語句。SQL 查詢的結果，是一個新的 Table。
代碼實作如下：
val resultSqlTable: Table = tableEnv.sqlQuery("select id, temperature from inputTable where id ='sensor_1'")
或者：
val resultSqlTable: Table = tableEnv.sqlQuery(
"""
|select id, temperature
|from inputTable
|where id = 'sensor_1'
""".stripMargin)
當然，也可以加上聚合操作，比如我們統計每個sensor溫度資料出現的個數，做個count統計：
val aggResultTable = sensorTable
.groupBy('id)
.select('id, 'id.count as 'count)
SQL的實作：
val aggResultSqlTable = tableEnv.sqlQuery("select id, count(id) as cnt from inputTable group by id")
這裡Table API裡指定的字段，前面加了一個單引号’，這是Table API中定義的Expression類型的寫法，可以很友善地表示一個表中的字段。
字段可以直接全部用雙引号引起來，也可以用半邊單引号+字段名的方式。以後的代碼中，一般都用後一種形式。
4.5 将DataStream 轉換成表
Flink允許我們把Table和DataStream做轉換：我們可以基于一個DataStream，先流式地讀取資料源，然後map成樣例類，再把它轉成Table。Table的列字段（column fields），就是樣例類裡的字段，這樣就不用再麻煩地定義schema了。
4.5.1 代碼表達
代碼中實作非常簡單，直接用 tableEnv.fromDataStream() 就可以了。預設轉換後的 Table schema 和 DataStream 中的字段定義一一對應，也可以單獨指定出來。
這就允許我們更換字段的順序、重命名，或者隻選取某些字段出來，相當于做了一次map操作（或者Table API的 select操作）。
代碼具體如下：
val inputStream: DataStream[String] = env.readTextFile("sensor.txt")
val dataStream: DataStream[SensorReading] = inputStream
.map(data => {
val dataArray = data.split(",")
SensorReading(dataArray(0), dataArray(1).toLong, dataArray(2).toDouble)
})
val sensorTable: Table = tableEnv.fromDataStreama(datStream)
val sensorTable2 = tableEnv.fromDataStream(dataStream, 'id, 'timestamp as 'ts)
4.5.2 資料類型與 Table schema的對應
在上節的例子中，DataStream 中的資料類型，與表的 Schema 之間的對應關系，是按照樣例類中的字段名來對應的（name-based mapping），是以還可以用as做重命名。
另外一種對應方式是，直接按照字段的位置來對應（position-based mapping），對應的過程中，就可以直接指定新的字段名了。
基于名稱的對應：
val sensorTable = tableEnv.fromDataStream(dataStream, 'timestamp as 'ts, 'id as 'myId, 'temperature)
基于位置的對應：
val sensorTable = tableEnv.fromDataStream(dataStream, 'myId, 'ts)
Flink的 DataStream 和 DataSet API 支援多種類型。
組合類型，比如元組（内置Scala和Java元組）、POJO、Scala case類和Flink的Row類型等，允許具有多個字段的嵌套資料結構，這些字段可以在Table的表達式中通路。其他類型，則被視為原子類型。
元組類型和原子類型，一般用位置對應會好一些；如果非要用名稱對應，也是可以的：元組類型，預設的名稱是 “_1”, “_2”；而原子類型，預設名稱是 ”f0”。
4.6 建立臨時視圖（Temporary View）
建立臨時視圖的第一種方式，就是直接從DataStream轉換而來。同樣，可以直接對應字段轉換；也可以在轉換的時候，指定相應的字段。
代碼如下：
tableEnv.createTemporaryView("sensorView", dataStream)
tableEnv.createTemporaryView("sensorView", dataStream, 'id, 'temperature, 'timestamp as 'ts)
另外，當然還可以基于Table建立視圖：
tableEnv.createTemporaryView("sensorView", sensorTable)
View和Table的Schema完全相同。事實上，在Table API中，可以認為View 和 Table 是等價的。
4.7 輸出表
表的輸出，是通過将資料寫入 TableSink 來實作的。TableSink 是一個通用接口，可以支援不同的檔案格式、存儲資料庫和消息隊列。
具體實作，輸出表最直接的方法，就是通過 Table.insertInto() 方法将一個 Table 寫入注冊過的 TableSink 中。
4.7.1 輸出到檔案
代碼如下：
// 注冊輸出表
tableEnv.connect(
new FileSystem().path("…\\resources\\out.txt")
) // 定義到檔案系統的連接配接
.withFormat(new Csv()) // 定義格式化方法，Csv格式
.withSchema(new Schema()
.field("id", DataTypes.STRING())
.field("temp", DataTypes.DOUBLE())
) // 定義表結構
.createTemporaryTable("outputTable") // 建立臨時表
resultSqlTable.insertInto("outputTable")
4.7.2 更新模式（Update Mode）
在流處理過程中，表的處理并不像傳統定義的那樣簡單。
對于流式查詢（Streaming Queries），需要聲明如何在（動态）表和外部連接配接器之間執行轉換。與外部系統交換的消息類型，由更新模式（update mode）指定。
Flink Table API中的更新模式有以下三種：
- 追加模式（Append Mode）
在追加模式下，表（動态表）和外部連接配接器隻交換插入（Insert）消息。
- 撤回模式（Retract Mode）
在撤回模式下，表和外部連接配接器交換的是：添加（Add）和撤回（Retract）消息。
其中：
- 插入（Insert）會被編碼為添加消息；
- 删除（Delete）則編碼為撤回消息；
- 更新（Update）則會編碼為，已更新行（上一行）的撤回消息，和更新行（新行）的添加消息。
在此模式下，不能定義key，這一點跟upsert模式完全不同。
- Upsert（更新插入）模式
在Upsert模式下，動态表和外部連接配接器交換Upsert和Delete消息。
這個模式需要一個唯一的key，通過這個key可以傳遞更新消息。為了正确應用消息，外部連接配接器需要知道這個唯一key的屬性。
- 插入（Insert）和更新（Update）都被編碼為Upsert消息；
- 删除（Delete）編碼為Delete資訊
這種模式和 Retract 模式的主要差別在于，Update操作是用單個消息編碼的，是以效率會更高。
4.7.3 輸出到Kafka
除了輸出到檔案，也可以輸出到Kafka。我們可以結合前面Kafka作為輸入資料，建構資料管道，kafka進，kafka出。
代碼如下：
// 輸出到 kafka
tableEnv.connect(
new Kafka()
.version("0.11")
.topic("sinkTest")
.property("zookeeper.connect", "localhost:2181")
.property("bootstrap.servers", "localhost:9092")
)
.withFormat( new Csv() )
.withSchema( new Schema()
.field("id", DataTypes.STRING())
.field("temp", DataTypes.DOUBLE())
)
.createTemporaryTable("kafkaOutputTable")
resultTable.insertInto("kafkaOutputTable")
4.7.4 輸出到ElasticSearch
ElasticSearch的connector可以在upsert（update+insert，更新插入）模式下操作，這樣就可以使用Query定義的鍵（key）與外部系統交換UPSERT/DELETE消息。
另外，對于“僅追加”（append-only）的查詢，connector還可以在 append 模式下操作，這樣就可以與外部系統隻交換 insert 消息。
es目前支援的資料格式，隻有Json，而 flink 本身并沒有對應的支援，是以還需要引入依賴：
<dependency>
<groupId>org.apache.flink</groupId>
<artifactId>flink-json</artifactId>
<version>1.10.0</version>
</dependency>
代碼實作如下：
// 輸出到es
tableEnv.connect(
new Elasticsearch()
.version("6")
.host("localhost", 9200, "http")
.index("sensor")
.documentType("temp")
)
.inUpsertMode() // 指定是 Upsert 模式
.withFormat(new Json())
.withSchema( new Schema()
.field("id", DataTypes.STRING())
.field("count", DataTypes.BIGINT())
)
.createTemporaryTable("esOutputTable")
aggResultTable.insertInto("esOutputTable")
4.7.5 輸出到MySql
Flink專門為Table API的jdbc連接配接提供了flink-jdbc連接配接器，我們需要先引入依賴：
<dependency>
<groupId>org.apache.flink</groupId>
<artifactId>flink-jdbc_2.11</artifactId>
<version>1.10.0</version>
</dependency>
jdbc連接配接的代碼實作比較特殊，因為沒有對應的java/scala類實作
ConnectorDescriptor
，是以不能直接
tableEnv.connect()
。不過Flink SQL留下了執行DDL的接口：
tableEnv.sqlUpdate()
對于jdbc的建立表操作，天生就适合直接寫DDL來實作，是以我們的代碼可以這樣寫：
// 輸出到 Mysql
val sinkDDL: String =
"""
|create table jdbcOutputTable (
| id varchar(20) not null,
| cnt bigint not null
|) with (
| 'connector.type' = 'jdbc',
| 'connector.url' = 'jdbc:mysql://localhost:3306/test',
| 'connector.table' = 'sensor_count',
| 'connector.driver' = 'com.mysql.jdbc.Driver',
| 'connector.username' = 'root',
| 'connector.password' = '123456'
|)
""".stripMargin
tableEnv.sqlUpdate(sinkDDL)
aggResultSqlTable.insertInto("jdbcOutputTable")
4.7.6 将表轉換成DataStream
表可以轉換為DataStream或DataSet。這樣，自定義流處理或批處理程式就可以繼續在 Table API或SQL查詢的結果上運作了。
将表轉換為DataStream或DataSet時，需要指定生成的資料類型，即要将表的每一行轉換成的資料類型。通常，最友善的轉換類型就是Row。當然，因為結果的所有字段類型都是明确的，我們也經常會用元組類型來表示。
表作為流式查詢的結果，是動态更新的。是以，将這種動态查詢轉換成的資料流，同樣需要對表的更新操作進行編碼，進而有不同的轉換模式。
Table API 中表到 DataStream 有兩種模式：
- 追加模式（Append Mode）
用于表隻會被插入（Insert）操作更改的場景
- 撤回模式（Retract Mode）
用于任何場景。有些類似于更新模式中Retract模式，它隻有 Insert 和 Delete 兩類操作。
得到的資料會增加一個Boolean類型的辨別位（傳回的第一個字段），用它來表示到底是新增的資料（Insert），還是被删除的資料（老資料， Delete）。
代碼實作如下：
val resultStream: DataStream[Row] = tableEnv.toAppendStream[Row](resultTable)
val aggResultStream: DataStream[(Boolean, (String, Long))] =
tableEnv.toRetractStream[(String, Long)](aggResultTable)
resultStream.print("result")
aggResultStream.print("aggResult")
是以，沒有經過groupby之類聚合操作，可以直接用 toAppendStream 來轉換；而如果經過了聚合，有更新操作，一般就必須用 toRetractDstream。
4.7.7 Query的解釋和執行
Table API提供了一種機制來解釋（Explain）計算表的邏輯和優化查詢計劃。這是通過TableEnvironment.explain（table）方法或TableEnvironment.explain（）方法完成的。
explain方法會傳回一個字元串，描述三個計劃：
- 未優化的邏輯查詢計劃
- 優化後的邏輯查詢計劃
- 實際執行計劃
我們可以在代碼中檢視執行計劃：
val explaination: String = tableEnv.explain(resultTable)
println(explaination)
Query的解釋和執行過程，老planner和 blink planner 大體是一緻的，又有所不同。整體來講，Query都會表示成一個邏輯查詢計劃，然後分兩步解釋：
- 優化查詢計劃
- 解釋成 DataStream 或者 DataSet程式
而 Blink 版本是批流統一的，是以所有的Query，隻會被解釋成DataStream程式；另外在批處理環境 TableEnvironment 下，Blink版本要到 tableEnv.execute() 執行調用才開始解釋。