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 runtimes-uppdateringar 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 under 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 beteendet med de senaste förbättringarna
- 1.1 – Tidigare beteende
- 1.0 – Ursprunglig kompatibilitetsnivå som introducerades under den allmänna tillgängligheten 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-portalen eller med hjälp av REST API-anropet för att skapa jobb.
Så här uppdaterar du kompatibilitetsnivån för jobbet i Azure-portalen:
- Använd Azure-portalen för att hitta till ditt Stream Analytics-jobb.
- Stoppa jobbet innan du uppdaterar kompatibilitetsnivån. Du kan inte uppdatera kompatibilitetsnivån om jobbet är i ett körningstillstånd.
- Under rubriken Konfigurera väljer du Kompatibilitetsnivå.
- Välj det kompatibilitetsnivåvärde som du vill använda.
- 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 införs 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
Tidigare nivåer: Azure Stream Analytics använde geografiska beräkningar.
1.2-nivå: Med Azure Stream Analytics kan du beräkna geometriska beräknade geokoordinater. Det finns ingen ändring i signaturen för geospatiala funktioner. Deras semantik är dock något annorlunda, vilket ger mer exakt beräkning än tidigare.
Azure Stream Analytics stöder geospatial referensdataindexering. Referensdata som innehåller geospatiala element kan indexeras för en snabbare kopplingsberäkning.
De uppdaterade geospatiala funktionerna ger fullständig uttrycksfullhet i geospatialt format med välkänd text (WKT). Du kan ange andra geospatiala komponenter som inte tidigare stöddes med GeoJson.
Mer information finns i Uppdateringar av geospatiala funktioner i Azure Stream Analytics – Cloud och IoT Edge.
Parallell frågekörning för indatakällor med flera partitioner
Tidigare nivåer: Azure Stream Analytics-frågor krävde användning av PARTITION BY-satsen för att parallellisera frågebearbetning mellan indatakällapartitioner.
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
Tidigare nivåer: Upsert-beteendet var infogning eller sammanslagning.
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 när du skriver 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
Tidigare 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 när du skriver till SQL-utdata
Tidigare nivåer: Poster skrevs som "Record" och matriser skrevs som "Matris".
1.2-nivå: Poster och matriser serialiseras i JSON-format.
Strikt validering av prefix för funktioner
Tidigare 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. Till exempelmyprefix.ABS(…) stöds inte.
Att lägga till ett prefix i inbyggda aggregeringar resulterar också i fel. Till exempel myprefix.SUM(…) stöds inte.
Om du använder prefixet "system" för alla användardefinierade funktioner resulterar det i fel.
Tillåt inte matris och objekt som nyckelegenskaper i Azure Cosmos DB-utdatakort
Tidigare nivåer: Matris- och objekttyper stöds som en nyckelegenskap.
1.2-nivå: Matris- och objekttyper stöds inte längre som en nyckelegenskap.
Deserialisera boolesk typ i JSON, AVRO och PARQUET
Tidigare 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.
Till exempel skriver en direktfråga som SELECT value INTO output1 FROM input1 att läsa en JSON { "value": true } från input1 till output1 ett JSON-värde { "value": 1 }.
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 till utdata1 ett JSON-värde { "value": true }. Du kan casta värde för att skriva BIT i frågan för att säkerställa att de visas som sanna och falska i utdata för format som stöder boolesk typ.
Kompatibilitetsnivå 1.1
Följande större ändringar införs i kompatibilitetsnivå 1.1:
Service Bus XML-format
1.0-nivå: Azure Stream Analytics använde DataContractSerializer, så meddelandeinnehållet innehöll XML-taggar. Till 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. Till exempel: { "SensorId":"1", "Temperature":64}
Bevara skiftlägeskänslighet för fältnamn
1.0-nivå: Fältnamn ändrades till gemener när de bearbetades av Azure Stream Analytics-motorn.
1.1-nivå: Skiftlägeskänslighet sparas för fältnamn när de bearbetas av Azure Stream Analytics-motorn.
Kommentar
Beständig skiftlägeskänslighet är ännu inte tillgängligt för Stream Analys-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 datum-/tidszonsinformation 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 fältet inte användes i frågan.
1.1-nivå: Det finns ingen automatisk konvertering av strängvärden med datum/tid/zoninformation 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 (DATEADD-funktion, till exempel), konverteras det till DATETIME-typ för att utföra beräkningen och den förlorar sitt ursprungliga formulär.
Nästa steg
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för