Databricks Lakehouse: حين يلتقي الـ data lake أخيرًا بالـ warehouse

على مدى عقد كامل، كانت كل منصة بيانات جادة تعمل بنظامين. data lake يُلقى فيه كل شيء داخل تخزين كائنات رخيص، وdata warehouse يقدّم الجداول النظيفة والمنمذجة التي يستعلم عنها العمل فعلًا. نسختان من البيانات، ومجموعتان من الـ pipelines، وفاتورتان، وجدال دائم حول أيهما يحمل الحقيقة.

الـ lakehouse هو المحاولة لطيّ هذا الانقسام في واحد. لم يخترع Databricks لا التخزين ولا صيغة الملف، لكنه غلّف النمط في شيء يستطيع فريق أن يشغّله في الإنتاج. بعد عدة مشاريع من هذا النوع، إليك ما هو حقيقي وما هو تسويق.

عالمان، ولماذا كانت الفرق تستخدم كليهما

الـ data lake هو تخزين كائنات — Azure Data Lake Storage Gen2 وS3 وGCS — يحمل ملفات خامة بأي صيغة. إنه رخيص، وقابل للتوسّع إلى ما لا نهاية، وهو schema-on-read: تقرّر البنية عند الاستعلام، لا عند الكتابة. الثمن أن lake بلا انضباط يتحوّل إلى مستنقع. بلا معاملات، بلا فرض للمخطط، بلا طريقة سهلة لتحديث صف واحد.

الـ warehouse هو العكس. جداول مُهيكلة، وضمانات ACID، وSQL سريع، وحوكمة حقيقية. الثمن هو الجمود والسعر: تدفع لتحميل البيانات، وتدفع مقابل تخزين مملوك، وأحمال machine learning التي تريد ملفات خامة لا تناسب النموذج.

استخدام كليهما يعني نسخ البيانات بينهما والتوفيق بين النسخ إلى الأبد. سؤال الـ lakehouse بسيط: ماذا لو استطاع الـ lake أن يتصرّف كـ warehouse بلا نسخة ثانية؟

ما هو الـ lakehouse فعلًا

الحيلة هي صيغة جدول مفتوحة تُطبَّق فوق الملفات في تخزين الكائنات. في Databricks هذا هو Delta Lake: ملفات بيانات Parquet زائد سجل معاملات. ذلك السجل هو اللعبة كلها. إنه يمنحك:

• معاملات ACID — الكتابات المتزامنة لم تعد تُفسد جدولًا.
• فرض المخطط وتطوّره — تُرفض البيانات السيئة، وتُصدَّر التغييرات الجيدة بأرقام إصدارات.
• Time travel — استعلم عن الجدول كما كان يوم الثلاثاء الماضي، أو تراجع عن تحميل معطوب.
• Upserts والحذف — MERGE يعمل، وهو ما يهم من أجل الحذف بموجب GDPR وchange-data-capture.

بما أن البيانات تبقى بصيغة Parquet المفتوحة في حساب التخزين الخاص بك، فإن نسخة واحدة تخدم كل شيء: لوحات معلومات SQL، وأعمال streaming، وتدريب ML كلها تقرأ الجداول نفسها. بلا احتكار على البايتات، وبلا خطوة تصدير. تلك هي المكافأة.

بنية الـ medallion

الـ lakehouse يمنحك العناصر الأولية؛ وبنية الـ medallion هي الطريقة التي تُبقيها بها مرتبة. تتدفق البيانات عبر ثلاثة مستويات من الجودة:

1. البرونزي — استيعاب خام، تمامًا كما وصلت. للإلحاق فقط، قابل للتدقيق، لا يُحرَّر أبدًا.
2. الفضي — منظَّف، منزوع التكرار، مُوحَّد. مربوط ومُنمَّط، لكنه ما زال دقيق التفصيل.
3. الذهبي — تجميعات على مستوى العمل ومخططات نجمية تستهلكها لوحات المعلومات والتقارير.

الانضباط يهم أكثر من الأداة. البرونزي هو بوليصة تأمينك: إن كان تحويل فضي خاطئًا، تعيد المعالجة من البرونزي بدلًا من إعادة الاستيعاب من المصدر. تجاوَزه وتفقد القدرة على إصلاح التاريخ.

Unity Catalog: الحوكمة التي لا يمكنك إضافتها لاحقًا

Unity Catalog هي القطعة التي يستهين بها أغلب الفرق. إنها طبقة حوكمة واحدة فوق كل workspace: تحكّم دقيق في الوصول، وإخفاء للأعمدة والصفوف، و — الجزء الذي ينقذك في التدقيق — lineage تلقائي. تستطيع أن ترى أيّ تقرير يعتمد على أيّ جدول ذهبي، الذي يعتمد على أيّ عمل فضي، وصولًا إلى الملف الخام.

الحوكمة ليست شيئًا تُركّبه لاحقًا حين تصبح لديك خمسمئة جدول ولا أحد يعرف من يستطيع قراءة ماذا. فعّلها عند الجدول الأول. تكلفة نقلها لاحقًا وحشية.

الأداء: Photon والـ SQL warehouse

كان الاعتراض القديم على الـ lakes هو السرعة: الاستعلام عن الملفات لم يكن قادرًا على منافسة warehouse مضبوط. أمران سدّا الفجوة. Photon محرك استعلام متجهي مكتوب بـ C++ يُسرّع أحمال SQL وDataFrame دون تغيير كودك. وSQL warehouses من Databricks تمنح المحللين نقطة نهاية مألوفة: يوصلون أداة BI ويستعلمون عن الجداول الذهبية، غير مدركين أن تحتها تخزين كائنات.

التخزين والحوسبة منفصلان، لذا تُوسّع عناقيد الاستعلام إلى الأعلى لإغلاق شهري ثقيل ثم إلى الأسفل بعده دون لمس البيانات. تلك المرونة هي حيث تميل اقتصاديات السحابة فعلًا لصالحك — الانضباط نفسه الذي أدافع عنه في منصات الذكاء الاصطناعي الهادئة.

متى يكون الـ lakehouse هو الإجابة الخاطئة

إنه ليس ترقية شاملة. كن صادقًا بشأن الحجم:

• بيانات صغيرة وعلائقية بحتة. إن كان كل شيء يتّسع بارتياح في Postgres وتقدّم BI فقط، فإن warehouse مُدار أبسط وأرخص. الـ lakehouse آلية لا تحتاجها.
• بلا قدرة هندسية. Delta والعناقيد وتدفّق الـ medallion سطح تشغيلي حقيقي. فريق صغير يغرق.
• مخططات نجمية بحتة ومستقرة، بلا ML ولا streaming. يتألق الـ lakehouse حين تكون الأحمال مختلطة. إن كانت أحمالك لن تكون كذلك أبدًا، فالمرونة ثقل ميّت.

---

يكسب الـ lakehouse مكانه حين تملك حقًا كلا العالمين — بيانات خامة وstreaming تُغذّي ML و جداول نظيفة تُغذّي العمل — وتكون قد سئمت الدفع مرتين لإبقائهما متزامنين. ابدأ بـ Delta ومستويات الـ medallion، فعّل Unity Catalog فورًا، ودَع Photon يقلق بشأن السرعة. التالي في هذه السلسلة: كيف تلعب Microsoft اللعبة نفسها مع Fabric وOneLake وCopilot Studio.