Analytikerveiledningen For Å Designe Et Moderne Datalager

Så du blir bedt om å bygge et datalager for firmaet ditt. Et datalager som er effektivt, skalerbart og pålitelig. Hvis bedriften din seriøst tar fatt på å implementere datarapportering som en viktig strategisk ressurs for virksomheten din, vil det til slutt komme opp i samtalen å bygge et datalager.

men å bygge et datalager er ikke lett eller trivielt. Over 50 prosent av data warehouse prosjekter har begrenset aksept, eller vil være direkte feil.

Hvordan skal du begynne å designe og bygge datalageret ditt? Hva er fallgruvene og hvordan skal du optimalisere det? Viktigst, hvor skal jeg begynne?

dette innlegget gir en veiledning på høyt nivå om hvordan du tenker på å sette opp datalageret ditt for å unngå noen vanlige fallgruver.

Hva er et datalager?

en moderne bedrift har vanligvis data lagret på forskjellige steder (datakilder). Dette kan være data fra:

• Søknadsdatabaser: For oppstart er dette sannsynligvis deres kjerneproduktapplikasjon. For andre bedrifter, kan det være deres point of sale søknad,
• Webapplikasjoner: Dette kan være programmer som er nødvendig for å enten skalere en bedrift eller opprettholde driften. Eksempler kan være e-postmarkedsføringsprogramvare som Mailchimp, webanalyseprogrammer Som Google Analytics eller Mixpanel, eller til og med regnskapsprogramvare som Xero og Quickbooks.
• Regneark: Dette kan være i form av desktop regneark (Excel, CSV) eller online regneark som Google Sheets. Disse dataene kan oppdateres manuelt av noen, eller oppdateres av En Zapier-aktivitet.

et datalager synkroniserer data fra ulike kilder til ett sted for alle datarapporteringsbehov.

Det gir data som kan være klarert for å være pålitelig, og kan håndtere spørring arbeidsmengden fra alle ansatte i selskapet.

Designe et datalager

les også: når skal du få et datalager?

slik ser et typisk datalageroppsett ut:

du utformer og bygger datalageret ditt basert på rapporteringskravene dine. Når du har identifisert dataene du trenger, utformer du dataene slik at informasjonen flyter inn i datalageret.

Opprette et skjema for hver datakilde

Opprette et databaseskjema for hver datakilde som du vil synkronisere til databasen. Denne

1. hjelper deg med å raskt identifisere datakilden som hver tabell kommer fra, noe som hjelper når antall datakilder vokser. Fremtidige dataanalytikere og forretningsteammedlemmer som blir med i firmaet, kan også raskt lære hva hver datakilde har.
2. lar deg tilordne bestemte tillatelser (lese / skrive) for hver datakilde. En dataingeniør kan for eksempel ikke tillate at en junior analytiker bare leser, men ikke skriver til et bestemt skjema.

Dette er spesielt nyttig når antall datakilder vokser over tid. Bare se på antall kilder som dataene dine kan være i.

du kan for eksempel sette opp et skjema som heter mailchimpxero ellerfbads for e-postmarkedsførings -, finans-og annonseringsdataene du vil importere fra disse programmene til lageret ditt.

når du importerer kontakttabellen Fra Mailchimp til databasen, kan du:

SELECT name, email FROM mailchimp.contacts

hvordan lage et skjema

Å Lage et skjema Er enkelt. Du trenger bare å skrive inn en linje for å opprette et nytt skjema. Faktisk er det bare 3 ord I Postgres.

CREATE SCHEMA 

Eksempel:

CREATE SCHEMA mailchimp

Merk 1: Nye analytikere kan bli forvirret mellom et databaseskjema. Det er 2 skjemadefinisjoner. Et skjema kan brukes til å beskrive Enten

1. hvordan tabeller Og felt i en database er relatert til hverandre, eller
2. en mappe for databasetabeller, akkurat som hvordan mapper organiserer filene dine

Notat 2: mySQL-databaser støtter ikke skjema, så du vil kanskje bruke en navnekonvensjon for å nevne tabellene du importerer, for eksempel mailchimp_contacts etc. Det er en av grunnene til at vi oppfordrer våre kunder til Å bruke PostgreSQL for deres rapporteringsdatabase.

Flytte kildedata til datalageret

det neste trinnet er å synkronisere kildedataene til datalageret. Dine ingeniører kan vite dette som ET ETL-skript.

Design ditt importskript med følgende hensyn:

1. Fjern kolonner som åpenbart er unødvendige. Det er ikke så vanskelig for deg å legge dem til senere hvis du skjønner at du trenger dem.
2. Gi nytt navn til kolonnenavn for å gjøre dem mer beskrivende eller databasevennlige (for eksempel å bruke små bokstaver eller kameldeksel.
3. Filtrer ut åpenbart unødvendige poster. Dette kan være poster interne brukere test på produksjonssystemet (noen ganger brukerne kan legge til data som [email protected] som tester)
4. Kart postverdier for å gjøre dem mer lesbare. Dette sparer dine analytikere innsats døpe dem under rapport MED CASE-ifs senere). For eksempel kan noen poster lagre numeriske nøkler (1,2,3, 99 osv.) eller forkortede navn som kanskje ikke er kjent for resten av organisasjonen. I slike tilfeller vil du kanskje tilordne disse nøklene til de faktiske verdiene under importprosessen.
5. Bruk databaseindekser til måltabellen etter at importen er ferdig. Merk vi har skrevet om hva database indekser er i et tidligere innlegg.
6. Feilhåndtering: Oppsett av e-post / / Slack-varselmelding som skal sendes til relevante interessenter (spesielt dataanalytikere) med detaljerte feillogger når jobben mislykkes. Det kan være lurt å konfigurere automatiserte forsøk på nytt (eller automatiserte gjenopprettingsprosesser) innen en bestemt tidsperiode for å redusere antall falske positiver i dette tilfellet.

skal du transformere kildedataene dine?

et spørsmål vi ofte får spurt er hvordan man bruker data transformerer før du flytter dataene til lageret.

via GIPHY

vårt generelle råd er ikke å gjøre det. I hvert fall ikke i begynnelsen. Spesielt hvis dette er ditt første datalagerprosjekt. Det er noen grunner til dette.

a. Det er usannsynlig at du har klare krav til dine data transform behov

Selv om du får «klare krav», er det sannsynlig at dette kravet vil endre seg i løpet av prosjektet, eller blir utdatert.

Du vil ikke bruke tid på å revidere etl-skriptet ditt basert på hva ulike interessenter vil ha på forskjellige tidspunkter.

Flytte (untransformed) kildedata hjelper deg å skille avhengigheten av etl script bort fra «forretningskrav».

b. Det er sannsynlig at du trenger kildedataene for andre tilfeller

Tenk på kildedataene dine som en base for samhandling som kan utledes i flere avledede tabeller, enten ved å samle dem langs forskjellige dimensjoner eller bli med i tabeller fra andre kilder.

Se eksempel nedenfor på hvordan du kan spore effektiviteten av selgers konvertering.

når du transformerer data, mister du detaljer fra kildedataene som kan være nødvendige for fremtidig rapportering av brukstilfeller.

når du oppsummerer salgsinntekter etter tidsperiode, mister du for eksempel detaljer om de bestemte transaksjonspostene som en annen bruker kanskje må korrelere med andre rapporter.

Flytte untransformed kildedata vil gi deg fleksibilitet til å kombinere den med andre datakilder.

behovet for kildedata blir viktigere når du begynner å se på å bygge gjenbrukbare datamodeller for å svare på ulike spørsmål. Se et eksempel nedenfor pa en kohortrapport er bygget med en rekke posttransformerte data. Dette vil være vanskeligere å gjøre hvis du ikke har

c. Redusere belastningen på kildesystemer

Running data transformerer i kildesystemet kan ta opp betydelige ressurser, spesielt hvis du har en database som service kunder over hele verden.

Du vil ikke overbelaste den med langvarige datatransformasjonsjobber før du flytter dem over.

det er noen tilfeller som kan være fornuftig for deg å transformere data før du flytter dem over, men disse tilfellene er vanligvis for selskaper som allerede har satt opp et pålitelig datalager og ønsker å forbedre det ytterligere.

Transform data for å løse et bestemt problem

Å Tenke på hvordan å transformere data kan være komplisert. Hvis venstre ukontrollert, kan du ende opp med å bruke mye tid på å optimalisere data som ikke leverer verdi til virksomheten.

Planlegging, utforming og implementering av data transformerer uten et klart utfall er en løsning på jakt etter et problem.

en god tommelfingerregel er å begynne med slutten i tankene. Datatransformasjoner bør kun opprettes for å løse et praktisk brukstilfelle eller problem fra rapporteringen.

en god måte å finne (og prioritere) de praktiske brukssakene på, er å begynne å bygge rapportene og instrumentbordene med dataene du importerte.

når brukerne begynner å heve ytelsesproblemer for spørringer, kan du se nærmere på å transformere dataene.

dette kan skyldes rapporter som Enten
(A) Inneholder nestede delspørringer eller egendefinerte tabelluttrykk (Cte)

(b) eller har flere (dyre) sammenføyninger på tvers av flere tabeller.

det Er her fleksibiliteten TIL SQL-baserte rapporter kommer til nytte for å identifisere problemene som datatransformasjon kan løse.det er enkelt for enhver analytiker å raskt identifisere årsaken til rapporter med lange løpende spørringer, og starte for å optimalisere ytelsen.

dette gjøres i stor grad gjennom automatisk forhåndsaggregering av dataene. Dette kan gjøres med materialiserte visninger der du kan opprette data transformere jobber som enten:

1. Samle store transaksjonstabeller for å øke hastigheten på spørringsytelsen.
2. Opprett avledede tabeller med kolonner fra ulike datakilder
3. Erstatt / maskere sensitive data for utvalgte brukergrupper.

En annen anbefaling er å opprette et nytt databaseskjema i datalageret slik at du kan lagre transformerte (eller etterbehandlede) tabeller.

som den tidligere tilnærmingen til å skille hver datakilde med skjemaer, kan det å opprette et bestemt skjema hjelpe deg med å identifisere listen over avledede / transformerte datatabeller. Dette vil være nyttig senere når du begynner å streng en rekke dataimport, data transformere jobber i rekkefølge som data modenhet vokser.

Lag dine interne datadokumenter

Dette er viktig, spesielt hvis du ikke vil at datalageret ditt skal være en svart boks der bare noen få ingeniører forstår hvordan du bruker det. Hvis brukerne ikke forstår det, vil de ikke være sikre på å spørre det.

Du kan starte med å opprette et delt dokument (Kan Være Google Doc) som beskriver en felles forståelse av:

• Tabeller og kolonner i kildedataene dine, og hvordan du tolker dem
• Inkluder datadiagram hvis noen.
• slik leser du kolonnene dine i rapportene dine (dashbord, beregninger) og eventuelle underliggende forutsetninger bak dem

hver gang en rapport opprettes (eller oppdateres), oppdaterer du dette dokumentet for å gjenspeile et nytt nivå av forretningsforståelse av dataene dine.

vi vil dele flere detaljer om hvordan du oppretter og strukturerer dette interne datadokumentet i et eget innlegg, så pass på dette rommet!

Det er det!

vi håper denne veiledningen har vært nyttig! La oss få vite hvordan vi kan hjelpe deg med å bygge et pålitelig datalager.