SQL on Hadoop在快手大數據平臺的實踐與優化 | 分享實錄

 

快手大數據架構工程師鍾靚

本文是根據快手大數據架構工程師鍾靚於 5月18-19日在A2M人工智能與機器學習創新峯會《SQL on Hadoop在快手大數據平臺的實踐與優化》演講中的分享內容整理而成。

內容簡介：本文主要從SQL on Hadoop介紹、快手SQL on Hadoop平臺概述、SQL on Hadoop在快手的使用經驗和改進分析、快手SQL on Hadoop的將來計劃四方面介紹了SQL on Hadoop架構。

01SQL on Hadoop介紹

SQL on Hadoop，顧名思義它是基於Hadoop生態的一個SQL引擎架構，咱們其實經常聽到Hive、SparkSQL、Presto、Impala架構，接下來，我會簡單的描述一下經常使用的架構狀況。

SQL on Hadoop-HIVE

HIVE，一個數據倉庫系統。它將數據結構映射到存儲的數據中，經過SQL對大規模的分佈式存儲數據進行讀、寫、管理。

 

根據定義的數據模式，以及輸出Storage，它會對輸入的SQL通過編譯、優化，生成對應引擎的任務，而後調度執行生成的任務。

HIVE當前支持的引擎類型有：MR、SPARK、TEZ。

 

基於HIVE自己的架構，還有一些額外的服務提供方式，好比HiveServer2與MetaStoreServer都是Thrift架構。

此外，HiveServer2提供遠程客戶端提交SQL任務的功能，MetaStoreServer則提供遠程客戶端操做元數據的功能。

 

SQL on Hadoop介紹-SPARK

Spark，一個快速、易用，以DAG做爲執行模式的大規模數據處理的統一分析引擎，主要模塊分爲SQL引擎、流式處理 、機器學習、圖處理。

 

SQL on Hadoop介紹-SPARKSQL

SPARKSQL基於SPARK的計算引擎，作到了統一數據訪問，集成Hive，支持標準JDBC鏈接。SPARKSQL經常使用於數據交互分析的場景。

 

SPARKSQL的主要執行邏輯，首先是將SQL解析爲語法樹，而後語義分析生成邏輯執行計劃，接着與元數據交互，進行邏輯執行計劃的優化，最後，將邏輯執行翻譯爲物理執行計劃，即RDD lineage，並執行任務。

 

SQL on Hadoop介紹-PRESTO

PRESTO，一個交互式分析查詢的開源分佈式SQL查詢引擎。

由於基於內存計算，PRESTO的計算性能大於有大量IO操做的MR和SPARK引擎。它有易於彈性擴展，支持可插拔鏈接的特色。

業內的使用案例不少，包括FaceBook、AirBnb、美團等都有大規模的使用。

 

SQL on Hadoop介紹-其它業內方案

 

咱們看到這麼多的SQL on Hadoop架構，它側面地說明了這種架構比較實用且成熟。利用SQL on Hadoop架構，咱們能夠實現支持海量數據處理的需求。 

02快手SQL on Hadoop平臺概述

快手SQL on Hadoop平臺概覽—平臺規模

 

查詢平臺每日SQL總量在70萬左右，DQL的總量在18萬左右。AdHoc集羣主要用於交互分析及機器查詢，DQL平均耗時爲300s；AdHoc在內部有Loacl任務及加速引擎應用，因此查詢要求耗時較低。

ETL集羣主要用於ETL處理以及報表的生成。DQL平均耗時爲1000s，DQL P50耗時爲100s，DQL P90耗時爲4000s，除上述兩大集羣外，其它小的集羣主要用於提供給單獨的業務來使用。

快手SQL on Hadoop平臺概覽—服務層次

 

服務層是對上層進行應用的。在上層有四個模塊，這其中包括同步服務、ETL平臺、AdHoc平臺以及用戶程序。在調度上層，一樣也有四方面的數據，例如服務端日誌，對它進行處理後，它會直接接入到HDFS裏，咱們後續會再對它進行清洗處理；服務打點的數據以及數據庫信息，則會經過同步服務入到對應的數據源裏，且咱們會將元數據信息存在後端元數據系統中。

網頁爬取的數據會存入hbase，後續也會進行清洗與處理。

快手SQL on Hadoop平臺概覽—平臺組件說明

 

HUE、NoteBook主要提供的是交互式查詢的系統。報表系統、BI系統主要是ETL處理以及常見的報表生成，額外的元數據系統是對外進行服務的。快手如今的引擎支持MR、Presto及Spark。

管理系統主要用於管理咱們當前的集羣。HiveServer2集羣路由系統，主要用於引擎的選擇。監控系統以及運維繫統，主要是對於HiveServer2引擎進行運維。

咱們在使用HiveServer2過程當中，遇到過不少問題。接下來，我會詳細的爲你們闡述快手是如何進行優化及實踐的。 

03SQL on Hadoop在快手的使用經驗和改進分析

HiveServer2多集羣架構

當前有多個HiveServer2集羣，分別是AdHoc與ETL兩大集羣，以及其餘小集羣。不一樣集羣有對應的鏈接ZK，客戶端可經過ZK鏈接HiveServer2集羣。

爲了保證核心任務的穩定性，將ETL集羣進行了分級，分爲核心集羣和通常集羣。在客戶端鏈接HS2的時候，咱們會對任務優先級斷定，高優先級的任務會被路由到核心集羣，低優先級的任務會被路由到通常集羣。

 

HiveServer2服務內部流程圖

 

BeaconServer服務

BeaconServer服務爲後端Hook Server服務，配合HS2中的Hook，在HS2服務以外實現了所需的功能。當前支持的模塊包括路由、審計、SQL重寫、任務控制、錯誤分析、優化建議等。

無狀態，BeaconServer服務支持水平擴展。基於請求量的大小，可彈性調整服務的規模。

配置動態加載，BeaconServer服務支持動態配置加載。各個模塊支持開關，服務可動態加載配置實現上下線。好比路由模塊，可根據後端加速引擎集羣資源狀況 ，進行路由比率調整甚至熔斷。

無縫升級，BeaconServer服務的後端模塊可單獨進行下線升級操做，不會影響Hook端HS2服務。

SQL on Hadoop平臺在使用中遇到的痛點

 

使用新引擎進行加速面臨的問題

Hive支持SPARK與TEZ引擎，但不適用於生產環境。

SQL on Hadoop的SQL引擎各有優缺點，用戶學習和使用的門檻較高。

不一樣SQL引擎之間的語法和功能支持上存在差別，須要大量的測試和兼容工做，徹底兼容的成本較高。

不一樣SQL引擎各自提供服務會給數倉的血緣管理、權限控制、運維管理、資源利用都帶來不便。

智能引擎的解決方案

在Hive中，自定義實現引擎。

自動路由功能，不須要設置引擎，自動選擇適合的加速引擎。

根絕規則匹配SQL，只將兼容的SQL推給加速引擎。

複用HiveServer2集羣架構。

智能引擎：主流引擎方案對比

 

智能引擎：HiveServer2自定義執行引擎的模塊設計

基於HiveServer2，有兩種實現方式。JDBC方式是經過JDBC接口，將SQL發送至後端加速引擎啓動的集羣上。PROXY方式是將SQL下推給本地的加速引擎啓動的Client。

JDBC方式啓動的後端集羣，均是基於YARN，能夠實現資源的分時複用。好比AdHoc集羣的資源在夜間會自動回收，做爲報表系統的資源進行復用。

 

智能引擎：SQL路由方案設計架構

路由方案基於HS2的Hook架構，在HS2端實現對應 Hook，用於引擎切換；後端BeaconServer服務中實現路由 服務，用於SQL的路由規則的匹配處理。不一樣集羣可配置不一樣的路由規則。

爲了保證後算路由服務的穩定性，團隊還設計了Rewrite Hook，用於重寫AdHoc集羣中的SQL，自動添加LIMIT上限，防止大數據量的SCAN。 

 

智能引擎：SQL路由規則一覽

 

智能引擎：方案優點

易於集成，當前主流的SQL引擎均可以方便的實現JDBC與PROXY方式。再經過配置，能簡單的集成新的查詢引擎，好比impala、drill等。

自動選擇引擎，減小了用戶的引擎使用成本，同時也讓遷移變得更簡單。而且在加速引擎過載 的狀況下，能夠動態調整比例，防止因過載 對加速性能的影響。

自動降級，保證了運行的可靠性。SQL路由支持failback模塊，能夠根據配置選擇是否再路由引擎執行失敗後，回滾到 MR運行。

模塊複用，對於新增的引擎，均可以複用HiveServer2定製的血緣採集、權限認證、併發鎖控制等方案，大大下降了使用成本。

資源複用，對於adhoc查詢佔用資源能夠分時動態調整，有效保證集羣資源的利用率。

智能引擎DQL應用效果

 

HiveServer2中存在的性能問題

 

FetchTask加速：預排序與邏輯優化

當查詢完成後，本地會輪詢結果文件，一直獲取到LIMIT大小，而後返回。這種狀況下，當有大量的小文件存在，而大文件在後端的時候，會致使Bad Case，不停與HDFS交互，獲取文件信息以及文件數據，大大拉長運行時間。

在Fetch以前，對結果文件的大小進行預排序，能夠有數百倍的性能提高。

示例：當前有200個文件。199個小文件一條記錄a，1個大文件混合記錄a與test共200條，大文件名index在小文件以後。

 

FetchTask加速：預排序與邏輯優化

Hive中有一個SimpleFetchOptimizer優化器，會直接生成FetchTask，減少資源申請時間與調度時間。但這個優化會出現瓶頸。若是數據量小，可是文件數多，須要返回的條數多， 存在能大量篩掉結果數據的Filter條件。這時候串行讀取輸入文件，致使查詢延遲大，反而沒起到加速效果。

在SimpleFetchOptimizer優化器中，新增文件數的判斷條件，最後將任務提交到集羣環境， 經過提升併發來實現加速。

示例：讀取當前500個文件的分區。優化後的文件數閾值爲100。

 

大表Desc Table優化

一個表有大量的子分區，它的DESC過程會與元數據交互，獲取全部的分區。但最後返回的結果，只有跟表相關的信息。

與元數據交互的時候，延遲了整個DESC的查詢，當元數據壓力大的時候甚至沒法返回結果。

針對於TABLE的DESC過程，直接去掉了跟元數據交互獲取分區的過程，加速時間跟子分區數量成正比。

示例：desc十萬分區的大表。

 

其它改進

複用split計算的數據，跳過reduce估算重複統計輸入過程。輸入數據量大的任務，調度速率提高50%。

parquetSerde init加速，跳過同一表的重複列剪枝優化，防止map task op init時間超時。

新增LazyOutputFormat，有record輸出再建立文件，避免空文件的產生，致使下游讀取大量空文件消耗時間。

statsTask支持多線程聚合統計信息，防止中間文件過多致使聚合過慢，增大運行時間。

AdHoc須要打開並行編譯，防止SQL串行編譯致使總體延遲時間增大的問題。

SQL on Hadoop平臺在使用中遇到的痛點

 

SQL on Hadoop在快手使用：常見可用性問題

 

HiveServer2服務啓動優化

HS2啓動時會對物化視圖功能進行初始化，輪詢整個元數據庫，致使HS2的啓動時間很是長，從下線狀態到從新上線間隔過大，可用性不好。

將物化視圖功能修改成延遲懶加載，單獨線程加載，不影響HS2的服務啓動。物化視圖支持加載中獲取已緩存信息，保證功能的可用性。

HS2啓動時間從5min+提高至<5s。

 

HiveServer2配置熱加載

HS2自己上下線成本較高，須要保證服務上的任務所有執行完成才能進行操做。配置的修改可做爲較高頻率的操做，且須要作到熱加載。

在HS2的ThriftServer層咱們增長了接口，與運維繫統打通後，配置下推更新的時候自動調用，可實現配置的熱加載生效。

 

HiveServer2的Scratchdir優化

HiveServer2的scratchdir主要用於運行過程當中的臨時文件存儲。當HS2中的會話建立時，便會建立scratchdir。 在HDFS壓力大的時候，大量的會話會阻塞在建立scratchdir過程，致使鏈接數堆積至上限，最終HS2服務沒法再連入新鏈接，影響服務可用性。

對此，咱們先分離了通常查詢與create temporay table查詢的scratch目錄，並支持create temporay table查詢的scratch的懶建立。 當create temporay table大量建立臨時文件，便會影響HDFS NameNode延遲時間的時候，通常查詢的scratchdir HDFS NameNode能夠正常響應。

此外，HS2還支持配置多scratch，不一樣的scratch能設置加載比率，從而實現HDFS的均衡負載。

 

Hive Stage併發調度異常修復

Hive調度其中存在兩個問題。

1、子Task非執行狀態爲完成狀況的時候，如有多輪父Task包含子Task，致使子Task被重複加入調度隊列。這種Case，須要將非執行狀態修改爲初始化狀態。

2、當判斷子Task是否可執行的過程當中，會由於狀態檢測異常，沒法正常加入須要調度的子Task，從而導致查詢丟失Stage。而這種Case，咱們的作法是在執行完成後，加入一輪Stage的執行結果狀態檢查，一旦發現有下游Stage沒有完成，直接拋出錯誤，實現查詢結果狀態的完備性檢查。

 

其它改進

HS2實現了接口終止查詢SQL。利用這個功能，能夠及時終止異常SQL。

metastore JDOQuery查詢優化，關鍵字異常跳過，防止元數據長時間卡頓或者部分異常查詢影響元數據。

增長開關控制，強制覆蓋外表目錄，解決insert overwrite外表，文件rename報錯的問題。

hive parquet下推增長關閉配置，避免parquet異常地下推OR條件，致使結果不正確。

executeForArray函數join超大字符串致使OOM，增長限制優化。

增長根據table的schema讀取分區數據的功能，避免未級聯修改分區schema致使讀取數據異常。

SQL on Hadoop平臺在使用中遇到的痛點

 

爲何要開發SQL專家系統

部分用戶並無開發經驗，沒法處理處理引擎返回的報錯。

有些錯誤的報錯信息不明確，用戶沒法正確瞭解錯誤緣由。

失敗的任務排查成本高，須要對Hadoop整套系統很是熟悉。

用戶的錯誤SQL、以及須要優化的SQL，大量具備共通性。人力維護成本高，但系統分析成本低。

SQL專家系統

SQL專家系統基於HS2的Hook架構，在BeaconServer後端實現了三個主要的模塊，分別是SQL規則控制模塊、SQL錯誤分析模塊，與SQL優化建議模塊。SQL專家系統的知識庫，包含關鍵字、緣由說明、處理方案等幾項主要信息，存於後端數據庫中，並一直積累。

經過SQL專家系統，後端能夠進行查詢SQL的異常控制，避免異常SQL的資源浪費或者影響集羣穩定。用戶在遇到問題時，能直接獲取問題的處理方案，減小了使用成本。

示例：空分區查詢控制。

 

做業診斷系統

SQL專家系統能解決一部分HS2的任務執行的錯誤診斷需求，可是好比做業健康度、任務執行異常等問題緣由的判斷，須要專門的系統來解決，爲此咱們設計了做業診斷系統。

做業診斷系統在YARN的層面，針對不一樣的執行引擎，對蒐集的Counter和配置進行分析。在執行層面，提出相關的優化建議。

做業診斷系統的數據也能經過API提供給SQL專家系統，補充用於分析的問題緣由。

 

做業診斷系統提供了查詢頁面來查詢運行的任務。如下是命中map輸入過多規則的任務查詢過程：

 

在做業界面，還能夠查看更多的做業診斷信息，以及做業的修改建議。

 

SQL on Hadoop平臺在使用中遇到的痛點

 

SQL on Hadoop在快手使用：常見運維性問題

 

審計分析 - 架構圖

審計功能也是BeaconServer服務的一個模塊。

經過HS2中配置的Hook，發送須要的SQL、IP、User等信息至後端，進行語法分析，即可提取出DataBase、Table、Columns與操做信息，將其分析後再存入Druid系統。用戶可經過可視化平臺查詢部分開放的數據。

 

審計分析 - 熱點信息查詢

熱點信息查詢即將熱點信息展現了一段時間之內，用戶的熱點操做，這其中包括訪問過哪些庫，哪些表，以及哪些類型的操做。

 

審計分析 - 血緣信息查詢

下圖可看出，血緣信息展現了一張表建立的上游依賴，通常用於統計表的影響範圍。

 

審計分析 - 歷史操做查詢

歷史操做能夠溯源到一段時間內，對於某張表的操做。能獲取到操做的用戶、客戶端、平臺、以及時間等信息。通常用於跟蹤表的增刪改狀況。

 

HiveServer2集羣AB切換方案

由於HiveServer2服務自己的上下線成本較高，若是要執行一次升級操做，每每耗時較長且影響可用性。HiveServer2集羣的AB切換方案，主要依靠A集羣在線，B集羣備用的方式，經過切換ZK上的在線集羣機器，來實現無縫的升級操做。

 

HiveServer2集羣動態上下線

HiveServer2集羣部署了Metrics監控，可以實時地跟蹤集羣服務的使用狀況。此外，咱們對HS2服務進行了改造，實現了HS2 ZK下線和請求Cancel的接口。

當外部Monitor監控感知到連續內存太高，會自動觸發HS2服務進程的FGC操做，若是內存依然連續太高，則經過ZK直接下線服務，並根據查詢提交的時間順序，依次中止查詢，直到內存恢復，保證服務中剩餘任務的正常運行。

 

HiveServer2集羣管理平臺

HiveServer2在多集羣狀態下，須要掌握每一個集羣、以及每一個HS2服務的狀態。經過管理平臺，能夠查看版本狀況、啓動時間、資源使用狀況以及上下線狀態。

後續跟運維平臺打通，能夠更方便地進行一鍵式灰度以及升級。

 

快手查詢平臺的改進總結

 

04快手SQL on Hadoop的將來計劃

專家系統的升級，實現自動化參數調優和SQL優化

AdHoc查詢的緩存加速

新引擎的調研與應用

 

以上內容來自鍾靚老師的分享。是否還想看更多關於快手老師的演講？6月21-23日來參加GIAC全球互聯網架構大會深圳站吧~咱們邀請到了快手應用研發部測試負責人羋峮，將爲咱們講述《快手移動端線上質量監控》的話題。

 

此外，本屆大會，組委會還邀請到了105位來自Google、微軟、Oracle、eBay、百度、阿里、騰訊、商湯、圖森、字節跳動、新浪、美團點評等一線互聯網大廠嘉賓出席，圍繞AI、大中臺、Cloud-Native、IoT、混沌工程、Fintech、數據及商業智能、工程文化及管理、經典架構等專題分享他們的實踐經驗、遇到的問題及解決方案。如今填寫報名信息，還可免費得到GIAC峯會全部的PPT！快來識別圖中二維碼報名吧！