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

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

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

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

SQL 查詢平臺：業(yè)務(wù)分析師根據(jù)需求進行 SQL 語句編寫，對平臺數(shù)據(jù)進行查詢分析，每位業(yè)務(wù)人員都需要掌握 SQL，導(dǎo)致學(xué)習(xí)成本高、上手難度大。

固定看板（Dashboard）：技術(shù)人員基于常規(guī)業(yè)務(wù)開發(fā)制作數(shù)據(jù)看板，雖然能夠簡化業(yè)務(wù)分析師查詢的過程，但是看板制作成本高且靈活度低，當面對復(fù)雜的用戶問題時，看板無法及時調(diào)整以滿足需求變更。

定制分析工具：基于特定的業(yè)務(wù)需求，技術(shù)人員需要定制化開發(fā)產(chǎn)品分析工具，整體開發(fā)成本過高，且單一的開發(fā)工具不具備通用性，隨著工具數(shù)量增加，操作介面變得散亂，從而降低業(yè)務(wù)效率。

人工跑數(shù)：當以上三個場景都無法滿足業(yè)務(wù)需求時，業(yè)務(wù)分析師需要向技術(shù)人員提需求進行人工跑數(shù)，溝通成本過高、整體解決效率低下。

隨著行業(yè)發(fā)展趨勢，LLMs 大語言模型（LLMs - Large Language Models，以下統(tǒng)一簡稱為大模型）出現(xiàn)有效地解決了這些問題。當平臺融入大模型后，平臺用戶輸入的問題會進入大模型進行語義解析，自動轉(zhuǎn)化為 SQL 語句觸發(fā) OLAP 引擎開啟數(shù)據(jù)分析與查詢。通過平臺智能問答交互的方式，業(yè)務(wù)分析師不再需要依靠人工編寫 SQL 提供查詢分析結(jié)果，技術(shù)人員也不需要再制作過于固定或者過于定制化的產(chǎn)品工具。大模型 + OLAP 引擎結(jié)合的全新數(shù)據(jù)服務(wù)模式，不僅為平臺用戶提供了個性化、靈活表達、秒級回復(fù)的服務(wù)體驗，還大幅降低了企業(yè)內(nèi)部技術(shù)與業(yè)務(wù)學(xué)習(xí)成本，加速數(shù)據(jù)分析效率，實現(xiàn)多端入口統(tǒng)一、界面統(tǒng)一的平臺構(gòu)建。本文將詳細介紹騰訊音樂如何基于 Apache Doris 構(gòu)建查詢高效、實時寫入且統(tǒng)一的 OLAP 分析引擎，使 OLAP 作為底層基建加強大模型與之連接轉(zhuǎn)化的效率、結(jié)果輸出的準確率，最終提供更智能化的問答交互服務(wù)，也希望通過這篇文章為有相關(guān)業(yè)務(wù)需求的公司提供不同視角和思路。

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

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

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

復(fù)雜數(shù)據(jù)口徑不統(tǒng)一：大模型對于技術(shù)方面的詞匯，如字段、行列、表等無法理解，相反對于業(yè)務(wù)方面的詞匯，如公司收入情況、日活躍用戶數(shù)量等能夠提供有效翻譯與轉(zhuǎn)換。因此挑戰(zhàn)之一是需要思考如何引導(dǎo)用戶進入指標范圍內(nèi)提問，挑戰(zhàn)之二是當用戶存在對多種指標、多類指標查詢時，需要考慮如何保持指標維度口徑的統(tǒng)一、如何有效生成對應(yīng)的指標計算公式。

模型處理效率較低：現(xiàn)階段大模型雖然支持交互能力，但推理速度較慢，需要花費十秒級以上響應(yīng)，用戶每增加一個問題輸入，就需要花費更多等待時間，使服務(wù)質(zhì)量降低。同時大模型整體按照 Token 收費，使用量增加時也會導(dǎo)致平臺成本升高。

私域知識無法識別：雖然大模型已經(jīng)開展許多公開數(shù)據(jù)集的語言轉(zhuǎn)換訓(xùn)練，但面對企業(yè)內(nèi)部的大量專業(yè)術(shù)語仍無法很好地理解轉(zhuǎn)化。以音樂內(nèi)容數(shù)據(jù)庫為例，大模型時常缺少對于某些冷門歌曲的認知，在問答過程中無法正確給出交互反饋，因此我們需要增強大模型對于私域知識的理解。

定制場景無法滿足：大模型主要依據(jù)自身數(shù)據(jù)集進行回答，會出現(xiàn)“知識幻覺”（輸出缺乏依據(jù)的內(nèi)容）問題，我們需要允許第三方插件的接入使大模型得以聯(lián)網(wǎng)，讓用戶借助內(nèi)部插件完成更定制化、更多樣的任務(wù)。因此如何接入、匹配并觸發(fā)組件功能是我們的重點優(yōu)化目標。

面對經(jīng)典方案中的落地難點，我們的總體解決思路是將以上四大挑戰(zhàn)逐一拆解，通過組件疊加分階段完善大模型 + OLAP 架構(gòu)構(gòu)建，最終實現(xiàn)全新的交互問答服務(wù)模式，接下來我們將介紹各階段挑戰(zhàn)對應(yīng)的解決方案。01增加語義層：處理復(fù)雜數(shù)據(jù)問題

為了解決復(fù)雜數(shù)據(jù)處理問題，我們在大模型與 OLAP 中間增加 Semantic Layer（以下簡稱語義層）。一方面語義層作為連接技術(shù)與業(yè)務(wù)之間的轉(zhuǎn)換橋梁，能夠?qū)?shù)據(jù)字段翻譯為業(yè)務(wù)用戶的術(shù)語，使業(yè)務(wù)知識作為額外的抽象層。通過語義層，業(yè)務(wù)分析師不需要在定義指標后存儲于 OLAP 數(shù)倉中，能夠直接在語義層中指定過濾條件，將所需指標篩選后生成 SQL 語句并在 OLAP 中進行字段查詢。這意味著，業(yè)務(wù)分析師能夠把多源數(shù)據(jù)按照需求定義成語義信息并形成語義標準，有效解決了多種指標、多類維度計算口徑不統(tǒng)一的挑戰(zhàn)。另一方面語義層能夠針對業(yè)務(wù)計算邏輯，進行語義加工、描述、關(guān)聯(lián)和運算。語義層在過濾數(shù)據(jù)后，能夠屏蔽由表關(guān)聯(lián)所產(chǎn)生的復(fù)雜指標計算公式，將多表 Join 場景進行拆解、轉(zhuǎn)化，形成較為簡單的單表查詢，以提升語義轉(zhuǎn)化的準確性。02設(shè)定人工經(jīng)驗：處理模型效率問題

針對模型效率問題，我們的解決思路是對指標計算、明細查詢、人群圈選等查詢場景進行復(fù)雜度判定，將簡單查詢場景直接跳過大模型解析的步驟，進入底層 OLAP 進行處理分析，使大模型更加專注處理復(fù)雜查詢場景。

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

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

針對私域知識的問題，我們在大模型上游增加 Schema Mapper 、在外部建立業(yè)務(wù)知識庫，將平臺用戶的問題與知識庫進行連接，通過 Schema Mapper 判定是否存在部份文字能夠與知識庫內(nèi)容匹配。如果匹配成功，大模型將進一步解析轉(zhuǎn)化、OLAP 分析處理。Schema Mapper 與業(yè)務(wù)知識庫的引入，有效解決了大模型對私域知識理解不足的問題，提升語言處理的效果。

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

04插件接入：處理定制場景問題

定制化場景主要指代業(yè)務(wù)范圍之外的查詢需求，需要將音樂內(nèi)容數(shù)據(jù)與法律、政治、金融、監(jiān)管等方面信息結(jié)合提供問答服務(wù)。通過增加插件，使平臺用戶能夠訪問實時更新且無法包含在訓(xùn)練數(shù)據(jù)或業(yè)務(wù)知識庫中的信息，以實現(xiàn)定制化交互。由于插件類型不同，模型接入方式也會有所不同，常見的接入方式主要分為兩種：

Embedding 本地文本接入：該方式首先對本地文檔進行向量化處理，通過語義向量搜索，找到本地文檔中相關(guān)或者相似的詞語進行匹配，之后將文檔內(nèi)容注入大模型解析窗口中生成答案。這種方式非常適合業(yè)務(wù)分析師希望將音樂內(nèi)容數(shù)據(jù)庫與最新政策等一類較為私有的文件結(jié)合完成查詢需求。

ChatGPT 第三方插件接入：每款插件具備對應(yīng)的 Prompt 與調(diào)用函數(shù)。業(yè)務(wù)人員在安裝某款插件之后，在與模型對話中可以通過 Prompt 詞觸發(fā)函數(shù)開啟調(diào)用。目前第三方插件類型豐富，涉及行業(yè)廣泛，能夠有效增加多元場景的處理與響應(yīng)能力。

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

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

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

用戶輸入問題通過 Schema Mapper 檢索，判定字段是否匹配與業(yè)務(wù)知識庫。

如若匹配則跳過大模型解析步驟，直接利用知識庫中的指標計算公式觸發(fā) OLAP 進行查詢分析；如若不匹配則進入大模型，開啟下一步判定。

大模型首先通過人工經(jīng)驗判定問題復(fù)雜度，簡單查詢將指定 OLAP 引擎直接分析，復(fù)雜查詢則開啟語義解析形成 DSL 語句。

DSL 語句通過語義層進一步過濾、拆解關(guān)聯(lián)查詢場景，生成簡易單表 SQL 語句以觸發(fā) OLAP 數(shù)據(jù)處理與查詢加速。

針對需要與外部信息結(jié)合的查詢場景，大模型會判斷是否調(diào)用第三方插件來輔助完成查詢。

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

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

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

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

超音數(shù)平臺框架演進??????

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

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

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

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

處理層：在 ODS- DWD- DWS 三層中將數(shù)據(jù)整合為不同主題的標簽和指標體系之后，通過對 DWS 調(diào)度與采集所需字段，在 DWM 層將維度與指標數(shù)據(jù)加工成大寬表。

分析層：通過大寬表進入分析層，將數(shù)據(jù)導(dǎo)入 Clickhouse 與 Elasticsearch，其中 Clickhosue 主要負責維度與指標兩類數(shù)據(jù)的查詢加速，作為分析引擎為后續(xù)提供報表開發(fā)服務(wù)；Elasticsearch 主要負責維度數(shù)據(jù)處理，作為搜索/圈選引擎。

應(yīng)用層：業(yè)務(wù)人員基于場景選取所需要的標簽與指標，在應(yīng)用層中創(chuàng)建數(shù)據(jù)集作為邏輯視圖，同時可以二次定義衍生的標簽與指標。

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

數(shù)據(jù)延遲：處理層不支持部分列表更新，DWS 層數(shù)據(jù)寫入產(chǎn)生延遲后會造成大寬表的延遲，進而導(dǎo)致數(shù)據(jù)時效性下降。

運維成本高：在處理層大寬表中維度數(shù)據(jù)量平均占一張大寬表的 50%，且在大部份情況下變化緩慢，這意味著每一張寬表的開發(fā)會將維度數(shù)據(jù)疊加，造成存儲資源的浪費、維護成本增加；在分析層中存在多引擎使用的問題，查詢 SQL 語句需要同時適配 Clickhouse 與 Elasticsearch 兩個組件，增加人力成本，且兩套組件也會加大運維難度，運維成本進一步升高。

架構(gòu)冗余：在應(yīng)用層進行指標與維度定義時，導(dǎo)致相同數(shù)據(jù)會進行多次定義使各種指標、維度定義口徑不一致，造成權(quán)限不可控，例如上圖所示的 T1 （標簽）與 M1 （維度）在應(yīng)用層中，被不同數(shù)據(jù)集多次定義。

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

基于以上問題，我們開始對架構(gòu)進行改造升級，并在眾多 OLAP 引擎中選擇了 Apache Doris 來替換原有組件，主要因為 Apache Doris 具備以下核心優(yōu)勢：

實時導(dǎo)入：Apache Doris 能夠支持海量業(yè)務(wù)數(shù)據(jù)的高吞吐實時寫入，時效性可以做到秒級完成導(dǎo)入。

引擎統(tǒng)一：支持 Multi-Catalog 功能，能夠通過 Elasticsearch Catalog 外表查詢，實現(xiàn)查詢出口統(tǒng)一，查詢層架構(gòu)實現(xiàn)鏈路極簡，維護成本也大幅降低。

查詢分析性能：Apache Doris 是 MPP 架構(gòu)，支持大表分布式 Join，其倒排索引、物化視圖、行列混存等功能使查詢分析性能更加高效極速。

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

分析層：引入 Apache Doris 替換 Clickhouse 組件，利用 Doris 的 Elasticsearch Catalog 功能對 Elasticsearch 外表進行查詢，實現(xiàn)查詢出口統(tǒng)一；

語義層：應(yīng)用層不再需要創(chuàng)建數(shù)據(jù)集視圖，直接通過語義層獲取指標與標簽內(nèi)容執(zhí)行查詢?nèi)蝿?wù)，有效解決標簽與指標口徑問題。

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

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

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

處理層：按照業(yè)務(wù)分類在 DWM 中將大寬表拆分成緩慢維度表與指標表，使兩類表在本地 Hive 中進行關(guān)聯(lián)，通過 Hive 導(dǎo)入 Apache Doris 分析層中加速任務(wù)；

分析層：將關(guān)聯(lián)數(shù)據(jù)表直接導(dǎo)入 Apache Doris 中，結(jié)合語義層暴露指標與維度以實現(xiàn)語義統(tǒng)一，用戶只需要通過過濾條件就能夠直接查詢數(shù)據(jù)，得到所需要的結(jié)果。

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

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

分析層 + 處理層：數(shù)倉 DWD 層數(shù)據(jù)采用 Rollup 功能使事實表與維度表實時關(guān)聯(lián)并創(chuàng)建多個視圖進入 DWS 中。通過這種方式，分析層與處理層中的各類指標數(shù)據(jù)無需再重復(fù)定義，能夠基于 Apache Doris 全部寫入新建的 Rollup 視圖中并利用GROUP BY將維度傳入視圖進行查詢加速，直接對外暴露所需數(shù)據(jù)。

語義層：利用 Apache Doris 物化視圖對指標與維度自定義口徑，通過語義物化層進行查詢加速，并將指標與維度通過SUM加工開發(fā)衍生標簽與維度數(shù)據(jù)。

應(yīng)用層：利用 Apache Doris 2.0 版本的倒排索引功能，對現(xiàn)有的索引結(jié)構(gòu)進行豐富，滿足了對知識庫進行模糊查詢、等值查詢和范圍查詢等場景中的能力，進一步加速指標、維度查詢響應(yīng)速度。

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

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

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

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

指標大寬表：采用 Apache Doris 的 Aggregate Key 模型，使用增量的方式將數(shù)據(jù)覆蓋寫入；

緩慢維度表：主要通過start_date和end_date的設(shè)置進行表建設(shè)，同時利用end_date進行分區(qū)，當我們需要查詢最新的維度數(shù)據(jù)時只需要將end_date設(shè)置為‘9999-12-31’即可。此外我們引用 Doris 2.0 版本中的寫時合并，利用 Unique Key 模型進行維度數(shù)據(jù)聚合，使查詢性能在該場景中得到很大的提升。

對外訪問視圖：在指標與維度表建設(shè)完成之后，利用CREAT VIEW提供統(tǒng)一對外訪問視圖，同時添加end_date條件，使視圖保持最新數(shù)據(jù)的展示。通過這樣的方式不僅能夠大幅度降低查詢的復(fù)雜性，還能夠充分利用 Doris 特性實現(xiàn)查詢加速。

02Rollup 解決指標膨脹問題

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

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

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

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

除了減少指標數(shù)量外，我們還希望能夠衍生指標并且做到查詢加速。在 Apache Doris 2.0 版本中我們采用了物化視圖功能進行衍生指標的開發(fā)。目前，我們主要在單一維度表中單獨地去查詢自定義標簽與維度，在定義復(fù)雜口徑后自動的通過語義層物化任務(wù)。如上圖所示我們將指標 M1 、M2、M3 與維度 T1、T2、T3 分別進行定義，并通過 SUM 加工衍生標簽，在加工完成之后創(chuàng)建物化視圖加速查詢。此外，在 Doris 后續(xù) 2.1 版本中還會支持多表創(chuàng)建物化視圖，我們也非常期待使用該功能。

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

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

導(dǎo)入鏈路如圖所示，主要分為離線與實時兩個部分，離線鏈路中指標表與變更維度表通過 Spark 進行批量導(dǎo)入，兩類表利用 Flink 聚合形成寬表后寫入；實時鏈路主要利用 Kafak 消息隊列進行流式寫入。最終，離線與實時兩條鏈路利用 Flink 實時寫入 Apache Doris 數(shù)倉中。由于 Flink 聚合為攢批寫入，如果出現(xiàn)寫入任務(wù)失敗，會導(dǎo)致數(shù)據(jù)丟失；同時，在聚合任務(wù)過多、字段過多的情況下存在 Compaction 不及時的情況，導(dǎo)致實時能力不可控；此外在加工寬表的過程中，也會造成重復(fù)寫入的問題，無法保證數(shù)據(jù)寫入準確性。在 Apache Doris 2.0 版本發(fā)布后，我們引入了其全新功能 Flink Doris Connector 與 Doris Compaction，有效解決了 Flink 聚合引起的問題。

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

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

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

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

Vertical Compaction 功能優(yōu)勢：在單次合并過程中，我們不需要再將所有的列讀出，只需要加載部份列數(shù)據(jù)即可，這能極大減少合并過程中的內(nèi)存占用問題，提高壓縮的執(zhí)行速度，實現(xiàn)在大寬表場景下的部份數(shù)據(jù)合并。

Segment Compaction 功能優(yōu)勢：在單批次大數(shù)據(jù)量的導(dǎo)入場景下可以有效減少 Flink 寫入過程中產(chǎn)生的 Segment 數(shù)量，且能夠使合并和導(dǎo)入兩個過程并行，避免增加導(dǎo)入時間。

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

總結(jié)收益與展望

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

極速查詢分析：通過 Apache Doris 的 Rollup、物化視圖、倒排索引功能，由原來的分鐘級查詢時間達到現(xiàn)如今秒級毫秒級；

導(dǎo)入性能提升：導(dǎo)入優(yōu)化完成后，原本 3000+ 維度、指標數(shù)據(jù)的導(dǎo)入時間需要超過一天，現(xiàn)如今能夠在 8 小時內(nèi)完成導(dǎo)入，導(dǎo)入時間縮短至原來的 1/3，實現(xiàn)快速導(dǎo)入需求；更重要的是，Apache Doris 在保證數(shù)據(jù)快寫入的同時，使數(shù)據(jù)能夠不丟不重、準確寫入；

鏈路極簡與統(tǒng)一：Apache Doris 將查詢與分析出口引擎統(tǒng)一，去除 Elasticsearch 集群使架構(gòu)鏈路極簡；

存儲成本降低：通過大寬表拆分的方式，使存儲成本降低 30%，開發(fā)成本降低 40% 。

在未來，我們將進一步拓展使用 Apache Doris 湖倉一體功能，對 Hive、MySQL、數(shù)據(jù)湖等多源異構(gòu)數(shù)據(jù)庫進行網(wǎng)關(guān)統(tǒng)一，實現(xiàn)真正意義上的實時統(tǒng)一分析引擎。同時，嘗試 CCR 跨集群數(shù)據(jù)同步功能，通過用戶多集群的數(shù)據(jù)庫表自動同步以提升在線服務(wù)數(shù)據(jù)的可用性。未來，我們也將在測試環(huán)節(jié)中驗證讀寫負載分離以及多機房備份的性能效果。目前，Apache Doris 社區(qū)已經(jīng)公布了后續(xù)版本中將推出的存算分離全新架構(gòu)，能夠利用低成本的共享存儲系統(tǒng)簡化上層計算節(jié)點的復(fù)雜度，使架構(gòu)帶來巨大的成本經(jīng)濟優(yōu)勢。我們也希望能夠進一步探索，基于 Apache Doris 本地高速緩存 + 共享存儲系統(tǒng)的混合模式，在保障性能的同時降低系統(tǒng)存儲開銷。最后，非常感謝 SelectDB 技術(shù)團隊的積極響應(yīng)與專業(yè)解答，希望通過這篇文章分享大語言模型在互聯(lián)網(wǎng)業(yè)務(wù)中的應(yīng)用，也歡迎更多人參與 Apache Doris 社區(qū)與超音數(shù)平臺的開源框架構(gòu)建。最后，我們也會持續(xù)參與社區(qū)活動，將相關(guān)成果貢獻回饋社區(qū)，希望 Apache Doris 飛速發(fā)展，越來越好！