作者簡介

攜程OLAP引擎開發組，專注于大數據OLAP引擎trino/starrocks的開發與大規模部署和運維。

一、背景

數據報表平臺（代稱Nova，后同）用于支持攜程內部數據分析、數據挖掘、數據可視化等業務需求，目前每日承載數十萬Hive表AP查詢，所涉數據量達萬億級別。隨著用戶基數逐步提升，承載查詢量不斷增大，平臺查詢性能面臨挑戰，具體表現如下：

1）平均響應時間延長，大查詢在業務高峰期存在阻塞現象，超時數量增多；

2）查詢所需時間不穩定，性能波動較大，在業務高峰期可能出現響應時間突增現象；

3）查詢負載集群資源占用率高，CPU、內存資源吃緊，I/O 請求排隊等待，進而導致集群穩定性下降，時有節點宕機現象出現。

針對上述現象，我們從平臺自身服務、SQL路由分發組件、SQL執行引擎等方面入手，采用了一套“全方位組合拳”對平臺的查詢性能進行治理，目標有二：

1）從用戶體驗角度：改善查詢性能，提升查詢效率和穩定性；

2）從集群維護角度：提升集群穩定性，增強查詢結果復用能力，提高算力使用效率。

二、平臺設計概覽

數據報表平臺執行查詢的主要鏈路如圖1所示，其中有幾個關鍵構件：

圖1：Nova 數據查詢鏈路

1）Nova：應用本體，提供可視化用戶界面，包含報表即時查詢、執行離線定時任務等功能；

2）Router：用于分離指向不同引擎的查詢請求，起到SQL路由功能；

3）Starrocks & Hive：平臺使用Starrocks作為主要查詢引擎，向Hive外表發起查詢請求。

三、多維度數據緩存

在硬件資源有限的情況下，要提升查詢性能，最直觀的思想是對重復的查詢進行結果復用。在對平臺的查詢請求數據進行統計分析后，可發現存在相當數量的查詢請求在不同時段內重復出現，這為我們引入緩存機制提供了實踐基礎。

若將在執行過程中可能遭遇瓶頸的查詢進行劃分，可將大致分為I/O型、計算型和高頻型三類，其中I/O型查詢對網絡和磁盤帶寬的要求較高，往往涉及大規模數據的掃描；計算型查詢對CPU和內存資源的要求較高，往往涉及大量連接、分組、聚合、篩選、再計算操作；高頻型查詢的單次調用開銷可能較小，但在單位時間內發起的次數顯著高于均值，在涉及遠程調用（如元數據獲取）的環節可能遭遇性能瓶頸，且在單位時間造成的資源開銷可能與大查詢相當。

圖2：受限查詢分類

目前，在整個數據查詢鏈路中，我們在以下幾個環節引入了緩存機制，以應對不同類型查詢所帶來的挑戰。

3.1 底表Data Cache預熱

當Starrocks從Hive外表進行數據查詢時，Scan算子會將所需數據文件以塊的形式讀取至本地。對于典型的I/O型查詢而言，這個過程所需時間可達整個查詢流程耗時的70%以上。在業務高峰期，由于大量查詢請求同時發起，I/O型查詢的堆積將導致其他查詢請求讀取數據文件的等待時間增長，進而影響查詢響應時間。

針對這類情況，我們在Starrocks集群中開啟了Data Cache，將每次讀取得到的文件塊標識并臨時存儲在本地磁盤中，在下次查詢請求需要相同文件塊時，若發現該文件塊沒有更新，則直接從本地磁盤讀取，避免了經由網絡和Hive帶來的文件讀取延遲。

通過Data Cache緩存的文件塊在Starrocks中由帶冷熱分區的LRU隊列維護，當隊列滿時，將根據文件塊的訪問頻率和時間戳進行淘汰，以保證緩存的命中率。

從緩存一致性角度，Starrocks在使用Data Cache時，會通過元數據判斷底表數據是否發生更新，若發現數據文件已更新，則將廢棄緩存數據，重新拉取底表數據文件，以保證查詢結果的準確性。

3.1.1 預熱機制

通過對查詢請求命中底表的情況進行統計，可發現其中熱點表的使用呈現一定的規律性（如：每日相近時刻、每周固定幾日訪問量達峰等）。為此，我們為統計得到的各熱點表建立了用戶畫像，記錄并預測其訪問高峰。

圖3：預熱機制

通過在業務高峰到來前將熱點表數據主動Cache預熱，可進一步分散業務高峰期的I/O壓力。如圖4 所示，這部分主動指定Cache的數據文件將會優先被置入LRU隊列的熱區，以保證其在高峰期的查詢中能夠被快速命中。

圖4：Data Cache LRU 隊列

3.2 HDFS元數據緩存

在Starrocks查詢引擎執行查詢時，需要獲取Hive表的元數據信息，如表的列信息、分區信息、表的存儲格式；HDFS File的元數據信息，如block塊屬性等。Starrocks將通過這些信息來生成最優的執行計劃。在業務高峰期，大量并發查詢可能導致Hadoop Namenode的元數據請求壓力過大，進而影響查詢的執行效率。

Starrocks原有的元數據緩存時間較短，這是因為其無法實時感知HDFS File文件變化。為防止緩存不一致，原有的Remote File元數據緩存時間不宜設置過長，但這會導致即使元數據未更新，在某些場景下Starrocks也會頻繁發起重復的元數據請求。

為此，我們選擇在Starrocks的FE側通過元數據接口（該接口調用開銷遠小于元數據的獲取）對元數據的新鮮度進行檢測，僅在遠端元數據發生更新時拉取元數據，此功能可使得Remote File緩存時長延長至6小時，在保證緩存一致性的同時，提升相同元數據的復用程度。

3.3 Router Redis 緩存

當數據從查詢引擎返回至Router時，Router會將查詢結果進行緩存，以便后續面對完全相同的查詢請求，可直接從緩存中獲取結果，避免重復計算。

在緩存一致性方面，Router同樣可通過血緣信息實時獲取底表數據的更新時間，從而判斷緩存數據是否過期。在緩存數據過期時，Router將棄用緩存數據，重新執行查詢，以保證查詢結果的準確性。

3.4 Download 緩存

對于查得的報表數據，平臺支持用戶將數據下載至本地，以便用戶進一步分析。在實踐過程中我們發現，部分報表數據除了在查詢后被即時下載外，還可能需要在未來的某個時間點被再次下載（如瀏覽器關閉后）。這種行為將觸發二次查詢，導致相同請求被反復執行以滿足下載需求。

針對這種現象，我們在Download服務中同樣引入了緩存機制，將下載的數據進行緩存，以便后續相同的下載請求直接從緩存中獲取數據。

圖5：Download 緩存

3.5 小結

如圖6所示，通過引入多維度數據緩存機制，我們在平臺的數據傳輸的全鏈路中，盡可能實現了對重復數據的復用。而為了進一步提升在計算過程中，數據和算力的使用效率，我們進一步在物化視圖的使用上進行了探索。

圖6：查詢鏈路緩存總覽

四、使用物化視圖加速查詢

物化視圖（Materialized View, MV）作為一種預先計算的結果集，可以有效減少查詢時的計算量，提升查詢性能。面對計算型查詢，MV可以將查詢計算的部分結果進行固化存儲，避免復雜計算邏輯的重復執行；面對I/O型查詢，MV可以將查詢所需數據進行預聚合，減少數據掃描的規模，或者更簡單地，將需要頻繁查詢的數據底表保存為MV，作為優先級更高的Data Cache來使用，使得對Hive外表的查詢達到和Starrocks內表一致的查詢性能。不過，想要發揮MV的優勢，需要解決如下幾個問題：

1）視圖定義：如何創建有效的MV；

2）視圖利用：如何在查詢時高效地利用MV；

3）視圖維護：如何保證MV的新鮮度。

4.1 視圖定義：為數據集構建MV

在Nova平臺構建數據報表時，用戶首先需要創建數據集，最終在數據集定義的范圍內進行數據查詢、生成可視化報表。這一特點使得在選擇MV的目標時，將數據集作為構建對象是一個較為合適的選擇，因為它代表著一系列特定業務邏輯的公共數據查詢需求。

在用戶自定義的數據集中，視構建MV的難度，可將數據集分為以下三類：

1）靜態數據集：數據集的定義不隨使用時間、用戶及其他環境因素發生變化，在底表數據不發生變化的前提下，執行任意次查詢都將返回相同結果。此類數據集在構建一次MV后便無需再次修改視圖定義；

2）半靜態數據集：數據集的定義按日（或更長的時間單位）進行更新，但其可變部分僅限于日期（配置了日期變參）。面對此種類型的數據集，需要構建模板，按日重新渲染視圖；

3）動態數據集：即使數據集所涉底表的數據未有更新，但隨查詢的執行時間不同（如包含CURRENT_TIMESTAMP函數或RAND函數等）、執行查詢的用戶不同（數據集配置了用戶變參）、查詢的上下文參數不同（數據集配置了自定義變量）等，查詢結果也會發生變化。此類數據集的MV構建較為困難，需要進一步拆解數據集的定義，分離得到其中靜態的部分以構建MV，其極端情況為僅對數據集的底表進行物化。

通過將半靜態或動態數據集轉換為靜態形式，并對靜態數據集構建MV，可將各類查詢的中間計算結果進行固化，在確保MV所涉數據底表中的數據沒有更新的前提下，可將MV中的數據進行重復利用。

4.2 視圖利用：MV自動改寫

面對一個潛在的可利用已有MV數據的查詢，Starrocks提供MV自動改寫的能力，可將查詢計劃中的相關計算邏輯改寫為直接從MV進行讀取，從而減少查詢的計算量。

Starrocks提供兩類視圖改寫規則：SPJG改寫和文本匹配改寫。

4.2.1 SPJG模式改寫

SPJG模式改寫是一種基于邏輯計劃的改寫規則，其原理基于這篇論文：《Optimizing Queries Using Materialized Views: A Practical, Scalable Solution》。

這種改寫規則的核心思想在于：首先確保查詢（或某一邏輯子樹構成的查詢）所需的全部數據均可由MV查詢得到，隨后計算查詢與MV間的謂詞差異（稱為補償謂詞），應用至可用于改寫的視圖上，構成一個新的查詢計劃。圖7 是改寫規則生效的一個示例。

圖7：SPJG模式改寫示例

SPJG模式改寫的優勢在于，面對建立在相同數據集上的各類不同查詢，Starrocks可根據實際情況靈活復用已經在MV中完成預計算的數據，從而達成“一次計算，多次使用”的目的。

不過，由于這種改寫的復雜性，目前僅支持對只包含Select、Project、Join和Group-By這四類算子（SPJG）的查詢計劃樹（或邏輯子樹）進行改寫，而在涉及Union、Order-By、Limit等算子的查詢改寫時能力受限。面對復雜的數據集，更具實踐性的做法是抽取出其中的SPJG模式子樹用于創建MV，以擴展MV的適用范圍，增大匹配改寫成功率。

4.2.2 文本匹配改寫

文本匹配改寫是一種基于抽象語法樹（AST）的改寫規則，通過比對Query和MV規范化后的AST是否一致，可判斷是否可以將查詢改寫至MV上。

這種改寫的優勢在于可支持更多類型算子的查詢改寫，但其改寫的自由度和適應性不如SPJG模式改寫，一旦數據集或查詢的SQL結構在處理過程中發生變化，則文本匹配改寫可能無法發揮作用。

4.2.3 改寫數據一致性

通過合理利用上述兩類MV改寫規則，可做到以用戶無感的方式，自動復用中間計算結果，在節約計算資源的同時大幅提升復雜查詢的效率。

值得一提的是，在數據一致性方面，Starrocks在執行查詢改寫流程時，會自動檢測MV中的數據是否過期，若是，則放棄改寫，執行原有查詢計劃。這使得引入MV查詢改寫機制后，在達成查詢加速效果的同時，依然能夠保證查詢結果的準確性。

而由于此機制的存在，截至目前，Starrocks在執行MV改寫時，若發現MV本身的定義中包含非確定返回值（Non-deterministic）函數，例如CURRENT_DATE 和 RAND等，將棄用此MV，這是因為Starrocks無法保證MV返回的結果在當前時刻下依然可用。因此，在選擇數據集進行物化時，必須先確保數據集的定義為靜態，這也是“視圖定義”小節對數據集分類的重要意義所在。

4.2.4 CURRENT_DATE函數改寫問題

在構建MV時，我們發現部分數據集的定義中包含CURRENT_DATE函數，而并未使用平臺提供的日期變參（$EFFECTDATE）。這將導致即使數據集SQL的文本定義未發生變化，隨著時間推進，數據集本身所指代的數據范圍卻按日發生變化。

與平臺提供的日期變參不同的是，CURRENT_DATE函數在執行時不會被替換為具體日期，而是在查詢時由執行引擎動態計算，這使得查詢引擎在執行改寫操作時，將由于涉及非確定返回值函數而棄用此類數據集對應的MV，使得這類本該滿足半靜態數據集條件的數據集需要被作為動態數據集處理。

經統計，報表平臺中目前有相當數量的數據集定義，其可變部分僅為CURRENT_ DATE函數，為提升對此類數據集的物化能力，我們在平臺側引入了重渲機制，在將查詢請求提交至引擎前，會將CURRENT_DATE函數以和EFFECTDATE變參類似的方式重渲為具體日期，從而保證查詢引擎的改寫機制能夠正常生效。

4.3 視圖維護：MV自動刷新

在確保MV SQL為靜態的前提下，MV的數據新鮮度僅和底表數據是否更新有關。通過分析MV創建語句中SQL所涉及的底表追溯血緣依賴關系，并通過元數據服務獲取底表的最近更新時間，可創建自動化應用實時監控MV是否過期，并根據實際情況選擇是否刷新MV。

4.4 MV價值發掘

為數據集創建MV并不一定必然為平臺的查詢性能帶來優化，原因可羅列為以下幾點：

1）MV的創建和維護需要消耗額外的計算資源，每一次刷新都對應一次對數據集的查詢操作。若MV的使用率較低，其帶來的性能提升可能無法彌補其維護成本；

2）部分數據集在定義時所涉及的數據范圍遠大于真正使用所需，在直接執行查詢操作時，可通過謂詞下推等優化操作過濾掉不必要的掃描范圍，而如果為此類數據集創建MV，將反而導致更大的全局計算開銷；

3）Starrocks集群能夠提供的磁盤空間有限，不可能為所有數據集都創建MV來優化。在有限的資源下，需保證“好鋼用在刀刃上”，優先創建有較大查詢性能提升潛力的MV進行創建。

為此，我們在MV的選擇過程中，引入了MV價值評估機制，通過綜合分析數據集的使用頻率、數據集計算及相關查詢的計算代價、數據集的數據規模等多個維度，為數據集的MV創建提供參考。以查詢所消耗的CPU代價為例，建立MV前后的所節省的計算代價可使用如下公式計算：

為精確捕獲查詢執行或數據集刷新的計算代價，我們會將統計得到的待改寫查詢（高代價或高頻查詢）在獨立環境下執行預跑，獲取量化數據作為評估的依據，大致測試流程如圖8所示。

圖8：MV價值評估流程

4.5 小結

通過選取合適的數據集構建MV，并利用Starrocks的自動改寫能力加速查詢，可在一定程度上規避平臺在計算過程中的出現的短板，補足全查詢鏈路的數據復用能力，使得數據報表平臺面對不同類型的高負載查詢，有更加成熟、可靠、易維護的應對方案。

五、查詢策略優化和SQL質量治理

目前，數據報表平臺所承載的查詢任務主要分為兩類：一是即時報表查詢，用戶通過Web界面即時運行查詢并獲取數據報表；二是離線定時任務調度，用戶通過配置定時任務執行查詢，任務觸發后用戶可通過郵件等途徑獲取數據。

這兩類查詢任務分別存在以下特征：

1）即時報表查詢：觸發時間隨機，由用戶自主觸發，查詢請求所涉計算量相對較小，但對查詢響應時間更為敏感，一般要求在數秒內返回結果；

2）離線定時任務調度：觸發時間固定，由預注冊的計劃周期性自動觸發，查詢需要計算的數據量往往較大，但對查詢響應時間要求相對較低，一般可容忍的查詢響應延遲較寬。

立足于平臺自身的業務場景思考，可發現以下痛點：

1）負載不均問題：平臺執行查詢的高峰和低谷期分明，需要調整定時任務調度策略，以平滑負載；

2）資源爭用問題：相同時間段內，不同查詢間存在資源爭用，例如離線定時任務的執行可能影響同期即時報表查詢的性能；

3）慢查詢問題：部分查詢請求自身所需的計算資源過大，或是配置的計算邏輯不佳，可能對平臺造成過量負載。

對于慢查詢問題，其成因可能有多種，包括但不限于以下幾點：

1）平臺查詢策略問題：面對特定查詢，原有的實現或查詢策略在執行時性能較差，需要進行改進；

2）查詢SQL實現欠優：查詢SQL在實現上存在質量問題，在執行時消耗的計算量遠大于業務邏輯所需，可能引入大量非必要的底表掃描和計算操作，需要整治優化；

3）業務需求：即使優化了查詢策略和SQL質量，仍有部分查詢請求所需計算量較大，對于其中涉及關鍵業務的部分，可能需要整合計算資源，以專門提升這類查詢的性能。

在本節中，將分別對目前我們針對上述痛點所做的工作進行闡述。

5.1 整點調度問題治理

Nova平臺所提供的離線任務定時調度功能，由用戶根據所需自行配置任務的觸發時間。但出于用戶習慣，可發現大量查詢都被設置在整點進行調度，這導致平臺在整點出現查詢負載高峰。

通過對此業務場景的痛點進行分析，我們采用了兩種策略來解決整點調度問題。

一方面，通過與用戶溝通，我們提出了“錯峰調度”策略，即在原有配置的基礎上，對部分任務進行時間錯峰調度，以減少整點負載高峰。例如，原定于每日九點執行的調度任務，可能被延遲至九點十分執行。這種策略在一定程度上緩解了整點負載高峰的問題，而不至于為用戶帶來過多的使用不便。

另一方面，我們提供了“依賴調度”方案，即不再以時間，而是以數據更新為觸發條件進行調度。報表元數據完成更新時間的隨機性，使得這種調度方式可變相地起到“錯峰調度”的作用，且通過數據更新作為觸發條件，可使得報表數據新鮮度具有更加便捷的維護方式。

5.2 查詢流量切分

資源隔離是避免查詢請求相互干擾的有效手段。通過將平臺的查詢請求按照類型進行切分，能夠有效提升查詢請求的執行效率。

平臺的原有的查詢請求路由策略僅根據用戶指定的查詢引擎類型進行請求分流，而根據即時報表查詢和離線調度查詢的特征，我們選擇進一步改進路由策略，將這兩類查詢請求分發至不同的Starrocks集群，防止離線調度過高的查詢負載對即時報表查詢的響應時間造成影響。

另外，通過對平臺每日查詢性能數據進行分析，可識別得到一系列慢查詢請求，這些SQL需要我們根據實際情況細分，并逐步對其進行優化。為避免這些查詢請求對平臺中其他查詢的性能造成影響，我們選擇將這類查詢分發至專門用于處理待優化查詢的獨立Starrocks集群，以減輕對主集群的壓力。

圖9：查詢流量切分

5.3 Max-d查詢專項治理

在各類數據集的查詢中，有一類典型的SQL在實際查詢時將引入極高的查詢代價。這類查詢在對數據條目的日期d進行篩選時，使用max(d)子查詢作為謂詞判斷依據，以獲取數據集中所包含的最新一日的數據進行計算，SQL示例如下所示：

此種查詢結構將導致查詢引擎在實際執行查詢時，對數據表的每一行數據都觸發一次全表掃描的子查詢調用，隨著數據表數據量的上升，這種查詢的查詢代價將呈二次函數倍率增長，產生難以忽視的性能開銷。

面對這類查詢，我們對其執行策略分兩期進行了專項優化。

第一期，在Router側，通過對查詢SQL的AST進行模式匹配，可篩得存在Max-d問題的查詢請求。在此基礎上，我們將這類查詢的執行策略拆分為兩階段：首先執行max(d)子查詢，獲取最新日期d的值，隨后將此實值作為謂詞條件對原查詢進行改寫后執行。

通過這種方式，不但可解決原有的嵌套查詢問題，將查詢掃表的時間復雜度由O(N2)降至O(N)，還可進一步觸發Starrocks的列分區裁剪行為，大幅減少這類查詢的計算代價。

第二期，在Nova平臺側，直接通過配置變參方式替換Max-d SQL，然后獲取MetaStore元數據最新分區替換變量。此舉可提升這種執行機制的可維護性，且max(d)值在計算前即可獲取，能夠進一步提升優化后的查詢性能。

5.4 SQL實現優化

查詢效率優化的核心在于提升查詢的執行速度、降低資源消耗，然而單從查詢的執行側進行優化，對于存在潛在質量問題的SQL，仍然難以解決根本病因。通過分析歸納用戶提交的SQL中可能導致查詢效率低下的原因，我們與用戶協調，開展了以下幾類SQL語句優化工作。

5.4.1 distinct * 語句刪減

在撰寫SQL時，為保證查詢結果的唯一性，用戶可能會習慣性地添加distinct * 子句進行去重，然而這種操作涉及到全表數據行、全字段域的掃描去重，當目標數據集合行數或列數較多時，將產生大量的cpu和內存資源開銷。

為減少這類查詢的資源消耗，我們向用戶提出了兩項修改建議：

1）檢查在使用distinct * 前，計算結果是否已由上游數據源或計算操作去重，避免重復引入去重操作；

2）檢查當前去重操作是否必要，是否必須對全部字段進行去重，盡可能減少對去重操作的依賴。

5.4.2 數據表拆分

通過對部分復雜的查詢邏輯進行分析，可發現其主要原因是數據模型設計不合理，對應的數據表拆分不當，例如一些權限表和靜態信息表存在嚴重耦合，致使計算邏輯復雜，查詢數據量大。

對于這類問題，重新設計底表數據模型，將非必要的耦合部分進行子表拆分，重新定義數據集和報表計算流程，往往可以起到理想的性能優化效果。

5.4.3 限制查詢分區

部分用戶在創建SQL（主要是定義數據集）時，未對數據查詢范圍進行限制，或所做限制缺乏發展性考慮。例如，對一個按日分區的數據表，簡單地將數據表查詢范圍設置為 d > 2022-01-01，而未配置動態參數。隨著時間積累，此類數據集的查詢資源開銷將逐步上升，出現查詢性能劣化現象。

在一個SQL被執行時，所涉底表分區的數量可能會對查詢性能產生重要影響，因為它對應著查詢涉及的目標點位數量。為提升此類數據集的查詢性能，我們向用戶提出了限制查詢分區的建議，例如根據所需添加動態日期范圍限制，保證報表數據計算的可持續發展性。

5.5 潛在慢查詢阻斷機制

為防止未經優化的SQL對平臺的查詢性能造成影響，我們在平臺側引入了慢查詢阻斷機制，對用戶提交的SQL進行檢查，判斷其是否滿足執行標準，目前主要涉及以下兩個點位：

1）平臺規范卡點：當用戶在平臺新增或修改數據集/報表時，平臺將對用戶提交的SQL進行檢查，判斷其是否滿足規范。目前，上述規范將檢查用戶提交查詢的掃描行數、查詢耗時和占用內存，而后續將進一步補充對Join連接數、底表個數、Union操作個數、所涉分區數等指標的檢查，以保證用戶提交的SQL質量符合平臺的執行標準。

2）Starrocks熔斷機制：當Starrocks為查詢請求生成執行計劃，發現待掃描的文件數和分區數量過大時，將觸發熔斷機制，跳出此次查詢的執行，并返回錯誤信息。

六、成效

通過以上一系列的查詢性能治理措施，我們在數據報表平臺的查詢性能上達成了階段性目標，平臺查詢性能逐步穩定，具體表現如下：

1）查詢平均響應時間降低：在業務高峰期，平臺的查詢平均響應時間從原來的8秒降低至4秒；

2）查詢超時數量顯著降低：查詢時間90線由原先的約18秒降低至約8秒，由超時導致的查詢失敗量由日均7000次縮減至日均1400次；

3）查詢性能波動幅度減小：平臺每日平均查詢性能指標趨于平滑，全平臺查詢時間標準差由原來的約25秒縮短至14秒左右；

圖10：查詢響應時間統計

對平臺所承載的各類大查詢而言，本文所述的治理策略起到的優化作用尤為明顯，由圖11可見，長耗時查詢數量在治理措施實施后呈明顯下降趨勢。

圖11：長耗時查詢數量變化趨勢

七、總結

通過本文所述內容，我們采取了多項措施來對數據報表平臺的查詢效率進行治理。通過建立緩存機制、使用物化視圖，可提升查詢性能和算力使用效率；通過對查詢策略進行優化，可裁剪非必要開銷，解放平臺查詢瓶頸；通過切分流量和對SQL質量進行管控，可更好地實現資源隔離，提升平臺查詢質量。

未來，隨著治理措施的不斷演進，這些優化策略將被逐步規范化、集成化、自動化，以更好地服務于平臺的查詢需求。