Hive SQL on Flink 構建流批一體引擎

• 應用層的對接。在流批割裂的環境下，應用層仍然是有不同的提交平臺，如何保證原來的應用層能無損且直接地對接到新的 SQL Gateway 上，是一個巨大的難點。

• 使用者作業遷移的成本。使用者原來的 Batch 作業是用 Hive SQL 進行撰寫的，現在則需要替換成 Flink SQL。為了保證使用者的作業能無損遷上來，我們需要解決語言上的相容和使用者所用的 UDF 的相容。

• Flink 對 Hive SQL 的相容，我們在 1.16 中大大提升了對 Hive SQL 本身的相容性。

• 我們在 Flink 社群引入了 SQL Gateway，從而相容 Hive 的生態。

2.1 Hive SQL on Flink 的具體工作

• 支援 Hive MetaStore 作為 Flink 的 Catalog，Hive 已有的表可自動註冊進 Flink 中，使用者無需再定義各種 DDL 來對映底層的 Hive 表。

• 支援 Hive MetaStore 儲存 Flink 定義的 Hive 表/ 非 Hive 表。

• 支援從 Hive MetaStore 獲得表的統計資訊，從而最佳化查詢的執行計劃，提升端到端 SQL 的效能。

• Hive 提供了非常豐富的 UDF，在 Flink 中我們可以直接呼叫 Hive 中內建的 UDF。換句話說，使用者使用 Flink 就能享受到 Hive 那套內建 UDF 所帶來的方便及易用性。

• 支援呼叫自定義的 Hive UDF。對於熟悉 Hive 的人，他們會基於 Hive UDF 的介面去定義自己的 UDF。但如果他們想用 Flink，又不想廢棄那些 UDF，更不想重寫。要怎麼辦呢？其實 Flink 支援呼叫使用者自定義的 Hive UDF，所以使用者不需要對 UDF 做任何重寫的工作，這極大的方便了使用者的操作。

• 支援流讀/批讀/流寫/批寫 Hive 表。

• 批讀 Hive 表支援靜態分割槽裁剪和動態分割槽裁剪。可以大幅削減讀取資料的規模，從而提升讀的效能和效率。

• 批讀 Hive 表支援併發推斷。在批場景下，併發設定是一個比較難的問題，但如果在批讀 Hive 場景下，我們可以透過 Hive 表的檔案資訊推斷出合理的併發，從而提升端到端鏈路的效能。

• 批寫/流寫 Hive 支援自定義分割槽提交策略。在批排程鏈路裡，我們可能會把先提交分割槽，然後觸發一些其他下游的操作或排程，這時我們無需引入其他額外的元件，直接在 Flink 裡自定義這些分割槽提交的策略即可。比如指定分割槽提交後，觸發定時任務或者在訊息佇列插一條資料等等。

• 流寫 Hive 表支援小檔案自動合併。在流的場景下，會生成很多小檔案，但在流寫 Hive 表時，我們支援小檔案的自動合併，透過將小檔案合併成更大的檔案，減少了小檔案的數量，從而緩解 HDFS 叢集的壓力。

• 批寫 Hive 表支援自動收集統計資訊，這一部分完全相容了 Hive 的行為。在使用 Hive 寫 Hive 表的時候，它會收集統計資訊並提交到 MetaStore。我們用 Flink 寫 Hive 表的時候，也能支援將統計資訊提交到 MetaStore，包括檔案的大小、資料的條數等等。

2.2 Flink 相容 Hive SQL 的架構

2.3 Flink 對 Hive SQL 的相容

• 支援 distribute by/sort by/ cluster by。

• 支援 multi insert。一個 scan 可以插入到多個不同資料的 sink 端，極大的提高了資料 ETL 鏈路的效率。

• 支援 insert directory。

• 支援 load data。

• 支援 create function using jar。

• ……

• 基於 Hive 2.3 的 qtest 測試集，12000 條 DQL/DML 都扔到 Flink 去執行，這些 SQL 都能夠被正常執行。

• 12000 條 DQL/DML 也包含了很多對 ACID 表的查詢。Hive 的 ACID 表在生產中用的較少，如果我們除去針對 ACID 表的 DQL/DML，相容度可達 97%。

2.4 Flink 對 Hive 生態的相容

2.5 引入 Flink SQL Gateway 的原因

• 目前 Flink 社群官方提供了 SQL Client 供使用者提交 SQL 作業。但由於 SQL Client 本身沒有服務化，使用者往往需要基於 SQL Client 做一層封裝，新增一個服務化的前端。透過該服務化的前端，使用者的 SQL 作業最終會被提交給 SQL Client 去執行。以上的過程比較繁瑣而且開發成本較大，因此，我們在社群提供了一個預設的服務化的實現，降低使用者的使用成本。

• 以上的方案是基於 SQL Client 來做的作業提交，但這套 API 並不穩定。而引入的 SQL Gateway 則提供了穩定的 API。

• 相比於 SQL Client, SQL Gateway 是 C/S 架構，更容易對接諸多生態 ，e.g. HiveServer2。

• 開箱即用，使用者可以直接使用 SQL Gateway 搭建一個生產可用的提交工具。

• 生態對接，提供了穩定的 API，方便 Flink 對接其它生態工具。

• 相容 HiveServer2 協議，提供了 HiveServer2 Endpoint 以相容 Hive 生態。

2.6 Flink SQL Gateway 架構

• REST Endpoint：用戶可以透過 REST 工具提交作業。

• HiveServer2 Endpoint：透過它我們就能提供對接 Hive 主流生態的能力。

2.7 HiveServer2 Endpoint

3.1 Hive SQL on Flink 構建流批一體引擎

• 第一，統一流批引擎。降低維護成本，提升研發的效率。因為我們現在就一套引擎了，所以維護成本會非常低。

• 第二，流批一體數倉。我們透過流批一體引擎構建出了流批一體 SQL 層。藉此，我們可以把流批一體的儲存考慮進來，構建完整的流批一體數倉架構。

• 第三，Hive SQL 實時化。目前 Hive SQL 主要還是跑在批引擎上，每天做一次排程，產生結果。如果把 Hive SQL 遷移到 Flink 中，我們就可以很方便的將它實時化改造。只要把引擎模式設定成流模式，就可以將其實時化，數倉實時化改造的成本非常低。

• 第四，OLAP & 聯邦查詢。我們可以基於 Flink + Hive SQL 搭建 OLAP 系統。藉助 Flink 對各種資料來源的支援，以及對 Hive SQL 稍微進行擴充套件就可以實現聯邦查詢。

3.2 基於 Hive 語法進行聯邦查詢

• 實時的 pipeline，我們往往透過 Flink 將 Kafka 的資料進行打寬聚合寫入下游，並透過 Flink 寫入 HDFS 的最終表。

• 離線的 pipeline，我們則可以透過週期性地排程 Flink 作業將資料寫入到 HDFS 中。為了保持資料的正確性，在 Lambda 架構之中往往透過將批的結果回刷到 HDFS 中，保證資料的正確性。

• 最佳化讀各種格式的檔案，包括對讀 Parquet 檔案的巢狀列 PushDown、FilterPushDown 的最佳化等，從而提升效能。

• 提升寫 Hive 端到端的生產可用性。比如，批模式下解決小檔案多的問題。

• 根據使用者的反饋不斷加強 Hive 的語法支援。

• SQL Client 支援向 SQL Gateway 提交 SQL，保證功能完整性。

• 補全認證功能，保證 SQL Gateway 基本生產可用。

• 基於 SQL Gateway 對接更多生態工具，增強 SQL Gateway 的應用範圍。