Analytikerguiden för att designa ett modernt datalager

så du blir ombedd att bygga ett datalager för ditt företag. Ett datalager som är effektivt, skalbart och pålitligt. Om ditt företag på allvar börjar implementera datarapportering som en viktig strategisk tillgång för ditt företag kommer det så småningom att bygga ett datalager i konversationen.

men att bygga ett datalager är inte lätt eller trivialt. Över 50 procent av datalagerprojekten har begränsad acceptans, eller kommer att vara direkta misslyckanden.

hur ska du börja designa och bygga ditt datalager? Vilka är fallgroparna och hur ska du optimera det? Viktigast, var ska jag börja?

det här inlägget ger en guide på hög nivå om hur du tänker på att ställa in ditt datalager för att undvika några vanliga fallgropar.

Vad är ett datalager?

ett modernt företag har vanligtvis data lagrade på olika platser (datakällor). Detta kan vara data från:

• Applikationsdatabaser: för startups är detta sannolikt deras kärnproduktapplikation. För andra företag kan det vara deras försäljningsapplikation,
• webbapplikationer: detta kan vara applikationer som behövs för att antingen skala ett företag eller upprätthålla affärsverksamhet. Exempel kan vara e-postmarknadsföringsprogram som Mailchimp, webbanalysapplikationer som Google Analytics eller Mixpanel, eller till och med bokföringsprogram som Xero och Quickbooks.
• Kalkylark: detta kan vara i form av skrivbords kalkylblad (Excel, CSV) eller online kalkylblad som Google Sheets. Dessa data kan uppdateras manuellt av någon eller uppdateras av en Zapier-aktivitet.

ett datalager synkroniserar data från olika källor till en enda plats för alla datarapporteringsbehov.

det ger data som kan lita på att vara tillförlitliga och kan hantera den frågande arbetsbelastningen från alla anställda i företaget.

designa ett datalager

Läs också: när ska du få ett datalager?

Så här ser en typisk datalagerinställning ut:

du designar och bygger ditt datalager baserat på dina rapporteringskrav. När du har identifierat de data du behöver utformar du data för att strömma information till ditt datalager.

skapa ett schema för varje datakälla

skapa ett databasschema för varje datakälla som du vill synkronisera med databasen. Denna

1. hjälper dig att snabbt identifiera datakällan som varje tabell kommer från, vilket hjälper när ditt antal datakällor växer. Framtida dataanalytiker och företagsteammedlemmar som går med i ditt företag kan också snabbt lära sig vad varje datakälla har.
2. låter dig tilldela specifika behörigheter (Läs/skriv) för varje datakälla. Till exempel kanske en dataingenjör inte vill tillåta en junioranalytiker att bara läsa, men inte skriva till ett specifikt schema.

detta är särskilt användbart när ditt antal datakällor växer över tiden. Titta bara på antalet källor som dina data kan vara i.

Du kan till exempel ställa in ett schema som heter mailchimpxero eller fbads för e-postmarknadsföring, Ekonomi och reklamdata som du vill importera från dessa applikationer till ditt lager.

När du importerar tabellen kontakter från Mailchimp till din databas, kan du
fråga dem som:

SELECT name, email FROM mailchimp.contacts

hur man skapar ett schema

att skapa ett schema är enkelt. Du behöver bara skriva in en rad för att skapa ett nytt schema. I själva verket är det bara 3 ord i Postgres.

CREATE SCHEMA 

exempel:

CREATE SCHEMA mailchimp

Obs 1: Nya analytiker kan bli förvirrade mellan ett databasschema. Det finns 2 schemadefinitioner. Ett schema kan användas för att beskriva antingen

1. hur tabellerna och fälten i en databas är relaterade till varandra, eller
2. en mapp för databastabeller, precis som hur mappar organiserar dina filer

Not 2: mySQL-databaser stöder inte schema, så du kanske vill använda en namnkonvention för att namnge tabellerna du importerar, till exempel mailchimp_contacts etc. Det är en av anledningarna till att vi uppmuntrar våra kunder att använda PostgreSQL för sin rapporteringsdatabas.

flytta källdata till ditt datalager

nästa steg är att synkronisera källdata till ditt datalager. Dina ingenjörer kanske vet detta som ett ETL-skript.

Designa ditt importskript med följande överväganden:

1. ta bort kolumner som uppenbarligen är onödiga. Det är inte så svårt för dig att lägga till dem senare om du inser att du behöver dem.
2. Byt namn på kolumnnamn för att göra dem mer beskrivande eller databasvänliga (som att använda gemener eller kamelfall.
3. filtrera bort uppenbarligen onödiga poster. Detta kan registrera ditt interna användartest på ditt produktionssystem (ibland kan dina användare lägga till data som [email protected] eller ställa in deras förnamn som test)
4. Kartpostvärden för att göra dem mer läsbara. Detta sparar dina analytikers ansträngningar att byta namn på dem under rapport med CASE-IFs senare). Till exempel kan vissa poster lagra siffertangenter (1,2,3, 99 etc) eller förkortade namn som kanske inte är kända för resten av organisationen. I dessa fall kanske du vill mappa dessa nycklar till deras faktiska värden under importprocessen.
5. använd databasindex till din destinationstabell när importen är klar. Vi har skrivit om vilka databasindex som finns i ett tidigare inlägg.
6. felhantering: Setup e-post / / Slack varningsmeddelande som ska skickas till berörda parter (särskilt dataanalytiker) med detaljerade felloggar när jobbet misslyckas. Du kanske vill ställa in automatiska försök igen (eller automatiserade återställningsprocesser) inom en viss tidsperiod för att minska antalet falska positiva i det här fallet.

ska du omvandla dina källdata (raw)?

en fråga som vi ofta får är hur man tillämpar datatransformationer innan data flyttas till lagret.

via GIPHY

vårt allmänna råd är att inte göra det. Åtminstone inte i början. Särskilt om detta är ditt första datalagerprojekt. Det finns några skäl till detta.

a. Det är osannolikt att du har tydliga krav på dina datatransformationsbehov

Även om du får ”tydliga krav” är det troligt att detta krav kommer att förändras under projektets gång eller blir föråldrat.

du vill inte spendera tid på att revidera ditt ETL-skript baserat på vad olika intressenter vill ha vid olika tidpunkter.

att flytta dina (ej transformerade) källdata hjälper dig att skilja beroendet av ditt ETL-skript från ”affärskrav”.

b. Det är troligt att du behöver källdata för andra fall

Tänk på dina källdata som en bas för interaktion som kan härledas till flera härledda tabeller, antingen genom att aggregera dem längs olika dimensioner eller sammanfoga dem med tabeller från andra källor.

se exempel nedan om hur man spårar effektiviteten av säljarens konvertering.

När du omvandlar data förlorar du information från källdata som kan behövas för framtida rapporteringsanvändningsfall.

När du till exempel sammanfattar försäljningsintäkter efter tidsperiod förlorar du information om de specifika transaktionsposter som en annan användare kan behöva korrelera med andra rapporter.

Om du flyttar dina oförvandlade källdata får du flexibilitet att kombinera dem med andra datakällor.

behovet av källdata blir viktigare när du börjar titta på att bygga återanvändbara datamodeller för att svara på olika frågor. Se ett exempel nedan på en kohort rapport är byggd med en serie efter transformerade data. Detta blir svårare att göra om du inte har

c. Minska belastningen på dina källsystem

att köra datatransformationer i källsystemet kan ta upp betydande resurser, särskilt om du har en databas som betjänar kunder runt om i världen.

du vill inte överbelasta det med långvariga datatransformationsjobb innan du flyttar dem över.

det finns några fall som kan vara meningsfullt för dig att omvandla data innan du flyttar dem, men dessa fall är vanligtvis för företag som redan har installerat ett tillförlitligt datalager och vill förbättra det ytterligare.

transformera data för att lösa ett specifikt problem

att tänka på hur man omvandlar data kan vara komplicerat. Om du inte är markerad kan du sluta spendera mycket tid på att optimera data som inte levererar värde till verksamheten.

planering, design och implementering av datatransformer utan ett tydligt resultat är en lösning som letar efter ett problem.

en bra tumregel är att börja med slutet i åtanke. Datatransformationer bör endast skapas för att hantera ett praktiskt användningsfall eller problem från din rapportering.

ett bra sätt att hitta (och prioritera) de praktiska användningsfallen är att börja bygga rapporter och instrumentpaneler med de data du importerade.

När dina användare börjar ta upp problem med frågans prestanda kan du sedan titta på att omvandla data.

detta kan orsakas av rapporter som antingen
(A) innehåller kapslade underfrågor eller anpassade tabelluttryck (CTES)

(b) eller har flera (dyra) kopplingar över flera tabeller.

det är här flexibiliteten i SQL-baserade rapporter är till nytta för att identifiera de problem som datatransformation kan hantera.

det är lätt för alla analytiker att snabbt identifiera orsaken till rapporter med långvariga frågor och initiera för att optimera deras prestanda.

detta görs till stor del genom att automatiskt föraggregera data. Detta kan göras med materialiserade vyer där du kan skapa datatransformerade jobb som antingen:

1. sammanställer stora transaktionstabeller för att påskynda frågans prestanda.
2. skapa härledda tabeller med kolumner från olika datakällor
3. ersätt/mask känslig data för utvalda grupper av användare.

en annan rekommendation är att skapa ett nytt databasschema i ditt datalager så att du kan lagra dina transformerade (eller efterbehandlade) tabeller.

liksom det tidigare tillvägagångssättet att separera varje datakälla med scheman kan skapa ett specifikt schema hjälpa dig att identifiera listan över härledda/transformerade datatabeller. Detta kommer att vara till hjälp senare när du börjar sträng en serie av dataimport, data omvandla jobb i sekvens som din data mognad växer.

skapa dina interna datadokument

detta är viktigt, särskilt om du inte vill att ditt datalager ska vara en svart låda där endast ett fåtal ingenjörer förstår hur man använder det. Om dina användare inte förstår det kommer de inte att vara säkra på att fråga det.

Du kan börja med att skapa ett delat dokument (kan vara Google Doc) som beskriver en gemensam förståelse av:

• tabeller och kolumner i dina källdata och hur man tolkar dem
• inkludera datadiagram om något.
• så här läser du dina kolumner i dina rapporter (instrumentpanel, mätvärden) och eventuella underliggande antaganden bakom dem

varje gång en rapport skapas (eller uppdateras), uppdatera det här dokumentet för att återspegla en ny nivå av affärsförståelse för dina data.

Vi kommer att dela mer information om hur du skapar och strukturerar detta interna datadokument i ett separat inlägg, så se upp för detta utrymme!

det är det!

Vi hoppas att den här guiden har varit till hjälp! Låt oss veta hur vi kan hjälpa till med din resa för att bygga ett pålitligt datalager.