一、理想與現實 Apache Flink 是一個分散式流批一體化的開源平臺。Flink 的核心是一個提供數據分發、通信以及自動容錯的流計算引擎。Flink 在流計算之上構建批處理，並且原生的支持迭代計算，記憶體管理以及程式優化。 實時計算（Alibaba Cloud Realtime Compute， ...
一、理想與現實
Apache Flink 是一個分散式流批一體化的開源平臺。Flink 的核心是一個提供數據分發、通信以及自動容錯的流計算引擎。Flink 在流計算之上構建批處理，並且原生的支持迭代計算，記憶體管理以及程式優化。
實時計算（Alibaba Cloud Realtime Compute，Powered by Ververica）是阿裡雲提供的基於 Apache Flink 構建的企業級大數據計算平臺。在 PB 級別的數據集上可以支持亞秒級別的處理延時，賦能用戶標準實時數據處理流程和行業解決方案；支持 Datastream API 作業開發，提供了批流統一的 Flink SQL，簡化 BI 場景下的開發；可與用戶已使用的大數據組件無縫對接，更多增值特性助力企業實時化轉型。
Apache Flink 社區迎來了激動人心的兩位數位版本號，Flink 1.10.0 正式宣告發佈！作為 Flink 社區迄今為止規模最大的一次版本升級，Flink 1.10 容納了超過 200 位貢獻者對超過 1200 個 issue 的開發實現，包含對 Flink 作業的整體性能及穩定性的顯著優化、對原生 Kubernetes 的初步集成以及對 Python 支持（PyFlink）的重大優化。
Flink 1.10 同時還標志著對 Blink的整合宣告完成，隨著對 Hive 的生產級別集成及對 TPC-DS 的全面覆蓋，Flink 在增強流式 SQL 處理能力的同時也具備了成熟的批處理能力。
在過去的2019年，大數據領域的Flink異常火爆，從年初阿裡巴巴高調收購Flink的母公司，到秋天發佈的1.9以及最近的1.10版本完成整合阿裡Blink分支，各類分享文章和一系列國內外公司應用案例，都讓人覺得Flink是未來大數據領域統一計算框架的趨勢。尤其是看過阿裡雲上的實時計算平臺，支持完善的SQL開發和批流都能處理的模式讓人印(直)象(流)深(口)刻(水)。因為相對於公有雲產品，稍微有點規模的公司都更願意使用開源產品搭建自己的平臺，可是仔細研究Flink的官方文檔和源碼，準備擼起袖子開干時，才發現理想和現實的差距很大……
首先是阿裡實時計算平臺產品的SQL開發界面：
然而現實中Flink所支持的SQL開發API是這樣的：
// create a TableEnvironment for specific planner batch or streaming
TableEnvironment tableEnv = ...; // see "Create a TableEnvironment" section
// register a Table
tableEnv.registerTable("table1", ...) // or
tableEnv.registerTableSource("table2", ...); // or
tableEnv.registerExternalCatalog("extCat", ...);
// register an output Table
tableEnv.registerTableSink("outputTable", ...);
// create a Table from a Table API query
Table tapiResult = tableEnv.scan("table1").select(...);
// create a Table from a SQL query
Table sqlResult = tableEnv.sqlQuery("SELECT ... FROM table2 ... ");
// emit a Table API result Table to a TableSink, same for SQL result
tapiResult.insertInto("outputTable");
// execute
tableEnv.execute("java_job");最後翻遍Flink文檔發現提供了一個實驗性質的命令行SQL客戶端:
此外當我們用開源Flink代碼部署一套集群後，整個集群有 JobManager 和 TaskManager 兩種角色，其中 JobManager 提供了一個簡單的管理界面，提供了上傳Jar包執行任務的功能，以及一些簡單監控界面，此外還提供一系列管理和監控的 Rest Api，可惜都沒有和SQL層面直接相關的東西。
之所以有這一系列理想與現實的差異，是因為Flink更多的定位在計算引擎，在開發界面等方面暫時投入較少，但是每寫一個SQL然後嵌入到代碼中編譯成JAR包上傳到Flink集群執行是客(小)戶(白)所不能接受的，這也就需要我們自己開發一套以SQL作業為中心的管理平臺（對用戶暴露的web系統），由該平臺管理 Flink 集群，共同構成 Flink SQL 計算平臺。
二、平臺功能梳理
一個完整的SQL平臺在產品流程上至少（第一版）需要有以下部分。
SQL作業管理：新增、調試、提交、下線SQL任務
數據源和維表管理：用DDL創建數據源表，其中維表也是一種特殊數據源
數據匯管理：用DDL創建數據結果表，即 insert into 結果表 select xxx
UDF管理：上傳UDF的jar包
調度和運維：任務定時上下線、任務縮容擴容、savepoint管理
監控：日誌查看、指標採集和記錄、報警管理
其他：角色和許可權管理、文檔幫助等等……
除了作為Web系統需要的一系列增刪改查和交互展示功能外，大部分功能可以通過操作Flink集群提供的Rest介面實現，但是其中沒有SQL相關內容，也就是前面四項功能（提交SQL、DDL、UDF，後文統稱提交作業部分）都需要自己實現和 Flink 的交互，這也是構建平臺的第一個挑戰。
