Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / Azure Event Hubs spiegato: streaming di dati in tempo reale con partizioni, consumer group e Kafka (Doppiaggio IA)

Transcript

Azure Event Hubs spiegato: streaming di dati in tempo reale con partizioni, consumer group e Kafka (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Speaker 2: Pronto per dieci giorni di Microsoft 365 Copilot, intelligenza artificiale,
0:04
Speaker 2: Azure e le persone che stanno plasmando il futuro del lavoro?
0:08
Speaker 2: A gennaio torna M365Con e ci stiamo espandendo. Unisciti a
0:13
Speaker 2: noi per sessioni live, dimostrazioni pratiche e conoscenze pratiche da
0:16
Speaker 2: parte di MVP ed esperti del settore di tutto il mondo.
0:18
Speaker 2: Nessuna slide generica, nessun termine di moda infinito. Stiamo affrontando
0:22
Speaker 2: le vere sfide. Copilot Studio, agenti di intelligenza artificiale, Fabric, sicurezza,
0:27
Speaker 2: governance e automazione. Anche tu sia un professionista IT, uno
0:31
Speaker 2: sviluppatore o un leader aziendale, ci sono sessioni pensate per te.
0:35
Speaker 2: Con 10 giorni interi puoi esplorare più tecnologie e connetterti
0:38
Speaker 2: con una community globale. Guarda la diretta e porta spunti
0:42
Speaker 2: pratici alla tua organizzazione. Gennaio 2027. 10 giorni. Una community Microsoft.
0:49
Speaker 2: Le registrazioni sono aperte ora. Vai subito a casa tua.
0:54
Speaker 2: Questo è m3santacinquecon. net. it Iscriviti ora su m365con. net e ci vediamo
1:03
Speaker 2: dal vivo a gennaio. Bentornati ad un altro episodio di
1:06
Speaker 2: Microsoft Knowledge Nuggets. Sono il vostro ospite Mirko Peters e
1:09
Speaker 2: oggi affronteremo un problema di dati del mondo reale. Lasciate
1:12
Speaker 2: che vi chiedo questo. Immaginate di essere una fabbrica con
1:14
Speaker 2: mille sensori, temperatura, pressione, vibrazione, tutto in funzione costantemente che
1:18
Speaker 2: ci inviano una lettura ogni secondo. Quindi si tratta di
1:20
Speaker 2: mille punti dati ogni singolo secondo. Vent'anni fa la soluzione
1:23
Speaker 2: era semplice. Raccoglievate tutti quei dati durante il giorno, li
1:27
Speaker 2: archiviaste in un file, quindi eseguivate un processo batch a
1:29
Speaker 2: mezzanotte per elaborarli, e la mattina dopo avreste avuto un
1:31
Speaker 2: report che mostrava cosa era successo il giorno prima. Funzionava
1:34
Speaker 2: bene quando abbastanza velocemente, significava entro la mattina successiva. Ma
1:37
Speaker 2: il mondo è cambiato. I sensori sono diventati più economici,
1:40
Speaker 2: le app più intelligenti e gli utenti si aspettano risposte immediate. Ora,
1:43
Speaker 2: quel processo batch notturno significa che i vostri dati sono
1:45
Speaker 2: sempre vecchi di un giorno e in un mondo in
1:47
Speaker 2: cui il surriscaldamento di una macchina può causare un incendio
1:49
Speaker 2: e una macchina può causare un incendio in pochi minuti
1:50
Speaker 2: in un giorno in più. Quindi passate al tempo reale
1:52
Speaker 2: raccogliendo i dati nel momento in cui vengono generate. È
1:55
Speaker 2: qui che iniziano i problemi. Se provi a inserire tutti
1:58
Speaker 2: quei dati in streaming in un database tradizionale, si blocca.
2:01
Speaker 2: I database sono creati per query e transazioni, non per
2:04
Speaker 2: l'acquisizione di un flusso di eventi. Provi con una normale
2:07
Speaker 2: coda di messaggi e funziona per un po' prima, ma
2:09
Speaker 2: le code sono progettate per consentire a un singolo consumatore
2:11
Speaker 2: di acquisire un messaggio ed elaborarlo. Quindi non sono create
2:14
Speaker 2: per milioni di eventi al secondo, con più sistemi downstream
2:17
Speaker 2: che vogliono leggere lo stesso flusso. Questa è la sfida principale.
2:22
Speaker 2: Hai bisogno di un modo per acquisire enormi quantità di dati,
2:24
Speaker 2: memorizzarli nel buffer in modo da non perdere nulla e
2:27
Speaker 2: distribuirli a più consumatori, il tutto in tempo reale? Non
2:29
Speaker 2: è un problema di database. Non è un problema di coda.
2:31
Speaker 2: Il problema è il streaming. Qual è la soluzione? È
2:34
Speaker 2: qui che entra in gioco Azure Event Hub. Cos'è Azure
2:36
Speaker 2: Event Hub? Ecco la definizione più semplice. Azure Event Hub
2:40
Speaker 2: è una piattaforma di streaming di dati in tempo reale
2:42
Speaker 2: completamente gestita, creata appositamente per acquisire milioni di eventi al
2:45
Speaker 2: secondo con bassa latenza. Nota che non ho parlato di
2:47
Speaker 2: coda di messaggi o database. Event Hub non è una
2:50
Speaker 2: coda e non è un database. È uno stream e
2:53
Speaker 2: la differenza è importante. Una coda conserva un messaggio finché
2:55
Speaker 2: un consumer non lo prende e dopodiché scompare. Un database
2:58
Speaker 2: archivia i dati in modo da poterli interrogare in un
3:00
Speaker 2: secondo momento, ma uno stream è diverso. È un flusso
3:02
Speaker 2: continuo di eventi che più lettori possono leggere in modo
3:04
Speaker 2: indipendente al proprio ritmo senza rimuovere nulla dallo stream. Ora
3:09
Speaker 2: chiariamo alcuni miti. Event Hub può gestire milioni di eventi
3:12
Speaker 2: al secondo. Stiamo parlando di acquisire centinaia di migliaia di
3:15
Speaker 2: messaggi ogni singolo secondo da migliaia di producer e lo
3:17
Speaker 2: fa con una latenza molto bassa a millisecondi dal momento
3:20
Speaker 2: in cui un evento viene inviato al momento in cui
3:22
Speaker 2: un consumer può leggerlo. Ecco qualcosa che sorprende molte persone.
3:26
Speaker 2: Event Hub è compatibile con Kafka. Quindi se hai già
3:29
Speaker 2: lavorato con Apache Kafka puoi utilizzare i tuoi strumenti e
3:31
Speaker 2: client Kafka esistenti per comunicare con Event Hub senza dover
3:34
Speaker 2: imparare un nuovo protocollo o riscrivere le tue applicazioni. Parlo
3:37
Speaker 2: lo stesso linguaggio. Il modo più semplice per pensare a
3:40
Speaker 2: questo è che Event Hub sia come una porta d'ingresso
3:41
Speaker 2: per i dati ad alta velocità. Immagina un affollato palazzo
3:44
Speaker 2: di uffici durante l'ora di punto. Centinaia di persone avarcano
3:47
Speaker 2: la porta d'ingresso ogni minuto e la porta non le ferma,
3:49
Speaker 2: non pone domande, né ne indirizza verso stanze specifiche. Semplicemente
3:52
Speaker 2: le fa entrare velocemente. Questo è Ventavo. È la porta
3:55
Speaker 2: d'indirizzo per i tuoi danni. Non li elabora, non li
3:57
Speaker 2: analizza e non decide cosa farne. Li fa semplicemente entrare
4:01
Speaker 2: nel tuo ambiente Azure il più velocemente possibile, in modo
4:03
Speaker 2: che i tuoi sistemi downstream possano svolgere il vero lavoro.
4:05
Speaker 2: Ma come funziona esattamente? Analizziamo i singoli componenti. I componenti
4:08
Speaker 2: di base partiziano i gruppi di consumatori produttivitari. Quindi all'interno
4:11
Speaker 2: di ogni Event Hub c'è una struttura che fa funzionare
4:13
Speaker 2: il tutto. Il componente più importante è la partizione. Pensa
4:16
Speaker 2: a una partizione come un'autostrada. I dati entrano e finiscono
4:19
Speaker 2: in una di queste corsie. Ecco il punto. All'interno di
4:21
Speaker 2: ogni corsia l'ordine degli eventi rimane esattamente come è arrivato.
4:24
Speaker 2: L'evento 1 precede l'evento 2 e l'evento 2 precede l'evento 3.
4:27
Speaker 2: Tale ordine non cambia mai all'interno di tale corsia. Quindi
4:30
Speaker 2: se la tua applicazione necessita di eventi nell'ordine esatto li
4:32
Speaker 2: mantieni nella stessa partizione. Puoi avere da due partizioni per
4:35
Speaker 2: Event Hub imposti questo numero. Quando crei l'Hub non puoi
4:39
Speaker 2: modificarlo in sé. Quindi devi pensare in anticipo alle tue
4:41
Speaker 2: esigenze di produttività. Più partizioni implicano più elaborazione parallela. Se
4:45
Speaker 2: prevedi un volume elevato di eventi vorrai più partizioni in
4:48
Speaker 2: modo che più consumatori possano leggere da corsie diverse contemporaneamente.
4:51
Speaker 2: Tuttavia partizioni implicano anche maggiore complessità. La regola generale è
4:54
Speaker 2: quella di scegliere in base alla produttività prevista, non in
4:57
Speaker 2: modo casuale. Se non sei sicuro inizia con partizioni più
4:59
Speaker 2: piccole e fedele. Ma le partizioni da sole non sono sufficienti.
5:01
Speaker 2: Hai anche bisogno di gruppi consumatori. Un gruppo di consumatori
5:04
Speaker 2: è semplicemente un'applicazione downstream separata che legge lo stesso flusso.
5:07
Speaker 2: Ogni gruppo di consumatori riceve la propria copia indipendente. Quindi
5:10
Speaker 2: se è un gruppo per l'analisi in tempo reale e
5:12
Speaker 2: un altro per l'archiviazione nello storage, entrambi leggono gli stessi
5:15
Speaker 2: eventi contemporaneamente senza interferire. Il gruppo di analisi legge i
5:18
Speaker 2: dati sulla temperatura per rilevare anomalie. Il gruppo di archiviazione
5:21
Speaker 2: legge gli stessi dati e gli invia un data lake
5:23
Speaker 2: per l'archiviazione a lungo termine. Entrambi i gruppi vedono ogni evento.
5:26
Speaker 2: Nessuno dei due blocca l'altro. Questo è un grosso problema.
5:29
Speaker 2: In una coda tradizionale un messaggio viene consumato da un
5:31
Speaker 2: processore e poi scompare. Più consumatori possono leggere lo stesso
5:34
Speaker 2: flusso in modo indipendente. Questa è la potenza dei gruppi
5:36
Speaker 2: di consumatori. Ma come si misura la quantità di dati
5:38
Speaker 2: che Ventab è in grado di gestire? E' qui che
5:40
Speaker 2: entra in gioco l'unità di produttività. Un'unità di produttività o
5:42
Speaker 2: TU è il modo in cui misuriamo la capacità. Una
5:44
Speaker 2: TU fornisce 1 MB al secondo di dati in entrata
5:47
Speaker 2: e 2 MB al secondo di dati in uscita. Quindi
5:50
Speaker 2: se devi acquisire 10 MB al secondo hai bisogno di
5:52
Speaker 2: almeno 10 TU. Puoi aumentare manualmente oppure abilitare l'aumento automatico
5:56
Speaker 2: che aumenta automaticamente le tue TU quando il traffico aumenta.
5:59
Speaker 2: Paghi per il numero massimo di TU utilizzati in un'ora.
6:02
Speaker 2: Quindi se imposti 20 TU per 10 minuti ne avrai
6:05
Speaker 2: 20 per quell'ora intera. Un altro aspetto è la conservazione.
6:09
Speaker 2: Gli eventi non scompaiono dal lab dopo essere stati utilizzati.
6:12
Speaker 2: Rimangono nel lab per un periodo configurabile. Nel livello standard
6:14
Speaker 2: vanno da 1 a 7 giorni. Nel livello premium fino
6:16
Speaker 2: a 90 giorni. Ciò consente una funzionalità denominata replay. Se
6:19
Speaker 2: il tuo consumatore avvale non funziona o se devi elaborare
6:22
Speaker 2: i dati per una nuova analisi, puoi tornare indietro e
6:24
Speaker 2: leggere di nuovo i vecchi eventi. Questo è diverso da
6:27
Speaker 2: una coda in cui una volta utilizzato un messaggio perso
6:28
Speaker 2: per sempre. Quindi ora conosci le parti, ma come funzionano
6:31
Speaker 2: effettivamente insieme in un sistema reale? Come funziona? Il modello produttore- consumatore.
6:36
Speaker 2: Esaminiamo il flusso dall'inizio alla fine. Da un lato hai
6:39
Speaker 2: il produttore. Un produttore è qualsiasi applicazione o dispositivo che
6:42
Speaker 2: invia eventi all'hub. Potrebbe essere un sensore di temperatura in
6:45
Speaker 2: una fabbrica, un server web che registra le visualizzazioni di
6:48
Speaker 2: pagina o un'app bancaria che invia dati sulle transazioni. I
6:50
Speaker 2: produttori possono comunicare con gli hub eventi utilizzando tre protocolli diversi, MQP,
6:54
Speaker 2: HTTPS o Kafka. Indipendentemente dal linguaggio o dalla piattaforma utilizzati,
6:58
Speaker 2: esiste un modo per connettere. Quando un produttore invia un evento,
7:00
Speaker 2: l'hub decide in quale partizione deve andare. Per impostazione predefinita,
7:04
Speaker 2: gli eventi vengono distribuiti in modalità roundup. Il primo evento
7:06
Speaker 2: va alla partizione 1, il secondo alla partizione 2, e
7:08
Speaker 2: così via. Tuttavia è anche possibile utilizzare una chiave di partizioni.
7:10
Speaker 2: Se si desidera che tutti gli eventi provenienti dallo stesso
7:12
Speaker 2: dispositivo vengano indirizzati alla stessa partizione, è possibile impostarli nei
7:15
Speaker 2: dispositivi da impostare lì di partizione. In questo modo, l'ordine
7:17
Speaker 2: degli eventi provenienti da tale dispositivo viene preservato. L'Hub insieme
7:19
Speaker 2: non esegue molte elaborazioni. Memorizza gli eventi nel buffer e
7:22
Speaker 2: li archivia nelle partizioni per il periodo di conservazione. Considera
7:25
Speaker 2: lo comunale da te. Gli eventi rimangono lì in attesa
7:27
Speaker 2: che qualcuno li legga? Dall'altro lato ci sono i consumatori.
7:31
Speaker 2: I consumatori sono applicazioni downstream che leggono dal Lab. Ed
7:34
Speaker 2: ecco la parte importante. I consumatori utilizzano un modello pool.
7:37
Speaker 2: Controllano i propri ritmi. Non ricevono eventi push, ma li
7:40
Speaker 2: richiedono quando sono pronti. Questo è diverso da una coda
7:43
Speaker 2: in cui il sistema invia messaggi a un consumer. Qui
7:45
Speaker 2: il consumer decide quando estrarre il batch successivo. Ogni gruppo
7:48
Speaker 2: di consumer tiene traccia della propria posizione nel flusso. Questa
7:51
Speaker 2: posizione è chiamata offset. L'offset indica al consumer quali eventi
7:54
Speaker 2: ha già elaborato. Il consumer archivia questo offset in un
7:58
Speaker 2: punto durevole, in genere nell'archivio blob di Azure. Questo processo
8:01
Speaker 2: è chiamato checkpointing. Ecco perché il checkpointing è importante. Immagina
8:04
Speaker 2: che la tua applicazione consumer si arresti in modo anomalo
8:06
Speaker 2: a metà dell'elaborazione di un batch di event. Quando si riavvia,
8:09
Speaker 2: legge l'ultimo checkpoint dall'archivio blob e riprende da quel punto esatto.
8:13
Speaker 2: Non rielabora vecchi eventi e non salta alcun evento. Riprende
8:16
Speaker 2: esattamente dove si era interrotto. E questa è affidabilità senza complessità.
8:20
Speaker 2: L'intuizione chiave è che Event Hub separa completamente i producer
8:23
Speaker 2: dai consumer. I producer non sanno chi sta leggendo i
8:25
Speaker 2: loro dati. I consumer non sanno chi sta inviando i dati.
8:28
Speaker 2: Sono indipendenti. L'Hub si trova al centro, esegue il buffering
8:31
Speaker 2: e la distribuzione degli eventi e ogni lato opera al
8:32
Speaker 2: tuo ritmo. Ed è proprio questo disaccoppiamento a rendere gli
8:35
Speaker 2: AB20 così potenti per la creazione di sistemi resilienti scalabili.
8:38
Speaker 2: Rendiamolo concreto con scenari reali, casi d'uso reali. Iniziamo con
8:43
Speaker 2: il più grande, la telemetria IoT. Immagina una fabbrica intelligente
8:46
Speaker 2: con migliaia di sensori. Ogni macchina ha sensori che misurano temperatura, pressione,
8:50
Speaker 2: vibrazione e consumo energetico e ognuna invia una lettura ogni
8:53
Speaker 2: pochi secondi. Non si tratta di centinaia di eventi al secondo,
8:56
Speaker 2: bensì di centinaia di migliaia, forse milioni a seconda, delle
8:58
Speaker 2: dimensioni della fabbrica. Non puoi archiviarli in un database tradizionale
9:01
Speaker 2: e non puoi elaborarli con un processo batch eseguito una
9:03
Speaker 2: volta al giorno. Quando ricevi il report, una macchina potrebbe
9:06
Speaker 2: essersi già surriscaldata e aver interrotto la produzione. Quindi, inoltre
9:09
Speaker 2: tutti quei dati dei sensori negli AB20 che acquisiscono i
9:11
Speaker 2: dati senza problemi. Quindi colleghi Azure Stream Analytics all'hub ed
9:16
Speaker 2: esegue query in tempo reale sui dati. Quando una lettura
9:19
Speaker 2: della temperatura supera una soglia, viene generato un avviso, un
9:21
Speaker 2: team di manutenzione viene avvisato e una macchina viene spenta
9:24
Speaker 2: prima che si guasti. Questa è la manutenzione predittiva in azione.
9:27
Speaker 2: Un altro caso d'uso comune è la registrazione e monitoraggio
9:28
Speaker 2: delle applicazioni. Supponiamo di eseguire un'architettura di microservizi con 50
9:32
Speaker 2: servizi diversi che svolgono tutte attività diverse. Ognuno genera registri
9:36
Speaker 2: con errori, avvisi e metriche sulle prestazioni. Nel vecchio mondo
9:39
Speaker 2: scrivevi quei registri in file su ciascun server e quando
9:41
Speaker 2: qualcosa si rompeva accedevi a 5 macchine diverse per trovare l'errore.
9:44
Speaker 2: Questo è un incubo? Invece fai in modo che ogni
9:47
Speaker 2: servizio invii i suoi registri a un singolo event hub,
9:50
Speaker 2: una pipeline centrale. Quindi crei più gruppi di consumatori, Un
9:54
Speaker 2: gruppo legge il flusso e invia errori critici a un
9:56
Speaker 2: sistema di avviso in tempo reale. Un altro gruppo legge
9:59
Speaker 2: lo stesso flusso e scrive tutti i registri su Azure
10:01
Speaker 2: Data Lake per l'archiviazione e l'analisi a lungo termine. Un
10:03
Speaker 2: terzo gruppo alimenta una dashboard in tempo reale che mostra
10:05
Speaker 2: lo stato esistente. Ogni team visualizza gli stessi dati in
10:08
Speaker 2: tempo reale senza interferire l'uno con l'altro. L'analisi del flusso
10:10
Speaker 2: di click è un altro aspetto importante. Immagine di gestire
10:13
Speaker 2: un sito di e- commerce. Ogni click, visualizzazione di pagina, quelli
10:15
Speaker 2: di ricerca aggiunta al carrello, viene inviato a Event Hub.
10:17
Speaker 2: Si tratta di un flusso enorme di dati sul comportamento
10:19
Speaker 2: di utenti. I consumatori a valle analizzano il flusso in
10:22
Speaker 2: tempo reale. Un consumatore crea profili utente che mostrano quali
10:25
Speaker 2: prodotti le persone guardano e quali categorie esplora. Un altro
10:28
Speaker 2: consumatore rileva le tendenze e individua quali prodotti diventano improvvisamente popolari.
10:31
Speaker 2: Un terzo consumatore personalizza l'esperienza di acquisto mostrando consigli basati
10:35
Speaker 2: su ciò su cui l'utente ha appena cliccato. Tutto questo
10:37
Speaker 2: avviene in millisecondi, non da un giorno all'altro. E poi
10:39
Speaker 2: c'è il rilevamento delle fraude nel settore finanziario. Le banche
10:42
Speaker 2: elaborano milioni di transazioni ogni giorno. Strisci di carte di credito, bonifici,
10:45
Speaker 2: pagamenti online... Ogni transazione è un evento e ognuna deve
10:49
Speaker 2: essere valutata per frode in tempo reale. Non puoi aspettare
10:52
Speaker 2: un processo batch perché se una transazione è frodo o
10:54
Speaker 2: lenta viene eseguita e i soldi spariscono, quindi la banca
10:56
Speaker 2: trasmette ogni transazione eventabile. A valle, i modelli di apprendimento
11:00
Speaker 2: automatico utilizzano il flusso e valutano ogni transazione per il
11:02
Speaker 2: rischio di frode e le transazioni sospette vengono segnalate e
11:05
Speaker 2: bloccate in pochi secondi. Nel frattempo, gruppi di consumatori separati
11:09
Speaker 2: alimentano lo stesso flusso e sistemi di conformità per la
11:11
Speaker 2: segnalazione normativa e le dashboard operative per il monitoraggio dei
11:13
Speaker 2: volumi delle transazioni. Tre consumatori diversi, leggono tutti lo stesso flusso,
11:17
Speaker 2: ma svolgono tutte attività diverse. Il filo conduttore di tutti
11:20
Speaker 2: questi scenari è lo stesso. Volume elevato, più consumatori e
11:23
Speaker 2: la necessità di informazioni in tempo reale. Event Hub non
11:26
Speaker 2: è la soluzione a tutti i problemi, ma quando si
11:28
Speaker 2: ha questa combinazione, è lo strumento giusto per il lavoro. Ora,
11:31
Speaker 2: Event Hub non è l'unico servizio di messaggistica in Azure.
11:34
Speaker 2: Confrontiamolo con gli altri. Event Hub, Event Grid e Service Bus.
11:38
Speaker 2: Azure ha tre servizi principali per spostare i dati Event Grid,
11:41
Speaker 2: Event Hub e Service Bus. Le persone li confondono sempre,
11:44
Speaker 2: quindi chiediamo la confusione. Event Grid è l'allarme antincendio. È
11:47
Speaker 2: leggero e reattivo. Quando succede qualcosa, un blob viene caricato nell'archivio,
11:52
Speaker 2: una macchina virtuale cambia stato, viene creata una risorsa. Event
11:56
Speaker 2: Grid genera un evento. Non trasporta i dati stessi e
11:59
Speaker 2: dice solo, ehi, è successo qualcosa. Quindi indirizza la notifica
12:02
Speaker 2: a gestore come funzioni di Azure o App, per la logica.
12:05
Speaker 2: Event Grid non è uno streaming e non è progettato
12:06
Speaker 2: per un'elevata produttività. È pensato per eventi discreti che richiedono
12:09
Speaker 2: reazione rap. È ideale per trigger di caricamento di blob,
12:12
Speaker 2: modifiche dello stato delle risorse e flussi di lavoro senza servo.
12:15
Speaker 2: Service Bus è il servizio postale. È affidabile e ordinato
12:17
Speaker 2: e garantisce la consegna. Quando invii un messaggio tramite Service
12:20
Speaker 2: Bus sai che arriverà. Supporta l'ordinamento first in first out,
12:24
Speaker 2: il rilevamento dei duplicati e le transazioni. Se un messaggio
12:26
Speaker 2: non viene elaborato viene inserito in una coda di messaggi
12:28
Speaker 2: non recapitabili dove poi esaminato in un secondo modo. Service
12:30
Speaker 2: Bus è progettato per flussi di lavoro aziendali critici come
12:33
Speaker 2: l'elaborazione dei pagamenti, l'evasione degli ordini e le catene di approvazione.
12:36
Speaker 2: Gestisce migliaia di messaggi al secondo, non milioni, e questo
12:38
Speaker 2: va bene perché quando elabori un pagamento non hai bisogno
12:40
Speaker 2: di milioni di eventi al secondo, hai bisogno che ogni
12:43
Speaker 2: singolo messaggio arrivi esattamente una volta nell'ordine corretto. Event Hub
12:46
Speaker 2: è la telecamera di sicurezza. Registra tutto per la riproduzione
12:49
Speaker 2: e l'analisi. È progettato per streaming di grandi volumi. Milioni
12:52
Speaker 2: di eventi al secondo e più consumatori possono leggere lo
12:54
Speaker 2: stesso flusso in modo indipendente. Gli eventi rimangono nel Hub
12:57
Speaker 2: per giorni o settimane, quindi puoi riprodurli se necessario. Event
12:59
Speaker 2: Hub non è pensato per la messaggistica transazione. È pensato
13:02
Speaker 2: per la telemetria, le pipeline di analisi e qualsiasi scenario
13:05
Speaker 2: in cui è necessario acquisire enormi quantità di dati e
13:07
Speaker 2: distribuirli a più consumatori. Quindi come decidi? Pogniti tre domande.
13:11
Speaker 2: Stai reggendo un cambiamento. È stato caricato un blob, è
13:13
Speaker 2: stata creata una VM, una risorsa ha cambiato stato. Questo
13:16
Speaker 2: è VentGrid. Hai bisogno di una consegna garantita e di
13:19
Speaker 2: un ordigoloso. Elaborare pagamenti, eseguire flussi di lavoro, coordinare transazioni aziendali.
13:23
Speaker 2: Questo è Service Bus. Stai trasmettendo in streaming enormi quantità
13:26
Speaker 2: di dati per analisi, telemetria IoT, registri delle applicazioni, flussi
13:29
Speaker 2: di click, rilevamento delle fraudi. Questo è VentHub. Ecco il punto.
13:33
Speaker 2: Non devi scegliere solo uno. Questi servizi funzionano insieme. Event
13:36
Speaker 2: Hub acquisisce flusso di dati grezzi. Event Grid reagisce agli
13:39
Speaker 2: eventi all'interno di tale flusso e attivazione a valle. Service
13:42
Speaker 2: Bus gestisce la messaggistica affidabile per i flussi di lavoro aziendali.
13:45
Speaker 2: Utilizzali insieme e otterrai il meglio da entrambi i mondi.
13:48
Speaker 2: Parliamo dei costi di esecuzione di questo tipo di pipeline.
13:51
Speaker 2: Prezzi e livelli. Parliamo di costi perché sapere cosa fa
13:53
Speaker 2: Event Hub è una cosa, ma sapere quanto costa è
13:56
Speaker 2: un'altra cosa. Event Hub ha quattro livelli e Basic è
13:58
Speaker 2: il più economico. Offre un giorno di conservazione, funzionalità limitate
14:02
Speaker 2: e il costo più basso per unità di elaborazione. Funziona
14:05
Speaker 2: per scenari semplici in cui non hai bisogno di molto,
14:07
Speaker 2: ma la maggior parte delle persone salta basic e inizia
14:09
Speaker 2: con standard. Standard è il punto di forza. Offre fino
14:11
Speaker 2: a 7 giorni di conservazione, Event Hub Capture per l'archiviazione
14:14
Speaker 2: automatica nello storage, compatibilità con Kafka e fino a 20
14:17
Speaker 2: gruppi di consumatori. Copre la maggior parte dei carichi di
14:20
Speaker 2: lavoro di produzione, quindi se stai creando qualcosa di concreto,
14:22
Speaker 2: di solito è da qui che niente. Premium è un
14:24
Speaker 2: passo avanti. Ottieni 90 giorni di conservazione, 1 TB di
14:26
Speaker 2: storage per unità di elaborazione, prestazioni prevedibili, supporto VNet per
14:29
Speaker 2: l'isolamento dell'area. Le risorse riservate significano che i vicini rumorosi
14:33
Speaker 2: non ti influenzeranno e questo livello è pensato per carichi
14:35
Speaker 2: di lavoro di fascia alta in cui le latenze di
14:36
Speaker 2: isolamento sono importanti. Dedicato al livello più alto. Un cluster
14:39
Speaker 2: single tenant solo per te con 10 TB per unità
14:41
Speaker 2: di capacità. È pensato per carichi di lavoro molto grandi
14:44
Speaker 2: in cui hai bisogno di un interambiente per te. Sì,
14:45
Speaker 2: è costoso, ma se stai elaborando volumi enormi in modo
14:48
Speaker 2: costante può essere più conveniente rispetto alla scalabilità premium. Quindi
14:51
Speaker 2: cosa determina il costo? 4 fattori. Unità di elaborazione, ovvero
14:55
Speaker 2: la quantità di dati che stai spostando, durata della conservazione,
14:58
Speaker 2: per quanto tempo conservi gli eventi, acquisizione, se stai archiviando
15:01
Speaker 2: nello storage, e replica geografica, se stai copiando dati tra
15:04
Speaker 2: regioni per il ripristino di emergenza. Ecco alcuni suggerimenti per
15:07
Speaker 2: l'ottimizzazione dei costi. Inizia con lo standard e aumenta solo
15:10
Speaker 2: quando necessario. Utilizza la conservazione breve per i dati più richiesti.
15:13
Speaker 2: Conservali nel lab per un giorno o due e quindi
15:15
Speaker 2: scaricali su storage più economici come Blob o Data Lake
15:18
Speaker 2: per analisi a lungo termine. Monitora l'utilizzo della velocità effettiva
15:20
Speaker 2: e ridimensiona correttamente le tue tool senza effettuare un provisioning accesso.
15:23
Speaker 2: Inoltre utilizza HTTP per emittenti anziché AMQP ove possibile, perché
15:27
Speaker 2: le connessioni AMQP hanno dei costi mentre HTTP no. Ora
15:31
Speaker 2: esaminiamo un'architettura semplice per vedere come iniziare. Per iniziare un'architettura semplice.
15:36
Speaker 2: Un modello di base semplice. I produttori inviano eventi a
15:39
Speaker 2: Event Hub e i consumatori leggono da Event Hub. Tutto qui.
15:42
Speaker 2: Ecco un esempio concreto. Immagina che i dispositivi IoT invino
15:45
Speaker 2: dati sulla temperatura a Event Hub. Una funzione di Azure
15:48
Speaker 2: viene attivata da ogni nuovo batch di eventi e la
15:50
Speaker 2: funzione lavora i dati. Potrebbe filtrare letture che rientrano all'intervallo normale,
15:54
Speaker 2: mantenere solo le anomalie e quindi scrivere tali anomalie in
15:56
Speaker 2: Cosmos DB per query rapide. Questa è una pipeline completa
15:59
Speaker 2: in tre servizi. Il bello delle funzioni è che si
16:01
Speaker 2: adattano automaticamente al numero di partizioni. Se hai otto partizioni,
16:05
Speaker 2: le funzioni possono creare fino a otto istanze, ciascuna delle
16:06
Speaker 2: quali esegue una lettura.