雲原生分散式檔案系統JuiceFS開源了

語言: CN / TW / HK

作者注:JuiceFS 的服務端和客戶端完全使用 Golang 編寫,同時為了更精細化的管理記憶體,我們沒有使用 Golang 的記憶體模型,手工控制,避免 GC。後續會寫專門的文章來分享我們在 Golang 多個角度的技術實踐。

我們很激動地宣佈,將經過 4 年持續迭代和累計幾千萬小時線上考驗的 JuiceFS 開源了!

JuiceFS 是什麼

JuiceFS 是為海量資料設計的分散式檔案系統,使用物件儲存來做資料持久化,避免重複造輪子,還能大大降低工程複雜度,讓我們專注解決元資料和訪問協議部分的難題。

JuiceFS 的創新架構更符合雲原生的發展趨勢,我們一開始就以 SaaS 的形式將它提供給公有云的客戶,讓客戶分鐘級就可以獲得 PB 級企業檔案儲存服務。同時,我們也和行業領先的物件儲存廠商一起服務私有云客戶。

為什麼開源

在創業之初,我們認為 SaaS 可以為使用者提供最佳的體驗,同時讓我們更快地迭代產品,決定優先把 SaaS 做好。經過 4 年的持續迭代和積累,JuiceFS 已經在幾十家科技企業的大資料、AI、容器平臺、歸檔、備份等場景中形成最佳實踐, SaaS 使用量也持續快速增長,並且在過去的 2020 年首次實現了盈虧平衡。我們相信找到了可持續發展的模式,有信心保障 JuiceFS 的長期運營。

我們也發現閉源的基礎軟體會限制使用者對它的深度理解,不利於它服務更多的人,依靠 SaaS 產品的收入支撐和開源社群的力量,我們可以讓 JuiceFS 幫助更多的人。

架構再升級

藉助物件儲存的幫助,JuiceFS 已經大大降低了分散式檔案系統的複雜度,元資料管理是它最核心的問題。JuiceFS 的 SaaS 使用的元資料引擎,是專為檔案系統打造的資料庫,我們已經積累了豐富的運維經驗,仍然如履薄冰。如果開源的話,讓社群使用者自己運維仍然會是一個大的挑戰和負擔,一旦運維失誤導致資料丟失,後果非常嚴重。

帶著這個問題,我們將元資料服務改造為支援多引擎的外掛式架構,可以利用已有的開源資料庫實現元資料儲存。這樣可以更靈活地適應不同場景,根據場景的規模、效能和成本需求,選用不同的元資料實現。這是 JuiceFS 的架構再升級,為未來的發展翻開新的篇章。

我們選用 Redis 作為第一個開源儲存引擎,是因為它:

  1. 是全記憶體的,可以滿足元資料的低延時和高 IOPS 要求;

  2. 支援樂觀事務,能夠滿足檔案系統元資料操作的原子性要求;

  3. 有豐富的資料結構,易於實現檔案系統的諸多 API;

  4. 有著非常廣泛的社群和成熟的生態,運維 Redis 不會是一個問題;

  5. 在各個雲上都有託管的服務,在雲上使用會更簡單;



未來,我們還會增加 SQL 資料庫、TiKV 等支援事務的 KV 資料庫支援。

未來發展

最近幾年,資料庫領域發生了一件有趣的事情:當 NoSQL 資料庫在滿足了資料的快速增長後,它在一致性、訪問便捷性和管理能力方面的不足逐漸顯露,把這些複雜性轉嫁到了業務系統和運維上,開始被人詬病。同時, SQL 資料庫也有了長足的進展,已經能夠滿足現在的資料規模需求,經過全面的對比分析後,大家又在迴歸 SQL 資料庫,曾經的 NoSQL 運動也逐漸顯出頹勢。

估計類似的事情也會發生在非結構資料領域。物件儲存在媒體檔案等場景取得了巨大的成功,但當人們以為它就是未來的儲存形態,開始推廣到更大範圍時,它犧牲掉的樹形目錄結構、可修改性、元資料效能、一致性等等,變成了一隻只攔路虎,影響它在其他場景的使用效果。

我們堅信檔案系統是最好的管理非結構化資料的方式,物件儲存只適用於某些簡單場景。分散式檔案系統一直是基礎軟體中難啃的骨頭,JuiceFS 通過對檔案系統中元資料和資料的獨立抽象,大大減低了系統複雜度,使得檔案系統能夠藉助這些年來物件儲存和分散式資料庫的進展,管理超大規模的資料。同時,複雜度的降低可以讓更多的開發者參與進來,未來更多的應用也會建立在檔案系統介面之上。

我們將通過開源社群的相互協作,一方面為各個應用提供更好的儲存支援,也會在底層儲存引擎和物件儲存上加深協作,一起推動檔案儲存的快速發展,打造未來資料生態的堅實底座。

我們 GitHub 見!

https://github.com/juicedata/juicefs

閱讀原文給我們star