導讀：當前，大語言模型的應用正在全球范圍內引發(fā)新一輪的技術革命與商業(yè)浪潮。騰訊音樂作為中國領先在線音樂娛樂平臺，利用龐大用戶群與多元場景的優(yōu)勢，持續(xù)探索大模型賽道的多元應用。本文將詳細介紹騰訊音樂如何基于 Apache Doris 構建查詢高效、實時統(tǒng)一分析的 OLAP 引擎，使 OLAP 作為底層基建加強模型連接轉化效率、結果輸出準確率，最終將大模型 + OLAP 引擎結合為用戶提供個性化、實時化、靈活化的智能數據服務平臺。
騰訊音樂娛樂集團（以下簡稱“騰訊音樂”）是中國在線音樂娛樂服務開拓者，有著廣泛的用戶基礎，總月活用戶數超過 8 億，通過“一站式”的音樂娛樂平臺，用戶可以在多場景間無縫切換并享受多元的音樂服務。我們希望通過技術和數據賦能，為用戶帶來更好的體驗，為音樂人和合作伙伴在音樂制作、發(fā)行、銷售等方面提供支持。
基于公司豐富的音樂內容資產，需要將歌曲庫、藝人資訊、專輯信息、廠牌信息等大量數據進行統(tǒng)一存儲形成音樂內容數據倉庫，并通過產品工具為業(yè)務人員提供數據分析服務。在內容數倉搭建的過程中，我們的工作始終圍繞降本增效為主要目的進行優(yōu)化與迭代，希望在數據服務方面不斷提升產品工具的開發(fā)與分析效率，同時在數倉架構方面能夠有效減少架構成本與資源開銷。
在傳統(tǒng)數據服務中，我們?yōu)闃I(yè)務分析師提供了多種數據服務，包括 SQL 查詢、固定看板、定制化的分析工具以及人工跑數。然而，在實際應用過程中仍然存在一定痛點：
- SQL 查詢平臺 ： 業(yè)務分析師根據需求進行 SQL 語句編寫，對平臺數據進行查詢分析，每位業(yè)務人員都需要掌握 SQL，導致學習成本高、上手難度大。
- 固定看板（Dashboard） ： 技術人員基于常規(guī)業(yè)務開發(fā)制作數據看板，雖然能夠簡化業(yè)務分析師查詢的過程，但是看板制作成本高且靈活度低，當面對復雜的用戶問題時，看板無法及時調整以滿足需求變更。
- 定制分析工具： 基于特定的業(yè)務需求，技術人員需要定制化開發(fā)產品分析工具，整體開發(fā)成本過高，且單一的開發(fā)工具不具備通用性，隨著工具數量增加，操作介面變得散亂，從而降低業(yè)務效率。
- 人工跑數： 當以上三個場景都無法滿足業(yè)務需求時，業(yè)務分析師需要向技術人員提需求進行人工跑數，溝通成本過高、整體解決效率低下。
隨著行業(yè)發(fā)展趨勢，LLMs 大語言模型（LLMs - Large Language Models，以下統(tǒng)一簡稱為大模型）出現有效地解決了這些問題。當平臺融入大模型后，平臺用戶輸入的問題會進入大模型進行語義解析，自動轉化為 SQL 語句觸發(fā) OLAP 引擎開啟數據分析與查詢。通過平臺智能問答交互的方式，業(yè)務分析師不再需要依靠人工編寫 SQL 提供查詢分析結果，技術人員也不需要再制作過于固定或者過于定制化的產品工具。大模型 + OLAP 引擎結合的全新數據服務模式，不僅為平臺用戶提供了個性化、靈活表達、秒級回復的服務體驗，還大幅降低了企業(yè)內部技術與業(yè)務學習成本，加速數據分析效率，實現多端入口統(tǒng)一、界面統(tǒng)一的平臺構建。
本文將詳細介紹騰訊音樂如何基于 Apache Doris 構建查詢高效、實時寫入且統(tǒng)一的 OLAP 分析引擎，使 OLAP 作為底層基建加強大模型與之連接轉化的效率、結果輸出的準確率，最終提供更智能化的問答交互服務，也希望通過這篇文章為有相關業(yè)務需求的公司提供不同視角和思路。
大模型 + OLAP ：開啟數據服務平臺新模式
在大模型 + OLAP 架構方案中，目前經典方案如下圖所示，大模型充當中間層將用戶輸入的自然語言轉化為 SQL 執(zhí)行語句，OLAP 作為底層存儲和數據處理的引擎，負責接受和執(zhí)行從大模型發(fā)送過來的 SQL 語句，對數據進行預聚合、多維分析等操作，滿足大規(guī)模數據集的查詢分析需求。
然而，這種架構在實際落地過程中也面臨一定挑戰(zhàn)，例如語義理解的準確性、查詢效率的優(yōu)化、私域知識的理解等方面，具體如下：
- 復雜數據口徑不統(tǒng)一： 大模型對于技術方面的詞匯，如字段、行列、表等無法理解，相反對于業(yè)務方面的詞匯，如公司收入情況、日活躍用戶數量等能夠提供有效翻譯與轉換。因此挑戰(zhàn)之一是需要思考如何引導用戶進入指標范圍內提問，挑戰(zhàn)之二是當用戶存在對多種指標、多類指標查詢時，需要考慮如何保持指標維度口徑的統(tǒng)一、如何有效生成對應的指標計算公式。
- 模型處理效率較低： 現階段大模型雖然支持交互能力，但推理速度較慢，需要花費十秒級以上響應，用戶每增加一個問題輸入，就需要花費更多等待時間，使服務質量降低。同時大模型整體按照 Token 收費，使用量增加時也會導致平臺成本升高。
- 私域知識無法識別： 雖然大模型已經開展許多公開數據集的語言轉換訓練，但面對企業(yè)內部的大量專業(yè)術語仍無法很好地理解轉化。以音樂內容數據庫為例，大模型時常缺少對于某些冷門歌曲的認知，在問答過程中無法正確給出交互反饋，因此我們需要增強大模型對于私域知識的理解。
- 定制場景無法滿足： 大模型主要依據自身數據集進行回答，會出現“知識幻覺”（輸出缺乏依據的內容）問題，我們需要允許第三方插件的接入使大模型得以聯(lián)網，讓用戶借助內部插件完成更定制化、更多樣的任務。因此如何接入、匹配并觸發(fā)組件功能是我們的重點優(yōu)化目標。
面對經典方案中的落地難點，我們的總體解決思路是將以上四大挑戰(zhàn)逐一拆解，通過組件疊加分階段完善大模型 + OLAP 架構構建，最終實現全新的交互問答服務模式，接下來我們將介紹各階段挑戰(zhàn)對應的解決方案。
01 增加語義層：處理復雜數據問題
為了解決復雜數據處理問題，我們在大模型與 OLAP 中間增加 Semantic Layer（以下簡稱語義層）。
一方面語義層作為連接技術與業(yè)務之間的轉換橋梁，能夠將數據字段翻譯為業(yè)務用戶的術語，使業(yè)務知識作為額外的抽象層。通過語義層，業(yè)務分析師不需要在定義指標后存儲于 OLAP 數倉中，能夠直接在語義層中指定過濾條件，將所需指標篩選后生成 SQL 語句并在 OLAP 中進行字段查詢。這意味著，業(yè)務分析師能夠把多源數據按照需求定義成語義信息并形成語義標準，有效解決了多種指標、多類維度計算口徑不統(tǒng)一的挑戰(zhàn)。
另一方面語義層能夠針對業(yè)務計算邏輯，進行語義加工、描述、關聯(lián)和運算。語義層在過濾數據后，能夠屏蔽由表關聯(lián)所產生的復雜指標計算公式，將多表 Join 場景進行拆解、轉化，形成較為簡單的單表查詢，以提升語義轉化的準確性。
02 設定人工經驗：處理模型效率問題
針對模型效率問題，我們的解決思路是對指標計算、明細查詢、人群圈選等查詢場景進行復雜度判定，將簡單查詢場景直接跳過大模型解析的步驟，進入底層 OLAP 進行處理分析，使大模型更加專注處理復雜查詢場景。
為此，如上圖所示我們在模型中添加人工經驗判斷。當業(yè)務分析師輸入 “查詢各大音樂平臺收入”問題時，模型依據判定規(guī)則發(fā)現該場景只需要提供某個指標或幾個維度即可完成，這時不需要將問題進入大模型解析，直接使用 OLAP 進行查詢分析，能夠有效縮短響應時間，提升結果反饋效率。此外，跳過大模型解析的步驟也能夠節(jié)省 API 調用經費，解決平臺使用成本升高的問題。
03 增加內容映射：處理私域知識問題
針對私域知識的問題，我們在大模型上游增加 Schema Mapper 、在外部建立業(yè)務知識庫，將平臺用戶的問題與知識庫進行連接，通過 Schema Mapper 判定是否存在部份文字能夠與知識庫內容匹配。如果匹配成功，大模型將進一步解析轉化、OLAP 分析處理。Schema Mapper 與業(yè)務知識庫的引入，有效解決了大模型對私域知識理解不足的問題，提升語言處理的效果。
目前，我們正在不斷對 Schema Mapper 匹配準確性進行測試與優(yōu)化，將知識庫中的內容進行分類處理、字段評級等操作，同時將輸入文本進行不同范圍的內容映射（如全文本映射與模糊映射），通過映射結果來加強模型語義解析的能力。
04 插件接入：處理定制場景問題
定制化場景主要指代業(yè)務范圍之外的查詢需求，需要將音樂內容數據與法律、政治、金融、監(jiān)管等方面信息結合提供問答服務。通過增加插件，使平臺用戶能夠訪問實時更新且無法包含在訓練數據或業(yè)務知識庫中的信息，以實現定制化交互。
由于插件類型不同，模型接入方式也會有所不同，常見的接入方式主要分為兩種：
- Embedding 本地文本接入： 該方式首先對本地文檔進行向量化處理，通過語義向量搜索，找到本地文檔中相關或者相似的詞語進行匹配，之后將文檔內容注入大模型解析窗口中生成答案。這種方式非常適合業(yè)務分析師希望將音樂內容數據庫與最新政策等一類較為私有的文件結合完成查詢需求。
- ChatGPT 第三方插件接入： 每款插件具備對應的 Prompt 與調用函數。業(yè)務人員在安裝某款插件之后，在與模型對話中可以通過 Prompt 詞觸發(fā)函數開啟調用。目前第三方插件類型豐富，涉及行業(yè)廣泛，能夠有效增加多元場景的處理與響應能力。
超音數平臺框架構思
根據上述大模型 + OLAP 的四大解決方案進行了方案整合，以此進行框架設計并將其命名為超音數平臺。大模型主要作用于自然語言與 SQL 分析語句的連接與轉化，OLAP 引擎則作為數據存儲與查詢分析的核心基建。
超音數平臺對于業(yè)務流程如圖所示，模型運轉具體過程如下：
- 用戶輸入問題通過 Schema Mapper 檢索，判定字段是否匹配與業(yè)務知識庫。
- 如若匹配則跳過大模型解析步驟，直接利用知識庫中的指標計算公式觸發(fā) OLAP 進行查詢分析；如若不匹配則進入大模型，開啟下一步判定。
- 大模型首先通過人工經驗判定問題復雜度，簡單查詢將指定 OLAP 引擎直接分析，復雜查詢則開啟語義解析形成 DSL 語句。
- DSL 語句通過語義層進一步過濾、拆解關聯(lián)查詢場景，生成簡易單表 SQL 語句以觸發(fā) OLAP 數據處理與查詢加速。
- 針對需要與外部信息結合的查詢場景，大模型會判斷是否調用第三方插件來輔助完成查詢。
以“某首歌曲能否在綜藝節(jié)目播出”為例，在經過檢索匹配、語義解析后，大模型選擇利用 OLAP 數據查詢與第三方版權行業(yè)插件結合的方式進行回答，最終呈現結果由數倉中的歌曲信息與插件判定結果構成。
如今，業(yè)務分析師只需要在超音數平臺中定義指標含義、維度類型即可直接開展自然語言的問答交互服務。同時還可以在平臺中內置插件、豐富指標市場來拓展語義解析能力，完全覆蓋了業(yè)務在常規(guī)與定制化場景下的查詢需求。平臺基于大模型 + OLAP 的模式加速業(yè)務分析效率，減少技術開發(fā)成本，向智能化、個性化、實時化的全新業(yè)務服務模式更近一步。
在這里希望可以與大家分享該開源項目，讓更多人體驗和學習大模型構建，也歡迎感興趣的讀者們共同參與大模型開發(fā)與建設。
超音數平臺框架演進
在平臺構建的過程中，OLAP 引擎作為整體架構的基建對 SQL 語句處理、數據存儲分析、上游應用層的查詢響應等有著至關重要的作用，我們希望通過架構升級以加強大模型到 OLAP 引擎的轉化效率與結果輸出準確性。
接下來我們將對比介紹 OLAP 早期架構與新一代架構在數據寫入與查詢兩方面的差異，分享在架構演進過程中大模型 + OLAP 模型優(yōu)化歷程，最終助力超音數平臺的構建，開啟新一代的數據服務模式。
01 數據架構 1.0
我們初期的業(yè)務架構如上圖所示，分為處理層、分析層、應用層三部份，用戶文本在進入大模型之后解析為 SQL 語句使 OLAP 開始執(zhí)行任務，具體的工作原理如下：
- 處理層：在 ODS- DWD- DWS 三層中將數據整合為不同主題的標簽和指標體系之后，通過對 DWS 調度與采集所需字段，在 DWM 層將維度與指標數據加工成大寬表。
- 分析層：通過大寬表進入分析層，將數據導入 Clickhouse 與 Elasticsearch，其中 Clickhosue 主要負責維度與指標兩類數據的查詢加速，作為分析引擎為后續(xù)提供報表開發(fā)服務；Elasticsearch 主要負責維度數據處理，作為搜索/圈選引擎。
- 應用層：業(yè)務人員基于場景選取所需要的標簽與指標，在應用層中創(chuàng)建數據集作為邏輯視圖，同時可以二次定義衍生的標簽與指標。
在實際業(yè)務使用中，早期架構的數據處理方式存在大寬表帶來的數據延遲與存儲浪費、多套組件導致架構冗余帶來指標維度重復定義、學習與運維成本高等問題，具體如下：
- 數據延遲： 處理層不支持部分列表更新，DWS 層數據寫入產生延遲后會造成大寬表的延遲，進而導致數據時效性下降。
- 運維成本高： 在處理層大寬表中維度數據量平均占一張大寬表的 50%，且在大部份情況下變化緩慢，這意味著每一張寬表的開發(fā)會將維度數據疊加，造成存儲資源的浪費、維護成本增加；在分析層中存在多引擎使用的問題，查詢 SQL 語句需要同時適配 Clickhouse 與 Elasticsearch 兩個組件，增加人力成本，且兩套組件也會加大運維難度，運維成本進一步升高。
- 架構冗余： 在應用層進行指標與維度定義時，導致相同數據會進行多次定義使各種指標、維度定義口徑不一致，造成權限不可控，例如上圖所示的 T1 （標簽）與 M1 （維度）在應用層中，被不同數據集多次定義。
02 數據架構 2.0
基于以上問題，我們開始對架構進行改造升級，并在眾多 OLAP 引擎中選擇了 Apache Doris 來替換原有組件，主要因為 Apache Doris 具備以下核心優(yōu)勢：
- 實時導入： ?Apache Doris 能夠支持海量業(yè)務數據的高吞吐實時寫入，時效性可以做到秒級完成導入。
- 引擎統(tǒng)一： 支持 Multi-Catalog 功能，能夠通過 Elasticsearch Catalog 外表查詢，實現查詢出口統(tǒng)一，查詢層架構實現鏈路極簡，維護成本也大幅降低。
- 查詢分析性能： Apache Doris 是 MPP 架構，支持大表分布式 Join，其倒排索引、物化視圖、行列混存等功能使查詢分析性能更加高效極速。
在數據架構 2.0 版本中，數據架構保留處理層部份，主要升級分析層架構，并進行了語義層疊加：
- 分析層：引入 Apache Doris 替換 Clickhouse 組件，利用 Doris 的 Elasticsearch Catalog 功能對 Elasticsearch 外表進行查詢，實現查詢出口統(tǒng)一；
- 語義層：應用層不再需要創(chuàng)建數據集視圖，直接通過語義層獲取指標與標簽內容執(zhí)行查詢任務，有效解決標簽與指標口徑問題。
03 數據架構 3.0
由于寬表開發(fā)過程中，維度數據一般變化較小、字符存儲空間較大，且分析查詢一般只需要查詢最新的維度數據。在這種情況下，如果不斷疊加維度數據制作寬表，會造成存儲空間浪費的問題，同時查詢響應速度也受到影響。
為了進一步提升架構性能，數據架構 3.0 主要將處理層中大寬表進行拆分，同時將分析層統(tǒng)一使用 Apache Doris 作為查詢分析引擎：
- 處理層：按照業(yè)務分類在 DWM 中將大寬表拆分成緩慢維度表與指標表，使兩類表在本地 Hive 中進行關聯(lián)，通過 Hive 導入 Apache Doris 分析層中加速任務；
- 分析層：將關聯(lián)數據表直接導入 Apache Doris 中，結合語義層暴露指標與維度以實現語義統(tǒng)一，用戶只需要通過過濾條件就能夠直接查詢數據，得到所需要的結果。
04 數據架構 4.0
我們延續(xù)了 3.0 架構中分析層統(tǒng)一的優(yōu)勢，對處理層、分析層、語義層架構進一步優(yōu)化，使查詢性能顯著提升：
- 分析層 + 處理層：數倉 DWD 層數據采用 ?Rollup 功能使事實表與維度表實時關聯(lián)并創(chuàng)建多個視圖進入 DWS 中。通過這種方式，分析層與處理層中的各類指標數據無需再重復定義，能夠基于 Apache Doris 全部寫入新建的 Rollup 視圖中并利用
GROUP BY將維度傳入視圖進行查詢加速，直接對外暴露所需數據。 - 語義層：利用 Apache Doris 物化視圖對指標與維度自定義口徑，通過語義物化層進行查詢加速，并將指標與維度通過?
SUM?加工開發(fā)衍生標簽與維度數據。 - 應用層：利用 Apache Doris 2.0 版本的倒排索引功能，對現有的索引結構進行豐富，滿足了對知識庫進行模糊查詢、等值查詢和范圍查詢等場景中的能力，進一步加速指標、維度查詢響應速度。
數倉架構基于 Apache Doris 迭代升級，最終實現導入實時、引擎統(tǒng)一、查詢高效的現代化湖倉 OLAP 引擎，簡化架構鏈路的同時，有效解決大寬表中指標重復定義所帶來的問題。在架構演進的過程，我們也積累許多關于 Apache Doris 性能優(yōu)化經驗，希望通過分享給讀者們帶來一些參考。
Apache Doris 性能優(yōu)化實踐
01 Colocate Join 寬表優(yōu)化
在上文架構改造中我們提及，由于寬表開發(fā)會不斷疊加字符數據，消耗存儲空間，降低查詢性能，因此我們充分利用了 Colocate Join 功能對寬表拆分、本地關聯(lián)查詢加速進行優(yōu)化，具體過程如下：
- 指標大寬表：采用 Apache Doris 的 Aggregate Key 模型，使用增量的方式將數據覆蓋寫入；
- 緩慢維度表：主要通過?
start_date?和?end_date?的設置進行表建設，同時利用?end_date?進行分區(qū)，當我們需要查詢最新的維度數據時只需要將?end_date?設置為?‘9999-12-31’?即可。此外我們引用 Doris 2.0 版本中的寫時合并，利用 Unique Key 模型進行維度數據聚合，使查詢性能在該場景中得到很大的提升。 - 對外訪問視圖：在指標與維度表建設完成之后，利用?
CREAT VIEW?提供統(tǒng)一對外訪問視圖，同時添加?end_date?條件，使視圖保持最新數據的展示。通過這樣的方式不僅能夠大幅度降低查詢的復雜性，還能夠充分利用 Doris 特性實現查詢加速。
02 Rollup 解決指標膨脹問題
寬表拆分為指標表與維度表后，我們發(fā)現每一次視圖產生都需要定義多個指標，出現指標膨脹的情況。以“歌曲播放量結算”為例，當僅定義單一指標時，我們需要將各個平臺 + 各類內容進行排列組合，使語義層定義很多指標數據，造成指標數量過多。此外這些指標都需要通過離線生產任務進行加工，并通過 Hive 導入至 Apache Doris 中，造成鏈路較長、加工維護比較困難。
平臺指標：覆蓋四大音樂平臺，包括酷我、QQ 音樂、酷狗、K 歌內容指標：包含歌曲、歌手、專輯以及廠牌等數據
為了有效解決指標膨脹問題，我們引入了 Doris Rollup 功能。如圖所示，在 Doris Base 表數據基礎之上，可以根據指定維度來創(chuàng)建任意多個 Rollup 視圖并自動進行?GROUP BY?，實現各個平臺與各類內容指標定義不重復、查詢性能提升的目標。
03 物化視圖實現查詢加速
除了減少指標數量外，我們還希望能夠衍生指標并且做到查詢加速。在 Apache Doris 2.0 版本中我們采用了物化視圖功能進行衍生指標的開發(fā)。目前，我們主要在單一維度表中單獨地去查詢自定義標簽與維度，在定義復雜口徑后自動的通過語義層物化任務。
如上圖所示我們將指標 M1 、M2、M3 與維度 T1、T2、T3 分別進行定義，并通過 ?SUM ?加工衍生標簽，在加工完成之后創(chuàng)建物化視圖加速查詢。此外，在 Doris 后續(xù) 2.1 版本中還會支持多表創(chuàng)建物化視圖，我們也非常期待使用該功能。
Apache Doris 導入性能調優(yōu)實踐
目前，騰訊音樂具有 90+ 數據來源表、 3000 + 維度和指標、導入數據量達到千億級別，我們希望數倉能夠支持大規(guī)模數據快速導入，且導入過程中保證數據寫入的準確性。
導入鏈路如圖所示，主要分為離線與實時兩個部分，離線鏈路中指標表與變更維度表通過 Spark 進行批量導入，兩類表利用 Flink 聚合形成寬表后寫入；實時鏈路主要利用 Kafak 消息隊列進行流式寫入。最終，離線與實時兩條鏈路利用 Flink ?實時寫入 Apache Doris 數倉中。
由于 Flink 聚合為攢批寫入，如果出現寫入任務失敗，會導致數據丟失；同時，在聚合任務過多、字段過多的情況下存在 Compaction 不及時的情況，導致實時能力不可控；此外在加工寬表的過程中，也會造成重復寫入的問題，無法保證數據寫入準確性。
在 Apache Doris 2.0 版本發(fā)布后，我們引入了其全新功能 Flink Doris Connector 與 Doris Compaction，有效解決了 Flink 聚合引起的問題。
01 Flink Doris Connector 實現快寫入
Flink Doris Connector 主要是依賴 Checkpoint 機制進行流式寫入，同時該功能默認開啟兩階段提交，保證寫入過程中 Exactly Once 語義。值得注意的是，我們在引入最新版的 Flink Doris Connector 功能后，實現了從關系型數據庫到 Apache Doris 的一鍵整庫同步，承載了我們實際業(yè)務中千億級別的實時并行寫入，滿足數據快寫入與不丟不重的需求。
02 Doris Compaction 保證寫入穩(wěn)定性
為了解決 Flink 聚合引起的偶發(fā)性 Compaction 不及時問題，我們引入最新版的 Vertical Compaction 與 Segment Compaction 功能。
- Vertical Compaction 功能優(yōu)勢： 在單次合并過程中，我們不需要再將所有的列讀出，只需要加載部份列數據即可，這能極大減少合并過程中的內存占用問題，提高壓縮的執(zhí)行速度，實現在大寬表場景下的部份數據合并。
- Segment Compaction 功能優(yōu)勢： 在單批次大數據量的導入場景下可以有效減少 Flink 寫入過程中產生的 Segment 數量，且能夠使合并和導入兩個過程并行，避免增加導入時間。
如上圖所示在引入 Doris Compation 功能后，在寫入量增加 50 % 的情況下，Compaction Score 從平均 650 分降低至 80 分，技術人員不再需要擔心夜間出現告警的情況，保證了整體鏈路的穩(wěn)定性。
總結收益與展望
在引入 Apache Doris 后，數據架構圍繞降本增效的目標，不僅在寫查方面的性能得到大幅度提升，并且有效減少架構成本與資源開銷，具體的收益如下：
- 極速查詢分析： 通過 Apache Doris 的 Rollup、物化視圖、倒排索引功能，由原來的分鐘級查詢時間達到現如今秒級毫秒級；
- 導入性能提升： 導入優(yōu)化完成后，原本 3000+ 維度、指標數據的導入時間需要超過一天，現如今能夠在 8 小時內完成導入，導入時間縮短至原來的 1/3，實現快速導入需求；更重要的是，Apache Doris 在保證數據快寫入的同時，使數據能夠不丟不重、準確寫入；
- 鏈路極簡與統(tǒng)一： Apache Doris 將查詢與分析出口引擎統(tǒng)一，去除 Elasticsearch 集群使架構鏈路極簡；
- 存儲成本降低： 通過大寬表拆分的方式，使存儲成本降低 30%，開發(fā)成本降低 40% 。
在未來，我們將進一步拓展使用 Apache Doris 湖倉一體功能，對 Hive、MySQL、數據湖等多源異構數據庫進行網關統(tǒng)一，實現真正意義上的實時統(tǒng)一分析引擎。同時，嘗試 CCR 跨集群數據同步功能，通過用戶多集群的數據庫表自動同步以提升在線服務數據的可用性。未來，我們也將在測試環(huán)節(jié)中驗證讀寫負載分離以及多機房備份的性能效果。
目前，Apache Doris 社區(qū)已經公布了后續(xù)版本中將推出的存算分離全新架構，能夠利用低成本的共享存儲系統(tǒng)簡化上層計算節(jié)點的復雜度，使架構帶來巨大的成本經濟優(yōu)勢。我們也希望能夠進一步探索，基于 Apache Doris 本地高速緩存 + 共享存儲系統(tǒng)的混合模式，在保障性能的同時降低系統(tǒng)存儲開銷。
最后，非常感謝 SelectDB 技術團隊的積極響應與專業(yè)解答，希望通過這篇文章分享大語言模型在互聯(lián)網業(yè)務中的應用，也歡迎更多人參與 Apache Doris 社區(qū)與超音數平臺的開源框架構建。最后，我們也會持續(xù)參與社區(qū)活動，將相關成果貢獻回饋社區(qū)，希望 Apache Doris 飛速發(fā)展，越來越好！
