96%企業用上Iceberg后，真正的麻煩才開始

Apache Iceberg 已經成為開放數據湖的默認表格格式。2025年Apache Iceberg生態調查顯示，Spark采用率高達96.4%，Trino為60.7%，DuckDB和Flink的使用量也在持續增長。Ryft 2026年企業研究報告顯示，58%的組織現在將Iceberg用于關鍵業務分析，79%計劃在未來12個月內將剩余數據遷移至Iceberg。

采用率不再是問題。問題是：誰來維護這一切？

Iceberg提供了快照隔離、模式演進、隱藏分區和時間旅行功能。但它不會幫你壓縮文件、過期快照、清理孤兒文件、重寫清單，也不會告訴你800張表中哪一張即將讓你的晨間儀表盤癱瘓。這是你的工作——而在大規模場景下，這是一項會壓垮人的工作。

本文將介紹在生產環境中運行Iceberg數據湖的實際成本：維護操作、故障模式，以及LakeOps——一個面向Apache Iceberg的自主控制平面——如何解決這些問題。

"托管"這個詞在Iceberg領域被過度使用。它指的是數據寫入后保持表健康所需的持續運營工作。Iceberg處理事務正確性——原子提交、快照隔離、樂觀并發控制。但它有意將維護工作留給運營者。格式規范定義了快照、清單和數據文件是什么，但沒有定義何時清理、如何重組文件，或哪些表需要優先關注。

托管式Iceberg數據湖是指這些操作被持續、自動地處理，并對整個系統有全局感知——而非僅針對單張表。

維護工作大致分為六類：文件壓縮、快照過期、孤兒文件清理、清單重寫、元數據壓縮，以及表級健康監控。每一項單獨看都很直接。難點在于為每張表、以正確頻率、按正確順序全部執行，且不出問題。大多數團隊從Airflow中調度的自定義Spark腳本起步。10張表時這能行。200張表橫跨多個目錄和引擎時，腳本本身就成了問題——脆弱、不協調、對操作間的相互影響視而不見。

LakeOps將這六類維護視為一個協調統一的系統。你連接目錄和存儲——通常不到10分鐘，無需安裝代理、無需移動數據、無需更改管道——平臺便會在整個集群范圍內持續管理全部六項操作。

每次Iceberg寫入都會產生新的數據文件。幾秒鐘提交一次的流式管道每小時可生成數千個文件。高基數分區的批處理作業會將數據分散到眾多小文件中。即使設計良好的管道，隨著表演進，也會逐漸積累文件碎片。

后果層層疊加：查詢掃描更多文件、打開更多文件句柄、消耗更多內存和CPU。成本上升，延遲惡化，查詢超時。標準解決方案是壓縮：定期將小組文件重寫成更少、更大的文件，目標大小為256-512 MB。Iceberg原生支持此功能。