lakeFS مقابل DVC: التحكم في الإصدار يريد أن يكون نظام ملفات
القصة في التحكم في إصدار البيانات هي أن الجميع يومئون برأسهم وكأنه Git لكل شيء - حتى تحاول استخدامه بالفعل لبيتابايت عبر فريق وتدرك أن Git كان، في الواقع، Git للتعليمات البرمجية. يقولون: "فقط تعامل مع حاوية S3 الخاصة بك كمستودع"، وهو أشبه بإخبار سيمفونية باستخدام آلة الكازو لأنها أداة نفخية من الناحية الفنية.
هذه قصة عن نظرتين للعالم تشتركان في شعار: lakeFS مقابل DVC. كلاهما يعدان بالعقلانية حيث تضيع البيانات والنماذج والتجارب عادةً. لكنهم يهاجمون المشكلة من اتجاهين متعاكسين. DVC هي مجموعة أدوات مطور أولاً ومجاورة لـ Git تركب بندقية مع المستودع الخاص بك. lakeFS عبارة عن طبقة أصلية للتخزين تحول متجر الكائنات الخاص بك إلى نظام ملفات ذي إصدارات مع فروع وعمليات إيداع ودمج. نفس اللحن، تواقيع مفاتيح مختلفة.
إذا كنت هنا للحصول على حكم: فربما تعرف بالفعل المعسكر الذي تنتمي إليه. إذا كان ألمك اليومي هو نقل الملفات الكبيرة ونقاط تفتيش النموذج مع إمكانية إعادة الإنتاج، فسوف تشعر أن DVC وكأنه سلك تمديد ذكي للغاية. إذا كان ألمك هو حوكمة البيانات متعددة الفرق والعزل والقراءات القابلة لإعادة الإنتاج عبر بحيرة بيانات، فإن lakeFS يشبه تثبيت قواطع الدائرة في المنزل الفعلي.
نعم، يمكنك استخدام كليهما. هذا ليس تهربًا. إنه اعتراف بأن عمل البيانات عبارة عن وظائف عديدة ترتدي نفس القميص.
تخطيط الأرض: ما الذي يفعله DVC و lakeFS فعليًا
- DVC (التحكم في إصدار البيانات): يعيش بجوار Git، وليس بداخله. يمكنك إصدار مؤشرات (ملفات تعريفية صغيرة) في Git وتخزين القطع الأثرية الكبيرة الفعلية - مجموعات البيانات والنماذج والصور - في جهاز تحكم عن بعد مثل S3 أو GCS أو Azure أو SSH أو ذاكرة تخزين مؤقت محلية. يمكنك الحصول على خطوط أنابيب تعتمد على CLI، و
dvc.lock لإمكانية إعادة الإنتاج، وتتبع التجارب، و dvc push/pull للمزامنة.
- lakeFS: يقع أمام متجر الكائنات الخاص بك (S3، GCS، Azure Blob) ويجعل الفروع وعمليات الإيداع ميزة أساسية في مساحة اسم التخزين. ترى القراءات والكتابات فروعًا معزولة. يمكنك إنشاء فرع من "الإنتاج"، وتشغيل التحويلات، والدمج مرة أخرى - دون نسخ تيرابايت. إنها دلالات Git-ish لبحيرة البيانات الخاصة بك.
بمعنى آخر: يقوم DVC بتطعيم إدارة البيانات في سير عمل المطورين؛ يقوم lakeFS بنقش دلالات سير العمل في طبقة البيانات.
الفرق الأساسي (ولماذا هو مهم)
يعامل DVC البيانات الكبيرة كامتداد لقاعدة التعليمات البرمجية الخاصة بك. يبدأ كل شيء بمستودع Git: يمكنك إيداع ملفات *.dvc، وقفل التبعيات، وتنظيم خطوط الأنابيب. إنه أمر رائع لتجارب ML حيث يوجد الأصل بجانب التعليمات البرمجية التي أنشأته.
يعكس lakeFS الأمر: بحيرة البيانات هي مصدر الحقيقة. الفروع ليست استعارات - إنها مساحات أسماء فوق نفس الكائنات الأساسية. وهذا يعني أنه يمكنك:
- تشغيل فرع
feature/try-new-schema لمجموعة بيانات بحجم 200 تيرابايت في ثوانٍ.
- تشغيل Spark/Presto/Trino على هذا الفرع كما لو كان حقيقيًا، لأنه كذلك بالفعل.
- الدمج (أو الإلغاء) دون تبديل البحيرة بأكملها.
لا يمكنك تزييف ذلك باستخدام خطافات Git الذكية.
lakeFS مقابل DVC: حالات الاستخدام بدون اللمعان التسويقي
متى يفوز DVC
- الفرق التي تركز على النموذج: لديك تعليمات برمجية ولقطات بيانات وتجارب يجب أن تكون قابلة لإعادة الإنتاج وقابلة للمشاركة. يتألق تتبع التجارب في DVC وخطوط أنابيب
dvc repro.
- نظام المستودع الواحد: تعيش مؤسستك في Git. أنت تريد "البيانات كتعليمات برمجية" دون اختراع تجريد للتخزين. DVC مألوف،
git add data.dvc، تم.
- الميزانية والبساطة: لا توجد طبقة أساسية لتشغيلها. يمكن أن يعمل DVC مع حاوية S3 عادية وسياسة أذونات. CLI مباشر. المحلي أولاً هو ميزة.
متى يفوز lakeFS
- عزل الفريق على نطاق واسع: تحتاج إلى فرق متعددة لتشغيل عمليات الكتابة/القراءة بأمان على نفس البحيرة دون تجاوز بعضها البعض. العزل القائم على الفروع هو الهدف.
- الإدارة والتدقيق: سجل الالتزام واللقطات القابلة لإعادة الإنتاج وخطافات السياسة على حدود التخزين. يمكنك فرض القواعد حيثما يهم.
- محركات كبيرة، جداول كبيرة: Spark و Hive و Presto و Trino وجداول Snowflake الخارجية - الأدوات التي تتحدث إلى مخازن الكائنات. يتكامل lakeFS على مستوى URL؛ لا تحتاج مجموعة الحوسبة الخاصة بك إلى تعلم حيل جديدة.
متى تستخدم كليهما (وتشعر بالذكاء)
- DVC لـ القطع الأثرية النموذجية وخطوط الأنابيب المرتبطة بالمستودع؛ lakeFS لـ مجموعات البيانات الأولية والمنظمة في البحيرة. تتبع وثبت إصدارات مجموعة البيانات في DVC التي تشير إلى تجزئة إيداع lakeFS. تعيش التعليمات البرمجية في Git؛ تعيش دلالات البيانات في البحيرة. لا يتعين على أحد أن يتظاهر بأن الطبقة الأخرى يمكنها القيام بكلتا المهمتين بشكل جيد.
lakeFS مقابل DVC: المقايضات العملية
الإعداد والعمليات
- DVC: تثبيت CLI، وتكوين أجهزة التحكم عن بعد. ستدير حجم ذاكرة التخزين المؤقت وتكاليف التخزين والوصول. يظل Git قاعدتك الرئيسية. الحد الأدنى من الاحتكاك.
- lakeFS: أنت تقوم بتشغيل خدمة. يوجد خادم وبيانات تعريف و GC وسياسات التفرع وبيانات الاعتماد. ليس صعبًا، لكنه بنية تحتية. المكافأة هي عزل حقيقي وعمليات إيداع ذرية في بحيرة البيانات.
الأداء والمقياس
- DVC: يمكن أن يكون دفع/سحب القطع الأثرية الكبيرة سريعًا باستخدام ذاكرة التخزين المؤقت المحلية والروابط الثابتة، ولكن النموذج يعتمد بشكل أساسي على العميل. لن تقوم بتفريغ بيتابايت في أجزاء من الثانية؛ سوف تشير إليه وتحرك القطع حسب الحاجة.
- lakeFS: التفرع رخيص من حيث بيانات التعريف (نسخ عند الكتابة). القراءات "سرعة أصلية" لأنها مجرد قراءات لمتجر الكائنات. تتكبد الكتابات غير مباشرة ولكن ليس عقوبة "نسخ العالم". توجد تعارضات في الدمج، لكنها على مستوى الكائن/المفتاح، وليس أسطر التعليمات البرمجية.
إمكانية إعادة الإنتاج
- DVC:
dvc.lock الخاص بك يربط التعليمات البرمجية والمعلمات وتجزئات القطع الأثرية للبيانات معًا. يجب أن يؤدي إعادة تشغيل تجربة من الشهر الماضي إلى إنتاج نفس البتات. هذه هي إمكانية إعادة الإنتاج على حدود التعليمات البرمجية.
- lakeFS: إمكانية إعادة الإنتاج على حدود البيانات: "اقرأ الجدول X اعتبارًا من الإيداع Y." يمكنك السفر عبر الزمن إلى سطح الإدخال بأكمله للتحليلات أو عمليات الملء الخلفي.
نموذج التعاون
- DVC: تعاون يركز على المطورين - العلاقات العامة والمراجعات والتجارب. إنه أمر رائع لحلقة ML: البيانات → التدريب → التقييم → الشحن.
- lakeFS: تعاون يركز على فريق البيانات - فروع للاستيعاب والتحويل والتحقق من الصحة. إنه أمر رائع لحلقة التحليلات: الاستيعاب → النموذج (كما في dbt/ETL) → النشر → الخدمة.
عقود البيانات بلغة إنجليزية بسيطة
يقول الناس "عقود البيانات" ويبدأون في التلويح حول لقطات شاشة تسجيل المخطط. إليك النسخة العادية:
- مع DVC، يكون العقد ضمنيًا في خط الأنابيب الخاص بك: الملفات التي تعلن عنها كتابعيات تشكل العقد. قم بتغييرها، وسيعرف خط الأنابيب الخاص بك.
- مع lakeFS، يمكن فرض العقد عند الدمج: يمكن لخطافات ما قبل الدمج تشغيل عمليات التحقق من الصحة (فحوصات المخطط، وعدد الصفوف، وعتبات القيم الخالية) ومنع البيانات السيئة من الوصول إلى الفرع
الرئيسي. إنه البالغ في الغرفة.
تجربة المطور (DX): حيث يلتقي المطاط بالطريق
- بيئة عمل CLI: CLI الخاص بـ DVC متحيز ولكنه قابل للتنبؤ:
dvc add، dvc push، dvc exp run. يفكر CLI (وواجهة المستخدم) الخاصة بـ lakeFS في الفروع/عمليات الإيداع على مستوى مجموعة البيانات: lakefs branch create، commit، merge.
- النموذج الذهني: يطلب DVC من المطورين التعامل مع البيانات مثل الثنائيات الخاصة بجهات خارجية مع التجزئات. يطلب lakeFS من مهندسي البيانات التعامل مع البحيرة مثل مستودع به طبقات عزل.
- الحمل المعرفي: يضيف DVC طقوسًا لكل مستودع؛ يضيف lakeFS البنية التحتية والسياسات. اختر سمكك بناءً على المكان الذي يعيش فيه فريقك بالفعل - IDEs أو منصات البيانات.
التكلفة: الوقت والمال وصداع السحابة
- التخزين: يستخدم كلاهما مخازن الكائنات بكفاءة. يمكن لـ DVC تكرار القطع الأثرية إذا كنت مهملاً بشأن ذاكرة التخزين المؤقت؛ يعتمد lakeFS على بيانات التعريف للنسخ عند الكتابة، وهي رخيصة حتى تقوم بالتدفق.
- الخروج والحركة: يمكن أن يؤدي الدفع/السحب في DVC إلى إنشاء المزيد من تقلبات الكائنات. قراءات lakeFS هي في الغالب تمرير مباشر. إذا كانت تكاليف الخروج تبقيك مستيقظًا في الليل، فإن نموذج "الفرع بدون نسخ" الخاص بـ lakeFS صديق.
- النفقات العامة للعمليات: تكلفة DVC هي في الغالب وقت المطور. تكلفة lakeFS هي صيانة الخدمة - النسخ الاحتياطية والترقيات والسياسات.
الحواف الحادة (لا أحد يحب الحديث عن هذه)
- تعارضات دمج DVC ليست سحرية: أنت لا تقوم بدمج صفوف CSV. أنت تقوم بتسوية الكتل التي تفوز. لعمليات الدمج الدقيقة، ستظل بحاجة إلى معالجة البيانات الفعلية.
- دلالات دمج lakeFS ليست SQL: يمكنك تفريع ودمج مسارات S3، ولكن تسوية تغييرات الجدول الدلالية (إعادة ترتيب الأقسام، عمليات التحديث) هي وظيفتك، وليست وظيفة lakeFS. فكر في نظام الملفات، وليس قاعدة البيانات.
- التحكم في الوصول مختلف: يرث DVC نموذج Git الاجتماعي (العلاقات العامة والمراجعات). يتكامل lakeFS مع IAM وخطافات السياسة. إذا قامت مؤسستك بالفعل بمركزية IAM للبيانات، فإن lakeFS يبدو طبيعيًا؛ إذا كنت تعيش في GitHub، فإن DVC يبدو صحيحًا.
عمليات التكامل: المحركات والمنظمون والعالم الحقيقي
- DVC: يعمل بشكل جيد مع GitHub/GitLab CI و Makefiles و Airflow والتطوير المحلي. لتجارب ML، يعد تتبع التجارب في DVC وإدارة القطع الأثرية هو الجاذبية.
- lakeFS: يعمل بشكل جيد مع Spark و Hive و Trino و Presto و dbt (عبر الجداول الخارجية) و Airflow وأي محرك يقرأ
s3a://repo/branch/path. الحيلة هي أن الحساب الخاص بك يتحدث نفس لغة التخزين.
الأمان والامتثال بدون الكلمات الطنانة
- DVC: يعتمد الأمان على التخزين السحابي الخاص بك وأذونات Git الخاصة بك. التدقيق على مستوى خط الأنابيب - ما الذي أنتج ماذا ومتى.
- lakeFS: كل عملية إيداع هي نقطة تفتيش للتدقيق. يمكن للخطافات فحص البيانات قبل الدمج. إذا كنت تهتم بـ "ما الذي تغير ومتى" على غرار GDPR، فإن lakeFS هو الخيار الأفضل.
مواجهة رأس برأس بلغة إنجليزية بسيطة
- الكلمة الرئيسية الأساسية - "lakeFS مقابل DVC" ليست مجرد مقارنة؛ إنها مفترق طرق في الفلسفة. DVC هو Git مع مزايا للملفات الكبيرة والتجارب. lakeFS هي دلالات تشبه Git حيث توجد بياناتك فعليًا.
- إذا كان يومك في الغالب تعليمات برمجية تلامس بيانات، فستكون أكثر سعادة مع DVC.
- إذا كان يومك في الغالب بيانات تلتقي أحيانًا بـ تعليمات برمجية، فمن المحتمل أن تختار lakeFS.
- إذا كان يومك كلاهما، فتهانينا: أنت طبيعي. استخدم DVC للحلقة المواجهة للتعليمات البرمجية و lakeFS للحلقة المواجهة للبحيرة. كلمة "كلاهما" ليست مترددة - إنها دقيقة.
ملاحظة حول ضجيج الأدوات (وأين يتناسب Sider.AI)
الأدوات مثيرة للاهتمام فقط عندما توفر الوقت أو تمنع الفوضى. كل شيء آخر هو عرض توضيحي. Sider.AI يساعد بالفعل هنا - ليس بالتظاهر بأنه البحيرة الخاصة بك، ولكن من خلال القيام بالعمل غير اللامع: مساعدتك على التفكير في خطوط الأنابيب الخاصة بك، وإنشاء فحوصات الحماية، والحفاظ على صدق المستندات والاختلافات الخاصة بك. إذا كنت ستربط DVC و lakeFS معًا، فإن Sider.AI هو الصديق الحكيم الذي يقول، "ضع علامة على القواطع الخاصة بك"، ثم اطبع الملصقات. سيناريوهات عملية: lakeFS مقابل DVC في البرية
السيناريو 1: عزل الميزات لـ ETL
- أنت تحتفظ ببحيرة برونزية/فضية/ذهبية. تريد اختبار مخطط جديد لاستيعاب تدفق النقرات دون كسر لوحات المعلومات النهائية. باستخدام lakeFS، قم بتفريغ
etl/schema-v2 من silver، وقم بتشغيل مهامك، والتحقق من الصحة في العزلة، والدمج بعد اجتياز الفحوصات. لا توجد حاويات ظل، ولا نسخ ليلية.
السيناريو 2: عمليات تشغيل تدريب قابلة لإعادة الإنتاج
- أنت تدرب نماذج أسبوعية. يثبت DVC لقطة مجموعة البيانات الدقيقة (
data.dvc تشير إلى إيداع lakeFS أو إصدار S3)، والمعلمات، والتعليمات البرمجية. dvc repro تدور التشغيل. النموذج والمقاييس والمخططات هي قطع أثرية يمكنك دفعها ومشاركتها. يحب المدققون هذا. وكذلك أنت في المستقبل.
السيناريو 3: إصلاح نشر سيئ
- ينشر شخص ما مجموعة Parquet مشوهة إلى
main. باستخدام lakeFS، يمكنك التراجع إلى آخر إيداع أو فرع جيد، وتصحيحه، ودمجه. باستخدام DVC، تقوم بإصلاحه في خط الأنابيب وإعادة دفع القطع الأثرية. كلاهما يعملان؛ lakeFS أفضل عندما يعني "النشر" "البحيرة التي يقرأها الجميع".
الترحيل والتعايش بدون دموع
- ابدأ بـ تسمية الحقائق الخاصة بك: ما هي مجموعات البيانات التي تمثل نظام التسجيل؟ ما هي المجموعات الزائلة؟ ضع نظام التسجيل في lakeFS. ضع القطع الأثرية التجريبية في DVC.
- تكامل رقيق: قم بتخزين معرفات إيداع lakeFS في معلمات DVC أو بيانات التعريف. تعامل معها كإصدارات غير قابلة للتغيير من مجموعة البيانات.
- لا تقم بغلي البحيرة: اعتمد lakeFS حيث يوفر لك العزل أموالًا حقيقية أو عطلات نهاية الأسبوع. اعتمد DVC حيث توفر لك إمكانية إعادة الإنتاج عمليات إعادة التشغيل.
الجدل: ليس إما/أو، بل حيث توجد الحقيقة
تريد فرق البرامج أداة واحدة تحكمها جميعًا. هذا هو السؤال الخطأ. السؤال الصحيح: أين توجد الحقيقة؟
- إذا كانت الحقيقة في المستودع - التعليمات البرمجية والتكوينات والملفات المحددة التي تدربت عليها - فإن DVC هو الامتداد الطبيعي لـ Git.
- إذا كانت الحقيقة في البحيرة - الجداول والأقسام ومفاتيح الكائنات التي تشغل شركتك - فإن lakeFS يمنحك العقلانية في وقت الالتزام.
كلاهما شكل من أشكال التحكم في الإصدار. واحد فقط يعيش فعليًا حيث توجد البيانات.
lakeFS مقابل DVC: إجابات سريعة للأسئلة التي يطرحها الأشخاص بالفعل
- "هل يمكن لـ DVC استبدال بحيرة البيانات الخاصة بي؟" لا. يمكنه تنظيم القطع الأثرية الخاصة بك وجعل التجارب عقلانية. لن يجعل S3 يتصرف مثل متجر معاملات.
- "هل يمكن لـ lakeFS استبدال أداة تعقب تجارب ML الخاصة بي؟" أيضًا لا. يمكنه إصدار إدخال/إخراج التجارب، لكنه لا يهتم بمنحنيات ROC الخاصة بك.
- "أليس هذا مجرد Git LFS؟" هذا مثل القول بأن الدراجة هي مجرد سيارة بها معدن أقل. DVC مجاور لـ Git ولكنه يفهم خطوط أنابيب البيانات. يمنحك lakeFS دلالات Git-ish دون سحب Git إلى بيتابايت.
كلمة موجزة عن التعقيد (تدفع في مكان ما)
كل تجريد هو فاتورة مستحقة لاحقًا. فاتورة DVC هي طقوس المطورين والتعامل العرضي مع القطع الأثرية. فاتورة lakeFS هي تشغيل خدمة وتعلم دلالات دمج جديدة لمتاجر الكائنات. إذا بدت الأداة مجانية، فإنها تفرض رسومًا على انتباهك.
اللقطة الوداعية
"lakeFS مقابل DVC" تبدو وكأنها مواجهة. إنه أشبه بموسيقيين لا يعزفون على نفس الآلة. لا تطلب من عازف الطبول حمل اللحن، ولا تطلب من الكمان الحفاظ على الإيقاع لفرقة موسيقية. استخدم DVC حيث تمتلك التعليمات البرمجية الحلقة. استخدم lakeFS حيث تمتلك البيانات الغرفة. وإذا كنت تعيش في كلا العالمين، فهذا جيد: فهذا يعني أنك تولي اهتمامًا.
لأن النقطة الحقيقية للتحكم في الإصدار - سواء كانت تلتف حول Git أو تلتف حول S3 - ليست تجزئة الالتزام. إنه إذن لتغيير الأشياء دون كسر العالم. كل شيء آخر هو مجرد شريط علامات التبويب.
عناوين سهلة الاستخدام وسهلة النطق (لأنك طلبت ذلك)
lakeFS مقابل DVC لخطوط أنابيب ML
إذا كانت خطوط أنابيب ML الخاصة بك ثقيلة التعليمات البرمجية مع مجموعات بيانات منفصلة وقطع أثرية نموذجية، فإن DVC يتكامل بشكل أفضل: ملفات المؤشر في Git، والتجزئات، والتجارب المتعقبة. بالنسبة لخطوط الأنابيب الثقيلة البيانات التي تغذي فرقًا متعددة، يفوز lakeFS بعزل قائم على الفروع عبر البحيرة بأكملها.
lakeFS مقابل DVC لحوكمة البيانات
يمنحك lakeFS عمليات إيداع قابلة للتدقيق وخطافات دمج على حدود التخزين. يمنحك DVC الأصل على حدود خط الأنابيب. إذا كان القانون يريد نقاط تفتيش غير قابلة للتغيير، فهذا هو lakeFS؛ إذا كانت الهندسة تريد عمليات تشغيل قابلة لإعادة الإنتاج، فهذا هو DVC.
الاختيار بين DVC و lakeFS لتخزين الكائنات
لا يوفر تخزين الكائنات معاملات. يعمل DVC على حل ذلك باستخدام تجزئات على مستوى الكائن والدفع/السحب. يميل lakeFS إلى ذلك باستخدام بيانات تعريف النسخ عند الكتابة ودلالات الفروع. اختر بناءً على ما إذا كان ألمك في المستودع أو الحاوية.
الجمع بين lakeFS و DVC بدون صداع
استخدم lakeFS لإصدار البحيرة؛ معرفات إيداع السطح إلى DVC بحيث يتم تثبيت التجارب على مدخلات دقيقة. احتفظ بالقطع الأثرية النموذجية في أجهزة التحكم عن بعد DVC؛ احتفظ بمجموعات البيانات الأولية والمنظمة في فروع lakeFS. لا توجد اختراقات غير مصرح بها مطلوبة.
الأسئلة الشائعة
س1: أيهما أفضل لتجارب ML: lakeFS أو DVC؟
لتجارب ML، عادةً ما يفوز DVC. فهو يربط التعليمات البرمجية والمعلمات ومجموعات البيانات والنماذج معًا، بينما يتعامل lakeFS مع عزل مجموعة البيانات والسفر عبر الزمن على مستوى البحيرة.
س2: هل يمكنني استخدام lakeFS و DVC معًا بدون فوضى؟
نعم. استخدم عمليات إيداع lakeFS لإصدار مجموعات بيانات البحيرة الخاصة بك وقم بالإشارة إلى معرفات الالتزام هذه في DVC. اسمح لـ DVC بالتعامل مع القطع الأثرية وخطوط الأنابيب؛ اسمح لـ lakeFS بالتعامل مع الفروع وعمليات الدمج على تخزين الكائنات.
س3: هل يستبدل DVC بحيرة بيانات أو lakeFS؟
لا. يقوم DVC بتنظيم الملفات الكبيرة والتجارب حول Git؛ لا يحول S3 إلى متجر معاملات. يقع lakeFS أمام البحيرة الخاصة بك ويضيف التفرع وعمليات الإيداع والعزل.
س4: هل يعتبر lakeFS مبالغة بالنسبة للفرق الصغيرة؟
في الغالب، نعم. إذا كنت لا تتعامل مع عزل أو حوكمة متعددة الفرق، فإن بساطة DVC جذابة. يكون lakeFS منطقيًا عندما يوفر العزل القائم على الفروع ومسارات التدقيق أموالًا حقيقية أو حالات انقطاع.
س5: كيف تتم مقارنة التكاليف بين lakeFS و DVC؟
تميل تكاليف DVC نحو وقت المطور وتغيير التخزين أثناء الدفع/السحب. تميل تكاليف lakeFS نحو تشغيل الخدمة وإدارة السياسات، ولكن التفرع رخيص وصديق للتصدير.