編輯整理:汪宸妃 武漢大學(xué) 出品平臺(tái):DataFunTalk 導(dǎo)讀:在騰訊金融場(chǎng)景,我們每天都會(huì)產(chǎn)生大量的數(shù)據(jù),為了提升分析的交互性,讓決策更加敏捷,我們引入了Impala來(lái)解決我們的分析需求。所以,本文將和大家分享Impala在騰訊金融大數(shù)據(jù)場(chǎng)景中的應(yīng)用架構(gòu),Impala的原理,落地過(guò)程的案例和優(yōu)化以及總結(jié)思考。 首先介紹Impala的整體架構(gòu),幫助大家從宏觀角度理解整個(gè)Impala系統(tǒng),掌握框架上的知識(shí)和概念。 Impala存儲(chǔ)的方式分為兩種分別是Kudu和HDFS,其中Kudu實(shí)時(shí)點(diǎn)擊流的場(chǎng)景,HDFS存儲(chǔ)大多數(shù)據(jù)。 Impala應(yīng)用包括以下幾類:
Impala的主要特點(diǎn):Impala是在Hadoop大數(shù)據(jù)的框架中構(gòu)建查詢引擎,并主要依賴Hive和HDFS的組建,并通過(guò)Fdata將海量數(shù)據(jù)寫(xiě)入平臺(tái),從而為業(yè)務(wù)方提供高效便捷的數(shù)據(jù)查詢功能。
在從宏觀角度整體了解了Impala的架構(gòu)之后,接下來(lái),為大家介紹Impala的兩個(gè)重要原理,分別是并發(fā)原理和基于CBO的表關(guān)聯(lián)優(yōu)化原理。 1. 線程的分層 主要包括三類,分別是實(shí)例線程,數(shù)據(jù)掃描scan線程(解壓縮),io線程。在impala的默認(rèn)模式下,實(shí)現(xiàn)了計(jì)算和掃描一對(duì)多,掃描層充分開(kāi)發(fā),但在多線程模式下,在掃描層化為單線程直接使用實(shí)例線程,跟計(jì)算層構(gòu)成以實(shí)例為單位的開(kāi)發(fā)。 2. 遇到的兩個(gè)問(wèn)題 ① 高并發(fā)下抖動(dòng)嚴(yán)重,原因出現(xiàn)在RPC相關(guān)的EXCHANGE:因?yàn)樵诟卟l(fā)狀態(tài)下,數(shù)據(jù)由sender端push給Receiver端,且Receiver端由BatchQueue進(jìn)行接受,一旦隊(duì)列滿了或者deferred不為空,就會(huì)傳輸給deferredRPCS,因此極容易導(dǎo)致隊(duì)列堆積。 解決方式,首先將參數(shù): datastream_service_num_deserialization_threads 進(jìn)行調(diào)整,因?yàn)闄C(jī)器CPU超線程數(shù)為96,所以將該參數(shù)調(diào)整到80,成功地提高了在高并發(fā)狀態(tài)下地穩(wěn)定性,提高了數(shù)據(jù)查詢地有效性。 ② Cast to string問(wèn)題,導(dǎo)致并發(fā)不增反降,對(duì)查詢效率帶來(lái)極大的影響。 3. 并發(fā)特性的制約因素 并發(fā)的最小顆粒度為文件,因此當(dāng)表字段比較少,且按照文件大小生成文件,將導(dǎo)致在同一個(gè)文件中所包含的行數(shù)增多,并發(fā)度降低;若選擇將文件拆開(kāi)提高并行度,但獲取的數(shù)據(jù)量變小,導(dǎo)致磁盤(pán)的io效率降低。因此從這兩方面來(lái)說(shuō),均制約了Impala的并發(fā)。 1. 基本工作
2. 三個(gè)問(wèn)題 ① Outer join出現(xiàn)數(shù)據(jù)傾斜,采取軸心表策略控制join的順序,提升效率。 比如因?yàn)閮杀碜隽藘纱蔚膃xchange,所以A表join B表之后重新exchange導(dǎo)致大量NULL數(shù)據(jù)傾斜,對(duì)于這一問(wèn)題采取的解決方案是軸心表策略,從join的順序上控制數(shù)據(jù)的問(wèn)題。該策略是基于RBO規(guī)則的,首先結(jié)合CBO預(yù)估子查詢的數(shù)據(jù)量,以某個(gè)子查詢?yōu)檩S心,將其他的查詢以這個(gè)表作為首位進(jìn)行排列,并采用straight_join控制join的順序,從而順利解決該問(wèn)題。并且在優(yōu)化前后,效率得到了一個(gè)極大地提升。 ② 多個(gè)表group不一致導(dǎo)致多余的exchange,不同地子查詢有不同地groupby順序,頻繁地交換數(shù)據(jù)產(chǎn)出地順序,帶來(lái)大量數(shù)據(jù)冗余,降低了后續(xù)相關(guān)數(shù)據(jù)查詢地效率,因此解決這個(gè)問(wèn)題需要保證多個(gè)表在執(zhí)行g(shù)roup by順序一致,才能有效減少exchange地次數(shù),從而提高效率 ③ 平均分布假設(shè)引發(fā)的預(yù)估偏差導(dǎo)致broadcast join,因?yàn)閕mpala在實(shí)踐查詢之前,會(huì)基于平均分布假設(shè)預(yù)估生成表地?cái)?shù)據(jù)量,但一旦產(chǎn)生偏差,就會(huì)導(dǎo)致broadcast join地發(fā)生,從而影響該次查詢的效率。 3. 廣泛應(yīng)用 針對(duì)跨主題分析的情況,采用多表關(guān)聯(lián)的虛擬cube方案,避免創(chuàng)建大量用戶包,并嘗試從產(chǎn)品和技術(shù)層面限制關(guān)聯(lián)關(guān)系,減少無(wú)效關(guān)聯(lián)查詢和多對(duì)多關(guān)聯(lián)查詢。 比如需要查詢11.26日訪問(wèn)過(guò)首頁(yè)banner的用戶申購(gòu)轉(zhuǎn)化情況,首先需要根據(jù)訪問(wèn)11.26首頁(yè)banner的用戶數(shù)據(jù),生成用戶行為主題,隨后提取所有訪問(wèn)過(guò)首頁(yè)banner的人群,通過(guò)人群關(guān)聯(lián)分析整個(gè)用戶申購(gòu)的情況,申城主站用戶申購(gòu)的主題。這一過(guò)程反映了原來(lái)的分析模型不支持主題分析,主題和主題之間需要通過(guò)人群包進(jìn)行轉(zhuǎn)化,效率低下。 但在運(yùn)用了impala的多表關(guān)聯(lián)功能之后,可以將用戶申贖回行為的虛擬主題這以請(qǐng)求進(jìn)行拆分,轉(zhuǎn)換成關(guān)聯(lián)子查詢,分為用戶行為主題和主站用戶申購(gòu)主題,極大的提高了效率,也避免了人群包的使用,減少數(shù)據(jù)量的處理。 除了以上介紹的兩個(gè)基本原理,Impala的存儲(chǔ)層實(shí)現(xiàn)的原理和應(yīng)用在整個(gè)Impala中也是不可忽視的,接下來(lái)為大家介紹的就是其存儲(chǔ)層的相關(guān)理論和運(yùn)用。 1. 原理 交互式分析引擎的實(shí)現(xiàn)思路分為進(jìn)行預(yù)計(jì)算,提前計(jì)算出所有可能維度組合的結(jié)果,或通過(guò)即時(shí)計(jì)算包括建立倒排索引和列式存儲(chǔ)統(tǒng)計(jì)信息。其中倒排索引是指對(duì)匹配的結(jié)果進(jìn)行鏈表歸并或bitmap處理,將每一列獨(dú)立存儲(chǔ),并在符合olap每次只分析部分列的需求,同時(shí)利用統(tǒng)計(jì)信息減少io的消耗。在并發(fā)度不那么高的背景下,多采用列式存儲(chǔ)的原理,因其采用單行組的形式對(duì)數(shù)據(jù)進(jìn)行存儲(chǔ),可以減少io次數(shù),從而提升QPS。下圖為列式存儲(chǔ)的抽象表示: 對(duì)于性能差異的原因,通過(guò)一個(gè)例子能夠很好的理解,比如一個(gè)分區(qū)存儲(chǔ)150G,供727個(gè)文件,平均每個(gè)文件211M,一共273列,平均每一列774k。impala再讀取的過(guò)程中會(huì)向scanRange對(duì)象中填充讀取一個(gè)內(nèi)存塊,所以若每次只讀一列,只需要一次io,但如果分散再多個(gè)行組中就需要多次io,尤其是如果行組太多就同行存無(wú)異。因此在一個(gè)parquet文件與hdfs的block大小一致,并且僅包含一個(gè)row group,可以最大限度地提高QPS和運(yùn)行效率,避免大量行組導(dǎo)致效率低下地問(wèn)題。 2. 數(shù)據(jù)過(guò)濾 Impala的存儲(chǔ)層有良好的數(shù)據(jù)過(guò)濾體系,主要分三步從行組級(jí)統(tǒng)計(jì)信息、pageIndex、字典信息三個(gè)方面進(jìn)行最大化的數(shù)據(jù)過(guò)濾,減少io次數(shù)。其中前兩步都需要考慮profile中的指標(biāo),行組中每個(gè)列地統(tǒng)計(jì)信息包括最大值或最小值等等。第三步字典信息中對(duì)于profile重點(diǎn)阿指標(biāo)只對(duì)encode類型進(jìn)行考慮,包括PLAIN DICTIONARY等并只使用與總數(shù)小于4萬(wàn)地情況。 并考慮采取全局排序、hash分區(qū)后排序、z-order排序三種方式對(duì)數(shù)據(jù)過(guò)濾過(guò)程進(jìn)行優(yōu)化,提高處理效率和穩(wěn)定性。 3. 應(yīng)用 優(yōu)化前的畫(huà)像分析需要運(yùn)用spark進(jìn)行資源調(diào)度,并對(duì)全部字段生成倒排索引消耗大量時(shí)間,在引入Impala優(yōu)化后,可以直接進(jìn)行畫(huà)像分析。Impala通過(guò)用戶包畫(huà)像表直接表關(guān)聯(lián)到畫(huà)像寬度和依據(jù)用戶包和全量業(yè)務(wù)表生成的集合表,提供畫(huà)像分析功能的使用?;谶@一層次x優(yōu)化落地的功能效果也十分顯著,例如針對(duì)1800萬(wàn)人群包畫(huà)像生成時(shí)間從20分鐘縮短成1分鐘,并支持基于交互式結(jié)果的直接查看用戶畫(huà)像的能力,性能和功能都得到了極大的提升。 在了解完Impala的整體架構(gòu),處理邏輯的原理和存儲(chǔ)層的相關(guān)理論之后,相信大家都對(duì)Impala有了一個(gè)更加深入的認(rèn)識(shí),接下來(lái)就為大家提供一些思路的總結(jié)。 1. OLAP引擎性能優(yōu)化技術(shù)路線 下面是對(duì)OLAP引擎性能優(yōu)化技術(shù)路線的一個(gè)總結(jié),這對(duì)于深入到某個(gè)具體的引擎做深度優(yōu)化,提升性能是很好的參考思路。向量化、動(dòng)態(tài)代碼生成這兩種方式是比較傳統(tǒng)的思路,其中動(dòng)態(tài)代碼生成最大化減少對(duì)類型的分支判斷,減少指令,提升計(jì)算性能。 2. Impala性能相關(guān)優(yōu)化思路總結(jié) 性能優(yōu)化思路分為問(wèn)題驅(qū)動(dòng)和指標(biāo)驅(qū)動(dòng)。其中問(wèn)題驅(qū)動(dòng)包括基本優(yōu)化和高級(jí)優(yōu)化兩類,基本優(yōu)化需要從基本原理和profile信息進(jìn)行基本理解,并優(yōu)化系統(tǒng)日志兩部分;高級(jí)優(yōu)化首先需要理解源碼,反復(fù)直接調(diào)整參數(shù)看優(yōu)化效果,同時(shí)考慮從應(yīng)用外分析和應(yīng)用內(nèi)分析。 指標(biāo)驅(qū)動(dòng)則通過(guò)設(shè)計(jì)壓力測(cè)試場(chǎng)景進(jìn)行優(yōu)化,將IO,CPU,網(wǎng)絡(luò)壓滿,并看在這些狀況下,系統(tǒng)查詢行為表現(xiàn)如何,在不斷實(shí)踐過(guò)程中調(diào)整參數(shù),并構(gòu)建線上運(yùn)行指標(biāo),分析占比,重點(diǎn)優(yōu)化各項(xiàng)重要指標(biāo),從而對(duì)impala性能進(jìn)行一個(gè)好的優(yōu)化。 |
|
來(lái)自: 520jefferson > 《大數(shù)據(jù)》