一、快手分析產品介紹

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。