《火山引擎：2024云原生數據倉庫ByteHouse性能白皮書（企業版）（35頁）.pdf》由會員分享，可在線閱讀，更多相關《火山引擎：2024云原生數據倉庫ByteHouse性能白皮書（企業版）（35頁）.pdf（35頁珍藏版）》請在三個皮匠報告上搜索。

1、CONTENTS目 錄人群圈選&用戶畫像BitEngine/BitMap行為分析留存分析函數漏斗分析函數數據分析場景實時數倉0102060708高并發場景10Kafka&FlinkCDC（Change Data Capture）實時數據同步Upsert&部分列更新1.11.21.30101022.12.202043.13.23.33.4060607074.1075.15.20809復雜查詢優化器執行層寬表查詢預聚合Zero copy 優化全局字典UncompressedCache 優化Vector 向量檢索GIS時空分析1012標準測試集性能參照SSB 性能測試測試結果測試環境測試步驟TPC-

2、H 性能測試測試結果測試環境測試步驟TPC-DS 性能測試測試結果測試環境測試步驟1539571.11.21.31517171.11.21.33941411.11.21.3576464在數據處理和分析的領域，提升查詢效率始終是一項關鍵挑戰。在 OLAP 領域，性能的關鍵需求在于能夠快速進行數據檢索，支持實時分析，具備處理大規模數據的能力，輕松應對復雜查詢，提供快速響應，具備良好的可擴展性，高效處理并發操作，以及實現高效的數據壓縮和存儲。這些方面對于滿足高效、準確的數據分析需求至關重要。ByteHouse 是火山引擎自主研發的云原生數據倉庫產品，它全面繼承了開源 ClickHouse 的高性能和

3、強大的分析能力，并在架構上遵循新一代云原生理念進行全面重構，實現了容器化、存儲計算分離、多租戶管理和讀寫分離等功能。在可擴展性、穩定性、可運維性、性能以及資源利用率等方面都有顯著提升。截至 2022 年 2 月，ByteHouse 在字節跳動內部的部署規模超過 18000 臺，單集群超過 2400 臺。它經過了內部數百個應用場景和數萬用戶的錘煉，并在多個外部企業客戶中得到了廣泛應用。本文將介紹 ByteHouse 企業版的一系列優化措施。這些改進旨在縮短查詢執行時間、優化資源利用，提供更流暢的數據分析體驗。通過智能優化算法和先進的執行技術，ByteHouse 能夠更好地應對各種復雜的查詢場景。

4、為了讓大家親身感受這些優化帶來的效果，我們提供了使用 SSB 100G、TPC-H 100G、TPC-DS 100G 數據集的性能測試步驟。您可以按照這些步驟進行測試，親自驗證 ByteHouse 企業版在查詢效率方面的顯著提升。數據分析場景實時數倉HaKafka：更穩定的高可用 Kafka 消費引擎Kafka&FlinkCDC（Change Data Capture）實時數據同步Upsert&部分列更新ByteHouse 的 HaKafka Engine 是一款自研表引擎，在數據實時消費性能不降級的基礎上解決了Kafka 消費的高可用問題，提供了 low-level 消費模式，保證了 At-

5、least-once 消費語義。用戶可以通過ByteHouse 控制臺可視化創建實時導入任務。當前，很多企業在分析型業務中對數據去重有很強的訴求，為此，ByteHouse 研發了 HaUniqueMergeTree 表引擎，保留了 ClickHouse 高效的查詢性能，還支持主鍵實時更新的場景，ByteHouse 在落盤即去重，解決了社區版 查詢時去重的效率問題，可以幫助業務更輕松地開發實時分析應用。同時，在 ByteHouse 中，我們可以在 HaUniqueMergeTree 表中實現部分列更新的功能。部分列更新模式在指定變量 enable_unique_partial_update=1

6、后，允許以部分列更新的模式進行寫入。DES 數據快車服務（ByteHouse 插件）Flink ConnectorFlink Connector for ByteHouse 連接器專用于通過 Flink 將數據加載到 ByteHouse，目前 FlinkConnector 已經支持 通過 Table API&SQL 和 Flink DataStreamAPI 兩種方式來連接 ByteHouse并處理數據，詳情請參見產品手冊（https:/ Express Service）是一個用于將多源異構數據源和數據結構導入到ByteHouse 的服務，通過提供數據集成、結構映射、高效導入、安全可靠等功能，

7、幫助用戶快速、準確地將各種類型的數據（如關系型數據庫、日志文件、對象存儲等）導入到 ByteHouse 中進行后續的處理和分析。使用 DES 可實現數據秒級同步到目標端，用戶可以根據業務需求選擇不同規格的獨享資源以享受更高性能的同步體驗，同步性能可達到 25 萬 records/s 以上，詳情請參見產品手冊。目前，數據快車的 CDC 同步任務已支持 MySQL/PostgreSQL 數據源的歷史或增量數據同步。內置 MaterializedMySQL 引擎0102為了強化實時數倉的能力，便于將 MySQL 中的表映射到 ByteHouse 企業版中，ByteHouse 引入了Materiali

8、zedMySQL 數據庫引擎，ByteHouse 服務作為 MySQL 副本，可以讀取 Binlog 并執行 DDL和 DML 請求，實現了基于 MySQL Binlog 機制的業務數據庫實時同步功能。ByteHouse 企業版在實現 MaterializedMySQL 時，底層引擎采用了自研的 HaUniqueMergeTree 引擎，支持自定義版本字段以及根據 UNIQUE KEY 實時刪除數據功能，無需引入其他額外字段。同時，ByteHouse增強了 MaterializedMySQL 引擎的穩定性和易用性。SQL-以部分列更新的模式進行寫入，并主動制定更新列示例SET enable_u

9、nique_partial_update=1;-主動指定 _update_columns_INSERT INTO t1(k,c1,m1,a1,_update_columns_)VALUES(1,20,k2:2,world,k,c1,m1,a1);kc1c2c3c4m1a1 1 20 3.14 k2:2 world 復雜查詢優化器數據庫優化器是DBMS中一個核心組件，它負責分析查詢語句，并根據表的結構、索引等信息來生成最優的執行計劃。通過優化查詢執行計劃，可以提高查詢的執行效率，減少資源消耗，提升系統性能。為了提升在復雜場景的查詢性能，ByteHouse 的自研優化器進行了大量的優化，主要包括四

10、個大的優化方向：RBO（基于規則的優化能力），CBO（基于代價的優化能力），分布式計劃優化以及一些高階優化能力。RBO優化器實現了常見的優化規則。例如列裁剪、分區裁剪、表達式簡化、子查詢解關聯、謂詞下推、冗余算子消除、Outer-JOIN 轉 INNER-JOIN、算子下推存儲、分布式算子拆分等常見的啟發式優化能力。解關聯很多 OLAP 引擎不支持相關子查詢，在語法分析階段就會報錯。優化器實現了完整的解關聯能力，對于關聯查詢可以轉換為常見的 join agg filter 等算子執行，下圖就是一個簡單的解關聯例子。對于一些特殊類型的關聯查詢也可以利用 window 算子執行，更加快速簡潔。N

11、U L LN U L LCBO0304非等值 Join 優化在很多引擎中，帶有非等值條件的 join 需要通過多個算子來組合執行(inner join+filter+group-by)，而在 ByteHouse 中，支持非等值 join 之后可以直接在 join 算子中完成非等值條件的執行。優化器會對一些關聯子查詢轉成非等值 join 來執行，相較于轉成其他常見的算子（inner join,filter,agg）性能有一倍以上的提升。Join Reorder對 10 表級別規模的 Join Reorder 問題，能夠全量枚舉并尋求最優解，同時針對大于 10 表規模的 JoinReorder 支

12、持啟發式枚舉并尋求最優解。CBO 支持基于規則擴展搜索空間，除了常見的 Join Reorder問題以外，還支持 Outer/Semi/Anti-Join 的 Reorder?；?Cascade 搜索框架，利用 Graph Partition 技術實現了高效的 Join 枚舉算法，以及基于 Histogram的代價估算。分布式計劃生成業界主流實現分為兩個階段，首先尋求最優的單機版計劃，然后將其分布式化。但是這樣的設計流程，不能提前考慮分布式系統的特點，可能會導致網絡延遲、數據分布不均衡，并導致可擴展性限制等問題。我們的方案則是將這兩個階段融合在一起，在整個 CBO 尋求最優解的過程中，會結合

13、分布式計劃的訴求，從代價的角度選擇最優的分布式計劃。同時在 Join/Aggregate 過程中，也支持 Partition 屬性展開。另外，我們也在 CBO 中實現了對于 Aggregate/Join Reorder，Magic Set Placement 等相關能力。對于 CTE 的實現方式也基于 Cost 進行選擇，在 inline，shared 和 partial inline 之間做權衡，選出最優的計劃。在 tpcds 等 benchmark 中都有一定的應用。SELECT count(c_custkey)FROM customerWHERE 10000 10000Aggregati

14、ngNodeGrupBy:o_custkeyFunctions;SUM(o_totalprice)ProjectionNodeDatabase:tpchTable;customerGreaterOrEqualsGroupBy:Functions:count(c_custkey)Assignments:count(c_custkey):count(c_custkey)Assignments：o_totalprice：o_totalpriceo_custkey:o_custkey build side non null symbol:1Ulnt8ReadFromStorageNodeDatabas

15、e:tpchTable:orders執行層Exchange在執行層中，數據的傳入和傳出依賴于 Exchange 模塊。Exchange 是數據在 PlanSegment 實例之間進行數據交換的邏輯概念。在具體實現上，我們將其分為數據傳輸層和算子層。數據傳輸層主要基于定義的 Receiver/Sender 接口，同進程傳輸基于隊列，跨進程基于 BRPC Stream，支持保序、狀態碼傳輸、壓縮和連接池復用。簡單來說，就是在大集群上的兩個節點之間只建立一個連接，所有查詢都在這個連接上通信。由于我們使用連接池，實際上兩個節點之間是固定數量的連接，這樣穩定性更高。算子層支持四種場景：一對多的 Broa

16、dcast、多對多的 Repartition、多對一的 Gather，以及本進程之間的 Round-Robin。ByteHouse中另外還做了一些優化，包括避免 Broadcast 重復序列化、提升Repartition 性能以及 sink 攢批。在大集群下，通過一個 ExchangeSource 讀取多個 receiver 的數據來降低線程數。0506并行化重構+Bucket 表ClickHouse 內部的并行執行在 Agg 和 Join 上存在一些性能瓶頸，主要表現在不能很好地結合數據上下游的數據特征，以及在中間執行過程中引入了不必要的 Final Merge 和數據 Shuffle。在此

17、基礎上，ByteHouse 對 ClickHouse 進行了并行化重構，支持 Aggregation Streaming 并結合HashTable Two-Level 的并行和數據的分布特征，有效減少了中間出現的 Agg Final Merge 和ConcurrentHashJoin 中的數據 Shuffle，從而顯著提升了整體 Query 的執行性能。QueryPlanQueryPipelineIQueryPlanStepIProcessorExchangeSourceBufferedCopyTransformTransformerExchange SinkRepartitionTransf

18、ormMultiPartitionExchangeSinkLoadBalancedExchangeSinkRemote Broadcast APIBRPC BroadcastLocal BroadcastSinglePartitionExchangeSinkBroadcastExchangeSinkRemoteExchangeSourceStepProcessors ModuleData TransportLayerRuntimeFilter 優化在 OLAP 場景中，Join 是一個十分常見的操作，也是查詢的性能瓶頸。Runtime Filter 是在 Join 的Probe 端提前過濾掉那

19、些不會命中 Join 的數據，減少存儲掃描、網絡傳輸和算子計算的數據，是優化復雜查詢的重要手段之一。Runtime Filter 也稱為 Dynamic Filter，是一種在執行引擎中動態構建 Filter 的能力。它的目的是通過在 Join 的 Probe 端提前過濾掉那些不會命中 Join 的輸入數據，來大幅減少 Join 中的數據傳輸和計算，從而減少整體的執行時間。例如在 Hash Join 的過程中，當右表 HashTable 構建完成后，將根據 JoinKey+HashTable 生成 RuntimeFilter，并將其作用于左表的 Scan 節點，從而減少左表的掃描數據量，可進一

20、步減少磁盤 IO、網絡數據傳輸等，最終使得 Query 的性能顯著提高。ByteHouse 支持根據不同的場景生成最優的 RuntimeFilter，優化了生成和 Apply 的流程，同時支持 Distributed 和 Local 的 RuntimeFilter，在較大規模集群上也自適應的支持 Shuffle-Aware 的RuntimeFilter。JoinJoinFilterTableScanRuntimeFilterBuilderTableScanRuntimeFilterBuilderFilterTableScan提前過濾RPCTableScan(withRuntimeFilter)

21、RuntimeFilterProbe寬表查詢預聚合物化視圖物化視圖存儲了 SQL 查詢語句包含的數據，并提供更新機制。物化視圖最重要的功能就是查詢加速。用查詢物化視圖來替代直接查詢數據表，可以避免對數據進行再次的計算與聚合，能夠以空間換時間的方式節省查詢時間，達到查詢加速和簡化查詢邏輯的目的。數據倉庫中存在大量在大型表上執行復雜的查詢，并會消耗大量資源和時間。物化視圖可以通過預計算的結果回答查詢，消除昂貴的 Join 和聚合計算所帶來的開銷，大幅度改善查詢處理時間，降低系統負載。對于可以預見并反復使用相同子查詢結果的查詢，物化視圖非常高效。0708ProjectionProjection 是按

22、照 ByteHouse 的存算分離架構進行設計的，Projecton 數據由分布式存儲統一進行管理，而針對 projection 的查詢和計算則在無狀態的計算節點上進行。相比于社區版，ByteHouse Projection實現了以下優勢：對于 Projection 數據的存儲節點和計算節點可以獨立擴展，即可以根據不同業務對于 Projection 的使用需求，增加存儲或者計算節點。當進行 Projection 查詢時，可以根據不同 Projection 的數據查詢量來分配計算節點的資源，從而實現資源的隔離和優化，提高查詢效率。Projection 的元數據存儲十分輕量，在業務數據急劇變化的時

23、候，計算節點可以做到業務無感知擴縮容，無需額外的 Projection 數據遷移。Zero copy 是一種優化技術，用于在數據傳輸過程中減少數據的拷貝次數，從而提高數據傳輸的效率和性能。Zero copy 可以避免原來前期需要的大量 deep copy 操作。在減少 deep copy 降低查詢計算overhead 的同時，也可以避免內存 IO 吞吐過早達到內存 IO 帶寬上限，從而緩解高并發下內存 IO 吞吐帶寬瓶頸帶來的問題。Zero copy 優化全局字典UncompressedCache 優化全局字典以全局字典編碼的方式進行數據的讀寫計算，針對 Agg、Function和Exchan

24、ge 實現了基于編碼值的處理，將基于非定長字符串類型的計算改變為基于定長整型編碼值的計算，以此提升計算效率。UncompressedCache 優化提高了多線程下 cache 訪問的效率。社區 OLAP 多個 cache 模塊使用 LRU cache，在多線程并發場景中存在鎖競爭激烈，影響 cache 效率的情況。而 UncompressedCache 優化解決了這一問題，提高了系統的性能和響應能力。BitMap 索引（BitMap index）目前用于 Array+Int8/16/32/64/String UInt/8/16/32/64/String 類型，它為 Array 數組中每個元素構

25、建一個 bitmap-index，在查詢的時候，我們使用 arraySetCheck(column,(item)檢測 item 是否在數組里的時候會使用 bitmap-index 做過濾，從而避免大量的 array 數據讀取，目前大部分 Array 類型的過濾操作都使用了 bitmap-index，性能有 4-10 倍不等的提升。人群圈選分析是客戶畫像平臺(CDP)中的核心功能。分析師利用各種標簽組合，挑選出最合適的人群，進而進行廣告推送，達到精準投放的效果。同時由于人群查詢在不同標簽組合下的結果集大小不同，在一次廣告投放中，分析師需要經過多次的邏輯調整，以獲得更合適的人群包。在這種高頻的操作

26、下，畫像平臺通常會遇到兩方面的問題：第一，由于此類查詢分析是臨時性的，各種標簽組合數巨大，離線預計算無法滿足此類靈活性。第二，由于此類查詢是實時場景，查詢性能變得非常關鍵，通常一次查詢在分鐘級，耗時較長，無法滿足分析師需求。目前，從 ByteHouse 實測數據表現上看，在 10 億級用戶測試數據下，ByteHouse 的人群查詢 P99 小于 10s，展現了優異的性能。人群圈選&用戶畫像BitEngine/BitMapBitEngine 是一個高效集合數據 處理模型，它是查詢分析數據庫 ClickHouse 的一部分。BitEngine 底層基于 MergeTree Family 存儲引擎，

27、并在此基礎上引入了 BitMap64 類型，開發了系列相關運算函數。BitEngine 提供的 BitMap64 類型適合表達具有特定關系的大量實體 ID 的集合，將集合的交并補運算轉化為 bitmap 之間的交并補運算，從而達到遠超普通查詢的性能指標。已上線業務的測試表明，使用BitEngine 相比普通和 Array 或者用戶表方式，在查詢速度上有 10-50 倍不等的提升，詳情可參見官方文檔（https:/ 根據用戶行為分析使用場景，定制了部分函數，包括留存分析類函數 genArrayIf()/retention2()、路徑分析類函數 pathSplit()/pathCount()，以及

28、漏斗分析函數 finderFunnel()/funnelRep()等。漏斗分析和留存分析是常用的轉化分析方法，在用戶行為分析和 App 數據分析的流量分析、產品目標轉化等數據運營和分析中得到廣泛應用，使用這些函數相比拼裝 SQL 或者 ClickHouse原生函數更為高效。留存分析函數留存分析函數通常用于分析用戶在一段時間內的留存情況。這些函數可以幫助我們了解用戶在特定時間段后是否仍然活躍或繼續使用產品或服務。通過對留存率數據分析數據，可以識別用戶行為模式，并通過持續不斷的優化產品和數據監測，可以提高用戶滿意度和忠誠度，增加留存率。0910漏斗分析函數漏斗模型是一種常見的分析方法，用于描述一個

29、過程中各個階段的轉化情況，就像一個漏斗一樣，數據從寬口進入，逐漸縮小，最終到達窄口。ByteHouse 中的漏斗函數主要用于統計用戶在不同階段的轉化率和轉化路徑。它可以根據用戶的行為數據，分析用戶的每一步操作，并將其分為不同的階段。根據不同的條件，例如訪問量、點擊量、注冊量等，計算每個階段的轉化率，并顯示出用戶在整個轉化路徑上的轉化。例如，在一些業務場景中，需要選定一段時間范圍，觀察此時間范圍內每一個時間單位（天）內用戶按一定時間范圍劃分的漏斗分層匯總情況。目前，通過使用 ByteHouse 作為查詢加速引擎，幫助行為分析系統 接入了字節跳動內部幾乎所有的產品線。業務上，在滿足了高效查詢性能的

30、同時，擴展了時間分析的范圍與事件埋點的數量。讓分析用戶能夠在海量數據的情況下，依然可以靈活地進行交互式分析，洞察事件行為背后的原因。SQLDAU:4000+活躍項目：1000+OpenAPI 活躍業務方：100+日增事件數：4萬億條總事件數：1000萬億條+高并發場景OLAP 高并發場景指的是在在線分析處理（Online Analytical Processing）環境中，有大量用戶同時進行數據分析操作的情況。在這種場景下，系統需要處理多個并發請求，以滿足用戶對快速數據查詢和分析的需求。比如，在部分在線服務的分析場景下（如游戲日志檢索，用戶信息檢索等），需要給多個分析師提供相似 SQL Pat

31、tern 的查詢服務。通常此類查詢性能要求極高，需要有 10000 以上、可線性擴展的QPS 查詢性能。業內主流 OLAP 引擎在高并發能力上表現不佳，通常需要借助行存引擎去支持高并發點查場景，但是對建模和運維管理都帶來了很多額外工作量。ByteHouse 針對性做了很多增強，在純列存模式上極大提升了點查場景的 QPS，技術點包括：TopN 短路計算、唯一鍵索引、讀鏈路優化、查詢模板等等。在某游戲廣告推薦業務上，僅僅 256 Core 的算力，即可支持 10萬+QPS。Vector 向量檢索向量是一種常見的非結構化數據表現形式?；谙蛄肯嗨贫鹊?KNN 計算廣泛使用于圖像搜索、多模態搜索、推薦

32、、大模型推理等場景。ByteHouse 企業版已提供向量數據的管理與近似度查詢功能，同時通過支持多種常見近近似最近鄰搜索算法（Approximate Nearest Neighbor，ANN）算法來提升檢索性能，以提供對非結構化數據的處理能力。ByteHouse 企業版當前支持 HNSW(hnswlib)、Faiss 兩個算法庫，后續還會對 DiskANN 等算法庫提供支持。HNSW 索引熱門的基于圖的近似最近鄰搜索算法（ANN）。HNSW 是一種非常流行和強大的算法，具有超快的搜索速度和出色的召回率。（Hierarchical Navigable Small World graphs，分層-

33、可導航-小世界-圖）FaissFacebook 開源的 ANN 算法庫，包含了倒排（IVF，Inverted File）、PQ、SQ 等多種類型的索引，同時多種索引還可以組合使用。我們主要使用 Faiss 的 IVF 類索引，同時支持 PQ、SQ 等向量壓縮方法，以減少索引的內存使用。訪問激活注冊活躍交易留存用戶首次使用時間新增用戶留存率1周后2周后3周后4周后5周后6周后7周后8周后日 周 月9周后09-13-09-1909-20-09-2609-27-10-0310-04-10-1010-11-10-1710-18-10-2410-25-10-3111-01-11-0711-08-11-1

34、412061292158412331227137314331351140343.4%43%44.9%39.1%41.6%41.7%45.8%43%28.7%31.9%31.6%31.8%26%28.3%28.9%32%16.8%25.1%24.9%26.6%19.4%22.6%24.2%16.2%21.5%20.2%21.1%16.5%19.4%11.4%18.4%15.9%19.1%13.9%9.5%15.4%14.4%17.1%7.2%15.2%13.9%9%13.4%7%7.5%表：Vector 大模型向量檢索核心應用場景廣泛基于業界最新的 VectorDBBench 測試工具進行測試，

35、在 cohere 1M 標準測試數據集上、recall 98 的情況下，ByteHouse 可以達到與專用向量數據庫（以專用向量數據庫 Milvus 為例）同等水平的性能。在 recall 95 以上的情況下，QPS 可以達到 2600 以上，p99 時延在 15ms 左右，具備業界領先優勢。1112GIS 時空分析在數字化時代，地理空間分析（Geospatial Analytics）成為輔助企業市場策略洞察的重要手段。無論是精準廣告投放，還是電商物流的效率優化，都離不開對地理空間數據的查詢、分析和可視化處理，以便助力企業更好決策。ByteHouse 的 GIS 功能不僅提供了高性能的地理空間

36、分析能力，還具有易于使用、實時分析和云原生等特點。這使得企業可以更靈活、更高效地利用地理空間數據，從而在激烈的市場競爭中獲得優勢。在關鍵性能層面，ByteHouse GIS在列式小批組織的數據結構上引入 RTree 等二維空間索引能力，并在CPU 硬件層面實現了二維空間函數的性能優化，整體提升了端到端性能。在功能層面，兼容 OGC 標準，支持導入標準 GIS 文件格式，目前已支持超過 50 個主流的空間函數。在具體的業務場景中，ByteHouse 的 GIS 功能可以帶來顯著的提升：位置洞察：通過高性能 GIS（ST_DistanceSphere）函數，企業可以快速獲取指定范圍內的相關 信息，

37、為定價策略和市場定位提供數據支持。作戰地圖：利用 GIS（ST_Within）函數，企業可以實時觀察特定區域內的商家供給和客流量，為即 時零售業務的配送優化提供決策依據。為了說明性能效果，我們基于兩個關鍵的 GIS 函數：ST_DistanceSphere 和 ST_Within；并使用 NYCTaxi 數據集（Size：21GB；條數：169,001,162），數據集將紐約拆分成多個地理區域（比如 Brooklyn，Manhattan），選取其中 3 個不同大小的地理區域（按照過濾度區分：zone 1、zone 2、zone 3），將 ByteHouse 與 ClickHouse、PostG

38、IS、DuckDB 等常見數據庫進行了性能對比?；跇藴蕯祿臏y試結果來看，ByteHouse GIS 對比傳統的 PostGIS：在 OLAP 層面，ByteHouse 已經有計算優勢。在 GIS 層面，空間數據對象按照列的方式存儲，而非序列化成字節數組，在存儲上能夠做到更加緊湊并節省空間，在計算上能夠充分發揮向量化的優勢。在空間函數層面，可以利用硬件的并行化能力提速。ByteHouse GIS 對比社區 ClickHouse：ByteHouse GIS 兼容 OGC 標準，能夠水平替換之前 PostGIS 的場景?？臻g索引能力可以大大減少 ClickHouse 的讀放大的現象。ByteH

39、ouse 自研的優化器同樣具備適配 GIS 特性的能力。Search Performance Test(1M Dataset,768 Dim)Qps(more is better)ByteHouse-HNSW1,8501,601Milvus0.9850.9825ByteHouse-HNSWMilvusRecall(more is better)533.5s801sByteHouse-HNSWMilvusLoad duration(less is better)5.4ms12.8msMilvusByteHouse-HNSWSerial latency_p99(less is better)行業互

40、聯網-電商互聯網社交政府機構金融零售應用場景商品以圖搜搜圖像去重、視頻原創驗證、風控審核、關聯推薦、輿情監控人臉識別、視頻檢索、指紋搜索、人體圖像檢索、車輛查找、內容查重人臉識別、文本檢索、智能客服人臉識別、商品識別、自動售貨機1314標準測試集性能參照SSB、TPC-H 和 TPC-DS 都是常用于測試分析型數據庫/數據倉庫的數據集。這些數據集被廣泛應用于數據倉庫領域，并且包含了常見的業務場景和數據模式。通過測試這些數據集，可以全面評估數倉在處理復雜數據結構和查詢操作時的性能和效率。SSB：Star Schema Benchmark 是一種在學術界和工業界廣泛應用的數據庫系統性能評估基準測試

41、方法。它能夠對比不同數據倉庫在處理星型模式查詢時的性能，幫助數據庫管理員和決策者選擇最符合需求的數據庫系統。此外，參考 OLAP 行業的做法，將 SSB 中的星型模型展平轉化為寬表，還可以改造成單一表測試 Benchmark（SSB flat）。TPC-H：TPC-H 作為一種決策支持基準，被廣泛應用于學術界和工業界，用于評估決策支持技術應用的性能。它以真實的生產運行環境為基礎進行建模，模擬了一個包含 8 張表的銷售系統數據倉庫。其選擇的查詢和填充數據庫的數據具有廣泛的行業相關性，同時具備足夠的易實現性。TPC-DS：TPC-DS 由 TPC 委員會制定并發布，是一種面向決策支持系統的、涵蓋多

42、維度常規應用模型的決策支持基準，包括查詢和數據維護。該基準對被測系統在決策支持系統層面的表現評估具有代表性。TPC-DS 查詢包含共計 99 個測試語句。以下內容將以性能著稱的某開源 OLAP C*為基準產品，通過 SSB、TPC-H 和 TPC-DS 三種數據集，展示 ByteHouse 的性能效果。您可以按照這些數據集的測試步驟進行測試，驗證 ByteHouse 在查詢效率方面的顯著提升。某汽車內容平臺借助 ByteHouse 的 GIS 時空分析功能，幫助用戶在選擇店址時快速評估商業價值。例如，某汽車品牌使用該平臺的建店選址產品，可以快速了解該城市的人口分布、消費水平、競爭對手等信息，從

43、而選擇最合適的店址，提高開店成功率。ST_Within 函數性能對比ST_DistanceSphere 函數性能對比測試結果經過對標準 SSB 和 SSB 寬表的測試發現：SSB 寬表測試的 13 個查詢中，ByteHouse 查詢性能全面超越開源產品 C*，整體查詢性能達到該產品的 3.6+倍。SSB 標準測試的 13 個查詢中，開源產品 C*最后三個查詢因為內存問題查詢失敗，整體查詢性能與ByteHouse 相差較大。SSB 性能測試q1.1q1.2q1.3q2.1q2.2q2.3q3.1q3.2q3.3q3.4q4.1q4.2q4.3sum199117974609974671511947

44、36709811512293265253334270191164571991722558查詢完成時間（ms）ByteHouse開源產品 C*q1.1q1.2q1.3q2.1q2.2q2.3q3.1q3.2q3.3q3.4q4.1q4.2q4.32811121661501283141581292531114095235207209111267615763095129893278915788792查詢完成時間（ms）ByteHouse開源產品 C*SSB 寬表測試結果如下：標準 SSB 測試結果如下：15161718測試環境下面列舉了本次 SSB 性能測試所使用的環境信息。硬件環境每個測試環境 3

45、 個節點，配置如下：CPU 16 核：INTEL內存：64 GB網絡帶寬：5 Gbits/s磁盤：ESSD 高效云盤，空間 200 GB測試步驟ByteHouse 測試所使用的數據、生成、導入和查詢步驟如下。測試數據軟件環境內核版本：Linux 3.10.0-1127.19.1.el7.x86_64 x86_64操作系統：CentOS Linux release 7.8.2003(Core)數據庫版本：ByteHoue 企業版:2.4.0.231 (混布 ZooKeeper：3.8.1)開源產品 C*：24.3.1.1023表名lineordercustomerpartsupplierdate

46、slineorder_flat行數6 億300 萬140 萬20 萬25566 億解釋SSB 商品訂單表SSB 客戶表SSB 零部件表SSB 供應商表日期表SSB 打平后的寬表數據生成首先下載 ssb 工具包并編譯Bash$git clone https:/ ssb-dbgen$make生產數據Bash$./dbgen-s 1000-T c$./dbgen-s 1000-T l$./dbgen-s 1000-T p$./dbgen-s 1000-T s$./dbgen-s 1000-T d創建測試表SQLDROP DATABASE IF EXISTS ssb_local ON CLUSTER

47、ch_benchmark;CREATE DATABASE ssb_local ON CLUSTER ch_benchmark;USE ssb_local;CREATE TABLE customer ON CLUSTER ch_benchmark(C_CUSTKEY UInt32,C_NAME String,C_ADDRESS String,C_CITY GlobalLowCardinality(String),C_NATION GlobalLowCardinality(String),C_REGION GlobalLowCardinality(String),C_PHONE FixedStri

48、ng(15),C_MKTSEGMENT GlobalLowCardinality(String)ENGINE=MergeTree()ORDER BY(C_CUSTKEY);CREATE TABLE dwdate ON CLUSTER ch_benchmark(D_DATEKEY UInt32,D_DATE String,1920 D_DAYOFWEEK String,-defined in Section 2.6 as Size 8,but Wednes-day is 9 letters D_MONTH String,D_YEAR UInt32,D_YEARMONTHNUM UInt32,D_

49、YEARMONTH String,D_DAYNUMINWEEK UInt32,D_DAYNUMINMONTH UInt32,D_DAYNUMINYEAR UInt32,D_MONTHNUMINYEAR UInt32,D_WEEKNUMINYEAR UInt32,D_SELLINGSEASON String,D_LASTDAYINWEEKFL UInt32,D_LASTDAYINMONTHFL UInt32,D_HOLIDAYFL UInt32,D_WEEKDAYFL UInt32)ENGINE=MergeTree()ORDER BY(D_DATEKEY);CREATE TABLE lineor

50、der ON CLUSTER ch_benchmark(LO_ORDERKEY UInt32,LO_LINENUMBER UInt8,LO_CUSTKEY UInt32,LO_PARTKEY UInt32,LO_SUPPKEY UInt32,LO_ORDERDATE UInt32,LO_ORDERPRIORITY GlobalLowCardinality(String),LO_SHIPPRIORITY UInt8,LO_QUANTITY UInt8,LO_EXTENDEDPRICE UInt32,LO_ORDTOTALPRICE UInt32,LO_DISCOUNT UInt8,LO_REVE

51、NUE UInt32,LO_SUPPLYCOST UInt32,LO_TAX UInt8,LO_COMMITDATE Date,LO_SHIPMODE GlobalLowCardinality(String)ENGINE=MergeTree()PARTITION BY toYear(toString(LO_ORDERDATE)ORDER BY(LO_ORDERDATE,LO_ORDERKEY);CREATE TABLE part ON CLUSTER ch_benchmark(P_PARTKEY UInt32,P_NAME String,P_MFGR GlobalLowCardinality(

52、String),P_CATEGORY GlobalLowCardinality(String),P_BRAND GlobalLowCardinality(String),P_COLOR GlobalLowCardinality(String),P_TYPE GlobalLowCardinality(String),P_SIZE UInt8,P_CONTAINER GlobalLowCardinality(String)ENGINE=MergeTree()ORDER BY(P_PARTKEY);CREATE TABLE supplier ON CLUSTER ch_benchmark(S_SUP

53、PKEY UInt32,S_NAME String,S_ADDRESS String,S_CITY GlobalLowCardinality(String),S_NATION GlobalLowCardinality(String),S_REGION GlobalLowCardinality(String),S_PHONE String)ENGINE=MergeTree()ORDER BY(S_SUPPKEY);-Create distributed tableDROP DATABASE IF EXISTS ssb ON CLUSTER ch_benchmark;CREATE DATABASE

54、 ssb ON CLUSTER ch_benchmark;use ssb;CREATE TABLE customer ON CLUSTER ch_benchmark AS ssb_local.customerENGINE=Distributed(ch_benchmark,ssb_local,customer,C_CUSTKEY);CREATE TABLE dwdate ON CLUSTER ch_benchmark AS ssb_local.dwdateENGINE=Distributed(ch_benchmark,ssb_local,dwdate,D_DATEKEY);CREATE TABL

55、E lineorder ON CLUSTER ch_benchmark AS ssb_local.lineorderENGINE=Distributed(ch_benchmark,ssb_local,lineorder,rand();CREATE TABLE part ON CLUSTER ch_benchmark AS ssb_local.partENGINE=Distributed(ch_benchmark,ssb_local,part,P_PARTKEY);CREATE TABLE supplier ON CLUSTER ch_benchmark AS ssb_local.supplie

56、rENGINE=Distributed(ch_benchmark,ssb_local,supplier,S_SUPPKEY);數據導入導入單表數據。Bashclickhouse-client-d bench-query INSERT INTO customer FORMAT CSV customer.tblclickhouse-client-d bench-query INSERT INTO part FORMAT CSV part.tblclickhouse-client-d bench-query INSERT INTO supplier FORMAT CSV supplier.tblcl

57、ickhouse-client-d bench-query INSERT INTO lineorder FORMAT CSV lineorder.tblclickhouse-client-d bench-query INSERT INTO dwdate FORMAT CSV=1993-01-01 and LO_ORDERDATE=1993-12-31 AND LO_DISCOUNT BETWEEN 1 AND 3 AND LO_QUANTITY=1994-01-01 and LO_ORDERDATE=1994-01-01 and LO_ORDERDATE=1992-01-01 AND LO_O

58、RDERDATE=MFGR#2221 AND P_BRAND=1997-12-01 AND LO_ORDERDATE=1992-01-01 AND LO_ORDERDATE=1992-01-01 AND LO_ORDERDATE=1997-01-01 and LO_ORDERDATE=1997-01-01 and LO_ORDERDATE=MFGR#2221 AND P_BRAND=MFGR#2228 AND S_REGION=ASIAGROUP BY D_YEAR,SQL-Q1.1SELECT SUM(LO_EXTENDEDPRICE*LO_DISCOUNT)AS REVENUEFROM l

59、ineorder,dwdateWHERE LO_ORDERDATE=D_DATEKEY AND D_YEAR=1993 AND LO_DISCOUNT BETWEEN 1 AND 3 AND LO_QUANTITY=1992 AND D_YEAR=1992 AND D_YEAR=1992 AND D_YEAR=date 1996-01-01 and l_shipdate date 1996-01-01+interval 3 monthGROUP BY l_suppkey;sum(l_extendedprice)as sum_base_price,sum(l_extendedprice*(1-l

60、_discount)as sum_disc_price,sum(l_extendedprice*(1-l_discount)*(1+l_tax)as sum_charge,avg(l_quantity)as avg_qty,avg(l_extendedprice)as avg_price,avg(l_discount)as avg_disc,count(*)as count_orderfrom lineitemwhere l_shipdate=date 1998-12-01group by l_returnflag,l_linestatusorder by l_returnflag,l_lin

61、estatus;-Q2select count(*)from(select s_acctbal,s_name,n_name,p_partkey,p_mfgr,s_address,s_phone,s_commentfrom part,partsupp,supplier,nation,regionwhere p_partkey=ps_partkey and s_suppkey=ps_suppkey and p_size=15 and p_type like%BRASS and s_nationkey=n_nationkey and n_regionkey=r_regionkey and r_nam

62、e=EUROPE and ps_supplycost=(select min(ps_supplycost)from partsupp,supplier,nation,region where p_partkey=ps_partkey and s_suppkey=ps_suppkey and s_nationkey=n_nationkey and n_regionkey=r_regionkey and r_name=EUROPE )order by s_acctbal desc,n_name,s_name,p_partkey)as t1;-Q3select count(*)from(select

63、 l_orderkey,sum(l_extendedprice*(1-l_discount)as revenue,o_orderdate,o_shippriority導入數據Pythonclickhouse-client-d bench-query=insert into region format CSV region.tbl;clickhouse-client-d bench-query=insert into nation format CSV nation.tbl;clickhouse-client-d bench-query=insert into supplier format C

64、SV supplier.tbl;clickhouse-client-d bench-query=insert into part format CSV part.tbl;clickhouse-client-d bench-query=insert into customer format CSV customer.tbl;clickhouse-client-d bench-query=insert into lineitem format CSV lineitem.tbl;clickhouse-client-d bench-query=insert into orders format CSV

65、 orders.tbl;clickhouse-client-d bench-query=insert into partsupp format CSV partsupp.tbl;查詢數據SQL-Q1select l_returnflag,l_linestatus,sum(l_quantity)as sum_qty,性能測試過程中，將執行以下 22 條查詢 SQL。from customer,orders,lineitem where c_mktsegment=BUILDING and c_custkey=o_custkey and l_orderkey=o_orderkey and o_ord

66、erdate date 1995-03-15 group by l_orderkey,o_orderdate,o_shippriority order by revenue desc,o_orderdate )as t1;-Q4select o_orderpriority,count(*)as order_countfrom orderswhere o_orderdate=date 1993-07-01 and o_orderdate date 1993-07-01+interval 3 month and exists(select *from lineitem where l_orderk

67、ey=o_orderkey and l_commitdate=date 1994-01-01 and o_orderdate=date 1994-01-01 and l_shipdate date 1994-01-01+interval 1 year and l_discount between 0.06-0.01 and 0.06+0.01 and l_quantity=date 1993-10-01 and o_orderdate (select sum(ps_supplycost*ps_availqty)*0.0001000000 from partsupp,supplier,natio

68、n where ps_suppkey=s_suppkey and s_nationkey=n_nationkey and n_name=GERMANY )order by value desc)as t1;4950-Q12select l_shipmode,sum(case when o_orderpriority=1-URGENT or o_orderpriority=2-HIGH then 1 else 0 end)as high_line_count,sum(case when o_orderpriority 1-URGENT and o_orderpriority 2-HIGH the

69、n 1 else 0 end)as low_line_countfrom orders,lineitemwhere o_orderkey=l_orderkey and l_shipmode in(MAIL,SHIP)and l_commitdate l_receiptdate and l_shipdate=date 1994-01-01 and l_receiptdate=date 1995-09-01 and l_shipdate date 1995-09-01+interval 1 month;-Q15select s_suppkey,s_name,s_address,s_phone,to

70、tal_revenuefrom supplier,revenue0where s_suppkey=supplier_no and total_revenue=(select max(total_revenue)from revenue0 )order by s_suppkey;-Q16select count(*)from(select p_brand,p_type,p_size,count(distinct ps_suppkey)as supplier_cntfrom partsupp,partwhere p_partkey=ps_partkey and p_brand Brand#45 a

71、nd p_type not like MEDIUM POLISHED%and p_size in(49,14,23,45,19,3,36,9)and ps_suppkey not in(select s_suppkey from supplier where s_comment like%Customer%Complaints%)group by p_brand,p_type,p_sizeorder by supplier_cnt desc,p_brand,p_type,p_size)as t1;-Q17select sum(l_extendedprice)/7.0 as avg_yearly

72、from lineitem,partwhere p_partkey=l_partkey and p_brand=Brand#23 and p_container=MED BOX and l_quantity 300 )and c_custkey=o_custkey and o_orderkey=l_orderkeygroup by c_name,c_custkey,o_orderkey,o_orderdate,o_totalpriceorder by o_totalprice desc,o_orderdate)as t1;-Q19select sum(l_extendedprice*(1-l_

73、discount)as revenuefrom lineitem,partwhere (p_partkey=l_partkey and p_brand=Brand#12 and p_container in(SM CASE,SM BOX,SM PACK,SM PKG)and l_quantity=1 and l_quantity=10 and l_quantity=20 and l_quantity (select 0.5*sum(l_quantity)from lineitem where l_partkey=ps_partkey and l_suppkey=ps_suppkey and l

74、_shipdate=date 1994-01-01 and l_shipdate l1.l_commitdate and exists(select *from lineitem l2 where l2.l_orderkey=l1.l_orderkey and l2.l_suppkey l1.l_suppkey )and not exists(select *from lineitem l3 where l3.l_orderkey=l1.l_orderkey and l3.l_suppkey l1.l_suppkey and l3.l_receiptdate l3.l_commitdate )

75、and s_nationkey=n_nationkey and n_name=SAUDI ARABIAgroup by s_nameorder by numwait desc,s_name)as t1;-Q22select cntrycode,count(*)as numcust,sum(c_acctbal)as totacctbalfrom (select substr(c_phone,1,2)as cntrycode,c_acctbal from customer where substr(c_phone,1,2)in (13,31,23,29,30,18,17)and c_acctbal

76、 (select avg(c_acctbal)from customer where c_acctbal 0.00 and substr(c_phone,1,2)in (13,31,23,29,30,18,17)and not exists(select *from orders where o_custkey=c_custkey )as custsalegroup by cntrycodeorder by cntrycode;5556測試結果經過測試發現，在完成 TPC-DS 標準測試數據集的 99 個查詢中，開源產品 C*總體時間超出 6 倍多，且部分語句無法正常執行。在兩者均完成查詢的結

77、果中，開源 OLAP C*與 ByteHouse 查詢時間相差15.7 倍，其中 Q53、Q63、Q82 等語句的查詢效率相差 200 倍左右，具體數據如下圖：TPC-DS 性能測試5758q23q24q25q26q27q28q29q30q31q32q33q34q35q36q37q38q39q40q41q42q43q441002516512802894231403356328112610627020771925114313295741791711112153730266120676123925100014887096784901197219361720256203498047556001898

78、查詢完成時間（ms）ByteHouse開源 OLAP C*q1q2q3q4q5q6q7q8q9q10q11q12q13q14q15q16q17q18q19q20q21q224202875085899416382348223106619833671281430671130249037663526013020391408950523900011544860222301028166170025520006782106914871897查詢完成時間（ms）ByteHouse開源 OLAP C*5960q67q68q69q70q71q72q73q74q75q76q77q78q79q80q81q82q83

79、q84q85q86q87q8848393022955701801787158271224125454485984549554458205249261528200134411167837815600386337510813009609500168096090385084935606242135617485594查詢完成時間（ms）ByteHouse開源 OLAP C*6162q45q46q47q48q49q50q51q52q53q54q55q56q57q58q59q60q61q62q63q64q65q662133951014603229416276011018039211223466042310

80、3942834536618213857555751618162700065651591147083714633528484297502832434710373360121237093000查詢完成時間（ms）ByteHouse開源 OLAP C*測試環境下面列舉了本次性能測試所使用的環境信息。硬件環境每個測試環境 3 個節點，配置如下：CPU 8 核：INTEL內存：32 GB網絡帶寬：5 Gbits/s磁盤：ESSD 高效云盤，空間 500 GB測試步驟準備工作軟件環境內核版本：Linux 3.10.0-1127.19.1.el7.x86_64 x86_64操作系統：CentOS Linux

81、 release 7.8.2003(Core)數據庫版本：開源產品 C*：24.3.1.1023ByteHoue 企業版:2.4.0.231 1.請掃描下面的二維碼聯系 ByteHouse 小助手，回復“ByteHouse 性能測試腳本”，獲取最新版本的 ByteHouse-TPCDS 測試腳本。2.確保安裝了 ClickHouse Client 程序，詳情可參考 ClickHouse Client。6364q89q90q91q92q93q94q95q96q97q98q992253152271114954642762771953158551397343301469068240054713921

82、20562064查詢完成時間（ms）ByteHouse開源 OLAP C*6566安裝依賴Bashsudo apt-get install gcc make flex bison byacc git time通過下面的命令安裝依賴程序。查詢數據在 ByteHouse 上運行 TPD-DS 100G 基準測試，運行成功后系統會顯示測試結果。Bash./benchmark.sh 100版權聲明本書正文部分的所有內容，包括但不限于文字、商標、架構、圖示、圖片、頁面布局等，其知識產權（著作權、商標權、專利權、商業秘密等）歸屬于北京火山引擎科技有限公司及其關聯公司，非經火山引擎書面同意，任何個人和組織不

83、得復制、使用、修改、轉發或以任何違反本書所承載的目的進行傳播。獲取并解壓 ByteHouse-TPCDS 工具包，進入目錄后先配置 Config 文件，重點關注配置文件中的ByteHouse 連接地址 ip、端口，以及 連接密碼。Bashcp config.sh.tpl config.sh創建指向“bin/clickhouse”的軟鏈接。Bashln-s$path-to-clickhouse-binary bin/clickhouse按下面的命令完成編譯。Bashchmod a+x*.sh./build.sh生成數據生成 TPC-DS 標準測試集 100G 的數據。這一過程可能時間較長，請耐心等待。Bash./gen_data.sh 100導入數據執行命令將生成的 TPD-DS 數據從數據文件導入到 ByteHouse。這一過程可能時間較長，請耐心等待。Bash./populate_data.sh 100創建表結構運行下面的命令以在 ByteHouse 中創建數據庫和表。SQL./create_table.sh 100