一、快手分析產品介紹

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。