ترحيل مسارات ETL إلى Azure Databricks
توفر هذه المقالة نظرة عامة على خيارات ترحيل مسارات الاستخراج والتحويل والتحميل (ETL) التي تعمل على أنظمة البيانات الأخرى إلى Azure Databricks. إذا كنت تقوم بترحيل التعليمات البرمجية ل Apache Spark، فشاهد تكييف التعليمات البرمجية ل Apache Spark exisiting ل Azure Databricks.
للحصول على معلومات عامة حول الانتقال من مستودع بيانات المؤسسة إلى مستودع بحيرة، راجع ترحيل مستودع البيانات إلى مستودع Databricks. للحصول على معلومات حول الانتقال من Parquet إلى Delta Lake، راجع ترحيل مستودع بيانات Parquet إلى Delta Lake.
يمكن تشغيل معظم أحمال عمل Apache Hive على Azure Databricks بأقل قدر من إعادة بناء التعليمات البرمجية. يسمح إصدار Spark SQL المدعوم من Databricks Runtime بالعديد من بنيات HiveQL. راجع توافق Apache Hive. يتضمن Azure Databricks مخزن بيانات Hive بشكل افتراضي. تحتاج معظم عمليات ترحيل Hive إلى معالجة بعض المخاوف الأساسية:
- يجب تحديث Hive SerDe لاستخدام برامج ترميز ملفات Azure Databricks الأصلية. (تغيير DDL من
STORED AS
إلىUSING
لاستخدام Azure Databricks SerDe.) - يجب تثبيت Hive UDFs إما على المجموعات كمكتبات أو إعادة بناء التعليمات البرمجية إلى Spark الأصلي. نظرا لأن Hive UDFs موجودة بالفعل في JVM، فقد توفر أداء كافيا للعديد من أحمال العمل. راجع اعتبارات الأداء.
- يجب تغيير بنية الدليل للجداول، حيث يستخدم Azure Databricks أقساما بشكل مختلف عن Apache Hive. راجع متى يتم تقسيم الجداول على Azure Databricks.
إذا اخترت تحديث الجداول إلى Delta Lake أثناء الترحيل الأولي، فإن عددا من عبارات DDL وDML غير مدعومة. يتضمن هذا ما يلي:
ROWFORMAT
SERDE
OUTPUTFORMAT
INPUTFORMAT
COMPRESSION
STORED AS
ANALYZE TABLE PARTITION
ALTER TABLE [ADD|DROP] PARTITION
ALTER TABLE RECOVER PARTITIONS
ALTER TABLE SET SERDEPROPERTIES
CREATE TABLE LIKE
INSERT OVERWRITE DIRECTORY
LOAD DATA
- تحديد الأقسام المستهدفة باستخدام
PARTITION (part_spec)
فيTRUNCATE TABLE
عادة ما يتطلب ترحيل أحمال عمل SQL من أنظمة أخرى إلى Azure Databricks القليل جدا من إعادة بناء التعليمات البرمجية، اعتمادا على مدى استخدام بروتوكولات النظام المحددة في التعليمات البرمجية المصدر. يستخدم Azure Databricks Delta Lake بتنسيق الجدول الافتراضي، لذلك يتم إنشاء الجداول بضمانات المعاملات بشكل افتراضي.
Spark SQL متوافق في الغالب مع ANSI، ولكن قد توجد بعض الاختلافات في السلوك. راجع كيف يختلف Databricks Data Intelligence Platform عن مستودع بيانات المؤسسة؟.
نظرا لأن أنظمة البيانات تميل إلى تكوين الوصول إلى البيانات الخارجية بشكل مختلف، فقد يكون الكثير من مسارات SQL ETL لإعادة بناء التعليمات البرمجية للعمل تكوين الوصول إلى مصادر البيانات هذه ثم تحديث المنطق الخاص بك لاستخدام هذه الاتصالات الجديدة. يوفر Azure Databricks خيارات للاتصال بالعديد من مصادر البيانات لاستيعابها.
يوفر Azure Databricks تكاملا أصليا مع dbt، ما يسمح لك بالاستفادة من برامج dbt النصية الحالية مع القليل جدا من إعادة بناء التعليمات البرمجية.
توفر Delta Live Tables بناء جملة SQL تعريفيا أصليا من Databricks لإنشاء البنية الأساسية لبرنامج ربط العمليات التجارية واختبارها ونشرها. بينما يمكنك الاستفادة من dbt على Azure Databricks، قد يؤدي إعادة بناء التعليمات البرمجية الخفيفة إلى Delta Live Tables إلى خفض التكلفة الإجمالية لتشغيل المسارات الخاصة بك على Azure Databricks. راجع ما هي جداول Delta Live؟.
تجعل قابلية توسعة وتنوع وظائف السحابة المخصصة بلا خادم من الصعب تقديم توصية شائعة، ولكن إحدى حالات الاستخدام الأكثر شيوعا لهذه الوظائف هي انتظار ظهور الملفات أو البيانات في موقع أو قائمة انتظار الرسائل ثم تنفيذ بعض الإجراءات نتيجة لذلك. في حين أن Azure Databricks لا يدعم المنطق المعقد لتشغيل أحمال العمل استنادا إلى ظروف السحابة، يمكنك استخدام Structured Streaming بالاقتران مع الوظائف لمعالجة البيانات بشكل متزايد.
استخدم "المحمل التلقائي" لاستيعاب البيانات المحسنة من تخزين كائن السحابة. يمكن أن يعالج الدفق المنظم البيانات من مصادر الدفق في الوقت الفعلي تقريبا.
قد تحتاج مسارات ETL المعرفة بلغات أخرى غير SQL أو Apache Spark أو Hive إلى إعادة بناء التعليمات البرمجية بشكل كبير قبل التشغيل على Azure Databricks. يتمتع Azure Databricks بخبرة في مساعدة العملاء على الترحيل من معظم أنظمة البيانات المستخدمة اليوم، وقد يكون لديهم موارد متاحة لبدء جهود الترحيل الخاصة بك.