دليل ترحيل Databricks Runtime 7.x (غير مدعوم)

مقالة
03/01/2024

يوفر هذا الدليل إرشادات لمساعدتك في ترحيل أحمال عمل Azure Databricks من Databricks Runtime 6.x، المبني على Apache Spark 2.4، إلى Databricks Runtime 7.3 LTS (غير مدعوم) ، وكلاهما مبني على Spark 3.0.

يسرد هذا الدليل تغييرات سلوك Spark 3.0 التي قد تتطلب منك تحديث أحمال عمل Azure Databricks. تتضمن بعض هذه التغييرات الإزالة الكاملة لدعم Python 2، والترقية إلى Scala 2.12، والدعم الكامل ل JDK 11، والتبديل من التقويم الميلادي إلى التقويم Proleptic للتواريخ والطوابع الزمنية.

هذا الدليل هو مصاحب لدليل ترحيل Databricks Runtime 7.3 LTS (غير مدعوم).

للحصول على معلومات حول الترحيل بين إصدارات وقت تشغيل Databricks، راجع دليل ترحيل وقت تشغيل Databricks.

الميزات والتحسينات الجديدة المتوفرة على Databricks Runtime 7.x

للحصول على قائمة بالميزات الجديدة والتحسينات وترقيات المكتبة المضمنة في Databricks Runtime 7.3 LTS، راجع ملاحظات الإصدار لكل إصدار Databricks Runtime أعلى الإصدار الذي تقوم بالترحيل منه. تتضمن إصدارات Databricks Runtime 7.x المدعومة ما يلي:

Databricks Runtime 7.3 LTS (غير مدعوم)

يتم سرد تحديثات الصيانة بعد الإصدار في تحديثات الصيانة لوقت تشغيل Databricks (مؤرشف) .

بيئة نظام Databricks Runtime 7.3 LTS

نظام التشغيل: Ubuntu 18.04.5 LTS
Java:
- 7.3 LTS: Zulu 8.48.0.53-CA-linux64 (النسخة 1.8.0_265-b11)
Scala: 2.12.10
Python: 3.7.5
R: 3.6.3 (2020-02-29)
Delta Lake 0.7.0

تغييرات سلوك Apache Spark 3.0 الرئيسية

قد تتطلب تغييرات السلوك التالية من Spark 2.4 إلى Spark 3.0 تحديث أحمال عمل Azure Databricks عند الترحيل من Databricks Runtime 6.x إلى Databricks Runtime 7.x.

إشعار

توفر هذه المقالة قائمة بتغييرات سلوك Spark المهمة التي يجب مراعاتها عند الترحيل إلى Databricks Runtime 7.x. للحصول على قائمة كاملة بتغييرات السلوك، راجع دليل ترحيل Spark 3.0.1.

الأساسي

في Spark 3.0، تتم إزالة المجمع المهمل v1.
ستتم كتابة ملف سجل الأحداث بترميز UTF-8، وسيعيد Spark History Server تشغيل ملفات سجل الأحداث كترميز UTF-8. في السابق، كتب Spark ملف سجل الأحداث كمجموعة أحرف افتراضية لعملية JVM لبرنامج التشغيل، لذلك يلزم خادم محفوظات Spark ل Spark 2.x لقراءة ملفات سجل الأحداث القديمة في حالة الترميز غير المتوافق.
يتم استخدام بروتوكول جديد لجلب كتل التبديل العشوائي. يوصى بترقية خدمات التبديل العشوائي الخارجية عند تشغيل تطبيقات Spark 3.0. لا يزال بإمكانك استخدام خدمات التبديل العشوائي الخارجية القديمة عن طريق تعيين التكوين spark.shuffle.useOldFetchProtocol إلى true. وإلا، قد تواجه Spark أخطاء مع رسائل مثل IllegalArgumentException: Unexpected message type: <number>.

PySpark

في Spark 3.0، Column.getItem تم إصلاحه بحيث لا يستدعي Column.apply. وبالتالي، إذا Column تم استخدام كوسيطة ل getItem، يجب استخدام عامل تشغيل الفهرسة. على سبيل المثال، map_col.getItem(col('id')) يجب استبدال ب map_col[col('id')].
اعتبارا من Spark 3.0، Row لم تعد أسماء الحقول يتم فرزها أبجديا عند الإنشاء باستخدام وسيطات مسماة لإصدارات Python 3.6 وما فوق، وسيتطابق ترتيب الحقول مع ذلك كما تم إدخاله. لتمكين الحقول التي تم فرزها بشكل افتراضي، كما هو الحال في Spark 2.4، قم بتعيين متغير PYSPARK_ROW_FIELD_SORTING_ENABLED البيئة إلى true لكل من المنفذين وبرنامج التشغيل. يجب أن يكون متغير البيئة هذا متناسقا على جميع المنفذين وبرنامج التشغيل. وإلا، فقد يتسبب ذلك في فشل أو إجابات غير صحيحة. بالنسبة لإصدارات Python الأقل من 3.6، يتم فرز أسماء الحقول أبجديا كخيار وحيد.
دعم Python 2 المهمل (SPARK-27884).

دفق منظم

في Spark 3.0، يفرض Structured Streaming مخطط المصدر إلى قيم خالية عند استخدام مصادر البيانات المستندة إلى الملفات مثل النص وjson وcsv وparquet وorc عبر spark.readStream(...). في السابق، كان يحترم قابلية القيم الخالية في مخطط المصدر؛ ومع ذلك، تسبب في مشكلات صعبة لتصحيح الأخطاء باستخدام NPE. لاستعادة السلوك السابق، قم بتعيين spark.sql.streaming.fileSource.schema.forceNullable إلى false.
يعمل Spark 3.0 على إصلاح مشكلة التصحيح في الصلة الخارجية Stream-stream، والتي تغير مخطط الحالة. راجع SPARK-26154 لمزيد من التفاصيل. إذا بدأت الاستعلام من نقطة التحقق التي تم إنشاؤها من Spark 2.x والتي تستخدم الصلة الخارجية دفق الدفق، يفشل Spark 3.0 في الاستعلام. لإعادة حساب المخرجات، تجاهل نقطة التحقق وإعادة تشغيل الإدخالات السابقة.
في Spark 3.0، تمت إزالة الفئة org.apache.spark.sql.streaming.ProcessingTime المهملة. استخدم org.apache.spark.sql.streaming.Trigger.ProcessingTime بدلاً من ذلك. وبالمثل ، org.apache.spark.sql.execution.streaming.continuous.ContinuousTrigger تمت إزالتها لصالح Trigger.Continuous، وتم org.apache.spark.sql.execution.streaming.OneTimeTrigger إخفاؤها لصالح Trigger.Once. راجع SPARK-28199.

SQL ومجموعات البيانات وDataFrame

في Spark 3.0، عند إدراج قيمة في عمود جدول بنوع بيانات مختلف، يتم تنفيذ نوع الإكراه وفقا لمعيار ANSI SQL. بعض تحويلات النوع غير المعقولة مثل التحويل string إلى int وإلى doubleboolean غير مسموح بها. سيتم طرح استثناء وقت التشغيل إذا كانت القيمة خارج النطاق لنوع بيانات العمود. في إصدار Spark 2.4 والإصدارات السابقة، يسمح بإجراء تحويلات النوع أثناء إدراج الجدول طالما أنها صالحة Cast. عند إدراج قيمة خارج النطاق إلى حقل متكامل، يتم إدراج وحدات البت ذات الترتيب المنخفض للقيمة (مثل تحويل نوع Java/Scala الرقمي). على سبيل المثال، إذا تم إدراج 257 في حقل من نوع البايت، تكون النتيجة 1. يتم التحكم في السلوك بواسطة الخيار spark.sql.storeAssignmentPolicy، بقيمة افتراضية ك "ANSI". يؤدي تعيين الخيار إلى "Legacy" إلى استعادة السلوك السابق.
في Spark 3.0، عند تحويل قيمة السلسلة إلى أنواع متكاملة (tinyint وs smallint و int و bigint)، يتم اقتطاع أنواع التاريخ والوقت (التاريخ والطوابع الزمنية والفاصل الزمني) والنوع المنطقي، يتم اقتطاع المسافات البيضاء البادئة واللاحقة (<= ACSII 32) قبل تحويلها إلى قيم النوع هذه، على سبيل المثال cast(' 1\t' as int) إرجاع 1، وإرجاع cast(' 1\t' as boolean)true، cast('2019-10-10\t as date) وإرجاع قيمة 2019-10-10التاريخ . في إصدار Spark 2.4 والإصدارات السابقة، أثناء تحويل السلسلة إلى أجزاء متكاملة وقيم منطقية، فإنه لن يقلم المسافات البيضاء من كلا الطرفين، وستكون nullالنتائج السابقة ، بينما إلى أوقات التاريخ، ستتم إزالة المسافات اللاحقة فقط (= ASCII 32). راجع https://databricks.com/blog/2020/07/22/a-comprehensive-look-at-dates-and-timestamps-in-apache-spark-3-0.html.
في Spark 3.0، الأساليب SQLContext.createExternalTable المهملة وتمت SparkSession.createExternalTable إزالتها لصالح استبدالها، createTable.
في Spark 3.0، يصبح التكوين spark.sql.crossJoin.enabled تكوينا داخليا، ويصدق بشكل افتراضي، لذلك لن يقوم Spark بشكل افتراضي برفع استثناء على SQL مع الصلات المتقاطعة الضمنية.
في Spark 3.0، قمنا بعكس ترتيب الوسيطة لدالة الاقتطاع من TRIM(trimStr, str) إلى TRIM(str, trimStr) لتكون متوافقة مع قواعد البيانات الأخرى.
في إصدار Spark 2.4 والإصدارات السابقة، يتم دعم استعلامات SQL مثل FROM <table> أو FROM <table> UNION ALL FROM <table> عن طريق الصدفة. في نمط FROM <table> SELECT <expr>الخلية ، العبارة SELECT ليست ضئيلة. لا يدعم Apache Hive ولا Presto بناء الجملة هذا. لذلك سوف نتعامل مع هذه الاستعلامات على أنها غير صالحة منذ Spark 3.0.
منذ Spark 3.0، لم يعد يتم إهمال Dataset وDataFrame API unionAll بعد الآن. وهو اسم مستعار ل union.
في إصدار Spark 2.4 والإصدارات السابقة، يتعامل محلل مصدر بيانات JSON مع السلاسل الفارغة على أنها خالية لبعض أنواع البيانات مثل IntegerType. بالنسبة إلى FloatType و DoubleType، فإنه يفشل في السلاسل الفارغة ويطرح استثناءات. منذ Spark 3.0، لا نلسماح بالسلاسل الفارغة وسنطرح استثناءات لأنواع البيانات باستثناء StringType و BinaryType.
منذ Spark 3.0، from_json تدعم الوظائف وضعين - PERMISSIVE و FAILFAST. يمكن تعيين الأوضاع عبر mode الخيار . أصبح PERMISSIVEالوضع الافتراضي . في الإصدارات السابقة، لم يتوافق سلوك from_json مع أي PERMISSIVE من أو FAILFAST, خاصة في معالجة سجلات JSON التي تم تكوينها بشكل غير جيد. على سبيل المثال، يتم تحويل سلسلة {"a" 1} JSON مع المخطط a INT إلى null بواسطة الإصدارات السابقة ولكن Spark 3.0 يحولها إلى Row(null).

عبارات لغة تعريف البيانات "DDL"

في Spark 3.0، CREATE TABLE بدون موفر معين، يستخدم قيمة spark.sql.sources.default كموفر له. في إصدار Spark 2.4 والإصدارات أدناه، كانت Hive. لاستعادة السلوك قبل Spark 3.0، يمكنك تعيين spark.sql.legacy.createHiveTableByDefault.enabled إلى true.
في Spark 3.0، عند إدراج قيمة في عمود جدول بنوع بيانات مختلف، يتم تنفيذ نوع الإكراه وفقا لمعيار ANSI SQL. بعض تحويلات النوع غير المعقولة مثل التحويل string إلى int وإلى doubleboolean غير مسموح بها. يتم طرح استثناء وقت التشغيل إذا كانت القيمة خارج النطاق لنوع بيانات العمود. في إصدار Spark 2.4 والإصدارات الأحدث، يسمح بإجراء تحويلات النوع أثناء إدراج الجدول طالما أنها صالحة Cast. عند إدراج قيمة خارج النطاق إلى حقل متكامل، يتم إدراج وحدات البت ذات الترتيب المنخفض للقيمة (مثل تحويل نوع Java/Scala الرقمي). على سبيل المثال، إذا تم إدراج 257 في حقل من نوع البايت، تكون النتيجة 1. يتم التحكم في السلوك بواسطة الخيار spark.sql.storeAssignmentPolicy، بقيمة افتراضية ك "ANSI". يؤدي تعيين الخيار ك "قديم" إلى استعادة السلوك السابق.
في Spark 3.0، SHOW CREATE TABLE يقوم دائما بإرجاع Spark DDL، حتى عندما يكون الجدول المحدد هو جدول Hive SerDe. لإنشاء Hive DDL، استخدم SHOW CREATE TABLE AS SERDE الأمر بدلا من ذلك.
في Spark 3.0، العمود من CHAR النوع غير مسموح به في جداول غير Hive-Serde، CREATE/ALTER TABLE وستفشل الأوامر إذا CHAR تم الكشف عن النوع. الرجاء استخدام STRING النوع بدلا من ذلك. في إصدار Spark 2.4 والإصدارات أدناه، CHAR يتم التعامل مع النوع كنوع STRING ويتم تجاهل معلمة الطول ببساطة.

UDFs والوظائف المضمنة

في Spark 3.0، لا يسمح باستخدام org.apache.spark.sql.functions.udf(AnyRef, DataType) بشكل افتراضي. قم بتعيين spark.sql.legacy.allowUntypedScalaUDF إلى true لمتابعة استخدامه. في إصدار Spark 2.4 والإصدارات أدناه، إذا org.apache.spark.sql.functions.udf(AnyRef, DataType) حصل على إغلاق Scala مع وسيطة من النوع الأولي، فإن UDF الذي تم إرجاعه يرجع قيمة خالية إذا كانت قيم الإدخال فارغة. ومع ذلك، في Spark 3.0، ترجع UDF القيمة الافتراضية لنوع Java إذا كانت قيمة الإدخال فارغة. على سبيل المثال، val f = udf((x: Int) => x, IntegerType), f($"x") إرجاع قيمة خالية في Spark 2.4 والإصدارات أدناه إذا كان العمود x فارغا، ويرجع 0 في Spark 3.0. يتم تقديم تغيير السلوك هذا لأن Spark 3.0 تم إنشاؤه باستخدام Scala 2.12 بشكل افتراضي.
في إصدار Spark 2.4 والإصدارات أدناه، يمكنك إنشاء خريطة بمفاتيح مكررة عبر وظائف مضمنة مثل CreateMap، StringToMap، وما إلى ذلك. سلوك الخريطة بالمفاتيح المكررة غير معرف، على سبيل المثال، البحث عن الخريطة يحترم ظهور المفتاح المكرر أولا، Dataset.collect ويحافظ فقط على ظهور المفتاح المكرر أخيرا، MapKeys ويعيد المفاتيح المكررة، وما إلى ذلك. في Spark 3.0، يطرح RuntimeException Spark عند العثور على مفاتيح مكررة. يمكنك التعيين spark.sql.mapKeyDedupPolicy إلى LAST_WIN لإلغاء تكرار مفاتيح الخريطة باستخدام نهج الفوز الأخير. لا يزال بإمكان المستخدمين قراءة قيم الخريطة باستخدام مفاتيح مكررة من مصادر البيانات التي لا تفرضها (على سبيل المثال، Parquet)، السلوك غير معرف.

مصادر البيانات

في إصدار Spark 2.4 والإصدارات أدناه، يتم تحويل قيمة عمود القسم كقيمة خالية إذا تعذر تحويلها إلى مخطط مقدم من مستخدم مطابق. في 3.0، يتم التحقق من قيمة عمود القسم باستخدام مخطط مقدم من المستخدم. يتم طرح استثناء إذا فشل التحقق من الصحة. يمكنك تعطيل التحقق من الصحة هذا عن طريق تعيين spark.sql.sources.validatePartitionColumns إلى false.
في إصدار Spark 2.4 والإصدارات أدناه، يتعامل محلل مصدر بيانات JSON مع السلاسل الفارغة على أنها خالية لبعض أنواع البيانات مثل IntegerType. بالنسبة إلى FloatTypeو DateTypeDoubleTypeو، TimestampTypeفإنه يفشل في السلاسل الفارغة ويطرح استثناءات. لا تسمح Spark 3.0 بالسلاسل الفارغة وستطرح استثناء أنواع البيانات باستثناء StringType و BinaryType. يمكن استعادة السلوك السابق للسماح بسلسلة فارغة عن طريق تعيين spark.sql.legacy.json.allowEmptyString.enabled إلى true.
في Spark 3.0، إذا اختفت الملفات أو الدلائل الفرعية أثناء إدخال قائمة الدليل المتكرر (أي أنها تظهر في قائمة وسيطة ولكن بعد ذلك لا يمكن قراءتها أو سردها أثناء المراحل اللاحقة من سرد الدليل المتزامن، بسبب عمليات حذف الملفات المتزامنة أو مشكلات تناسق مخزن الكائنات) فستفشل القائمة مع استثناء ما لم يكن spark.sql.files.ignoreMissingFilestrue (خطأ افتراضي). في الإصدارات السابقة، سيتم تجاهل هذه الملفات أو الدلائل الفرعية المفقودة. لاحظ أن هذا التغيير في السلوك ينطبق فقط أثناء إدخال ملف الجدول الأولي (أو أثناء REFRESH TABLE)، وليس أثناء تنفيذ الاستعلام: التغيير الصافي هو الذي spark.sql.files.ignoreMissingFiles يتم تنفيذه الآن أثناء سرد ملف الجدول وتخطيط الاستعلام، وليس فقط في وقت تنفيذ الاستعلام.
في إصدار Spark 2.4 والإصدارات أدناه، يحول مصدر بيانات CSV سلسلة CSV مشوهة إلى صف يحتوي على كافة القيم الخالية في وضع PERMISSIVE. في Spark 3.0، يمكن أن يحتوي الصف الذي تم إرجاعه على حقول غير فارغة إذا تم تحليل بعض قيم أعمدة CSV وتحويلها إلى الأنواع المطلوبة بنجاح.
في Spark 3.0، يتم استخدام نوع TIMESTAMP_MICROS parquet المنطقي بشكل افتراضي أثناء حفظ TIMESTAMP الأعمدة. في إصدار Spark 2.4 والإصدارات أدناه، TIMESTAMP يتم حفظ الأعمدة كما في INT96 ملفات parquet. لاحظ أن بعض أنظمة SQL مثل Hive 1.x و Impala 2.x يمكنها قراءة الطوابع الزمنية INT96 فقط. يمكنك تعيين spark.sql.parquet.outputTimestampType ك INT96 لاستعادة السلوك السابق والحفاظ على إمكانية التشغيل التفاعلي.
في Spark 3.0، عند كتابة ملفات Avro مع مخطط مقدم من المستخدم، تتم مطابقة الحقول بأسماء الحقول بين مخطط المحفز ومخطط Avro بدلا من المواضع.

محرك الاستعلام

في Spark 3.0، يفشل استعلام مجموعة البيانات إذا كان يحتوي على مرجع عمود غامض بسبب الصلة الذاتية. مثال نموذجي: val df1 = ...; val df2 = df1.filter(...);, then df1.join(df2, df1("a") > df2("a")) إرجاع نتيجة فارغة مربكة جدا. وذلك لأن Spark لا يمكنه حل مراجع أعمدة مجموعة البيانات التي تشير إلى الجداول التي يتم ربطها ذاتيا، وهي df1("a") تماما نفس الموجودة df2("a") في Spark. لاستعادة السلوك قبل Spark 3.0، يمكنك تعيين spark.sql.analyzer.failAmbiguousSelfJoin إلى false.
في Spark 3.0، يتم تحليل الأرقام المكتوبة في تدوين علمي (على سبيل المثال، 1E2) ك Double. في إصدار Spark 2.4 والإصدارات أدناه، يتم تحليلها على أنها Decimal. لاستعادة سلوك ما قبل Spark 3.0، يمكنك تعيين spark.sql.legacy.exponentLiteralAsDecimal.enabled إلى true.
في Spark 3.0، يصبح التكوين spark.sql.crossJoin.enabled تكوينا داخليا ويصدق بشكل افتراضي. بشكل افتراضي، لن يقوم Spark برفع استثناءات على SQL مع الصلات المتقاطعة الضمنية.
في إصدار Spark 2.4 والإصدارات الأحدث، يكون float/double -0.0 مساويا دلاليا ل 0.0، ولكن -0.0 و0.0 يعتبران قيما مختلفة عند استخدامها في مفاتيح التجميع التجميعية ومفاتيح أقسام النافذة ومفاتيح الربط. في Spark 3.0، تم إصلاح هذا الخطأ. على سبيل المثال، Seq(-0.0, 0.0).toDF("d").groupBy("d").count() إرجاع [(0.0, 2)] في Spark 3.0، وفي [(0.0, 1), (-0.0, 1)] Spark 2.4 والإصدارات أدناه.
في Spark 3.0، TIMESTAMP يتم تحويل القيم الحرفية إلى سلاسل باستخدام تكوين spark.sql.session.timeZoneSQL . في إصدار Spark 2.4 والإصدارات الأحدث، يستخدم التحويل المنطقة الزمنية الافتراضية لجهاز Java الظاهري.
في Spark 3.0، يتم تحويل String Spark إلى Date/Timestamp في مقارنات ثنائية مع التواريخ/الطوابع الزمنية. يمكن استعادة السلوك السابق للصب Date/Timestamp إلى String عن طريق تعيين spark.sql.legacy.typeCoercion.datetimeToString.enabled إلى true.
في إصدار Spark 2.4 والإصدارات أدناه، يتم تجاهل معرفات المنطقة الزمنية غير الصالحة بصمت واستبدالها بالمنطقة الزمنية GMT، على سبيل المثال، في الدالة from_utc_timestamp . في Spark 3.0، يتم رفض معرفات المنطقة الزمنية هذه، ويرمي java.time.DateTimeExceptionSpark .
في Spark 3.0، يتم استخدام التقويم الميلادي Proleptic في تحليل التواريخ والطوابع الزمنية وتنسيقها وتحويلها وكذلك في استخراج المكونات الفرعية مثل السنوات والأيام وما إلى ذلك. يستخدم Spark 3.0 فئات Java 8 API من حزم java.time التي تستند إلى ترتيب ISO الزمني. في إصدار Spark 2.4 والإصدارات أدناه، يتم تنفيذ هذه العمليات باستخدام التقويم المختلط (جوليان + ميلادي). تؤثر التغييرات على نتائج التواريخ قبل 15 أكتوبر 1582 (الميلادي) وتؤثر على واجهة برمجة تطبيقات Spark 3.0 التالية:
- تحليل/تنسيق الطابع الزمني/سلاسل التاريخ. يؤدي هذا إلى التأثير على مصادر بيانات CSV/JSON وعلى الوظائف و unix_timestampto_timestampdate_formatto_unix_timestampfrom_unixtimeto_dateعند استخدام الأنماط المحددة من قبل المستخدمين لتحليلها وتنسيقها. في Spark 3.0، نحدد سلاسل النمط الخاصة بنا في sql-ref-datetime-pattern.md، والتي يتم تنفيذها عبر java.time.format.DateTimeFormatter تحت الغطاء. ينفذ التنفيذ الجديد فحصا صارما لمدخلاته. على سبيل المثال، 2015-07-22 10:00:00 لا يمكن تحليل الطابع الزمني إذا كان النمط لأن yyyy-MM-dd المحلل لا يستهلك الإدخال الكامل. مثال آخر هو 31/01/2015 00:00 أنه لا يمكن تحليل الإدخال حسب dd/MM/yyyy hh:mm النمط لأن hh الساعات تفترض مسبقا في النطاق 1-12. في إصدار Spark 2.4 والإصدارات أدناه، java.text.SimpleDateFormat يتم استخدام لتحويلات سلسلة الطابع الزمني/التاريخ، ويتم وصف الأنماط المدعومة في simpleDateFormat. يمكن استعادة السلوك القديم عن طريق تعيين spark.sql.legacy.timeParserPolicy إلى LEGACY.
- weekofyearfrom_utc_timestampdayofweekweekdayto_utc_timestampunix_timestampdate_truncتستخدم java.time الدالات و واجهة برمجة التطبيقات لحساب عدد الأسابيع من السنة ورقم يوم الأسبوع بالإضافة إلى التحويل من/إلى TimestampType القيم في المنطقة الزمنية UTC.
- يتم تحويل خيارات lowerBound JDBC وتحويلها upperBound إلى قيم TimestampType/DateType بنفس طريقة تحويل السلاسل إلى قيم TimestampType/DateType. يعتمد التحويل على التقويم الميلادي Proleptic والمنطقة الزمنية المحددة بواسطة تكوين spark.sql.session.timeZoneSQL . في إصدار Spark 2.4 والإصدارات الأحدث، يستند التحويل إلى التقويم المختلط (جوليان + ميلادي) وعلى المنطقة الزمنية الافتراضية للنظام.
- TIMESTAMP التنسيق والأحرف DATE الحرفية.
- إنشاء القيم الحرفية TIMESTAMP والمكتبة DATE من السلاسل. في Spark 3.0، يتم إجراء تحويل السلسلة إلى قيم حرفية مكتوبة TIMESTAMP/DATE عبر التحويل إلى TIMESTAMP/DATE القيم. على سبيل المثال، TIMESTAMP '2019-12-23 12:59:30' يساوي CAST('2019-12-23 12:59:30' AS TIMESTAMP)دلاليا . عندما لا تحتوي سلسلة الإدخال على معلومات حول المنطقة الزمنية، يتم استخدام المنطقة الزمنية من تكوين spark.sql.session.timeZone SQL في هذه الحالة. في إصدار Spark 2.4 والإصدارات الأحدث، يعتمد التحويل على المنطقة الزمنية لنظام JVM. قد تغير المصادر المختلفة للمنطقة الزمنية الافتراضية سلوك القيم الحرفية TIMESTAMP والمكتبة DATE .

Apache Hive

في Spark 3.0، قمنا بترقية إصدار Hive المضمن من 1.2 إلى 2.3 الذي يجلب التأثيرات التالية:
- قد تحتاج إلى تعيين spark.sql.hive.metastore.version ووفقا spark.sql.hive.metastore.jars لإصدار Hive metastore الذي تريد الاتصال به. على سبيل المثال: تعيين spark.sql.hive.metastore.version إلى 1.2.1 وإلى mavenspark.sql.hive.metastore.jars إذا كان إصدار Hive metastore هو 1.2.1.
- تحتاج إلى ترحيل SerDes المخصصة إلى Hive 2.3 أو إنشاء Spark الخاص بك مع hive-1.2 ملف التعريف. راجع HIVE-15167 لمزيد من التفاصيل.
- يمكن أن يختلف تمثيل السلسلة العشرية بين Hive 1.2 وHive 2.3 عند استخدام TRANSFORM عامل التشغيل في SQL لتحويل البرنامج النصي، والذي يعتمد على سلوك الخلية. في Hive 1.2، يحذف تمثيل السلسلة الأصفار اللاحقة. ولكن في Hive 2.3، تتم إضافته دائما إلى 18 رقما مع أصفار زائدة إذا لزم الأمر.
- في Databricks Runtime 7.x، عند قراءة جدول Hive SerDe، لا تسمح Spark افتراضيا بقراءة الملفات ضمن دليل فرعي ليس قسم جدول. لتمكينه، قم بتعيين التكوين spark.databricks.io.hive.scanNonpartitionedDirectory.enabled ك true. لا يؤثر هذا على قراء الجدول الأصليين وقارئات الملفات في Spark.

MLlib

OneHotEncoder، الذي تم إهماله في 2.3، تتم إزالته في 3.0 ويتم OneHotEncoderEstimator الآن إعادة تسميته إلى OneHotEncoder.
org.apache.spark.ml.image.ImageSchema.readImages، الذي تم إهماله في 2.3، تتم إزالته في 3.0. استخدم spark.read.format('image') بدلاً من ذلك.
org.apache.spark.mllib.clustering.KMeans.train مع param Int runs، الذي تم إهماله في 2.1، تتم إزالته في 3.0. استخدم أسلوب التدريب بدون تشغيل بدلا من ذلك.
org.apache.spark.mllib.classification.LogisticRegressionWithSGD، الذي تم إهماله في 2.0، تتم إزالته في 3.0، استخدم org.apache.spark.ml.classification.LogisticRegression أو spark.mllib.classification.LogisticRegressionWithLBFGS بدلا من ذلك.
org.apache.spark.mllib.feature.ChiSqSelectorModel.isSorted، الذي تم إهماله في 2.1، تمت إزالته في 3.0، غير مخصص للفئات الفرعية لاستخدامه.
org.apache.spark.mllib.regression.RidgeRegressionWithSGD، الذي تم إهماله في 2.0، تتم إزالته في 3.0. استخدم org.apache.spark.ml.regression.LinearRegression مع elasticNetParam = 0.0. لاحظ أن الافتراضي regParam هو 0.01 ل RidgeRegressionWithSGD، ولكن هو 0.0 ل LinearRegression.
org.apache.spark.mllib.regression.LassoWithSGD، الذي تم إهماله في 2.0، تتم إزالته في 3.0. استخدم org.apache.spark.ml.regression.LinearRegression مع elasticNetParam = 1.0. لاحظ أن الافتراضي regParam هو 0.01 ل LassoWithSGD، ولكن هو 0.0 ل LinearRegression.
org.apache.spark.mllib.regression.LinearRegressionWithSGD، الذي تم إهماله في 2.0، تتم إزالته في 3.0. استخدم org.apache.spark.ml.regression.LinearRegression أو LBFGS بدلا من ذلك.
org.apache.spark.mllib.clustering.KMeans.getRuns و setRuns، التي تم إهمالها في 2.1، تتم إزالتها في 3.0، وليس لها أي تأثير منذ Spark 2.0.0.
org.apache.spark.ml.LinearSVCModel.setWeightCol، الذي تم إهماله في 2.4، تتم إزالته في 3.0، وليس مخصصا للمستخدمين.
في 3.0، org.apache.spark.ml.classification.MultilayerPerceptronClassificationModel يمتد لكشف المعلمات MultilayerPerceptronParams التدريبية. ونتيجة لذلك، layers تم تغيير في MultilayerPerceptronClassificationModel من Array[Int] إلى IntArrayParam. يجب استخدام MultilayerPerceptronClassificationModel.getLayers بدلا من MultilayerPerceptronClassificationModel.layers لاسترداد حجم الطبقات.
org.apache.spark.ml.classification.GBTClassifier.numTrees، الذي تم إهماله في 2.4.5، تتم إزالته في 3.0. استخدم getNumTrees بدلاً من ذلك.
org.apache.spark.ml.clustering.KMeansModel.computeCost، الذي تم إهماله في 2.4، تتم إزالته في 3.0، استخدم ClusteringEvaluator بدلا من ذلك.
تتم إزالة دقة متغير العضو في org.apache.spark.mllib.evaluation.MulticlassMetrics، التي تم إهمالها في 2.0، في 3.0. استخدم الدقة بدلا من ذلك.
تتم إزالة استدعاء متغير العضو في org.apache.spark.mllib.evaluation.MulticlassMetrics، الذي تم إهماله في 2.0، في 3.0. استخدم accuracy بدلاً من ذلك.
تتم إزالة متغير fMeasure العضو في org.apache.spark.mllib.evaluation.MulticlassMetrics، الذي تم إهماله في 2.0، في 3.0. استخدم accuracy بدلاً من ذلك.
org.apache.spark.ml.util.GeneralMLWriter.context، الذي تم إهماله في 2.0، تتم إزالته في 3.0. استخدم session بدلاً من ذلك.
org.apache.spark.ml.util.MLWriter.context، الذي تم إهماله في 2.0، تتم إزالته في 3.0. استخدم session بدلاً من ذلك.
org.apache.spark.ml.util.MLReader.context، الذي تم إهماله في 2.0، تتم إزالته في 3.0. استخدم session بدلاً من ذلك.
abstract class UnaryTransformer[IN, OUT, T <: UnaryTransformer[IN, OUT, T]] تم تغيير إلى abstract class UnaryTransformer[IN: TypeTag, OUT: TypeTag, T <: UnaryTransformer[IN, OUT, T]] في 3.0.
في Spark 3.0، سيرجع LogisticRegressionSummaryالانحدار اللوجستي متعدد الفئات في Pyspark الآن (بشكل صحيح) ، وليس الفئة BinaryLogisticRegressionSummaryالفرعية . لن تعمل الأساليب الإضافية التي كشفها BinaryLogisticRegressionSummary في هذه الحالة على أي حال. (SPARK-31681)
في Spark 3.0، pyspark.ml.param.shared.Has* لا توفر mixins أي set*(self, value) أساليب setter بعد الآن، استخدم كل منها self.set(self.*, value) بدلا من ذلك. راجع SPARK-29093 للحصول على التفاصيل. (SPARK-29093)

تغييرات السلوك الأخرى

تتضمن الترقية إلى Scala 2.12 التغييرات التالية:
- تتم معالجة تسلسل خلية الحزمة بشكل مختلف. يوضح المثال التالي تغيير السلوك وكيفية التعامل معه.
  
  تشغيل foo.bar.MyObjectInPackageCell.run() كما هو محدد في خلية الحزمة التالية سيؤدي إلى ظهور الخطأ java.lang.NoClassDefFoundError: Could not initialize class foo.bar.MyObjectInPackageCell$
```
package foo.bar

case class MyIntStruct(int: Int)

import org.apache.spark.sql.SparkSession
import org.apache.spark.sql.functions._
import org.apache.spark.sql.Column

object MyObjectInPackageCell extends Serializable {

  // Because SparkSession cannot be created in Spark executors,
  // the following line triggers the error
  // Could not initialize class foo.bar.MyObjectInPackageCell$
  val spark = SparkSession.builder.getOrCreate()

  def foo: Int => Option[MyIntStruct] = (x: Int) => Some(MyIntStruct(100))

  val theUDF = udf(foo)

  val df = {
    val myUDFInstance = theUDF(col("id"))
    spark.range(0, 1, 1, 1).withColumn("u", myUDFInstance)
  }

  def run(): Unit = {
    df.collect().foreach(println)
  }
}
```
  للتغلب على هذا الخطأ، يمكنك الالتفاف MyObjectInPackageCell داخل فئة قابلة للتسلسل.
- تتطلب بعض الحالات التي تستخدم DataStreamWriter.foreachBatch تحديث التعليمات البرمجية المصدر. ويرجع هذا التغيير إلى حقيقة أن Scala 2.12 لديه تحويل تلقائي من تعبيرات lambda إلى أنواع SAM ويمكن أن يسبب الغموض.
  
  على سبيل المثال، لا يمكن تحويل التعليمات البرمجية Scala التالية برمجيا:
```
streams
  .writeStream
  .foreachBatch { (df, id) => myFunc(df, id) }
```
  لإصلاح خطأ التحويل البرمجي، قم بالتغيير foreachBatch { (df, id) => myFunc(df, id) } إلى foreachBatch(myFunc _) واجهة برمجة تطبيقات Java أو استخدامها بشكل صريح: foreachBatch(new VoidFunction2 ...).
نظرا لأن إصدار Apache Hive المستخدم لمعالجة الوظائف المعرفة من قبل مستخدم Apache Hive وHive SerDes تتم ترقيته إلى 2.3، يلزم إجراء تغييرين:
- يتم استبدال واجهة Apache Hive SerDe بفئة AbstractSerDeمجردة . بالنسبة إلى أي تطبيق Apache Hive SerDe مخصص، يلزم الترحيل إلى AbstractSerDe .
- الإعداد spark.sql.hive.metastore.jars إلى builtin يعني أنه سيتم استخدام عميل Hive 2.3 metastore للوصول إلى metastores لوقت تشغيل Databricks 7.x. إذا كنت بحاجة إلى الوصول إلى metastores الخارجية المستندة إلى Hive 1.2، فقم بتعيين spark.sql.hive.metastore.jars إلى المجلد الذي يحتوي على جرات Hive 1.2.

الإهمال والإزالة

تم إهمال فهرس تخطي البيانات في Databricks Runtime 4.3 وإزالته في Databricks Runtime 7.x. نوصي باستخدام جداول Delta بدلا من ذلك، والتي توفر قدرات محسنة لتخطي البيانات.
في Databricks Runtime 7.x، يستخدم الإصدار الأساسي من Apache Spark Scala 2.12. نظرا لأن المكتبات المحولة برمجيا مقابل Scala 2.11 يمكنها تعطيل مجموعات Databricks Runtime 7.x بطرق غير متوقعة، فإن المجموعات التي تقوم بتشغيل Databricks Runtime 7.x لا تثبت المكتبات التي تم تكوينها ليتم تثبيتها على جميع المجموعات. تعرض علامة التبويب مكتبات نظام المجموعة حالة Skipped ورسالة إهمال توضح التغييرات في معالجة المكتبة. ومع ذلك، إذا كان لديك نظام مجموعة تم إنشاؤه على إصدار سابق من Databricks Runtime قبل إصدار نظام Azure Databricks الأساسي 3.20 إلى مساحة العمل الخاصة بك، وقمت الآن بتحرير نظام المجموعة هذا لاستخدام Databricks Runtime 7.x، فسيتم تثبيت أي مكتبات تم تكوينها ليتم تثبيتها على جميع المجموعات على نظام المجموعة هذا. في هذه الحالة، يمكن أن تتسبب أي JARs غير متوافقة في المكتبات المثبتة في تعطيل نظام المجموعة. الحل البديل هو إما استنساخ نظام المجموعة أو لإنشاء نظام مجموعة جديد.

مشكلات معروفة

يقوم تحليل يوم السنة باستخدام حرف النمط 'D' بإرجاع النتيجة الخاطئة إذا كان حقل السنة مفقودا. يمكن أن يحدث هذا في دالات SQL مثل to_timestamp التي تحلل سلسلة التاريخ والوقت إلى قيم التاريخ والوقت باستخدام سلسلة نمط. (SPARK-31939)
قد يؤدي الانضمام/النافذة/التجميع داخل الاستعلامات الفرعية إلى نتائج خاطئة إذا كانت المفاتيح تحتوي على قيم -0.0 و0.0. (SPARK-31958)
قد يفشل استعلام النافذة مع حدوث خطأ غامض في الانضمام الذاتي بشكل غير متوقع. (SPARK-31956)
قد لا تتمكن الاستعلامات المتدفقة مع dropDuplicates عامل التشغيل من إعادة التشغيل مع نقطة التحقق المكتوبة بواسطة Spark 2.x. (SPARK-31990)