مستوى التوافق لوظائف Azure Stream Analytics
توضح هذه المقالة خيار مستوى التوافق في Azure Stream Analytics.
Stream Analytics هي خدمة مدارة، مع تحديثات ميزات منتظمة وتحسينات مستمرة في الأداء. يتم توفير معظم تحديثات أوقات تشغيل الخدمة تلقائيًا للمستخدمين النهائيين، بشكل مستقل عن مستوى التوافق. ومع ذلك، عندما تقدم وظيفة جديدة تغييرًا في سلوك الوظائف الحالية، أو تغييرًا في طريقة استهلاك البيانات في تشغيل الوظائف، فإننا نقدم هذا التغيير ضمن مستوى توافق جديد. يمكنك الاحتفاظ بوظائف Stream Analytics الحالية قيد التشغيل دون تغييرات رئيسية عن طريق ترك إعداد مستوى التوافق منخفضًا. عندما تكون مستعدًا لأحدث سلوكيات وقت التشغيل، يمكنك الاشتراك عن طريق رفع مستوى التوافق.
اختيار مستوى توافق
يتحكم مستوى التوافق في سلوك وقت التشغيل لمهمة تحليلات الدفق.
يدعم Azure Stream Analytics حاليًا ثلاثة مستويات توافق:
- 1.2 - أحدث سلوك مع أحدث التحسينات
- 1.1 - السلوك السابق
- 1.0 - مستوى التوافق الأصلي، الذي تم تقديمه أثناء التوفر العام لـAzure Stream Analytics منذ عدة سنوات.
عند إنشاء وظيفة Stream Analytics جديدة، من أفضل الممارسات إنشائها باستخدام أحدث مستوى توافق. ابدأ تصميم وظيفتك بالاعتماد على أحدث السلوكيات، لتجنب التغيير الإضافي والتعقيد لاحقًا.
تعيين مستوى التوافق
يمكنك تعيين مستوى التوافق لوظيفة Stream Analytics في مدخل Microsoft Azure أو باستخدام استدعاء واجهة برمجة تطبيقات REST لمهمة الإنشاء.
لتحديث مستوى توافق المهمة في مدخل Microsoft Azure:
- انتقل إلى مدخل Microsoft Azure لتحديد موقع وظيفة Stream Analytics.
- أوقف المهمة قبل تحديث مستوى التوافق. لا يمكنك تحديث مستوى التوافق إذا كانت وظيفتك في حالة تشغيل.
- ضمن عنوان تكوين، حدد مستوى التوافق.
- اختر قيمة مستوى التوافق التي تريدها.
- حدد حفظ في أسفل الصفحة.
عند تحديث مستوى التوافق، يتحقق المحول البرمجي T من صحة المهمة باستخدام بناء الجملة الذي يتوافق مع مستوى التوافق المحدد.
مستوى التوافق 1.2
يتم إدخال التغييرات الرئيسية التالية في مستوى التوافق 1.2:
بروتوكول مراسلة AMQP
مستوى 1.2: يستخدم Azure Stream Analytics بروتوكول المراسلة المتقدم لبروتوكول وضع الرسائل في قائمة انتظار (AMQP) للكتابة إلى قوائم انتظار وموضوعات ناقل الخدمة. يمكّنك AMQP من إنشاء تطبيقات مختلطة عبر الأنظمة الأساسية باستخدام بروتوكول قياسي مفتوح.
دوال مكانية
المستويات السابقة: استخدمت Azure Stream Analytics حسابات الجغرافيا.
مستوى 1.2: يسمح لك Azure Stream Analytics بحساب الإحداثيات الجغرافية الهندسية المتوقعة. لا يوجد تغيير في توقيع الدوال الجغرافية المكانية. ومع ذلك، فإن دلالاتها مختلفة قليلًا، ما يسمح بالحساب أكثر دقة من ذي قبل.
يدعم Azure Stream Analytics فهرسة البيانات المرجعية الجغرافية المكانية. يمكن فهرسة البيانات المرجعية التي تحتوي على عناصر جغرافية مكانية لحساب انضمام أسرع.
توفر الوظائف الجغرافية المكانية المحدثة التعبير الكامل للتنسيق الجغرافي المكاني للنص المعروف (WKT). يمكنك تحديد المكونات الجغرافية المكانية الأخرى التي لم تكن مدعومة مسبقًا مع GeoJson.
لمزيد من المعلومات، راجع التحديثات إلى الميزات الجغرافية المكانية في Azure Stream Analytics - السحابة وIoT Edge.
تنفيذ الاستعلام المتوازي لمصادر الإدخال ذات أقسام متعددة
المستويات السابقة: تتطلب استعلامات Azure Stream Analytics استخدام عبارة PARTITION BY لموازاة معالجة الاستعلام عبر أقسام مصدر الإدخال.
مستوى 1.2: إذا كان منطق الاستعلام يمكن موازاته عبر أقسام مصدر الإدخال، فإن Azure Stream Analytics ينشئ مثيلات استعلام منفصلة ويشغل الحسابات بالتوازي.
تكامل واجهة برمجة التطبيقات المجمعة الأصلية مع إخراج Azure Cosmos DB
المستويات السابقة: تم إدراج سلوك upsert أو دمجه.
مستوى 1.2: يعمل تكامل واجهة برمجة التطبيقات المجمعة الأصلية مع إخراج Azure Cosmos DB على زيادة معدل النقل إلى أقصى حد ومعالجة طلبات التقييد بكفاءة. لمزيد من المعلومات، راجع إخراج Azure Stream Analytics إلى صفحة Azure Cosmos DB.
سلوك upsert هو إدراج أو استبدال.
DateTimeOffset عند الكتابة إلى إخراج SQL
المستويات السابقة: تم تعديل أنواع DateTimeOffset إلى UTC.
مستوى 1.2: لم يعد DateTimeOffset معدلًا.
طويل عند الكتابة إلى إخراج SQL
المستويات السابقة: تم اقتطاع القيم استنادًا إلى النوع الهدف.
مستوى 1.2: تتم معالجة القيم التي لا تتناسب مع النوع الهدف وفقًا لنهج خطأ الإخراج.
تسلسل السجل والصفيف عند الكتابة إلى إخراج SQL
المستويات السابقة: تمت كتابة السجلات كـ"سجل" وتمت كتابة الصفائف كـ"صفيف".
مستوى 1.2: يتم تسلسل السجلات والصفائف بتنسيق JSON.
التحقق الصارم من صحة بادئة الدالات
المستويات السابقة: لم يكن هناك تحقق صارم من صحة بادئات الدالة.
مستوى 1.2: يحتوي Azure Stream Analytics على تحقق صارم من صحة بادئات الوظائف. تؤدي إضافة بادئة إلى دالة مضمنة إلى حدوث خطأ. على سبيل المثال، myprefix.ABS(…) غير مدعوم.
تؤدي إضافة بادئة إلى التجميعات المضمنة أيضًا إلى حدوث خطأ. على سبيل المثال، myprefix.SUM(…) غير مدعوم.
يؤدي استخدام البادئة "النظام" لأي وظائف معرفة من قبل المستخدم إلى حدوث خطأ.
عدم السماح بالصفيف والكائن كخصائص رئيسية في محول إخراج Azure Cosmos DB
المستويات السابقة: تم دعم أنواع الصفيف والكائنات كخاصية مفتاح.
مستوى 1.2: لم تعد أنواع الصفيف والكائنات مدعومة كخاصية مفتاح.
إلغاء تسلسل النوع المنطقي في JSON وAVRO وPARQUET
المستويات السابقة: تعمل Azure Stream Analytics على إلغاء تسلسل القيمة المنطقية في النوع BIGINT - خرائط خاطئة إلى 0 والخرائط الحقيقية إلى 1. ينشئ الإخراج قيما منطقية فقط في JSON وAVRO وPARQUET إذا قمت بتحويل الأحداث بشكل صريح إلى BIT.
على سبيل المثال، سيكتب استعلام تمرير مثل SELECT value INTO output1 FROM input1 قراءة JSON { "value": true } من input1 في output1 قيمة { "value": 1 }JSON .
مستوى 1.2: إلغاء تسلسل Azure Stream Analytics القيمة المنطقية في نوع BIT. تعيينات خاطئة إلى 0 وخرائط صحيحة إلى 1. سيكتب استعلام تمرير مثل SELECT value INTO output1 FROM input1 قراءة JSON { "value": true } من input1 في output1 قيمة { "value": true }JSON . يمكنك تحويل القيمة لكتابة BIT في الاستعلام للتأكد من ظهورها على أنها صحيحة وخطأ في الإخراج للتنسيقات التي تدعم النوع المنطقي.
مستوى التوافق 1.1
يتم إدخال التغييرات الرئيسية التالية في مستوى التوافق 1.1:
تنسيق XML لناقل خدمة Microsoft Azure
مستوى 1.0: استخدم Azure Stream Analytics DataContractSerializer، لذا تضمن محتوى الرسالة علامات XML. على سبيل المثال:
@\u0006string\b3http://schemas.microsoft.com/2003/10/Serialization/\u0001{ "SensorId":"1", "Temperature":64\}\u0001
مستوى 1.1: يحتوي محتوى الرسالة على الدفق مباشرة بدون علامات إضافية. على سبيل المثال: { "SensorId":"1", "Temperature":64}
استمرار حساسية حالة الأحرف لأسماء الحقول
مستوى 1.0: تم تغيير أسماء الحقول إلى حالة أقل عند معالجتها بواسطة محرك Azure Stream Analytics.
مستوى 1.1: تستمر حساسية حالة الأحرف لأسماء الحقول عند معالجتها بواسطة محرك Azure Stream Analytics.
إشعار
لا تتوفر حساسية حالة الأحرف المستمرة بعد لمهام Stream Analytic المستضافة باستخدام بيئة Edge. ونتيجة لذلك، يتم تحويل جميع أسماء الحقول إلى أحرف صغيرة إذا تمت استضافة وظيفتك على Edge.
FloatNaNDeserializationDisabled
مستوى 1.0: لم يقم الأمر CREATE TABLE بتصفية الأحداث باستخدام NaN (Not-a-Number. على سبيل المثال، Infinity، -Infinity) في نوع عمود FLOAT لأنها خارج النطاق الموثق لهذه الأرقام.
مستوى 1.1: يتيح لك CREATE TABLE تحديد مخطط قوي. يتحقق محرك Stream Analytics من أن البيانات تتوافق مع هذا المخطط. باستخدام هذا النموذج، يمكن للأمر تصفية الأحداث بقيم NaN.
تعطيل التحويل التلقائي لسلاسل التاريخ والوقت إلى نوع DateTime عند الدخول لـJSON
مستوى 1.0: سيقوم محلل JSON تلقائيا بتحويل قيم السلسلة بمعلومات التاريخ/الوقت/المنطقة إلى نوع DATETIME عند الدخول بحيث تفقد القيمة على الفور معلومات التنسيق والزون الزمني الأصلية الخاصة بها. نظرًا لأن هذا يتم عند الدخول، حتى إذا لم يتم استخدام هذا الحقل في الاستعلام، يتم تحويله إلى UTC DateTime.
مستوى 1.1: لا يوجد تحويل تلقائي لقيم السلسلة بمعلومات التاريخ/الوقت/المنطقة إلى نوع DATETIME. ونتيجة لذلك، يتم الاحتفاظ بمعلومات المنطقة الزمنية والتنسيق الأصلي. ومع ذلك، إذا تم استخدام الحقل NVARCHAR(MAX) في الاستعلام كجزء من تعبير DATETIME (الدالة DATEADD، على سبيل المثال)، يتم تحويله إلى نوع DATETIME لإجراء الحساب ويفقد نموذجه الأصلي.