progettazione di data warehouse a microservizi

Lascia che il data warehouse dei microservizi non sia più un labirinto: parla di come rendere più fluido il flusso di dati

Parliamo di questo: hai speso molti sforzi per scomporre un enorme sistema in piccoli moduli flessibili: i microservizi. Eseguono i propri compiti e corrono molto velocemente. Ma qui arriva il problema. Ogni servizio genera i propri dati, che sono sparsi in ogni angolo, come isole informative. Quando vuoi vedere il quadro completo dell'intera azienda, eseguire un'analisi o generare un report, scopri che i dati sono come un pezzo di sabbia sparsa, messo insieme qua e là, il che richiede molto tempo, lavoro ed è soggetto a errori.

È come dirigere un'orchestra in cui ogni musicista suona in una tonalità diversa, e potrebbe suonare bene in alcune parti, ma insieme è un disastro. Il tuo data warehouse ha bisogno di un nuovo modo di pensare, un design in grado di comprendere e adattarsi alla natura "silos" ma "che necessita di collaborare" dei microservizi.

Qual è la differenza tra i dati nei microservizi?

In questo caso il design tradizionale e unificato del data warehouse potrebbe scontrarsi con un muro. Il motivo è semplice: il nucleo dei microservizi è l’autonomia e l’implementazione indipendente. Ciò significa:

• La proprietà dei dati è dispersa: il servizio ordini gestisce i dati dell'ordine e il servizio utente gestisce i dati dell'utente. Hanno i propri database e possono anche avere diversi tipi di archiviazione dei dati.
• I moduli dati sono più diversificati: Alcuni servizi utilizzano database relazionali, altri utilizzano database di documenti e le strutture dei dati non sono più uniformi.
• Il cambiamento arriva più velocemente: Un aggiornamento di un servizio non dovrebbe sempre richiedere che l'intera architettura del data warehouse entri in guerra.

Come possiamo costruire un ponte per portare questi dati sparsi ed eterogenei in un luogo dove possiamo analizzare e ottenere approfondimenti in modo ordinato e affidabile? La chiave è progettare un data warehouse in grado di "ascoltare" e "parlare" con ciascun microservizio.

Non solo spostamenti: nuovi flussi di dati per la collaborazione

Un design di data warehouse che si adatta ai microservizi è più simile a un hub di trasporto ben progettato che a un semplice magazzino centralizzato. Deve gestire diversi "flussi di traffico" chiave:

È un flusso "guidato dagli eventi". Molti microservizi moderni comunicano pubblicando eventi. Viene creato un ordine, lo stato di un utente viene aggiornato, questi eventi possono essere catturati in tempo reale e confluiti nel data warehouse. È come installare sensori su ogni strada (microservizio). Una volta che si verifica il flusso di traffico (modifiche dei dati), le informazioni vengono immediatamente trasmesse al centro di comando. Questo metodo ha una bassa latenza e può riflettere bene lo stato attuale del sistema.

Poi c'è Change Data Capture (CDC). Se il servizio non utilizza un meccanismo di eventi, CDC è un potente supplemento. È come un recordkeeper dedicato che monitora continuamente il registro delle modifiche (binlog) del database. Una volta aggiunti, eliminati o modificati, i dati acquisiscono silenziosamente la modifica e la passano al downstream. Ciò garantisce che i dati siano sincronizzati, "copiando" quasi ogni azione alla fonte.

Naturalmente esiste anche la classica sincronizzazione batch. Per alcuni scenari meno urgenti e con una quantità di dati particolarmente elevata, la sincronizzazione regolare dell'intero snapshot dei dati (ad esempio ogni giorno a tarda notte) sarà comunque stabile e affidabile. È come un treno merci di linea. Sebbene non sia in tempo reale, ha una grande capacità di carico e una pianificazione chiara.

Combinando sapientemente questi flussi di dati si forma una rete di fornitura dati con acutezza in tempo reale e produttività batch. L'obiettivo principale di questa rete è garantire che il viaggio dei dati dalla fonte al magazzino sia affidabile, coerente e tracciabile.

Dal caos alla chiarezza: costruire “mappe” di dati affidabili

I dati sono qui, ma una serie di eventi grezzi e record di modifiche potrebbero ancora essere una bibbia per gli analisti. Pertanto, dobbiamo apportare alcune "rifiniture" a questo hub, ovvero creare un livello di dati chiaro e coerente.

Questo di solito inizia con un "data Lake" o "source layer" in cui i dati grezzi vengono archiviati con tutti i dettagli conservati nel caso in cui siano necessari. Quindi, attraverso la pulizia, la correlazione e l'integrazione, creiamo gradualmente un "livello di dettaglio del data warehouse" di facile comprensione, per poi arrivare al "livello di aggregazione" o "data mart" che serve temi di analisi specifici.

Questo processo, soprattutto la costruzione degli strati intermedi di dettaglio, è un po’ come disegnare una mappa standardizzata. Indipendentemente dal fatto che i dati dell'ordine provengano da MySQL o PostgreSQL, o che il ritratto dell'utente provenga da MongoDB o da qualche altra parte, a questo livello vengono tutti convertiti in un "linguaggio" e "coordinate" unificati e standardizzati. In questo modo, sia che tu voglia analizzare i percorsi di acquisto degli utenti o calcolare indicatori aziendali in tempo reale, ti troverai di fronte a dati chiari e credibili, e non dovrai più preoccuparti di incongruenze e contraddizioni dei dati.

Qui può sorgere una domanda pratica: cosa succede se si verificano errori durante il trasferimento dei dati? Oppure voglio monitorare passo dopo passo come viene calcolato un determinato numero di chiave. Posso farlo? Ciò porta a due pilastri cruciali: il monitoraggio della qualità dei dati e il tracciamento della derivazione dei dati.

Una buona progettazione incorporerà le regole di ispezione della qualità dei dati nel processo, come un punto di controllo, per rilevare tempestivamente dati anomali o mancanti. La derivazione dei dati è come un albero genealogico dettagliato, che registra da quale servizio provengono i dati, a quale elaborazione sono stati sottoposti e infine in quale indicatore si sono trasformati in quale rapporto. Quando hai domande su un dato, puoi seguire questa linea fino in fondo per trovare la causa principale. Ciò non solo crea fiducia, ma semplifica notevolmente anche la risoluzione dei problemi.

Scelte e considerazioni per implementare la progettazione

Vedendo questo, potresti pensare, suona bene, ma come farlo? Quali sono gli ostacoli invisibili?

In effetti, in questo campo esistono già molti strumenti open source e servizi cloud maturi che possono aiutarti a creare pipeline di dati ed elaborare attività di elaborazione in flusso e batch. Quando scegli, devi considerare quanto bene si adattano al tuo attuale stack tecnologico, nonché i costi di formazione e manutenzione per il tuo team. Non esiste un bene o un male assoluto, ma solo se è adatto o meno.

Ancora più importante, questa non è semplicemente una questione di scelta tecnica. Riguarda il modo in cui lavora il tuo team. Un data warehouse progettato per i microservizi spesso incoraggia anche un modello collaborativo: la responsabilità dei prodotti dati può essere più vicina ai team aziendali che generano i dati, mentre il team dati centrale fornisce più piattaforme, standard e strumenti di supporto. Ciò accelera la creazione di valore dei dati.

A proposito, qual è lo scopo finale di tutto questo? Non si tratta solo di risvegliare i dati dormienti nei servizi distribuiti in modo che possano essere utilizzati in modo semplice e accurato per rispondere a domande e guidare le decisioni? Che si tratti di visualizzare dashboard operativi in ​​tempo reale, formare una raccomandazione o condurre una revisione aziendale approfondita, un data warehouse adeguatamente progettato è la base più solida.

Non si tratta di rinchiudere nuovamente il sistema in una gabbia, ma di stabilire una serie di eleganti regole di collaborazione per i microservizi che hanno guadagnato libertà, in modo che il valore dei dati possa fluire senza intoppi. Quando i dati non saranno più un peso ma una risorsa prontamente disponibile, potresti scoprire che quelle domande precedentemente vaghe sulla crescita aziendale iniziano ad avere risposte chiare.

Sulla strada verso la guida dei dati,kpowerStiamo anche continuando a pensare ed esplorare queste pratiche. Riteniamo che una buona progettazione tecnica sia sempre al servizio di obiettivi aziendali chiari e che mantenere i dati organizzati sia il primo passo verso un processo decisionale intelligente.

Fondata nel 2005,kpowerè dedicata a un produttore professionale di unità di movimento compatte, con sede a Dongguan, nella provincia del Guangdong, in Cina. Sfruttando le innovazioni nella tecnologia di azionamento modulare,kpowerintegra motori ad alte prestazioni, riduttori di precisione e sistemi di controllo multiprotocollo per fornire soluzioni di sistemi di azionamento intelligenti efficienti e personalizzate. Kpower ha fornito soluzioni di sistemi di azionamento professionali a oltre 500 clienti aziendali in tutto il mondo con prodotti che coprono vari campi come sistemi domestici intelligenti, elettronica automatica, robotica, agricoltura di precisione, droni e automazione industriale.