【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有兩個：

將Hive許可權控制機制移植到SparkSQL之上
實現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許可權控制模式主要有四種：

在Hive 0.13版本之前，是Default Authorization，簡稱v1，當然官方文章上曾提及該版本存在一些問題
在Hive 0.13或者之後的版本中，提出的是 SQL Standards Based Hive Authorizatio，簡稱v2
第三種是Storage Based Authorization in the Metastore Server
最後一個是 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之後，對記憶體的使用量也急劇上升，在某些時間點出現了應用記憶體分配滿而無法分配更多作業的情況，我們的解決思路有兩個：

根據作業歷史的記憶體使用情況，在排程系統端自動設定合適的記憶體

未來我們希望做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釋出之後。

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

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

相關文章