大數據問題排查系列- 同樣的HIVE SQL,在CDH與TDH平臺執行效率差异的根本原因

IT明哥 2021-08-15 13:10:26 阅读数:178

本文一共[544]字,预计阅读时长:1分钟~
排查 系列 hive sql cdh

大數據線上問題排查系列 - 同樣的HQL,在CDH與TDH平臺執行效率差异巨大的根本原因與業務側應對方案

前言

大家好,我是明哥!

公眾號已經運維有一段時間了,也寫了不少博文,其中很多是從自己解决真實線上問題的實戰經曆出發,寫的經驗總結和IT感悟。但由於前期摸索過程中,文風不統一且排版不太好,各篇博文之間也欠缺呼應,不太方便大家分類閱讀學習,所以後續博文會盡量歸類到對應的系列下。

本片博文是“大數據線上問題排查系列”大類別之一,以下是正文。

問題概述

某日測試團隊同學跟我反饋了一個問題,即某大數據應用系統中HIVE離線計算作業脚本在CDH大數據平臺跟TDH大數據平臺的執行效率相差很大,經過驗證該脚本在TDH大概需要 13 seconds,在CDH大概需要8 min 25 seconds,相差確實很大。

由於該大數據應用系統是是產品化的發包方案,在不同客戶不同平臺性能差异如此巨大,是不利於統一部署和運維的。所以需要對對該性能差异的背後原因,業務系統安裝配置需注意的地方,以及業務代碼側潜在的應對方案,進行詳盡的分析。

問題分析

問題分析的思路,仍然是查看相關大數據組件的WEB UI (在這裏是 HIVE SERVER2 UI,和 YARN WEB UI), 業務系統及各中間件的日志 (涉及到業務系統日志,業務系統使用的到二方包三方包的日志,調度系統日志等),以及相關大數據組件的日志 (在這裏是 HIVE SERVER2, HIVE METASTORE, YARN RESOURCE MANAGER, YARN TASK MANAGER等日志)。

順著上述思路,該問題的原因很輕松就找到了: 通過 HIVE SERVER2 WEBUI 和 YARN WEB UI,發現該 HIVE 離線計算作業脚本在底層對應了多個SQL語句,這些SQL語句在CDH平臺上是以 MR 任務的形式運行在 YARN 上的 (而不是預期的TEZ或SPARK)!

熟悉 MR/TEZ/SPARK 的小夥伴們,一般都有個籠統的印象,即 SPARK 比 MR 的速度一般是要快很多的,特別是在 SQL 底層對應多個子任務的時候。該問題的根本原因,其實就跟這個有關。

問題根本原因

  • 同樣的 HIVE SQL 在 CDH 與 TDH平臺性能差异的根本原因,是作業執行機制的不同,在SQL底層對應大量小任務時該性能差异尤其明顯,其實這也是星環對inceptor最引以為豪的地方;
  • 在TDH中,sql 作業是以 hive on spark的模式運行的:sql經 hiveserver2解析編譯優化一般會生成 spark任務,這些spark任務是在spark集群中執行的,該 spark 集群是在inceptor 集群啟動時就啟動好了的,而不是在有 spark 任務需要執行時再動態啟動,且該spark集群 不受 yarn 資源管理框架的管控,默認的資源配置也很高(JVM堆空間是32G);
  • 而在CDH中,sql作業是以 hive on mr/tez/spark的模式運行的:sql 經hiveserver2解析編譯優化生成 mr/tez/spark任務,這些 mr/tez/spark 任務在執行時,首先需要向 yarn申請資源,然後在申請獲得的多個 yarn container中啟動多個 Jvm虛擬機,此後才可以在這些container中執行任務。由於向yarn申請資源需要花費時間,且jvm虛擬機的啟動和銷毀也需要花費時間,再加上作業默認配置的spark 資源需求不高,所以作業執行速度較TDH會有差异,在SQL底層對應多個小任務時,該差异尤其明顯;
  • 所以,HIVE SQL 在CDH中以MR引擎運行,跟TDH平臺的速度差异特別大;當經過配置在CDH中以SPARK引擎運行時,跟TDH平臺的速度差异會比MR引擎小,但仍會跟TDH平臺有差异;
  • 在我們的上述測試環境中,上述SQL脚本對應了29個底層任務,在CDH中是以 hive on mr的方式運行的,最小/最大/平均執行時間分別是8.8/48.2/18.5秒,在tdh中最小/最大/平局執行時間分別是177ms/2.98s/512ms,這其實是典型的大量小任務,所以性能差异比較明顯。
  • 從本質上來講,TDH 是采用了預計算和空間換時間的思想,提前啟動了 SPARK 集群,且改SPARK集群是以 STANDALONE 模式運行的跟YARN不會存在資源競爭,再加上該 SPARK 集群的 driver/excutor的memory和cpu等資源參數默認都比較高,所以作業執行效率會比CDH平臺高。

問題解决方案

  • 業務系統安裝配置注意點:

    • 我們無法改變CDH的執行機制,但由於 hive on spark有session的概念,且在同一個session內的所有sql底層的所有spark 任務都會複用同一個spark集群,所以配置使用hive on spark 而不是 hive on mr/tez,能盡量减少向yarn頻繁申請資源的時間開銷,以及虛擬機頻繁啟動和銷毀的時間開銷;(set hive.execution.engine=spark)
    • 另外,配置業務系統使用用戶指定的/合適的YARN資源隊列而不是默認的資源隊列,也是需要注意的地方;(set mapred.job.queue.name=xxx;或set mapreduce.job.queuename=xx)
    • Spark任務的資源配置,需要針對不同客戶的數據量和yarn隊列資源數,以及該任務的複雜性,合理進行配置;(由於調度系統是以SQL脚本為單比特進行調度的且很多調度系統都支持設置資源相關參數,建議在SQL脚本級別配置spark任務的具體資源參數,這些參數對sql脚本內部的多個sql語句都是有效的;如果多個SQL語句對資源有不同需求,建議劃分到不同的SQL脚本中)
  • 業務代碼側潜在的應對方案:

  • 如果采用以上方案後,仍達不到客戶的性能要求,業務代碼測潜在的應對方案是,進一步拆分SQL脚本增大業務系統總體的並行度(一個SQL脚本中的多個SQL,是串行提交的,結合業務邏輯進一步拆分SQL語句到多個脚本,並並行提交這些SQL脚本,能提高業務系統整體的並行度,更大化地利用YARN集群資源 – 前提是yarn隊列資源要够)

問題總結

同樣的HQL,在CDH與TDH平臺執行效率差异巨大的根本原因,是因為 TDH 采用了預計算和空間換時間的思想,提前啟動了 SPARK 集群,且改SPARK集群是以 STANDALONE 模式運行的跟YARN不會存在資源競爭,再加上該 SPARK 集群的 driver/excutor的memory和cpu等資源參數默認都比較高,所以作業執行效率會比CDH平臺高。

話說回來,凡事有利就有弊,TDH 將所有作業都運行在同一個 spark 集群中,作業相互之間就有資源的競爭相互之間會有影響;而在CDH中,不同客戶端提交的SQL屬於不同的 SESSION,每個SESSION都會有自己的SPARK ON YARN集群,相互之間資源隔離處理的更好影響也更小。

新的問題

拋出個問題,HIVE ON SPARK 模式下,各個SESSION背後的 SAARK 集群何時啟動?何時關閉?會不會有處理不慎資源泄露,造成SPARK集群不能及時關閉浪費YARN資源,甚至極端情况下因YARN 集群資源被浪費沒有新的資源新的作業無法提交的風險?

筆者確實在線上遇到了這種情况,後續會通過另一篇博文講述下相關知識。小夥伴們可先行思考下。STAY TUNED.

版权声明:本文为[IT明哥]所创,转载请带上原文链接,感谢。 https://gsmany.com/2021/08/20210815131015732K.html