Analytikervejledningen til design af et moderne datalager

så du bliver bedt om at opbygge et datalager til din virksomhed. Et datalager, der er effektivt, skalerbart og pålideligt. Hvis din virksomhed seriøst går i gang med at implementere datarapportering som et vigtigt strategisk aktiv for din virksomhed, vil opbygning af et datalager til sidst komme op i samtalen.

men at opbygge et datalager er ikke let eller trivielt. Over 50 procent af datalagerprojekter har begrænset accept eller vil være direkte fejl.

hvordan skal du gå i gang med at designe og opbygge dit datalager? Hvad er faldgruberne, og hvordan skal du optimere det? Vigtigst, hvor skal jeg starte?

dette indlæg giver en vejledning på højt niveau om, hvordan du tænker på at oprette dit datalager for at undgå nogle almindelige faldgruber.

Hvad er et datalager?

en moderne virksomhed har typisk data gemt forskellige steder (datakilder). Dette kan være data fra:

• Applikationsdatabaser: for startups er dette sandsynligvis deres kerneproduktapplikation. For andre virksomheder kan det være deres salgsstedsapplikation,
• internetapplikationer: dette kan være applikationer, der er nødvendige for enten at skalere en virksomhed eller opretholde forretningsdrift. Eksempler kan være e-mailmarkedsføringsprogrammer som Mailchimp, internetanalyseapplikationer som f.eks.
• regneark: dette kan være i form af desktop-regneark (f.eks. Disse data kan opdateres manuelt af en person eller opdateres af en Google-aktivitet.

et datalager synkroniserer data fra forskellige kilder til et enkelt sted for alle datarapporteringsbehov.

det giver data, der kan have tillid til at være pålidelige, og kan håndtere den forespørgende arbejdsbyrde fra alle medarbejdere i virksomheden.

design af et datalager

Læs også: Hvornår skal du få et datalager?

Sådan ser en typisk datalageropsætning ud:

du designer og bygger dit datalager baseret på dine rapporteringskrav. Når du har identificeret de data, du har brug for, designer du dataene til at flyde oplysninger ind i dit datalager.

Opret et skema for hver datakilde

Opret et databaseskema for hver datakilde, du vil synkronisere med din database. Denne

1. hjælper dig med hurtigt at identificere den datakilde, som hver tabel kommer fra, hvilket hjælper, når dit antal datakilder vokser. Fremtidige dataanalytikere og forretningsholdsmedlemmer, der slutter sig til din virksomhed, kan også hurtigt lære, hvad hver datakilde har.
2. lader dig tildele specifikke tilladelser (læse/skrive) for hver datakilde. For eksempel vil en dataingeniør muligvis ikke tillade en junioranalytiker kun at læse, men ikke skrive til et specifikt skema.

dette er især nyttigt, når dit antal datakilder vokser over tid. Bare se på antallet af kilder, som dine data kan være i.

for eksempel kan du oprette et skema kaldetmailchimpxero ellerfbads for de e-mailmarkedsførings -, Finans-og reklamedata, du gerne vil importere fra disse applikationer til dit lager.

når du importerer tabellen kontakter fra Mailchimp til din database, kan du
forespørge dem som:

SELECT name, email FROM mailchimp.contacts

Sådan oprettes et skema

oprettelse af et skema er let. Du skal bare indtaste en linje for at oprette et nyt skema. Faktisk er det bare 3 ord i Postgres.

CREATE SCHEMA 

eksempel:

CREATE SCHEMA mailchimp

Note 1: nye analytikere kan blive forvirrede mellem et databaseskema. Der er 2 skemadefinitioner. Et skema kan bruges til at beskrive enten

1. hvordan tabellerne og felterne i en database er relateret til hinanden, eller
2. en mappe til databasetabeller, ligesom hvordan mapper organiserer dine filer

Note 2: du kan bruge en navngivningskonvention til at navngive de tabeller, du importerer, f.eks. mailchimp_contacts osv. Det er en af grundene til, at vi opfordrer vores kunder til at bruge til deres rapporteringsdatabase.

flytning af kildedata til dit datalager

det næste trin er at synkronisere dine kildedata til dit datalager. Dine ingeniører kender muligvis dette som et ETL-script.

Design dit importscript med følgende overvejelser:

1. fjern kolonner, der naturligvis er unødvendige. Det er ikke så svært for dig at tilføje dem senere, hvis du indser, at du har brug for dem.
2. Omdøb kolonnenavne for at gøre dem mere beskrivende eller databasevenlige (f.eks.
3. Filtrer åbenlyst unødvendige poster. Dette kan være registrerer dine interne brugere test på dit produktionssystem (nogle gange dine brugere kan tilføje data som [email protected] eller indstille deres fornavn som Test)
4. Kortlæg postværdier for at gøre dem mere læsbare. Dette gemmer dine analytikeres indsats for at omdøbe dem under rapport med CASE-IFs senere). For eksempel kan nogle poster gemme numeriske nøgler (1,2,3, 99 osv.) eller forkortede navne, der muligvis ikke er kendt for resten af organisationen. I disse tilfælde kan du knytte disse nøgler til deres faktiske værdier under importprocessen.
5. Anvend databaseindekser til din destinationstabel, når importen er færdig. Bemærk, at vi har skrevet om, hvilke databaseindekser der er i et tidligere indlæg.
6. fejlhåndtering: opsætning af e-mails//Slack-advarselsmeddelelse, der skal sendes til de relevante interessenter (især dataanalytikere) med detaljerede fejllogfiler, når jobbet mislykkes. Det kan være en god ide at konfigurere automatiserede forsøg igen (eller automatiserede gendannelsesprocesser) inden for en bestemt tidsperiode for at reducere antallet af falske positive i dette tilfælde.

skal du omdanne din kilde (rå) data?

et spørgsmål, vi ofte bliver stillet, er, hvordan man anvender datatransformationer, før dataene flyttes til lageret.

via GIPHY

vores generelle råd er ikke at gøre det. I hvert fald ikke i begyndelsen. Især hvis dette er dit første datalagerprojekt. Der er et par grunde til dette.

A. Det er usandsynligt, at du har klare krav til dine data transformationsbehov

selvom du får “klare krav”, er det sandsynligt, at dette krav vil ændre sig i løbet af projektet eller bliver forældet.

du vil ikke bruge tid på at revidere dit ETL-script baseret på, hvad forskellige interessenter ønsker på forskellige tidspunkter.

flytning af dine (ikke-transformerede) kildedata hjælper dig med at adskille afhængigheden af dit ETL-script væk fra “forretningskrav”.

b. Det er sandsynligt, at du har brug for kildedataene til andre tilfælde

tænk på dine kildedata som en base for interaktion, der kan udledes i flere afledte tabeller, enten ved at samle dem langs forskellige dimensioner eller forbinde dem med tabeller fra andre kilder.

se eksempel nedenfor om, hvordan du sporer effektiviteten af sælgers konvertering.

Når du transformerer data, mister du oplysninger fra de kildedata, der kan være nødvendige for fremtidige rapporteringsforbrugssager.

Når du f.eks. opsummerer salgsindtægter efter tidsperiode, mister du oplysninger om de specifikke transaktionsposter, som en anden bruger muligvis skal korrelere med andre rapporter.

flytning af dine ikke-transformerede kildedata giver dig fleksibilitet til at kombinere dem med andre datakilder.

behovet for kildedata bliver vigtigere, når du begynder at undersøge at bygge genanvendelige datamodeller for at besvare forskellige spørgsmål. Se et eksempel nedenfor på en kohortrapport er bygget med en række posttransformerede data. Dette vil være sværere at gøre, hvis du ikke har

c. Reducer belastningen på dine kildesystemer

kørsel af dataomformninger i kildesystemet kan tage betydelige ressourcer, især hvis du har en database, der servicerer kunder over hele verden.

du vil ikke overbelaste det med langvarige datatransformationsjob, før du flytter dem over.

der er et par tilfælde, der kan give mening for dig at transformere data, inden du flytter dem over, men disse sager er typisk for virksomheder, der allerede har konfigureret et pålideligt datalager og ønsker at forbedre det yderligere.

Transformer data for at løse et specifikt problem

det kan være komplekst at tænke på, hvordan man transformerer data. Hvis du ikke er markeret, kan du ende med at bruge masser af tid på at optimere data, der ikke leverer værdi til virksomheden.

planlægning, design og implementering af data transformationer uden et klart resultat er en løsning på udkig efter et problem.

en god tommelfingerregel er at begynde med slutningen i tankerne. Dataomformninger bør kun oprettes for at løse en praktisk brugssag eller et problem fra din rapportering.

en god måde at finde (og prioritere) disse praktiske brugssager er at begynde at opbygge rapporter og dashboards med de data, du importerede.

når dine brugere begynder at rejse problemer med forespørgselsydeevne, kan du derefter se på at transformere dataene.

dette kan skyldes rapporter, der enten
(A) indeholder indlejrede underforespørgsler eller brugerdefinerede tabeludtryk (CTE ‘ er)

(b) eller har flere (dyre) sammenføjninger på tværs af flere tabeller.

det er her, hvor fleksibiliteten i data-baserede rapporter er praktisk til at hjælpe med at identificere de problemer, som datatransformation kan løse.

det er nemt for enhver analytiker hurtigt at identificere årsagen til rapporter med langvarige forespørgsler og indlede for at optimere deres ydeevne.

dette gøres i vid udstrækning ved automatisk at pre-aggregere dataene. Dette kan gøres med materialiserede visninger, hvor du kan oprette datatransformationsjob, der enten:

1. samler store transaktionstabeller for at fremskynde forespørgselsydelsen.
2. Opret afledte tabeller med kolonner fra forskellige datakilder
3. Erstat/mask følsomme data for udvalgte grupper af brugere.

en anden anbefaling er at oprette et nyt databaseskema i dit datalager, så du kan gemme dine transformerede (eller efterbehandlede) tabeller.

ligesom den tidligere tilgang til at adskille hver datakilde med skemaer, kan oprettelse af et specifikt skema hjælpe dig med at identificere listen over afledte/transformerede datatabeller. Dette vil være nyttigt senere, når du begynder at strengen en række data import, data omdanne job i rækkefølge som dine data modenhed vokser.

Opret dine interne datadokumenter

Dette er vigtigt, især hvis du ikke ønsker, at dit datalager skal være en sort boks, hvor kun få ingeniører forstår, hvordan man bruger det. Hvis dine brugere ikke forstår det, vil de ikke være sikre på at forespørge det.

Du kan starte med at oprette et delt dokument (kan være Google Doc), der beskriver en fælles forståelse af:

• tabeller og kolonner i dine kildedata, og hvordan du fortolker dem
• Inkluder eventuelt datadiagram.
• Sådan læses dine kolonner i dine rapporter (dashboard, metrics) og eventuelle underliggende antagelser bag dem

hver gang en rapport oprettes (eller opdateres), skal du opdatere dette dokument, så det afspejler et nyt niveau af forretningsforståelse af dine data.

Vi deler flere detaljer om, hvordan du opretter og strukturerer dette interne datadokument i et separat indlæg, så pas på dette rum!

det er det!

Vi håber, at denne vejledning har været nyttig! Fortæl os, hvordan vi kan hjælpe med din rejse med at opbygge et pålideligt datalager.