張翼：Spark SQL在攜程的實踐經驗分享！

【IT168 專稿】本文根據張翼老師在2018年5月13日【第九屆中國資料庫技術大會】現場演講內容整理而成。

講師簡介：

張翼，10年互聯網老兵;2015年3月加入攜程，攜程的大數據平台技術總監，帶領團隊構建穩定，高效的數據平台和系統，保證了攜程數據的高速發展;加入攜程之前，在大眾點評負責數據基礎架構，從0開始組建團隊，搭建起點評的數據分析平台;平時關注與大數據及AI系統的發展，致力於將開源技術和公司場景相結合，創造業務價值。

摘要：

之前，大多數公司大數據的數倉都是構建在Hive上的，數據開發的ETL任務以及用戶對於數據的即時查詢主要使用的工具也是Hive，隨著Spark以及其社區的不斷發展，Spark及Spark SQL本身技術的不斷成熟，Spark在技術架構和性能上都展示出Hive無法比擬的優勢，如何使用Spark構建大數據的數倉?如何將現有的數倉平台從Hive轉到Spark上?這些問題都是每家公司需要考慮的問題;攜程原先的數倉也是構建在Hive之上的，每天運行超過20000個Hive的定時任務，從2017年9月份開始，我們正式啟動了SparkSQL落地的一系列項目，到目前為止，大部分的ETL作業和用戶的臨時查詢已經使用了SparkSQL;在這個演講中，我將分享下我們在這段時間中的做法，實踐和思考，我們遇到問題，以及我們的解決方案。

分享大綱：

1、平台簡介

2、總體方案和效果

3、經驗分享

4、未來展望

正文：

1、平台簡介

首先介紹一下攜程大數據平台總體架構：

如下圖所示，底層是資源部署和運維監控，主要包括兩部分：自動運維繫統和監控系統;自動運維繫統大大降低了我們運維的effort，也降低了運維操作出錯的概率，是我們能在很少的運維人力投入的情況下維護大規模的集群;隨著系統變大，各個相關係統增多，一個有效的監控能幫助我們及時發現問題，並嘗試進行自動的處理，這個也能夠大大提升運維的效率。

第二層是開源的大數據框架，主要分成兩部分：分散式存儲計算和實時框架，實時框架目前主要支持JStorm，Spark Streaming和Flink，其中Flink是今年新支持的;而分散式存儲和計算框架這邊，底層是Hadoop，ETL主要使用Hive和Spark，交互查詢則會使用Spark，Presto和Kylin。

第三層是工具系統層，直接提供給BI同學或者業務用戶，主要分為以下幾部分：數據開發平台，包括日常使用的調度，數據傳輸，主數據以及數據質量系統;數據查詢平台，主要包括報表系統Art nova和Adhoc查詢系統;機器學習演算法平台，包括一個基於Spark的MLlib圖形化拖拽平台，以及基於Docker的GPU雲平台，主要提供給數據演算法科學家做模型訓練使用;最後一塊是實時數據平台Muise，通過一個系統提供對所有類型實時作業的發布，管理，監控和運維的功能。

本文重點介紹Spark SQL在攜程數據開發和數據查詢系統的落地實踐過程，所以在平台簡介部分我先簡單介紹一下這兩大塊的系統：

數據開發系統運行在分散式存儲計算框架之上，分散式存儲和計算框架最下面一層是Hadoop，其上是Hive和Spark;開發平台Zeus主要由調度系統、主數據系統、傳輸系統以及數據質量系統四部分組成。目前，我們的集群規模在1300台左右，調度系統的Active任務數超過75000個，每天運行調度任務的實例超過13萬個，換算成底層MapReduce任務數大約在30萬左右，系統中的傳輸任務和ETL任務大約佔比50%，在2017年Q4季度，我們內部絕大多數在使用Hive。

數據查詢系統同樣運行在分散式存儲和計算框架之上，整個平台包含兩部分——報表系統ArtNova和Adhoc查詢;Adhoc系統每天的查詢數載每天1萬+，2017年Q4季度主要支持Hive和Presto;新建報表系統ART Nova在去年12月正式上線，設計初衷就考慮摒棄Hive，改用Spark SQL或者Presto做查詢。

那麼為什麼我們要將數據平台的計算引擎從Hive轉到SparkSQL來呢?

在對於Hive優缺點的分析中我們能夠發現這個原因;Hive的優點是歷史悠久，且穩定性有保證，已經被用戶廣泛接受。而Hive的缺點也很明顯，第一，其計算效率相比新一代計算引擎，比如Spark、Presto等要慢得多，因為其HQL會轉化為多個MR Job，MR Job之間需要進行數據落地，效率自然比不上純內存RDD的Spark效率，把Hive轉到新一代的計算引擎能夠大幅度地提昇平台的計算效率;第二，Hive的源代碼結構比較混亂，了解需要花費一定時間，在其上進行優化的代價也比較大。

那麼怎麼來做呢?我們曾經考慮過2種候選方案：第一，更換Hive的執行引擎為Tez或者Spark，第二，更換一個能同時兼容Hive Table(讀、寫、許可權等)並可保持HQL最大兼容性的計算引擎。很長一段時間，我們傾向於第一種候選方案，也就是Hive on Spark的方案

而SparkSQL 和Presto則被用來作為即時查詢計算引擎 。但是，下面的原因使我們最終下決心擁抱SparkSQL，並把其作為整個查詢和開發平台的主要引擎：

• 2017下半年，和攜程規模相當，甚至比攜程規模小的互聯網公司完成或已經開始SparkSQL的遷移，並取得了一些成果
• SparkSQL的成熟，特別是2.2之後它的兼容性，穩定性，性能有很大的提升
• Hive on Spark除了Uber外很少有其他的用例
• Hive社區的衰落和Spark社區的繁榮
• 時機，2017下半年，我們已經基本解決了Hadoop集群增長帶來的穩定性問題，有精力做較大的項目

2、總體方案和效果

遷移SparkSQL的挑戰主要體現在技術和團隊兩層面：

技術層面，最大的挑戰是對於已經在運行的大量作業，我們需要考慮如何將遷移過程的影響降到最小，需要做到以下3點：

• 第一點也是最重要的需要有灰度升級過程
• 第二點是SQL語法盡量兼容Hive原有語法
• 第三點是許可權控制需要兼容Hive原有方式

第二大挑戰是原有與Hive配套的大量周邊設施需要改造，比如日誌、Metrics收集、監控和告警系統以及Dr Elephant等作業分析系統。

團隊層面，我們對SparkSQL源碼以及Scala並不熟悉，缺乏較大改動經驗。

基於上述原因，我們將整個遷移過程分為四個階段：

第一階段，集中力量解決Blocking技術問題，主要的Blocking Issue有兩個：

1. 將Hive許可權控制機制移植到SparkSQL之上
2. 實現Thrift Server的impersonation

通過這個過程熟悉Spark和Scala，積累技術實力。

第二階段，在Adhoc查詢平台開始初步嘗試，由於是即席查詢，如果失敗，用戶可人工覆蓋到Hive，影響較小;後面也新的報表系統ArtNova中嘗試使用;在這個過程中，我們修復了大量bug，積累了開發和運維經驗。

第三階段，改造開發平台，讓整個平台支持灰度推送。

第四階段，開發平台作業全麵灰度升級，優化性能並處理遺留的長尾問題。

根據上述四個階段，我們制定了遷移時間表：

截止到今年5月份，Adhoc查詢工具中使用Spark SQL查詢佔比57%，Art Nova大約有52%使用了Spark SQL。 開發平台的非數據傳輸作業大約52%使用了Spark SQL，差不多是兩萬多個，也可理解為原有Hive腳本已全部轉成Spark SQL方式。轉化完成，計算效率較之前提升了6-7倍。

3、經驗分享

3.1 開發平台的灰度變更支持

首先分享我們在灰度變更部分的經驗，這也是整個過程最重要的部分。我們最初在開發平台構建灰度變更機制是在Hive從0.13升級到1.1時，最開始僅支持環境變數等簡單規則，在本次SparkSQL升級的過程中添加了執行engine / shell cmd變更規則等更多複雜的規則;系統支持變更組，也支持包括多種類型的變更策略：如全量推送，分作業優先順序按照百分比推送，指定單個作業進行推送;最後一點是在作業失敗後，fallback到當前默認配置的功能，這點對於作業穩定性保障至關重要。

一個典型的用戶操作流程如下圖所示：

我們在SparkSQL灰度升級時的實際配置如下：

Spark灰度升級引入了一種新的灰度升級規則 - engine，如上圖所示，我們先在規則配置里設置一條使用SQL的引擎，即SparkSQL;我們配置了3條策略，對低優先順序任務，當前的推送比例是100%，對高優先順序任務，我們的推送比例是70%，並外我們還設置了一條Black List的策略，將遇到問題的作業暫時排除在推送之外

3.2 問題及其解決

在整個升級的過程中，我們遇到了很多問題，需有問題社區已經有了相關的解決方案(Apply社區Jira的修復超過30)，還有很多問題需要我們自己解決，這邊我分享下我們遇到的幾個主要的問題：

1. 許可權相關

1.1 Hive許可權落地

1.2 Thrift Server Impersonation

2. 小文件合併

3. 資源利用率優化

Hive許可權落地

Hive許可權控制模式主要有四種：

1. 在Hive 0.13版本之前，是Default Authorization，簡稱v1，當然官方文章上曾提及該版本存在一些問題
2. 在Hive 0.13或者之後的版本中，提出的是 SQL Standards Based Hive Authorizatio，簡稱v2
3. 第三種是Storage Based Authorization in the Metastore Server
4. 最後一個是 Authorization using Apache Ranger & Sentry方式

由於攜程使用Hive的歷史比較長，所以我們主要使用的許可權控制方式是第一種，在這個基礎上對問題進行修復，比如grant無許可權控制等問題等;考慮到未來的實際需求，Spark SQL也需要支持前兩種許可權控制方式。

我們對Spark code進行了修改以支持這兩種許可權控制的方式;Spark用到了很多Hive代碼，最終通過ExternalCatalog調用HiveExternalCatalog執行 HiveClientImpl里的方法，在HiveClientImpl里，我們增加了許可權檢查方法，從而做到在Spark語句執行前檢查在Hive中設置的許可權;對於許可權控制模式v2的話，實現非常簡單，基本加一行code就可以;而許可權控制模式v1相對來說複雜一點，需要把Hive的許可權和相關邏輯全部移植過來。做法與v2相同，代碼量大約在400行左右

Thrift Server Impersonation

Adhoc查詢平台使用Thrift Server的方式執行SparkSQL，雖然其上的絕大多數操作是查詢，但是也有少量的寫操作，Thrift Server是以Hive賬號啟動的，如果沒有用戶賬號的Impersonation，寫的文件的Owner是Hive賬號，但是我們希望的Owner是用戶在Adhoc平台上選擇的賬號。

Hortonworks有自己的解決方案，Thrift Server只作為Proxy Server，在用戶作業提交時再以其身份去啟動AM和executor，以用戶+connection id維度重用資源;這樣做的問題是賬號較多的情況下，executor的啟停帶來額外的開銷。由於攜程內部BU較多，每個BU使用的賬號也非常多，這種方式可能對我們不是太適用。

我們採取的做法是在Thrift Server啟動時預先啟動AM和executor，將各賬號keytab分配到各個nodemanager之上，然後在executor端真正執行Task時，使用超級賬戶把用戶impersonate 成實際用戶。

下圖為詳細技術圖:

小文件問題

如果不做任何修改，Spark在寫數據時會產生很多小文件;由於我們集群本身的存量文件就較多，Spark大量產生小文件的話，就會對NN產生很大的壓力，進而帶來整個系統穩定性的隱患，我們在灰度推送到30%(6000 Job / day)時發現不到3周的時間內就使NN的文件 + Block數飆升了近1億，這個還是在每天有程序合併小文件的情況下;另外文件變小帶來了壓縮率的降低，數據會膨脹3-4倍。

修復的方法其實比較簡單，在Insert Into Table或是Create Table as的情況下，如果本身沒有RepartitionByExpression的話，就增加一個RepartitionByExpression的stage

下面是相關的代碼：

在這之後，小文件問題就得到了控制，運行到目前為止還是比較正常的。

資源利用效率優化

上圖橘色的圖片是每個作業的平均時間，在紅色邊框的時間內沒有明顯變化，下方紫色的圖片是整個集群的平均延遲，可以看到有30%的下降。雖然這個改動非常簡單，但是對整體集群的資源利用效率有很大提升。

4、未來展望

近期工作

1. 繼續推進SparkSQL在數據開發平台的使用比例，我們的目標是在5月底達到90%

目前純粹的Hive的分析任務已經基本轉換完成，剩餘的主要任務是轉換Legacy的Shell腳本中使用到Hive的地方，我們使用的方法是用函數的方式將hive直接替換為sparksql的command

2. 優化作業內存的使用，作業轉到SparkSQL之後，對內存的使用量也急劇上升，在某些時間點出現了應用內存分配滿而無法分配更多作業的情況，我們的解決思路有兩個：

• 根據作業歷史的內存使用情況，在調度系統端自動設置合適的內存
• https://issues.apache.org/jira/browse/YARN-1011

未來我們希望做2件事:

1. 能夠進一步優化長尾的SparkSQL作業的性能;從Hive轉換為SparkSQL之後，絕大多數作業的性能得到了較大的提高，但是還有有少量的作業運行效率反而下降了，也有一些作業出現運行失敗的情況(目前都fallback到Hive)，我們簡單地統計了一下

• 有2.5%左右的作業會出現失敗(400~)
• 有6%左右的作業運行效率接近或比Hive更差(1000~)
• 有2.5%左右的作業運行時間比Hive慢5分鐘以上

後續我們會針對上面這些問題作業的共性問題，進行研究和解決

2. 升級到Spark 2.3

積極跟進社區的步伐，調研，測試，適配Spark 2.3;當然正式的生產使用會放在Spark 2.3.1發布之後。

以上是我所有的分享，希望對大家有所幫助，謝謝!

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！