Apache Doris 2.0 盲測性能 10 倍提升，更統一的多場景極速分析體驗！

親愛的社群小夥伴們，我們很高興地向大家宣布，Apache Doris 2.0-beta 版本已于 2023 年 7 月 3 日正式釋出！在 2.0-beta 版本中有超過 255 位貢獻者為 Apache Doris 送出了超過 3500 個優化與修複，歡迎大家下載下傳使用！

下載下傳連結：https://doris.apache.org/download

GitHub 源碼：https://github.com/apache/doris/tree/branch-2.0

在今年年初舉辦的 Doris Summit 年度峰會上，我們曾釋出了 Apache Doris 的 2023 年 Roadmap 并提出了新的願景：

我們希望使用者可以基于 Apache Doris 建構多種不同場景的資料分析服務、同時支撐線上與離線的業務負載、高吞吐的互動式分析與高并發的點查詢；通過一套架構實作湖和倉的統一、在資料湖和多種異構存儲之上提供無縫且極速的分析服務；也可通過對日志/文本等半結構化乃至非結構化的多模資料進行統一管理和分析、來滿足更多樣化資料分析的需求。

這是我們希望 Apache Doris 能夠帶給使用者的價值，不再讓使用者在多套系統之間權衡，僅通過一個系統解決絕大部分問題，降低複雜技術棧帶來的開發、運維和使用成本，最大化提升生産力。

面對海量資料的實時分析難題，這一願景的實作無疑需要克服許多困難，尤其是在應對實際業務場景的真實訴求中更是遭遇了許多挑戰：

• 如何保證上遊資料實時高頻寫入的同時保證使用者的查詢穩定；
• 如何在上遊資料更新及表結構變更的同時保證線上服務的連續性；
• 如何實作結構化與半結構化資料的統一存儲與高效分析；
• 如何同時應對點查詢、報表分析、即席查詢、ETL/ELT 等不同的查詢負載且保證負載間互相隔離？
• 如何保證複雜 SQL 語句執行的高效性、大查詢的穩定性以及執行過程的可觀測性？
• 如何更便捷地內建與通路資料湖以及各種異構資料源？
• 如何在大幅降低資料存儲和計算資源成本的同時兼顧高性能查詢？
• ……

秉持着“将易用性留給使用者、将複雜性留給自己”的原則，為了克服以上一系列挑戰，從理論基礎到工程實作、從理想業務場景到極端異常 Case、從内部測試通過到大規模生産可用，我們耗費了更多的時間與精力在功能的開發、驗證、持續疊代與精益求精上。值得慶祝的是，在經過近半年的開發、測試與穩定性調優後，Apache Doris 終于迎來了 2.0-beta 版本的正式釋出！而這一版本的成功釋出也使得我們的願景離現實更進一步！

盲測性能 10 倍以上提升！

全新的查詢優化器

高性能是 Apache Doris 不斷追求的目标。過去一年在 Clickbench、TPC-H 等公開測試資料集上的優異表現，已經證明了其在執行層以及算子優化方面做到了業界領先，但從 Benchmark 到真實業務場景之間還存在一定距離：

• Benchmark 更多是真實業務場景的抽象、提煉與簡化，而現實場景往往可能面臨更複雜的查詢語句，這是測試所無法覆寫的；
• Benchmark 查詢語句可枚舉、可針對性進行調優，而真實業務場景的調優極度依賴工程師的心智成本、調優效率往往較為低下且過于消耗工程師人力；

基于此，我們着手研發了現代架構的全新查詢優化器，并在 Apache Doris 2.0-beta 版本全面啟用。全新查詢優化器采取了更先進的 Cascades 架構、使用了更豐富的統計資訊、實作了更智能化的自适應調優，在絕大多數場景無需任何調優和 SQL 改寫即可實作極緻的查詢性能，同時對複雜 SQL 支援得更加完備、可完整支援 TPC-DS 全部 99 個 SQL。

我們對全新查詢優化器的執行性能進行了盲測，僅以 TPC-H 22 個 SQL 為例 ，全新優化器在未進行任何手工調優和 SQL 改寫的情況下 查詢耗時，盲測性能提升了超過 10 倍！而在數十個 2.0 版本使用者的真實業務場景中，絕大多數原始 SQL 執行效率得以極大提升，真正解決了人工調優的痛點！

參考文檔：https://doris.apache.org/zh-CN/docs/dev/query-acceleration/nereids

如何開啟：SET enable_nereids_planner=true 在 Apache Doris 2.0-beta 版本中全新查詢優化器已經預設開啟，通過調用 Analyze 指令收集統計資訊。

自适應的 Pipeline 執行引擎

過去 Apache Doris 的執行引擎是基于傳統的火山模型建構，為了更好利用多機多核的并發能力，過去我們需要手動設定執行并發度（例如将 parallel_fragment_exec_instance_num 這一參數從預設值 1 手工設定為 8 或者 16），在存在大量查詢任務時存在一系列問題：

• 大查詢、小查詢需要設定不同的instance 并發度，系統不能做到自适應調整；
• Instance 算子占用線程阻塞執行，大量查詢任務将導緻執行線程池被占滿、無法響應後續請求，甚至出現邏輯死鎖；
• Instance 線程間的排程依賴于系統排程機制，線程進行反複切換将産生額外的性能開銷；
• 在不同分析負載并存時，Instance 線程間可能出現 CPU 資源争搶的情況，可能導緻大小查詢、不同租戶之間互相受影響；

針對以上問題，Apache Doris 2.0 引入了 Pipeline 執行模型作為查詢執行引擎。在 Pipeline 執行引擎中，查詢的執行是由資料來驅動控制流變化的， 各個查詢執行過程之中的阻塞算子被拆分成不同 Pipeline，各個 Pipeline 能否擷取執行線程排程執行取決于前置資料是否就緒，是以實作了以下效果：

• Pipeline 執行模型通過阻塞邏輯将執行計劃拆解成 Pipeline Task，将 Pipeline Task 分時排程到線程池中，實作了阻塞操作的異步化，解決了 Instance 長期占用單一線程的問題。
• 可以采用不同的排程政策，實作 CPU 資源在大小查詢間、不同租戶間的配置設定，進而更加靈活地管理系統資源。
• Pipeline 執行模型還采用了資料池化技術，将單個資料分桶中的資料進行池化，進而解除分桶數對 Instance 數量的限制，提高 Apache Doris 對多核系統的利用能力，同時避免了線程頻繁建立和銷毀的問題。

通過 Pipeline 執行引擎，Apache Doris 在混合負載場景中的查詢性能和穩定性都得以進一步提升。

參考文檔：https://doris.apache.org/zh-CN/docs/dev/query-acceleration/pipeline-execution-engine

如何開啟：Set enable_pipeline_engine = true該功能在 Apache Doris 2.0 版本中将預設開啟，BE 在進行查詢執行時預設将 SQL 的執行模型轉變 Pipeline 的執行方式。parallel_pipeline_task_num代表了 SQL 查詢進行查詢并發的 Pipeline Task 數目。Apache Doris 預設配置為0，此時 Apache Doris 會自動感覺每個 BE 的 CPU 核數并把并發度設定為 CPU 核數的一半，使用者也可以實際根據自己的實際情況進行調整。對于從老版本更新的使用者，建議使用者将該參數設定成老版本中parallel_fragment_exec_instance_num的值。

查詢穩定性進一步提升

多業務資源隔離

随着使用者規模的極速擴張，越來越多的使用者将 Apache Doris 用于建構企業内部的統一分析平台。這一方面需要 Apache Doris 去承擔更大規模的資料處理和分析，另一方面也需要 Apache Doris 同時去應對更多分析負載的挑戰，而其中的關鍵在于如何保證不同負載能夠在一個系統中穩定運作。

Apache Doris 2.0 版本中基于 Pipeline 執行引擎增加了 Workload 管理器 ，通過對 Workload 進行分組管理，以保證記憶體和 CPU 資源的精細化管控。

在過去版本中 Apache Doris 通過資源标簽的方式進行了多租戶資源隔離，可以通過節點資源劃分來避免不同業務間的互相幹擾，而 Workload Group 實作了更精細化的資源管控方式，通過将 Query 與 Workload Group 相關聯，可以限制單個 Query 在 BE 節點上的 CPU 和記憶體資源的百分比，并可以配置開啟資源組的記憶體軟限制。當叢集資源緊張時，将自動 Kill 組内占用記憶體最大的若幹個查詢任務以減緩叢集壓力。當叢集資源空閑時，一旦 Workload Group 使用資源超過預設值時，多個 Workload 将共享叢集可用空閑資源并自動突破阙值，繼續使用系統記憶體以保證查詢任務的穩定執行。

create workload group if not exists etl_group
properties (
  "cpu_share"="10",
  "memory_limit"="30%",
  "max_concurrency" = "10",
  "max_queue_size" = "20",
  "queue_timeout" = "3000"
);
           

可以通過 Show 指令來檢視建立的 Workload Group，例如：

作業排隊

同時在 Workload Group 中我們還引入了查詢排隊的功能，在建立 Workload Group 時可以設定最大查詢數，超出最大并發的查詢将會進行隊列中等待執行。

• max_concurrency 目前 Group允許的最大查詢數，超過最大并發的查詢到來時會進入排隊邏輯；
• max_queue_size查詢排隊的長度，當隊列滿了之後，新來的查詢會被拒絕；
• queue_timeout查詢在隊列中等待的時間，如果查詢等待時間超過等待時間查詢将會被拒絕，時間機關為毫秒；

參考文檔：https://doris.apache.org/zh-CN/docs/dev/admin-manual/workload-group/

徹底告别 OOM

在記憶體充足時記憶體管理通常對使用者是無感的，但真實場景中往往面臨着各式各樣的極端 Case，這些都将為記憶體性能和穩定性帶來挑戰，尤其是在面臨記憶體資源消耗巨大的複雜計算和大規模作業時，由于記憶體 OOM 導緻查詢失敗甚至可能造成 BE 程序當機。

是以我們逐漸統一記憶體資料結構、重構 MemTracker、開始支援查詢記憶體軟限，并引入程序記憶體超限後的 GC 機制，同時優化了高并發的查詢性能等。在 2.0 版本中我們引入了全新的記憶體管理架構，通過有效的記憶體配置設定、統計、管控，在 Benchmark、壓力測試和真實使用者業務場景的回報中，基本消除了記憶體熱點以及 OOM 導緻 BE 當機的問題，即使發生 OOM 通常也可依據日志定位記憶體位置并針對性調優，進而讓叢集恢複穩定，對查詢和導入的記憶體限制也更加靈活，在記憶體充足時讓使用者無需感覺記憶體使用。

通過以上一系列優化，Apache Doris 2.0 版本在應對複雜計算以及大規模 ETL/ELT 操作時，記憶體資源得以有效控制，系統穩定性表現更上一個台階。

詳細介紹：https://mp.weixin.qq.com/s/Z5N-uZrFE3Qhn5zTyEDomQ

高效穩定的資料寫入

更高的實時資料寫入效率

導入性能進一步提升

聚焦于實時分析，我們在過去的幾個版本中在不斷增強實時分析能力，其中端到端的資料實時寫入能力是優化的重要方向，在 Apache Doris 2.0 版本中，我們進一步強化了這一能力。通過 Memtable 不使用 Skiplist、并行下刷、單副本導入等優化，使得導入性能有了大幅提升：

• 使用 Stream Load 對 TPC-H 144G lineitem 表原始資料進行三副本導入 48 buckets 的 Duplicate 表，吞吐量提升 100%。
• 使用 Stream Load 對 TPC-H 144G lineitem 表原始資料進行三副本導入 48 buckets 的 Unique Key 表，吞吐量提升 200%。
• 使用 insert into select 對 TPC-H 144G lineitem 表進行導入 48 buckets 的 Duplicate 表，吞吐量提升 50%。
• 使用 insert into select 對 TPC-H 144G lineitem 表進行導入 48 buckets 的 Unique Key 表，吞吐提升 150%。

資料高頻寫入更穩定

在高頻資料寫入過程中，小檔案合并和寫放大問題以及随之而來的磁盤 I/O和 CPU 資源開銷是制約系統穩定性的關鍵，是以在 2.0 版本中我們引入了 Vertical Compaction 以及 Segment Compaction，用以徹底解決 Compaction 記憶體問題以及寫入過程中的 Segment 檔案過多問題，資源消耗降低 90%，速度提升 50%，記憶體占用僅為原先的 10%。

詳細介紹：https://mp.weixin.qq.com/s/BqiMXRJ2sh4jxKdJyEgM4A

資料表結構自動同步

在過去版本中我們引入了毫秒級别的 Schema Change，而在最新版本 Flink-Doris-Connector 中，我們實作了從 MySQL 等關系型資料庫到 Apache Doris 的一鍵整庫同步。在實際測試中單個同步任務可以承載數千張表的實時并行寫入，從此徹底告别過去繁瑣複雜的同步流程，通過簡單指令即可實作上遊業務資料庫的表結構及資料同步。同時當上遊資料結構發生變更時，也可以自動捕獲 Schema 變更并将 DDL 動态同步到 Doris 中，保證業務的無縫運作。

詳細介紹：https://mp.weixin.qq.com/s/Ur4VpJtjByVL0qQNy_iQBw

主鍵模型支援部分列更新

在 Apache Doris 1.2 版本中我們引入了 Unique Key 模型的 Merg-on-Write 寫時合并模式，在上遊資料高頻寫入和更新的同時可以保證下遊業務的高效穩定查詢，實作了實時寫入和極速查詢的統一。 而 2.0 版本我們對 Unique Key 模型進行了全面增強。在功能上，支援了新的部分列更新能力，在上遊多個源表同時寫入時無需提前處理成寬表，直接通過部分列更新在寫時完成 Join，大幅簡化了寬表的寫入流程。

在性能上，2.0 版本大幅增強了 Unique Key 模型 Merge-on-Write 的大資料量寫入性能和并發寫入能力，大資料量導入較 1.2 版本有超過 50% 的性能提升，高并發導入有超過 10 倍的性能提升，并通過高效的并發處理機制來徹底解決了 publish timeout(Error -3115) 問題，同時由于 Doris 2.0 高效的 Compaction 機制，也不會出現 too many versions (Error-235) 問題。這使得 Merge-on-Write 能夠在更廣泛的場景下替代 Merge-on-Read 實作，同時我們還利用部分列更新能力來降低 UPDATE 語句和 DELETE 語句的計算成本，整體性能提升約 50%。

部分列更新的使用示例（Stream Load）：

例如有表結構如下

mysql> desc user_profile;
+------------------+-----------------+------+-------+---------+-------+
| Field           | Type           | Null | Key   | Default | Extra |
+------------------+-----------------+------+-------+---------+-------+
| id               | INT             | Yes | true | NULL   |       |
| name             | VARCHAR(10)     | Yes | false | NULL   | NONE |
| age             | INT             | Yes | false | NULL   | NONE |
| city             | VARCHAR(10)     | Yes | false | NULL   | NONE |
| balance         | DECIMALV3(9, 0) | Yes | false | NULL   | NONE |
| last_access_time | DATETIME       | Yes | false | NULL   | NONE |
+------------------+-----------------+------+-------+---------+-------+
           

使用者希望批量更新最近 10s 發生變化的使用者的餘額和通路時間，可以把資料組織在如下 csv 檔案中

1,500,2023-07-03 12:00:01
3,23,2023-07-03 12:00:02
18,9999999,2023-07-03 12:00:03
           

然後通過 Stream Load，增加 Header partial_columns:true，并指定要導入的列名即可完成更新

curl --location-trusted -u root: -H "partial_columns:true" -H "column_separator:," -H 
"columns:id,balance,last_access_time" -T /tmp/test.csv http://127.0.0.1:48037/api/db1/user_profile/_stream_load
           

極緻彈性與存算分離

過去 Apache Doris 憑借在易用性方面的諸多設計幫助使用者大幅節約了計算與存儲資源成本，而面向未來的雲原生架構，我們已經走出了堅實的一步。

從降本增效的趨勢出發，使用者對于計算和存儲資源的需求可以概括為以下幾方面：

• 計算資源彈性：面對業務計算高峰時可以快速進行資源擴充提升效率，在計算低谷時可以快速縮容以降低成本；
• 存儲成本更低：面對海量資料可以引入更為廉價的存儲媒體以降低成本，同時存儲與計算單獨設定、互相不幹預；
• 業務負載隔離：不同的業務負載可以使用獨立的計算資源，避免互相資源搶占；
• 資料管控統一：統一 Catalog、統一管理資料，可以更加便捷地分析資料。

存算一體的架構在彈性需求不強的場景具有簡單和易于維護的優勢，但是在彈性需求較強的場景有一定的局限。而存算分離的架構本質是解決資源彈性的技術手段，在資源彈性方面有着更為明顯的優勢，但對于存儲具有更高的穩定性要求，而存儲的穩定性又會進一步影響到 OLAP 的穩定性以及業務的存續性，是以也引入了 Cache 管理、計算資源管理、垃圾資料回收等一系列機制。

而在與 Apache Doris 社群廣大使用者的交流中，我們發現使用者對于存算分離的需求可以分為以下三類：

• 目前選擇簡單易用的存算一體架構，暫時沒有資源彈性的需求；
• 欠缺穩定的大規模存儲，要求在 Apache Doris 原有基礎上提供彈性、負載隔離以及低成本；
• 有穩定的大規模存儲，要求極緻彈性架構、解決資源快速伸縮的問題，是以也需要更為徹底的存算分離架構；

為了滿足前兩類使用者的需求，Apache Doris 2.0 版本中提供了可以相容更新的存算分離方案：

第一種，計算節點。2.0 版本中我們引入了無狀态的計算節點 Compute Node，專門用于資料湖分析。相對于原本存儲計算一體的混合節點，Compute Node 不儲存任何資料，在叢集擴縮容時無需進行資料分片的負載均衡，是以在資料湖分析這種具有明顯高峰的場景中可以靈活擴容、快速加入叢集分攤計算壓力。同時由于使用者資料往往存儲在 HDFS/S3 等遠端存儲中，執行查詢時查詢任務會優先排程到 Compute Node 執行，以避免内表與外表查詢之間的計算資源搶占。

參考文檔：https://doris.apache.org/zh-CN/docs/dev/advanced/compute_node

第二種，冷熱分層。在存儲方面，冷熱資料資料往往面臨不同頻次的查詢和響應速度要求，是以通常可以将冷資料存儲在成本更低的存儲媒體中。在過去版本中 Apache Doris 支援對表分區進行生命周期管理，通過背景任務将熱資料從 SSD 自動冷卻到 HDD，但 HDD 上的資料是以多副本的方式存儲的，并沒有做到最大程度的成本節約，是以對于冷資料存儲成本仍然有較大的優化空間。在 Apache Doris 2.0 版本中推出了冷熱資料分層功能 ，冷熱資料分層功能使 Apache Doris 可以将冷資料下沉到存儲成本更加低廉的對象存儲中，同時冷資料在對象存儲上的儲存方式也從多副本變為單副本，存儲成本進一步降至原先的三分之一，同時也減少了因存儲附加的計算資源成本和網絡開銷成本。通過實際測算，存儲成本最高可以降低超過 70%！

參考文檔：https://doris.apache.org/zh-CN/docs/dev/advanced/cold_hot_separation

後續計算節點會支援查詢冷資料和存儲節點的資料，進而實作能相容更新的存算分離方案。

而為了滿足第三類使用者的需求，我們還将把 SelectDB Cloud 存算分離方案貢獻回社群。這一方案在性能、功能成熟度、系統穩定性等方面經曆了上百家企業生産環境的考驗，後續功能合入的實際進展我們也将及時同步。

10 倍以上成本效益的日志分析方案

從過去的實時報表和 Ad-hoc 等典型 OLAP 場景到 ELT/ETL、日志檢索與分析等更多業務場景，Apache Doris 正在不斷拓展應用場景的邊界，而日志資料的統一存儲與分析正是我們在 2.0 版本的重要突破。

過去業界典型的日志存儲分析架構難以同時兼顧 高吞吐實時寫入、低成本大規模存儲與高性能文字檢索分析，隻能在某一方面或某幾方面做權衡取舍。而在 Apache Doris 2.0 版本中，我們引入了全新反向索引、以滿足字元串類型的全文檢索和普通數值/日期等類型的等值、範圍檢索，同時進一步優化反向索引的查詢性能、使其更加契合日志資料分析的場景需求，同時結合過去在大規模資料寫入和低成本存儲等方面的優勢，實作了更高成本效益的日志分析方案。

在相同硬體配置和資料集的測試表現上，Apache Doris 相對于 ElasticSearch 實作了日志資料寫入速度提升 4 倍、存儲空間降低 80%、查詢性能提升 2 倍，再結合 Apache Doris 2.0 版本引入的冷熱資料分層特性，整體成本效益提升 10 倍以上。

除了日志分析場景的優化以外，在複雜資料類型方面，我們增加了全新的資料類型 Map/Struct，包括支援以上類型的高效寫入、存儲、分析函數以及類型之間的互相嵌套，以更好滿足多模态資料分析的支援。

詳細介紹：https://mp.weixin.qq.com/s/WJXKyudW8CJPqlUiAro_KQ

更全面、更高性能的資料湖分析能力

在 Apache Doris 1.2 版本中，我們釋出了 Multi-Catalog 功能，支援了多種異構資料源的中繼資料自動映射與同步，實作了資料湖的無縫對接。依賴 資料讀取、執行引擎、查詢優化器方面的諸多優化，在标準測試集場景下，Apache Doris 在湖上資料的查詢性能，較 Presto/Trino 有 3-5 倍的提升。

在 2.0 版本中，我們進一步對資料湖分析能力進行了加強，不但支援了更多的資料源，同時針對使用者的實際生産環境做了諸多優化，相較于 1.2 版本，能夠在真實工作負載情況下顯著提升性能。

更多資料源支援

• 支援 Hudi Copy-on-Write 表的 Snapshot Query 以及 Merge-on-Read 表的 Read Optimized Query，後續将支援 Incremental Query 和 Time Trival。參考文檔：https://doris.apache.org/zh-CN/docs/dev/lakehouse/multi-catalog/hudi
• JDBC Catalog 新增支援 Oceanbase，目前支援包括 MySQL、PostgreSQL、Oracle、SQLServer、Doris、Clickhouse、SAP HANA、Trino/Presto、Oceanbase 等近十種關系型資料庫。參考文檔：https://doris.apache.org/zh-CN/docs/dev/lakehouse/multi-catalog/jdbc

資料權限管控

• 支援通過 Apache Range 對 Hive Catalog 進行鑒權，可以無縫對接使用者現有的權限系統。同時還支援可擴充的鑒權插件，為任意 Catalog 實作自定義的鑒權方式。 參考文檔：https://doris.apache.org/zh-CN/docs/dev/lakehouse/multi-catalog/hive

性能進一步優化，最高提升數十倍

• 優化了大量小檔案場景以及寬表場景的讀取性能。通過小檔案全量加載、小 IO 合并、資料預讀等技術，顯著降低遠端存儲的讀取開銷，在此類場景下，查詢性能最高提升數十倍。
• 優化了 ORC/Parquet 檔案的讀取性能，相較于 1.2 版本查詢性能提升一倍。

• 支援湖上資料的本地檔案緩存。可以利用本地磁盤緩存 HDFS 或對象存儲等遠端存儲系統上的資料，通過緩存加速通路相同資料的查詢。在命中本地檔案緩存的情況下，通過 Apache Doris 查詢湖上資料的性能可與 Apache Doris 内部表持平，該功能可以極大提升湖上熱資料的查詢性能。參考文檔：https://doris.apache.org/zh-CN/docs/dev/lakehouse/filecache
• 支援外表的統計資訊收集。和 Apache Doris 内表一樣，使用者可以通過 Analyze 語句分析并收集指定外表的統計資訊，結合 Nereids 全新查詢優化器，能夠更準确更智能地對複雜 SQL 進行查詢計劃的調優。以 TPC-H 标準測試資料集為例，無需手動改寫 SQL 即可獲得最優的查詢計劃并獲得更好的性能表現。 參考文檔：https://doris.apache.org/zh-CN/docs/dev/lakehouse/multi-catalog/
• 優化了 JDBC Catalog 的資料寫回性能。通過 PrepareStmt 和批量方式，使用者通過 INSERT INTO 指令、通過 JDBC Catalog 将資料寫回到 MySQL、Oracle 等關系型資料庫的性能提升數十倍。

高并發資料服務支援

與複雜 SQL 和大規模 ETL 作業不同，在諸如銀行交易流水單号查詢、保險代理人保單查詢、電商曆史訂單查詢、快遞運單号查詢等 Data Serving 場景，會面臨大量一線業務人員及 C 端使用者基于主鍵 ID 檢索整行資料的需求，在過去此類需求往往需要引入 Apache HBase 等 KV 系統來應對點查詢、Redis 作為緩存層來分擔高并發帶來的系統壓力。

對于基于列式存儲引擎建構的 Apache Doris 而言，此類的點查詢在數百列寬表上将會放大随機讀取 IO，并且執行引擎對于此類簡單 SQL 的解析、分發也将帶來不必要的額外開銷，往往需要更高效簡潔的執行方式。是以在新版本中我們引入了全新的行列混合存儲以及行級 Cache，使得單次讀取整行資料時效率更高、大大減少磁盤通路次數，同時引入了點查詢短路徑優化、跳過執行引擎并直接使用快速高效的讀路徑來檢索所需的資料，并引入了預處理語句複用執行 SQL 解析來減少 FE 開銷。

通過以上一系列優化，Apache Doris 2.0 版本在并發能力上實作了數量級的提升！在标準 YCSB 基準測試中，單台 16 Core 64G 記憶體 4*1T 硬碟規格的雲伺服器上實作了單節點 30000 QPS 的并發表現，較過去版本點查詢并發能力提升超 20 倍！基于以上能力，Apache Doris 可以更好應對高并發資料服務場景的需求，替代 HBase 在此類場景中的能力，減少複雜技術棧帶來的維護成本以及資料的備援存儲。

參考文檔：https://doris.apache.org/zh-CN/docs/dev/query-acceleration/hight-concurrent-point-query

詳細介紹：https://mp.weixin.qq.com/s/Ow77-kFMWXFxugFXjOPHhg

CCR 跨叢集資料同步

為了滿足使用者多叢集之間資料同步的需求，在過去需要定期通過 Backup/Restore 指令進行資料備份和恢複，操作較為複雜、資料同步時延高并且還需要中間存儲。為了滿足使用者多叢集的資料庫表自動同步需求，在 2.0-beta 版本中我們增加了 CCR 跨叢集資料同步的功能，能夠在庫/表級别将源叢集的資料變更同步到目标叢集、以提升線上服務的資料可用性并更好地實作了讀寫負載分離以及多機房備份。

支援 Kubernetes 容器化部署

在過去 Apache Doris 是基于 IP 通信的，在 K8s 環境部署時由于主控端故障發生 Pod IP 漂移将導緻叢集不可用，在 2.0 版本中我們支援了 FQDN，使得 Apache Doris 可以在無需人工幹預的情況下實作節點自愈，是以可以更好應對 K8s 環境部署以及靈活擴縮容。

參考文檔：https://doris.apache.org/zh-CN/docs/dev/install/k8s-deploy/

其他更新注意事項

• 1.2-lts 可以滾動更新到 2.0-beta，2.0-alpha 可以停機更新到 2.0-beta；
• 查詢優化器開關預設開啟 enable_nereids_planner=true；
• 系統中移除了非向量化代碼，是以參數将不再生效enable_vectorized_engine；
• 新增參數 enable_single_replica_compaction；
• 預設使用 datev2, datetimev2, decimalv3 來建立表，不支援 datev1，datetimev1， decimalv2 建立表；
• 在 JDBC 和 Iceberg Catalog 中預設使用decimalv3；
• date type 新增 AGG_STATE；
• backend 表去掉 cluster 列；
• 為了與 BI 工具更好相容，在 show create table 時，将 datev2 和 datetimev2 顯示為 date 和 datetime。
• 在 BE 啟動腳本中增加了 max_openfiles 和 swap 的檢查，是以如果系統配置不合理，be 有可能會啟動失敗；
• 禁止在 localhost 通路 FE 時無密碼登入；
• 當系統中存在 Multi-Catalog 時，查詢 information schema 的資料預設隻顯示 internal catalog 的資料；
• 限制了表達式樹的深度，預設為 200；
• array string 傳回值 單引号變雙引号；
• 對 Doris的程序名重命名為 DorisFE 和 DorisBE；

踏上 2.0 之旅

距離 Apache Doris 2.0-alpha 版本釋出已經有一個半月之久，這一段時間内我們在加速核心功能特性開發的同時、還收獲到了數百家企業對于新版本的切身體驗與真實回報，這些來自真實業務場景的回報對于功能的打磨與進一步完善有着極大的幫助。是以 2.0-beta 版本無論在功能的完整度還是系統穩定性上，都已經具備了更佳的使用體驗，歡迎所有對于 2.0 版本新特性有需求的使用者部署更新。

如果您在調研、測試以及部署更新 2.0 版本的過程中有任何問題，歡迎送出問卷資訊（https://wenjuan.feishu.cn/m/cfm?t=sF2FZOL1KXKi-m73g），屆時将由社群核心貢獻者提供 1-1 專項支援。我們也期待 2.0 版本為更多社群使用者提供實時統一的分析體驗，相信 Apache Doris 2.0 版本會成為您在實時分析場景中的最理想選擇。