今天的部落格來自 JuiceFS 雲服務使用者 Jerry，他們透過使用 JuiceFS snapshot 功能，創新性地實現了資料的版本控制。Jerry，是一家位於北美的科技公司，利用人工智慧和機器學習技術，簡化使用者購買汽車和家庭保險的比較及購買流程。
在軟體開發領域，嚴格的測試和受控釋出已經成為幾十年來的標準做法。但如果我們能將這些原則應用到資料庫和資料倉儲中會怎樣？想象一下，能夠為資料基礎設施定義一套帶有測試用例的標準，自動應用於每個新的"釋出"，以確保客戶始終看到準確和一致的資料。這將會極大改善資料質量。
01 挑戰：為什麼端到端測試在資料管理中並不常見
這個想法看似直觀，但端到端測試在資料管理中並不常見，因為它需要資料庫或資料倉儲具備克隆或快照的功能，而大多數資料系統都不提供這一功能。
現代資料倉儲本質上是隨時間變化的有組織的可變儲存，我們透過資料管道對其進行操作。資料通常在生成後立即對最終客戶可見，沒有"釋出"的概念。當沒有這個釋出概念，對資料倉儲進行端到端測試就沒有多大意義。因為無法確保測試所看到的內容就是客戶將看到的內容，這些資料在不斷因為資料管線的修改而變化。
所以問題的核心，就是要在實現一種資料釋出的機制，這種機制能夠把某一個時刻資料倉儲的狀態提取成一個“快照“，並且控制這個”快照“對終端使用者的可見性。這樣，這個快照就成為一個”釋出工件“，我們控制它什麼條件、什麼時間最終可以讓使用者看見。
02 現有方法及其侷限性
一些團隊在資料倉儲之上開發了版本控制系統。他們不直接修改終端使用者查詢的表，而是為變更建立新版本的表，並使用原子交換操作來"釋出"表。雖然這種方法在某種程度上有效，但它帶來了重大挑戰：
- 高效實施"建立和交換"模式並不容易；
- 確保涉及多個表的一致性（例如，驗證訂單表中的每一行在價格表中都有對應行）需要將多個表的變更"打包"成一個"事務"，這也具有挑戰性，不僅僅實現這種模式是困難的，這種模式也要求資料管線被相對嚴格的編排。
03 解決方案：由 JuiceFS 支援的 ClickHouse 資料庫克隆
我們開發了一個系統，利用 JuiceFS snapshot 功能將 ClickHouse 資料庫"克隆"為副本。這種方法在我們早前的文章 "低成本讀寫分離：Jerry構建主從ClickHouse架構" 中有詳細介紹。
它的工作原理如下：
- 我們在 JuiceFS 上執行 ClickHouse 資料庫，JuiceFS 是一個由物件儲存服務（OSS）支援的 POSIX 相容共享檔案系統。
- JuiceFS 提供了一個實現 git 分支語義的"快照"功能。
- 使用簡單的命令如
juicefs snapshot src_dir des_dir，我們可以建立 src_dir 在那一刻的克隆。
這種方法使我們能夠輕鬆地從執行中的例項複製/克隆 ClickHouse 例項，建立一個可以被視為"釋出工件"的凍結快照。
04 使用資料庫克隆實施端到端測試
有了這種機制，我們可以對 ClickHouse 副本執行端到端測試，並根據測試結果控制其可見性。
現在可以使用常見的單元測試框架（我們使用 pytest ）開發、組織和迭代資料端到端測試。這種方法使我們能夠將資料可用性和可靠性的基礎設施和業務標準編碼成資料測試。
一個典型的測試是表大小測試，它有助於防止由意外或臨時表損壞導致的資料問題。還可以定義業務標準，以保護資料包告和分析免受資料管道中可能導致資料錯誤的意外更改的影響。例如，使用者可以在一列或一組列上強制唯一性以避免重複——這在計算營銷成本時是一個關鍵因素。
在 Jerry，這種架構在近幾個季度中發揮了至關重要的作用，有效防止了幾乎所有可能暴露給最終客戶的 P0 級資料問題。
這種方法不僅限於 ClickHouse。如果在 JuiceFS 之上執行任何型別的資料湖或湖倉，採納本文描述的釋出機制可能會更容易。
05 結論
透過將現代軟體開發實踐引入資料管理世界，我們可以顯著提高資料質量、可靠性和一致性。資料庫克隆和端到端測試的結合為確保客戶始終看到正確的資料提供了強大的工具集，就像他們期望在經過充分測試的軟體釋出中看到正確的功能一樣。
下圖展示了我們的資料庫釋出和端到端測試過程的工作流程。
這個架構的誕生標誌著我們在縮小軟體開發與資料管理之間的差距方面邁出了重要一步，為資料領域的創新和質量保障開闢了全新的可能性。
希望這篇內容能夠對你有一些幫助，如果有其他疑問歡迎加入 JuiceFS 社群與大家共同交流。