分享不易，關注轉發，随筆感悟，職場心得。

在大數據企業中，需要一個平台，使我們的業務用戶能夠通過對龐大的數據集執行交互式分析來做出相對清晰的數據驅動決策。這個場景需要一個可以處理大量數據的 OLAP 系統。為了做到這一點，可以利用 ClickHouse（關于ClickHouse之前有發文分析，我們已經投入生産使用了兩年，效果客觀，結果滿意，未來持續跟進），它可以在幾秒鐘内對數十億行數據運行分析查詢。

但是，管理和維護一個存儲和處理 TB 級數據的數據庫集群可能是一項艱巨的任務。通過這篇文章，将回顧我們平台的架構來分享一些對設置 ClickHouse 分布式集群有用的最佳實踐。我們的很多B端客戶也是基于我們的DaaS，基于我們的集群，構建儀表闆，使他們能夠做出更明智的業務決策。

該平台的架構設計需要保持高度可用且易于擴展，還需要屏蔽底層基礎設施的細節，這樣我們能夠對基礎架構進行更改，而不會造成任何停機或對用戶産生影響。

架構概述：

以下是對關鍵組件以及它們如何與系統其餘部分交互的說明：

關于負載局衡器的落地可以場景有多種技術方案， 負載均衡器是我們的客戶端和平台之間的接口。負載均衡器将流量定向到 Chproxy 服務器，該服務器進一步與 ClickHouse 集群通信。

負載均衡器會配置健康檢查，通過LB 不斷輪詢 Chproxy 服務器将流量定向到健康服務器，并在主服務器不可用的情況下切換到故障轉移服務器。

Chproxy 是為 ClickHouse 數據庫開發的開源第 3 方代理層。

Chproxy 為我們提供以下好處：

• 用戶特定路由：由于 ClickHouse 集群在許多消費者之間共享，因此 Chproxy 使我們能夠将用戶請求路由到處理請求的數據節點。針對物理集群中存在的特定消費者的數據，可以做指向性的路由策略。
• 緩存：我們已将特定用戶的查詢，基于Chproxy 配置了緩存，特别是那些不經常刷新數據的用戶。這樣的操作是為了讓底層 ClickHouse 集群免于重複執行複雜的查詢，直接從緩存中讀取數據，也使用戶能夠更快地獲得結果，。
• Chproxy 充當客戶端應用程序和 ClickHouse 集群之間的抽象層。它使我們能夠在不影響消費者的情況下對 ClickHouse 基礎架構進行更改。

Chproxy 進程在我們的服務器上會配置為自定義 Linux 服務，在出現任何故障時會自動啟動。

ClickHouse 集群是平台的核心和靈魂，是一個共享集群，我們的許多客戶會在不同的場景下應用它。

• 可擴展性：

此類系統處理 TB 級數據非常常見。在這種情況下，在多個節點之間拆分數據，俗稱為Sharding。分片可以水平擴展集群，并結合多台服務器的功能來共同處理資源密集型查詢。

• 高可用性：

為了确保高可用性，可創建每個分片的跨 DC 副本。這樣可以保證服務器或整個 DC 的故障不會導緻平台崩潰。異步複制是使用 ClickHouse 平台的 Replicated 引擎實現的。

• 單獨的讀寫副本：

在我們平台的初始階段，我們曾經在服務器節點之間進行分片循環複制的方法。ClickHouse 集群中的每個節點都攜帶一個分片的原始數據以及另一個分片的副本。但是，采用這種方法會對讀取查詢産生不可預知的影響。

為了解決這個問題，我們決定在集群中分離服務于讀取和寫入流量的副本。執行複雜寫入操作的 ETL 作業的所有流量在寫入集群中的副本之間共享。寫入副本的數據由 ClickHouse 異步複制到讀取副本。使用 ClickHouse 中的first_or_random負載平衡，讀取查詢由讀取集群中的副本處理，但是，如果一個分片的讀取副本不可用，它将由寫入集群中的副本處理。

總的來說，這種方法提供了以下好處：

• 讀取變得更加可預測。由于正在運行的 ETL 作業而必須執行的所有繁重處理都在寫入節點上執行。
• 這種架構更容易擴展。如果讀取流量急劇增加，可以通過在讀取集群中添加更多副本來橫向擴展系統，并在它們之間共享流量。
• 隻讀副本可以利用具有更高 IOPS（本地 SSD）的更快磁盤，這可以進一步提高讀取查詢的性能。

ClickHouse 使用 Apache ZooKeeper 執行數據複制。ZooKeeper 存儲副本的元數據，用于确保所有副本同步。

ZooKeeper 集成由運行在不同機器上的三個 ZooKeeper 服務器創建，确保 ZooKeeper 服務在任何一個 ZooKeeper 服務器崩潰的情況下可用。

這種平台架構設計使客戶或者業務用戶能夠在幾秒鐘内根據海量數據做數字決策。同時兼顧了高度可用且易于擴展。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!