前言

Apache Hive 經過多年的發展，目前基本已經成為業界構建超大規模數據倉庫的事實標準和數據處理工具，Hive 已經不單單是一個技術組件，而是一種設計理念。Hive 有 JDBC 客戶端、支持標準 JDBC 接口訪問的 HiveServer2 服務器、管理元數據服務的 Hive Metastore，以及任務以 MapReduce 分布式任務運行在 YARN 上。

標準的 JDBC 接口、標準的 SQL 服務器、分布式任務執行以及元數據中心，這一系列組合讓 Hive 完整地具備了構建一個企業級數據倉庫的所有特性，并且 Hive 的 SQL 服務器是目前使用最廣泛的標準服務器。

雖然 Hive 有非常明顯的優點，可以找出完全替代 Hive 的組件寥寥無幾，但是并不等于 Hive 在目前階段是一個完全滿足企業業務要求的組件，很多時候選擇 Hive 出發點并不是因為 Hive 很好地支持了企業需求，單單是因為暫時找不到一個能支撐企業訴求的替代服務。

企業級數倉構建需求

數倉架構通常是一個企業數據分析的起點，在數倉之下會再有一層數據湖，用來做異構數據的存儲以及數據的冷備份。但是也有很多企業，特別是幾乎完全以結構化數據為主的企業在實施上會把數據湖和企業數倉庫合并，基于某個數倉平臺合二為一。

企業在考慮構建自身數倉體系的時候，雖然需要參考現有的行業技術體系，以及可以選擇的組件服務，但是不能太過于局限于組件本身，尋找 100%開箱即用的產品。太過局限于尋找完全契合的組件服務必然受限于服務本身的實現，給未來擴展留下巨大的約束。企業數據倉庫架構必然不等于一個組件，大部分企業在數倉架構實施的都是基于現有的部分方案，進行基于自己業務合適的方向進行部分開發與定制，從而達到一個半自研的穩態，既能跟上業務變化的速度，又不過于依賴和受限于組件自身的發展。

一般來說企業級數倉架構設計與選型的時候需要從以下幾個維度思考：

• 開發的便利性：所選擇的數倉架構是否具有很好的開發生態，可以提供不同類型的開發態接口，不限于 SQL 編輯器，代碼提交，以及第三方工具整合。
• 生態：所選擇實現引擎自身是否有很好的生態功能，或者是否可以很好的與其他服務集成，例如數據湖引擎 delta lake，icebeg，hudi 等優秀組件出現，但是 Hive 集成的節奏卻非常慢。
• 解耦程度：分布式任務必然需要多個組件的協調，例如分布式存儲，資源管理，調度等，像 Hive 就重度依賴于 YARN 體系，計算引擎也與 MR 強綁定，在解耦方面較弱，如果企業考慮在 K8S 上構建自己的計算引擎，Hive 面臨的局限會更加明顯。
• 性能：整體架構是否擁有更好的性能。
• 安全：是否支持不同級別，不同力度的用戶訪問和數據安全鑒權體系。

對于企業數倉架構來說，最重要的是如何基于企業業務流程來設計架構，而不是基于某個組件來擴展架構。

一個企業數倉的整體邏輯如上圖所示，數倉在構建的時候通常需要 ETL 處理和分層設計，基于業務系統采集的結構化和非結構化數據進行各種 ETL 處理成為 DWD 層，再基于 DWD 層設計上層的數據模型層，形成 DM，中間會有 DWB/DWS 作為部分中間過程數據。

從技術選型來說，從數據源的 ETL 到數據模型的構建通常需要長時任務，也就是整個任務的運行時間通常是小時及以上級別。而 DM 層主要是支持業務的需求，對時效性要求比較高，通常運行在 DM 層上的任務時間以分鐘作為單位。

基于如上的分層設計的架構圖可以發現，雖然目前有非常多的組件，像 Presto、Doris、ClickHouse、Hive 等等，但是這些組件各自工作在不同的場景下，像數倉構建和交互式分析就是兩個典型的場景。

交互式分析強調的是時效性，一個查詢可以快速出結果，像 Presto、Doris、ClickHouse 雖然也可以處理海量數據，甚至達到 PB 及以上，但主要還是用在交互式分析上，也就是基于數據倉庫的 DM 層，給用戶提供基于業務的交互式分析查詢，方便用戶快速進行探索。由于這類引擎更聚焦在交互式分析上，因此對于長時任務的支持度并不友好，為了達到快速獲取計算結果，這類引擎重度依賴內存資源，需要給這類服務配置很高的硬件資源，這類組件通常有著如下約束：

• 沒有任務級的重試，失敗了只能重跑 Query，代價較高。
• 一般全內存計算，無 shuffle 或 shuffle 不落盤，無法執行海量數據。
• 架構為了查詢速度快，執行前已經調度好了 task 執行的節點，節點故障無法重新調度。

一旦發生任務異常，例如網絡抖動引起的任務失敗、機器宕機引起的節點丟失，再次重試所消耗的時間幾乎等于重新提交一個任務。在分布式任務的背景下，任務運行的時間越長，出現錯誤的概率越高。對于此類組件的使用，業界最佳實踐的建議也是不超過 30 分鐘左右查詢使用這類引擎是比較合適的。

而在離線數倉場景下，幾乎所有任務都是長時任務，也就是任務運行時長在小時級以上，這時就要求執行 ETL 和構建數倉模型的組件服務需要具有較高的容錯性和穩定性，當任務發生錯誤時可以以低成本的方式快速恢復，盡可能避免因為部分節點狀態異常導致整個任務完全失敗。

可以發現在這樣的訴求下類似于 Presto、Doris、ClickHouse 就很難滿足這樣的要求，而像 Hive、Spark 這類計算引擎依托于 Yarn 做資源管理，對于分布式任務的重試、調度、切換有著非常可靠的保證。Hive、Spark 等組件自身基于可重算的數據落盤機制，確保某個節點出現故障或者部分任務失敗后可以快速進行恢復。數據保存于 HDFS 等分布式存儲系統上，自身不管理數據，具有極高的穩定性和容錯處理機制。

反過來，因為 Hive、Spark 更善于處理這類批處理的長時任務，因此這類組件不擅長與上層的交互式分析，對于這種對時效性要求更高的場景，都不能很好地滿足。所以在考慮構建數倉的時候，通常會選擇 Hive、Spark 等組件來負責，而在上層提供交互式分析查詢的時候，通常會使用 Presto、Doris、ClickHouse 等組件。

歸納如下：

• Presto、Doris、ClickHouse：更注重交互式分析，對單機資源配置要求很高，重度依賴內存，缺乏容錯恢復，任務重試等機制，適合于 30 分鐘以內的任務，通常工作在企業的 DM 層直接面向業務，處理業務需求。
• Hive、Spark：更注重任務的穩定性，對網絡，IO 要求比較高，有著完善的中間臨時文件落盤，節點任務失敗的重試恢復，更加合適小時級以上的長時任務運行，工作在企業的的 ETL 和數據模型構建層，負責清洗和加工上層業務所需要的數據，用來支撐整個企業的數倉構建。

一個企業在實施數據平臺的時候，由多個不同組件各自工作在不同的架構層中，無法相互取代，相互協作配合，承載整個企業的數據平臺業務。

企業級數倉技術選擇

Google 發表的三篇論文從存儲、計算、檢索三個方向闡述了海量數據下一種新的分布式數據加工處理技術，這三個方向被雅虎 Nutch 團隊實現后貢獻給 Apache，也就是目前大家看到的 HDFS、MapReduce 和 HBase，形成了早期 Hadoop 的三大利器。

然而這三大利器更聚焦在異構數據的信息提取處理上，沒有提供對結構化數據很友好的類似 SQL 語法的分析入口，同時在編程態的支撐也不夠友好，只有 Map 和 Reduce 兩階段，嚴重限制了業務處理的實現，雅虎團隊也是爬蟲相關業務孵化而出，可以看出 Hadoop 早期的三大套件有著如下特點：

• 門檻高，需要編程實現，并且編程態受限于 MapReduce 的兩階段約束。
• 以離散數據處理為主，對分析能力、查詢等常用數據分析功能支持不足。
• 沒有交互式客戶端，無法實現交互式探索。

Hive 就是誕生在這樣的較大的行業背景下，Hive 的出現剛好彌補了 Hadoop 只能用來做離線數據處理這個缺陷，提供了一種常用的分析接口，并且提供了非常好的用戶交互方式。

Hive 整體架構如上圖所示，Hive 提供 JDBC 接口實現支持以編程形式進行交互，同時業內幾乎所有 SQL Client、開源或商業 BI 工具都支持通過標準 JDBC 的方式連接 Hive，可以支持數據探索的動作，極大地豐富了大數據生態圈下的組件多樣性，同時也降低了使用門檻，可以讓熟悉 SQL 的人員低成本遷移。

基于這些設計非常好的特效，加上 Hive 經過多年的逐步完善，發展到今天已經是一個非常穩定成熟的生產環境可用的數據倉庫組件，甚至替代品都很難找到，因此使用 Hive 作為數據倉庫的構建基礎是一個非常好的選擇。

如上圖所示，其中有很多優點：

• 穩定：穩定性是 Hive 一個非常讓人稱道的特性，很多時候雖然 Hive 的性能，計算速度不及其他引擎，但是 Hive 的穩定性卻一直是非常好的。
• 低門檻：只需要掌握基本的 SQL 技能，便可使用 Hive 進行開發，相比其他分布式計算引擎引擎成本更低。
• 生態豐富：Hive 和 Hadoop 生態圈緊密結合，而 Hive 自身的 Metastore 也成了大數據生態圈內的標準元數據服務，大部分引擎都支持直接適配 MetaStore。
• 擴展方便：Hive 自身的 UDF 機制可以快速基于業務需要擴展功能。
• 安全：Hive 支持 Kerberos/LDAP 多種認證方式，并且和 Ranger 結合可以做到更細粒度的行列權限級別，擁有較好的數據安全。
• 集成成本低：MapReduce 只支持編程態的接口，并且不支持迭代計算，Hive 封裝了 MapReduce 提供 SQL 的接口，可以很低成本的和上層數據挖掘，數據分析工具進行集成。

所以，雖然 Hive 出現已經有很長時間了，但依舊是數倉構建的首選，在整個數倉構建中隨處可見 Hive 的身影。盡管 Hive 有種種優點，讓人難以割舍，但是并不等于能很好地支撐企業業務需求。很多時候選擇 Hive 僅僅是因為暫時沒有其他可選的組件，如果自己從頭開發一個，或者基于某個組件改造，成本又會遠超企業預期，因此不得不繼續選擇使用 Hive。

基于實踐來看，Hive 在構建企業數倉過程中存在的主要局限圍繞在以下幾個方面：

• 性能：Hive 基于 MapReduce 雖然帶來了非常好的穩定性，同時也降低了它的性能，雖然有 TEZ 做一定的優化，但是與同類的計算引擎 Spark 相比依舊有非常大的差距。
• 資源配置：由于 Hive 底層使用 MapReduce 作為計算引擎，而 MapReduce 對 SQL 不友好，因此 Hive 在 HiveServer2 層面實現了 SQL 的轉換處理，再生成基于 MapReduce 的物理計劃，從而導致 HiveServer2 需要非常高的配置，才能維持足夠好的穩定性。
• 并發：Hive 的并發受限于 HiveServer2，企業需要維護多個高配的 HiveServer2 實例才能支持更好的并非，通常 Hive 的瓶頸都在 HiveServer2 而不是更底層的分布式計算。
• 容錯成本：Hive 基于 HiveServer2 進行 SQL 的分析處理，多個 HiveServer2 之間相互獨立不共享信息，因此當 HiveServer2 掛掉后，整個 HiveServer2 的任務都會結束，需要客戶端自行重試，為整個作業級別的容錯重啟。
• 事務支持：Hive 的事務設置在 HiveServer2 上，一旦 HiveServer2 實例開啟事務后，整個通過該 HiveServer2 的請求都會開啟事務，整個事務成本過高。
• 部署：如果企業的計算引擎部署是基于 K8S 等容器架構，Hive on K8S 將會帶來非常大的部署成本。

雖然 Hive 在以上局限層面也做了很多嘗試(Hive On Spark)，但是受限于 Hive 的架構，HiveServer2 自身有自己的 SQL 解析引擎，為了兼容架構將解析后的結果直接翻譯成 Spark 最底層的接口，整體性能反而提升不大。

除了 Hive 之外，還有非常多其他的優秀組件。然而，從企業數倉技術選型的視角來看，適合用來構建數據倉庫的，目前只有 Hive 和 Spark SQL 相對更加合適，在這兩個組件中，Spark SQL 相對 Hive 的優勢又更加明顯。

SparkSQL 如何支撐企業級數倉

Spark 引擎因為自身強大的生態和方便的編程接口被廣泛應用在數據處理場景下，Spark 提供的 Spark SQL 模塊更是為使用 Spark 支撐企業數據倉庫提供了一個良好的基礎設施。

如上圖所示，一個典型的數據倉庫架構需要包含不同層次的模型構建。由于數據量大、數據結構異構等多種原因，大數據架構下的企業數倉構建拋棄了基于關系型數據庫下的 Cube 設計，直接采用基于分布式任務進行處理來構建多層數據模型。因此對于構建企業數倉的服務來說，有著如下要求：

• 支持長時任務，通常是小時以上，天級別居多。
• 支持多任務，也就是高并發。
• 穩定性必須被保障。
• 速度快。
• 支持 SQL 的交互式接口。
• 易于集成。
• 支持任務的重跑和容錯以及快速任務失敗恢復。

基于以上特性可以發現，在目前可選擇的組件范圍內，Spark SQL 相比其他組件(乃至 Hive)更加適合承擔這類任務。但是很多企業在進行架構設計的時候割舍不掉 Spark SQL 帶來的豐富特性，又愁于 Spark SQL 缺乏類似 Hive 這樣的 SQL 服務器，于是退而求其次變成 Hive 與 Spark SQL 兩個組件共存的形態，Hive 退化為僅僅提供 MetaStore 服務，因此從很多實踐的現象來看，Hive 構建企業數倉已是過去式，采用 Spark SQL 進行數據倉庫的構建是眾多的選擇。

如上圖所示，企業在構建數倉的時候，通過一個 Spark SQL Server 提供基于 SQL 接口的常駐服務，同時也可以采用 Spark Submit 的方式直接提交 Jar 任務去運行，既能達到提供標準 SQL 交互式接口，又能提供更靈活的編程態接口。

從不同的企業級數倉構建視角來看，Hive 帶來的約束都越來越大，而 Spark SQL 的成熟度和發展趨勢已經完全具備取代 Hive 來構建整個數倉，Spark SQL 的優勢集中體現在如下方面：

• 豐富的生態：Spark 不僅可以和很多組件集成，其自身擁有生態已經涵蓋各個方面，從數據分析到機器學習和圖計算。
• 開放：Spark 架構設計上非常開放，可以快速整合其他產品，例如相比 Hive，在集成 Iceberg，Hudi 等特性方面就會開放很多。
• 部署：Spark 既可以部署在 ECS 虛擬機上，也可部署在 K8S 架構上，多種部署形態非常靈活。
• 性能：Spark 的機制的流批處理性能非常合適用來構建企業數倉。
• 易于開發：Spark SQL 既有 SQL 接口，也支持靈活的可迭代編程接口，非常方便不同場景下的數據開發。
• 安全：Spark SQL 可和不同的安全服務集成，實現細粒度的鑒權。

因此，完全基于使用 Spark SQL 來支撐企業級的數倉是完全可行的，并且在目前也被眾多企業實踐驗證。

如上圖所示，一個基于 Spark SQL 構建的企業數倉架構邏輯架構設計上包含以上幾個部分，每一個 Spark SQL 引擎都是一個服務器，Spark SQL 引擎將自己的信息注冊到 Zookeeper 中，SQL 服務器基于 Zookeeper 中的 Spark SQL 引擎來執行客戶端過來的請求，SQL 服務器是一個兼容 Hive JDBC 接口的服務器，在使用 Spark SQL 來支撐數倉構建的時需要重點考慮的實施點是：

• 如何提供一個交互服務用來支撐不同的客戶端來連接，包括交互式的 beeline，以及編程態的 JDBC 和工具接口。
• 如何打通權限對接，如果是 Ranger 的話需要的是 Spark SQL Ranger Plugin。
• 如何支持跨多個隊列的任務提交。

使用 Spark SQL 支撐企業級數倉的核心之處還是在于如何提供一個好用的任務服務器，用來支撐任務的管理。任務管理服務器在邏輯上與 HiveServer2 相似，但是更加的輕量，沒有 HiveServe2 中復雜而繁重的 SQL 解析，同時又沒有 Spark Thrift Server 這種自身就是一個 YARN 作業的約束。企業可以基于自身的業務流程，開發一個輕量的服務器，在這方面字節有非常深的實踐經驗，同時也有自己的 Spark SQL 引擎服務器，可關注后續的動態。同時業界也有其他企業做了類似的工作，例如網易開源的 Kyuubi。

Kyuubi 整個架構圖如上所示，Kyuubi 基于 Spark SQL 之上，較好地彌補了 Spark Thrift Server 在多租戶、資源隔離和高可用等方面的不足，是一個真正可以滿足大多數生產環境場景的開源項目。但是 Kyuubi 在設計時考慮的是如何彌補 Spark Thrift Server 的不足，目的在于增強 Spark SQL 的能力，而不是對等設計一個可以替換 Hive 組件的服務。因此對于遺留項目來說遷移成本較高，Spark SQL 與 Hive 有著兩套不兼容的 SQL，在使用 Kyuubi 的時候如何降低遺留系統的遷移成本將是一個非常大的工作量。

而行業也有開源的 Spark Thrift Server，該思路是非常優秀的，但是因為開發過程中有點太過于局限，導致依舊存在很多問題，主要體現在：

• Driver 單點：整個 Spark thrift server 以一個 Spark 任務的形式運行在 YARN 上，所有的請求都運行在一個 Driver 中，一旦 Driver 掛掉后，所有任務都會同時失敗。
• 資源隔離：因為 Spark thrift server 是以 Spark 任務的形式運行在 YARN 上，因此提交的任務如果有跨隊列提交需求的時候，Spark thrift server 很難支撐，其次多個任務運行在同一個 Driver 之中，資源使用會相互影響，很難更精細化的進行資源的管理。
• 多租戶：Spark thrift server 從請求層面是可以支持多用戶的，但是從架構層面來看 Spark thrift server 是一個運行在 Yarn 上的任務，它也有自己的 Application Id 有自己的任務提交者，因此它實際上是以一個超級管理員的身份運行，再做二次租戶隔離，必然存在一定的資源安全問題。
• 高可用：Spark thrift server 本身是沒有高可用涉及的，因此它的高可用需要自行單獨設計，且還得考慮客戶端的兼容，例如 Hive JDBC 將 HA 信息存儲在 ZK 中，而 Spark thrift server 沒有這樣的機制，因此高可用的實施成本較高。

因此雖然 Spark 提供了 Spark thrift server 服務用來提供類似 JDBC 這樣的接口交互方式，但是目前依舊缺乏很多生成功能，導致在生產環境使用的情況非常少，Spark thrift server 更像是一個小眾的半成品，小修小補地嘗試著解決部分問題，但是沒有給予一個徹底的方案，導致現在有點缺乏實際的生產應用。

字節跳動 EMR 產品在 Spark SQL 的優化實踐

數據湖引擎集成

Hudi、Iceberg 等數據湖引擎目前使用的越來越廣泛，很多 B 端客戶在使用 Spark SQL 的時候也存在需要使用數據湖引擎的需求，因此字節 EMR 產品需要將數據湖引擎集成到 Spark SQL 中，在這個過程中遇到了非常多的問題。

首先在與 Iceberg 集成的時候，對體驗和易用的問題進行了優化，用戶在使用 Spark SQL 過程中，需要手動輸入很多指令，并且需要找到對應的 spark-iceberg 依賴包，這個也是目前集成 Iceberg 最常用的方案。我們的解決方式是在預先安裝的過程中，提前把 iceberg 的相關 jar 包放到 spark jars 目錄下，這樣用戶只需要指定 catalog 即可，無需再手動輸出很多指令。

其次在 Spark 與 Hive 跨引擎分析場景下使用 Iceberg，Spark 正常創建表，Presto/Trono 可以正常讀寫，但 Hive 無法正常讀寫，這個問題官方的文檔也沒有清晰的描述，解決方案是需要修改 Spark 的配置文件或者修改 Hive 的 hive-site-spark override 配置，確保初始化出來的 Spark Session 中的配置項 iceberg.engine.hive.enable 的值為 true，Hive 才能正常地讀取 Spark 創建的表。

問題本質上是由于 Iceberg 為了支持 Hive 引擎，在整體的設計上做了一些妥協，使用了 Storage Handler 的方式去實現 Hive 對 Iceberg 格式的表的讀寫，需要顯式的指定 Hive 的 Input/Output Format 實現，而 Presto/Trono 則可以基于 Hive 的 format_type 自動識別表的格式進行識別。

在兼容性上，由于 Iceberg 0.12 版本不支持 Spark 3.2，由于升級 Spark 的影響范圍非常大，于是更新了 Iceberg，使用了社區的一個 master 的 snapshot 版本進行編譯，與 Spark 3.2 進行集成。

Spark SQL 服務器

雖然行業針對 Spark SQL 提供一個 SQL 服務器已經有 Spark Thrift Server 或者 Kyuubi 這樣的工具，但是在某些 B 端客戶的業務背景下，這些工具并不能完全滿足要求，因此字節跳動 EMR 團隊自己設計實現了 Spark SQL Server，主要聚焦解決的是如下場景：

• 兼容 Hive 語義：由于大部分 B 端客戶早期是基于 Hive 構建的數據倉庫，后續逐步全部替換為 Spark SQL，中間必然面臨大量的系統遷移，而由于 Hive 與 Spark SQL 語義不盡相同，重寫 SQL 實現的工作量非常大，因此在字節 EMR 產品中的 Spark SQL Server 中實現 Hive 語義和 Spark SQL 語義的兼容，在實現方案上采用的時候講 Hive SQL 解析注入到 Spark 引擎中，形成一個 SQL Parser Chain，最終會匹配到某一個解析器，實現對 SQL 的解析，從而達到對整個 SQL 語義的兼容。
• 提前初始化 Spark SQL 引擎：在業務請求到達前提前在 YARN 上提交 Spark 任務，初始化資源信息，讓整個引擎處于等待的狀態，可以減少任務提交消耗的時間，在用戶較多的情況下可以提示整體的任務執行時間。
• 跨 Yarn 隊列的任務提交：用戶可以指定 Yarn 隊列執行任務。

如上圖所示，SQL 服務器是一個實現了 Thrift 接口的服務器，提供標準的 JDBC 訪問接口，Spark SQL 引擎同樣實現了 Thrift 接口，Spark SQL 引擎在服務啟動的時候便已經被提交至 Yarn，處于等待狀態。當業務任務到達的時候，由 SQL 服務器實現引擎的篩選，匹配一個已經存在的引擎，或者重新提交一個全新的引擎用來執行任務。

SQL 服務器支持 OpenLDAP、Kerberos 等常用的權限認證，同時支持多種不同的隔離級別，例如 Session 級別則每一個業務 SQL 都會初始化一個 Spark SQL 引擎用來接收任務，任務執行結束后，引擎從 Yarn 中銷毀。而 User 級別則針對用戶會初始性 0-N 個引擎，常駐于 Yarn 中，處于交替執行任務。

這樣的服務器設計打破了 Spark Thrift Server 的單 Driver 所帶來的局限，解耦了 SQL 服務和任務執行。也就支持更細粒度的資源管理和跨隊列的任務提交。

同時也兼容了 Hive 的接口，用戶可以通過如下方式訪問服務器：

HA 訪問鏈接：

./bin/beeline -u 
"jdbc:hive2://emr-5fqkwudj144d2gc1k8hi-master-1/;serviceDiscoveryMode=zooKeeper;zooKeeperNamespace=midas/ha;auth=LDAP" 
-n emr_dev -pEMR123456emr

非 HA 訪問鏈接：

./bin/beeline -u "jdbc:hive2://emr-master-2:10005/default;auth=LDAP” -n 
test_sub -pEMR123456emr

HA 模式下的信息被記錄在 Zookeeper 中，保存的內容格式與 HiveServer2 的內容一致，能確保使用 Hive 的客戶端可以直接訪問 HA 模式下的服務器。

Spark SQL 多租戶

在 Hive 任務執行過程中，HiveServer2 服務承擔了提供 SQL 服務器進行用戶身份認證、權限判斷，以及解析 SQL 生成最終的執行計劃，再由 MR 引擎執行具體的分布式任務。

在這個過程中 HiveServer2 承擔了非常重的職責，因此需要消耗非常大的資源，因此會很大程度的影響用戶的并發。對于分布式任務運行來說，它的資源約束來自于 Yarn 作為資源管理器所分配的資源，但是在 Hive 架構下卻受限于 HiveServer2 的影響，導致用戶并發的數量無法隨著 Yarn 資源的提升而提升。

而在 Spark SQL 引擎中，SQL 解析是下推到引擎內部，與具體的分布式任務執行合為一體，不需要單獨的服務器去做 SQL 解析。也正因為 Spark SQL 與 Hive 在解析模塊的架構存在差異，Hive On Spark 的模式會變得非常難。

針對如上的場景，字節跳動 EMR 團隊重新設計的 SQL 服務器只負責任務的接收，進行用戶資源、權限和身份的判斷，然后將任務發送給運行在 Yarn 中的 Spark SQL 服務器。打破了 Hive 這種并發受制于 HiveServer2 和 Yarn 兩層約束的局面，只由 Yarn 的資源決定用戶的并發程度，從而極大的降低了 Spark SQL 服務器的資源需求，增強了其穩定性，在用戶并發上有了非常大的提升。

其次通過引擎預熱的功能減少任務執行的時間，提升整體速度，引擎預熱指的是在服務啟動的時候便向 Yarn 提交 Spark SQL 引擎，處于等待的狀態，當業務請求到達的時候，基于業務類型從已經處于就緒的引擎中選擇一個引擎來執行任務。

并不是每一個預熱提交的引擎都會被選擇執行，在 SQL 服務器中存在如下三種引擎隔離級別：

• Session：基于每一個 connection 都會全新提交 Spark SQL 引擎，在鏈接斷開后，引擎從 Yarn 上銷毀。
• User：同一個用戶可以共享多個 Spark SQL 引擎，具體的 Spark SQL 引擎個數由該用戶提交的任務資源需求決定，引擎在連接斷開后不會銷毀，直到引擎空閑時長到達上限。
• Open：所有用戶都可共享的 Spark SQL 引擎，通常是用來應對大賬號，或者集群不需要做權限管理的場景。

由此可見只有在 User、Open 的級別下引擎預熱才會產生價值，預熱省去了 Spark Submit 的時間，當用戶數量足夠多，群體為統計單位所節省的時間越多。

Spark SQL 事務支持

Hive 的事務力度是基于 HiveServer2 實現的，例如通過如下語法：

CREATE TABLE tm (a int, b int) stored as orc TBLPROPERTIES
('transactional'='true', 'transactional_properties'='insert_only')

可開啟事務，但是由于對事務的管理是在服務器上，因此需要開啟 ACID 的時候受影響的是整個 HiveServer2 的所有請求，而 Spark SQL 很好地集成和支持了 Hudi，Iceberg 等數據湖格式，因此在 Spark SQL 服務器中不需要實現類似 HiveServer2 的事務機制，只需要在最終讀取處理數據的時候，采用 Hudi、Iceberg 等特性便可達到支持事務的效果。

例如對于 Icdberg 數據格式的表已支持 update、delete 操作：

MERGE INTO prod.nyc.taxis ptUSING (SELECT * FROM staging.nyc.taxis) stON 
pt.id = st.idWHEN NOT MATCHED THEN INSERT *;

因此當 Spark SQL 集成了 Iceberg 后，便具有了事務能力，再配合 SQL 服務器，便可在很低的成本上具有和 Hive 事務能力同等的效益，同時也沒有 Hive 下的一些約束，從這樣的架構設計上來看，能夠完整地替換 Hive。另外一個方面當用戶數量變多，同時數據會發生修改、更新等操作，很容易造大量的小廣播傳輸，從而引起 Driver 的 OOM。雖然大廣播也會存在 OOM 的問題，但是大廣播可以通過閾值控制，而小廣播閾值對其不生效，一旦說數量變多，很容易引起 Driver 的 OOM。字節 EMR 團隊通過對小廣播進行合并廣播，解決大量小廣播進行傳播，導致打爆 Driver 的情況出現。

尾聲

隨著企業的業務發展越來越復雜，需要更加靈活、更加高效的數倉架構，在這樣的業務驅動背景下，Hive 的局限變得越來越明顯，而基于 Spark SQL 靈活構建數倉的方案將會變得越來越主流。所以企業在考慮數據倉庫構建體系的時候，可以考慮如何基于 Spark SQL 構建自身數據體系，Spark 完善和開放的生態在未來必然會有更多優秀的服務圍繞 Spark 形成強大的優勢。