一、快手分析產品介紹

KwaiBI 產品是當前快手內部使用的數(shù)據(jù)分析產品，平臺愿景是：致力于通過豐富分析工具產品，打造一站式的數(shù)據(jù)分析平臺，提升數(shù)據(jù)獲取與分析效率。KwaiBI 目前月活達到 1.5W，支持 5W 以上的報表數(shù)，10W 以上的模型，接入 150 多個大大小小的業(yè)務。

KwaiBI 提供 5 種數(shù)據(jù)消費場景，取數(shù)、多維分析、可視化、推送、門戶。其中主要的分析場景是多維分析和可視化。

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

快手分析平臺底層對接多種數(shù)據(jù)源，包括大數(shù)據(jù)存儲各種引擎、傳統(tǒng)的關系型數(shù)據(jù)庫，也支持一些本地文件的數(shù)據(jù)分析。

在使用 KwaiBI 分析平臺做數(shù)據(jù)分析之前，用戶需要將以上這些數(shù)據(jù)源先接入到分析平臺。數(shù)據(jù)接入通常由數(shù)據(jù)內容的建設者（DE/DPM）完成，會對數(shù)據(jù)源進行數(shù)據(jù)建模，即構建表與表之間的關系，通過數(shù)據(jù)建模得到相應的數(shù)據(jù)模型，在此模型之上，構建數(shù)據(jù)集（數(shù)據(jù)集通常是一個業(yè)務域或者一個業(yè)務主題的集合）。在數(shù)據(jù)接入過程中，如果標準化的指標維度會通過指標中臺，進行規(guī)范化管理指標/維度，再直接接入分析平臺。

數(shù)據(jù)接入后，分析平臺提供了一系列的分析能力，如基礎的數(shù)據(jù)分析能力（數(shù)據(jù)明細、數(shù)據(jù)聚合、跨源計算），在基礎的分析之上可以做一些復雜分析，如同環(huán)比、占比、LOD 分析、表計算等?；谶@些強大的分析能力，數(shù)據(jù)的終端消費用戶（DA/運營）通過多維分析和可視化可使用這些能力做分析。

2.快手分析場景性能挑戰(zhàn)

快手大數(shù)據(jù)分析平臺，作為一個數(shù)據(jù)輸出平臺，對于用戶而言，面臨的挑戰(zhàn)主要包括：

性能分析難：不清楚耗時在哪個環(huán)節(jié)，平臺對用戶來說是黑盒的；不了解數(shù)據(jù)消費用戶的查詢特征；性能波動難以歸因。

優(yōu)化門檻高：需要很強的知識背景，很強的專業(yè)領域性，而分析用戶通常是小白用戶無法自己進行分析和優(yōu)化。

平臺方面，也面臨一些挑戰(zhàn)：

分析復雜度高：30%以上的復雜分析，包含同環(huán)比、占比、LOD分析等；

引擎查詢復雜度高：關聯(lián)查詢多、數(shù)據(jù)量大，查詢時間范圍大；

引擎局限性：當前快手主要的引擎是ClickHouse，其對關聯(lián)查詢不友好，SQL優(yōu)化不智能。（每個引擎都有其自身局限性）

3.快手分析場景性能優(yōu)化實踐

（1）打法策略

針對性能分析難的問題，分析平臺通過進行全鏈路埋點，來得知性能耗時到底在哪個環(huán)節(jié)?；谶@些埋點，平臺可對用戶進行查詢畫像分析，從而了解用戶在分析什么指標、在分析什么維度、分析的時間范圍。有了用戶畫像信息后，進一步可構建自主化數(shù)據(jù)集性能診斷分析工具，進行開放式自助的性能分析。

針對優(yōu)化門檻高的問題，分析平臺會對查詢自動優(yōu)化，包括緩存預熱、物化加速、查詢優(yōu)化等各種手段。此外，基于已有的用戶查詢畫像，可以用數(shù)據(jù)消費來驅動數(shù)據(jù)內容，進行相關優(yōu)化。

整體思路主要分為四步，即確定目標、確認團隊（參與方）、性能分析（分析不同場景下性能原因）、制定解決方案并落地。

（2）確定目標

分析性能的目標，是以分析平臺數(shù)據(jù)消費用戶視角來評價分析平臺的性能，主要抽象成三個性能北極星指標：查詢平均耗時、查詢耗時 P90、查詢成功率。針對三個指標，分場景來確定目標值。比如在可視化看板場景下，大多是一些重要數(shù)據(jù)的沉淀，也是一些重要的人在看，所以對性能保障要求相對更高；對于多維分析場景，更自主化，靈活化，用于日常運營，這時性能目標可以定得相對寬松一些。

總的來說，性能目標并沒有一個絕對值，需要根據(jù)公司的業(yè)務場景，各個業(yè)務團隊的分析需求來達成。以指標作為牽引，持續(xù)追蹤對性能優(yōu)化的效果。

（3）確認團隊

分析性能的提升不僅僅是分析平臺的，性能優(yōu)化是需要分析平臺團隊、數(shù)倉團隊以及引擎團隊，三方來進行合作共建，共同保障的。一個完整的分析鏈路包括引擎查詢 以及 分析平臺二次分析計算，其影響因素是多因子的，若僅僅從分析平臺本身做功，只能是把分析平臺內部優(yōu)化做好。但是一些數(shù)據(jù)內容建設質量提升，以及引擎層面計算優(yōu)化，需要三方來進行合作共建。

（4）性能分析

做好性能優(yōu)化，我們首先要明確性能劣化的根因，進而對癥下藥。平臺側希望通過沉淀通用的查詢性能分析工具，來幫助用戶進行自助分析。自助分析的前提要有充分的元數(shù)據(jù)，元數(shù)據(jù)主要是兩類，一個是分析服務的埋點，另外是收集一些物理元數(shù)據(jù)。

結合兩類元數(shù)據(jù)，則可以構建數(shù)據(jù)集的查詢畫像數(shù)據(jù)。這樣就可以了解到，用戶在看哪些高熱的指標維度、使用了哪些高熱表以及通常查詢哪些時間范圍的數(shù)據(jù)，也可以看到分析平臺自己的一些指標，比如緩存命中率以及其它一些內部查詢的耗時，這些都可以根據(jù)元數(shù)據(jù)分析出來。另外，也有一些診斷的規(guī)則合集，這些診斷規(guī)則，主要是一些對查詢性能不友好的規(guī)則?；诋嬒窈鸵?guī)則，最終得到一個診斷結論：數(shù)據(jù)集可能存在哪些數(shù)據(jù)問題、有哪些可以優(yōu)化的空間。常見的性能問題可以基于分析工具來自助分析。

（5）解決方案

基于性能分析的結論，分析平臺側制定體系化的解決方案，推動三個團隊共同建設，達成優(yōu)化目標。分析平臺本身做平臺的性能優(yōu)化，通過比如緩存預熱、物化加速、查詢優(yōu)化等各種手段，優(yōu)化分析平臺的性能。分析平臺為數(shù)倉提供數(shù)據(jù)集的性能診斷，把數(shù)據(jù)集可能存在的問題，直接暴露給數(shù)倉團隊，針對相應問題，來做針對化的數(shù)據(jù)建設優(yōu)化，比如一些高熱查詢可以做聚合表、加索引、做數(shù)據(jù)哈希等。

數(shù)倉做的一些高質量的數(shù)據(jù)，也會接入數(shù)據(jù)平臺，對用戶的體現(xiàn)就是性能和質量的提升。引擎團隊會對分析平臺和數(shù)倉，提供引擎方面的能力支持，也會做持續(xù)的性能優(yōu)化。

以下重點介紹分析平臺側做的一些優(yōu)化策略：

分析平臺性能優(yōu)化-緩存預熱

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

緩存預熱能力構建主要是四部分，預熱觸發(fā)器、預熱計算器、預熱執(zhí)行器、預熱監(jiān)控。

預熱觸發(fā)器判斷什么情況下需要做緩存預熱。比如定時調度，在用戶高峰使用期，提前進行緩存預熱。另外，進行數(shù)據(jù)加速的同時，也要保障數(shù)據(jù)質量。

預熱計算器，計算歷史的哪些查詢、哪些圖表，是值得預熱、有價值的。通過觀察數(shù)據(jù)集的血緣，來知道數(shù)據(jù)是離線生產的還是實時生產的，很顯然實時生產的數(shù)據(jù)不適合做預熱。另外，對于一些固定化的、高熱的圖表做預熱。最終計算到，想要預熱的是哪些圖表，或者哪些用戶歷史查詢。

因為預熱執(zhí)行器預熱的量可能很大，考慮到對服務負載，要加入一些并發(fā)控制，最后把預熱的數(shù)據(jù)放到緩存中。

最后是預熱的監(jiān)控，監(jiān)控緩存預熱的執(zhí)行情況，執(zhí)行耗時以及緩存預熱的緩存命中率。經過緩存預熱建設，可視化看板場景的首屏命中率可達到 90%，非首屏的緩存命中率達到了 30%。

分析平臺性能優(yōu)化-查詢優(yōu)化

查詢的優(yōu)化首先會基于快手開放分析表達式 OAX（快手面向分析場景的統(tǒng)一分析語言，上述所有分析場景都基于 OAX 構建）。即將用戶最終的數(shù)據(jù)分析抽象成 OAX 語言，并對此 OAX 語言進行解析，知道用戶有哪些高級計算，以及哪些是基于模型或者基于物理表的計算，然后會進行一些初級的分析編排。

接著進行 AST 優(yōu)化。AST 的葉子節(jié)點是從引擎來讀取數(shù)據(jù)，但是對于分析平臺來說，有的是面向表，有的是面向模型（基于表與表之間的關系，構建模型）。一個數(shù)據(jù)集可以有多個模型，一個指標在多個模型中都可以支持。其中會進行模型搜索的優(yōu)化，以保障選取的表或模型，是數(shù)據(jù)準確的，同時保障選取的模型，其取數(shù)效率是最優(yōu)的。取到既滿足準確性，又高效率的一個模型。

有了模型后，會把這個模型翻譯成引擎的查詢語言，并在翻譯中，做一些通用的或者 Native 的 SQL 優(yōu)化。

當葉子節(jié)點也是面向引擎的 SQL 的時候，AST 就可以真正的物理編排，物理編排后就可以執(zhí)行了。

快手在查詢優(yōu)化過程中，沉淀了 50 多個通用的 & Native 優(yōu)化規(guī)則包括：

復雜分析查詢下推：占比或者同環(huán)比這些復雜分析，盡量轉換成一個完整的SQL下推執(zhí)行；

謂詞下推；

聚合算子優(yōu)化；

JOIN順序調整。

分析平臺性能優(yōu)化-物化加速

物化加速就是構建一個最終的結果表，把數(shù)據(jù)計算過程通過 ETL 生產直接生產到結果表內。

快手物化加速當前使用的是生成生產任務方式來做數(shù)據(jù)生產，而非利用 OLAP 引擎物化能力。面對不同的應用場景，有不同的性能目標，對歷史查詢的圈選也不一樣。

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

有了需要物化加速的目標模型之后，會自動生成生產任務，然后生產任務進行生產，最終數(shù)據(jù)落到 Hive 或 ClickHouse。生產出的結果表，最終也會自動接入分析平臺，結果表與指標進行綁定。

這就是一種數(shù)據(jù)消費驅動生產的場景。知道數(shù)據(jù)終端的消費是什么，然后來做數(shù)據(jù)生產。使得平均結果表的性能會有 50% 的提升。也會帶來效率提升，因為自動生成的生產任務，結果表也會自動接入系統(tǒng)，提升數(shù)據(jù)生產和接入效率。

（6）引擎的性能優(yōu)化-湖倉一體 OLAP 引擎 Bleem

在引擎層面的優(yōu)化，快手的策略是構建統(tǒng)一的湖倉一體化分析引擎 Bleem，然后在 Bleem 支持高性能的引擎計算能力。其主要的能力建設包括以下幾點：

首先緩存方面，構建不同級別的緩存，包括元數(shù)據(jù)緩存、數(shù)據(jù)緩存、索引數(shù)據(jù)緩存。其次算子執(zhí)行方面，有向量化、多線程、分布式。以及物化視圖、優(yōu)化器（RBO&CBO 優(yōu)化器、針對 JOIN 的優(yōu)化）。

Bleem 是快手正在推廣使用的湖倉一體引擎。其定位不是為了替換 ClickHouse，ClickHouse 已經滿足很多需求。湖倉一體引擎 Bleem 會對 ClickHouse 的一些痛點問題進行優(yōu)化，比如 join 的優(yōu)化，RBO&CBO 的優(yōu)化。另外，Bleem 直接面向數(shù)據(jù)湖，主要目的是提升數(shù)據(jù)湖的分析效率，最終目標是實現(xiàn)接近 ClickHouse 的性能。這樣數(shù)據(jù)分析就可以直接從數(shù)據(jù)湖中進行，避免一些數(shù)據(jù)生產的消耗。

4.未來展望

以上介紹了分析場景的性能優(yōu)化實踐?？偨Y下來，性能優(yōu)化是需要團隊協(xié)同作戰(zhàn)，才能實現(xiàn)最終面向用戶高效分析，例如分析診斷、查詢優(yōu)化、物化加速、緩存預熱、數(shù)倉建設、引擎優(yōu)化等等。對于未來發(fā)展方向，數(shù)據(jù)分析有一個永恒的話題就是極致的分析性能，未來一定是軟硬結合來進行優(yōu)化。最終的愿景目標是能夠從問題發(fā)現(xiàn)、分析、優(yōu)化能夠全鏈路自動化/智能化，進而減少人力投入，又能提供高效數(shù)據(jù)分析。

5.問答環(huán)節(jié)

Q1：關于 Bleem 有沒有跟社區(qū)合作的一些發(fā)展計劃，例如開源。

A1：了解到目前還沒有，這個還在持續(xù)優(yōu)化迭代過程中。

Q2：Bleem 在生態(tài)圈里屬于哪一層？

A2：數(shù)據(jù)湖的一個分析引擎。

Q3：物化優(yōu)化能不能優(yōu)化跨表 JOIN？

A3：可以的。物化有兩種模式，一種是聚合模式，另一種是全量模式，主要是優(yōu)化 JOIN。