يُعَد Delta Lake تنسيق تخزين بيانات مفتوح المصدر يجمع بين ملفات بيانات Apache Parquet وسجل البيانات الوصفية القوي. يوفِّر Delta Lake وظائف رئيسية لإدارة البيانات، مثل معاملات ACID وتحديد إصدارات البيانات، إلى بحيرات البيانات، ما يجعله الأساس للعديد من مستودعات بحيرات البيانات.
تم تطوير Delta Lake لأول مرة بواسطة Databricks في عام 2016، وهو تنسيق جدول مفتوح، وإطار عمل مفتوح المصدر للبيانات الجدولية يبني طبقة بيانات وصفية فوق تنسيقات الملفات الموجودة. يستخدم Delta Lake على وجه التحديد جداول Parquet لتخزين البيانات. وتتضمن تنسيقات الجداول المفتوحة الأخرى Apache Iceberg و Apache Hudi.
تُتيح طبقة البيانات الوصفية لتنسيق Delta Lake والجداول المفتوحة الأخرى تحسين استعلامات البحث ودعم العمليات المتقدمة للبيانات التي لا يمكن للعديد من تنسيقات الجداول القياسية تنفيذها. غالبًا ما تستخدم المؤسسات Delta Lake لجعل بحيرات البيانات الخاصة بها أكثر موثوقية وسهولة في الاستخدام.
كان إنشاء Delta Lake خطوة حاسمة في تطوير هندسة مستودعات بحيرات البيانات، والتي تجمع بين تخزين بحيرة البيانات وأداء مستودع البيانات.
غالبًا ما تتم مناقشة Delta Lake وبحيرات البيانات معًا، ولكن من المهم أن نعلم أن هذه التقنيات تختلف عن بعضها.
بحيرة البيانات هي بيئة تخزين بيانات منخفضة التكلفة مصممة للتعامل مع مجموعات بيانات كبيرة من أي نوع أو تنسيق. تستخدم معظم بحيرات البيانات منصات تخزين الكائنات السحابية مثل Amazon Simple Storage Service (S3) أو Microsoft Azure Blob Storage أو IBM Cloud Object Storage.
يُعَد Delta Lake تنسيق تخزين بيانات جدوليًا يمكن للمؤسسة استخدامه في بحيرة البيانات أو أي مخزن بيانات آخر.
لا يُعَد Delta Lake نوعًا من بحيرات البيانات، وليس بديلًا لها. وبدلًا من ذلك، يمكننا أن نفكر في بحيرة البيانات باعتبارها "المكان" وبحيرة دلتا باعتبارها "الكيفية":
يمكن أن يساعد تنسيق Delta Lake على جعل بحيرات البيانات أكثر قابلية للإدارة والكفاءة.
تحتوي بحيرات البيانات على العديد من الفوائد، ولكنها تفتقر عادةً إلى ضوابط جودة البيانات المدمجة، وقد يكون من الصعب الاستعلام المباشر منها. غالبًا ما يتعين على المؤسسات أخذ البيانات من بحيرة البيانات، وتنظيفها، وتحميلها في مستودعات بيانات ومتاجر بيانات منفصلة قبل التمكُّن من استخدامها.
ومن خلال تقديم طبقة البيانات الوصفية، يوفِّر Delta Lake للمؤسسة طريقة لفرض المخططات وتتبُّع التغييرات والتراجع عنها ودعم معاملات ACID.
يمكن للمستخدمين تنفيذ استعلامات لغة الاستعلامات الهيكلية (SQL)، وأعباء العمل التحليلية، والأنشطة الأخرى مباشرةً على بحيرة البيانات، ما يُسهم في تبسيط ذكاء الأعمال (BI)، وذكاء البيانات (DI)، والذكاء الاصطناعي (AI)، والتعلم الآلي (ML).
يحتوي Delta Lake على عنصرين أساسيين: ملفات البيانات التي تحتوي على البيانات وسجل المعاملات الذي يضم البيانات الوصفية حول ملفات البيانات هذه.
يعمل سجل المعاملات على تسجيل معلومات حول ملفات البيانات (مثل أسماء الأعمدة والقيم الدنيا والعليا) والتغييرات التي تم إجراؤها على الملفات (ما تم تغييره، ومتى، وكيف، ومن قام بذلك).
السجل هو ما يجعل Delta Lake مختلفًا عن ملف Parquet العادي. يعمل سجل المعاملات كطبقة إدارة ومجموعة من التعليمات لجميع الأنشطة في بحيرة البيانات، ما يُتيح ميزات مثل المعاملات ACID، والسفر عبر الزمن، وتطور المخطط.
ملفات Parquet العادية غير قابلة للتغيير، ما يعني أنه لا يمكن تعديلها بعد إنشائها؛ يمكن فقط إعادة كتابتها. يُسهم سجل المعاملات في Delta Lake في جعل ملفات Parquet قابلة للتعديل من الناحية الوظيفية، إن لم يكن حرفيًا، من خلال فصل الإجراءات المادية (الإجراءات التي تُنفَّذ مباشرةً على البيانات) عن الإجراءات المنطقية (الإجراءات التي تُنفَّذ على البيانات الوصفية).
على سبيل المثال، لا يمكن للمستخدم إزالة عمود واحد من جدول Parquet دون إعادة كتابة الملف بأكمله. في Delta Lake، يمكن للمستخدم إزالة هذا العمود بشكل فعَّال عن طريق تعديل البيانات الوصفية للجدول ووضع علامة على أن العمود تم حذفه. يبقى العمود في الملف، لكن جميع الاستعلامات والتحديثات والكتابات اللاحقة ترى البيانات الوصفية وتتعامل مع العمود على أنه غير موجود.
يشير الاختصار ACID هو اختصار للمصطلحات التالية: الذَّرية (Atomicity) والاتساق (Consistency) والعزلة (Isolation) والمتانة (Durability)، وهي خصائص أساسية تساعد على ضمان سلامة المعاملات على البيانات.
لا يمكن لبحيرات البيانات القياسية دعم معاملات ACID. ومن دون ضمانات ACID، تكون بحيرات البيانات عرضة للمعاملات الفاشلة والكتابة الجزئية وغيرها من المشكلات التي يمكن أن تُفسد البيانات.
يستطيع سجل المعاملات في Delta Lake تسجيل معلومات المعاملات وفقًا لمبادئ ACID، ما يجعل بحيرات البيانات أكثر موثوقية لتدفق مسارات البيانات، وذكاء الأعمال، والتحليلات، وحالات الاستخدام الأخرى.
يمكن للمسؤولين تعيين متطلبات المخطط في سجل المعاملات، وتنطبق هذه المتطلبات على جميع البيانات عند الاستيعاب. يتم رفض البيانات التي لا تفي بمتطلبات المخطط.
يمكن للمسؤولين أيضًا استخدام سجل المعاملات لتغيير مخطط ملف موجود، مثل إضافة أعمدة جديدة أو تغيير أنواع الأعمدة. وتُعرَف هذه العملية باسم "تطور المخطط".
على الرغم من أنه ليس فهرسًا تقليديًا، إلا أن سجل المعاملات يمكن أن يساعد الاستعلامات على استرجاع البيانات بشكل أسرع وأكثر كفاءة.
على سبيل المثال، لنفترض أن المستخدم يبحث عن قيمة معينة في عمود ما. باستخدام البيانات الوصفية في سجل المعاملات، يمكن لاستعلام المستخدم تخطي أي ملفات لا يمكن أن توجد فيها القيمة المستهدفة. إذا كان الحد الأدنى للقيمة أعلى أو كانت القيمة القصوى أقل من القيمة الهدف، فيمكن للاستعلام تخطي الملف.
يقوم سجل المعاملات أيضًا بتخزين مسارات الملفات. فبدلًا من فحص بحيرة البيانات بأكملها، يمكن للاستعلامات استخدام مسارات الملفات هذه للتوجه مباشرةً إلى الملفات ذات الصلة.
يمكن لتنسيق Delta Lake استخدام تقنيات مثل "الترتيب على شكل Z" لتخزين البيانات المتشابهة بالقرب من بعضها على القرص، ما يسهِّل تخطي الملفات غير ذات الصلة والعثور على الملفات ذات الصلة.
ملفات Parquet العادية غير قابلة للتغيير، لكن يمكن للمستخدمين التلاعب بجداول Delta عبر طبقة البيانات الوصفية. تدعم Delta Lake جميع أنواع عمليات البيانات، بما في ذلك إضافة أو إسقاط الأعمدة وتحديث الإدخالات ودمج الملفات.
نظرًا لأن سجل المعاملات يسجل كل ما يحدث في جداول Delta، فإنه يحتفظ بشكل فعَّال بسجلات الإصدار لكل جدول. يمكن للمستخدمين الاستعلام عن الإصدارات السابقة وكذلك السفر عبر الزمن، أي التراجع عن التغييرات لاستعادة إصدارات الجدول السابقة.
يتمتع Delta Lake بمنظومة قوية من الموصِّلات. يمكن استخدام التنسيق مع محركات الحوسبة المختلفة، مثل Apache Spark أو Apache Hive أو Apache Flink أو Trino. تحتوي Delta Lake أيضًا على واجهات برمجة التطبيقات (APIs) للغات Python وJava وScala ولغات أخرى، ما يُتيح للمطورين إدارة جداول Delta والاستعلام عنها برمجيًا.
على الرغم من أن Delta Lake لا يفرض ضوابط الأمان بشكل أصلي، إلا أنه يمكنه التكامل مع أدوات أمن البيانات وحوكمة البيانات . يمكن لهذه الأدوات بعد ذلك استخدام البيانات الوصفية من سجل المعاملات لتدقيق النشاط وتتبُّع التغييرات وفرض سياسات التحكم في الوصول المستندة إلى الأدوار (RBAC ).
يمكن أن تقبل Delta Lake كلًّا من البيانات المتدفقة والمجمعة، ويمكن إرسال البيانات من جداول Delta إلى الخدمات المتصلة كتدفق أو على دفعات.
من المخطط أن يتضمن Delta Lake 4.0، الإصدار الرئيسي التالي المتوقع لتنسيق Delta Lake، المزيد من الميزات مثل:
يُعَد Apache Iceberg تنسيق مصدر مفتوح للأداء للجداول التحليلية الضخمة. ومثل Delta Lake، يقوم Iceberg ببناء طبقة بيانات وصفية فوق تنسيقات الجداول الحالية لدعم معاملات ACID والعمليات الأخرى في بحيرة البيانات.
يستطيع Iceberg تخزين البيانات في ملفات Parquet أو ORC أو Avro، بينما يستخدم Delta Lake تنسيق Parquet حصريًا. يستخدم Iceberg أيضًا طبقة بيانات وصفية ثلاثية المستويات بدلًا من سجل معاملات واحد مثل Delta Lake.
يتكامل Iceberg بشكل مدمج مع العديد من محركات الاستعلام المختلفة، ويُعَد خيارًا شائعًا للتحليلات المعتمدة على SQL في بحيرات البيانات.
مثل Delta Lake وIceberg، يحتفظ Hudi بطبقة بيانات وصفية أعلى طبقة البيانات. يستطيع Hudi استخدام تنسيقات ملفات Parquet وHFile وORC، وتأخذ طبقة البيانات الوصفية شكل "الجدول الزمني" الذي يسجل كل ما يحدث في طبقة البيانات.
تم تصميم Hudi لمعالجة البيانات المتزايدة، حيث تتم معالجة دفعات صغيرة من البيانات بشكل متكرر. هذا التركيز على المعالجة التدريجية يجعل من Hudi خيارًا شائعًا للتحليلات الفورية والتقاط بيانات التغيير (CDC).
ساعد تطوير تنسيق Delta Lake على تمهيد الطريق لإنشاء مستودعات بحيرات البيانات.
لفترة طويلة، كانت المؤسسات تدير بياناتها بشكل أساسي في مستودعات البيانات. على الرغم من أن المستودعات مفيدة للتحليلات وذكاء الأعمال، إلا أنها تتطلب مخططات صارمة. فهي لا تعمل بشكل جيد مع البيانات غير المنظمة أو شبه المنظمة، والتي أصبحت أكثر انتشارًا وأهمية مع زيادة المؤسسات لاستثماراتها في الذكاء الاصطناعي والتعلم الآلي (ML).
إن ظهور بحيرات البيانات في أوائل العقد الأول من الألفية الجديدة أتاح للمؤسسات وسيلة لتجميع جميع أنواع البيانات من مصادر بيانات متنوعة في مكان واحد.
ومع ذلك، فإن بحيرات البيانات لديها مشكلاتها الخاصة. فهي غالبًا ما تفتقر إلى ضوابط الجودة. إذ لا تدعم معاملات ACID، وليس من السهل الاستعلام عنها مباشرةً.
لجعل البيانات قابلة للاستخدام، غالبًا ما تحتاج المؤسسات إلى بناء استخراج وتحويل وتحميل (ETL) مسارات بيانات منفصلة لنقل البيانات من بحيرة إلى مستودع.
ظهر Delta Lake في عام 2016، وأضاف معاملات ACID، وفَرَض المخططات، والتنقل عبر الزمن إلى بحيرات البيانات، ما جعلها أكثر موثوقية للاستعلام المباشر والتحليلات.
تم فتح مصدر Delta Lake في عام 2019، وكان له دور رئيسي في تشكيل بنية مستودعات بحيرات البيانات، التي تجمع بين مرونة بحيرات البيانات وأداء مستودعات البيانات.
تُنشئ العديد من المؤسسات مستودعات بحيرات بيانات من خلال بناء طبقة تخزين Delta Lake فوق بحيرة بيانات موجودة ودمجها مع محرك معالجة بيانات مثل Spark أو Hive.
تساعد مستودعات بحيرات البيانات على دعم تكامل البيانات وتبسيط هيكل البيانات من خلال القضاء على الحاجة إلى الحفاظ على بحيرات بيانات ومستودعات بيانات منفصلة، ما قد يؤدي إلى وجود صوامع بيانات.
بدورها، تساعد هذه الهياكل المبسطة على ضمان تمكُّن علماء البيانات، ومهندسي البيانات، والمستخدمين الآخرين من الوصول إلى البيانات التي يحتاجونها في الوقت الذي يحتاجون فيه إليها. تُعَد أعباء العمل الخاصة بالذكاء الاصطناعي والتعلم الآلي من الحالات الشائعة لاستخدامات بحيرات البيانات المدعومة بتنسيق Delta Lake.
تُعَد بحيرات البيانات، في حد ذاتها، مفيدة بالفعل لأعباء العمل هذه لأنها يمكن أن تضم كميات هائلة من البيانات المنظمة وغير المنظمة وشبه المنظمة.
ومن خلال إضافة ميزات مثل معاملات ACID وإنفاذ المخطط، يساعد Delta Lake على ضمان جودة بيانات التدريب والموثوقية بطرق لا تستطيع بحيرات البيانات القياسية القيام بها.
استفِد من بياناتك أينما كانت باستخدام مستودع بحيرة البيانات الهجين المفتوح للذكاء الاصطناعي والتحليلات.
تغلب على تحديات البيانات الحالية باستخدام بنية مستودع بحيرة بيانات؛ لتتمكن من الاتصال بالبيانات في دقائق، والحصول بسرعة على رؤى موثوقة وتقليل تكاليف مستودع البيانات لديك.
استفِد من قيمة بيانات المؤسسة مع IBM Consulting لبناء مؤسسة تعتمد على الرؤى لتحقيق ميزة تنافسية في الأعمال.