Come progettare il data warehouse perfetto

Le tecniche di deposito chiave rese semplici

Data Warehousing: semplificato

In superficie, potrebbe sembrare che negli ultimi anni siano cambiate molte cose per quanto riguarda la raccolta, l'archiviazione e il deposito dei dati. L'introduzione e l'acquisizione delle tecnologie NoSQL, "Big Data", Graphing e Streaming possono sembrare aver cambiato il panorama, ma rimangono alcuni fondamenti.

Nel mio ruolo attuale, utilizziamo Amazon Redshift per il nostro data warehousing. Tuttavia, sia che abbiamo costruito un data warehouse tradizionale utilizzando Oracle o un data lake in Hadoop, l'architettura di base rimarrebbe la stessa.

L'architettura principale si riduce ad alcune preelaborazioni e tre aree separate (schemi se si utilizza il redshift) denominate Staging, Master e Reporting. In questo post ne parlerò in dettaglio.

Pre-elaborazione

Sfortunatamente, non tutti i dati vengono creati allo stesso modo, ma sono comunque dati e quindi hanno valore.

Per far fronte alla complessità dei dati esterni, una certa pre-elaborazione è quasi inevitabile, specialmente quando vengono raccolti da un numero di fonti diverse. L'obiettivo principale della fase di pre-elaborazione è di ottenere i dati in un formato coerente che può essere caricato dal data warehouse.

Ciò include, ma non è limitato a:

  • Conversione di fogli di calcolo Excel in CSV
  • Analisi dei dati JSON (tendiamo a elaborare ogni oggetto su una riga in una singola colonna e lasciare che Redshift lo analizzi, ma è possibile analizzarlo anche in anticipo)
  • Pulizia di file di dati errati o errati

Una volta pronto, avrai bisogno di un posto centrale per mettere questi file pronti per il caricamento nel data warehouse.

Un esempio potrebbe essere quello di mettere tutti i file in un bucket Amazon S3. È versatile, economico e si integra con molte tecnologie. Se stai usando Redshift per il tuo data warehouse, anche questo ha una grande integrazione.

messa in scena

L'area di gestione temporanea è il pane e burro per qualsiasi data warehouse.

Un buon data warehouse prende dati da molte fonti diverse. Ogni fonte di dati presenta sfumature, stili e convenzioni di denominazione propri.

L'area di gestione temporanea è il luogo in cui inserire tutto questo - molto probabilmente da dove lo hai inserito dopo la pre-elaborazione (ma non sempre) - e archiviarlo in modo transitorio fino a quando non viene elaborato ulteriormente lungo la linea.

Come l'area di carico in un magazzino reale. Il luogo in cui le merci scaricate non è la destinazione finale o la forma finale dei materiali o dei prodotti. È solo un'area di contenimento.
Foto di Hannes Egler su Unsplash

Ti consente semplicemente per la prima volta di avere tutti i dati entro i limiti del magazzino pronti per l'ulteriore elaborazione e modellazione.

La mia opinione personale è che i dati nell'area di gestione temporanea dovrebbero essere quanto più vicini possibile a raw (di nuovo, è necessario apportare alcune modifiche durante la pre-elaborazione, ma ciò non dovrebbe cambiare ciò che i dati grezzi ti dicono). Potresti anche voler mantenere uguali i nomi delle colonne e delle tabelle originali. Ciò semplifica il rintracciamento quando si esaminano o si segnalano problemi nell'origine.

Anche l'area di stadiazione dovrebbe essere considerata transitoria.

È necessario conservare i dati per un periodo di tempo selezionato nell'area di gestione temporanea dopo la quale devono essere eliminati. Ad esempio, è possibile mantenere una finestra mobile di un mese di dati in caso di carichi non riusciti o qualsiasi altra indagine.

Questo è l'ultimo punto in cui i dati dovrebbero essere considerati grezzi. Da questo punto in avanti i dati dovrebbero essere conformi agli standard del data warehouse.

Maestro

L'area principale è dove i dati in entrata prendono una forma reale.

Lo schema principale deve contenere tabelle correttamente modellate, che sono opportunamente denominate. I nomi delle colonne dovrebbero anche essere corretti insieme ai loro tipi di dati.

Ciò semplifica la comprensione di cosa sono le tabelle e di ciò che contengono, migliorando intrinsecamente l'usabilità. Proprio come la vecchia scuola di documenti.

Foto di Drew Beamer su Unsplash

Quando si spostano i dati dalla stadiazione al master, il pensiero dovrebbe andare a pulirli, cose come:

  • Standardizzare tutti i formati di data e fusi orari in modo che siano uguali (se del caso)
  • Arrotondando i numeri ove appropriato a meno decimali
  • Pulizia delle stringhe per correggere le maiuscole o rimuovere gli spazi bianchi iniziali e finali
  • La standardizzazione degli indirizzi deve essere dello stesso formato
  • Suddivisione dei dati in più colonne o estrazione da JSON
Darei anche del tempo per garantire che i nomi delle colonne per le colonne che si uniscono corrispondano.

Ad esempio, se si dispone di dati utente da alcuni registri Web, l'archivio dati utente in MongoDB e forse alcuni dati pubblicitari sugli utenti. Si spera che tutte queste fonti contengano un identificativo utente univoco. Tuttavia, potrebbero non chiamarli tutti la stessa cosa.

Standardizzando i nomi delle colonne diventa così facile per te, o per qualsiasi altro utente dei tuoi dati, capire intuitivamente quali dati possono essere uniti.

Come ingegnere dei dati questo è l'obiettivo finale finale.

Sono disponibili dati puliti e opportunamente denominati in modo che corrispondano al linguaggio aziendale, modellati correttamente e pronti per qualsiasi esplorazione o calcolo da eseguire a valle.

Segnalazione

Il lavoro di base è terminato. Abbiamo preparato e ingerito, modellato e pulito. Ora vogliamo esporre al mondo i nostri nuovi dati luccicanti. È qui che entra in gioco il livello di reporting.

A questo punto, se si utilizza un data warehouse basato su righe in Oracle, è possibile creare alcune tabelle dei fatti e data mart. Questo è un caso d'uso perfettamente ragionevole per il livello di reporting, in quanto puoi attaccare qualsiasi strumento di report decente su di esso e saresti a posto.

Tuttavia, alcune di queste tradizionali tecniche di data warehousing hanno in mente l'efficienza delle soluzioni di storage basate su file come Oracle. Questi sistemi sono efficienti nell'unione dei dati ma le righe con molte colonne sono inefficienti, principalmente a causa dell'approccio basato su righe che ha a che fare con l'intera riga, anche se per la query sono necessarie solo poche colonne.

Se stai utilizzando un data warehouse basato su colonne come Amazon Redshift, il tuo approccio dovrebbe essere diverso. Redshift non si preoccupa delle tabelle ampie e di denormalizzare dimensioni e fatti su una tabella è preferibile a più dimensioni.

I vantaggi della modellazione dei dati in questo modo quando si utilizza Redshift includono:

  • Miglioramento dell'efficienza in quanto Redshift è più contento di gestire tabelle di grandi dimensioni rispetto a molti join.
  • Facilità d'uso per utenti finali o analisti che non sono esperti di modelli di dati in quanto non devono combattere con i join.
  • È più facile eseguire una query poiché tutti i dati richiesti per l'entità segnalata si trovano in un unico posto.
Foto di Micheile Henderson su Unsplash

Ad esempio, supponiamo che tu voglia segnalare sui tuoi clienti. Hai una tabella dei clienti, una tabella degli ordini, una tabella dei log di marketing e alcuni dati di analisi web nel tuo livello Master perfettamente pulito.

In Redshift, all'interno del livello Rapporti si costruisce una tabella Clienti. Ciò conterrebbe tutti i dati standard dei clienti (meno i loro dettagli personali, poiché non dovrebbero essere richiesti per la segnalazione) come la loro data di registrazione, forse un codice postale, ecc.

Puoi stabilire se si sono registrati su un dispositivo mobile o se hanno installato l'app per smartphone o l'app desktop.

È possibile unire i dati dell'ordine e creare alcune colonne dei fatti come, totale speso fino ad oggi, data del primo ordine, data dell'ultimo ordine, numero di ordini.

La tabella di marketing faresti lo stesso e creeresti alcuni fatti rilevanti come il numero di email inviate, aperte e cliccate ecc.

Dall'analisi dei dati web è possibile estrarre la data dell'ultima visita al sito Web, il dispositivo preferito, il tipo di dispositivo più comune (desktop, cellulare, ecc.) Ecc.

Ottieni l'immagine.

Tutto ciò si traduce in una tabella clienti estremamente ampia con tutte le dimensioni e i fatti rilevanti. I tuoi analisti possono utilizzarlo per calcolare qualsiasi cosa, dai tassi di acquisizione, lo spostamento degli utilizzi dei dispositivi attraverso la tua base di clienti, i clienti di alto valore (e tutti i punti in comune tra loro), il churn e l'impegno dei clienti e molto altro ancora.

Tutto da un unico punto, senza join e la maggior parte dei lavori di sollevamento pesanti eseguiti come dovrebbe essere fatto, sfruttando la potenza del data warehouse.

I data warehouse non tendono ad essere economici e sono letteralmente progettati per sgretolare i dati. Ottieni il massimo da esso, fai il più possibile qui. Libera i tuoi analisti a scavare approfondimenti invece di aspettare che il server di reporting meno robusto esegua il duro lavoro.

Potresti scoprire che non solo gli analisti sono disposti a usarlo, se lo rendi abbastanza facile e veloce.

In sintesi

Seguendo questo semplice approccio, credo che tu possa costruire un data warehouse perfettamente funzionante che non sia solo facile da espandere, ma anche da capire.

Potresti pensare ai tuoi livelli di gestione temporanea, principale e di reporting come elementi logici. Questo potrebbe funzionare per te. Preferisco tenerli fisicamente separati poiché non solo sembra più pulito, ma ti consente di limitare ciò che gli utenti finali possono usare e vedere dagli stati precedenti.