當前位置:
首頁 > 知識 > 張翼:Spark SQL在攜程的實踐經驗分享!

張翼:Spark SQL在攜程的實踐經驗分享!

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

講師簡介:

張翼:Spark SQL在攜程的實踐經驗分享!

打開今日頭條,查看更多圖片

張翼,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在攜程的實踐經驗分享!

本文重點介紹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,積累了開發和運維經驗。

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

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

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


張翼:Spark SQL在攜程的實踐經驗分享!

截止到今年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到當前默認配置的功能,這點對於作業穩定性保障至關重要。

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


張翼:Spark SQL在攜程的實踐經驗分享!

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

張翼:Spark SQL在攜程的實踐經驗分享!

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行左右

張翼:Spark SQL在攜程的實踐經驗分享!

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 SQL在攜程的實踐經驗分享!

小文件問題

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

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

下面是相關的代碼:

張翼:Spark SQL在攜程的實踐經驗分享!

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

資源利用效率優化

張翼:Spark SQL在攜程的實踐經驗分享!

上圖橘色的圖片是每個作業的平均時間,在紅色邊框的時間內沒有明顯變化,下方紫色的圖片是整個集群的平均延遲,可以看到有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發布之後。

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

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

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 IT168企業級 的精彩文章:

朋友還是敵人:五個問題概述了人工智慧的未來
華為CloudNative分散式資料庫技術解析

TAG:IT168企業級 |