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