前言

有贊資料平臺從2017年上半年開始，逐步使用 SparkSQL 替代 Hive 執行離線任務，目前 SparkSQL 每天的執行作業數量5000個，佔離線作業數目的55%，消耗的 cpu 資源佔叢集總資源的50%左右。本文介紹由 SparkSQL 替換 Hive 過程中碰到的問題以及處理經驗和優化建議，包括以下方面的內容：

• 有贊資料平臺的整體架構。
• SparkSQL 在有讚的技術演進。
• 從 Hive 到 SparkSQL 的遷移之路。

一. 有贊資料平臺介紹

首先介紹一下有贊大資料平臺總體架構：

如下圖所示，底層是資料匯入部分，其中 DataY 區別於開源屆的全量匯入匯出工具 alibaba/DataX，是有贊內部研發的離線 Mysql 增量匯入 Hive 的工具，把 Hive 中歷史資料和當天增量部分做合併。DataX / DataY 負責將 Mysql 中的資料同步到數倉當中，Flume 作為日誌資料的主要通道，同時也是 Mysql binlog 同步到 HDFS 的管道，供 DataY 做增量合併使用。

第二層是大資料的計算框架，主要分成兩部分：分散式儲存計算和實時計算，實時框架目前主要支援 JStorm，Spark Streaming 和 Flink，其中 Flink 是今年開始支援的；而分散式儲存和計算框架這邊，底層是 Hadoop 和 Hbase，ETL主要使用 Hive 和 Spark，互動查詢則會使用 Spark，Presto，實時 OLAP 系統今年引入了 Druid，提供日誌的聚合查詢能力。

第三層是資料平臺部分，資料平臺是直接面對資料開發者的，包括幾部分的功能，資料開發平臺，包括日常使用的排程，資料傳輸，資料質量系統；資料查詢平臺，包括ad-hoc查詢以及後設資料查詢。有關有贊資料平臺的詳細介紹可以參考往期有贊資料平臺的部落格內容。
　　

​

二. SparkSQL技術演進

從2017年二季度，有贊資料組的同學們開始了 SparkSQL 方面的嘗試，主要的出發點是當時叢集資源是瓶頸，Hive 跑任務已經逐漸開始乏力，有些複雜的 SQL，通過 SQL 的邏輯優化達到極限，仍然需要幾個小時的時間。業務資料量正在不斷增大，這些任務會影響業務對外服務的承諾。同時，隨著 Spark 以及其社群的不斷髮展，Spark 及 Spark SQL 本身技術的不斷成熟，Spark 在技術架構和效能上都展示出 Hive 無法比擬的優勢。

從開始上線提供離線任務服務，再到 Hive 任務逐漸往 SparkSQL 遷移，踩過不少坑，也填了不少坑，這裡主要分兩個方面介紹，一方面是我們對 SparkSQL 可用性方面的改造以及優化，另一方面是 Hive 遷移時遇到的種種問題以及對策。

2.1 可用性改造

可用性問題包括兩方面，一個是系統的穩定性，監控/審計/許可權等，另一個是使用者使用的體驗，使用者以前習慣用 Hive，如果 SparkSQL 的日誌或者 Spark thrift server 的 UI 不能夠幫助使用者定位問題，解決問題，那也會影響使用者的使用或者遷移意願。所以我首先談一下使用者互動的問題。

使用者體驗

我們碰到的第一個問題是使用者向我們抱怨通過 JDBC 的方式和 Spark thrift server(STS) 互動，執行一個 SQL 時，沒有執行的進度資訊，需要一直等待執行成功，或者任務出錯時接收任務報錯郵件得知執行完。於是執行進度讓使用者可感知是一個必要的功能。我們做了 Spark 的改造，增加執行時的 operation 日誌，並且向社群提交了 patch(spark-22496)， 而在我們內部，更增加了執行進度日誌，每隔2秒列印出當前執行的 job/stage 的進度，如下圖所示。

監控

SparkSQL 需要收集 STS 上執行的 SQL 的審計資訊，包括提交者執行的具體 SQL，開始結束時間，執行完成狀態。原生 STS 會把這些資訊通過事件的方式 post 到事件匯流排，監聽者角色 (HiveThriftServer2Listener) 在事件匯流排上註冊，訂閱消費事件，但是這個監聽者只負責 Spark UI 的 JDBC Tab 上的展示，我們改造了 SparkListener 類，將 session 以及執行的 sql statement 級別的訊息也放到了匯流排上，監聽者可以在匯流排上註冊，以便消費這些審計資訊，並且增加了一些我們感興趣的維度，如使用的 cpu 資源，歸屬的工作流(airflowId)。同時，我們增加了一種新的完成狀態 cancelled，以方便區分是使用者主動取消的任務。

Thrift Server HA

相比於 HiveServer，STS 是比較脆弱的，一是由於 Spark 的 driver 是比較重的，所有的作業都會通過 driver 編譯 sql，排程 job/task 執行，分發 broadcast 變數，二是對於每個 SQL，相比於 HiveServer 會新起一個程式去處理這個 SQL 的執行，STS 只有一個程式去處理，如果某個 SQL 有異常，查詢了過多的資料量， STS 有 OOM 退出的風險，那麼生產環境維持 STS 的穩定性就顯得無比重要。

除了必要的存活報警，首先我們區分了 ad-hoc 查詢和離線排程的 STS 服務，因為離線排程的任務往往計算結束時是把結果寫入 table 的，而 ad-hoc 大部分是直接把結果彙總在 driver，對 driver 的壓力比較大；此外，我們增加了基於 ZK 的高可用。對於一種型別的 STS（事實上，有讚的 STS 分為多組，如 ad-hoc，大記憶體配置組）在 ZK 上註冊一個節點，JDBC 的連線直接訪問 ZK 獲取隨機可用的 STS 地址。這樣，偶然的 OOM ，或者 bug 被觸發導致 STS 不可用，也不會嚴重到影響排程任務完全不可用，給開發運維人員比較充足的時間定位問題。

許可權控制

之後有另一個文章詳細介紹我們對於安全和許可權的建設之路，這裡簡單介紹一下，Hive的許可權控制主要包括以下幾種:

• SQL Standards Based Hive Authorization
• Storage Based Authorization in the Metastore
• ServerAuthorization using Apache Ranger \u0026amp; Sentry

調研對比各種實現方案之後，由於我們是從無到有的增加了許可權控制，沒有歷史負擔。我們直接選擇了ranger + 元件 plugin 的許可權管理方案。

除了以上提到的幾個點，我們還從社群 backport 了數十個 patch 以解決影響可用性的問題，如不識別 hiveconf/hivevar (SPARK-13983)，最後一行被截斷(HIVE-10541) 等等。

2.2 效能優化

之前談到，STS 只有一個程式去處理所有提交 SQL 的編譯，所有的 SQL Job 共享一個 Hive 例項，更糟糕的是這個 Hive 例項還有處理 loadTable/loadPartition 這樣的 IO 操作，會阻塞其他任務的編譯，存在單點問題。我們之前測試一個上萬 partition 的 Hive 表在執行 loadTable 操作時，會阻塞其他任務提交，時間長達小時級別。對於 loadTable 這樣的IO操作，要麼不加鎖，要麼減少加鎖的時間。我們選擇的是後者，首先採用的是社群 SPARK-20187 的做法，將 loadTable 實現由 copyFile 的方式改為 moveFile，見下圖：

之後變更了配置spark.sql.hive.metastore.jars=maven，執行時通過 Maven 的方式載入 jar 包，解決包依賴關係，使得載入的 Hive 類是2.1.1的版本，和我們 Hive 版本一致，這樣得好處是很多行為都會和 Hive 的相一致，方便排查問題；比如刪除檔案到 Trash，之前 SparkSQL 刪除表或者分割槽後是不會落到 Trash 的。

2.3 小檔案問題

我們在使用 SparkSQL 過程中，發現小檔案的問題比較嚴重，SparkSQL 在寫資料時會產生很多小檔案，會對 namenode 產生很大的壓力，進而帶來整個系統穩定性的隱患，最近三個月檔案個數幾乎翻了個倍。對於小檔案問題，我們採用了社群 SPARK-24940 的方式處理，藉助 SQL hint 的方式合併小檔案。同時，我們有一個專門做 merge 的任務，定時非同步的對天級別的分割槽掃描並做小檔案合併。

還有一點是spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version=2, MapReduce-4815 詳細介紹了 fileoutputcommitter 的原理，實踐中設定了 version=2 的比預設 version=1 的減少了70%以上的 commit 時間。

三. SparkSQL 遷移之路

解決了大部分的可用性問題以後，我們逐步開始了 SparkSQL 的推廣，引導使用者選擇 SparkSQL 引擎，絕大部分的任務的效能能得到較大的提升。於是我們進一步開始將原來 Hive 執行的任務向 SparkSQL 轉移。

在 SparkSQL 遷移之初，我們選擇的路線是遵循二八法則，從優化耗費資源最多的頭部任務開始，把Top100的任務從 Hive 往 SparkSQL 遷移，逐步積累典型錯誤，包括 SparkSQL 和Hive的不一致行為，比較典型的問題由ORC格式檔案為空，Spark會拋空指標異常而失敗，ORC 格式和 metastore 型別不一致，SparkSQL 也會報錯失敗。經過一波人工推廣之後，頭部任務節省的資源相當客觀，在2017年底，切換到 SparkSQL 的任務數佔比5%，佔的資源20%，資源使用僅佔 Hive 執行的10%-30%。

在 case by case 處理了一段時間以後，我們發現這種方式不太能夠擴充套件了。首先和作業的 owner 協商修改需要溝通成本，而且小作業的改動收益不是那麼大，作業的 owner 做這樣的改動對他來說收益比較小，反而有一定概率的風險。所以到這個階段 SparkSQL 的遷移之路進展比較緩慢。

於是我們開始構思自動化遷移方式，構思了一種執行引擎之上的智慧執行引擎選擇服務 SQL Engine Proposer(proposer)，可以根據查詢的特徵以及當前叢集中的佇列狀態為 SQL 查詢選擇合適的執行引擎。資料平臺向某個執行引擎提交查詢之前，會先訪問智慧執行引擎選擇服務。在選定合適的執行引擎之後，資料平臺將任務提交到對應的引擎，包括 Hive，SparkSQL，以及較大記憶體配置的 SparkSQL。

並且在 SQL Engine Proposer，我們新增了一系列策略：

• 規則策略，這些規則可以是某一種 SQL pattern，proposer 使用 Antlr4 來處理執行引擎的語法，對於某些遷移有問題的問題，將這種 pattern 識別出來，新增到規則集合中，典型的規則有沒有發生 shuffle 的任務，或者只發生 broadcast join 的任務，這些任務有可能會產生很多小檔案，並且邏輯一般比較簡單，使用Hive執行資源消耗不會太多。
• 白名單策略，有些任務希望就是用Hive執行，就通過白名單過濾。當 Hive 和 SparkSQL 行為不一致的時候，也可以先加入這個集合中，保持執行和問題定位能夠同時進行。
• 優先順序策略，在灰度遷移的時候，是從低優先順序任務開始的，在 proposer 中我們配置了灰度的策略，從低優先順序任務切一定的流量開始遷移，逐步放開，在優先順序內達到全量，目前放開了除 P1P2 以外的3級任務。
• 過往執行記錄，proposer 選擇時會根據歷史執行成功情況以及執行時間，如果 SparkSQL 效率比 Hive 有顯著提升，並且在過去一直執行成功，那麼 proposer 會更傾向於選擇 SparkSQL。

截止目前，執行引擎選擇的作業數中 SparkSQL 佔比達到了73%，使用資源僅佔32%，遷移到 SparkSQL 執行的作業帶來了67%資源的節省。

未來展望

我們計劃 Hadoop 叢集資源進一步向 SparkSQL 方向轉移，達到80%，作業數達70%，把最高優先順序也開放到選擇引擎，引入 Intel 開源的 Adaptive Execution 功能，優化執行過程中的 shuffle 數目，執行過程中基於代價的 broadcast join 優化，替換 sort merge join，同時更徹底解決小檔案問題。

作者簡介：大資料平臺是有贊共享技術的核心團隊之一，該團隊主要由資料技術、資料產品、演算法挖掘、廣告平臺四個小團隊組成，目前共有34位優秀的工程師組成。