مشاركة عبر

تحويل بيانات

  • مقالة

توفر هذه المقالة مقدمة ونظرة عامة حول تحويل البيانات باستخدام Azure Databricks. يعد تحويل البيانات أو إعداد البيانات خطوة رئيسية في جميع أحمال عمل هندسة البيانات والتحليلات وأحمال عمل التعلم الآلي.

تركز الأنماط والتوصيات في هذه المقالة على العمل مع جداول lakehouse، والتي تدعمها Delta Lake. نظرا لأن Delta Lake يوفر ضمانات ACID لمخزن بحيرة Databricks، فقد تلاحظ سلوكا مختلفا عند العمل مع البيانات بتنسيقات أو أنظمة بيانات أخرى.

توصي Databricks باستيعاب البيانات في مستودع في حالة أولية أو خام تقريبا، ثم تطبيق التحويلات والإثراء كخطوة معالجة منفصلة. يعرف هذا النمط باسم بنية الميدالية. راجع ما هو تصميم lakehouse medallion؟.

إذا كنت تعرف أن البيانات التي تحتاج إلى تحويلها لم يتم تحميلها بعد إلى مستودع، فشاهد استيعاب البيانات في مستودع Databricks. إذا كنت تحاول العثور على بيانات مستودع لكتابة التحويلات مقابلها، فشاهد اكتشاف البيانات.

تبدأ جميع التحويلات بكتابة استعلام دفعي أو استعلام دفق مقابل مصدر بيانات. إذا لم تكن على دراية بالاستعلام عن البيانات، فشاهد الاستعلام عن البيانات.

بمجرد حفظ البيانات المحولة إلى جدول Delta، يمكنك استخدام هذا الجدول كجدول ميزات ل ML. راجع هندسة الميزات وخدمتها.

إشعار

تناقش المقالات هنا التحويلات على Azure Databricks. يدعم Azure Databricks أيضا الاتصالات بالعديد من الأنظمة الأساسية لإعداد البيانات الشائعة. راجع الاتصال بشركاء إعداد البيانات باستخدام Partner Connect.

تحويلات Spark مقابل تحويلات lakehouse

تركز هذه المقالة على تعريف النماذج من حيث صلتها ب T في ETL أو ELT. يستخدم نموذج معالجة Apache Spark أيضا تحويل الكلمة بطريقة ذات صلة. باختصار: في Apache Spark، يتم تعريف جميع العمليات إما على أنها تحويلات أو إجراءات.

  • التحويلات: أضف بعض منطق المعالجة إلى الخطة. تتضمن الأمثلة قراءة البيانات والصلات والتجميعات وصب النوع.
  • الإجراءات: تشغيل منطق المعالجة لتقييم النتيجة وإخراجها. تتضمن الأمثلة عمليات الكتابة أو عرض النتائج أو معاينتها أو التخزين المؤقت اليدوي أو الحصول على عدد الصفوف.

يستخدم Apache Spark نموذج تنفيذ كسول، ما يعني أنه لا يتم تقييم أي من المنطق المحدد بواسطة مجموعة من العمليات حتى يتم تشغيل إجراء. يحتوي هذا النموذج على تشعب مهم عند تحديد مسارات معالجة البيانات: استخدم الإجراءات فقط لحفظ النتائج مرة أخرى في جدول هدف.

نظرا لأن الإجراءات تمثل ازدحاما في المعالجة لتحسين المنطق، فقد أضافت Azure Databricks العديد من التحسينات بالإضافة إلى تلك الموجودة بالفعل في Apache Spark لضمان التنفيذ الأمثل للمنطق. تأخذ هذه التحسينات في الاعتبار جميع التحويلات التي يتم تشغيلها بواسطة إجراء معين في وقت واحد وتجد الخطة المثلى استنادا إلى التخطيط الفعلي للبيانات. يمكن أن يؤدي التخزين المؤقت للبيانات يدويا أو إرجاع نتائج المعاينة في مسارات الإنتاج إلى مقاطعة هذه التحسينات ويؤدي إلى زيادات كبيرة في التكلفة وزمن الانتقال.

لذلك يمكننا تحديد تحويل مستودع ليكون أي مجموعة من العمليات المطبقة على واحد أو أكثر من جداول lakehouse التي تؤدي إلى جدول بحيرة جديد. لاحظ أنه في حين تتم مناقشة التحويلات مثل الصلات والتجميعات بشكل منفصل، يمكنك دمج العديد من هذه الأنماط في خطوة معالجة واحدة والثقة في المحسنين على Azure Databricks للعثور على الخطة الأكثر كفاءة.

ما هي الاختلافات بين الدفق ومعالجة الدفعات؟

بينما يستخدم الدفق ومعالجة الدفعات الكثير من نفس بناء الجملة على Azure Databricks، لكل منهما دلالات خاصة به.

تسمح لك معالجة الدفعات بتحديد إرشادات صريحة لمعالجة كمية ثابتة من البيانات الثابتة وغير المتغيرة كعملية واحدة.

تسمح لك معالجة الدفق بتحديد استعلام مقابل مجموعة بيانات غير مقيدة ومتزايدة باستمرار ثم معالجة البيانات على دفعات صغيرة تزايدية.

تستخدم عمليات الدفعات على Azure Databricks Spark SQL أو DataFrames، بينما تستفيد معالجة الدفق من الدفق المنظم.

يمكنك تمييز أوامر Apache Spark الدفعية عن Structured Streaming من خلال النظر في عمليات القراءة والكتابة، كما هو موضح في الجدول التالي:

Apache Spark دفق منظم
مقروء spark.read.load() spark.readStream.load()
الكتابة spark.write.save() spark.writeStream.start()

تتوافق طرق العرض المجسدة بشكل عام مع ضمانات معالجة الدفعات، على الرغم من استخدام جداول Delta Live لحساب النتائج بشكل متزايد عندما يكون ذلك ممكنا. دائما ما تكون النتائج التي يتم إرجاعها بواسطة طريقة عرض مجسدة مكافئة للتقييم الدفعي للمنطق، ولكن Azure Databricks تسعى إلى معالجة هذه النتائج بشكل متزايد عندما يكون ذلك ممكنا.

تقوم الجداول المتدفقة دائما بحساب النتائج بشكل متزايد. نظرا لأن العديد من مصادر بيانات الدفق تحتفظ بسجلات لفترة ساعات أو أيام فقط، يفترض نموذج المعالجة المستخدم بواسطة جداول الدفق أن كل دفعة من السجلات من مصدر بيانات تتم معالجتها مرة واحدة فقط.

يدعم Azure Databricks استخدام SQL لكتابة استعلامات الدفق في حالات الاستخدام التالية:

  • تعريف جداول الدفق في كتالوج Unity باستخدام Databricks SQL.
  • تعريف التعليمات البرمجية المصدر لخطوط أنابيب Delta Live Tables.

إشعار

يمكنك أيضا الإعلان عن جداول الدفق في Delta Live Tables باستخدام التعليمات البرمجية ل Python Structured Streaming.

تحويلات الدفعات

تعمل تحويلات الدفعات على مجموعة محددة جيدا من أصول البيانات في نقطة زمنية محددة. قد تكون تحويلات الدفعات عمليات لمرة واحدة، ولكنها غالبا ما تكون جزءا من المهام المجدولة أو المسارات التي تعمل بانتظام للحفاظ على تحديث أنظمة الإنتاج.

التحويلات المتزايدة

تفترض الأنماط المتزايدة بشكل عام أن مصدر البيانات ملحق فقط ولديه مخطط ثابت. توفر المقالات التالية تفاصيل حول الفروق الدقيقة للتحويلات التزايدية على الجداول التي تواجه التحديثات أو الحذف أو تغييرات المخطط:

التحولات في الوقت الحقيقي

تتفوق Delta Lake في توفير وصول قريب من الوقت الحقيقي إلى كميات كبيرة من البيانات لجميع المستخدمين والتطبيقات التي تستعلم عن lakehouse الخاص بك، ولكن بسبب الحمل مع كتابة الملفات وبيانات التعريف إلى تخزين الكائنات السحابية، لا يمكن الوصول إلى زمن الانتقال الحقيقي الحقيقي للعديد من أحمال العمل التي تكتب إلى متلقي Delta Lake.

بالنسبة لتطبيقات الدفق ذات زمن الانتقال المنخفض للغاية، توصي Databricks باختيار أنظمة المصدر والمتلقي المصممة لأحمال العمل في الوقت الحقيقي مثل Kafka. يمكنك استخدام Azure Databricks لإثراء البيانات، بما في ذلك التجميعات، والصلات عبر التدفقات، والانضمام إلى بيانات الدفق مع بيانات الأبعاد المتغيرة ببطء المخزنة في المستودع.