Vad är Infrastrukturaktivator? Omvandla dataströmmar till automatiserade åtgärder

Fabric Activator är en händelseidentifieringsmotor utan kod och låg latens som automatiskt utlöser åtgärder när specifika mönster eller villkor identifieras i datakällor. Viktiga funktioner är:

Den övervakar kontinuerligt dessa datakällor med svarstid på undersekunder och initierar åtgärder när tröskelvärden uppfylls eller specifika mönster identifieras. Dessa åtgärder kan omfatta att skicka e-postmeddelanden eller Teams-meddelanden, starta Power Automate-flöden eller integrera med tredjepartssystem.

Kärnarkitektur

Activator är händelseidentifierings- och regelmotorn i hjärtat av Fabric Real-Time intelligensstacken. Arkitektoniskt fungerar den som en intelligent observatör – använder dataströmmar med hög hastighet, utvärderar regelvillkor nästan i realtid och initierar automatiserade nedströmsåtgärder baserat på ändringar i händelsetillstånd.

Den passar in i en reaktiv, händelsedriven arkitektur där data flödar kontinuerligt och beslut fattas baserat på tillståndskänsliga utvärderingar av händelsedata nästan i realtid.

• Händelsekällor

  Aktivator ansluter direkt till eventstreams, som matar in data från olika producenter (Azure Event Hubs, IoT-enheter, anpassad slutpunkt osv.). Dessa strömmar fungerar som källa för händelser, och Activator kan prenumerera på en eller flera händelseströmmar för att observera dataändringar. Andra händelsekällor kan vara Fabric- eller Azure-händelser eller en Aktivator som lyssnar på en Power BI-rapport eller en Real-Time instrumentpanel.

• Händelser och objekt

  Händelser är enskilda poster (till exempel en telemetrisignal eller en filhämtning) som tas emot via eventstream. Dessa händelser grupperas i objekt baserat på en delad identifierare (till exempel bikepoint_id, device_id). Regler utvärderas sedan per objekt, vilket möjliggör detaljerad identifiering (till exempel per sensor eller per tillgång).

• Regler och villkor

  Varje aktivator innehåller en eller flera regler som utvärderas kontinuerligt. Dessa regler kan vara enkla jämförelser (value < threshold) eller tillståndskänsliga uttryck som BECOMES, DECREASES, INCREASES, EXIT RANGEeller avsaknad av data (pulsslag). Aktivator säkerställer tillståndsspårning per objekt, vilket möjliggör komplex mönsteridentifiering över tid.

• Åtgärder

  När ett regelvillkor är uppfyllt kan Activator utlösa:

  • pipelines, anteckningsbok eller spark-jobbdefinition i Fabric.

    • Externa åtgärder via Power Automate.
    • Skicka Teams-meddelande till en individ, grupp eller kanal
    • Skicka e-post

• Aviseringshantering och regeltestning

  Activator tillhandahåller förhandsgranskning och effektuppskattningar innan regler aktiveras, vilket visar hur ofta en regel skulle ha utlösts på historiska data. De här funktionerna hjälper till att förhindra skräppost och överaktivering av aviseringar. Internt hanteras tillståndsövergångar för att förhindra brus (till exempel måste ett värde överskrida ett tröskelvärde, inte bara förbli under det).

• Övervakning och kostnadskontroll

  Du får bara kostnader när aktivatorer körs aktivt. Aktivatorinstanser är begränsade till Fabrickapaciteter och kan övervakas genom arbetsytan. Körningsloggar och telemetri är tillgängliga via händelseströmmar och pipeline-utgångar.

Distributionsmodell

Aktivatorinstanser distribueras per arbetsyta och binds till specifika datakällor. Flera aktivatorer kan övervaka samma ström, vilket möjliggör parallella regelutvärderingar för distinkta affärsfunktioner. Eftersom aktiveraren är kapacitetsbegränsad gäller prissättning enligt användning endast när regler körs aktivt, vilket ger kostnadseffektivitet för sporadiska detekteringsscenarier.

Integreringspunkter inom Real-Time intelligens

Aktivator som orkestrerare

Effektiv användning av Activator i realtidsarkitekturer i företagsklass kräver avsiktlig orkestrering mellan Microsoft Fabric-komponenter och prestandajustering för händelsevolym, objekt kardinalitet och regelkomplexitet. I det här avsnittet beskrivs hur du samordnar Activator med andra tjänster och hur du optimerar identifieringslogik och körningsbeteende för att stödja låg latens, kostnadseffektiv automatisering i stor skala.

Activator spelar en central roll i händelsedrivna pipelines genom att utvärdera data vid ankomstpunkten och utlösa åtgärder nedströms. Vanliga orkestreringsmönster är:

Huvudkoncept

Microsoft Fabric Activator fungerar som en högpresterande, tillståndsmedveten regelmotor som är utformad för utvärdering av strömningshändelser med låg latens. I grunden bearbetar Activator realtidshändelser som genereras via händelseström, utvärderar regelvillkor per logiskt objekt och initierar nedströmsåtgärder som svar på tillståndsövergångar. En översikt över Fabric Activator finns i Introduktion till Fabric Activator.

Följande begrepp används för att skapa och utlösa automatiserade åtgärder och svar i Fabric Activator.

Händelsekällor och händelser

Fabric Activator behandlar alla datakällor som strömmar av händelser. En händelse representerar en observation om tillståndet för ett objekt och innehåller vanligtvis en identifierare för objektet, en tidsstämpel och värden för de fält som övervakas.

Händelser som matas in i Activator kommer från:

• Eventstream, som stöder flera överordnade källor (till exempel Azure Event Hubs, IoT Hub, Blob Storage-utlösare). En Eventstream är en specifik objekttyp i Microsoft Fabric, som gör att du kan mata in, transformera och dirigera realtidshändelser utan att skriva någon kod. Fabric Activator övervakar händelseströmmen och vidtar automatiskt åtgärder när definierade mönster eller tröskelvärden identifieras. Activator kan också prenumerera på två eller flera eventstreams för att observera dataändringar. Händelseströmmar varierar i frekvens. Till exempel genererar IoT-sensorer händelser flera gånger per sekund och logistiksystem genererar händelser sporadiskt, till exempel när paket genomsöks på leveransplatser.
• Nätverkshändelser. Exempelvis är objekthändelser för Fabric-arbetsytan diskreta Fabric-händelser som inträffar när ändringar görs i din Fabric-arbetsyta. Dessa ändringar omfattar att skapa, uppdatera eller ta bort ett objekt i Fabric.
• Azure-händelser. Azure Blob Storage-händelser utlöses till exempel när en klient skapar, ersätter, tar bort en blob osv.
• Power BI-rapport. I det här fallet är händelser periodiska observationer baserat på uppdateringsschemat för en Power BI-semantisk modell (kallades tidigare en datauppsättning). Dessa observationer kan inträffa dagligen eller varje vecka, vilket utgör en långsam händelseström.
• Infrastrukturresurser Real-Time instrumentpanel.

Varje händelse innehåller:

• En tidsstämpel
• En nyttolast (strukturerade eller halvstrukturerade data)
• Ett eller flera attribut som används för objektidentifiering (till exempel device_id, bikepoint_id)

Objekt

I Fabric Activator kallas de entiteter som du övervakar affärsobjekt, som kan vara antingen fysiska eller konceptuella. Exempel är fysiska objekt som frysar, fordon, paket och användare samt konceptuella objekt som reklamkampanjer, kundkonton, användarsessioner.

Om du vill modellera ett affärsobjekt i Activator ansluter du en eller flera händelseström, väljer en kolumn som ska fungera som objekt-ID och anger de fält som du vill behandla som egenskaper för objektet.

Termen objektinstans refererar till ett specifikt exempel på ett affärsobjekt, till exempel en viss frys, ett fordon eller en användarsession. Däremot refererar objektet vanligtvis till den allmänna definitionen eller klassen (till exempel frys som en typ). Termen population används för den fullständiga uppsättningen objektinstanser som övervakas.

Objektskapandet är implicit: Aktiveraren grupperar händelser med hjälp av en angiven objektnyckel. Regler är begränsade till objekt, vilket innebär att all utvärderingslogik är objektmedveten och oberoende mellan instanser. En regelövervakning bikepoint_id skapar till exempel distinkta logiska utvärderingar för varje unik cykelstation.

Regler

Regler definierar de villkor som du vill identifiera för dina objekt och vilka åtgärder som ska utföras när dessa villkor uppfylls. En regel för ett frysobjekt kan till exempel identifiera när temperaturen stiger över ett säkert tröskelvärde och automatiskt skicka en e-postavisering till den tilldelade teknikern.

Regler i Activator kan vara tillståndslösa eller tillståndskänsliga:

• Tillståndslösa regler utvärderar varje händelse isolerat (till exempel värde < 50).
• Tillståndskänsliga regler underhåller minne mellan händelser per objekt (till exempel värde minskar, blir, lämnar området)

Tillståndsbaserad utvärdering bygger på:

• Deltaidentifiering: Spårar ändringar mellan tidigare och aktuella händelsevärden.
• Temporal sekvensering: Utvärderar tidsbaserade villkor som frånvaro av händelser (pulsslagsidentifiering)
• Tillståndsövergångar: Regler utlöses endast vid inträde i ett nytt tillstånd, vilket förhindrar upprepade utlösningar under oförändrade förhållanden

Varje regelvillkor kompileras till ett körningsdiagram som utvärderas kontinuerligt, minnesinternt och nästan omedelbart. Systemet är optimerat för beslutsfattande latens på under en sekund efter mottagande av händelse.

Åtgärder

När en regels villkor uppfylls och en åtgärd initieras, sägs regeln vara aktiverad. De mål som stöds för åtgärder är:

• Dataflödesväv (för dataflytt, berikning)
• Tyganteckningsböcker (för maskininlärningsbedömning, diagnostik)
• Power Automate-flöden (för affärsprocessintegrering)
• Teams-meddelanden (med mallbaserade meddelanden)

Aktivator genererar ett utlösarmeddelande med aktuellt objekttillstånd och regelmetadata, och åtgärder är icke-blockering, det vill säga och Activator väntar inte på att åtgärderna ska slutföras för att aktivera skalbara asynkrona flöden.

Egenskaper

Egenskaper är specifika fält eller attribut för ett affärsobjekt som du vill övervaka. Dessa kan vara fysiska eller konceptuella egenskaper, till exempel:

• Temperatur av ett paket
• Status för en leverans
• Saldo för ett kundkonto
• Engagemangspoäng för en användarsession

De härleds från händelseströmmar, som är kontinuerliga dataflöden från källor som IoT-sensorer, Power BI-rapporter eller andra system.

När du definierar ett affärsobjekt i Activator ansluter du en eller flera händelseströmmar, väljer en kolumn som ska fungera som objekt-ID och väljer andra kolumner som ska behandlas som egenskaper för objektet. Du kan skapa regler för dessa egenskaper för att spåra ändringar över tid, identifiera när en egenskap överskrider ett tröskelvärde eller faller utanför ett intervall eller utlösa åtgärder som aviseringar, arbetsflöden eller meddelanden.

Egenskaper är också användbara när du vill återanvända logik i flera regler. På ett frysobjekt kan du till exempel definiera en egenskap som beräknar ett temperaturgenomsnitt under en entimmesperiod. När den har definierats kan den här egenskapen refereras till i flera regler, till exempel de som identifierar överhettning, temperaturfluktuationer eller underhållströsklar – utan att duplicera logiken. Genom att centralisera logiken i egenskaper gör du dina regler enklare att hantera, mer konsekventa och enklare att uppdatera över tid.

Återblicksperiod

Lookback-perioden syftar på tidsperioden av historiska data som Activator analyserar för att bedöma en regel. Det säkerställer att tillräckligt med tidigare data är tillgängliga för att korrekt identifiera mönster eller beräkningsaggregeringar som medelvärden, även om data kommer sent eller oregelbundet.

Tillbakablicksperioden bestäms av:

• Hur regeln definieras, till exempel om den kräver analys av trender, identifiering av avvikelser eller jämförelse av värden över tid.
• Volymen inkommande data, till exempel antalet händelser per sekund i händelseströmmen.

Överväg en läkemedelslogistik som transporterar läkemedelspaket i en kall kedja. Målet är att få en avisering när ett paket blir för varmt.

Anta att regeln har definierats för att:

• Utvärdera genomsnittstemperaturen för varje paket under ett tretimmarsfönster
• Utlös en avisering om medeltemperaturen överstiger 8°C

För att beräkna den här regeln korrekt måste Fabric Activator analysera ett bredare fönster med historiska data, särskilt en sex timmars återställningsperiod. Det säkerställer att tillräckligt med data är tillgängliga för att beräkna genomsnittet på tre timmar vid en tidpunkt, även om data kommer med viss fördröjning eller oregelbundenhet.

Återställningsperioden är viktig för att möjliggöra snabb och korrekt identifiering av villkor, särskilt i scenarier där datamönster utvecklas över tid.

Distinkta, aktiva objekt-ID:t

Regler som bygger på attribut används för att övervaka hur specifika attribut för ett objekt ändras över tid. I exemplet med läkemedelslogistik representeras varje medicinpaket av ett unikt objekt-ID och systemet får periodiska temperaturavläsningar för varje paket.

För att effektivt utvärdera dessa regler spårar Fabric Activator aktiva objekt-ID:er, dvs. objekt för vilka händelser anländer inom den definierade återställningsperioden. Det här beteendet säkerställer att endast relevanta, aktiva objekt beaktas när regler tillämpas.

Till exempel kan en avgiftsbelagd station spåra fordon (objekt-ID: er) när de passerar. Varje fordon genererar händelser (till exempel in- och utgående genomsökningar), och endast de objekt med den senaste aktiviteten anses vara aktiva och utvärderas av systemet.

Det finns också gränser baserat på antalet distinkta objekt-ID:er (antal paket) som spåras i lookback-fönstret.

Vanliga användningsfall

Här följer några verkliga scenarier där du kan använda Fabric Activator:

• Starta annonskampanjer automatiskt när försäljningen i samma butik minskar, vilket ökar prestandan på underpresterande platser.
• Meddela livsmedelsbutikscheferna att flytta mat från felaktiga frysar innan förstöring sker.
• Utlösa anpassade arbetsflöden för uppsökande verksamhet när en kunds resa mellan appar, webbplatser eller andra beröringspunkter indikerar en negativ upplevelse.
• Initiera proaktivt undersökningsarbetsflöden när en leveranss status inte uppdaterades inom en definierad tidsram, vilket hjälper till att hitta förlorade paket snabbare.
• Meddela kontoteam när kunder hamnar i betalningsdröjsmål, med användning av anpassade tröskelvärden för tid eller utestående belopp per kund.
• Övervaka pipelinehälsan och kör automatiskt misslyckade jobb eller aviseringsteam igen när avvikelser eller fel identifieras.

Nästa steg

Se Självstudie: Skapa och aktivera en Fabric-aktiveringsregel.