快手BI大數據分析場景效能最佳化實踐

2024.03.19

一、快手分析產品介紹

KwaiBI 產品是目前快手內部使用的資料分析產品,平台願景是:致力於透過豐富分析工具產品,打造一站式的資料分析平台,提升資料擷取與分析效率。KwaiBI 目前月活達到1.5W,支援5W 以上的報表數,10W 以上的模型,接入150 多個大大小小的業務。

KwaiBI 提供5 種資料消費場景,取數、多維分析、視覺化、推播、入口網站。其中主要的分析場景是多維分析和視覺化。

圖片

1. 快手分析平台的分析能力介紹

快手分析平台底層對接多種資料來源,包括大數據儲存各種引擎、傳統的關聯式資料庫,也支援一些本地文件的資料分析。

在使用KwaiBI 分析平台做資料分析之前,使用者需要先將以上這些資料來源連結到分析平台。資料存取通常由資料內容的建構者(DE/DPM)完成,會對資料來源進行資料建模,即建構表格與表格之間的關係,透過資料建模得到對應的資料模型,在此模型之上,建立資料集(資料集通常是一個業務域或一個業務主題的集合)。在資料存取過程中,如果標準化的指標維度會通過指標中台,進行標準化管理指標/維度,再直接接取分析平台。

圖片

資料存取後,分析平台提供了一系列的分析能力,例如基礎的資料分析能力(資料明細、資料聚合、跨來源運算),在基礎的分析之上可以做一些複雜分析,如同環比、佔比、LOD 分析、表格計算等。基於這些強大的分析能力,資料的終端消費使用者(DA/營運)透過多維分析和視覺化可使用這些能力做分析。

2.快手分析場景表現挑戰

快手大數據分析平台,作為一個資料輸出平台,對使用者而言,面臨的挑戰主要包括:

  • 效能分析困難:不清楚耗時在哪個環節,平台對使用者來說是黑盒的;不了解資料消費用戶的查詢特徵;效能波動難以歸因。
  • 優化門檻高:需要很強的知識背景,很強的專業領域性,而分析使用者通常是小白用戶無法自行分析和優化。

平台方面,也面臨一些挑戰:

  • 分析複雜度高:30% 以上的複雜分析,包含同環比、佔比、LOD 分析等;
  • 引擎查詢複雜度高:關聯查詢多、資料量大,查詢時間範圍大;
  • 引擎限制:目前快手主要的引擎是 ClickHouse,其對關聯查詢不友好,SQL 優化不聰明。(每個引擎都有其自身限制)

3.快手分析場景效能最佳化實踐

(1)打法策略

針對效能分析困難的問題,分析平台透過進行全鏈路埋點,得知效能耗時到底在哪個環節。基於這些埋點,平台可對使用者進行查詢畫像分析,從而了解使用者在分析什麼指標、在分析什麼維度、分析的時間範圍。有了使用者畫像資訊後,進一步可建立自主化資料集效能診斷分析工具,進行開放式自助的效能分析。

針對優化門檻高的問題,分析平台會對查詢自動優化,包括快取預熱、物化加速、查詢優化等各種手段。此外,基於現有的使用者查詢畫像,可以用資料消費來驅動資料內容,進行相關最佳化。

整體思路主要分為四步,分別為確定目標、確認團隊(參與者)、效能分析(分析不同場景下效能原因)、制定解決方案並落地。

(2)確定目標

分析效能的目標,是以分析平台資料消費使用者視角來評估分析平台的效能,主要抽象化成三個效能北極星指標:查詢平均耗時、查詢耗時P90、查詢成功率。針對三個指標,分場景來決定目標值。例如在視覺化看板場景下,大多是一些重要數據的沉澱,也是一些重要的人在看,所以對性能保障要求相對更高;對於多維分析場景,更自主化,靈活化,用於日常運營,這時性能目標可以定得相對寬鬆一些。

總的來說,效能目標並沒有一個絕對值,需要根據公司的業務場景,各個業務團隊的分析需求來達成。以指標作為牽引,持續追蹤對效能優化的效果。

(3)確認團隊

分析性能的提升不僅是分析平台的,性能優化是需要分析平台團隊、數倉團隊以及引擎團隊,三方來進行合作共建,共同保障的。一個完整的分析連結包括引擎查詢以及分析平台二次分析計算,其影響因素是多因子的,若僅僅從分析平臺本身做功,只能是把分析平台內部優化做好。但有些數據內容建構品質提升,以及引擎層面計算優化,需要三方來進行合作共建。

圖片

(4)性能分析

做好性能優化,我們首先要明確性能劣化的根因,進而對症下藥。平台側希望透過沉澱通用的查詢效能分析工具,來幫助使用者進行自助分析。自助分析的前提要有充分的元數據,元數據主要是兩類,一個是分析服務的埋點,另外是收集一些物理元數據。

結合兩類元數據,則可以建立數據集的查詢畫像數據。這樣就可以了解到,用戶在看哪些高熱的指標維度、使用了哪些高熱表以及通常查詢哪些時間範圍的數據,也可以看到分析平台自己的一些指標,比如緩存命中率以及其它一些內部查詢的耗時,這些都可以根據元資料分析出來。另外,也有一些診斷的規則合集,這些診斷規則,主要是一些對查詢效能不友善的規則。基於畫像和規則,最終得到一個診斷結論:資料集可能存在哪些資料問題、有哪些可以優化的空間。常見的效能問題可以基於分析工具來自助分析。

圖片

(5)解決方案

基於效能分析的結論,分析平台側制定體系化的解決方案,推動三個團隊共同建設,達成最佳化目標。分析平臺本身做平台的效能最佳化,透過例如快取預熱、物化加速、查詢最佳化等各種手段,優化分析平台的效能。分析平台為數倉提供資料集的效能診斷,把資料集可能存在的問題,直接暴露給數倉團隊,針對對應問題,來做針對化的資料建置最佳化,例如一些高熱查詢可以做聚合表、加索引、做資料哈希等。

圖片

數倉做的一些高品質的數據,也會接入數據平台,對用戶的體現就是效能和品質的提升。引擎團隊會對分析平台和數倉,提供引擎方面的能力支持,也會做持續的效能優化。

以下重點介紹分析平台側做的一些最佳化策略:

分析平台效能最佳化-快取預熱

對於一些固化的看數場景,例如看板場景,提前把看板數據或圖表查詢放到緩存中,當用戶使用時,直接從緩訪問數據,這樣不管原始查詢的數據量有多大,直接讀取緩存的性能一定是很有效率的。

快取預熱能力建置主要是四個部分,預熱觸發器、預熱計算器、預熱執行器、預熱監控。

預熱觸發器判斷什麼情況下需要做快取預熱。例如定時調度,在使用者高峰使用期,提前進行快取預熱。另外,進行資料加速的同時,也要保障資料品質。

預熱計算器,計算歷史的哪些查詢、哪些圖表,是值得預熱、有價值的。透過觀察資料集的血緣,來知道資料是離線生產的還是即時生產的,很顯然即時生產的資料不適合做預熱。另外,對於一些固定化的、高熱的圖表做預熱。最後計算到,想要預熱的是哪些圖表,或是哪些使用者歷史查詢。

圖片

因為預熱執行器預熱的量可能很大,考慮到對服務負載,要加入一些並發控制,最後把預熱的資料放到快取中。

最後是預熱的監控,監控快取預熱的執行情況,執行耗時以及快取預熱的快取命中率。經過快取預熱建設,可視化看板場景的首屏命中率可達到90%,非首屏的快取命中率達到了30%。

分析平台效能最佳化-查詢最佳化

查詢的最佳化首先會基於快手開放分析表達式OAX(快手面向分析場景的統一分析語言,上述所有分析場景都基於OAX 建構)。即將使用者最終的資料分析抽象化成OAX 語言,並對此OAX 語言進行解析,知道使用者有哪些高階計算,以及哪些是基於模型或基於物理表的計算,然後會進行一些初級的分析編排。

接著進行AST 優化。AST 的葉子節點是從引擎來讀取數據,但是對於分析平台來說,有的是面向表,有的是面向模型(基於表與表之間的關係,構建模型)。一個資料集可以有多個模型,一個指標在多個模型中都可以支援。其中會進行模型搜尋的最佳化,以保障選取的表格或模型,是資料準確的,同時保障選取的模型,其取數效率是最優的。取到既滿足準確性,又高效率的一個模型。

圖片

有了模型後,會把這個模型翻譯成引擎的查詢語言,並在翻譯中,做一些通用的或是Native 的SQL 最佳化。

當葉子節點也是面向引擎的SQL 的時候,AST 就可以真正的物理編排,物理編排後就可以執行了。

快手在查詢最佳化過程中,沉澱了50 多個通用的& Native 最佳化規則包括:

  • 複雜分析查詢下推:佔比或同環比這些複雜分析,盡量轉換成一個完整的 SQL 下推執行;
  • 謂詞下推;
  • 聚合算子優化;
  • JOIN 順序調整。

分析平台性能優化-物化加速

物化加速就是建立一個最終的結果表,把資料計算過程透過ETL 生產直接生產到結果表內。

快手物化加速目前使用的是產生生產任務方式來做資料生產,而非利用OLAP 引擎物化能力。面對不同的應用程式場景,有不同的效能目標,對歷史查詢的圈選也不一樣。

圖片

物化加速過程,首先是物化模型分析,把使用者歷史查詢的指標維度,抽象化成指標維度的模型,找出超過效能目標的指標維度組合,分析其聚合比(聚合後的資料行數和原行數的比率,聚合比越低說明聚合後的行數越少,最終的查詢效果越好)。接下來,對所有這些高熱指標維度物化模型做排序,綜合考慮物化模型的歷史查詢次數以及耗時進行排序,選出一個或幾個收益會比較高的模型來做物化加速生產。

有了需要物化加速的目標模型之後,會自動產生生產任務,然後生產任務進行生產,最終資料落在Hive 或ClickHouse。生產出的結果表,最終也會自動接取分析平台,結果表與指標綁定。

這就是一種數據消費驅動生產的場景。知道數據終端的消費是什麼,然後來做數據生產。使得平均結果表的效能會有50% 的提升。也會帶來效率提升,因為自動產生的生產任務,結果表也會自動接取系統,提升資料生產與存取效率。

(6)引擎的效能優化-湖倉一體OLAP 引擎Bleem

在引擎層面的最佳化,快手的策略是建立統一的湖倉一體化分析引擎Bleem,然後在Bleem 支援高效能的引擎運算能力。其主要的能力建構包括以下幾點:

首先緩存方面,建構不同層級的緩存,包括元資料快取、資料緩存、索引資料快取。其次算子執行方面,有向量化、多執行緒、分散式。以及物化視圖、優化器(RBO&CBO 優化器、針對JOIN 的最佳化)。

圖片

Bleem 是快手正在推廣使用的湖倉一體引擎。其定位不是為了替換ClickHouse,ClickHouse 已經滿足許多需求。湖倉一體引擎Bleem 會對ClickHouse 的一些痛點問題進行最佳化,例如join 的優化,RBO&CBO 的優化。另外,Bleem 直接面向資料湖,主要目的是提升資料湖的分析效率,最終目標是達到接近ClickHouse 的效能。這樣資料分析就可以直接從資料湖進行,避免一些資料生產的消耗。

4.未來展望

以上介紹了分析場景的效能最佳化實務。總結下來,性能優化是需要團隊協同作戰,才能實現最終面向用戶高效分析,例如分析診斷、查詢優化、物化加速、緩存預熱、數倉建設、引擎優化等等。對於未來發展方向,數據分析有一個永恆的議題就是極致的分析效能,未來一定是軟硬結合來進行最佳化。最終的願景目標是能夠從問題發現、分析、優化能夠全鏈路自動化/智慧化,進而減少人力投入,又能提供高效數據分析。

5.問答環節

Q1:關於Bleem 有沒有跟社群合作的一些發展計劃,例如開源。

A1:了解到目前還沒有,這還在持續優化迭代過程中。

Q2:Bleem 在生態圈裡屬於哪一層?

A2:資料湖的一個分析引擎。

Q3:物化優化能不能優化跨表JOIN?

A3:可以的。物化有兩種模式,一種是聚合模式,另一種是全量模式,主要是優化JOIN。

責任編輯:薑華來源: DataFunTalk