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

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

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

1、背景介紹

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

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

引入實(shí)時(shí) OLAP 之前的系統(tǒng)架構(gòu)

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

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

● 在計(jì)算層，小紅書(shū)利用 Kubernetes、YARN 等計(jì)算資源框架提供資源池化和彈性擴(kuò)展能力。

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

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

引入實(shí)時(shí)OLAP之后的系統(tǒng)架構(gòu)

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

1.2 面臨的問(wèn)題

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

● 彈性擴(kuò)展困難

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

● 資源利用率低

ClickHouse 通過(guò)多副本機(jī)制來(lái)提高整體的可靠性，但也導(dǎo)致資源幾何倍增。由于存儲(chǔ)和計(jì)算比例失調(diào)， 在大多數(shù)場(chǎng)景下，數(shù)據(jù)存儲(chǔ)量的需求遠(yuǎn)大于計(jì)算需求，卻因?yàn)榇嫠憬壎ǘ斐伤懔?yán)重浪費(fèi)。此外，許多業(yè)務(wù)存在明顯的波峰和波谷，缺乏彈性擴(kuò)展能力導(dǎo)致嚴(yán)重的資源冗余。

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

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

● 數(shù)據(jù)同步問(wèn)題

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

● 可維護(hù)性問(wèn)題

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

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

1.3 解決方案選型

方案1：集群擴(kuò)容

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

綜上，集群擴(kuò)容方案不僅大大增加了運(yùn)維難度，而且未能從根本上解決存儲(chǔ)瓶頸問(wèn)題。存儲(chǔ)問(wèn)題依然是一把時(shí)刻懸在團(tuán)隊(duì)頭上的“達(dá)摩克利斯之劍“。

方案2：存算分離

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

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

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

1.4 我們的選擇

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

基于社區(qū)開(kāi)源版 ClickHouse，我們打造了基于對(duì)象存儲(chǔ)的存算分離版 Red ClickHouse，簡(jiǎn)稱(chēng) REDck。

2、云原生實(shí)時(shí)數(shù)倉(cāng)設(shè)計(jì)與實(shí)現(xiàn)

云原生實(shí)時(shí)數(shù)倉(cāng)整體設(shè)計(jì)圖

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

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

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

REDck 整體架構(gòu)圖

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

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

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

● 計(jì)算層

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

● 存儲(chǔ)層

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

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

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

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

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

統(tǒng)一元信息庫(kù) Metastore 調(diào)用示意圖

2.3 對(duì)象存儲(chǔ)訪問(wèn)優(yōu)化

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

但對(duì)象存儲(chǔ)也并不是十全十美，引入對(duì)象存儲(chǔ)之后，我們碰到了如下問(wèn)題：

● 訪問(wèn)速度：對(duì)象存儲(chǔ)的總吞吐上限理論上只受帶寬限制，但是單線程訪問(wèn)速度較低，遠(yuǎn)低于磁盤(pán)。

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

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

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

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

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

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

具體流程如下圖所示：

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

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

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

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

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

3.  服務(wù)端獲取到下載的 Part，并計(jì)算查詢(xún)結(jié)果，返回給客戶(hù)端。

對(duì)象存儲(chǔ)優(yōu)化示意圖

2.4 緩存優(yōu)化

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

多級(jí)緩存架構(gòu)

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

● 被動(dòng)緩存：適用于不可預(yù)知的數(shù)據(jù)，在用戶(hù)查詢(xún)時(shí)，臨時(shí)緩存對(duì)應(yīng)的數(shù)據(jù)，以提高后續(xù)查詢(xún)的性能。

● 主動(dòng)緩存：適用于可以預(yù)知會(huì)被頻繁訪問(wèn)的數(shù)據(jù)。集群?jiǎn)?dòng)后，系統(tǒng)會(huì)在后臺(tái)主動(dòng)根據(jù)用戶(hù)設(shè)定的規(guī)則和用戶(hù)的查詢(xún)歷史，智能推算用戶(hù)今天可能會(huì)查詢(xún)的數(shù)據(jù)，并將這些數(shù)據(jù)預(yù)先從對(duì)象存儲(chǔ)緩存到本地磁盤(pán)，用戶(hù)查詢(xún)時(shí)直接從本地讀取，性能與本地磁盤(pán)相當(dāng)。

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

緩存策略示意圖

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

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

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

2.  在集群擴(kuò)縮容過(guò)程中，如何自動(dòng)調(diào)整調(diào)度計(jì)劃，以確保沒(méi)有任務(wù)沖突。

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

分布式任務(wù)調(diào)度架構(gòu)圖

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

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

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

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

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

通過(guò)將數(shù)據(jù)按 Bucket 劃分，我們?cè)谌蝿?wù)調(diào)度過(guò)程中以 Bucket 為單位，靈活調(diào)度 Bucket 和節(jié)點(diǎn)之間的映射關(guān)系，為彈性擴(kuò)縮容提供了基礎(chǔ)。

REDck Bucket 示意

2.7 分布式事務(wù)

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

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

REDck 兩階段提交

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

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

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

3、落地效果

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

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

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

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

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

4、作者信息

白樺

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

龐博

小紅書(shū)數(shù)據(jù)平臺(tái)部 LakeHouse 團(tuán)隊(duì)負(fù)責(zé)人，負(fù)責(zé) OLAP 及數(shù)據(jù)湖方向。

銅須

小紅書(shū)數(shù)據(jù)平臺(tái)部 OLAP 研發(fā)，負(fù)責(zé)小紅書(shū) OLAP 方向的研發(fā)工作，主要包括 REDck 的研發(fā)與落地。