Többhelyes és többrégiós összevonás
Számos kifinomult megoldás megköveteli, hogy ugyanazokat az eseménystreameket több helyen is elérhetővé lehessen tenni felhasználás céljából, vagy az eseménystreameket több helyen kell összegyűjteni, majd egy adott helyre kell összevonni felhasználás céljából. Gyakran szükség van az eseménystreamek dúsítására vagy csökkentésére, vagy az eseményformátumok konvertálására is egyetlen régión és megoldáson belül.
Ez gyakorlatilag azt jelenti, hogy a megoldás több Eseményközpontot fog fenntartani, gyakran különböző régiókban és Event Hubs-névterekben, majd replikálja közöttük az eseményeket. Az eseményeket olyan forrásokkal és célokkal is cserélheti, mint Azure Service Bus, Azure IoT Hub vagy Apache Kafka.
Ha több aktív eseményközpontot tart fenn különböző régiókban, az ügyfelek választhatnak és válthatnak közöttük, ha egyesítve vannak a tartalmuk, ami ellenállóbbá teszi az általános rendszert a regionális rendelkezésre állási problémákkal szemben.
Ez az "Összevonás" fejezet bemutatja az összevonási mintákat, és azt, hogyan valósíthatja meg ezeket a mintákat a kiszolgáló nélküli Azure Stream Analytics vagy a Azure Functions futtatókörnyezetek használatával, és saját átalakítást vagy bővítési kódot használhat közvetlenül az eseményfolyamat útvonalán.
Összevonási minták
Számos lehetséges motivációja lehet annak, hogy miért érdemes áthelyezni az eseményeket különböző eseményközpontok vagy más források és célok között, és számba vesszük az ebben a szakaszban szereplő legfontosabb mintákat, és a megfelelő mintához kapcsolódó részletesebb útmutatásra is hivatkozunk.
- Rugalmasság a regionális rendelkezésre állási események ellen
- Késés optimalizálása
- Ellenőrzés, csökkentés és bővítés
- Integráció az elemzési szolgáltatásokkal
- Eseménystreamek konszolidálása és normalizálása
- Eseménystreamek felosztása és útválasztása
- Naplóvetületek
Rugalmasság a regionális rendelkezésre állási események ellen
Bár az Event Hubs esetében a maximális rendelkezésre állás és megbízhatóság a legfontosabb üzemeltetési prioritás, számos módon akadályozható meg, hogy egy gyártó vagy fogyasztó hálózatkezelési vagy névfeloldási problémák miatt beszéljen a hozzárendelt "elsődleges" eseményközpontokkal, vagy ha egy eseményközpont átmenetileg nem válaszol vagy hibákat ad vissza.
Az ilyen feltételek nem "katasztrofálisak", ezért teljesen fel kell hagynia a regionális üzembe helyezéssel, mint egy vészhelyreállítási helyzetben, de egyes alkalmazások üzleti forgatókönyvét már befolyásolhatják a rendelkezésre állási események, amelyek legfeljebb néhány percig vagy akár másodpercig tartanak.
Az ilyen forgatókönyvek kezelésére két alapvető minta áll rendelkezésre:
- A replikációs minta az elsődleges eseményközpontok tartalmának egy másodlagos eseményközpontba való replikálásáról szól, amely szerint az elsődleges Event Hubsot általában az alkalmazás használja események előállítására és felhasználására, a másodlagos pedig tartalék lehetőségként szolgál arra az esetre, ha az elsődleges Event Hubs elérhetetlenné válik. Mivel a replikáció egyirányú, az elsődlegesről a másodlagosra, a termelők és a fogyasztók egy nem elérhető elsődlegesről a másodlagosra való váltása miatt a régi elsődleges nem kap új eseményeket, ezért az már nem lesz aktuális. A tiszta replikáció ezért csak egyirányú feladatátvételi forgatókönyvekhez alkalmas. A feladatátvételt követően a régi elsődleges rendszer elhagyatott, és egy új másodlagos eseményközpontot kell létrehozni egy másik célrégióban.
- Az egyesítési minta két vagy több Event Hubs tartalmának folyamatos egyesítésével kibővíti a replikációs mintát. A rendszer az eredetileg a sémában szereplő Event Hubs egyikébe előállított összes eseményt a másik Eseményközpontba replikálja. Az események replikálása során a rendszer úgy jegyzeteli őket, hogy a replikációs cél replikációs folyamata ezt követően figyelmen kívül hagyja őket. Az egyesítési minta használatának eredménye két vagy több olyan Eseményközpont, amely végül egységes módon fogja tartalmazni ugyanazt az eseménykészletet.
Mindkét esetben az Event Hubs tartalma nem lesz azonos. Bármely gyártótól származó és ugyanazon partíciókulcs szerint csoportosított események az eredetileg elküldött relatív sorrendben jelennek meg, de az események abszolút sorrendje eltérhet. Ez különösen igaz azokra a forgatókönyvekre, amelyekben a forrás és a cél Event Hubs partíciószáma eltér, ami az itt ismertetett több kiterjesztett minta esetében is kívánatos. Egy osztó vagy útválasztó egy sokkal nagyobb eseményközpont szeletét szerezheti be több száz partícióval és tölcsérrel egy kisebb Event Hubsba, mindössze néhány partícióval, amely alkalmasabb a korlátozott feldolgozási erőforrásokkal rendelkező részhalmaz kezelésére. Ezzel szemben az összesítés több kisebb Eseményközpontból származó adatokat egyetlen, nagyobb, több partícióval rendelkező eseményközpontba vonhatja be, hogy megbirkózzon a konszolidált átviteli sebességgel és a feldolgozási igényekkel.
Az események együtt tartásának feltétele a partíciókulcs, nem pedig az eredeti partícióazonosító. A replikációs minta leírásában további szempontokat talál a relatív sorrendről, valamint arról, hogyan hajthat végre feladatátvételt az egyik Eseményközpontból a következőre anélkül, hogy a streameltolások hatókörére támaszkodik.
Útmutatást:
Késés optimalizálása
Az eseménystreameket a készítők egyszer írják, de az eseményfogyasztók tetszőleges számú alkalommal elolvashatják. Olyan forgatókönyvek esetén, amikor egy régióban egy eseménystreamet több felhasználó is megoszt, és egy másik régióban található elemzési feldolgozás során vagy az egyidejű fogyasztókat éhező igények miatt többször is hozzá kell férni, előnyös lehet az eseménystream egy példányát az elemzési processzor közelében elhelyezni a lekerekítési késés csökkentése érdekében.
Jó példák arra, amikor a replikációt előnyben kell részesíteni az események távoli, régiók közötti felhasználásával szemben, különösen azokra, ahol a régiók rendkívül távol vannak egymástól, például Európa és Ausztrália közel antipodes, földrajzilag és hálózati késések könnyen meghaladhatják a 250 ms-ot minden oda-vissza utazás esetén. A fénysebesség nem gyorsítható fel, de csökkentheti a nagy késésű körutazások számát az adatokkal való interakcióhoz.
Útmutatást:
Ellenőrzés, csökkentés és bővítés
Előfordulhat, hogy az eseménystreameket a saját megoldásán kívüli ügyfelek küldik el egy Event Hubsba. Az ilyen eseménystreamek megkövetelhetik, hogy a külsőleg elküldött eseményeket ellenőrizni kell egy adott sémának való megfelelőségről, és hogy a nem megfelelő eseményeket el kell-e dobni.
Azokban az esetekben, amikor az ügyfelek rendkívül korlátozott sávszélességgel rendelkeznek, mivel ez sok olyan "dolgok internetes hálózata" forgatókönyvben fordul elő, amelyek forgalmi díjas sávszélességgel rendelkeznek, vagy ha az eseményeket eredetileg nem IP-hálózatokon, korlátozott csomagmérettel küldik el, előfordulhat, hogy az eseményeket hivatkozási adatokkal kell kiegészíteni, hogy további kontextust adjanak ahhoz, hogy az alsóbb rétegbeli eseményfeldolgozók használhatóak legyenek.
Más esetekben, különösen ha a streamek összevonva vannak, előfordulhat, hogy az eseményadatokat bizonyos részletek kihagyásával csökkenteni kell az összetettségben vagy a szűkebb méretben.
Ezen műveletek bármelyike a replikációs, összevonási vagy egyesítési folyamatok részeként történhet.
Útmutatást:
Integráció az elemzési szolgáltatásokkal
Az Azure több natív felhőalapú elemzési szolgáltatása, például az Azure Stream Analytics vagy Azure Synapse a legjobban az Azure Event Hubs által szolgáltatott streamelt vagy előre kötegelt adatokkal működik, és Azure Event Hubs lehetővé teszi az integrációt számos nyílt forráskódú elemzési csomaggal, például az Apache Samza, az Apache Flink, az Apache Spark és az Apache Storm szolgáltatással.
Ha a megoldás elsősorban a Service Bust vagy az Event Gridet használja, ezeket az eseményeket könnyen elérhetővé teheti az ilyen elemzési rendszerek számára, valamint archiválhatja őket az Event Hubs Capture szolgáltatással, ha azokat az Event Hubsba tölcsérezi. Az Event Grid ezt natív módon is megteheti az Event Hubs-integrációval, a Service Bus esetében a Service Bus replikációs útmutatóját követve.
Az Azure Stream Analytics közvetlenül integrálható az Event Hubs szolgáltatással.
Útmutatást:
Eseménystreamek konszolidálása és normalizálása
A globális megoldások gyakran olyan regionális lábnyomokból állnak, amelyek nagyrészt függetlenek, beleértve a saját elemzési képességeiket is, de a regionális és globális elemzési perspektívákhoz integrált perspektívára van szükség, és ezért kell központi összevonást létrehozni ugyanazon eseménystreamek esetében, amelyeket a helyi szempontból a megfelelő regionális lábnyomokban értékelnek.
A normalizálás a konszolidációs forgatókönyv egyik íze, amely szerint két vagy több bejövő eseményfolyam ugyanazt az eseménytípust hordozza, de különböző struktúrával vagy különböző kódolással, és a legtöbb esemény átkódolható vagy átalakítható, mielőtt felhasználhatók lennének.
A normalizálás magában foglalhatja a titkosítási munkákat is, például a végpontok közötti titkosított hasznos adatok visszafejtését, valamint a különböző kulcsokkal és algoritmusokkal történő újratitkosítást a lefelé irányuló fogyasztói közönség számára.
Útmutatást:
Eseménystreamek felosztása és útválasztása
Azure Event Hubs időnként "publish-subscribe" stílusú forgatókönyvekben használják, ahol az betöltött események bejövő özöne messze meghaladja a Azure Service Bus vagy Azure Event Grid kapacitását, amelyek mindegyike natív közzétételi-feliratkozási szűrési és terjesztési képességekkel rendelkezik, és előnyben részesítik ezt a mintát.
Bár a valódi "publish-subscribe" képesség lehetővé teszi az előfizetők számára a kívánt események kiválasztását, a felosztási mintában az előállító egy előre meghatározott terjesztési modell szerint particionálja az eseményeket, a kijelölt fogyasztók pedig kizárólag a "saját" partíciójukból húznak le. Ha az Event Hubs puffereli a teljes forgalmat, egy adott partíció tartalma, amely az eredeti átviteli sebesség töredékét képviseli, ezután egy üzenetsorba replikálható a megbízható, tranzakciós, versengő fogyasztói felhasználás érdekében.
Számos esetben, amikor az Event Hubsot elsősorban egy adott régión belüli alkalmazáson belüli események áthelyezésére használják, vannak olyan esetek, amikor a kiválasztott eseményeket , esetleg csak egyetlen partícióból, máshol is elérhetővé kell tenni. Ez a forgatókönyv hasonló a felosztási forgatókönyvhöz, de használhat skálázható útválasztót, amely figyelembe veszi az eseményközpontokba érkező összes üzenetet, és csak néhányat választ ki a további útválasztáshoz, és megkülönböztetheti az útválasztási célokat az esemény metaadatai vagy tartalma alapján.
Útmutatást:
Naplóvetületek
Bizonyos esetekben hozzá szeretne férni az esemény bármely alfolyamához küldött legújabb értékhez, amelyet általában a partíciókulcs különböztet meg. Az Apache Kafkában ez gyakran úgy érhető el, hogy engedélyezi a "naplótömörítést" egy témakörben, amely elveti az összes, egyedi kulccsal megjelölt legújabb eseményt. A naplótömörítési megközelítésnek három összetett hátránya van:
- A tömörítéshez a napló folyamatos átszervezése szükséges, ami rendkívül költséges művelet egy olyan közvetítő számára, amely csak hozzáfűző számítási feladatokra van optimalizálva.
- A tömörítés romboló, és nem teszi lehetővé ugyanannak a streamnek a tömörített és nem tömörített perspektíváját.
- A tömörített streamek továbbra is szekvenciális hozzáférési modellel bírnak, ami azt jelenti, hogy a naplóban a kívánt érték megkereséséhez a legrosszabb esetben a teljes naplót kell beolvasni, ami általában az itt bemutatott pontos mintát megvalósító optimalizáláshoz vezet: a napló tartalmának kivetítése egy adatbázisba vagy gyorsítótárba.
Végső soron a tömörített naplók kulcs-érték tárolók, és mint ilyen, ez a lehető legrosszabb megvalósítási lehetőség egy ilyen tároló esetében. Sokkal hatékonyabb a keresések és a lekérdezések számára a napló állandó vetületének létrehozása és használata egy megfelelő kulcs-érték tárolóra vagy más adatbázisra.
Mivel az események nem módosíthatók, és a sorrend mindig megmarad a naplókban, a naplók kulcs-érték tárolóba való kivetítése mindig azonos lesz ugyanahhoz az eseménytartományhoz, ami azt jelenti, hogy a folyamatosan frissített leképezés mindig mérvadó nézetet biztosít, és soha nincs jó ok arra, hogy a napló tartalmát a létrehozás után újraépítsék.
Útmutatást:
Replikációs alkalmazástechnológiák
A fenti minták implementálásához skálázható és megbízható végrehajtási környezet szükséges a konfigurálni és futtatni kívánt replikációs feladatokhoz. Az Azure-ban az ilyen feladatokhoz leginkább megfelelő futtatókörnyezetek az állapot nélküli feladatok az Azure Stream Analytics állapotalapú streamreplikációs feladatokhoz és Azure Functions állapot nélküli replikációs feladatokhoz.
Állapotalapú replikációs alkalmazások az Azure Stream Analyticsben
Az olyan állapotalapú replikációs alkalmazások esetében, amelyeknek figyelembe kell venniük az események közötti kapcsolatokat, összetett eseményeket kell létrehozniuk, eseményeket gazdagítaniuk vagy csökkenteniük kell az eseményeket, adatösszesítéseket kell létrehozniuk, és át kell alakítaniuk az esemény hasznos adatait, az Azure Stream Analytics a legjobb megvalósítási lehetőség.
Az Azure Stream Analyticsben olyan feladatokat hozhat létre , amelyek bemeneteket és kimeneteket integrálnak, és a bemenetekből származó adatokat olyan lekérdezésekkel integrálják, amelyek eredményeként a kimenetek elérhetővé válnak.
A lekérdezések az SQL lekérdezési nyelvén alapulnak, és használatával egyszerűen szűrhetők, rendezhetők, összesíthetők és összekapcsolhatók a streamelési adatok egy adott időszakban. Ezt az SQL-nyelvet javaScripttel és C# felhasználó által definiált függvényekkel (UDF-ekkel) is bővítheti. Egyszerű nyelvi szerkezetekkel és/vagy konfigurációkkal egyszerűen módosíthatja az eseményrendezési beállításokat és az időablakok időtartamát az összesítési műveletek végrehajtásakor.
Minden feladat egy vagy több kimenettel rendelkezik az átalakított adatokhoz, és szabályozhatja, hogy mi történjen az elemzett információkra válaszul. Megteheti például a következőt:
- Adatokat küldhet olyan szolgáltatásoknak, mint a Azure Functions, a Service Bus-témakörök vagy az üzenetsorok, hogy kommunikációt vagy egyéni munkafolyamatokat indítson el az alsóbb rétegben.
- Adatok küldése Power BI-irányítópultra valós idejű irányítópultok létrehozásához.
- Adatok tárolása más Azure Storage-szolgáltatásokban (például Azure Data Lake, Azure Synapse Analytics stb.) kötegelt elemzések elvégzéséhez vagy gépi tanulási modellek betanítása nagyon nagy, indexelt előzményadatok alapján.
- Az adatbázisokban (SQL Database, Azure Cosmos DB) tárolhatja a vetületek (más néven "materializált nézetek") tárolását.
Állapot nélküli replikációs alkalmazások a Azure Functions
Az olyan állapot nélküli replikációs feladatok esetében, ahol anélkül szeretné továbbítani az eseményeket, hogy figyelembe venné a hasznos adatokat, vagy önállóan dolgozza fel őket anélkül, hogy figyelembe kellene vennie az események kapcsolatait (kivéve a relatív sorrendjüket), használhatja a Azure Functions, amely hatalmas rugalmasságot biztosít.
Azure Functions előre összeállított, méretezhető eseményindítókkal és kimeneti kötésekkel rendelkezik Azure Event Hubs, Azure IoT Hub, Azure Service Bus, Azure Event Grid és Azure Queue Storage esetében, valamint egyéni a RabbitMQ és az Apache Kafka bővítmények. A legtöbb eseményindító dinamikusan alkalmazkodik az átviteli sebesség igényeihez az egyidejűleg végrehajtott példányok számának a dokumentált metrikák alapján történő vertikális fel- és leskálázásával.
Naplóvetítések készítéséhez Azure Functions támogatja az Azure Cosmos DB és az Azure Table Storage kimeneti kötéseit.
Azure Functions azure-beli felügyelt identitással futtatható, és ezzel a hitelesítő adatok konfigurációs értékeit az Azure Key Vault szigorúan hozzáférés-vezérlésű tárolójában tárolhatja.
Azure Functions lehetővé teszi továbbá, hogy a replikációs feladatok közvetlenül integrálhatók az Azure-beli virtuális hálózatokkal és szolgáltatásvégpontokkal az összes Azure-üzenetkezelési szolgáltatás esetében, és könnyen integrálható az Azure Monitorral.
A Azure Functions használati csomag esetén az előre összeállított eseményindítók akár nullára is leskálázhatók, miközben nem érhetők el üzenetek a replikációhoz, ami azt jelenti, hogy nincs költség a konfiguráció biztonsági mentésre való készen tartásához. A használati terv használatának fő hátránya, hogy az ebből az állapotból "felébredő" replikációs feladatok késése jelentősen magasabb, mint azoknál az üzemeltetési csomagoknál, ahol az infrastruktúra fut.
Mindezekkel ellentétben az üzenetküldés és az eseménykezelés leggyakoribb replikációs motorjai, például az Apache Kafka MirrorMaker megkövetelik, hogy üzemeltetési környezetet biztosítson, és saját maga skálázza a replikációs motort. Ez magában foglalja a biztonsági és hálózati funkciók konfigurálását és integrálását, valamint a monitorozási adatok áramlásának megkönnyítését, és így sem lesz lehetősége egyéni replikációs feladatokat injektálni a folyamatba.
Választás a Azure Functions és az Azure Stream Analytics között
Az Azure Stream Analytics (ASA) a legjobb megoldás, ha az események hasznos adatait kell feldolgoznia replikálás közben. Az ASA egyesével másolhat eseményeket, vagy olyan összesítéseket hozhat létre, amelyek az eseménystreamek információit összesítik a továbbítás előtt. Könnyen támaszkodhat a Azure Blob Storage vagy Azure SQL adatbázisban tárolt referenciaadatok kiegészítésére anélkül, hogy ezeket az adatokat streambe kellene importálnia.
Az ASA használatával egyszerűen hozhat létre állandó, materializált nézeteket a hiperméretű adatbázisokban lévő streamekről. Ez egy sokkal jobb megközelítés az Apache Kafka "log compaction" modelljéhez és a Kafka Streams illékony, ügyféloldali táblavetületeihez.
Az ASA könnyen feldolgozhatja a CSV, JSON és Apache Avro formátumban kódolt hasznos adatokat eredményező eseményeket, és bármilyen más formátumhoz csatlakoztathatja az egyéni deszerializálókat .
Az összes olyan replikációs feladat esetében, ahol az eseménystreameket "adott módon" szeretné másolni, és nem szeretné megérinteni a hasznos adatokat, vagy ha útválasztót kell implementálnia, kriptográfiai munkát kell végeznie, módosítania kell a hasznos adatok kódolását, vagy ha egyébként teljes mértékben szabályoznia kell az adatfolyam tartalmát, Azure Functions a legjobb megoldás.
Következő lépések
Ebben a cikkben számos összevonási mintát ismertettünk, és ismertettük a Azure Functions szerepét az Azure esemény- és üzenetkezelési replikációs futtatókörnyezeteként.
Ezután érdemes elolvasnia, hogyan állíthat be replikátoralkalmazást az Azure Stream Analytics vagy Azure Functions használatával, majd hogyan replikálhatja az eseményfolyamatokat az Event Hubs és más eseménykezelő és üzenetkezelő rendszerek között: