Latest / M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch / Azure Event Hubs einfach erklärt: Echtzeit-Datenstreaming mit Partitionen, Consumergruppen und Kafka (KI-Synchronfassung)

Transcript

Azure Event Hubs einfach erklärt: Echtzeit-Datenstreaming mit Partitionen, Consumergruppen und Kafka (KI-Synchronfassung) · M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch

• 0:00
  Bereit für 10 Tage Microsoft 365 Co-Pilot KI-Azure und die Menschen, die die Zukunft der Arbeit gestalten?
• 0:07
  Diesen Januar ist die M-Tron 65-Con zurück und zwar noch größer.
• 0:12
  Seien Sie dabei bei Live-Sitzungen, Demos aus der Praxis und praktischem Wissen von MVPs und Branchenexperten aus aller Welt.
• 0:18
  Keine generischen Folien, keine endlosen Schlagworte.
• 0:21
  Wir stellen uns den echten Herausforderungen Co-Pilot Studio, KI-Agents, Fabric, Sicherheit, Governance und Automatisierung.
• 0:28
  Ganz gleich, ob Sie IT-Experte, Entwickler oder Führungskraft sind, es gibt speziell auf Sie zugeschnittene Sitzungen.
• 0:35
  An 10 vollen Tagen können Sie verschiedene Technologien kennenlernen und sich mit einer globalen Community vernetzen.
• 0:40
  Sehen Sie sich die Live-Übertragung an und nehmen Sie praktische Einblicke mit nach Hause in Ihr Unternehmen.
• 0:45
  Januar 2027, 10 Tage, eine Microsoft Community.
• 0:49
  Die Registrierung ist ab sofort möglich.
• 0:51
  Gehen Sie noch heute zu Ihrem Standort.
• 0:53
  Das ist m325-conton.net.
• 0:58
  Melden Sie sich jetzt unter m325-conton.net an und wir sehen uns im Januar live.
• 1:05
  Willkommen zurück zu einer neuen Folge von Microsoft Knowledge Nuggets.
• 1:07
  Ich bin Ihr Gastgeber Mirko Peters und heute befassen wir uns mit einem realen Datenproblem.
• 1:12
  Lassen Sie mich Sie folgendes fragen.
• 1:14
  Stellen Sie sich vor, Sie arbeiten in einer Fabrik mit 1000 Sensoren für Temperatur, Druck und Vibration.
• 1:18
  Wieder unterbrochen, laufen, laufen und und und und und und.
• 1:19
  Das sind also 1000 Datenpunkte pro Sekunde.
• 1:22
  Vor 20 Jahren war die Lösung einfach.
• 1:24
  Sie haben tagsüber all diese Daten gesammelt, in einer Datei gespeichert und dann um Mitternacht einen Batchjob ausgeführt, um die Daten zu verarbeiten.
• 1:30
  Am nächsten Morgen hatten Sie dann einen Bericht, der Ihnen zeigte, was gestern passiert war.
• 1:33
  Das hat gut funktioniert, als schnell genug bedeutete, dass es morgen früh sein würde.
• 1:37
  Aber die Welt hat sich verändert.
• 1:38
  Sensoren wurden billiger, Apps wurden intelligenter und die Nutzer erwarten sofortige Antworten.
• 1:43
  Dieser nächtliche Batchjob bedeutet, dass Ihre Daten immer einen Tag alt sind.
• 1:46
  Und in einer Welt, in der eine überhitzte Maschine innerhalb von Minuten einen Brand verursachen kann, sind Daten von einem Tag nutzlos.
• 1:51
  Also stellen Sie auf Echtzeit um und erfassen die Daten, sobald sie generiert werden.
• 1:54
  Aber hier fangen die Probleme an.
• 1:56
  Versuchen Sie mal, all diese Streaming-Daten in eine herkömmliche Datenbank zu stellen.
• 1:59
  Und sie gerät einfach ins Stocken.
• 2:01
  Datenbanken sind für Abfragen und Transaktionen konzipiert, nicht für die Verarbeitung einer Flut von Ereignissen.
• 2:05
  Sie versuchen es mit einer normalen Nachrichtenwarteschlange und das funktioniert eine Zeit lang.
• 2:09
  Aber Warteschlangen sind dafür konzipiert, dass ein einzelner Konzipiert, dass ein einzelner Consumer eine Nachricht abrufende verarbeitet.
• 2:13
  Sie sind also nicht für Millionen von Ereignissen pro Sekunde mit mehreren nachgelagerten Systemen konzipiert, die alle denselben Stream lesen möchten.
• 2:20
  Das ist die zentrale Herausforderung.
• 2:22
  Sie benötigen eine Möglichkeit, riesige Datenmengen zu verarbeiten, diese zu puffern, damit nichts verloren geht und sie in Echtzeit an mehrere Consumer zu verteilen.
• 2:29
  Das ist kein Datenbankproblem.
• 2:30
  Es ist kein Warteschlangenproblem.
• 2:32
  Das sind Streaming-Probleme.
• 2:33
  Also wie kann man das lösen?
• 2:33
  Hier kommt Azure Event Hubs ins Spiel.
• 2:36
  Was ist Azure Event Hubs?
• 2:37
  Hier ist die einfachste Definition.
• 2:40
  Azure Event Hubs ist eine vollständig verwaltete Echtzeit-Datenstreaming-Plattform, die speziell dafür entwickelt wurde, mit geringer Latenz zu verarbeiten.
• 2:46
  Beachten Sie, dass ich nicht Nachrichtenwarteschlange oder Datenbank gesagt habe.
• 2:49
  Event Hubs ist keine Warteschlange und keine Datenbank.
• 2:52
  Es ist ein Datenstrom und der Unterschied ist wichtig.
• 2:54
  Eine Warteschlange enthält eine Nachricht, bis ein Consumer sie abruf und ist sie weg.
• 2:57
  Eine Datenbank speichert Daten, damit Sie sie später erfragen können.
• 3:00
  Ein Datenstrom ist jedoch anders.
• 3:01
  Es handelt sich um einen kontinuierlichen Fluss von Ereignissen, die mehrere Leser unabhängig voneinander in ihrem eigenen Tempo lesen können, ohne dass Datenstrom entfernt werden müssen.
• 3:08
  Lassen Sie uns nun ein paar Mythen ausräumen.
• 3:10
  Event Hubs können Millionen von Ereignissen pro Sekunde verarbeiten.
• 3:13
  Wir sprechen hier von der Aufnahme von Hunderttausenden von Nachrichten pro Sekunde von Tausenden von Produzenten von Produzenten.
• 3:18
  Dies geschieht mit sehr geringer Latenz.
• 3:20
  Von Senden eines Ereignisses bis zu dem Zeitpunkt, an dem ein Consumer es lesen kann, vergehen nur Millisekunden.
• 3:25
  Folgendes überrascht viele, Event Hubs ist Kafka-kompatibel.
• 3:28
  Wenn Sie also bereits mit Apache Kafka gearbeitet haben, können Sie Ihre vorhandenen Kafka-Tools und Clients verwenden, um mit Event Hubs zu kommunizieren, ohne ein neues Protokoll erlernen oder Ihre Anwendungen neu schreiben zu müssen.
• 3:36
  Event Hubs spricht dieselbe Sprache.
• 3:38
  Am einfachsten kann man sich Event Hubs als eine Art Hochgeschwindigkeitsdateneingangstür vorstellen.
• 3:42
  Denken Sie sich ein belebtes Bürogebäude während der Hauptverkehrszeit vor.
• 3:45
  Hunderte von Menschen betreten jede Minute die Eingangstür und die Tür hält sie nicht auf, stellt keine Fragen und leitet sie nicht in bestimmte Räume um.
• 3:52
  Sie lässt sie einfach schnell herein.
• 3:54
  Das Event Hubs. Es ist die Eingangstür für Ihre Daten.
• 3:56
  Die Daten werden nicht verarbeitet, analysiert oder entschieden, was damit zu tun ist.
• 3:59
  Die Daten werden einfach so schnell wie möglich in Ihre Azure-Umgebung eingeschleust, damit Ihre nachgelagerten Systeme die eigentliche Arbeit erledigen können.
• 4:05
  Aber wie funktioniert das eigentlich? Lassen Sie uns die Einzelbeschlüsse.
• 4:08
  Die Bausteine, Partitionen, Consumergruppen, Durchsatz.
• 4:11
  In jedem Event Hub gibt es also eine Struktur, die das Ganze zum Funktionieren bringt.
• 4:14
  Das wichtigste Element ist die Partition.
• 4:16
  Stellen Sie sich eine Partition, wenn eine Fahrspur von der Autobahn fährt.
• 4:18
  Daten kommen an und landen auf einer dieser Fahrspur.
• 4:20
  Hier ist der Schlüssel.
• 4:21
  Innerhalb jeder Fahrspur bleibt die Reihenfolge der Ereignisse genau in der Reihenfolge, in der Sie eingegangen sind.
• 4:24
  Ereignis 1 kommt vor Ereignis 2 und Ereignis 2 vor Ereignis 3.
• 4:27
  Diese Reihenfolge ändert sich innerhalb dieser Lainy.
• 4:30
  Wenn Ihre Anwendung Ereignisse, also in der exakten Reihenfolge benötigt, behalten Sie sie nicht.
• 4:33
  Sie können zwischen 2 und 32 Partitionen pro Event Hub haben und legen diese Zahl fest, wenn Sie den Hub erstellen.
• 4:39
  Sie kann später nicht mehr geändert werden.
• 4:40
  Daher müssen Sie sich im Voraus Gedanken über Ihren Durchsatzbedarf machen.
• 4:43
  Mehr Partitionen bedeuten mehr parallele Verarbeitung.
• 4:45
  Wenn Sie ein hohes Ereignis auf Komma warten, benötigen Sie mehr Partitionen, damit mehrere Consumer gleichzeitig aus verschiedenen Lanes lesen können.
• 4:51
  Mehr Partitionen bedeuten jedoch auch mehr Komplexität.
• 4:54
  Zwausträglich gilt, dass Sie Ihre Wahl nicht willkürlich, sondern basierend auf dem erwarteten Durchsatz treffen sollten.
• 4:57
  Wenn Sie sich nicht sicher sind, beginnen Sie mit einer kleineren Größe und testen.
• 5:00
  Partitionen allein reichen nicht aus.
• 5:01
  Sie benötigen auch Consumergruppen.
• 5:03
  Eine Consumergruppe ist einfach eine separate Downstream-Anwendung, die denselben Stream liest.
• 5:07
  Jede Consumergruppe erhält eine eigene, unabhängige Kopie.
• 5:10
  Wenn Sie also eine Gruppe für Echtzeitanalysen und eine andere für die Archivierung im Speicher haben, lesen beide gleichzeitig dieselben Ereignisse, ohne sich zu stören.
• 5:17
  Die Analysegruppe liest Temperaturdaten, um Anomalien zu erkennen.
• 5:20
  Die Archivierungsgruppe liest dieselben Daten und sendet sie zur Langzeitspeicherung an einen Data Lake.
• 5:24
  Beide Gruppen sehen jedes Ereignis.
• 5:26
  Keine Gruppe blockiert die andere.
• 5:27
  Und das ist ein wichtiger Aspekt.
• 5:28
  In einer herkömmlichen Warteschlange wird eine Nachricht von einem Prozessor verarbeitet und ist dann weg.
• 5:32
  Hier können mehrere Consumer denselben Datenstrom unabhängig von einer Nächsten.
• 5:35
  Das ist die Stärke von Consumergruppen.
• 5:37
  Aber wie messen Sie, wie viele Daten Ihr Event-Hub verarbeiten kann?
• 5:39
  Hier kommen die Durchsatzeinheiten ins Spiel.
• 5:41
  Eine Durchsatzeinheit oder TU ist ein Maß für die Kapazität.
• 5:44
  Eine TU bietet Ihnen 1 MB pro Sekunde an eingehenden Daten und 2 MB pro Sekunde an ausgehenden Daten.
• 5:50
  Wenn Sie also 10 MB pro Sekunde erfassen müssen, benötigen Sie mindestens 10 TUs.
• 5:53
  Sie können manuell hochskalieren oder die automatische Erhöhung aktivieren,
• 5:56
  wodurch Ihre TUs bei Datenverkehrsspitzen automatisch erhöht werden.
• 5:59
  Sie zahlen für die maximale Anzahl an TUs, die in einer Stunde genutzt werden.
• 6:02
  Wenn Sie also 20 TUs für 10 Minuten verwenden, bauen Sie für die gesamte Stunde 20 TUs ein.
• 6:07
  Noch ein Aspekt Aufbewahrung.
• 6:09
  Ereignisse verschwinden nicht aus dem Haupt, nachdem sie verbraucht wurden.
• 6:12
  Sie verbleiben für einen konfigurierbaren Zeitrahmen.
• 6:13
  Im Standardtarif sind das 1 bis 7 Tage.
• 6:15
  Im Premiumtarif bis zu 90 Tage.
• 6:17
  Dies ermöglicht etwas, das als Wiedergabe bezeichnet.
• 6:19
  Wenn Ihr nachgelagerter Consumer ausfällt
• 6:21
  oder Sie Daten für eine neue Analyse erneut verarbeiten müssen,
• 6:23
  können Sie zurückgehen und alte Ereignisse erneut lesen.
• 6:25
  Das ist anders als bei einer Warteschlange,
• 6:27
  bei der eine Nachricht, sobald sie verbraucht wurde, für immer verloren ist.
• 6:29
  Kennen Sie also die einzelnen Bestandteile,
• 6:31
  aber wir arbeiten sie in einem echten System tatsächlich zusammen.
• 6:34
  Funktionsweise.
• 6:34
  Das Producer- und Consumer-Modell.
• 6:36
  Lassen Sie uns den Ablauf von Anfang bis Ende durchgehen.
• 6:38
  Auf der einen Seite haben Sie Producer.
• 6:40
  Ein Producer ist eine beliebige Anwendung
• 6:42
  oder ein Gerät, das Ereignisse an den Hubs sendet.
• 6:44
  Dabei kann es sich um einen Temperatursensor in einer Fabrik,
• 6:46
  einen Webserver der Seitenaufrufe protokolliert
• 6:48
  oder eine Banking-App handeln, die Transaktionsdaten sendet.
• 6:50
  Produzenten können über drei verschiedene Protokolle mit Event-Hubs kommunizieren.
• 6:53
  In AMQP, HTTPS oder Kafka.
• 6:55
  Es gibt also eine Möglichkeit, eine Verbindung herzustellen,
• 6:57
  ganz gleich, welche Sprache oder Plattform Sie verwenden.
• 6:59
  Wenn ein Produzent ein Ereignis sendet,
• 7:00
  entscheidet der Hub, in welche Partition es verschoben.
• 7:03
  Standardmäßig werden Ereignisse im Round-Rubin-Verfahren verteilt.
• 7:06
  Das erste Ereignis wird am Partition 1 verschoben,
• 7:07
  das zweite am Partition 2 USB.
• 7:09
  Sie können aber auch einen Partitionsschlüssel verwenden.
• 7:10
  Wenn Sie möchten, dass alle Ereignisse von demselben Gerät
• 7:13
  in derselben Partition landen, legen Sie die Geräte-ID
• 7:15
  als Partitionsschlüssel für.
• 7:16
  Auf diese Weise bleibt die Reihenfolge der Ereignisse
• 7:17
  von diesem Gerät erhalten.
• 7:18
  Der Hub selbst führt nicht viele Verarbeitungsvorgänge auf.
• 7:21
  Er puffert die Ereignisse und speichert sie
• 7:22
  für den Aufbewahrungszeitraum in den Partitionen.
• 7:24
  Stellen Sie sich das als ein Aufbewahrungswort.
• 7:26
  Die Ereignisse verbleiben dort und warten darauf,
• 7:27
  dass sie gelesen werden.
• 7:29
  Auf der anderen Seite gibt es Konsumenten.
• 7:31
  Konsumenten sind nachgelagerte Anwendungen,
• 7:32
  die Daten aus dem Hub lesen.
• 7:34
  Und hier kommt der wichtige Teil.
• 7:35
  Konsumenten verwenden ein Pull-Modell.
• 7:37
  Sie steuern ihr eigenes Tempo.
• 7:38
  Sie erhalten keine Push-Ereignisse,
• 7:39
  sondern fordern Ereignisse an, wenn diese bereit sind.
• 7:41
  Dies unterscheidet sich von einer Warteschlange,
• 7:43
  bei der das System nachrichten an einen Consumer-Push.
• 7:45
  Hier entscheidet der Consumer,
• 7:46
  wann der nächste Batch abgerufen werden soll.
• 7:48
  Jede Consumer-Gruppe verfolgt ihre eigene Position im Stream.
• 7:51
  Diese Position wird als Offset bezeichnet.
• 7:53
  Der Offset teilt dem Consumer mit,
• 7:54
  welche Ereignisse er bereits verarbeitet hat.
• 7:56
  Der Consumer speichert diesen Offset an einem dauerhaften Ort,
• 7:59
  in der Regel im Azure Blob-Speicher.
• 8:00
  Dieser Vorgang wird als Prüfpunktspeicherung bezeichnet.
• 8:02
  Hier werden die Gründe für die Bedeutung von Prüfpunkten.
• 8:04
  Stellen Sie sich vor, Ihre Konsumeranwendung
• 8:05
  stürzt während der Verarbeitung eines Ereignis-Badges ab.
• 8:08
  Beim Neustart liest sie den letzten Prüfpunkt aus dem Blob-Speicher
• 8:11
  und setzt die Arbeit genau an diesem Punkt fort.
• 8:13
  Sie verarbeitet alte Ereignisse nicht erneut
• 8:14
  und überspringt keine Ereignisse.
• 8:16
  Sie setzt die Arbeit genau dort fort, wo sie aufgehört.
• 8:18
  Das ist Zuverlässigkeit ohne Komplexität.
• 8:20
  Die wichtigste Erkenntnis ist,
• 8:21
  dass Event-Hubs Produzenten und Konsumenten vollständig entkoppelt.
• 8:24
  Produzenten wissen nicht, wer ihre Daten liest.
• 8:26
  Consumer wissen nicht, wer die Daten sendet.
• 8:28
  Es ist unabhängig.
• 8:28
  Der Hub befindet sich in der Mitte und puffert und verteilt Ereignisse.
• 8:31
  Jede Seite arbeitet in ihrem eigenen Tempel.
• 8:33
  Diese Entkopplung macht Event-Hubs so leistungsstark
• 8:35
  für den Aufbau skalierbarer, widerstandsfähiger Systeme.
• 8:38
  Verdeutlichen wir dies anhand realer Szenarien.
• 8:41
  Reale Anwendungsfälle.
• 8:42
  Beginnen wir mit dem wichtigsten, IoT-Telemetrie.
• 8:45
  Stellen Sie sich eine intelligente Fabrik mit tausenden von Sensoren vor.
• 8:48
  Jede Maschine verfügt über Sensoren,
• 8:49
  die Temperatur, Druck, Vibration und Energieverbrauch messen.
• 8:52
  Jeder einzelne sendet alle paar Sekunden an Messwert.
• 8:54
  Das sind nicht hunderte von Ereignissen pro Sekunde,
• 8:56
  sondern hunderttausende oder vielleicht Millionen,
• 8:58
  je nach Größe der Fabrik.
• 8:59
  Sie können diese Daten nicht in einer herkömmlichen Datenbank speichern,
• 9:01
  nicht mit einem Batch-Auftrag verarbeiten,
• 9:02
  der einmal täglich ausgeführt wird.
• 9:04
  Bis Sie den Bericht erhalten, ist eine Maschine
• 9:05
  möglicherweise bereits überhitzt und hat die Produktion eingestellt.
• 9:08
  Daher leiten Sie alle Sensordaten an Event-Hubs weiter,
• 9:11
  die die Daten problemlos verarbeiten.
• 9:13
  Anschließend verbinden Sie Azure Stream Analytics mit dem Hub,
• 9:15
  damit Echtzeitabfragen für die Daten ausgeführt werden können.
• 9:18
  Wenn ein Temperaturmesswert einen Schwellenwert überschreitet,
• 9:20
  wird eine Warnung ausgelöst, ein Wartungsteam wird benachrichtigt
• 9:22
  und ein Computer wird heruntergefahren, bevor er ausfällt.
• 9:25
  Es ist vorausschauende Wartung in Aktion.
• 9:26
  Ein weiterer häufiger Anwendungsfall ist die Anwendungsprotokollierung
• 9:29
  und Überwachung.
• 9:29
  Angenommen, Sie betreiben eine Microservice-Architektur
• 9:31
  mit 50 verschiedenen Diensten, die alle unterschiedliche Dinge tun.
• 9:35
  Jeder Dienst generiert Protokolle mit Fehlern,
• 9:36
  Warnungen und Leistungsmetriken.
• 9:37
  Früher haben Sie diese Protokolle in Dateien auf jedem Server geschrieben
• 9:40
  und wenn etwas kaputt ging, mussten Sie sich bei fünf verschiedenen Computern anmelden,
• 9:43
  um den Fehler zu finden.
• 9:44
  Das ist ein Albtraum.
• 9:46
  Stattdessen veranlassen Sie, dass jeder Dienst seine Protokolle
• 9:48
  an einen einzelnen Event-Hub sendet.
• 9:50
  Eine zentrale Pipeline.
• 9:52
  Dann erstellen Sie mehrere Consumer-Gruppen.
• 9:54
  Eine Gruppe liest den Stream und sendet kritische Fehler
• 9:56
  an ein Echtzeitwarnsystem.
• 9:58
  Eine andere Gruppe liest denselben Stream
• 10:00
  und schreibt alle Protokolle zur langfristigen Speicherung und Analyse
• 10:02
  in Azure Data Lake.
• 10:03
  Eine dritte Gruppe speist ein Live-Dashboard aus den Systemzustand anzeigen.
• 10:06
  Jedes Team sieht dieselben Daten in Echtzeit,
• 10:08
  ohne sich gegenseitig zu stören.
• 10:10
  Klick-Stream-Analysen sind ein weiterer wichtiger Aspekt.
• 10:12
  Stellen Sie sich vor, Sie betreiben eine E-Commerce-Website.
• 10:13
  Jeder Klick, jeder Seitenaufruf, jede Suchanfrage
• 10:15
  und jedes Ereignis bei dem der Nutzer in den wahren Kopf will Liquid
• 10:17
  wird an Event-Hubs gesendet.
• 10:18
  Das ist ein riesiger Strom von Daten zum Nutzerverhalten.
• 10:20
  Nachgelagerte Verbraucher analysieren den Strom in Echtzeit.
• 10:23
  Ein Verbraucher erstellt Benutzerprofile,
• 10:24
  die zeigen, welche Produkte sich die Nutzer ansehen
• 10:26
  und welche Kategorien sie durchsuchen.
• 10:27
  Ein anderer Verbraucher erkennt Trends
• 10:29
  und sieht, welche Produkte plötzlich beliebt sind.
• 10:31
  Ein dritter Verbraucher personalisiert das Einkaufserlebnis,
• 10:34
  indem er Empfehlungen auf der Grundlage dessen anzeigt,
• 10:35
  worauf der Nutzer gerade geklickt hat.
• 10:37
  All dies geschieht in Millisekunden, nicht über Nacht.
• 10:39
  Und dann ist da noch die Betrugserkennung im Finanzwesen.
• 10:41
  Banken verarbeiten jeden Tag Millionen von Transaktionen.
• 10:44
  Kreditkartenabbuchungen, Überweisungen, Online-Zahlungen.
• 10:47
  Jede Transaktion ist ein Ereignis
• 10:48
  und jede einzelne muss in Echtzeit auf Betrug hin bewertet werden.
• 10:51
  Sie können nicht auf einen Batch-Auftrag warten,
• 10:53
  denn wenn eine betrügerische Transaktion durchgeführt wird,
• 10:55
  ist das Geld weg.
• 10:55
  Daher überträgt die Bank jede Transaktion an Event-Hubs.
• 10:58
  Nachgelagerte Machine-Learning-Modelle
• 11:00
  verarbeiten den Datenstrom
• 11:01
  und bewerten jede Transaktion auf Betrugsrisiko.
• 11:03
  Verdächtige Transaktionen werden innerhalb von Sekunden
• 11:05
  gekennzeichnet und blockiert.
• 11:07
  In der Zwischenzeit speisen separate Verbrauchergruppen
• 11:09
  denselben Datenstrom in Compliance-Systeme
• 11:10
  für die Berichterstattung über gesetzliche Bestimmungen
• 11:12
  und in operative Dashboards
• 11:13
  zur Überwachung des Transaktionsvolumens ein.
• 11:15
  Drei verschiedene Verbraucher,
• 11:16
  die alle denselben Datenstrom lesen
• 11:17
  und dabei unterschiedliche Dinge tun.
• 11:19
  Der rote Faden, der sich durch alle diese Szenarien zieht,
• 11:21
  ist derselbe.
• 11:21
  Hohes Volumen, mehrere Verbraucher
• 11:23
  und die Notwendigkeit von Echtzeit-Informationen.
• 11:25
  Event-Hubs ist nicht die Lösung für jedes Problem,
• 11:27
  aber in dieser Kombination ist es das richtige Tool
• 11:29
  für die Aufgabe.
• 11:31
  Nun ist Event-Hubs nicht der einzige Messaging-Dienst in Azure.
• 11:34
  Vergleichen wir mit den anderen.
• 11:35
  Event-Hubs im Vergleich zu Event-Grid und Service-Bus.
• 11:38
  Azure verfügt über drei Hauptdienste
• 11:39
  zum Verschieben von Daten.
• 11:41
  Event-Grid, Event-Hubs und Service-Bus.
• 11:43
  Diese werden oft verwechselt,
• 11:44
  deshalb wollen wir das Ganze aufklären.
• 11:46
  Event-Grid ist der Rauchmelder.
• 11:47
  Es ist schlank und reaktionsschnell.
• 11:48
  Wenn etwas passiert,
• 11:50
  wird ein Blob in den Speicher hochgeladen.
• 11:52
  Der Status eines virtuellen Computers ändert sich.
• 11:55
  Eine Ressource wird erstellt.
• 11:56
  Event-Grid löst ein Ereignis aus.
• 11:58
  Es überträgt nicht die Daten selbst,
• 11:59
  sondern meldet nur, hey, etwas ist passiert.
• 12:01
  Anschließend wird diese Benachrichtigung an Händler
• 12:02
  wie Azure Functions oder Logic Apps weitergeleitet.
• 12:04
  Event-Grid ist kein Datenstrom
• 12:06
  und nicht für hohen Durchsatz konzipiert.
• 12:08
  Es wird für diskrete Ereignisse vorgesehen,
• 12:09
  die eine schnelle Reaktion erfüllen.
• 12:10
  Es eignet sich am besten für Trigger zum Hochladen von Blobs,
• 12:12
  Änderungen des Ressourcenstatus
• 12:13
  und serverlose Workflows.
• 12:15
  Service-Bus ist der Postdienst.
• 12:16
  Er ist zuverlässig geordnet und garantiert die Zustellung.
• 12:19
  Wenn Sie eine Nachricht über Service-Bus senden,
• 12:21
  wissen Sie, dass sie ankommen.
• 12:22
  Service-Bus unterstützt die First-in-First-out-Reihenfolge
• 12:24
  der Erkennung von Duplikaten und Transaktionen.
• 12:26
  Wenn eine Nachricht nicht verarbeitet werden kann,
• 12:27
  wird sie in eine Warteschlange für unzustellbare Nachrichten verschoben,
• 12:29
  in der Sie sich später überprüfen können.
• 12:30
  Service-Bus wurde für geschäftskritische Workflows
• 12:32
  wie Zahlungsabwicklung, Auftragserfüllung
• 12:34
  und Genehmigungsketten entwickelt.
• 12:36
  Service-Bus verarbeitet tausende von Nachrichten pro Sekunde,
• 12:38
  nicht Millionen.
• 12:38
  Das ist auch gut so,
• 12:39
  denn wenn Sie eine Zahlung verarbeiten,
• 12:40
  benötigen Sie nicht Millionen von Ereignissen pro Sekunde.
• 12:42
  Jede einzelne Nachricht muss genau einmal
• 12:44
  in der richtigen Reihenfolge ankommen.
• 12:45
  EventHubs ist die Überwachungskamera.
• 12:47
  Es zeichnet alles zur Wiedergabe und Analyse auf.
• 12:50
  Das wurde für Streaming mit hohem Volumen
• 12:51
  und Millionen von Ereignissen pro Sekunde entwickelt
• 12:53
  und mehrere Consumer können denselben Stream
• 12:54
  unabhängig von Analysen.
• 12:56
  Ereignisse verbleiben Tage oder Wochen lang im Hub,
• 12:58
  sodass Sie sie bei Bedarf erneut abspielen können.
• 12:59
  EventHubs ist nicht für Transaktionsnachrichten vorgesehen.
• 13:02
  Es ist für Telemetriedaten,
• 13:03
  Analysepipelines und alle Szenarien vorgesehen,
• 13:05
  in denen Sie große Datenmengen erfassen
• 13:07
  und an mehrere Consumer verteilen müssen.
• 13:08
  Wie treffen Sie also Ihre Entscheidung?
• 13:10
  Stellen Sie sich drei Fragen.
• 13:11
  Reagieren Sie auf eine Änderung.
• 13:12
  Ein Blob wurde hochgeladen, eine VM wurde erstellt,
• 13:15
  der Status einer Ressource wurde geändert.
• 13:16
  Das ist EventGrid.
• 13:17
  Benötigen Sie eine garantierte Zustellung,
• 13:19
  eine strikte Reihenfolge.
• 13:20
  Zahlungen verarbeiten, Workflows ausführen,
• 13:22
  Geschäftstransaktionen koordinieren,
• 13:23
  das ist Servicebus.
• 13:24
  Streamen Sie große Datenmengen für Analysen,
• 13:26
  IoT-Telemetriedaten, Anwendungsprotokolle,
• 13:28
  Clickstreams oder zur Betrugserkennung
• 13:29
  oder zur Betrugserkenntung.
• 13:30
  Das ist EventHubs.
• 13:32
  Aber das ist der Clou.
• 13:33
  Sie müssen sich nicht für einen von beiden entscheiden.
• 13:34
  Diese Dienste arbeiten zusammen.
• 13:35
  EventHubs erfassen den Rohdatenstrom.
• 13:38
  EventGrid reagiert auf Ereignisse in diesem Strom
• 13:40
  und löst nachgelagerte Aktionen aus.
• 13:42
  Servicebus verarbeitet die zuverlässige Nachrichtenübermittlung
• 13:44
  für Geschäftsworkflows.
• 13:45
  Wenn Sie beides zusammen verwenden,
• 13:46
  erhalten Sie das Beste aus beiden Welten.
• 13:48
  Sprechen wir über die Kosten für den Betrieb dieser Art von Pipeline.
• 13:51
  Preise und Tarife
• 13:51
  Sprechen wir über die Kosten,
• 13:53
  denn zu wissen, was EventHubs leistet, ist eine Sache.
• 13:55
  Aber zu wissen, was es kostet, ist eine ganz andere.
• 13:57
  EventHubs verfügt über vier Tarife,
• 13:58
  wobei Basic der günstigste ist.
• 13:59
  Er bietet einen Tag Aufbewahrungsdauer,
• 14:01
  eingeschränkte Features
• 14:02
  und die niedrigsten Kosten pro Durchsatzeinheit.
• 14:04
  Dies eignet sich für einfache Szenarien,
• 14:06
  in denen Sie nicht viel benötigen.
• 14:07
  Die meisten Benutzer überspringen jedoch Basic
• 14:08
  und beginnen mit Stand.
• 14:09
  Standard ist die optimale Lösung.
• 14:11
  Sie bietet bis zu sieben Tage Aufbewahrungsdauer,
• 14:13
  EventHubs Capture für die automatische Archivierung im Speicher,
• 14:15
  Kafka-Kompatibilität
• 14:16
  und bis zu 20 Consumer-Gruppen.
• 14:19
  Dies deckt die meisten Produktionsworkloads.
• 14:20
  Wenn Sie also etwas Konkretes entwickeln,
• 14:22
  sollten Sie in der Regel hier beginnen.
• 14:23
  Premium ist eine Stufe höher.
• 14:24
  Sie erhalten 90 Tage Aufbewahrungsdauer,
• 14:26
  1TB Speicher pro Verarbeitungseinheit,
• 14:28
  vorhersagbare Leistungen
• 14:29
  für die Netunterstützung für die Netzwerkisolierung.
• 14:32
  Diese Stufe ist für anspruchsvolle Workloads konzipiert,
• 14:35
  bei denen Latenz und Isolation eine richtige Rolle spielen.
• 14:37
  Dedicate ist die oberste Stufe.
• 14:38
  Ein Single-Tenant-Cluster
• 14:39
  nur für Sie mit 10TB pro Kapazitätseinheiten.
• 14:42
  Er eignet sich für sehr große Workloads,
• 14:43
  bei denen Sie die gesamte Umgebung für sich benötigen.
• 14:45
  Ja, er ist teuer,
• 14:46
  aber wenn Sie kontinuierlich große Mengen verarbeiten,
• 14:48
  kann er kostengünstiger sein als die Skalierung Premium.
• 14:51
  Was sind also die Kostentreppen?
• 14:52
  Vier Faktoren.
• 14:54
  Durchsatzeinheiten?
• 14:54
  Die Menge der zu verschiebenden Daten.
• 14:57
  Aufbewahrungsdauer?
• 14:58
  Wie lange Sie Ereignisse aufbewahren?
• 14:59
  Erfassung, ob Sie im Speicher archivieren?
• 15:01
  Und Georeplikation,
• 15:03
  wenn Sie Daten für die Notfallwiederherstellung
• 15:04
  regionsübergreifend kopieren.
• 15:06
  Hier sind ein paar Tipps zur Kostenoptimierung.
• 15:08
  Beginnen Sie mit Standard
• 15:09
  und skalieren Sie nur bei Bedarf hoch.
• 15:11
  Verwenden Sie eine kurze Aufbewahrungsdauer für wichtige Daten.
• 15:13
  Bewahren Sie die Daten ein oder zwei Tage im Hub auf
• 15:15
  und lagern Sie sie dann für die Langzeitanalyse
• 15:17
  in einen kostengünstigen Speicher wie Blob oder Dadalek aus.
• 15:19
  Überwachen Sie Ihre Durchsatznutzung,
• 15:20
  dimensionieren Sie Ihre TOs richtig
• 15:21
  und stellen Sie nicht zu viele Daten.
• 15:22
  Verwenden Sie außerdem nach Möglichkeit
• 15:24
  HTTP für Absender anstelle von AMQP,
• 15:27
  da für AMQP-Verbindungen Gebühren anfallen,
• 15:29
  für HTTP jedoch nicht.
• 15:30
  Sehen wir uns nun eine einfache Architektur an,
• 15:32
  um zu sehen, wie Sie tatsächlich loslegen.
• 15:34
  Erste Schritte, eine einfache Architektur.
• 15:36
  Das grundlegende Muster ist einfach.
• 15:38
  Produzenten senden Ereignisse an Event Hubs
• 15:39
  und Konsumenten lesen von Event Hubs.
• 15:41
  Das ist alles.
• 15:42
  Hier ist ein konkretes Beispiel.
• 15:44
  Stellen Sie sich vor,
• 15:44
  IoT-Geräte senden Temperaturdaten an Event Hubs.
• 15:47
  Eine Azure-Funktion wird durch jeden neuen Batch
• 15:49
  von Ereignissen ausgelöst
• 15:50
  und die Funktion verarbeitet die Daten.
• 15:51
  Sie filtert möglicherweise Messwerte heraus,
• 15:53
  die im normalen Bereich liegen,
• 15:54
  behält nur die Anomalien bei
• 15:55
  und schreibt diese dann zur schnellen Abfrage in Cosmos DB.
• 15:58
  Das ist eine vollständige Pipeline in drei Diensten.
• 16:00
  Das Schöne an Funktionen ist,
• 16:01
  dass sie automatisch mit ihrer Partitionsanzahl skaliert werden.
• 16:04
  Wenn Sie über acht Partitionen verfügen,
• 16:05
  können Funktionen bis zu acht Instanzen hochfahren,
• 16:07
  wobei jeder Messwert
• 16:08
  und schreibt diese dann aufgrund der Abfrage in Cosmos DB.