在當今數據驅動的世界中，有效管理大量數據對於各種規模的組織至關重要。隨著資料湖和物件儲存系統的普及，對強大的資料版本控制和治理解決方案的需求也在增長。
資料保留和儲存優化已成為一項日益複雜的任務，在處理版本化資料時更是如此。這些版本可以快速累積，導致資料冗餘和不必要的儲存消耗。
此外，遵守監管要求例如 要
求組織以符合隱私權和資料保留政策和準則的方式處理資料。 LakeFS 旨在允許在對儲存進行重複資料刪除的同時進行版本控制，因此使用它是提供儲存優化的資料湖的自然的第一步。
此外，lakeFS 的突出功能之一是垃圾收集器，它可以解決儲存優化和法規遵循問題。
LakeFS 的垃圾收集器 (GC) 在
其生命週期中經歷了多次設計迭代，最近又進行了一次重大檢修，整合了已提交和未提交資料垃圾收集的流程。
在本文中，我們將討論目前的 GC 功能、我們如何大規模處理 GC，並解釋自管理 GC 和我們的雲端 GC 解決方案之間的主要差異。
LakeFS 中的垃圾收集
垃圾收集 (GC) 對於大數據 台灣 WhatsApp 號碼數據 湖來說可能很困難：它可能既消耗時間又消耗資源，而且如果操作不當，實際上無法擴展
當版本化資料引入方程式時，這可能是一項更具挑戰性的任務。
為了因應這些挑戰，lakeFS的GC採用了以下機制：
提交圖表和引用跟踪- 跟踪存儲庫和分支中的數據引用，垃圾收集器檢測不再引用的數據，並根據保留策略將其標記為刪除。這確保了資料版本只要綁定到現有分支就會持續存在。這種保護措施可以防止無意中刪除可能仍在使用的數據，從而保持下游流程中的資料完整性和連續性。
細粒度資料保留策略– GC 允許實施
細粒度資料保留策略。這些策略根據業務規則、合規性要求和使用模式規定資料版本的保留和刪除。此類策略使組織能夠在資料 最實惠的小型企業最佳打標機 可用性和儲存成本效率之間取得平衡。
標記和清除功能– GC 使用標記和清除策略，讓使用者可以更好地控制流程、分割工作負載並啟用審核。
LakeFS GC 區分兩種類型的資料：
提交的數據－提交到lakeFS分支的數據
對於提交的數據，是否刪除數據的決定由可以在儲存庫和分支範圍中定義的保留策略決定。
未提交的資料－已上傳到lakeFS但未提交的資料。
對於未提交的數據，GC會列出所有已上傳至儲存庫、未提交且不再被任何分支的暫存區引用的數據。發生這種情況的原因如下：
物件被上傳並隨後 清潔新聞 被刪除，而之前沒有提交它。
在分支上執行重置，導致其刪除部分或全部暫存資料。
包含未提交資料的分支已被刪除
大規模垃圾收集 (GC)
從本質上講，lakeFS 的 GC 是一個Apache Spark應用程序，它作為作業在 LakeFS 儲存庫層級上運行。它利用 Spark 的分區功能以最佳方式掃描物件儲存和 LakeFS 元資料的方式劃分工作負載。為了支援和利用分區功能，我們修改了lakeFS，將底層儲存中的資料分區為前綴。請點擊此連結更深入地了解該主題。
與大多數 Spark 應用程式一樣，需要在成本和效率之間進行權衡。根據經驗，分配更多資源意味著更
快執行作業，但這也意味著更高的成本
平衡成本和效率是一門藝術，它需要掌握 Spark 生態系統以及對上下文的深入理解（在我們的例子中，GC、lakeFS 的內部工作原理，甚至是我們正在運行的特定存儲庫的屬性） GC 打開）。
LakeFS 的 GC 在生產中經過了實際測試，並已在包含超過 6000 萬個物件的資料湖上成功執行。
在下面的範例中，您可以看到垃圾收集器（標記 + 清除）成功執行，在包含約 60M 物件的儲存庫上執行。