1. 首頁 > 生活百科 > >

JuiceFS 在 Elasticsearch/ClickHouse 溫冷數據存儲中的實踐( 五 )

生活百科

再往下是 policies 配置項，這里定義了一個叫做 hot_and_cold 的存儲策略 ， 用戶需要定義一些具體的規則，如 volumes 中按照先熱后冷的優先級排列，數據首先會落到 volumes 里的第一個 hot 盤上，及默認的 ClickHouse 磁盤，一般是本地的 SSD 。
volumes 中的 max_data_part_size_bytes 配置表示當某一個 part 的大小超過設定的大小之后，就會觸發存儲策略的執行，對應的 part 會下沉到下一個 volume ， 也就是 cold volume 。在上面的示例中，cold volume 就是 JuiceFS 。
最下面的 move_factor  配置代表 ClickHouse 會根據當前磁盤的剩余空間比例來觸發存儲策略的執行 。
CREATE TABLE test (  d DateTime,  ...) ENGINE = MergeTree...TTL d + INTERVAL 1 DAY TO DISK 'jfs'SETTINGS storage_policy = 'hot_and_cold'；如上面的代碼所示 ， 有了存儲策略之后，在創建表或者修改這個表的 schema 時，可以在 SETTINGS 中設置 storage_policy  為前面定義的 hot_and_cold 存儲策略 。上述代碼中倒數第二行的 TTL 即為上文提過的基于時間的分層規則 。在這個示例中，我們指定的表中某一個叫做 d 的列，它的類型是 DateTime，結合 INTERVAL 1 DAY 就表示當新的數據寫進來超過一天之后，這些數據就會轉移到 JuiceFS 上 。
06- 展望第一，副本共享 。無論是 ES 還是 ClickHouse，他們都是由多副本來保證數據的可用性和可靠性 。JuiceFS 本質上是一個共享文件系統，任何一份數據寫入到 JuiceFS 之后 ， 不再需要維護多個副本 。比如，用戶有兩個 ClickHouse 節點 ， 都有某一個表的或者某一個 part 的副本，這兩個節點都下沉到了 JuiceFS，它可能會寫兩次一樣的數據 。未來，我們是否可以做到讓上層引擎能夠感知到下層使用的是一個共享存儲，當數據下沉的時候去降低副本數，這樣在不同節點之間是可以做副本共享的 。從應用層來說，用戶查看這個表 ，  part 數還是多副本，但實際在底層的存儲上只保了一個副本，因為本質上數據是可以共享的 。
第二點，故障恢復 。當數據已經下沉到一個遠端的共享存儲之后，如果 ES 或 ClickHousle 節點宕機故障之后，怎么快速地做故障恢復？除了熱數據以外的大部分數據其實都已經轉移到了一個遠端的共享存儲上，這個時候如果要去恢復或創建一個新的節點時 ， 成本會比傳統的基于本地盤的故障恢復方式輕量很多，這在 ES 或者 ClickHouse 場景上是值得探索的 。
第三點，存算分離 。不管 ES 也好，還是 ClickHouse ， 整個社區也都在嘗試或者探索在云原生的大環境下，怎么去讓傳統的這些基于本地盤的存儲系統變成一個真正的存算分離系統 。但存算分離不是僅僅簡單地把數據和計算分離就好了 ， 同時要滿足上層各種復雜的需求，比如對于查詢性能的需求、對于寫入性能的需求、對各種維度調優的需求，在存量分離整個大的方向上還是有許多值得探索的技術難點 。
第四點，其他上層應用組件數據分層探索 。除了ES 和 ClickHouse 這兩個場景，我們最近也有在做一些嘗試，把 Apache Pulsar 中的溫冷數據下沉到 JuiceFS 中，用到的一些策略和方案與本文中提到的是類似的，只不過在 Apache Pulsar 中，它需要下沉的數據類型或者數據格式不太一樣 。有了進一步成功實踐后，會分享出來 。
相關閱讀：

  • JuiceFS 在攜程海量冷數據場景下的實踐
  • Shopee x JuiceFS: ClickHouse 冷熱數據分離存儲架構與實踐

推薦閱讀