Le aziende basate sui dati devono mantenere i sistemi back-end e di analisi quasi in tempo reale con le applicazioni rivolte ai clienti. L'impatto delle transazioni, degli aggiornamenti e delle modifiche deve riflettere in modo accurato tramite processi end-to-end, applicazioni correlate e sistemi OLTP (Online Transaction Processing). La latenza tollerabile per le modifiche nelle applicazioni OLTP da riflettere nei sistemi downstream che usano i dati potrebbe essere di pochi minuti.
Questo articolo descrive una soluzione end-to-end per l'elaborazione dei dati quasi in tempo reale per mantenere sincronizzati i dati lakehouse. La soluzione usa Hub eventi di Azure, Azure Synapse Analytics e Azure Data Lake Storage per l'elaborazione e l'analisi dei dati.
Apache e Apache® Spark sono marchi registrati o marchi di Apache Software Foundation nei Stati Uniti e/o in altri paesi. L'uso di questi marchi non implica alcuna approvazione da parte di Apache Software Foundation.
Architettura
Scaricare un file di Visio di questa architettura.
Flusso di dati
Change Data Capture è un prerequisito per i sistemi di origine per ascoltare le modifiche. I connettori debezium possono connettersi a sistemi di origine diversi e sfruttare le modifiche man mano che si verificano. I connettori possono acquisire modifiche e produrre eventi da vari sistemi di gestione di database relazionali (RDBMS). L'installazione di un connettore Debezium richiede un sistema di connessione Kafka.
I connettori estraggono i dati delle modifiche e inviano gli eventi acquisiti a Hub eventi di Azure. Hub eventi può ricevere grandi quantità di dati da più origini.
Hub eventi trasmette direttamente i dati ai pool di Spark di Azure Synapse Analytics oppure può inviare i dati a una zona di destinazione di Azure Data Lake Storage in formato non elaborato.
Altre origini dati batch possono usare le pipeline di Azure Synapse per copiare dati in Data Lake Storage e renderle disponibili per l'elaborazione. Un flusso di lavoro di estrazione, trasformazione e caricamento end-to-end potrebbe dover concatenare passaggi diversi o aggiungere dipendenze tra i passaggi. Le pipeline di Azure Synapse possono orchestrare le dipendenze del flusso di lavoro all'interno del framework di elaborazione complessivo.
I pool di Spark di Azure Synapse usano API di streaming strutturate Apache Spark completamente supportate per elaborare i dati nel framework di streaming Spark. Il passaggio di elaborazione dati incorpora controlli di qualità dei dati e convalide delle regole business di alto livello.
Data Lake Storage archivia i dati convalidati nel formato Delta Lake aperto. Delta Lake offre semantica, coerenza, isolamento e durabilità (ACID) semantica e transazioni, la gestione scalabile dei metadati e l'elaborazione unificata dei dati in streaming e batch per i data lake esistenti.
L'uso degli indici per l'accelerazione delle query aumenta Delta con ulteriori miglioramenti delle prestazioni. I dati della zona convalidata di Data Lake Storage possono anche essere un'origine per analisi avanzate e Machine Learning.
I dati della zona convalidata di Data Lake Storage, trasformati e arricchiti con più regole nello stato elaborato finale, vengono caricati in un pool SQL dedicato per l'esecuzione di query analitiche su larga scala.
Power BI usa i dati esposti tramite il pool SQL dedicato per creare dashboard e report di livello aziendale.
È anche possibile usare i dati non elaborati acquisiti nella zona di destinazione di Data Lake Store e i dati convalidati nel formato Delta per:
- Analisi esplorativa e ad hoc tramite pool serverless di Azure Synapse SQL.
- Machine Learning tramite Azure Machine Learning.
Per alcune interfacce a bassa latenza, i dati devono essere denormalizzati per latenze server a cifra singola. Questo scenario di utilizzo è principalmente per le risposte api. Questo scenario esegue query su documenti in un archivio dati NoSQL, ad esempio Azure Cosmos DB, per le risposte in millisecondi a cifra singola.
La strategia di partizionamento di Azure Cosmos DB potrebbe non prestarsi a tutti i modelli di query. In questo caso, è possibile aumentare la soluzione indicizzando i dati a cui devono accedere le API con Ricerca cognitiva di Azure. Azure Cosmos DB e Ricerca cognitiva possono soddisfare la maggior parte degli scenari che richiedono risposte di query a bassa latenza.
Componenti
Questa soluzione usa i componenti di Azure seguenti:
Hub eventi è un servizio di inserimento distribuito gestito che può essere ridimensionato per inserire grandi quantità di dati. Con il meccanismo di pubblicazione sottoscrittore di Hub eventi, diverse applicazioni possono inviare messaggi agli argomenti in Hub eventi e i consumer downstream possono connettersi ed elaborare i messaggi. La funzionalità di acquisizione di Hub eventi può scrivere messaggi in Data Lake Storage in formato AVRO man mano che arrivano. Questa funzionalità consente di semplificare l'elaborazione di micro batch e scenari di conservazione a lungo termine. Hub eventi offre anche un'API compatibile con Kafka e supporta il Registro di sistema dello schema.
Data Lake Storage costituisce il sottosistema di archiviazione che archivia tutti i dati in formati non elaborati e convalidati. Data Lake Storage può gestire le transazioni su larga scala e supporta formati e dimensioni di file diversi. Gli spazi dei nomi gerarchici consentono di organizzare i dati in una struttura di cartelle familiare e supportano le autorizzazioni Portable Operating System Interface per uniX (POSIX). Il driver ABFS (Blob File system) di Azure offre un'API compatibile con Hadoop.
Azure Synapse Analytics è un servizio di analisi senza limiti che riunisce funzionalità di integrazione dei dati, archiviazione dati aziendali e analisi di Big Data. Questa soluzione usa le funzionalità seguenti dell'ecosistema di Azure Synapse Analytics:
I pool di Spark di Azure Synapse offrono un runtime Spark su richiesta che aggiunge miglioramenti delle prestazioni predefiniti a Spark open source. I clienti possono configurare impostazioni di scalabilità automatica flessibili, inviare processi in remoto tramite l'endpoint Apache Livy e usare l'interfaccia notebook di Synapse Studio per esperienze interattive.
I pool serverless di Azure Synapse SQL forniscono un'interfaccia per eseguire query sui dati lakehouse usando una sintassi T-SQL familiare. Non esiste un'infrastruttura da configurare e la distribuzione dell'area di lavoro di Azure Synapse crea automaticamente l'endpoint. I pool serverless di Azure Synapse SQL consentono l'individuazione di base e l'esplorazione dei dati sul posto e rappresentano un'ottima opzione per l'analisi di query ad hoc dell'utente.
I pool SQL dedicati di Azure Synapse archiviano i dati in tabelle relazionali con archiviazione a colonne. I pool SQL dedicati usano un'architettura con scalabilità orizzontale per distribuire l'elaborazione dei dati tra più nodi. Le query PolyBase inseriscono i dati nelle tabelle del pool SQL. Le tabelle possono connettersi a Power BI per l'analisi e la creazione di report.
Power BI offre un'interfaccia visiva per creare e accedere a report e dashboard. Power BI Desktop può connettersi a varie origini dati, combinare le origini in un modello di dati e creare report o dashboard. Con Power BI è possibile trasformare i dati in base ai requisiti aziendali e condividere oggetti visivi e report con altri utenti tramite il servizio Power BI.
Azure Cosmos DB è un database NoSQL gestito multi modale che supporta API aperte, ad esempio MongoDB e Cassandra. Questa soluzione usa Azure Cosmos DB per le applicazioni che richiedono tempi di risposta in millisecondi a cifra singola e disponibilità elevata. Azure Cosmos DB offre scritture in più aree in tutte le aree di Azure. È possibile usare Azure Collegamento a Synapse per Azure Cosmos DB per derivare informazioni dettagliate ed eseguire analisi sui dati in tempo reale.
Ricerca cognitiva di Azure è un servizio di ricerca cloud in grado di indicizzare i dati necessari per le applicazioni e le API. Ricerca cognitiva offre funzionalità di arricchimento tramite intelligenza artificiale facoltative che consentono l'estrazione del testo e l'inferenza di testo da file non di testo. Ricerca cognitiva si integra con servizi come Azure Data Lake Storage e Azure Cosmos DB per accedere e indicizzare facilmente i dati. È possibile eseguire query sui dati indicizzati usando un'API REST o .NET SDK. Per ottenere dati da due indici separati, è possibile combinarli in un singolo indice o usare tipi di dati complessi.
Dettagli dello scenario
Il flusso di lavoro end-to-end per elaborare le modifiche quasi in tempo reale richiede:
- Tecnologia CDC (Change Data Capture). Le applicazioni OLTP potrebbero avere archivi dati back-end diversi, ad esempio SQL Server, MySQL e Oracle. Il primo passaggio consiste nell'ascoltare le modifiche man mano che si verificano e propagarle in avanti.
- Buffer di inserimento per pubblicare gli eventi di modifica su larga scala. Questo servizio deve avere la possibilità di gestire grandi quantità di dati all'arrivo dei messaggi. I singoli sottoscrittori possono connettersi a questo sistema ed elaborare i dati.
- Archiviazione distribuita e scalabile per i dati così come sono in un formato non elaborato.
- Un sistema di elaborazione dei flussi distribuito ed efficiente che consente agli utenti di riavviare e gestire lo stato.
- Un sistema di analisi eseguito su larga scala per prendere decisioni aziendali.
- Interfaccia di analisi self-service.
- Per le risposte API a bassa latenza, un database NoSQL per archiviare la rappresentazione denormalizzata dei dati.
- Per alcuni casi, un sistema per indicizzare i dati, aggiornare l'indice a intervalli regolari e rendere disponibili i dati più recenti per l'utilizzo downstream.
Tutte le tecnologie precedenti devono usare costrutti di sicurezza pertinenti per la sicurezza perimetrale, l'autenticazione, l'autorizzazione e la crittografia dei dati.
Potenziali casi d'uso
Questa soluzione è ideale per:
- Settori che devono propagare le modifiche da OLTP all'elaborazione di analisi online (OLAP).
- Applicazioni che richiedono la trasformazione o l'arricchimento dei dati.
Lo scenario di elaborazione dei dati in tempo reale è particolarmente importante per i settori dei servizi finanziari. Ad esempio, se un cliente assicurativo, carta di credito o cliente bancario effettua un pagamento e quindi contatta immediatamente il servizio clienti, l'agente di supporto clienti deve avere le informazioni più recenti.
Scenari simili si applicano ai settori della vendita al dettaglio, del commercio e del settore sanitario. L'abilitazione di questi scenari semplifica le operazioni, aumentando la produttività dell'organizzazione e aumentando la soddisfazione dei clienti.
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.
Affidabilità
L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.
Hub eventi offre la conservazione dei dati di 90 giorni nei livelli Premium e dedicati. Per gli scenari di failover, è possibile configurare uno spazio dei nomi secondario nell'area abbinata e attivarlo durante il failover.
I processi del pool di Spark di Azure Synapse vengono riciclati ogni sette giorni perché i nodi vengono disattivati per la manutenzione. Si consideri questa attività mentre si lavora attraverso i contratti di servizio (SLA) associati al sistema. Questa limitazione non è un problema per molti scenari in cui l'obiettivo del tempo di ripristino (RTO) è di circa 15 minuti.
Ottimizzazione dei costi
L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.
È possibile scegliere tra diversi livelli di Hub eventi in base alle caratteristiche del carico di lavoro. Hub eventi fattura l'archiviazione di Acquisizione separatamente, in base alla quantità di dati archiviati in Data Lake Storage.
Prendere in considerazione la gestione del ciclo di vita degli oggetti tramite livelli in Azure Data Lake Storage. Con l'età dei dati, è possibile spostare i dati da un livello ad accesso frequente, in cui è necessario accedere ai dati recenti per l'analisi, a un livello di archiviazione ad accesso sporadico molto inferiore. Il livello di archiviazione a freddo è un'opzione conveniente per la conservazione a lungo termine.
È possibile sospendere il pool SQL dedicato quando non viene usato negli ambienti di sviluppo o test. È possibile pianificare uno script per sospendere il pool in base alle esigenze oppure sospendere manualmente il pool tramite il portale.
Azure Cosmos DB offre modelli di provisioning diversi, ad esempio serverless, velocità effettiva con provisioning manuale e scalabilità automatica. Provare a usare il provisioning serverless per i carichi di lavoro di sviluppo e test. È anche possibile usare la scalabilità automatica, in cui è possibile impostare unità richiesta massime al secondo (UR/sec) nel contenitore. La velocità effettiva del contenitore viene ridimensionata automaticamente tra il 10% del numero massimo di UR/sec come soglia inferiore e il numero massimo di UR/sec configurato.
Efficienza prestazionale
L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere Panoramica del pilastro dell'efficienza delle prestazioni.
È possibile ridimensionare Hub eventi tramite il partizionamento. Prendere in considerazione il partizionamento dei dati per mantenere l'ordine degli eventi tramite un log di commit. Il partizionamento consente di creare più log paralleli ottimizzando la capacità di velocità effettiva disponibile.
È possibile configurare i pool di Azure Synapse Spark con SKU di macchine virtuali (VM) di piccole, medie o grandi dimensioni, in base al carico di lavoro. È anche possibile configurare la scalabilità automatica nei pool di Azure Synapse Spark per tenere conto dei carichi di lavoro spiky. Se sono necessarie più risorse di calcolo, i cluster aumentano automaticamente per soddisfare la domanda e aumentano le prestazioni dopo il completamento dell'elaborazione.
Usare le procedure consigliate per la progettazione di tabelle nel pool SQL dedicato. Si applicano i limiti di prestazioni e scalabilità associati, in base al livello su cui è in esecuzione il pool SQL.
Azure Cosmos DB usa le partizioni per ridimensionare i contenitori, in base a una chiave di partizione. Tutti i dati basati su una chiave di partizione costituisce una partizione logica. Assicurarsi di scegliere la strategia di partizionamento corretta in base ai requisiti del carico di lavoro. È anche possibile usare gli indici per un recupero dei dati più rapido.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Pratima Valavala | Cloud Solution Architect
Altro collaboratore:
- Rajesh Mittal | Cloud Solution Architect
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
- connettore Hub eventi di Azure per Apache Spark
- Scalabilità con Hub eventi
- Indicizzare i dati da Azure Cosmos DB
- Che cos'è Collegamento ad Azure Synapse per Azure Cosmos DB?
- Procedure consigliate per il pool SQL dedicato
- Procedure consigliate per il pool SQL serverless
- Modellare, eseguire query ed esplorare i dati in Azure Synapse
- Creare soluzioni di analisi dei dati usando pool SQL serverless di Azure Synapse