ClickHouse 作為業(yè)界性能最強大的 OLAP 系統(tǒng)，在小紅書內(nèi)部被廣泛應用于廣告、社區(qū)、直播和電商等多個業(yè)務領域。然而，原生 ClickHouse 的 MPP 架構(gòu)在運維成本、彈性擴展和故障恢復方面存在較大局限性。為應對挑戰(zhàn)，小紅書數(shù)據(jù)流團隊基于開源 ClickHouse 自主研發(fā)了云原生實時數(shù)據(jù)倉庫 RED ClickHouse（以下簡稱“REDck”）。

在保持 ClickHouse 原有超高性能的基礎上，我們對其進行深度的云原生改造，實現(xiàn)了計算和存儲層的彈性擴縮容能力，從而有效減輕運維負擔并降低成本。REDck 具備支持 PB 級別數(shù)據(jù)的用戶交互式分析能力，能夠靈活滿足各類數(shù)據(jù)分析需求，以滿足小紅書日益增長的業(yè)務和數(shù)據(jù)分析需求。

目前，REDck 已成功在公司電商、廣告、社區(qū)、直播等 10+ 個業(yè)務場景上落地，總存儲規(guī)模達到 30+PB。它在降本增效方面取得顯著成效，特別是在實驗平臺和用戶行為分析平臺等典型場景中。以實驗平臺為例，在過去 2 年里，實驗平臺的數(shù)據(jù)存儲周期從 2 個月增長到 2 年，實驗指標數(shù)量和分析場景也增長 10 倍以上。在如此快速的業(yè)務增長下，REDck 為實驗平臺提供了 99.9% 的可用性保障，其強大的可擴展性成為了業(yè)務擴展的有力支撐。

1.1 小紅書實時 OLAP 的發(fā)展

小紅書從誕生之日起，整個基建體系全部搭建在公有云之上，是云上的原住民。

如上圖所示，小紅書的云原生大數(shù)據(jù)架構(gòu)體系，自上而下分別是應用層、計算引擎層、計算資源層、數(shù)據(jù)層和存儲層。

●?存儲層核心是各大云廠商提供的對象存儲服務，數(shù)據(jù)層采用通用的數(shù)據(jù)格式如 Parquet、ORC、Avro 等，并通過 Hive Metastore 提供統(tǒng)一的元信息服務。

●?在計算層，小紅書利用 Kubernetes、YARN 等計算資源框架提供資源池化和彈性擴展能力。

●?在計算引擎層，借助 Spark、Flink 等技術(shù)實現(xiàn)離線和實時 ETL 鏈路，并通過 Presto、SparkSQL 等工具對外提供離線報表和數(shù)據(jù)分析功能。

這種典型的云原生架構(gòu)為小紅書的數(shù)據(jù)處理提供了高度的靈活性和可擴展性。然而，在此架構(gòu)體系中，實時 OLAP 引擎的缺失限制了小紅書數(shù)據(jù)分析業(yè)務的發(fā)展；亟需引入擁有強大分析性能的實時 OLAP 引擎，以滿足不斷增長的數(shù)據(jù)分析需求。

ClickHouse 作為一款高性能的實時 OLAP 數(shù)據(jù)庫，以其出色的極致性能、快速穩(wěn)定的更新迭代、積極響應的開源社區(qū)等優(yōu)勢，受到各大公司的青睞。為了實現(xiàn)更快速的查詢和分析，小紅書數(shù)據(jù)流團隊為公司的實驗平臺構(gòu)建了 ClickHouse 集群。

1.2 面臨的問題

在初期階段 ClickHouse 展示了出色的性能，具備極快的查詢響應速度，提供了靈活性和實時性，為小紅書的數(shù)據(jù)分析服務提供了更強大的 Ad-Hoc 分析能力。但隨著數(shù)據(jù)的累積，集群規(guī)模不斷膨脹，現(xiàn)有的實時 OLAP 系統(tǒng)在使用中遇到以下問題：

●?彈性擴展困難

隨著小紅書業(yè)務的快速發(fā)展，擴容成為團隊頻繁進行的運維操作。ClickHouse 采用 Share-Nothing 架構(gòu)， 每個節(jié)點的計算和存儲資源強綁定，導致集群擴容受限于機器的調(diào)度周期。同時，擴容過程中會引入以周甚至以月為單位的數(shù)據(jù)遷移工作，對用戶的查詢產(chǎn)生影響，包括穩(wěn)定性和一致性問題。

●?資源利用率低

ClickHouse 通過多副本機制來提高整體的可靠性，但也導致資源幾何倍增。由于存儲和計算比例失調(diào)， 在大多數(shù)場景下，數(shù)據(jù)存儲量的需求遠大于計算需求，卻因為存算綁定而造成算力嚴重浪費。此外，許多業(yè)務存在明顯的波峰和波谷，缺乏彈性擴展能力導致嚴重的資源冗余。

●?穩(wěn)定性問題

ClickHouse 在資源隔離能力方面較弱，容易引發(fā)用戶查詢體驗的不穩(wěn)定性問題。在查詢高峰期，資源緊張會導致查詢失敗率和查詢時延顯著增加。另外，ClickHouse 的多副本機制重度依賴 Zookeeper，當集群規(guī)模達到一定程度時，Zookeeper 的故障頻率增高，限制了集群的擴展能力。

●?數(shù)據(jù)同步問題

ClickHouse 一直被用戶詬病的問題就是缺乏成熟的分布式事務系統(tǒng)，數(shù)據(jù)同步時經(jīng)常出現(xiàn)數(shù)據(jù)不一致的現(xiàn)象。

●?可維護性問題

ClickHouse 分布式表和底層復制表模式大大增加了表管理的難度，同時缺少必要的分布式管理功能，如節(jié)點加入、節(jié)點退出和副本均衡等，使得一旦集群數(shù)量變多，維護代價巨大。

基于上述原因，社區(qū)開源版的 ClickHouse 難以滿足公司在廣告、社區(qū)、直播、電商等業(yè)務需求方面的大規(guī)模應用。解決集群岌岌可危的存儲上限和運維等問題，對團隊來說迫在眉睫。

1.3 解決方案選型

方案1：集群擴容

集群擴容是一種常見解決存儲瓶頸問題的方案。然而，社區(qū)開源版的 ClickHouse 沒有內(nèi)置支持自動平衡數(shù)據(jù)負載的功能，因此新加入的節(jié)點需要手動平衡負載，并同步其他集群的表結(jié)構(gòu)。此外，擴容無法真正地解決海量數(shù)據(jù)業(yè)務的挑戰(zhàn)，最終仍需要添加 TTL 來刪除歷史數(shù)據(jù)。同時，擴容后的集群在可用性方面存在風險，需要投入雙倍機器資源以避免單點故障導致的數(shù)據(jù)丟失，增加了成本和復雜性。

綜上，集群擴容方案不僅大大增加了運維難度，而且未能從根本上解決存儲瓶頸問題。存儲問題依然是一把時刻懸在團隊頭上的“達摩克利斯之劍“。

方案2：存算分離

另一個方案則是更困難的路，即自研云原生實時數(shù)倉。盡管該方案面臨諸多挑戰(zhàn)，如元信息中心化、存算分離改造、容器化等，需要團隊從運維能力轉(zhuǎn)向自主研發(fā)，但它能從根本上解決擴展性問題。

在傳統(tǒng)數(shù)據(jù)庫系統(tǒng)中，存儲與計算通常強綁定，即共用相同機器資源。得益于當下云原生技術(shù)的飛速發(fā)展，越來越多的數(shù)據(jù)庫系統(tǒng)選擇擁抱存算分離架構(gòu)，將存儲層與計算層解耦，使得存儲資源和計算資源分別彈性擴展成為可能。存算分離架構(gòu)帶來諸多益處：首先，將數(shù)據(jù)存儲到云廠商提供的對象存儲中，使數(shù)據(jù)存儲擁有了近乎無限擴展的能力。其次，根據(jù)需求動態(tài)調(diào)整計算資源，滿足高頻實時計算的性能需求并控制成本。最后，在面對故障時，可以快速遷移和恢復外部數(shù)據(jù)存儲，從而極大提高數(shù)據(jù)的可靠性。

如今，云原生數(shù)據(jù)庫大多是基于存算分離架構(gòu)實現(xiàn)，如 SnowFlake、Redshift、TiDB 等?？梢哉f，存算分離已成為分布式數(shù)據(jù)庫的主流方向。

1.4 我們的選擇

最終我們選擇了正確但困難的道路，希望通過自研存算分離架構(gòu)，從根本上解決實時 OLAP 引擎在擴容和運維方面的問題，更好地支撐小紅書分析業(yè)務的快速發(fā)展。自研使我們能快速響應業(yè)務需求，并有利于成本控制。

基于社區(qū)開源版 ClickHouse，我們打造了基于對象存儲的存算分離版 Red ClickHouse，簡稱?REDck。

小紅書自研云原生分析型數(shù)據(jù)庫的整體設計圖，如上圖所示。REDck 具備在海量數(shù)據(jù)下提供秒級的實時復雜分析能力，在公司內(nèi)廣泛支撐了非常多的業(yè)務場景，如A/B測試分析、用戶行為分析和廣告用戶分群等。

2.1 存算分離架構(gòu)

REDck 的存算分離架構(gòu)如下圖，具體包括三層：

●?統(tǒng)一的元信息中心

在開源 ClickHouse中，元信息存儲在各個節(jié)點的本地磁盤目錄下，并通過讀取目錄列表構(gòu)建對應的元信息。而 REDck 構(gòu)建的統(tǒng)一元信息服務是一個無狀態(tài)的中心化服務，包括內(nèi)部存儲和外部存儲等多種存儲方式；內(nèi)部存儲模型選擇關系型數(shù)據(jù)庫（如 MySQL）或健值數(shù)據(jù)庫（如 Redis），外部存儲模式可以與 Hive 數(shù)倉以及 Iceberg 數(shù)據(jù)湖進行深度集成。

構(gòu)建統(tǒng)一元信息服務層的好處是集群整體信息可以集中掌握，而不是離散到各個機器節(jié)點上。集中化的信息管理能力使得數(shù)據(jù)庫引擎，更方便地實現(xiàn)存算分離和事務機制。目前每個集群擁有自己獨立的元信息服務，未來可進一步實現(xiàn)多集群的元數(shù)據(jù)服務，即元數(shù)據(jù)服務只有一份，可以多個集群共享。

●?計算層

以計算組為基本單位，每個計算組內(nèi)是一個多節(jié)點的分布式計算集群，用戶通過網(wǎng)關對計算倉庫進行訪問，無需關心底層的 Server Node 和 Worker Node 等細節(jié)信息。計算任務將由 Server Node 按需調(diào)度至 Worker Node 上執(zhí)行。在此之上集群還有 Master 角色負責管理協(xié)調(diào)集群中心狀態(tài)。得益于存算分離的實現(xiàn)，集群能夠輕松進行橫向和縱向擴展。

●?存儲層

存儲層實現(xiàn)了分布式文件系統(tǒng)、對象存儲等多種低成本存儲方式，為數(shù)據(jù)庫提供高效、可擴展的存儲能力，以滿足海量數(shù)據(jù)處理需求。

2.2 統(tǒng)一元數(shù)據(jù)服務

將數(shù)據(jù)存儲在云上的對象存儲后，確保每個節(jié)點都能夠訪問數(shù)據(jù)的元信息是一項具有挑戰(zhàn)性的任務。在開源 ClickHouse 中，元信息來源于磁盤的目錄，通過讀取目錄列表構(gòu)建相應的元信息。然而元信息分散在每個節(jié)點內(nèi)部，每個節(jié)點都有獨一無二的狀態(tài)，當有節(jié)點宕機時，整個集群就無法使用。為了實現(xiàn)每個節(jié)點共享統(tǒng)一的元數(shù)據(jù)信息并提高可靠性，REDck 引入了統(tǒng)一元信息庫和 Metastore 角色。Metastore 負責統(tǒng)一管理集群的元信息。每個計算節(jié)點啟動后，只需要訪問 Metastore 獲取最新的元信息即可。

統(tǒng)一元信息庫存儲分為內(nèi)部存儲和外部存儲兩種方式，我們使用 MySQL 作為內(nèi)部存儲來存儲元數(shù)據(jù)，并利用 MySQL 的事務特性確保整體一致性。Metastore 接管并維護整個集群的信息，使得集群無需再通過 Zookeeper 進行管理，從而解除了 Zookeeper 對 ClickHouse 的束縛。同時，對于元信息的存儲，我們使用內(nèi)部自研的 REDkv（類比開源 Redis）實現(xiàn)了一套文件系統(tǒng)映射，使集群完全脫離磁盤文件系統(tǒng)的限制，實現(xiàn)真正的云原生。在外部存儲方面，我們積極與 Hive 數(shù)倉以及 Iceberg 數(shù)據(jù)湖進行深度集成，使得 REDck 可以直接從外部存儲中讀取元信息。

Metastore 與 REDck 之間的通信流程如下圖所示，首先部署好的 MetaStore 會向注冊中心發(fā)送注冊請求，對服務進行注冊。當 REDck 集群部署好后，會向注冊中心請求進行服務發(fā)現(xiàn)，并訪問發(fā)現(xiàn)的服務以獲取元數(shù)據(jù)信息。

2.3 對象存儲訪問優(yōu)化

對象存儲具有無限擴展、低成本、可靠性極高的特點。通過使用對象存儲來存儲數(shù)據(jù)，我們能夠從根本上解決不斷增長的數(shù)據(jù)存儲需求，從此告別傳統(tǒng)數(shù)據(jù)存儲帶來的煩惱。對象存儲的可靠性使我們能夠摒棄副本機制，從而解決了副本一致性、資源浪費、Zookeeper 穩(wěn)定性等一系列棘手問題，為 REDck 節(jié)點的無狀態(tài)化提供了基礎。

但對象存儲也并不是十全十美，引入對象存儲之后，我們碰到了如下問題：

●?訪問速度：對象存儲的總吞吐上限理論上只受帶寬限制，但是單線程訪問速度較低，遠低于磁盤。

●?延遲：目前對象存儲訪問主要通過 HTTP 協(xié)議，延遲較高（包括建立連接等操作的延遲可達到 20 毫秒級別），對部分小文件極其不友好。

●?穩(wěn)定性：如何減輕多家云廠商對象存儲穩(wěn)定性問題對計算層的影響。

對象存儲作為 REDck 的基石，它的性能問題將成為整個數(shù)據(jù)庫系統(tǒng)的瓶頸。為此，我們針對對象存儲的讀寫問題進行了以下優(yōu)化：

●?提升緩存機制：通過緩存機制提升對象存儲的訪問速度，從而實現(xiàn)查詢性能的百倍提升（詳見緩存策略）。針對非緩存的數(shù)據(jù)，采用并行化手段提升數(shù)據(jù)下載速度，實現(xiàn)十倍的性能提升。

●?優(yōu)化查詢計算過程：通過查詢執(zhí)行計劃重排序、多線程自適應優(yōu)化等手段，將 HTTP 延遲降低到用戶可以忽略的程度。

●?重構(gòu)訪問模塊：對對象存儲訪問模塊進行優(yōu)化和重構(gòu)，添加數(shù)據(jù)檢查、超時檢測和失敗重試機制，提升訪問的穩(wěn)定性。

具體流程如下圖所示：

1. ?客戶端將查詢發(fā)送至服務端，服務端根據(jù)查詢選擇需要讀取的 Parts，同時對 Parts 的 markRanges 進行重排序，使每個連接線程讀取相同 Part 的 Mark，減少連接次數(shù)，從而降低 HTTP 延遲。

2. ?將重排序后的 Ranges 傳給對應的 Part 類，Part 根據(jù) Ranges 的大小，動態(tài)選擇下載方式（分為三種），可減少下載壓力。

a. ?對于大型的 Part，采用多線程多段下載的方式，最后將多段合并成一個 Part。

b. ?對于小型的 Part，采用先緩存到內(nèi)存，再下載到本地的方式。

c. ?對于其他的 Part，選擇直接下載到本地的方式。

3. ?服務端獲取到下載的 Part，并計算查詢結(jié)果，返回給客戶端。

2.4 緩存優(yōu)化

對象存儲為我們實現(xiàn)存算分離提供了基礎，但同時也帶來了查詢時必須從云上拉取而導致延遲的問題。盡管通過對象存儲的優(yōu)化手段解決了大部分場景下的拉取問題，但對于部分頻繁訪問的熱數(shù)據(jù)，反復從云端拉取并不高效。為此我們提出了緩存策略，利用機器的磁盤用作對象存儲的緩存盤，為高頻查詢需求提供高性能保障。

整個多級緩存架構(gòu)如圖所示：內(nèi)存緩存 -> 本地磁盤緩存 -> 分布式緩存。從上到下，緩存的性能由高到低，可用性和容量由低到高，分別適用于不同類型和熱度的數(shù)據(jù)。這種多級緩存架構(gòu)幫助我們以最少的成本為用戶提供極致的查詢性能體驗。針對數(shù)據(jù)的特征，我們提供了兩種緩存策略：

●?被動緩存：適用于不可預知的數(shù)據(jù)，在用戶查詢時，臨時緩存對應的數(shù)據(jù)，以提高后續(xù)查詢的性能。

●?主動緩存：適用于可以預知會被頻繁訪問的數(shù)據(jù)。集群啟動后，系統(tǒng)會在后臺主動根據(jù)用戶設定的規(guī)則和用戶的查詢歷史，智能推算用戶今天可能會查詢的數(shù)據(jù)，并將這些數(shù)據(jù)預先從對象存儲緩存到本地磁盤，用戶查詢時直接從本地讀取，性能與本地磁盤相當。

同時，由于本地磁盤空間有限，我們提供了兩種緩存淘汰策略：LRU 和 Clock Sweep。為進一步優(yōu)化緩存清理的速度，我們在內(nèi)存中構(gòu)建了磁盤的 Catalog，以便快速篩選需要淘汰的緩存數(shù)據(jù)。

2.5 分布式任務調(diào)度

通過對象存儲和緩存策略，REDck 的集群節(jié)點能夠共享存儲在云廠商的數(shù)據(jù)，從而減輕了本地磁盤的壓力，但同時帶來了任務執(zhí)行沖突的挑戰(zhàn)。這里的任務類型包括 Compaction、Mutation、Insert 以及緩存任務等。在原有架構(gòu)中，每個實例相互獨立，無需考慮任務調(diào)度沖突。而實現(xiàn)存算分離后，不同節(jié)點之間的任務調(diào)度需要進行規(guī)劃，實現(xiàn)有序調(diào)度，以避免沖突。這對我們有兩個核心挑戰(zhàn)點：

1. ?如何統(tǒng)一調(diào)度全局的任務計劃；

2. ?在集群擴縮容過程中，如何自動調(diào)整調(diào)度計劃，以確保沒有任務沖突。

為實現(xiàn)統(tǒng)一調(diào)度，我們引入了全局選舉唯一的 Master 角色，Master 指定特定的 Server 作為整表的全局任務協(xié)調(diào)者。該協(xié)調(diào)者根據(jù)預設的調(diào)度策略（例如按 bucket 進行調(diào)度），將不同的任務進行分配，以確保所有任務有序執(zhí)行。但在集群異常情況下，可能會出現(xiàn)腦裂、任務分配重復等問題，為了解決這些問題，我們在整個任務執(zhí)行的過程中增加了事務管理和異常檢測邏輯，以保證不會有任務沖突，維護數(shù)據(jù)準確性。

2.6 數(shù)據(jù)分桶

如前所述，為了實現(xiàn)分布式任務調(diào)度，我們引入一個全局選舉的 Master 角色。然而在執(zhí)行分配任務過程中，如果沒有合適的調(diào)度策略，數(shù)據(jù)分布可能過于分散，導致聚合和多表連接的性能下降，并經(jīng)常會伴隨機器內(nèi)存溢出（OOM）和計算傾斜等問題。為了解決這些問題，我們在 REDck 中引入了桶 (Bucket)?的概念。

桶是指將表或分區(qū)中指定列的值為 Key 進行 Hash，將其 Hash 到指定的桶中，例如實驗平臺中將用戶 ID 指定為 Bucket 劃分的 Key。通過數(shù)據(jù)分桶，我們獲得以下幾個優(yōu)化效果：

●?在單點查詢時，可以通過分桶鍵進行快速過濾，實現(xiàn)高速索引的功能，從而減少數(shù)據(jù)讀取量。

●?通過分桶優(yōu)化聚合和多表連接查詢的性能，避免數(shù)據(jù) Shuffle。

通過將數(shù)據(jù)按 Bucket 劃分，我們在任務調(diào)度過程中以 Bucket 為單位，靈活調(diào)度 Bucket 和節(jié)點之間的映射關系，為彈性擴縮容提供了基礎。

2.7 分布式事務

經(jīng)過一系列優(yōu)化措施，如對象存儲的優(yōu)化、增加緩存策略、添加分布式任務調(diào)度、引入 Bucket 的概念等，REDck 的基本使用已經(jīng)比較穩(wěn)定。然而，在大規(guī)模部署集群后，我們發(fā)現(xiàn)從 Hive/Spark 導入數(shù)據(jù)到 ClickHouse 的過程中，由于不支持事務機制，經(jīng)常會發(fā)生寫入重復數(shù)據(jù)的問題。這是由于開源的 ClickHouse 本身缺少成熟的事務機制，也一直是眾多用戶所詬病的點。雖然 ClickHouse 內(nèi)有一套 Transaction 機制，但僅適用于單機模式，無法應用于我們部屬的分布式集群。因此，為了實現(xiàn) REDck 的 Exactly-Once 功能，減少數(shù)據(jù)導入過程中的失敗和數(shù)據(jù)不一致，提高系統(tǒng)導數(shù)的穩(wěn)定性，帶來的收益是很可觀的。

基于統(tǒng)一管理的元數(shù)據(jù)中心，我們實現(xiàn)了 REDck 的事務機制，對數(shù)據(jù)攝入進行事務管理，并通過 Metastore 角色統(tǒng)一管理全局的數(shù)據(jù)可見性，從而實現(xiàn)兩階段事務提交功能。這一改進使得我們能夠確保數(shù)據(jù)寫入的一致性和可靠性，避免重復數(shù)據(jù)的產(chǎn)生。

在實現(xiàn)了 REDck 的兩階段提交之后，我們進一步和 Flink 的 Checkpoint 機制打通，實現(xiàn)了Flink -> REDck 數(shù)據(jù)鏈路的 Exactly-Once 語義，提高數(shù)據(jù)處理的準確性和可靠性。

2.8 離線同步鏈路優(yōu)化

在離線數(shù)據(jù)攝入方面，我們使用 Spark 離線導入方式代替了原有的 Flink 小批導入方式，從而降低導入鏈路的復雜度，提升導數(shù)的效率，并消除由額外的 Compaction 工作引入的寫放大問題。同時，該離線導入方式天然支持 insert overwrite 語義，用戶不會讀取到正在導入的的數(shù)據(jù)，提供了更好的查詢體驗。

經(jīng)兩年多的發(fā)展，REDck 已全面上線，覆蓋公司廣告、電商、直播等多個領域的 10+ 條業(yè)務線，取得了顯著效果：

●?降低成本：通過存算分離改造，解決了實驗平臺集群窘迫資源上限的問題。改造前，集群的存儲空間僅為 TB 級別，改造后，理論上可以存儲無限的數(shù)據(jù)，實際上我們存儲了?PB 級別的數(shù)據(jù)，其中最大的計算組規(guī)模達到萬 Core 規(guī)模，單個集群最大存儲量達十 PB。此外，用戶的查詢時間范圍也從以月為單位增長到以年為單位。相比于原本的 ClickHouse，REDck 單位 CPU 能處理的數(shù)據(jù)量增長了?10 倍之多，大幅度減少了 CPU 資源浪費。同時基于存算分離的架構(gòu)，我們節(jié)省了多副本機制帶來的成本壓力，單位存儲成本也降低了?10 倍之多。

●?提高效率：在寫入性能方面，通過使用 Spark 對離線鏈路進行全面改造，離線導入性能提升了一倍。在查詢性能方面，盡管引入了分布式元數(shù)據(jù)服務和性能較慢的對象存儲，但 REDck 通過對象存儲讀優(yōu)化、多級緩存、預熱等技術(shù)手段，優(yōu)化單機查詢性能，查詢性能媲美原生ClickHouse。同時存算分離帶來了彈性擴展方面的優(yōu)勢，可以在業(yè)務高峰期進行分鐘級別的動態(tài)擴容，用戶再也不用擔心高峰期的查詢擁堵問題。

●?高可用性：摒棄原生 ClickHouse 冗余且難以管理的多副本模式，REDck 依托對象存儲，通過多種優(yōu)化手段使數(shù)據(jù)可靠性達到?99.9%。實現(xiàn)存算分離后，數(shù)據(jù)存儲在云端，單個節(jié)點的宕機不會影響整個集群的正常執(zhí)行，整體的可用性能達到?99.9%。

●?可擴展性：REDck 的云原生特性顯著降低了集群擴展的運維壓力，集群擴容的時間周期由周級別降低為分鐘級別。這得益于通過統(tǒng)一的元信息服務消除了 Zookeeper 這個明顯的中心化瓶頸，橫向無限擴展虛擬倉庫以支持不同業(yè)務的環(huán)境部署，縱向可隨需擴展虛擬倉庫的節(jié)點以增強抗壓能力，實現(xiàn)負載均衡。目前，最大虛擬倉庫可以擴展到?100+?節(jié)點規(guī)模。此外，REDck 采用統(tǒng)一的表引擎，將分布式表、Zookeeper、Replica 等概念對用戶屏蔽，使運維管理更加便捷。

白樺

小紅書數(shù)據(jù)平臺部 OLAP 研發(fā)專家，負責小紅書 OLAP 方向的架構(gòu)和研發(fā)工作，主要包括云原生實時數(shù)倉、湖倉一體化方向的研發(fā)與落地，有豐富的 OLAP 架構(gòu)和實踐經(jīng)驗。

龐博

小紅書數(shù)據(jù)平臺部 LakeHouse 團隊負責人，負責 OLAP 及數(shù)據(jù)湖方向。

銅須

小紅書數(shù)據(jù)平臺部 OLAP 研發(fā)，負責小紅書 OLAP 方向的研發(fā)工作，主要包括 REDck 的研發(fā)與落地。文章來源地址http://www.zghlxwxcb.cn/news/detail-699706.html

到了這里，關于ClickHouse 存算分離改造：小紅書自研云原生數(shù)據(jù)倉庫實踐的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！