快手大數(shù)據(jù)架構(gòu)工程師鐘靚近日在A2M人工智能與機(jī)器學(xué)習(xí)創(chuàng)新峰會(huì)分享了題為《SQL on Hadoop在快手大數(shù)據(jù)平臺(tái)的實(shí)踐與優(yōu)化》的演講，主要從SQL on Hadoop介紹、快手SQL on Hadoop平臺(tái)概述、SQL on Hadoop在快手的使用經(jīng)驗(yàn)和改進(jìn)分析、快手SQL on Hadoop的未來(lái)計(jì)劃四方面介紹了SQL on Hadoop架構(gòu)。

[[266868]]

01SQL on Hadoop介紹

SQL on Hadoop，顧名思義它是基于Hadoop生態(tài)的一個(gè)SQL引擎架構(gòu)，我們其實(shí)常常聽(tīng)到Hive、SparkSQL、Presto、Impala架構(gòu)，接下來(lái)，我會(huì)簡(jiǎn)單的描述一下常用的架構(gòu)情況。

SQL on Hadoop-HIVE

HIVE，一個(gè)數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)。它將數(shù)據(jù)結(jié)構(gòu)映射到存儲(chǔ)的數(shù)據(jù)中，通過(guò)SQL對(duì)大規(guī)模的分布式存儲(chǔ)數(shù)據(jù)進(jìn)行讀、寫(xiě)、管理。

根據(jù)定義的數(shù)據(jù)模式，以及輸出Storage，它會(huì)對(duì)輸入的SQL經(jīng)過(guò)編譯、優(yōu)化，生成對(duì)應(yīng)引擎的任務(wù)，然后調(diào)度執(zhí)行生成的任務(wù)。

HIVE當(dāng)前支持的引擎類(lèi)型有：MR、SPARK、TEZ。

基于HIVE本身的架構(gòu)，還有一些額外的服務(wù)提供方式，比如HiveServer2與MetaStoreServer都是Thrift架構(gòu)。

此外，HiveServer2提供遠(yuǎn)程客戶(hù)端提交SQL任務(wù)的功能，MetaStoreServer則提供遠(yuǎn)程客戶(hù)端操作元數(shù)據(jù)的功能。

SQL on Hadoop介紹-SPARK

Spark，一個(gè)快速、易用，以DAG作為執(zhí)行模式的大規(guī)模數(shù)據(jù)處理的統(tǒng)一分析引擎，主要模塊分為SQL引擎、流式處理 、機(jī)器學(xué)習(xí)、圖處理。

SQL on Hadoop介紹-SPARKSQL

SPARKSQL基于SPARK的計(jì)算引擎，做到了統(tǒng)一數(shù)據(jù)訪問(wèn)，集成Hive，支持標(biāo)準(zhǔn)JDBC連接。SPARKSQL常用于數(shù)據(jù)交互分析的場(chǎng)景。

SPARKSQL的主要執(zhí)行邏輯，首先是將SQL解析為語(yǔ)法樹(shù)，然后語(yǔ)義分析生成邏輯執(zhí)行計(jì)劃，接著與元數(shù)據(jù)交互，進(jìn)行邏輯執(zhí)行計(jì)劃的優(yōu)化，最后，將邏輯執(zhí)行翻譯為物理執(zhí)行計(jì)劃，即RDD lineage，并執(zhí)行任務(wù)。

SQL on Hadoop介紹-PRESTO

PRESTO，一個(gè)交互式分析查詢(xún)的開(kāi)源分布式SQL查詢(xún)引擎。

因?yàn)榛趦?nèi)存計(jì)算，PRESTO的計(jì)算性能大于有大量IO操作的MR和SPARK引擎。它有易于彈性擴(kuò)展，支持可插拔連接的特點(diǎn)。

業(yè)內(nèi)的使用案例很多，包括FaceBook、AirBnb、美團(tuán)等都有大規(guī)模的使用。

SQL on Hadoop介紹-其它業(yè)內(nèi)方案

我們看到這么多的SQL on Hadoop架構(gòu)，它側(cè)面地說(shuō)明了這種架構(gòu)比較實(shí)用且成熟。利用SQL on Hadoop架構(gòu)，我們可以實(shí)現(xiàn)支持海量數(shù)據(jù)處理的需求。

02快手SQL on Hadoop平臺(tái)概述

快手SQL on Hadoop平臺(tái)概覽—平臺(tái)規(guī)模

查詢(xún)平臺(tái)每日SQL總量在70萬(wàn)左右，DQL的總量在18萬(wàn)左右。AdHoc集群主要用于交互分析及機(jī)器查詢(xún)，DQL平均耗時(shí)為300s;AdHoc在內(nèi)部有Loacl任務(wù)及加速引擎應(yīng)用，所以查詢(xún)要求耗時(shí)較低。

ETL集群主要用于ETL處理以及報(bào)表的生成。DQL平均耗時(shí)為1000s，DQL P50耗時(shí)為100s，DQL P90耗時(shí)為4000s，除上述兩大集群外，其它小的集群主要用于提供給單獨(dú)的業(yè)務(wù)來(lái)使用。

快手SQL on Hadoop平臺(tái)概覽—服務(wù)層次

服務(wù)層是對(duì)上層進(jìn)行應(yīng)用的。在上層有四個(gè)模塊，這其中包括同步服務(wù)、ETL平臺(tái)、AdHoc平臺(tái)以及用戶(hù)程序。在調(diào)度上層，同樣也有四方面的數(shù)據(jù)，例如服務(wù)端日志，對(duì)它進(jìn)行處理后，它會(huì)直接接入到HDFS里，我們后續(xù)會(huì)再對(duì)它進(jìn)行清洗處理;服務(wù)打點(diǎn)的數(shù)據(jù)以及數(shù)據(jù)庫(kù)信息，則會(huì)通過(guò)同步服務(wù)入到對(duì)應(yīng)的數(shù)據(jù)源里，且我們會(huì)將元數(shù)據(jù)信息存在后端元數(shù)據(jù)系統(tǒng)中。

網(wǎng)頁(yè)爬取的數(shù)據(jù)會(huì)存入hbase，后續(xù)也會(huì)進(jìn)行清洗與處理。

快手SQL on Hadoop平臺(tái)概覽—平臺(tái)組件說(shuō)明

HUE、NoteBook主要提供的是交互式查詢(xún)的系統(tǒng)。報(bào)表系統(tǒng)、BI系統(tǒng)主要是ETL處理以及常見(jiàn)的報(bào)表生成，額外的元數(shù)據(jù)系統(tǒng)是對(duì)外進(jìn)行服務(wù)的。快手現(xiàn)在的引擎支持MR、Presto及Spark。

管理系統(tǒng)主要用于管理我們當(dāng)前的集群。HiveServer2集群路由系統(tǒng)，主要用于引擎的選擇。監(jiān)控系統(tǒng)以及運(yùn)維系統(tǒng)，主要是對(duì)于HiveServer2引擎進(jìn)行運(yùn)維。

我們?cè)谑褂肏iveServer2過(guò)程中，遇到過(guò)很多問(wèn)題。接下來(lái)，我會(huì)詳細(xì)的為大家闡述快手是如何進(jìn)行優(yōu)化及實(shí)踐的。

03SQL on Hadoop在快手的使用經(jīng)驗(yàn)和改進(jìn)分析

HiveServer2多集群架構(gòu)

當(dāng)前有多個(gè)HiveServer2集群，分別是AdHoc與ETL兩大集群，以及其他小集群。不同集群有對(duì)應(yīng)的連接ZK，客戶(hù)端可通過(guò)ZK連接HiveServer2集群。

為了保證核心任務(wù)的穩(wěn)定性，將ETL集群進(jìn)行了分級(jí)，分為核心集群和一般集群。在客戶(hù)端連接HS2的時(shí)候，我們會(huì)對(duì)任務(wù)優(yōu)先級(jí)判定，高優(yōu)先級(jí)的任務(wù)會(huì)被路由到核心集群，低優(yōu)先級(jí)的任務(wù)會(huì)被路由到一般集群。

HiveServer2服務(wù)內(nèi)部流程圖

BeaconServer服務(wù)

BeaconServer服務(wù)為后端Hook Server服務(wù)，配合HS2中的Hook，在HS2服務(wù)之外實(shí)現(xiàn)了所需的功能。當(dāng)前支持的模塊包括路由、審計(jì)、SQL重寫(xiě)、任務(wù)控制、錯(cuò)誤分析、優(yōu)化建議等。

• 無(wú)狀態(tài)，BeaconServer服務(wù)支持水平擴(kuò)展?；谡?qǐng)求量的大小，可彈性調(diào)整服務(wù)的規(guī)模。



• 配置動(dòng)態(tài)加載，BeaconServer服務(wù)支持動(dòng)態(tài)配置加載。各個(gè)模塊支持開(kāi)關(guān)，服務(wù)可動(dòng)態(tài)加載配置實(shí)現(xiàn)上下線。比如路由模塊，可根據(jù)后端加速引擎集群資源情況 ，進(jìn)行路由比率調(diào)整甚至熔斷。



• 無(wú)縫升級(jí)，BeaconServer服務(wù)的后端模塊可單獨(dú)進(jìn)行下線升級(jí)操作，不會(huì)影響Hook端HS2服務(wù)。




SQL on Hadoop平臺(tái)在使用中遇到的痛點(diǎn)

使用新引擎進(jìn)行加速面臨的問(wèn)題

• Hive支持SPARK與TEZ引擎，但不適用于生產(chǎn)環(huán)境。
• SQL on Hadoop的SQL引擎各有優(yōu)缺點(diǎn)，用戶(hù)學(xué)習(xí)和使用的門(mén)檻較高。
• 不同SQL引擎之間的語(yǔ)法和功能支持上存在差異，需要大量的測(cè)試和兼容工作，完全兼容的成本較高。
• 不同SQL引擎各自提供服務(wù)會(huì)給數(shù)倉(cāng)的血緣管理、權(quán)限控制、運(yùn)維管理、資源利用都帶來(lái)不便。




智能引擎的解決方案

• 在Hive中，自定義實(shí)現(xiàn)引擎。
• 自動(dòng)路由功能，不需要設(shè)置引擎，自動(dòng)選擇適合的加速引擎。

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

• 復(fù)用HiveServer2集群架構(gòu)。

智能引擎：主流引擎方案對(duì)比

智能引擎：HiveServer2自定義執(zhí)行引擎的模塊設(shè)計(jì)

基于HiveServer2，有兩種實(shí)現(xiàn)方式。JDBC方式是通過(guò)JDBC接口，將SQL發(fā)送至后端加速引擎啟動(dòng)的集群上。PROXY方式是將SQL下推給本地的加速引擎啟動(dòng)的Client。

JDBC方式啟動(dòng)的后端集群，均是基于YARN，可以實(shí)現(xiàn)資源的分時(shí)復(fù)用。比如AdHoc集群的資源在夜間會(huì)自動(dòng)回收，作為報(bào)表系統(tǒng)的資源進(jìn)行復(fù)用。

智能引擎：SQL路由方案設(shè)計(jì)架構(gòu)

路由方案基于HS2的Hook架構(gòu)，在HS2端實(shí)現(xiàn)對(duì)應(yīng) Hook，用于引擎切換;后端BeaconServer服務(wù)中實(shí)現(xiàn)路由 服務(wù)，用于SQL的路由規(guī)則的匹配處理。不同集群可配置不同的路由規(guī)則。

為了保證后算路由服務(wù)的穩(wěn)定性，團(tuán)隊(duì)還設(shè)計(jì)了Rewrite Hook，用于重寫(xiě)AdHoc集群中的SQL，自動(dòng)添加LIMIT上限，防止大數(shù)據(jù)量的SCAN。

智能引擎：SQL路由規(guī)則一覽

智能引擎：方案優(yōu)勢(shì)

• 易于集成，當(dāng)前主流的SQL引擎都可以方便的實(shí)現(xiàn)JDBC與PROXY方式。再通過(guò)配置，能簡(jiǎn)單的集成新的查詢(xún)引擎，比如impala、drill等。


• 自動(dòng)選擇引擎，減少了用戶(hù)的引擎使用成本，同時(shí)也讓遷移變得更簡(jiǎn)單。并且在加速引擎過(guò)載 的情況下，可以動(dòng)態(tài)調(diào)整比例，防止因過(guò)載 對(duì)加速性能的影響。


• 自動(dòng)降級(jí)，保證了運(yùn)行的可靠性。SQL路由支持failback模塊，可以根據(jù)配置選擇是否再路由引擎執(zhí)行失敗后，回滾到 MR運(yùn)行。


• 模塊復(fù)用，對(duì)于新增的引擎，都可以復(fù)用HiveServer2定制的血緣采集、權(quán)限認(rèn)證、并發(fā)鎖控制等方案，大大降低了使用成本。


• 資源復(fù)用，對(duì)于adhoc查詢(xún)占用資源可以分時(shí)動(dòng)態(tài)調(diào)整，有效保證集群資源的利用率。




智能引擎DQL應(yīng)用效果

HiveServer2中存在的性能問(wèn)題

FetchTask加速：預(yù)排序與邏輯優(yōu)化

當(dāng)查詢(xún)完成后，本地會(huì)輪詢(xún)結(jié)果文件，一直獲取到LIMIT大小，然后返回。這種情況下，當(dāng)有大量的小文件存在，而大文件在后端的時(shí)候，會(huì)導(dǎo)致Bad Case，不停與HDFS交互，獲取文件信息以及文件數(shù)據(jù)，大大拉長(zhǎng)運(yùn)行時(shí)間。

在Fetch之前，對(duì)結(jié)果文件的大小進(jìn)行預(yù)排序，可以有數(shù)百倍的性能提升。

示例：當(dāng)前有200個(gè)文件。199個(gè)小文件一條記錄a，1個(gè)大文件混合記錄a與test共200條，大文件名index在小文件之后。

FetchTask加速：預(yù)排序與邏輯優(yōu)化

Hive中有一個(gè)SimpleFetchOptimizer優(yōu)化器，會(huì)直接生成FetchTask，減小資源申請(qǐng)時(shí)間與調(diào)度時(shí)間。但這個(gè)優(yōu)化會(huì)出現(xiàn)瓶頸。如果數(shù)據(jù)量小，但是文件數(shù)多，需要返回的條數(shù)多， 存在能大量篩掉結(jié)果數(shù)據(jù)的Filter條件。這時(shí)候串行讀取輸入文件，導(dǎo)致查詢(xún)延遲大，反而沒(méi)起到加速效果。

在SimpleFetchOptimizer優(yōu)化器中，新增文件數(shù)的判斷條件，最后將任務(wù)提交到集群環(huán)境， 通過(guò)提高并發(fā)來(lái)實(shí)現(xiàn)加速。

示例：讀取當(dāng)前500個(gè)文件的分區(qū)。優(yōu)化后的文件數(shù)閾值為100。

大表Desc Table優(yōu)化

一個(gè)表有大量的子分區(qū)，它的DESC過(guò)程會(huì)與元數(shù)據(jù)交互，獲取所有的分區(qū)。但最后返回的結(jié)果，只有跟表相關(guān)的信息。

與元數(shù)據(jù)交互的時(shí)候，延遲了整個(gè)DESC的查詢(xún)，當(dāng)元數(shù)據(jù)壓力大的時(shí)候甚至無(wú)法返回結(jié)果。

針對(duì)于TABLE的DESC過(guò)程，直接去掉了跟元數(shù)據(jù)交互獲取分區(qū)的過(guò)程，加速時(shí)間跟子分區(qū)數(shù)量成正比。

示例：desc十萬(wàn)分區(qū)的大表。

其它改進(jìn)

• 復(fù)用split計(jì)算的數(shù)據(jù)，跳過(guò)reduce估算重復(fù)統(tǒng)計(jì)輸入過(guò)程。輸入數(shù)據(jù)量大的任務(wù)，調(diào)度速率提升50%。
• parquetSerde init加速，跳過(guò)同一表的重復(fù)列剪枝優(yōu)化，防止map task op init時(shí)間超時(shí)。
• 新增LazyOutputFormat，有record輸出再創(chuàng)建文件，避免空文件的產(chǎn)生，導(dǎo)致下游讀取大量空文件消耗時(shí)間。
• statsTask支持多線程聚合統(tǒng)計(jì)信息，防止中間文件過(guò)多導(dǎo)致聚合過(guò)慢，增大運(yùn)行時(shí)間。
• AdHoc需要打開(kāi)并行編譯，防止SQL串行編譯導(dǎo)致整體延遲時(shí)間增大的問(wèn)題。




SQL on Hadoop平臺(tái)在使用中遇到的痛點(diǎn)

SQL on Hadoop在快手使用：常見(jiàn)可用性問(wèn)題

HiveServer2服務(wù)啟動(dòng)優(yōu)化

HS2啟動(dòng)時(shí)會(huì)對(duì)物化視圖功能進(jìn)行初始化，輪詢(xún)整個(gè)元數(shù)據(jù)庫(kù)，導(dǎo)致HS2的啟動(dòng)時(shí)間非常長(zhǎng)，從下線狀態(tài)到重新上線間隔過(guò)大，可用性很差。

將物化視圖功能修改為延遲懶加載，單獨(dú)線程加載，不影響HS2的服務(wù)啟動(dòng)。物化視圖支持加載中獲取已緩存信息，保證功能的可用性。

HS2啟動(dòng)時(shí)間從5min+提升至<5s。

HiveServer2配置熱加載

HS2本身上下線成本較高，需要保證服務(wù)上的任務(wù)全部執(zhí)行完成才能進(jìn)行操作。配置的修改可作為較高頻率的操作，且需要做到熱加載。

在HS2的ThriftServer層我們?cè)黾恿私涌?，與運(yùn)維系統(tǒng)打通后，配置下推更新的時(shí)候自動(dòng)調(diào)用，可實(shí)現(xiàn)配置的熱加載生效。

HiveServer2的Scratchdir優(yōu)化

HiveServer2的scratchdir主要用于運(yùn)行過(guò)程中的臨時(shí)文件存儲(chǔ)。當(dāng)HS2中的會(huì)話創(chuàng)建時(shí)，便會(huì)創(chuàng)建scratchdir。 在HDFS壓力大的時(shí)候，大量的會(huì)話會(huì)阻塞在創(chuàng)建scratchdir過(guò)程，導(dǎo)致連接數(shù)堆積至上限，最終HS2服務(wù)無(wú)法再連入新連接，影響服務(wù)可用性。

對(duì)此，我們先分離了一般查詢(xún)與create temporay table查詢(xún)的scratch目錄，并支持create temporay table查詢(xún)的scratch的懶創(chuàng)建。 當(dāng)create temporay table大量創(chuàng)建臨時(shí)文件，便會(huì)影響HDFS NameNode延遲時(shí)間的時(shí)候，一般查詢(xún)的scratchdir HDFS NameNode可以正常響應(yīng)。

此外，HS2還支持配置多scratch，不同的scratch能設(shè)置加載比率，從而實(shí)現(xiàn)HDFS的均衡負(fù)載。

Hive Stage并發(fā)調(diào)度異常修復(fù)

Hive調(diào)度其中存在兩個(gè)問(wèn)題。

一、子Task非執(zhí)行狀態(tài)為完成情況的時(shí)候，若有多輪父Task包含子Task，導(dǎo)致子Task被重復(fù)加入調(diào)度隊(duì)列。這種Case，需要將非執(zhí)行狀態(tài)修改成初始化狀態(tài)。

二、當(dāng)判斷子Task是否可執(zhí)行的過(guò)程中，會(huì)因?yàn)闋顟B(tài)檢測(cè)異常，無(wú)法正常加入需要調(diào)度的子Task，從而致使查詢(xún)丟失Stage。而這種Case，我們的做法是在執(zhí)行完成后，加入一輪Stage的執(zhí)行結(jié)果狀態(tài)檢查，一旦發(fā)現(xiàn)有下游Stage沒(méi)有完成，直接拋出錯(cuò)誤，實(shí)現(xiàn)查詢(xún)結(jié)果狀態(tài)的完備性檢查。

其它改進(jìn)

• HS2實(shí)現(xiàn)了接口終止查詢(xún)SQL。利用這個(gè)功能，可以及時(shí)終止異常SQL。
• metastore JDOQuery查詢(xún)優(yōu)化，關(guān)鍵字異常跳過(guò)，防止元數(shù)據(jù)長(zhǎng)時(shí)間卡頓或者部分異常查詢(xún)影響元數(shù)據(jù)。
• 增加開(kāi)關(guān)控制，強(qiáng)制覆蓋外表目錄，解決insert overwrite外表，文件rename報(bào)錯(cuò)的問(wèn)題。
• hive parquet下推增加關(guān)閉配置，避免parquet異常地下推OR條件，導(dǎo)致結(jié)果不正確。
• executeForArray函數(shù)join超大字符串導(dǎo)致OOM，增加限制優(yōu)化。
• 增加根據(jù)table的schema讀取分區(qū)數(shù)據(jù)的功能，避免未級(jí)聯(lián)修改分區(qū)schema導(dǎo)致讀取數(shù)據(jù)異常。




SQL on Hadoop平臺(tái)在使用中遇到的痛點(diǎn)

為什么要開(kāi)發(fā)SQL專(zhuān)家系統(tǒng)

•  部分用戶(hù)并沒(méi)有開(kāi)發(fā)經(jīng)驗(yàn)，無(wú)法處理處理引擎返回的報(bào)錯(cuò)。
• 有些錯(cuò)誤的報(bào)錯(cuò)信息不明確，用戶(hù)無(wú)法正確了解錯(cuò)誤原因。
• 失敗的任務(wù)排查成本高，需要對(duì)Hadoop整套系統(tǒng)非常熟悉。
• 用戶(hù)的錯(cuò)誤SQL、以及需要優(yōu)化的SQL，大量具有共通性。人力維護(hù)成本高，但系統(tǒng)分析成本低。




SQL專(zhuān)家系統(tǒng)

SQL專(zhuān)家系統(tǒng)基于HS2的Hook架構(gòu)，在BeaconServer后端實(shí)現(xiàn)了三個(gè)主要的模塊，分別是SQL規(guī)則控制模塊、SQL錯(cuò)誤分析模塊，與SQL優(yōu)化建議模塊。SQL專(zhuān)家系統(tǒng)的知識(shí)庫(kù)，包含關(guān)鍵字、原因說(shuō)明、處理方案等幾項(xiàng)主要信息，存于后端數(shù)據(jù)庫(kù)中，并一直積累。

通過(guò)SQL專(zhuān)家系統(tǒng)，后端可以進(jìn)行查詢(xún)SQL的異?？刂疲苊猱惓QL的資源浪費(fèi)或者影響集群穩(wěn)定。用戶(hù)在遇到問(wèn)題時(shí)，能直接獲取問(wèn)題的處理方案，減少了使用成本。

示例：空分區(qū)查詢(xún)控制。

作業(yè)診斷系統(tǒng)

SQL專(zhuān)家系統(tǒng)能解決一部分HS2的任務(wù)執(zhí)行的錯(cuò)誤診斷需求，但是比如作業(yè)健康度、任務(wù)執(zhí)行異常等問(wèn)題原因的判斷，需要專(zhuān)門(mén)的系統(tǒng)來(lái)解決，為此我們?cè)O(shè)計(jì)了作業(yè)診斷系統(tǒng)。

作業(yè)診斷系統(tǒng)在YARN的層面，針對(duì)不同的執(zhí)行引擎，對(duì)搜集的Counter和配置進(jìn)行分析。在執(zhí)行層面，提出相關(guān)的優(yōu)化建議。

作業(yè)診斷系統(tǒng)的數(shù)據(jù)也能通過(guò)API提供給SQL專(zhuān)家系統(tǒng)，補(bǔ)充用于分析的問(wèn)題原因。

作業(yè)診斷系統(tǒng)提供了查詢(xún)頁(yè)面來(lái)查詢(xún)運(yùn)行的任務(wù)。以下是命中map輸入過(guò)多規(guī)則的任務(wù)查詢(xún)過(guò)程：

在作業(yè)界面，還可以查看更多的作業(yè)診斷信息，以及作業(yè)的修改建議。

SQL on Hadoop平臺(tái)在使用中遇到的痛點(diǎn)

SQL on Hadoop在快手使用：常見(jiàn)運(yùn)維性問(wèn)題

審計(jì)分析 - 架構(gòu)圖

審計(jì)功能也是BeaconServer服務(wù)的一個(gè)模塊。

通過(guò)HS2中配置的Hook，發(fā)送需要的SQL、IP、User等信息至后端，進(jìn)行語(yǔ)法分析，便可提取出DataBase、Table、Columns與操作信息，將其分析后再存入Druid系統(tǒng)。用戶(hù)可通過(guò)可視化平臺(tái)查詢(xún)部分開(kāi)放的數(shù)據(jù)。

審計(jì)分析 - 熱點(diǎn)信息查詢(xún)

熱點(diǎn)信息查詢(xún)即將熱點(diǎn)信息展示了一段時(shí)間以?xún)?nèi)，用戶(hù)的熱點(diǎn)操作，這其中包括訪問(wèn)過(guò)哪些庫(kù)，哪些表，以及哪些類(lèi)型的操作。

審計(jì)分析 - 血緣信息查詢(xún)

下圖可看出，血緣信息展示了一張表創(chuàng)建的上游依賴(lài)，一般用于統(tǒng)計(jì)表的影響范圍。

審計(jì)分析 - 歷史操作查詢(xún)

歷史操作可以溯源到一段時(shí)間內(nèi)，對(duì)于某張表的操作。能獲取到操作的用戶(hù)、客戶(hù)端、平臺(tái)、以及時(shí)間等信息。一般用于跟蹤表的增刪改情況。

HiveServer2集群AB切換方案

因?yàn)镠iveServer2服務(wù)本身的上下線成本較高，如果要執(zhí)行一次升級(jí)操作，往往耗時(shí)較長(zhǎng)且影響可用性。HiveServer2集群的AB切換方案，主要依靠A集群在線，B集群備用的方式，通過(guò)切換ZK上的在線集群機(jī)器，來(lái)實(shí)現(xiàn)無(wú)縫的升級(jí)操作。

HiveServer2集群動(dòng)態(tài)上下線

HiveServer2集群部署了Metrics監(jiān)控，能夠?qū)崟r(shí)地跟蹤集群服務(wù)的使用情況。此外，我們對(duì)HS2服務(wù)進(jìn)行了改造，實(shí)現(xiàn)了HS2 ZK下線和請(qǐng)求Cancel的接口。

當(dāng)外部Monitor監(jiān)控感知到連續(xù)內(nèi)存過(guò)高，會(huì)自動(dòng)觸發(fā)HS2服務(wù)進(jìn)程的FGC操作，如果內(nèi)存依然連續(xù)過(guò)高，則通過(guò)ZK直接下線服務(wù)，并根據(jù)查詢(xún)提交的時(shí)間順序，依次停止查詢(xún)，直到內(nèi)存恢復(fù)，保證服務(wù)中剩余任務(wù)的正常運(yùn)行。

HiveServer2集群管理平臺(tái)

HiveServer2在多集群狀態(tài)下，需要掌握每個(gè)集群、以及每個(gè)HS2服務(wù)的狀態(tài)。通過(guò)管理平臺(tái)，可以查看版本情況、啟動(dòng)時(shí)間、資源使用情況以及上下線狀態(tài)。

后續(xù)跟運(yùn)維平臺(tái)打通，可以更方便地進(jìn)行一鍵式灰度以及升級(jí)。

快手查詢(xún)平臺(tái)的改進(jìn)總結(jié)

04快手SQL on Hadoop的未來(lái)計(jì)劃

• 專(zhuān)家系統(tǒng)的升級(jí)，實(shí)現(xiàn)自動(dòng)化參數(shù)調(diào)優(yōu)和SQL優(yōu)化
• AdHoc查詢(xún)的緩存加速

新引擎的調(diào)研與應(yīng)用