本文導(dǎo)讀：

當(dāng)前，大語(yǔ)言模型的應(yīng)用正在全球范圍內(nèi)引發(fā)新一輪的技術(shù)革命與商業(yè)浪潮。騰訊音樂(lè)作為中國(guó)領(lǐng)先在線音樂(lè)娛樂(lè)平臺(tái)，利用龐大用戶(hù)群與多元場(chǎng)景的優(yōu)勢(shì)，持續(xù)探索大模型賽道的多元應(yīng)用。本文將詳細(xì)介紹騰訊音樂(lè)如何基于 Apache Doris 構(gòu)建查詢(xún)高效、實(shí)時(shí)統(tǒng)一分析的 OLAP 引擎，使 OLAP 作為底層基建加強(qiáng)模型連接轉(zhuǎn)化效率、結(jié)果輸出準(zhǔn)確率，最終將大模型 + OLAP 引擎結(jié)合為用戶(hù)提供個(gè)性化、實(shí)時(shí)化、靈活化的智能數(shù)據(jù)服務(wù)平臺(tái)。

作者｜騰訊音樂(lè)大數(shù)據(jù)架構(gòu)師?張俊、羅雷

騰訊音樂(lè)娛樂(lè)集團(tuán)（以下簡(jiǎn)稱(chēng)“騰訊音樂(lè)”）是中國(guó)在線音樂(lè)娛樂(lè)服務(wù)開(kāi)拓者，有著廣泛的用戶(hù)基礎(chǔ)，總月活用戶(hù)數(shù)超過(guò) 8 億，通過(guò)“一站式”的音樂(lè)娛樂(lè)平臺(tái)，用戶(hù)可以在多場(chǎng)景間無(wú)縫切換并享受多元的音樂(lè)服務(wù)。我們希望通過(guò)技術(shù)和數(shù)據(jù)賦能，為用戶(hù)帶來(lái)更好的體驗(yàn)，為音樂(lè)人和合作伙伴在音樂(lè)制作、發(fā)行、銷(xiāo)售等方面提供支持。

基于公司豐富的音樂(lè)內(nèi)容資產(chǎn)，需要將歌曲庫(kù)、藝人資訊、專(zhuān)輯信息、廠牌信息等大量數(shù)據(jù)進(jìn)行統(tǒng)一存儲(chǔ)形成音樂(lè)內(nèi)容數(shù)據(jù)倉(cāng)庫(kù)，并通過(guò)產(chǎn)品工具為業(yè)務(wù)人員提供數(shù)據(jù)分析服務(wù)。在內(nèi)容數(shù)倉(cāng)搭建的過(guò)程中，我們的工作始終圍繞降本增效為主要目的進(jìn)行優(yōu)化與迭代，希望在數(shù)據(jù)服務(wù)方面不斷提升產(chǎn)品工具的開(kāi)發(fā)與分析效率，同時(shí)在數(shù)倉(cāng)架構(gòu)方面能夠有效減少架構(gòu)成本與資源開(kāi)銷(xiāo)。

在傳統(tǒng)數(shù)據(jù)服務(wù)中，我們?yōu)闃I(yè)務(wù)分析師提供了多種數(shù)據(jù)服務(wù)，包括 SQL 查詢(xún)、固定看板、定制化的分析工具以及人工跑數(shù)。然而，在實(shí)際應(yīng)用過(guò)程中仍然存在一定痛點(diǎn)：

• SQL 查詢(xún)平臺(tái) ： 業(yè)務(wù)分析師根據(jù)需求進(jìn)行 SQL 語(yǔ)句編寫(xiě)，對(duì)平臺(tái)數(shù)據(jù)進(jìn)行查詢(xún)分析，每位業(yè)務(wù)人員都需要掌握 SQL，導(dǎo)致學(xué)習(xí)成本高、上手難度大。
• 固定看板（Dashboard） ： 技術(shù)人員基于常規(guī)業(yè)務(wù)開(kāi)發(fā)制作數(shù)據(jù)看板，雖然能夠簡(jiǎn)化業(yè)務(wù)分析師查詢(xún)的過(guò)程，但是看板制作成本高且靈活度低，當(dāng)面對(duì)復(fù)雜的用戶(hù)問(wèn)題時(shí)，看板無(wú)法及時(shí)調(diào)整以滿足需求變更。
• 定制分析工具： 基于特定的業(yè)務(wù)需求，技術(shù)人員需要定制化開(kāi)發(fā)產(chǎn)品分析工具，整體開(kāi)發(fā)成本過(guò)高，且單一的開(kāi)發(fā)工具不具備通用性，隨著工具數(shù)量增加，操作介面變得散亂，從而降低業(yè)務(wù)效率。
• 人工跑數(shù)： 當(dāng)以上三個(gè)場(chǎng)景都無(wú)法滿足業(yè)務(wù)需求時(shí)，業(yè)務(wù)分析師需要向技術(shù)人員提需求進(jìn)行人工跑數(shù)，溝通成本過(guò)高、整體解決效率低下。

隨著行業(yè)發(fā)展趨勢(shì)，LLMs 大語(yǔ)言模型（LLMs - Large Language Models，以下統(tǒng)一簡(jiǎn)稱(chēng)為大模型）出現(xiàn)有效地解決了這些問(wèn)題。當(dāng)平臺(tái)融入大模型后，平臺(tái)用戶(hù)輸入的問(wèn)題會(huì)進(jìn)入大模型進(jìn)行語(yǔ)義解析，自動(dòng)轉(zhuǎn)化為 SQL 語(yǔ)句觸發(fā) OLAP 引擎開(kāi)啟數(shù)據(jù)分析與查詢(xún)。通過(guò)平臺(tái)智能問(wèn)答交互的方式，業(yè)務(wù)分析師不再需要依靠人工編寫(xiě) SQL 提供查詢(xún)分析結(jié)果，技術(shù)人員也不需要再制作過(guò)于固定或者過(guò)于定制化的產(chǎn)品工具。大模型 + OLAP 引擎結(jié)合的全新數(shù)據(jù)服務(wù)模式，不僅為平臺(tái)用戶(hù)提供了個(gè)性化、靈活表達(dá)、秒級(jí)回復(fù)的服務(wù)體驗(yàn)，還大幅降低了企業(yè)內(nèi)部技術(shù)與業(yè)務(wù)學(xué)習(xí)成本，加速數(shù)據(jù)分析效率，實(shí)現(xiàn)多端入口統(tǒng)一、界面統(tǒng)一的平臺(tái)構(gòu)建。

本文將詳細(xì)介紹騰訊音樂(lè)如何基于 Apache Doris 構(gòu)建查詢(xún)高效、實(shí)時(shí)寫(xiě)入且統(tǒng)一的 OLAP 分析引擎，使 OLAP 作為底層基建加強(qiáng)大模型與之連接轉(zhuǎn)化的效率、結(jié)果輸出的準(zhǔn)確率，最終提供更智能化的問(wèn)答交互服務(wù)，也希望通過(guò)這篇文章為有相關(guān)業(yè)務(wù)需求的公司提供不同視角和思路。

大模型 + OLAP ：開(kāi)啟數(shù)據(jù)服務(wù)平臺(tái)新模式

---

在大模型 + OLAP 架構(gòu)方案中，目前經(jīng)典方案如下圖所示，大模型充當(dāng)中間層將用戶(hù)輸入的自然語(yǔ)言轉(zhuǎn)化為 SQL 執(zhí)行語(yǔ)句，OLAP 作為底層存儲(chǔ)和數(shù)據(jù)處理的引擎，負(fù)責(zé)接受和執(zhí)行從大模型發(fā)送過(guò)來(lái)的 SQL 語(yǔ)句，對(duì)數(shù)據(jù)進(jìn)行預(yù)聚合、多維分析等操作，滿足大規(guī)模數(shù)據(jù)集的查詢(xún)分析需求。

然而，這種架構(gòu)在實(shí)際落地過(guò)程中也面臨一定挑戰(zhàn)，例如語(yǔ)義理解的準(zhǔn)確性、查詢(xún)效率的優(yōu)化、私域知識(shí)的理解等方面，具體如下：

• 復(fù)雜數(shù)據(jù)口徑不統(tǒng)一： 大模型對(duì)于技術(shù)方面的詞匯，如字段、行列、表等無(wú)法理解，相反對(duì)于業(yè)務(wù)方面的詞匯，如公司收入情況、日活躍用戶(hù)數(shù)量等能夠提供有效翻譯與轉(zhuǎn)換。因此挑戰(zhàn)之一是需要思考如何引導(dǎo)用戶(hù)進(jìn)入指標(biāo)范圍內(nèi)提問(wèn)，挑戰(zhàn)之二是當(dāng)用戶(hù)存在對(duì)多種指標(biāo)、多類(lèi)指標(biāo)查詢(xún)時(shí)，需要考慮如何保持指標(biāo)維度口徑的統(tǒng)一、如何有效生成對(duì)應(yīng)的指標(biāo)計(jì)算公式。
• 模型處理效率較低： 現(xiàn)階段大模型雖然支持交互能力，但推理速度較慢，需要花費(fèi)十秒級(jí)以上響應(yīng)，用戶(hù)每增加一個(gè)問(wèn)題輸入，就需要花費(fèi)更多等待時(shí)間，使服務(wù)質(zhì)量降低。同時(shí)大模型整體按照 Token 收費(fèi)，使用量增加時(shí)也會(huì)導(dǎo)致平臺(tái)成本升高。
• 私域知識(shí)無(wú)法識(shí)別： 雖然大模型已經(jīng)開(kāi)展許多公開(kāi)數(shù)據(jù)集的語(yǔ)言轉(zhuǎn)換訓(xùn)練，但面對(duì)企業(yè)內(nèi)部的大量專(zhuān)業(yè)術(shù)語(yǔ)仍無(wú)法很好地理解轉(zhuǎn)化。以音樂(lè)內(nèi)容數(shù)據(jù)庫(kù)為例，大模型時(shí)常缺少對(duì)于某些冷門(mén)歌曲的認(rèn)知，在問(wèn)答過(guò)程中無(wú)法正確給出交互反饋，因此我們需要增強(qiáng)大模型對(duì)于私域知識(shí)的理解。
• 定制場(chǎng)景無(wú)法滿足： 大模型主要依據(jù)自身數(shù)據(jù)集進(jìn)行回答，會(huì)出現(xiàn)“知識(shí)幻覺(jué)”（輸出缺乏依據(jù)的內(nèi)容）問(wèn)題，我們需要允許第三方插件的接入使大模型得以聯(lián)網(wǎng)，讓用戶(hù)借助內(nèi)部插件完成更定制化、更多樣的任務(wù)。因此如何接入、匹配并觸發(fā)組件功能是我們的重點(diǎn)優(yōu)化目標(biāo)。

面對(duì)經(jīng)典方案中的落地難點(diǎn)，我們的總體解決思路是將以上四大挑戰(zhàn)逐一拆解，通過(guò)組件疊加分階段完善大模型 + OLAP 架構(gòu)構(gòu)建，最終實(shí)現(xiàn)全新的交互問(wèn)答服務(wù)模式，接下來(lái)我們將介紹各階段挑戰(zhàn)對(duì)應(yīng)的解決方案。

01 增加語(yǔ)義層：處理復(fù)雜數(shù)據(jù)問(wèn)題

為了解決復(fù)雜數(shù)據(jù)處理問(wèn)題，我們?cè)诖竽Ｐ团c OLAP 中間增加 Semantic Layer（以下簡(jiǎn)稱(chēng)語(yǔ)義層）。

一方面語(yǔ)義層作為連接技術(shù)與業(yè)務(wù)之間的轉(zhuǎn)換橋梁，能夠?qū)?shù)據(jù)字段翻譯為業(yè)務(wù)用戶(hù)的術(shù)語(yǔ)，使業(yè)務(wù)知識(shí)作為額外的抽象層。通過(guò)語(yǔ)義層，業(yè)務(wù)分析師不需要在定義指標(biāo)后存儲(chǔ)于 OLAP 數(shù)倉(cāng)中，能夠直接在語(yǔ)義層中指定過(guò)濾條件，將所需指標(biāo)篩選后生成 SQL 語(yǔ)句并在 OLAP 中進(jìn)行字段查詢(xún)。這意味著，業(yè)務(wù)分析師能夠把多源數(shù)據(jù)按照需求定義成語(yǔ)義信息并形成語(yǔ)義標(biāo)準(zhǔn)，有效解決了多種指標(biāo)、多類(lèi)維度計(jì)算口徑不統(tǒng)一的挑戰(zhàn)。

另一方面語(yǔ)義層能夠針對(duì)業(yè)務(wù)計(jì)算邏輯，進(jìn)行語(yǔ)義加工、描述、關(guān)聯(lián)和運(yùn)算。語(yǔ)義層在過(guò)濾數(shù)據(jù)后，能夠屏蔽由表關(guān)聯(lián)所產(chǎn)生的復(fù)雜指標(biāo)計(jì)算公式，將多表 Join 場(chǎng)景進(jìn)行拆解、轉(zhuǎn)化，形成較為簡(jiǎn)單的單表查詢(xún)，以提升語(yǔ)義轉(zhuǎn)化的準(zhǔn)確性。

02 設(shè)定人工經(jīng)驗(yàn)：處理模型效率問(wèn)題

針對(duì)模型效率問(wèn)題，我們的解決思路是對(duì)指標(biāo)計(jì)算、明細(xì)查詢(xún)、人群圈選等查詢(xún)場(chǎng)景進(jìn)行復(fù)雜度判定，將簡(jiǎn)單查詢(xún)場(chǎng)景直接跳過(guò)大模型解析的步驟，進(jìn)入底層 OLAP 進(jìn)行處理分析，使大模型更加專(zhuān)注處理復(fù)雜查詢(xún)場(chǎng)景。

為此，如上圖所示我們?cè)谀Ｐ椭刑砑尤斯そ?jīng)驗(yàn)判斷。當(dāng)業(yè)務(wù)分析師輸入 “查詢(xún)各大音樂(lè)平臺(tái)收入”問(wèn)題時(shí)，模型依據(jù)判定規(guī)則發(fā)現(xiàn)該場(chǎng)景只需要提供某個(gè)指標(biāo)或幾個(gè)維度即可完成，這時(shí)不需要將問(wèn)題進(jìn)入大模型解析，直接使用 OLAP 進(jìn)行查詢(xún)分析，能夠有效縮短響應(yīng)時(shí)間，提升結(jié)果反饋效率。此外，跳過(guò)大模型解析的步驟也能夠節(jié)省 API 調(diào)用經(jīng)費(fèi)，解決平臺(tái)使用成本升高的問(wèn)題。

03 增加內(nèi)容映射：處理私域知識(shí)問(wèn)題

針對(duì)私域知識(shí)的問(wèn)題，我們?cè)诖竽Ｐ蜕嫌卧黾?Schema Mapper 、在外部建立業(yè)務(wù)知識(shí)庫(kù)，將平臺(tái)用戶(hù)的問(wèn)題與知識(shí)庫(kù)進(jìn)行連接，通過(guò) Schema Mapper 判定是否存在部份文字能夠與知識(shí)庫(kù)內(nèi)容匹配。如果匹配成功，大模型將進(jìn)一步解析轉(zhuǎn)化、OLAP 分析處理。Schema Mapper 與業(yè)務(wù)知識(shí)庫(kù)的引入，有效解決了大模型對(duì)私域知識(shí)理解不足的問(wèn)題，提升語(yǔ)言處理的效果。

目前，我們正在不斷對(duì) Schema Mapper 匹配準(zhǔn)確性進(jìn)行測(cè)試與優(yōu)化，將知識(shí)庫(kù)中的內(nèi)容進(jìn)行分類(lèi)處理、字段評(píng)級(jí)等操作，同時(shí)將輸入文本進(jìn)行不同范圍的內(nèi)容映射（如全文本映射與模糊映射），通過(guò)映射結(jié)果來(lái)加強(qiáng)模型語(yǔ)義解析的能力。

04 插件接入：處理定制場(chǎng)景問(wèn)題

定制化場(chǎng)景主要指代業(yè)務(wù)范圍之外的查詢(xún)需求，需要將音樂(lè)內(nèi)容數(shù)據(jù)與法律、政治、金融、監(jiān)管等方面信息結(jié)合提供問(wèn)答服務(wù)。通過(guò)增加插件，使平臺(tái)用戶(hù)能夠訪問(wèn)實(shí)時(shí)更新且無(wú)法包含在訓(xùn)練數(shù)據(jù)或業(yè)務(wù)知識(shí)庫(kù)中的信息，以實(shí)現(xiàn)定制化交互。

由于插件類(lèi)型不同，模型接入方式也會(huì)有所不同，常見(jiàn)的接入方式主要分為兩種：

• Embedding 本地文本接入： 該方式首先對(duì)本地文檔進(jìn)行向量化處理，通過(guò)語(yǔ)義向量搜索，找到本地文檔中相關(guān)或者相似的詞語(yǔ)進(jìn)行匹配，之后將文檔內(nèi)容注入大模型解析窗口中生成答案。這種方式非常適合業(yè)務(wù)分析師希望將音樂(lè)內(nèi)容數(shù)據(jù)庫(kù)與最新政策等一類(lèi)較為私有的文件結(jié)合完成查詢(xún)需求。
• ChatGPT 第三方插件接入： 每款插件具備對(duì)應(yīng)的 Prompt 與調(diào)用函數(shù)。業(yè)務(wù)人員在安裝某款插件之后，在與模型對(duì)話中可以通過(guò) Prompt 詞觸發(fā)函數(shù)開(kāi)啟調(diào)用。目前第三方插件類(lèi)型豐富，涉及行業(yè)廣泛，能夠有效增加多元場(chǎng)景的處理與響應(yīng)能力。

超音數(shù)平臺(tái)框架構(gòu)思

---

根據(jù)上述大模型 + OLAP 的四大解決方案進(jìn)行了方案整合，以此進(jìn)行框架設(shè)計(jì)并將其命名為超音數(shù)平臺(tái)。大模型主要作用于自然語(yǔ)言與 SQL 分析語(yǔ)句的連接與轉(zhuǎn)化，OLAP 引擎則作為數(shù)據(jù)存儲(chǔ)與查詢(xún)分析的核心基建。

超音數(shù)平臺(tái)對(duì)于業(yè)務(wù)流程如圖所示，模型運(yùn)轉(zhuǎn)具體過(guò)程如下：

• 用戶(hù)輸入問(wèn)題通過(guò) Schema Mapper 檢索，判定字段是否匹配與業(yè)務(wù)知識(shí)庫(kù)。
• 如若匹配則跳過(guò)大模型解析步驟，直接利用知識(shí)庫(kù)中的指標(biāo)計(jì)算公式觸發(fā) OLAP 進(jìn)行查詢(xún)分析；如若不匹配則進(jìn)入大模型，開(kāi)啟下一步判定。
• 大模型首先通過(guò)人工經(jīng)驗(yàn)判定問(wèn)題復(fù)雜度，簡(jiǎn)單查詢(xún)將指定 OLAP 引擎直接分析，復(fù)雜查詢(xún)則開(kāi)啟語(yǔ)義解析形成 DSL 語(yǔ)句。
• DSL 語(yǔ)句通過(guò)語(yǔ)義層進(jìn)一步過(guò)濾、拆解關(guān)聯(lián)查詢(xún)場(chǎng)景，生成簡(jiǎn)易單表 SQL 語(yǔ)句以觸發(fā) OLAP 數(shù)據(jù)處理與查詢(xún)加速。
• 針對(duì)需要與外部信息結(jié)合的查詢(xún)場(chǎng)景，大模型會(huì)判斷是否調(diào)用第三方插件來(lái)輔助完成查詢(xún)。

以“某首歌曲能否在綜藝節(jié)目播出”為例，在經(jīng)過(guò)檢索匹配、語(yǔ)義解析后，大模型選擇利用 OLAP 數(shù)據(jù)查詢(xún)與第三方版權(quán)行業(yè)插件結(jié)合的方式進(jìn)行回答，最終呈現(xiàn)結(jié)果由數(shù)倉(cāng)中的歌曲信息與插件判定結(jié)果構(gòu)成。

如今，業(yè)務(wù)分析師只需要在超音數(shù)平臺(tái)中定義指標(biāo)含義、維度類(lèi)型即可直接開(kāi)展自然語(yǔ)言的問(wèn)答交互服務(wù)。同時(shí)還可以在平臺(tái)中內(nèi)置插件、豐富指標(biāo)市場(chǎng)來(lái)拓展語(yǔ)義解析能力，完全覆蓋了業(yè)務(wù)在常規(guī)與定制化場(chǎng)景下的查詢(xún)需求。平臺(tái)基于大模型 + OLAP 的模式加速業(yè)務(wù)分析效率，減少技術(shù)開(kāi)發(fā)成本，向智能化、個(gè)性化、實(shí)時(shí)化的全新業(yè)務(wù)服務(wù)模式更近一步。

在這里希望可以與大家分享該開(kāi)源項(xiàng)目，讓更多人體驗(yàn)和學(xué)習(xí)大模型構(gòu)建，也歡迎感興趣的讀者們共同參與大模型開(kāi)發(fā)與建設(shè)。

超音數(shù)開(kāi)源框架：https://github.com/tencentmusic/supersonic

超音數(shù)平臺(tái)框架演進(jìn)

---

在平臺(tái)構(gòu)建的過(guò)程中，OLAP 引擎作為整體架構(gòu)的基建對(duì) SQL 語(yǔ)句處理、數(shù)據(jù)存儲(chǔ)分析、上游應(yīng)用層的查詢(xún)響應(yīng)等有著至關(guān)重要的作用，我們希望通過(guò)架構(gòu)升級(jí)以加強(qiáng)大模型到 OLAP 引擎的轉(zhuǎn)化效率與結(jié)果輸出準(zhǔn)確性。

接下來(lái)我們將對(duì)比介紹 OLAP 早期架構(gòu)與新一代架構(gòu)在數(shù)據(jù)寫(xiě)入與查詢(xún)兩方面的差異，分享在架構(gòu)演進(jìn)過(guò)程中大模型 + OLAP 模型優(yōu)化歷程，最終助力超音數(shù)平臺(tái)的構(gòu)建，開(kāi)啟新一代的數(shù)據(jù)服務(wù)模式。

01 數(shù)據(jù)架構(gòu) 1.0

我們初期的業(yè)務(wù)架構(gòu)如上圖所示，分為處理層、分析層、應(yīng)用層三部份，用戶(hù)文本在進(jìn)入大模型之后解析為 SQL 語(yǔ)句使 OLAP 開(kāi)始執(zhí)行任務(wù)，具體的工作原理如下：

• 處理層：在 ODS- DWD- DWS 三層中將數(shù)據(jù)整合為不同主題的標(biāo)簽和指標(biāo)體系之后，通過(guò)對(duì) DWS 調(diào)度與采集所需字段，在 DWM 層將維度與指標(biāo)數(shù)據(jù)加工成大寬表。
• 分析層：通過(guò)大寬表進(jìn)入分析層，將數(shù)據(jù)導(dǎo)入 Clickhouse 與 Elasticsearch，其中 Clickhosue 主要負(fù)責(zé)維度與指標(biāo)兩類(lèi)數(shù)據(jù)的查詢(xún)加速，作為分析引擎為后續(xù)提供報(bào)表開(kāi)發(fā)服務(wù)；Elasticsearch 主要負(fù)責(zé)維度數(shù)據(jù)處理，作為搜索/圈選引擎。
• 應(yīng)用層：業(yè)務(wù)人員基于場(chǎng)景選取所需要的標(biāo)簽與指標(biāo)，在應(yīng)用層中創(chuàng)建數(shù)據(jù)集作為邏輯視圖，同時(shí)可以二次定義衍生的標(biāo)簽與指標(biāo)。

在實(shí)際業(yè)務(wù)使用中，早期架構(gòu)的數(shù)據(jù)處理方式存在大寬表帶來(lái)的數(shù)據(jù)延遲與存儲(chǔ)浪費(fèi)、多套組件導(dǎo)致架構(gòu)冗余帶來(lái)指標(biāo)維度重復(fù)定義、學(xué)習(xí)與運(yùn)維成本高等問(wèn)題，具體如下：

• 數(shù)據(jù)延遲： 處理層不支持部分列表更新，DWS 層數(shù)據(jù)寫(xiě)入產(chǎn)生延遲后會(huì)造成大寬表的延遲，進(jìn)而導(dǎo)致數(shù)據(jù)時(shí)效性下降。
• 運(yùn)維成本高： 在處理層大寬表中維度數(shù)據(jù)量平均占一張大寬表的 50%，且在大部份情況下變化緩慢，這意味著每一張寬表的開(kāi)發(fā)會(huì)將維度數(shù)據(jù)疊加，造成存儲(chǔ)資源的浪費(fèi)、維護(hù)成本增加；在分析層中存在多引擎使用的問(wèn)題，查詢(xún) SQL 語(yǔ)句需要同時(shí)適配 Clickhouse 與 Elasticsearch 兩個(gè)組件，增加人力成本，且兩套組件也會(huì)加大運(yùn)維難度，運(yùn)維成本進(jìn)一步升高。
• 架構(gòu)冗余： 在應(yīng)用層進(jìn)行指標(biāo)與維度定義時(shí)，導(dǎo)致相同數(shù)據(jù)會(huì)進(jìn)行多次定義使各種指標(biāo)、維度定義口徑不一致，造成權(quán)限不可控，例如上圖所示的 T1 （標(biāo)簽）與 M1 （維度）在應(yīng)用層中，被不同數(shù)據(jù)集多次定義。

02 數(shù)據(jù)架構(gòu) 2.0

基于以上問(wèn)題，我們開(kāi)始對(duì)架構(gòu)進(jìn)行改造升級(jí)，并在眾多 OLAP 引擎中選擇了 Apache Doris 來(lái)替換原有組件，主要因?yàn)?Apache Doris 具備以下核心優(yōu)勢(shì)：

• 實(shí)時(shí)導(dǎo)入： ?Apache Doris 能夠支持海量業(yè)務(wù)數(shù)據(jù)的高吞吐實(shí)時(shí)寫(xiě)入，時(shí)效性可以做到秒級(jí)完成導(dǎo)入。
• 引擎統(tǒng)一： 支持 Multi-Catalog 功能，能夠通過(guò) Elasticsearch Catalog 外表查詢(xún)，實(shí)現(xiàn)查詢(xún)出口統(tǒng)一，查詢(xún)層架構(gòu)實(shí)現(xiàn)鏈路極簡(jiǎn)，維護(hù)成本也大幅降低。
• 查詢(xún)分析性能： Apache Doris 是 MPP 架構(gòu)，支持大表分布式 Join，其倒排索引、物化視圖、行列混存等功能使查詢(xún)分析性能更加高效極速。

在數(shù)據(jù)架構(gòu) 2.0 版本中，數(shù)據(jù)架構(gòu)保留處理層部份，主要升級(jí)分析層架構(gòu)，并進(jìn)行了語(yǔ)義層疊加：

• 分析層：引入 Apache Doris 替換 Clickhouse 組件，利用 Doris 的 Elasticsearch Catalog 功能對(duì) Elasticsearch 外表進(jìn)行查詢(xún)，實(shí)現(xiàn)查詢(xún)出口統(tǒng)一；
• 語(yǔ)義層：應(yīng)用層不再需要?jiǎng)?chuàng)建數(shù)據(jù)集視圖，直接通過(guò)語(yǔ)義層獲取指標(biāo)與標(biāo)簽內(nèi)容執(zhí)行查詢(xún)?nèi)蝿?wù)，有效解決標(biāo)簽與指標(biāo)口徑問(wèn)題。

03 數(shù)據(jù)架構(gòu) 3.0

由于寬表開(kāi)發(fā)過(guò)程中，維度數(shù)據(jù)一般變化較小、字符存儲(chǔ)空間較大，且分析查詢(xún)一般只需要查詢(xún)最新的維度數(shù)據(jù)。在這種情況下，如果不斷疊加維度數(shù)據(jù)制作寬表，會(huì)造成存儲(chǔ)空間浪費(fèi)的問(wèn)題，同時(shí)查詢(xún)響應(yīng)速度也受到影響。

為了進(jìn)一步提升架構(gòu)性能，數(shù)據(jù)架構(gòu) 3.0 主要將處理層中大寬表進(jìn)行拆分，同時(shí)將分析層統(tǒng)一使用 Apache Doris 作為查詢(xún)分析引擎：

• 處理層：按照業(yè)務(wù)分類(lèi)在 DWM 中將大寬表拆分成緩慢維度表與指標(biāo)表，使兩類(lèi)表在本地 Hive 中進(jìn)行關(guān)聯(lián)，通過(guò) Hive 導(dǎo)入 Apache Doris 分析層中加速任務(wù)；
• 分析層：將關(guān)聯(lián)數(shù)據(jù)表直接導(dǎo)入 Apache Doris 中，結(jié)合語(yǔ)義層暴露指標(biāo)與維度以實(shí)現(xiàn)語(yǔ)義統(tǒng)一，用戶(hù)只需要通過(guò)過(guò)濾條件就能夠直接查詢(xún)數(shù)據(jù)，得到所需要的結(jié)果。

04 數(shù)據(jù)架構(gòu) 4.0

我們延續(xù)了 3.0 架構(gòu)中分析層統(tǒng)一的優(yōu)勢(shì)，對(duì)處理層、分析層、語(yǔ)義層架構(gòu)進(jìn)一步優(yōu)化，使查詢(xún)性能顯著提升：

• 分析層 + 處理層：數(shù)倉(cāng) DWD 層數(shù)據(jù)采用 ?Rollup 功能使事實(shí)表與維度表實(shí)時(shí)關(guān)聯(lián)并創(chuàng)建多個(gè)視圖進(jìn)入 DWS 中。通過(guò)這種方式，分析層與處理層中的各類(lèi)指標(biāo)數(shù)據(jù)無(wú)需再重復(fù)定義，能夠基于 Apache Doris 全部寫(xiě)入新建的 Rollup 視圖中并利用GROUP BY將維度傳入視圖進(jìn)行查詢(xún)加速，直接對(duì)外暴露所需數(shù)據(jù)。
• 語(yǔ)義層：利用 Apache Doris 物化視圖對(duì)指標(biāo)與維度自定義口徑，通過(guò)語(yǔ)義物化層進(jìn)行查詢(xún)加速，并將指標(biāo)與維度通過(guò)?SUM?加工開(kāi)發(fā)衍生標(biāo)簽與維度數(shù)據(jù)。
• 應(yīng)用層：利用 Apache Doris 2.0 版本的倒排索引功能，對(duì)現(xiàn)有的索引結(jié)構(gòu)進(jìn)行豐富，滿足了對(duì)知識(shí)庫(kù)進(jìn)行模糊查詢(xún)、等值查詢(xún)和范圍查詢(xún)等場(chǎng)景中的能力，進(jìn)一步加速指標(biāo)、維度查詢(xún)響應(yīng)速度。

數(shù)倉(cāng)架構(gòu)基于 Apache Doris 迭代升級(jí)，最終實(shí)現(xiàn)導(dǎo)入實(shí)時(shí)、引擎統(tǒng)一、查詢(xún)高效的現(xiàn)代化湖倉(cāng) OLAP 引擎，簡(jiǎn)化架構(gòu)鏈路的同時(shí)，有效解決大寬表中指標(biāo)重復(fù)定義所帶來(lái)的問(wèn)題。在架構(gòu)演進(jìn)的過(guò)程，我們也積累許多關(guān)于 Apache Doris 性能優(yōu)化經(jīng)驗(yàn)，希望通過(guò)分享給讀者們帶來(lái)一些參考。

Apach Doris 性能優(yōu)化實(shí)踐

---

01 Colocate Join 寬表優(yōu)化

在上文架構(gòu)改造中我們提及，由于寬表開(kāi)發(fā)會(huì)不斷疊加字符數(shù)據(jù)，消耗存儲(chǔ)空間，降低查詢(xún)性能，因此我們充分利用了 Colocate Join 功能對(duì)寬表拆分、本地關(guān)聯(lián)查詢(xún)加速進(jìn)行優(yōu)化，具體過(guò)程如下：

• 指標(biāo)大寬表：采用 Apache Doris 的 Aggregate Key 模型，使用增量的方式將數(shù)據(jù)覆蓋寫(xiě)入；
• 緩慢維度表：主要通過(guò)?start_date?和?end_date?的設(shè)置進(jìn)行表建設(shè)，同時(shí)利用?end_date?進(jìn)行分區(qū)，當(dāng)我們需要查詢(xún)最新的維度數(shù)據(jù)時(shí)只需要將?end_date?設(shè)置為?‘9999-12-31’?即可。此外我們引用 Doris 2.0 版本中的寫(xiě)時(shí)合并，利用 Unique Key 模型進(jìn)行維度數(shù)據(jù)聚合，使查詢(xún)性能在該場(chǎng)景中得到很大的提升。
• 對(duì)外訪問(wèn)視圖：在指標(biāo)與維度表建設(shè)完成之后，利用?CREAT VIEW?提供統(tǒng)一對(duì)外訪問(wèn)視圖，同時(shí)添加?end_date?條件，使視圖保持最新數(shù)據(jù)的展示。通過(guò)這樣的方式不僅能夠大幅度降低查詢(xún)的復(fù)雜性，還能夠充分利用 Doris 特性實(shí)現(xiàn)查詢(xún)加速。

02 Rollup 解決指標(biāo)膨脹問(wèn)題

寬表拆分為指標(biāo)表與維度表后，我們發(fā)現(xiàn)每一次視圖產(chǎn)生都需要定義多個(gè)指標(biāo)，出現(xiàn)指標(biāo)膨脹的情況。以“歌曲播放量結(jié)算”為例，當(dāng)僅定義單一指標(biāo)時(shí)，我們需要將各個(gè)平臺(tái) + 各類(lèi)內(nèi)容進(jìn)行排列組合，使語(yǔ)義層定義很多指標(biāo)數(shù)據(jù)，造成指標(biāo)數(shù)量過(guò)多。此外這些指標(biāo)都需要通過(guò)離線生產(chǎn)任務(wù)進(jìn)行加工，并通過(guò) Hive 導(dǎo)入至 Apache Doris 中，造成鏈路較長(zhǎng)、加工維護(hù)比較困難。

平臺(tái)指標(biāo)：覆蓋四大音樂(lè)平臺(tái)，包括酷我、QQ 音樂(lè)、酷狗、K 歌內(nèi)容指標(biāo)：包含歌曲、歌手、專(zhuān)輯以及廠牌等數(shù)據(jù)

為了有效解決指標(biāo)膨脹問(wèn)題，我們引入了 Doris Rollup 功能。如圖所示，在 Doris Base 表數(shù)據(jù)基礎(chǔ)之上，可以根據(jù)指定維度來(lái)創(chuàng)建任意多個(gè) Rollup 視圖并自動(dòng)進(jìn)行?GROUP BY?，實(shí)現(xiàn)各個(gè)平臺(tái)與各類(lèi)內(nèi)容指標(biāo)定義不重復(fù)、查詢(xún)性能提升的目標(biāo)。

03 物化視圖實(shí)現(xiàn)查詢(xún)加速

除了減少指標(biāo)數(shù)量外，我們還希望能夠衍生指標(biāo)并且做到查詢(xún)加速。在 Apache Doris 2.0 版本中我們采用了物化視圖功能進(jìn)行衍生指標(biāo)的開(kāi)發(fā)。目前，我們主要在單一維度表中單獨(dú)地去查詢(xún)自定義標(biāo)簽與維度，在定義復(fù)雜口徑后自動(dòng)的通過(guò)語(yǔ)義層物化任務(wù)。

如上圖所示我們將指標(biāo) M1 、M2、M3 與維度 T1、T2、T3 分別進(jìn)行定義，并通過(guò) ?SUM ?加工衍生標(biāo)簽，在加工完成之后創(chuàng)建物化視圖加速查詢(xún)。此外，在 Doris 后續(xù) 2.1 版本中還會(huì)支持多表創(chuàng)建物化視圖，我們也非常期待使用該功能。

Apach Doris 導(dǎo)入性能調(diào)優(yōu)實(shí)踐

---

目前，騰訊音樂(lè)具有 90+ 數(shù)據(jù)來(lái)源表、 3000 + 維度和指標(biāo)、導(dǎo)入數(shù)據(jù)量達(dá)到千億級(jí)別，我們希望數(shù)倉(cāng)能夠支持大規(guī)模數(shù)據(jù)快速導(dǎo)入，且導(dǎo)入過(guò)程中保證數(shù)據(jù)寫(xiě)入的準(zhǔn)確性。

導(dǎo)入鏈路如圖所示，主要分為離線與實(shí)時(shí)兩個(gè)部分，離線鏈路中指標(biāo)表與變更維度表通過(guò) Spark 進(jìn)行批量導(dǎo)入，兩類(lèi)表利用 Flink 聚合形成寬表后寫(xiě)入；實(shí)時(shí)鏈路主要利用 Kafak 消息隊(duì)列進(jìn)行流式寫(xiě)入。最終，離線與實(shí)時(shí)兩條鏈路利用 Flink ?實(shí)時(shí)寫(xiě)入 Apache Doris 數(shù)倉(cāng)中。

由于 Flink 聚合為攢批寫(xiě)入，如果出現(xiàn)寫(xiě)入任務(wù)失敗，會(huì)導(dǎo)致數(shù)據(jù)丟失；同時(shí)，在聚合任務(wù)過(guò)多、字段過(guò)多的情況下存在 Compaction 不及時(shí)的情況，導(dǎo)致實(shí)時(shí)能力不可控；此外在加工寬表的過(guò)程中，也會(huì)造成重復(fù)寫(xiě)入的問(wèn)題，無(wú)法保證數(shù)據(jù)寫(xiě)入準(zhǔn)確性。

在 Apache Doris 2.0 版本發(fā)布后，我們引入了其全新功能 Flink Doris Connector 與 Doris Compaction，有效解決了 Flink 聚合引起的問(wèn)題。

01 Flink Doris Connector 實(shí)現(xiàn)快寫(xiě)入

Flink Doris Connector 主要是依賴(lài) Checkpoint 機(jī)制進(jìn)行流式寫(xiě)入，同時(shí)該功能默認(rèn)開(kāi)啟兩階段提交，保證寫(xiě)入過(guò)程中 Exactly Once 語(yǔ)義。值得注意的是，我們?cè)谝胱钚掳娴?Flink Doris Connector 功能后，實(shí)現(xiàn)了從關(guān)系型數(shù)據(jù)庫(kù)到 Apache Doris 的一鍵整庫(kù)同步，承載了我們實(shí)際業(yè)務(wù)中千億級(jí)別的實(shí)時(shí)并行寫(xiě)入，滿足數(shù)據(jù)快寫(xiě)入與不丟不重的需求。

02 Doris Compaction 保證寫(xiě)入穩(wěn)定性

為了解決 Flink 聚合引起的偶發(fā)性 Compaction 不及時(shí)問(wèn)題，我們引入最新版的 Vertical Compaction 與 Segment Compaction 功能。

• Vertical Compaction 功能優(yōu)勢(shì)： 在單次合并過(guò)程中，我們不需要再將所有的列讀出，只需要加載部份列數(shù)據(jù)即可，這能極大減少合并過(guò)程中的內(nèi)存占用問(wèn)題，提高壓縮的執(zhí)行速度，實(shí)現(xiàn)在大寬表場(chǎng)景下的部份數(shù)據(jù)合并。
• Segment Compaction 功能優(yōu)勢(shì)： 在單批次大數(shù)據(jù)量的導(dǎo)入場(chǎng)景下可以有效減少 Flink 寫(xiě)入過(guò)程中產(chǎn)生的 Segment 數(shù)量，且能夠使合并和導(dǎo)入兩個(gè)過(guò)程并行，避免增加導(dǎo)入時(shí)間。

如上圖所示在引入 Doris Compation 功能后，在寫(xiě)入量增加 50 % 的情況下，Compaction Score 從平均 650 分降低至 80 分，技術(shù)人員不再需要擔(dān)心夜間出現(xiàn)告警的情況，保證了整體鏈路的穩(wěn)定性。

總結(jié)收益與展望

---

在引入 Apache Doris 后，數(shù)據(jù)架構(gòu)圍繞降本增效的目標(biāo)，不僅在寫(xiě)查方面的性能得到大幅度提升，并且有效減少架構(gòu)成本與資源開(kāi)銷(xiāo)，具體的收益如下：

• 極速查詢(xún)分析： 通過(guò) Apache Doris 的 Rollup、物化視圖、倒排索引功能，由原來(lái)的分鐘級(jí)查詢(xún)時(shí)間達(dá)到現(xiàn)如今秒級(jí)毫秒級(jí)；
• 導(dǎo)入性能提升： 導(dǎo)入優(yōu)化完成后，原本 3000+ 維度、指標(biāo)數(shù)據(jù)的導(dǎo)入時(shí)間需要超過(guò)一天，現(xiàn)如今能夠在 8 小時(shí)內(nèi)完成導(dǎo)入，導(dǎo)入時(shí)間縮短至原來(lái)的 1/3，實(shí)現(xiàn)快速導(dǎo)入需求；更重要的是，Apache Doris 在保證數(shù)據(jù)快寫(xiě)入的同時(shí)，使數(shù)據(jù)能夠不丟不重、準(zhǔn)確寫(xiě)入；
• 鏈路極簡(jiǎn)與統(tǒng)一： Apache Doris 將查詢(xún)與分析出口引擎統(tǒng)一，去除 Elasticsearch 集群使架構(gòu)鏈路極簡(jiǎn)；
• 存儲(chǔ)成本降低： 通過(guò)大寬表拆分的方式，使存儲(chǔ)成本降低 30%，開(kāi)發(fā)成本降低 40% 。

在未來(lái)，我們將進(jìn)一步拓展使用 Apache Doris 湖倉(cāng)一體功能，對(duì) Hive、MySQL、數(shù)據(jù)湖等多源異構(gòu)數(shù)據(jù)庫(kù)進(jìn)行網(wǎng)關(guān)統(tǒng)一，實(shí)現(xiàn)真正意義上的實(shí)時(shí)統(tǒng)一分析引擎。同時(shí)，嘗試 CCR 跨集群數(shù)據(jù)同步功能，通過(guò)用戶(hù)多集群的數(shù)據(jù)庫(kù)表自動(dòng)同步以提升在線服務(wù)數(shù)據(jù)的可用性。未來(lái)，我們也將在測(cè)試環(huán)節(jié)中驗(yàn)證讀寫(xiě)負(fù)載分離以及多機(jī)房備份的性能效果。

目前，Apache Doris 社區(qū)已經(jīng)公布了后續(xù)版本中將推出的存算分離全新架構(gòu)，能夠利用低成本的共享存儲(chǔ)系統(tǒng)簡(jiǎn)化上層計(jì)算節(jié)點(diǎn)的復(fù)雜度，使架構(gòu)帶來(lái)巨大的成本經(jīng)濟(jì)優(yōu)勢(shì)。我們也希望能夠進(jìn)一步探索，基于 Apache Doris 本地高速緩存 + 共享存儲(chǔ)系統(tǒng)的混合模式，在保障性能的同時(shí)降低系統(tǒng)存儲(chǔ)開(kāi)銷(xiāo)。

最后，非常感謝 SelectDB 技術(shù)團(tuán)隊(duì)的積極響應(yīng)與專(zhuān)業(yè)解答，希望通過(guò)這篇文章分享大語(yǔ)言模型在互聯(lián)網(wǎng)業(yè)務(wù)中的應(yīng)用，也歡迎更多人參與 Apache Doris 社區(qū)與超音數(shù)平臺(tái)的開(kāi)源框架構(gòu)建。最后，我們也會(huì)持續(xù)參與社區(qū)活動(dòng)，將相關(guān)成果貢獻(xiàn)回饋社區(qū)，希望 Apache Doris 飛速發(fā)展，越來(lái)越好！