الغوص في بحيرة دلتا: تنفيذ المخطط والتطور

يا هبر! أقدم انتباهكم إلى ترجمة المقال "الغوص في بحيرة دلتا: تنفيذ المخطط والتطور" المؤلفون بوراك يافوز ، برينر هاينز وديني لي ، والتي تم تحضيرها تحسبا لبدء الدورة مهندس بيانات من أوتوس.

البيانات ، مثل تجربتنا ، تتراكم وتتطور باستمرار. لمواكبة ذلك ، يجب أن تتكيف نماذجنا العقلية للعالم مع البيانات الجديدة ، التي يحتوي بعضها على أبعاد جديدة - طرق جديدة لمراقبة الأشياء التي لم تكن لدينا أي فكرة عنها من قبل. لا تختلف هذه النماذج العقلية كثيرًا عن مخططات الجدول التي تحدد كيفية تصنيف المعلومات الجديدة ومعالجتها.

هذا يقودنا إلى مسألة إدارة المخطط. مع تغير أهداف ومتطلبات العمل بمرور الوقت ، يتغير هيكل بياناتك أيضًا. تسهل Delta Lake تنفيذ قياسات جديدة مع تغير البيانات. يمكن للمستخدمين الوصول إلى دلالات بسيطة لإدارة مخططات الجداول الخاصة بهم. تتضمن هذه الأدوات تطبيق Schema Enforcement ، الذي يحمي المستخدمين من تلويث جداولهم عن غير قصد بأخطاء أو بيانات غير ضرورية ، و Schema Evolution ، الذي يسمح بإضافة أعمدة جديدة من البيانات القيمة تلقائيًا في الأماكن المناسبة. في هذه المقالة ، سوف نتعمق في استخدام هذه الأدوات.

فهم مخططات الجدول

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

ما هو تطبيق المخطط؟

فرض المخطط ، المعروف أيضًا باسم التحقق من صحة المخطط ، هو آلية حماية في Delta Lake تضمن جودة البيانات عن طريق رفض السجلات التي لا تتطابق مع مخطط الجدول. مثل مضيفة في مكتب الاستقبال في مطعم شهير يقبل الحجوزات فقط ، يقوم بالتحقق لمعرفة ما إذا كان كل عمود من البيانات المدخلة في الجدول موجودًا في القائمة المقابلة للأعمدة المتوقعة (بمعنى آخر ، إذا كان هناك "حجز" لـ كل واحد منهم) ، ويرفض أي مدخلات بها أعمدة غير موجودة في القائمة.

كيف يعمل تطبيق المخطط؟

تستخدم Delta Lake التحقق من صحة المخطط عند الكتابة ، مما يعني أنه يتم فحص جميع عمليات الكتابة الجديدة في الجدول للتأكد من توافقها مع مخطط الجدول الهدف في وقت الكتابة. إذا كان مخطط قاعدة البيانات غير متسق ، فإن Delta Lake يعكس المعاملة بالكامل (لا تتم كتابة أي بيانات) ويطرح استثناءً لإعلام المستخدم بعدم الاتساق.
تستخدم Delta Lake القواعد التالية لتحديد ما إذا كان أحد السجلات متوافقًا مع أحد الجداول. DataFrame مكتوبة:

• لا يمكن أن تحتوي على أعمدة إضافية غير موجودة في مخطط الجدول الهدف. على العكس من ذلك ، كل شيء على ما يرام إذا كانت البيانات الواردة لا تحتوي على الإطلاق على جميع الأعمدة من الجدول - سيتم ببساطة تعيين قيم صفرية لهذه الأعمدة.
• لا يمكن أن تحتوي على أنواع بيانات أعمدة مختلفة عن أنواع بيانات العمود في الجدول الهدف. إذا احتوى عمود في الجدول الهدف على بيانات StringType ، لكن العمود المقابل في DataFrame يحتوي على بيانات IntegerType ، فإن فرض المخطط سوف يطرح استثناء ويمنع حدوث عملية الكتابة.
• لا يمكن أن تحتوي على أسماء أعمدة تختلف فقط في حالة. هذا يعني أنه لا يمكنك تحديد أعمدة باسم "Foo" و "foo" في نفس الجدول. بينما يمكن استخدام Spark في الوضع الحساس لحالة الأحرف أو غير الحساسة لحالة الأحرف (الوضع الافتراضي) ، فإن Delta Lake تحافظ على حالة الأحرف ولكنها غير حساسة داخل تخزين المخطط. الباركيه حساس لحالة الأحرف عند تخزين وإعادة معلومات العمود. لتجنب الأخطاء المحتملة أو تلف البيانات أو فقدان البيانات (الذي واجهناه شخصيًا في Databricks) ، قررنا إضافة هذا القيد.

لتوضيح ذلك ، دعنا نلقي نظرة على ما يحدث في الكود أدناه عند محاولة إضافة بعض الأعمدة التي تم إنشاؤها حديثًا إلى جدول Delta Lake الذي لم يتم تكوينه بعد لقبولها.

# Сгенерируем DataFrame ссуд, который мы добавим в нашу таблицу Delta Lake
loans = sql("""
            SELECT addr_state, CAST(rand(10)*count as bigint) AS count,
            CAST(rand(10) * 10000 * count AS double) AS amount
            FROM loan_by_state_delta
            """)

# Вывести исходную схему DataFrame
original_loans.printSchema()

root
  |-- addr_state: string (nullable = true)
  |-- count: integer (nullable = true)
 
# Вывести новую схему DataFrame
loans.printSchema()
 
root
  |-- addr_state: string (nullable = true)
  |-- count: integer (nullable = true)
  |-- amount: double (nullable = true) # new column
 
# Попытка добавить новый DataFrame (с новым столбцом) в существующую таблицу
loans.write.format("delta") 
           .mode("append") 
           .save(DELTALAKE_PATH)

Returns:

A schema mismatch detected when writing to the Delta table.
 
To enable schema migration, please set:
'.option("mergeSchema", "true")'
 
Table schema:
root
-- addr_state: string (nullable = true)
-- count: long (nullable = true)
 
Data schema:
root
-- addr_state: string (nullable = true)
-- count: long (nullable = true)
-- amount: double (nullable = true)
 
If Table ACLs are enabled, these options will be ignored. Please use the ALTER TABLE command for changing the schema.

بدلاً من إضافة أعمدة جديدة تلقائيًا ، تفرض Delta Lake مخططًا وتوقف التسجيل. للمساعدة في تحديد العمود (أو مجموعة منهم) الذي يسبب عدم التطابق ، يقوم Spark بإخراج كلا المخططين من مكدس التتبع للمقارنة.

ما فائدة تطبيق المخطط؟

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

• خوارزميات التعلم الآلي
• لوحات معلومات BI
• أدوات تحليل البيانات والتصور
• أي نظام إنتاج يتطلب مخططات دلالية شديدة التنظيم وذات جودة عالية.

لإعداد بياناتهم لهذه العقبة الأخيرة ، يستخدم العديد من المستخدمين بنية بسيطة "متعددة القفزات" تُدخل البنية تدريجياً في جداولهم. لمعرفة المزيد حول هذا الموضوع ، يمكنك قراءة المقال تعلم الآلة على مستوى الإنتاج مع Delta Lake.

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

منع ترقق البيانات

عند هذه النقطة ، قد تتساءل عن سبب الضجيج؟ بعد كل شيء ، في بعض الأحيان قد يؤدي خطأ "عدم تطابق المخطط" غير المتوقع إلى إخطارك في سير العمل ، خاصة إذا كنت جديدًا في Delta Lake. لماذا لا تترك المخطط يتغير حسب الحاجة حتى أتمكن من كتابة DataFrame الخاص بي بغض النظر عن أي شيء؟

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

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

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

ما هو تطور المخطط؟

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

كيف يعمل تطور المخطط؟

باتباع المثال الوارد في القسم السابق ، يمكن للمطورين استخدام تطور المخطط بسهولة لإضافة أعمدة جديدة تم رفضها مسبقًا بسبب عدم اتساق المخطط. يتم تنشيط تطور الدائرة عن طريق الإضافة .option('mergeSchema', 'true') لفريق سبارك الخاص بك .write или .writeStream.

# Добавьте параметр mergeSchema
loans.write.format("delta") 
           .option("mergeSchema", "true") 
           .mode("append") 
           .save(DELTALAKE_SILVER_PATH)

لعرض الرسم البياني ، قم بتشغيل استعلام Spark SQL التالي

# Создайте график с новым столбцом, чтобы подтвердить, что запись прошла успешно
%sql
SELECT addr_state, sum(`amount`) AS amount
FROM loan_by_state_delta
GROUP BY addr_state
ORDER BY sum(`amount`)
DESC LIMIT 10

بدلاً من ذلك ، يمكنك ضبط هذا الخيار لجلسة Spark بأكملها عن طريق الإضافة spark.databricks.delta.schema.autoMerge = True لتكوين سبارك. لكن استخدم هذا بحذر ، لأن تطبيق المخطط لن يحذرك بعد الآن من تناقضات المخطط غير المقصودة.

بتضمين معلمة في الطلب mergeSchema، تتم إضافة جميع الأعمدة الموجودة في DataFrame ولكنها غير موجودة في الجدول الهدف تلقائيًا إلى نهاية المخطط كجزء من معاملة الكتابة. يمكن أيضًا إضافة الحقول المتداخلة ، وستتم أيضًا إضافتها إلى نهاية أعمدة البنية المقابلة.

يمكن لمهندسي التاريخ وعلماء البيانات استخدام هذا الخيار لإضافة أعمدة جديدة (ربما مقياس تم تتبعه مؤخرًا أو عمود أرقام مبيعات هذا الشهر) إلى جداول إنتاج التعلم الآلي الحالية دون كسر النماذج الحالية بناءً على الأعمدة القديمة.

يُسمح بالأنواع التالية من تغييرات المخطط كجزء من تطور المخطط أثناء إضافة جدول أو الكتابة فوقه:

• إضافة أعمدة جديدة (هذا هو السيناريو الأكثر شيوعًا)
• تغيير أنواع البيانات من NullType -> أي نوع آخر أو ترقية من ByteType -> ShortType -> IntegerType

تتطلب التغييرات الأخرى غير المسموح بها كجزء من تطور المخطط أن يتم الكتابة فوق المخطط والبيانات عن طريق الإضافة .option("overwriteSchema", "true"). على سبيل المثال ، في الحالة التي يكون فيها عمود "Foo" في الأصل عددًا صحيحًا ويكون المخطط الجديد من نوع بيانات سلسلة ، فحينئذٍ يجب الكتابة فوق جميع ملفات باركيه (البيانات). تشمل هذه التغييرات:

• حذف عمود
• تغيير نوع البيانات لعمود موجود (في المكان)
• إعادة تسمية الأعمدة التي تختلف فقط في حالة (على سبيل المثال ، "Foo" و "foo")

أخيرًا ، مع الإصدار التالي من Spark 3.0 ، سيتم دعم DDL الصريح (باستخدام ALTER TABLE) بالكامل ، مما يسمح للمستخدمين بتنفيذ الإجراءات التالية على مخططات الجدول:

• مضيفا الأعمدة
• تغيير تعليقات العمود
• تعيين خصائص الجدول التي تحدد سلوك الجدول ، مثل تعيين مدة الاحتفاظ بسجل المعاملات.

ما فائدة تطور المخطط؟

يمكن استخدام التطور التخطيطي متى شئت ينوي قم بتغيير مخطط الجدول الخاص بك (على عكس عندما أضفت بطريق الخطأ أعمدة إلى DataFrame الخاصة بك والتي لا ينبغي أن تكون موجودة). هذه هي أسهل طريقة لترحيل مخططك لأنه يضيف تلقائيًا أسماء الأعمدة وأنواع البيانات الصحيحة دون الحاجة إلى التصريح عنها صراحة.

اختتام

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

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

تطبيق المخطط هو yang ، حيث تكون تطورات المخطط هي yin. عند استخدامها معًا ، تجعل هذه الميزات تقليل الضوضاء وضبط الإشارة أسهل من أي وقت مضى.

نود أيضًا أن نشكر Mukul Murthy و Pranav Anand على مساهماتهم في هذا المقال.

مقالات أخرى في هذه السلسلة:

الغوص في Delta Lake: تفريغ سجل المعاملات

Статьи по теме

تعلم الآلة على مستوى الإنتاج مع Delta Lake

ما هي بحيرة البيانات؟

تعلم المزيد عن الدورة

المصدر: www.habr.com