La guida agli analisti per la progettazione di un Data Warehouse moderno

Quindi ti viene chiesto di creare un data warehouse per la tua azienda. Un data warehouse efficiente, scalabile e affidabile. Se la tua azienda sta seriamente intraprendendo l’implementazione del reporting dei dati come asset strategico chiave per la tua azienda, la costruzione di un data warehouse alla fine verrà fuori nella conversazione.

Ma costruire un data warehouse non è facile né banale. Oltre il 50 per cento dei progetti di data warehouse hanno un’accettazione limitata, o saranno guasti a titolo definitivo.

Come dovresti iniziare a progettare e costruire il tuo data warehouse? Quali sono le insidie e come si dovrebbe ottimizzare? Soprattutto, da dove dovrei iniziare?

Questo post fornisce una guida di alto livello su come pensare a configurare il data warehouse per evitare alcune insidie comuni.

Che cos’è un data warehouse?

Un business moderno in genere hanno i dati memorizzati in luoghi diversi (origini dati). Questi possono essere dati da:

• Database delle applicazioni: per le startup, questa è probabilmente la loro applicazione principale del prodotto. Per altre aziende, può essere il loro punto di applicazione di vendita,
• Applicazioni Web: Questo può essere applicazioni che è necessario per scalare un business o mantenere le operazioni di business. Esempi potrebbero essere software di email marketing come Mailchimp, applicazioni di analisi web come Google Analytics o Mixpanel, o anche software di contabilità come Xero e Quickbooks.
• Fogli di calcolo: questo può essere sotto forma di fogli di calcolo desktop (Excel, CSV) o fogli di calcolo online come Fogli Google. Questi dati possono essere aggiornati manualmente da qualcuno o aggiornati da un’attività Zapier.

Un data warehouse sincronizza i dati provenienti da fonti diverse in un unico luogo per tutte le esigenze di reporting dei dati.

Fornisce dati affidabili e in grado di gestire il carico di lavoro di interrogazione di tutti i dipendenti dell’azienda.

Progettare un data warehouse

Leggere anche: Quando si dovrebbe ottenere un data warehouse?

Ecco come si presenta una tipica configurazione del data warehouse:

Si progetta e si costruisce il data warehouse in base ai requisiti di reporting. Dopo aver identificato i dati necessari, è possibile progettare i dati per il flusso di informazioni nel data warehouse.

Creare uno schema per ogni origine dati

Creare uno schema di database per ogni origine dati che si desidera sincronizzare con il database. Questo

1. Consente di identificare rapidamente l’origine dati da cui proviene ogni tabella, il che consente di aumentare il numero di origini dati. I futuri analisti dei dati e i membri del team aziendale che si uniscono alla tua azienda possono anche apprendere rapidamente cosa ha ogni origine dati.
2. Consente di assegnare autorizzazioni specifiche (lettura / scrittura) per ogni origine dati. Ad esempio, un data engineer potrebbe non voler consentire a un analista junior di leggere solo, ma non scrivere su uno schema specifico.

Ciò è particolarmente utile quando il numero di origini dati cresce nel tempo. Basta guardare il numero di fonti che i dati potrebbero essere in.

Ad esempio, è possibile impostare uno schema chiamato mailchimpxero o fbads per i dati di email marketing, finanza e pubblicità che si desidera importare da queste applicazioni nel proprio magazzino, rispettivamente.

Quando si importa la tabella dei contatti da Mailchimp nel database,
è possibile interrogarli come:

SELECT name, email FROM mailchimp.contacts

Come creare uno schema

Creare uno schema è facile. Hai solo bisogno di digitare una riga per creare un nuovo schema. In realtà sono solo 3 parole in Postgres.

CREATE SCHEMA 

Esempio:

CREATE SCHEMA mailchimp

Nota 1: I nuovi analisti potrebbero confondersi tra uno schema di database. Ci sono 2 definizioni dello schema. Uno schema può essere usato per descrivere

1. Come le tabelle e i campi in un database sono correlati tra loro, o
2. Una cartella per le tabelle del database, proprio come le cartelle organizzano i file

Nota 2: I database MySQL non supportano lo schema, quindi è possibile utilizzare una convenzione di denominazione per denominare le tabelle importate,ad esempio mailchimp_contacts ecc. Questo è uno dei motivi per cui incoraggiamo i nostri clienti a utilizzare PostgreSQL per il loro database di reporting.

Spostamento dei dati di origine nel data warehouse

Il passo successivo è sincronizzare i dati di origine nel data warehouse. I tuoi ingegneri potrebbero saperlo come uno script ETL.

Progetta il tuo script di importazione con le seguenti considerazioni:

1. Rimuovi colonne che ovviamente non sono necessarie. Non è così difficile per te aggiungerli in seguito se ti rendi conto che ne hai bisogno.
2. Rinominare i nomi delle colonne per renderli più descrittivi o database amichevole (ad esempio utilizzando minuscolo, o caso cammello.
3. Filtra i record ovviamente non necessari. Questo può essere record che gli utenti interni testano sul sistema di produzione (a volte gli utenti possono aggiungere dati come [email protected] o impostando il loro nome come test)
4. Mappa i valori dei record per renderli più leggibili. Ciò consente agli analisti di ridenominarli durante il report con CASE-IFs in seguito). Ad esempio, alcuni record possono memorizzare chiavi numeriche (1,2,3, 99 ecc.) o nomi abbreviati che potrebbero non essere noti al resto dell’organizzazione. In questi casi, è possibile mappare queste chiavi ai loro valori effettivi durante il processo di importazione.
5. Applica gli indici del database alla tabella di destinazione al termine dell’importazione. Nota che abbiamo scritto su quali indici di database sono in un post precedente.
6. Gestione degli errori: E-mail di configurazione / / Slack messaggio di avviso da inviare alle parti interessate (in particolare gli analisti di dati) con i registri degli errori dettagliati quando il lavoro non riesce. È possibile impostare tentativi automatici di riprova (o processi di ripristino automatici) entro un periodo di tempo specifico per ridurre il numero di falsi positivi in questo caso.

Dovresti trasformare i tuoi dati di origine (grezzi)?

Una domanda che spesso ci viene posta è come applicare le trasformazioni dei dati prima di spostare i dati nel magazzino.

via GIPHY

Il nostro consiglio generale è di non farlo. Almeno non all’inizio. Soprattutto se questo è il tuo primo progetto di data warehouse. Ci sono alcune ragioni per questo.

a. È improbabile che tu abbia requisiti chiari sulle tue esigenze di trasformazione dei dati

Anche se ti vengono dati “requisiti chiari”, è probabile che questo requisito cambi nel corso del progetto o diventi obsoleto.

Non vorrai perdere tempo a rivedere il tuo script ETL in base a ciò che le diverse parti interessate vogliono in diversi punti nel tempo.

Spostare i dati di origine (non tradotti) consente di separare la dipendenza dello script ETL dai “requisiti aziendali”.

b. È probabile che tu abbia bisogno dei dati di origine per altri casi

Pensa ai tuoi dati di origine come a una base di interazione che può essere derivata in più tabelle derivate, aggregandole lungo dimensioni diverse o unendole con tabelle di altre fonti.

Vedi l’esempio seguente su come monitorare l’efficacia della conversione del venditore.

Quando si trasformano i dati, si perdono i dettagli dai dati di origine che potrebbero essere necessari per i futuri casi d’uso dei report.

Ad esempio, quando si riepilogano i ricavi delle vendite per periodo di tempo, si perdono i dettagli dei record di transazione specifici che un altro utente potrebbe dover correlare con altri report.

Spostare i dati di origine non trasformati ti darà la flessibilità di combinarli con altre fonti di dati.

La necessità di dati di origine diventa più importante quando si inizia a esaminare la creazione di modelli di dati riutilizzabili per rispondere a domande diverse. Vedere un esempio qui sotto su un rapporto di coorte è costruito con una serie di dati post-trasformati. Questo sarà più difficile da fare se non hai

c. Ridurre il carico sui sistemi di origine

L’esecuzione di trasformazioni di dati nel sistema di origine potrebbe richiedere risorse considerevoli, specialmente se si dispone di un database che fornisce servizi ai clienti di tutto il mondo.

Non si desidera sovraccaricarlo con processi di trasformazione dei dati di lunga durata prima di spostarli.

Ci sono alcuni casi che possono avere senso per trasformare i dati prima di spostarli, ma questi casi sono in genere per le aziende che hanno già configurato un data warehouse affidabile e che cercano di migliorarlo ulteriormente.

Trasforma i dati per risolvere un problema specifico

Pensare a come trasformare i dati può essere complesso. Se lasciato deselezionato, si può finire per spendere un sacco di tempo per ottimizzare i dati che non forniscono valore al business.

Pianificare, progettare e implementare trasformazioni di dati senza un risultato chiaro è una soluzione alla ricerca di un problema.

Una buona regola empirica è iniziare con la fine in mente. Le trasformazioni dei dati dovrebbero essere create solo per risolvere un caso d’uso pratico o un problema dal reporting.

Un buon modo per trovare (e dare la priorità) a questi casi d’uso pratici è iniziare a creare report e dashboard con i dati importati.

Quando gli utenti iniziano a sollevare problemi di prestazioni delle query, è possibile esaminare la trasformazione dei dati.

Ciò può essere causato da rapporti che
(a) Contiene sottoquery nidificate o espressioni di tabella personalizzate (CTEs)

(b) O hanno più join (costosi) su più tabelle.

È qui che la flessibilità dei report basati su SQL è utile per identificare i problemi che la trasformazione dei dati può risolvere.

È facile per qualsiasi analista identificare rapidamente la causa principale dei report con query di lunga durata e avviare per ottimizzare le loro prestazioni.

Questo viene fatto in gran parte attraverso la pre-aggregazione automatica dei dati. Questo può essere fatto con viste materializzate in cui è possibile creare processi di trasformazione dei dati che:

1. Aggregano tabelle di transazioni di grandi dimensioni per accelerare le prestazioni della query.
2. Crea tabelle derivate con colonne provenienti da diverse origini dati
3. Sostituisci / maschera i dati sensibili per gruppi di utenti selezionati.

Un’altra raccomandazione è quella di creare un nuovo schema di database nel data warehouse per memorizzare le tabelle trasformate (o post-elaborate).

Come il precedente approccio di separare ogni origine dati da schemi, la creazione di uno schema specifico può aiutare a identificare l’elenco di tabelle di dati derivate / trasformate. Ciò sarà utile in seguito quando inizi a stringa una serie di importazioni di dati, i dati trasformano i lavori in sequenza man mano che la maturità dei dati cresce.

Crea i tuoi documenti di dati interni

Questo è importante, soprattutto se non vuoi che il tuo data warehouse sia una scatola nera in cui solo pochi ingegneri capiscono come usarlo. Se i tuoi utenti non lo capiscono, non saranno sicuri di interrogarlo.

Puoi iniziare creando un documento condiviso (può essere Google Doc) che descrive una comprensione comune di:

• Tabelle e colonne nei tuoi dati di origine e come interpretarli
• Includi il diagramma dei dati se presente.
• Come leggere le colonne nei report (dashboard, metriche) e qualsiasi ipotesi sottostante

Ogni volta che viene creato (o aggiornato) un report, aggiorna questo documento per riflettere qualsiasi nuovo livello di comprensione aziendale dei tuoi dati.

Condivideremo maggiori dettagli su come creare e strutturare questo documento di dati interno in un post separato, quindi fai attenzione a questo spazio!

Questo è tutto!

Speriamo che questa guida sia stata utile! Fateci sapere come possiamo aiutarvi con il vostro viaggio per costruire un data warehouse affidabile.