Kompatibilitetsnivå för Azure Stream Analytics-jobb
I den här artikeln beskrivs alternativet för kompatibilitetsnivå i Azure Stream Analytics.
Stream Analytics är en hanterad tjänst med regelbundna funktionsuppdateringar och ständiga prestandaförbättringar. De flesta av tjänstens körningsuppdateringar görs automatiskt tillgängliga för slutanvändare, oberoende av kompatibilitetsnivån. Men när en ny funktion introducerar en ändring i beteendet för befintliga jobb, eller en ändring i hur data förbrukas i jobb som körs, introducerar vi den här ändringen på en ny kompatibilitetsnivå. Du kan hålla dina befintliga Stream Analytics-jobb igång utan större ändringar genom att låta inställningen för kompatibilitetsnivå sänkas. När du är redo för de senaste körningsbeteendena kan du anmäla dig genom att höja kompatibilitetsnivån.
Välj en kompatibilitetsnivå
Kompatibilitetsnivån styr körningsbeteendet för ett Stream Analytics-jobb.
Azure Stream Analytics stöder för närvarande tre kompatibilitetsnivåer:
- 1.2 – Senaste beteende med de senaste förbättringarna
- 1.1 – Tidigare beteende
- 1.0 – Ursprunglig kompatibilitetsnivå som introducerades vid allmän tillgänglighet för Azure Stream Analytics för flera år sedan.
När du skapar ett nytt Stream Analytics-jobb är det bästa praxis att skapa det med hjälp av den senaste kompatibilitetsnivån. Starta din jobbdesign och förlita dig på de senaste beteendena för att undvika ytterligare ändringar och komplexitet senare.
Ange kompatibilitetsnivå
Du kan ange kompatibilitetsnivån för ett Stream Analytics-jobb i Azure Portal eller genom att använda REST API-anropet för att skapa jobb.
Så här uppdaterar du kompatibilitetsnivån för jobbet i Azure Portal:
- Använd Azure Portal för att hitta till Stream Analytics-jobbet.
- Stoppa jobbet innan du uppdaterar kompatibilitetsnivån. Du kan inte uppdatera kompatibilitetsnivån om jobbet körs.
- Under rubriken Konfigurera väljer du Kompatibilitetsnivå.
- Välj önskat kompatibilitetsnivåvärde.
- Välj Spara längst ned på sidan.
När du uppdaterar kompatibilitetsnivån validerar T-kompilatorn jobbet med den syntax som motsvarar den valda kompatibilitetsnivån.
Kompatibilitetsnivå 1.2
Följande större ändringar introduceras i kompatibilitetsnivå 1.2:
AMQP-meddelandeprotokoll
1.2-nivå: Azure Stream Analytics använder meddelandeprotokollet Advanced Message Queueing Protocol (AMQP) för att skriva till Service Bus-köer och -ämnen. Med AMQP kan du skapa plattformsoberoende hybridprogram med hjälp av ett öppet standardprotokoll.
Geospatiala funktioner
Föregående nivåer: Azure Stream Analytics använde geografiska beräkningar.
1.2-nivå: Med Azure Stream Analytics kan du beräkna geometriska geokoordinater. Signaturen för geospatiala funktioner ändras inte. Deras semantik är dock något annorlunda, vilket möjliggör mer exakt beräkning än tidigare.
Azure Stream Analytics stöder geospatial referensdataindexering. Referensdata som innehåller geospatiala element kan indexeras för snabbare kopplingsberäkning.
De uppdaterade geospatiala funktionerna ger fullständig uttrycksfullhet i geospatialt WKT-format (Well Known Text). Du kan ange andra geospatiala komponenter som inte tidigare hade stöd med GeoJson.
Mer information finns i Uppdateringar till geospatiala funktioner i Azure Stream Analytics – moln och IoT Edge.
Parallell frågekörning för indatakällor med flera partitioner
Föregående nivåer: Azure Stream Analytics-frågor krävde användning av PARTITION BY-satsen för att parallellisera frågebearbetningen mellan indatakällans partitioner.
1.2-nivå: Om frågelogik kan parallelliseras mellan indatakällpartitioner skapar Azure Stream Analytics separata frågeinstanser och kör beräkningar parallellt.
Intern mass-API-integrering med Azure Cosmos DB-utdata
Föregående nivåer: Upsert-beteendet var infoga eller sammanfoga.
1.2-nivå: Intern mass-API-integrering med Azure Cosmos DB-utdata maximerar dataflödet och hanterar effektivt begränsningsbegäranden. Mer information finns på sidan Azure Stream Analytics-utdata till Azure Cosmos DB.
Upsert-beteendet är infoga eller ersätt.
DateTimeOffset vid skrivning till SQL-utdata
Tidigare nivåer:DateTimeOffset-typer justerades till UTC.
1.2-nivå: DateTimeOffset justeras inte längre.
Lång tid vid skrivning till SQL-utdata
Föregående nivåer: Värdena trunkerades baserat på måltypen.
1.2-nivå: Värden som inte passar in i måltypen hanteras enligt principen för utdatafel.
Post- och matrisserialisering vid skrivning till SQL-utdata
Föregående nivåer: Poster skrevs som "Record" och matriser skrevs som "Array".
1.2-nivå: Poster och matriser serialiseras i JSON-format.
Strikt validering av prefix för funktioner
Föregående nivåer: Det fanns ingen strikt validering av funktionsprefix.
1.2-nivå: Azure Stream Analytics har en strikt validering av funktionsprefix. Att lägga till ett prefix i en inbyggd funktion orsakar ett fel. Stöds till exempelmyprefix.ABS(…) inte.
Att lägga till ett prefix i inbyggda aggregeringar resulterar också i fel. Stöds till exempel myprefix.SUM(…) inte.
Om du använder prefixet "system" för användardefinierade funktioner resulterar det i fel.
Tillåt inte matris- och objektegenskaper som nyckelegenskaper i Azure Cosmos DB-utdatakort
Föregående nivåer: Matris- och objekttyper stöds som en nyckelegenskap.
1.2-nivå: Matris- och objekttyper stöds inte längre som en nyckelegenskap.
Avserialisera boolesk typ i JSON, AVRO och PARQUET
Föregående nivåer: Azure Stream Analytics deserialiserar booleskt värde till typen BIGINT – falska kartor till 0 och sanna kartor till 1. Utdata skapar endast booleska värden i JSON, AVRO och PARQUET om du uttryckligen konverterar händelser till BIT.
En direktfråga som SELECT value INTO output1 FROM input1 att läsa en JSON { "value": true } från input1 skriver till exempel ett JSON-värde { "value": 1 }till output1.
1.2-nivå: Azure Stream Analytics deserialiserar booleskt värde till typen BIT. Falska kartor till 0 och sanna kartor till 1. En direktfråga som SELECT value INTO output1 FROM input1 att läsa en JSON { "value": true } från input1 skriver ett JSON-värde { "value": true }till output1. Du kan omvandla värde för att skriva BIT i frågan för att säkerställa att de visas som sant och falskt i utdata för format som stöder boolesk typ.
Kompatibilitetsnivå 1.1
Följande större ändringar introduceras i kompatibilitetsnivå 1.1:
Service Bus XML-format
1.0-nivå: Azure Stream Analytics använde DataContractSerializer, så meddelandeinnehållet innehöll XML-taggar. Exempel:
@\u0006string\b3http://schemas.microsoft.com/2003/10/Serialization/\u0001{ "SensorId":"1", "Temperature":64\}\u0001
1.1-nivå: Meddelandeinnehållet innehåller strömmen direkt utan ytterligare taggar. Exempelvis: { "SensorId":"1", "Temperature":64}
Bevara skiftlägeskänslighet för fältnamn
1.0-nivå: Fältnamnen ändrades till gemener när de bearbetades av Azure Stream Analytics-motorn.
1.1-nivå: Skiftlägeskänslighet bevaras för fältnamn när de bearbetas av Azure Stream Analytics-motorn.
Anteckning
Beständig skiftlägeskänslighet är ännu inte tillgängligt för Stream Analytics-jobb som hanteras med hjälp av Edge-miljön. Därför konverteras alla fältnamn till gemener om jobbet finns på Edge.
FloatNaNDeserializationDisabled
1.0-nivå: KOMMANDOT CREATE TABLE filtrerade inte händelser med NaN (inte ett tal. Till exempel Infinity, -Infinity) i en FLOAT-kolumntyp eftersom de ligger inom det dokumenterade intervallet för dessa tal.
1.1-nivå: MED CREATE TABLE kan du ange ett starkt schema. Stream Analytics-motorn verifierar att data överensstämmer med det här schemat. Med den här modellen kan kommandot filtrera händelser med NaN-värden.
Inaktivera automatisk konvertering av datetime-strängar till DateTime-typ vid ingress för JSON
1.0-nivå: JSON-parsern konverterar automatiskt strängvärden med information om datum/tid/zon till DATETIME-typ vid ingress så att värdet omedelbart förlorar sin ursprungliga formatering och tidszonsinformation. Eftersom detta görs vid ingress konverteras det till UTC DateTime även om det fältet inte användes i frågan.
1.1-nivå: Det finns ingen automatisk konvertering av strängvärden med information om datum/tid/zon till DATETIME-typ. Därför behålls tidszonsinformation och ursprunglig formatering. Men om fältet NVARCHAR(MAX) används i frågan som en del av ett DATETIME-uttryck (till exempel funktionen DATEADD), konverteras det till DATETIME-typ för att utföra beräkningen och det förlorar sitt ursprungliga formulär.