導讀：騰訊音樂內容庫數據平臺旨在為應用層提供庫存盤點采盒、分群畫像旧乞、指標分析、標簽圈選等內容分析服務磅氨，高效為業(yè)務賦能尺栖。目前，內容庫數據平臺的數據架構已經從 1.0 演進到了 4.0 烦租，經歷了分析引擎從 ClickHouse 到?Apache Doris?的替換延赌、經歷了數據架構語義層的初步引入到深度應用，有效提高了數據時效性叉橱、降低了運維成本挫以、解決了數據管理割裂等問題，收益顯著窃祝。本文將為大家分享騰訊音樂內容庫數據平臺的數據架構演進歷程與實踐思考屡贺，希望所有讀者從文章中有所啟發(fā)。
作者：騰訊音樂內容庫數據平臺 張俊锌杀、代凱
騰訊音樂娛樂集團（簡稱“騰訊音樂娛樂”）是中國在線音樂娛樂服務開拓者甩栈，提供在線音樂和以音樂為核心的社交娛樂兩大服務。騰訊音樂娛樂在中國有著廣泛的用戶基礎糕再，擁有目前國內市場知名的四大移動音樂產品：QQ音樂量没、酷狗音樂、酷我音樂和全民K歌突想，總月活用戶數超過8億殴蹄。
業(yè)務需求
騰訊音樂娛樂擁有海量的內容曲庫，包括錄制音樂猾担、現(xiàn)場音樂袭灯、音頻和視頻等多種形式。通過技術和數據的賦能绑嘹，騰訊音樂娛樂持續(xù)創(chuàng)新產品稽荧，為用戶帶來更好的產品體驗，提高用戶參與度工腋，也為音樂人和合作伙伴在音樂的制作姨丈、發(fā)行和銷售方面提供更大的支持。
在業(yè)務運營過程中我們需要對包括歌曲擅腰、詞曲蟋恬、專輯、藝人在內的內容對象進行全方位分析趁冈，高效為業(yè)務賦能歼争，內容庫數據平臺旨在集成各數據源的數據拜马，整合形成內容數據資產（以指標和標簽體系為載體），為應用層提供庫存盤點沐绒、分群畫像俩莽、指標分析、標簽圈選等內容分析服務洒沦。
數據架構演進
TDW 是騰訊最大的離線數據處理平臺，公司內大多數業(yè)務的產品報表价淌、運營分析申眼、數據挖掘等的存儲和計算都是在TDW中進行，內容庫數據平臺的數據加工鏈路同樣是在騰訊數據倉庫 TDW 上構建的蝉衣。截止目前括尸，內容庫數據平臺的數據架構已經從 1.0 演進到了 4.0 ，經歷了分析引擎從 ClickHouse 到 Apache Doris 的替換病毡、經歷了數據架構語義層的初步引入到深度應用濒翻，有效提高了數據時效性、降低了運維成本啦膜、解決了數據管理割裂等問題有送，收益顯著。接下來將為大家分享騰訊音樂內容庫數據平臺的數據架構演進歷程與實踐思考僧家。
數據架構 1.0
如圖所示為數據架構 1.0 架構圖雀摘，分為數倉層、加速層八拱、應用層三部分阵赠，數據架構 1.0 是一個相對主流的架構，簡單介紹一下各層的作用及工作原理：
數倉層：通過 ODS-DWD-DWS 三層將數據整合為不同主題的標簽和指標體系肌稻， DWM 集市層圍繞內容對象構建大寬表清蚀，從不同主題域 DWS 表中抽取字段。
加速層：在數倉中構建的大寬表導入到加速層中爹谭，Clickhouse 作為分析引擎邻梆，Elasticsearch 作為搜索/圈選引擎风秤。
應用層：根據場景創(chuàng)建 DataSet，作為邏輯視圖從大寬表選取所需的標簽與指標，同時可以二次定義衍生的標簽與指標绿店。
存在的問題：
數倉層：不支持部分列更新，當上游任一來源表產生延遲敞贡，均會造成大寬表延遲换淆，進而導致數據時效性下降。
加速層：不同的標簽跟指標特性不同真屯、更新頻率也各不相同脸候。由于 ClickHouse 目前更擅長處理寬表場景，無區(qū)別將所有數據導入大寬表生成天的分區(qū)將造成存儲資源的浪費，維護成本也將隨之升高运沦。
應用層：ClickHouse 采用的是計算和存儲節(jié)點強耦合的架構泵额，架構復雜，組件依賴嚴重携添，牽一發(fā)而動全身嫁盲，容易出現(xiàn)集群穩(wěn)定性問題，對于我們來說烈掠，同時維護 ClickHouse 和 Elasticsearch 兩套引擎的連接與查詢羞秤，成本和難度都比較高。
除此之外左敌，ClickHouse 由國外開源瘾蛋，交流具有一定的語言學習成本，遇到問題無法準確反饋矫限、無法快速獲得解決哺哼，與社區(qū)溝通上的阻塞也是促進我們進行架構升級的因素之一。
數據架構 2.0
基于架構 1.0 存在的問題和 ClickHouse 的局限性叼风，我們嘗試對架構進行優(yōu)化升級取董，將分析引擎 ClickHouse 切換為 Doris，Doris 具有以下的優(yōu)勢：
Apache Doris 的優(yōu)勢：
Doris 架構極簡易用无宿，部署只需兩個進程甲葬，不依賴其他系統(tǒng)，運維簡單懈贺；兼容 MySQL 協(xié)議经窖，并且使用標準 SQL。
支持豐富的數據模型梭灿，可滿足多種數據更新方式画侣，支持部分列更新。
支持對 Hive堡妒、Iceberg配乱、Hudi 等數據湖和 MySQL、Elasticsearch 等數據庫的聯(lián)邦查詢分析皮迟。
導入方式多樣搬泥，支持從 HDFS/S3 等遠端存儲批量導入，也支持讀取 MySQL Binlog 以及訂閱消息隊列 Kafka 中的數據伏尼，還可以通過 Flink Connector?實時/批次同步數據源（MySQL,Oracle,PostgreSQL 等）到 Doris忿檩。****
社區(qū)目前 Apache Doris 社區(qū)活躍、技術交流更多爆阶，SelectDB 針對社區(qū)有專職的技術支持團隊燥透，在使用過程中遇到問題均能快速得到響應解決沙咏。
同時我們也利用 Doris 的特性，解決了架構 1.0 中較為突出的問題班套。
數倉層：Apache Doris 的?Aggregate 數據模型可支持部分列實時更新肢藐，因此我們去掉了 DWM 集市層的構建，直接增量到 Doris / ES 中構建寬表吱韭，解決了架構 1.0 中上游數據更新延遲導致整個寬表延遲的問題吆豹，進而提升了數據的時效性。數據（指標理盆、標簽等）通過 Spark 統(tǒng)一離線加載到 Kafka 中痘煤，使用 Flink 將數據增量更新到 Doris 和 ES 中（利用 Flink 實現(xiàn)進一步的聚合，減輕了 Doris 和 ES 的更新壓力）熏挎。
加速層：該層主要將大寬表拆為小寬表速勇，根據更新頻率配置不同的分區(qū)策略晌砾，減小數據冗余帶來的存儲壓力坎拐，提高查詢吞吐量。Doris 具備多表查詢和聯(lián)邦查詢性能特性养匈，可以利用多表關聯(lián)特性實現(xiàn)組合查詢哼勇。
應用層：DataSet 統(tǒng)一指向 Doris，Doris 支持外表查詢呕乎，利用該特性可對 ES 引擎直接查詢积担。
架構 2.0 存在的問題：
DataSet 靈活度較高，數據分析師可對指標和標簽自由組合和定義猬仁，但是不同的分析師對同一數據的定義不盡相同帝璧、定義口徑不一致，導致指標和標簽缺乏統(tǒng)一管理湿刽，這使得數據管理和使用的難度都變高的烁。
Dataset 與物理位置綁定，應用層無法進行透明優(yōu)化诈闺，如果 Doris 引擎出現(xiàn)負載較高的情況渴庆，無法通過降低用戶查詢避免集群負載過高報錯的問題。
數據架構 3.0
針對指標和標簽定義口徑不統(tǒng)一雅镊，數據使用和管理難度較高的問題襟雷，我們繼續(xù)對架構進行升級。數據架構 3.0 主要的變化是引入了專門的語義層仁烹，語義層的主要作用是將技術語言轉換為業(yè)務部門更容易理解的概念耸弄，目的是將標簽 (tag)與指標(metric)變?yōu)椤耙坏裙瘛保鳛閿祿x與管理的基本對象卓缰。
引入語義層的優(yōu)勢有：
對于技術來說叙赚，應用層不再需要創(chuàng)建 DataSet老客，從語義層可直接獲取特定內容對象的標簽集 (tagset)和指標集(metricset) 來發(fā)起查詢。
對于數據分析師來說震叮，可統(tǒng)一在語義層定義和創(chuàng)建衍生的指標和標簽胧砰，解決了定義口徑不一致、管理和使用難度較高的問題苇瓣。
對于業(yè)務來說尉间，無需耗費過長時間考慮什么場景應選擇哪個數據集使用，語義層對標簽和指標透明統(tǒng)一的定義提升了工作效率击罪、降低了使用成本哲嘲。
存在的問題：
從架構圖可知，標簽和指標等數據均處于下游位置媳禁，雖然標簽與指標在語義層被顯式定義眠副，但仍然無法影響上游鏈路，數倉層有自己的語義邏輯竣稽，加速層有自己的導入配置囱怕，這樣就造成了數據管理機制的割裂。
數據架構 4.0
在數據架構 3.0 的基礎上毫别，我們對語義層進行更深層次的應用娃弓，在數據架構 4.0 中，我們將語義層變?yōu)榧軜嫷闹袠泄?jié)點岛宦，目標是對所有的指標和標簽統(tǒng)一定義台丛，從計算-加速-查詢實現(xiàn)中心化、標準化管理砾肺，解決數據管理機制割裂的問題挽霉。
語義層作為架構中樞節(jié)點所帶來的變化：
數倉層：語義層接收 SQL 觸發(fā)計算或查詢任務。數倉從 DWD 到 DWS 的計算邏輯將在語義層中進行定義变汪，且以單個指標和標簽的形式進行定義侠坎，之后由語義層來發(fā)送命令，生成 SQL 命令給數倉層執(zhí)行計算疫衩。
加速層：從語義層接收配置硅蹦、觸發(fā)導入任務，比如加速哪些指標與標簽均由語義層指導闷煤。
應用層：向語義層發(fā)起邏輯查詢童芹，由語義層選擇引擎，生成物理 SQL鲤拿。
架構優(yōu)勢：
可以形成統(tǒng)一視圖假褪，對于核心指標和標簽的定義進行統(tǒng)一查看及管理。
應用層與物理引擎完成解耦近顷，可進一步對更加靈活易用的架構進行探索：如何對相關指標和標簽進行加速生音，如何在時效性和集群的穩(wěn)定性之間平衡等宁否。
存在的問題：
因為當前架構是對單個標簽和指標進行了定義，因此如何在查詢計算時自動生成一個準確有效的 SQL 語句是非常有難度的缀遍。如果你有相關的經驗慕匠，期待有機會可以一起探索交流。
優(yōu)化經驗
從上文已知域醇，為更好地實現(xiàn)業(yè)務需求台谊，數據架構演進到 4.0 版本，其中Apache Doris 作為分析加速場景的解決方案在整個系統(tǒng)中發(fā)揮著重要的作用譬挚。接下來將從場景需求锅铅、數據導入、查詢優(yōu)化以及成本優(yōu)化四個方面出發(fā)减宣，分享基于 Doris 的讀寫優(yōu)化經驗盐须，希望給讀者帶來一些參考。
場景需求
目前我們有 800+ 標簽漆腌， 1300+ 指標贼邓，對應 TDW 中有 80 + Source 表，單個標簽屉凯、指標的最大基數達到了 2 億+立帖。我們希望將這些數據從 TDW 加速到 Doris 中完成標簽畫像和指標的分析眼溶。從業(yè)務的角度悠砚，需要滿足以下要求：
實時可用：標簽/指標導入以后，需實現(xiàn)數據盡快可用堂飞。不僅要支持常規(guī)離線導入 T+1 灌旧，同時也要支持實時打標場景。
部分更新：因每個 Source 表由各自 ETL 任務產出對應的數據绰筛，其產出時間不一致枢泰，并且每個表只涉及部分指標或標簽，不同數據查詢對時效性要求也不同铝噩，因此架構需要支持部分列更新衡蚂。
性能高效：具備高效的寫入能力，且在圈選骏庸、洞察毛甲、報表等場景可以實現(xiàn)秒級響應。
控制成本：在滿足業(yè)務需求的前提下具被，最大程度地降低成本玻募；支持冷熱數據精細化管理，支持標簽靈活上下架一姿。
數據導入方案
為了減輕 Doris 寫入壓力七咧，我們考慮在數據寫入 Doris 之前跃惫，盡量將數據生成寬表，再寫入到 Doris 中艾栋。針對寬表的生成爆存，我們有兩個實現(xiàn)思路：第一個是在 TDW 數倉中生成寬表；第二個是 Flink 中生成寬表蝗砾。我們對這兩個實現(xiàn)思路進行了實踐對比终蒂，最終決定選擇第二個實現(xiàn)思路，原因如下：
在 TDW 中生成寬表遥诉，雖然鏈路簡單拇泣，但是弊端也比較明顯。
存儲成本較高矮锈， TDW 除了要維護離散的 80 +個 Source 表外霉翔，還需維護 1 個大寬表、2 份冗余的數據苞笨。
實時性比較差债朵，由于每個 Source 表產出的時間不一樣，往往會因為某些延遲比較大的 Source 表導致整個數據鏈路延遲增大瀑凝。
開發(fā)成本較高序芦，該方案只能作為離線方式，若想實現(xiàn)實時方式則需要投入開發(fā)資源進行額外的開發(fā)粤咪。
而在 Flink 中生成寬表谚中，鏈路簡單、成本低也容易實現(xiàn)寥枝，主要流程是：首先用 Spark 將相關 Source 表最新數據離線導入到 Kafka 中宪塔， 接著使用 Flink 來消費 Kafka，并通過主鍵 ID 構建出一張大寬表囊拜，最后將大寬表導入到 Doris 中某筐。如下圖所示，來自數倉 N 個表中 ID=1 的 5 條數據冠跷，經過 Flink 處理以后南誊，只有一條 ID=1 的數據寫入 Doris 中，大大減少 Doris 寫入壓力蜜托。
通過以上導入優(yōu)化方案抄囚，極大地降低了存儲成本， TDW 無需維護兩份冗余的數據盗冷，Kafka 也只需保存最新待導入的數據怠苔。同時該方案整體實時性更好且可控，并且大寬表聚合在 Flink 中執(zhí)行仪糖，可靈活加入各種 ETL 邏輯柑司，離線和實時可對多個開發(fā)邏輯進行復用迫肖，靈活度較高。
數據模型選擇
目前我們生產環(huán)境所使用的版本為 Apache Doris 1.1.3攒驰，我們對其所支持的 Unique 主鍵模型蟆湖、Aggregate 聚合模型和 Duplicate 明細模型進行了對比 ，相較于 Unique 模型和 Duplicate 模型玻粪，Aggregate 聚合模型滿足我們部分列更新的場景需求：
Aggregate 聚合模型可以支持多種預聚合模式隅津，可以通過REPLACE_IF_NOT_NULL的方式實現(xiàn)部分列更新。數據寫入過程中劲室，Doris 會將多次寫入的數據進行聚合伦仍，最終用戶查詢時，返回一份聚合后的完整且正確的數據很洋。
另外兩種數據模型適用的場景充蓝，這里也進行簡單的介紹：
Unique 模型適用于需要保證 Key 唯一性場景，同一個主鍵 ID 多次導入之后喉磁，會以 append 的方式進行行級數據更新谓苟，僅保留最后一次導入的數據。在與社區(qū)進行溝通后协怒，確定后續(xù)版本 Unique 模型也將支持部分列更新涝焙。
Duplicate 模型區(qū)別于 Aggregate 和 Unique 模型，數據完全按照導入的明細數據進行存儲孕暇，不會有任何預聚合或去重操作仑撞，即使兩行數據完全相同也都會保留，因此 Duplicate 模型適用于既沒有聚合需求芭商，又沒有主鍵唯一性約束的原始數據存儲派草。
確定數據模型之后搀缠，我們在建表時如何對列進行命名呢铛楣？可以直接使用指標或者是標簽的名稱嗎？
在使用場景中通常會有以下幾個需求：
為了更好地表達數據的意義艺普，業(yè)務方會有少量修改標簽簸州、指標名稱的需求。
隨著業(yè)務需求的變動歧譬，標簽經常存在上架岸浑、下架的情況。
實時新增的標簽和指標瑰步，用戶希望數據盡快可用矢洲。
Doris 1.1.3 是不支持對列名進行修改的，如果直接使用指標/標簽名稱作為列名缩焦，則無法滿足上述標簽或指標更名的需求读虏。而對于上下架標簽的需求责静，如果直接以 drop/add column 的方式實現(xiàn)，則會涉及數據文件的更改盖桥，該操作耗時耗力灾螃，甚至會影響線上查詢的性能。
那么揩徊，有沒有更輕量級的方式來滿足需求呢腰鬼？接下來將為大家分享相關解決方案及收益：****
為了實現(xiàn)少量標簽、指標名稱修改塑荒，我們用 MySQL 表存儲相應的元數據熄赡，包括名稱、全局唯一的 ID 和上下架狀態(tài)等信息齿税，比如標簽歌曲名稱song_name的 ?ID 為 4本谜，在 Doris 中存儲命名為 a4，用戶使用更具有業(yè)務含義song_name進行查詢偎窘。在查詢 Doris 前乌助，我們會在查詢層將 SQL 改寫成具體的列名 a4。這樣名稱的修改只是修改其元數據陌知，底層 Doris 的表結構可以保持不變他托。
為了實現(xiàn)標簽靈活上下架，我們通過統(tǒng)計標簽的使用情況來分析標簽的價值仆葡，將低價值的標簽進入下架流程赏参。下架指的是對元信息進行狀態(tài)標注，在下架標簽重新上架之前沿盅，不會繼續(xù)導入其數據把篓，元信息中數據可用時間也不會發(fā)生變化。
對于實時新增標簽/指標腰涧，我們基于名稱 ID 的映射在 Doris 表中預先創(chuàng)建適量 ID 列韧掩，當標簽/指標完成元信息錄入后，直接將預留的 ID 分配給新錄入的標簽/指標窖铡，避免在查詢高峰期因新增標簽/指標所引起的 Schema Change 開銷對集群產生的影響疗锐。經測試，用戶在元信息錄入后 10 分鐘內就可以使用相應的數據费彼。
值得關注的是滑臊，在社區(qū)近期發(fā)布的 1.2.0 版本中，增加了 Light Sche****ma Change 功能箍铲， 對于增減列的操作不需要修改數據文件雇卷，只需要修改 FE 中的元數據，從而可以實現(xiàn)毫秒級的 Schame Change 操作。同時開啟 Light Schema Change 功能的數據表也可以支持列名的修改关划，這與我們的需求十分匹配膘融，后續(xù)我們也會及時升級到最新版本。
寫入優(yōu)化
接著我們在數據寫入方面也進行了調整優(yōu)化祭玉，這里幾點小經驗與大家分享：
Flink 預聚合：通過主鍵 ID 預聚合氧映，減少寫入壓力。（前文已說明脱货，此處不再贅述）
寫入 Batch 大小自適應變更：為了不占用過多 Flink 資源岛都，我們實現(xiàn)了從同一個 Kafka Topic 中消費數據寫入到不同 Doris 表中的功能，并且可以根據數據的大小自動調整寫入的批次振峻，盡量做到攢批低頻寫入臼疫。
Doris 寫入調優(yōu)：針對- 235 報錯進行相關參數的調優(yōu)。比如設置合理的分區(qū)和分桶（Tablet 建議1-10G）扣孟，同時結合場景對 Compaction 參數調優(yōu)：
max_XXXX_compaction_thread
max_cumulative_compaction_num_singleton_deltas
優(yōu)化 BE 提交邏輯：定期緩存 BE 列表烫堤，按批次隨機提交到 BE 節(jié)點，細化負載均衡粒度凤价。
優(yōu)化背景：在寫入時發(fā)現(xiàn)某一個 BE負載會遠遠高于其他的 BE鸽斟，甚至出現(xiàn) OOM。結合源碼發(fā)現(xiàn)：作業(yè)啟動后會獲取一次 BE 地址列表利诺，從中隨機選出一個 BE 作為 Coordinator 協(xié)調者富蓄，該節(jié)點主要負責接收數據、并分發(fā)到其他的 BE 節(jié)點慢逾，除非作業(yè)異常報錯立倍，否則該節(jié)點不會發(fā)生切換。
對于少量 Flink 作業(yè)大數據場景會導致選中的 BE 節(jié)點負載較高侣滩，因此我們嘗試對 BE 提交邏輯進行優(yōu)化口注，設置每 1 小時緩存一次 BE 列表，每寫入一個批次都隨機從 BE 緩存列表中獲取一個進行提交君珠，這樣負載均衡的粒度就從 job 級別細化到每次提交的批次寝志，使得 BE 間負載更加的均衡，這部分實現(xiàn)我們已經貢獻到社區(qū)葛躏，歡迎大家一起使用并反饋澈段。
https://github.com/apache/doris-spark-connector/pull/59
https://github.com/apache/doris-spark-connector/pull/60
https://github.com/apache/doris-spark-connector/pull/61
通過以上數據導入的優(yōu)化措施，使得整體導入鏈路更加穩(wěn)定舰攒，每日離線導入時長下降了 75%?，數據版本累積情況也有所改善悔醋，其中 cumu compaction 的合并分數更是從 600+直降到 100 左右摩窃，優(yōu)化效果十分明顯。
查詢優(yōu)化
目前我們的場景指標數據是以分區(qū)表的形式存儲在 Doris 中， ES 保留一份全量的標簽數據猾愿。在我們的使用場景中鹦聪，標簽圈選的使用率很高，大約有 60% 的使用場景中用到了標簽圈選蒂秘，在標簽圈選場景中泽本，通常需要滿足以下幾個要求：
用戶圈選邏輯比較復雜，數據架構需要支持同時有上百個標簽做圈選過濾條件姻僧。
大部分圈選場景只需要最新標簽數據规丽，但是在指標查詢時需要支持歷史的數據的查詢。
基于圈選結果撇贺，需要進行指標數據的聚合分析赌莺。
基于圈選結果，需要支持標簽和指標的明細查詢松嘶。
經過調研艘狭，我們最終采用了Doris on ES 的解決方案來實現(xiàn)以上要求，將 Doris 的分布式查詢規(guī)劃能力和 ES 的全文檢索能力相結合翠订。Doris on ES 主要查詢模式如下所示：
SELECTtag,?agg(metric)FROMDorisWHEREidin(selectidfromEswheretagFilter)GROUPBYtag
在 ES 中圈選查詢出的 ID 數據巢音，以子查詢方式在 Doris 中進行指標分析。
我們在實踐中發(fā)現(xiàn)尽超，查詢時長跟圈選的群體大小相關港谊。如果從 ES 中圈選的群體規(guī)模超過 100 萬時，查詢時長會達到 60 秒橙弱，圈選群體再次增大甚至會出現(xiàn)超時報錯歧寺。經排查分析，主要的耗時包括兩方面：
BE 從 ES 中拉取數據（默認一次拉取 1024 行）棘脐，對于 100 萬以上的群體斜筐，網絡 IO 開銷會很大。
BE 數據拉取完成以后蛀缝，需要和本地的指標表做 Join顷链，一般以 SHUFFLE/BROADCAST 的方式，成本較高屈梁。
針對這兩點嗤练，我們進行了以下優(yōu)化：
增加了查詢會話變量es_optimize，以開啟優(yōu)化開關在讶；
數據寫入 ES 時煞抬，新增 BK 列用來存儲主鍵 ID Hash 后的分桶序號，算法和 Doris 的分桶算法相同（CRC32）构哺；
BE 生成 Bucket Join 執(zhí)行計劃革答，將分桶序號下發(fā)到 BE ScanNode 節(jié)點战坤，并下推到 ES；
ES 對查詢出的數據進行 Bitmap 壓縮残拐，并將數據的多批次獲取優(yōu)化為一次獲取途茫，減少網絡 IO 開銷；
Doris BE 只拉取和本地 Doris 指標表相關 Bucket 的數據溪食，直接進行本地 Join囊卜，避免 Doris BE 間數據再 Shuffle 的過程。
通過以上優(yōu)化措施错沃，百萬分群圈選洞察查詢時間從最初的 60 秒縮短到 3.7 秒栅组，性能顯著提升！
經過與社區(qū)溝通交流捎废，Apache Doris 從 2.0.0 版本開始笑窜，將支持倒排索引〉橇疲可進行文本類型的全文檢索排截；支持中文、英文分詞辐益；支持文本断傲、數值日期類型的等值和范圍過濾；倒排索引對數組類型也提供了支持智政，多個過濾條件可以任意進行 AND OR NOT 邏輯組合认罩。由于高性能的向量化實現(xiàn)和面向 AP 數據庫的精簡優(yōu)化，Doris 的倒排索引相較于 ES 會有 3~5 倍性價比提升续捂，即將在 2 月底發(fā)布的 2.0 preview 版本中可用于功能評估和性能測試垦垂，相信在這個場景使用后會有進一步的性能提升。
成本優(yōu)化
在當前大環(huán)境下牙瓢，降本提效成為了企業(yè)的熱門話題劫拗，如何在保證服務質量的同時降低成本開銷，是我們一直在思考的問題矾克。在我們的場景中页慷，成本優(yōu)化主要得益于 Doris 自身優(yōu)秀的能力，這里為大家分享兩點：
1胁附、冷熱數據進行精細化管理酒繁。
利用 Doris TTL 機制，在 Doris 中只存儲近一年的數據控妻，更早的數據放到存儲代價更低的 TDW 中州袒；
支持分區(qū)級副本設置，3 個月以內的數據高頻使用饼暑，分區(qū)設置為 3 副本 稳析；3-6 個月數據分區(qū)調整為 2 副本洗做；6 個月之前的數據分區(qū)調整為1 副本弓叛；
支持數據轉冷彰居， 在 SSD 中僅存儲最近 7 天的數據，并將 7 天之前的數據轉存到到 HDD 中撰筷，以降低存儲成本陈惰；
標簽上下線，將低價值標簽和指標下線處理后毕籽，后續(xù)數據不再寫入抬闯，減少寫入和存儲代價。
2关筒、降低數據鏈路成本溶握。
Doris 架構非常簡單，只有FE 和 BE 兩類進程蒸播，不依賴其他組件睡榆，并通過一致性協(xié)議來保證服務的高可用和數據的高可靠，自動故障修復袍榆，運維起來比較容易;
高度兼容 MySQL 語法，支持標準 SQL，極大降低開發(fā)人員接入使用成本弥激；
支持多種聯(lián)邦查詢方式孩饼，支持對 Hive、MySQL才写、Elasticsearch 葡兑、Iceberg 等組件的聯(lián)邦查詢分析，降低多數據源查詢復雜度赞草。
通過以上的方式讹堤，使得存儲成本降低 42%，開發(fā)與時間成本降低了 40%?房资，成功實現(xiàn)降本提效蜕劝，后續(xù)我們將繼續(xù)探索！
未來規(guī)劃
未來我們還將繼續(xù)進行迭代和優(yōu)化轰异，我們計劃在以下幾個方向進行探索：
實現(xiàn)自動識別冷熱數據岖沛，用 Apache Doris 存儲熱數據，Iceberg 存儲冷數據搭独，利用 Doris 湖倉一體化能力簡化查詢婴削。
對高頻出現(xiàn)的標簽/指標組合，通過 Doris 的物化視圖進行預計算牙肝，提升查詢的性能唉俗。
探索 Doris 應用于數倉計算任務嗤朴，利用物化視圖簡化代碼邏輯，并提升核心數據的時效性虫溜。
最后雹姊，感謝 Apache Doris 社區(qū)和?SelectDB?的同學，感謝其快速響應和積極支持衡楞，未來我們也會持續(xù)將相關成果貢獻到社區(qū)吱雏，希望 Apache Doris 飛速發(fā)展，越來越好瘾境！
# 相關鏈接：
SelectDB 官網：
Apache Doris 官網：
Apache Doris Github：
