The Analyst Guide to Designing a Modern Data Warehouse

zodat u wordt gevraagd om een data warehouse voor uw bedrijf te bouwen. Een datawarehouse dat efficiënt, schaalbaar en vertrouwd is. Als uw bedrijf serieus begint met het implementeren van datarapportering als een belangrijke strategische troef voor uw bedrijf, zal het bouwen van een datawarehouse uiteindelijk komen in het gesprek.

maar het bouwen van een datawarehouse is niet eenvoudig of triviaal. Meer dan 50 procent van de datawarehouse-projecten hebben beperkte acceptatie, of zullen regelrechte mislukkingen zijn.

Hoe moet u beginnen met het ontwerpen en bouwen van uw datawarehouse? Wat zijn de valkuilen en hoe moet je het optimaliseren? Het belangrijkste, waar moet ik beginnen?

Dit bericht biedt een gids op hoog niveau over hoe na te denken over het opzetten van uw datawarehouse om een aantal veelvoorkomende valkuilen te voorkomen.

Wat is een datawarehouse?

een modern bedrijf heeft doorgaans gegevens opgeslagen op verschillende plaatsen (gegevensbronnen). Dit kunnen gegevens zijn van:

• Toepassingsdatabases: voor startups is dit waarschijnlijk hun belangrijkste producttoepassing. Voor andere bedrijven kan het hun point of sale applicatie zijn,
• webapplicaties: dit kunnen applicaties zijn die nodig zijn om een bedrijf op te schalen of de bedrijfsvoering te onderhouden. Voorbeelden kunnen zijn e-mail marketing software zoals Mailchimp, web analytics toepassingen zoals Google Analytics of Mixpanel, of zelfs boekhoudsoftware zoals Xero en Quickbooks.
• Spreadsheets: dit kan in de vorm van bureaublad spreadsheets (Excel, CSV) of online spreadsheets zoals Google Spreadsheets. Deze gegevens kunnen handmatig worden bijgewerkt door iemand, of bijgewerkt door een Zapier-activiteit.

een datawarehouse synchroniseert gegevens uit verschillende bronnen naar een enkele plaats voor alle gegevensrapportagebehoeften.

het levert gegevens die betrouwbaar kunnen worden geacht, en kan de bevragende werklast van alle werknemers in het bedrijf aan.

een datawarehouse ontwerpen

Lees ook: Wanneer moet u een datawarehouse krijgen?

zo ziet een typische datawarehouse-instelling eruit:

u ontwerpt en bouwt uw datawarehouse op basis van uw rapportagevereisten. Nadat u de gegevens hebt geïdentificeerd die u nodig hebt, ontwerpt u de gegevens om informatie naar uw datawarehouse te sturen.

Maak een schema voor elke gegevensbron

Maak een databaseschema voor elke gegevensbron die u wilt synchroniseren met uw database. Deze

1. helpt u snel de gegevensbron te identificeren waar elke tabel vandaan komt, wat helpt als uw aantal gegevensbronnen groeit. Toekomstige data-analisten en business teamleden die lid worden van uw bedrijf kunnen ook snel leren wat elke gegevensbron heeft.met
2. kunt u specifieke rechten (lezen/schrijven) toewijzen voor elke gegevensbron. Een data engineer wil bijvoorbeeld niet toestaan dat een junior analist alleen leest, maar niet schrijft naar een specifiek schema.

Dit is vooral handig wanneer uw aantal gegevensbronnen in de loop van de tijd groeit. Kijk maar naar het aantal bronnen dat je gegevens kunnen bevatten.

u kunt bijvoorbeeld een schema instellen met de naam mailchimpxero, of fbads voor de e-mailmarketing -, finance-en advertentiegegevens die u wilt importeren uit deze toepassingen in uw magazijn.

wanneer u uw contactentabel importeert vanuit Mailchimp in uw database, kunt u
ze opvragen als:

SELECT name, email FROM mailchimp.contacts

Hoe maak je een schema

het maken van een schema is eenvoudig. U hoeft alleen maar een regel in te typen om een nieuw schema te maken. In feite zijn het maar 3 woorden in Postgres.

CREATE SCHEMA 

voorbeeld:

CREATE SCHEMA mailchimp

Opmerking 1: Nieuwe analisten kunnen verward raken tussen een databaseschema. Er zijn 2 schema definities. Een schema kan worden gebruikt om te beschrijven of

1. Hoe de tabellen en velden in een database aan elkaar gerelateerd zijn, of
2. een map voor databasetabellen, net als hoe mappen uw bestanden organiseren

Note 2: mySQL databases ondersteunen geen schema, dus u kunt een naamgevingsconventie gebruiken om de tabellen die u importeert een naam te geven, zoals mailchimp_contacts etc. Dat is een van de redenen waarom we onze klanten aanmoedigen om PostgreSQL te gebruiken voor hun rapportagedatabase.

brongegevens verplaatsen naar uw datawarehouse

de volgende stap is het synchroniseren van uw brongegevens naar uw datawarehouse. Uw ingenieurs kennen dit misschien als een ETL script.

ontwerp uw importscript met de volgende overwegingen:

1. verwijder kolommen die duidelijk onnodig zijn. Het is niet zo moeilijk voor u om ze later toe te voegen als je je realiseert dat je ze nodig hebt.
2. hernoem kolomnamen om ze beschrijvend of databasevriendelijker te maken (zoals het gebruik van kleine letters of camel-letters.
3. duidelijk onnodige records filteren. Dit kan records uw interne gebruikers test op uw productiesysteem (soms uw gebruikers kunnen gegevens toevoegen, zoals [email protected] of het instellen van hun voornaam Als tests)
4. kaart recordwaarden om ze leesbaarder te maken. Dit bespaart uw analisten moeite om ze te hernoemen tijdens het rapport met CASE-IFs later). Sommige records kunnen bijvoorbeeld numerieke sleutels (1,2,3, 99 enz.) of verkorte namen opslaan die mogelijk niet bekend zijn bij de rest van de organisatie. In die gevallen wilt u deze sleutels mogelijk toewijzen aan hun werkelijke waarden tijdens het importproces.
5. pas databaseindexen toe op uw doeltabel nadat de import is voltooid. Opmerking We hebben geschreven over welke database indexen zijn in een eerdere post.
6. foutafhandeling: stel e-mails//Slack waarschuwingsbericht in dat naar de relevante stakeholders (met name data-analisten) moet worden verzonden met gedetailleerde foutlogboeken wanneer de taak mislukt. U kunt automatische pogingen tot opnieuw proberen (of geautomatiseerde herstelprocessen) binnen een bepaalde periode instellen om het aantal valse positieven in dit geval te verminderen.

moet u uw bron (ruwe) gegevens transformeren?

een vraag die we vaak krijgen is hoe we datatransformaties moeten toepassen voordat we de gegevens naar het magazijn verplaatsen.

via GIPHY

ons algemene advies is om het niet te doen. Tenminste niet in het begin. Vooral als dit je eerste datawarehouse project is. Hier zijn een paar redenen voor.

a. Het is onwaarschijnlijk dat u duidelijke vereisten hebt voor uw data transform needs

zelfs als u “duidelijke vereisten” krijgt, is het waarschijnlijk dat deze vereiste in de loop van het project zal veranderen of verouderd wordt.

u zult geen tijd willen besteden aan het herzien van uw ETL script op basis van wat verschillende stakeholders willen op verschillende momenten in de tijd.

het verplaatsen van uw (niet-getransformeerde) brongegevens helpt u de afhankelijkheid van uw ETL-script te scheiden van de “business requirements”.

b. Het is waarschijnlijk dat u de brongegevens nodig hebt voor andere gevallen

denk aan uw brongegevens als een basis van interactie die kan worden afgeleid in meerdere afgeleide tabellen, hetzij door ze samen te voegen langs verschillende dimensies of ze te verbinden met tabellen uit andere bronnen.

Zie voorbeeld hieronder over hoe u de effectiviteit van de conversie van de verkoper kunt volgen.

bij het transformeren van gegevens verliest u details uit de brongegevens die mogelijk nodig zijn voor toekomstige rapportage-use-cases.

bijvoorbeeld, wanneer u omzet per periode samenvat, verliest u details van de specifieke transactierecords die een andere gebruiker mogelijk nodig heeft om te correleren met andere rapporten.

het verplaatsen van uw niet-getransformeerde brongegevens geeft u de flexibiliteit om deze te combineren met andere gegevensbronnen.

de behoefte aan brongegevens wordt belangrijker wanneer u begint te kijken naar het bouwen van herbruikbare datamodellen om verschillende vragen te beantwoorden. Zie een voorbeeld hieronder op een cohort rapport is gebouwd met een reeks van post-getransformeerde gegevens. Dit zal moeilijker zijn als u

c niet hebt. Verminder belasting op uw bronsystemen

het uitvoeren van datatransformaties in het bronsysteem kan aanzienlijke middelen in beslag nemen, vooral als u een database hebt die klanten over de hele wereld bedient.

u wilt het niet overbelasten met langlopende datatransformatietaken voordat u ze verplaatst.

er zijn een paar gevallen die voor u zinvol kunnen zijn om gegevens te transformeren voordat u ze verplaatst, maar die gevallen zijn typisch voor bedrijven die al een betrouwbaar datawarehouse hebben opgezet en het verder willen verbeteren.

transformeer gegevens om een specifiek probleem op te lossen

nadenken over hoe gegevens te transformeren kan complex zijn. Als links niet aangevinkt, je kan uiteindelijk besteden veel tijd het optimaliseren van gegevens die geen waarde aan het bedrijf levert.

het plannen, ontwerpen en implementeren van datatransformaties zonder een duidelijk resultaat is een oplossing die op zoek is naar een probleem.

een goede vuistregel is om te beginnen met het einde in gedachten. Datatransformaties moeten alleen worden gemaakt om een praktische use-case of probleem van uw rapportage aan te pakken.

een goede manier om deze praktische use-cases te vinden (en te prioriteren) is om te beginnen met het bouwen van de rapporten en dashboards met de data die je geïmporteerd hebt.

wanneer uw gebruikers problemen beginnen met query-prestaties, kunt u vervolgens kijken naar het transformeren van de gegevens.

Dit kan worden veroorzaakt door rapporten die ofwel
(a) geneste subqueries of aangepaste tabeluitdrukkingen (CTE ‘ s)

(b) bevatten of meerdere (dure) joins over meerdere tabellen hebben.

Dit is waar de flexibiliteit van SQL-gebaseerde rapporten van pas komt om te helpen bij het identificeren van de problemen die datatransformatie kan aanpakken.

Het is gemakkelijk voor elke analist om snel de oorzaak van rapporten met langlopende query ‘ s te identificeren, en te starten om hun prestaties te optimaliseren.

Dit wordt grotendeels gedaan door de gegevens automatisch vooraf te aggregeren. Dit kan worden gedaan met gematerialiseerde weergaven waar u gegevens kunt maken om taken te transformeren die ofwel:

1. Grote transactietabellen samenvoegen om de query-prestaties te versnellen.
2. maak afgeleide tabellen met kolommen uit verschillende gegevensbronnen
3. gevoelige gegevens voor geselecteerde groepen gebruikers vervangen/maskeren.

een andere aanbeveling is om een nieuw databaseschema aan te maken in uw datawarehouse zodat u uw getransformeerde (of nabewerkte) tabellen kunt opslaan.

net als de eerdere aanpak van het scheiden van elke gegevensbron door schema ‘ s, kan het creëren van een specifiek schema u helpen de lijst van afgeleide/getransformeerde gegevenstabellen te identificeren. Dit zal later nuttig zijn wanneer u begint met een reeks gegevensimport, data transformeren taken in volgorde als uw data volwassenheid groeit.

maak uw interne gegevensdocumenten

Dit is belangrijk, vooral als u niet wilt dat uw datawarehouse een zwarte doos is waar slechts een paar ingenieurs begrijpen hoe het te gebruiken. Als uw gebruikers het niet begrijpen, zullen ze niet zeker zijn om het te bevragen.

u kunt beginnen met het maken van een gedeeld document (kan Google Doc zijn) dat een gemeenschappelijk begrip beschrijft van:

• tabellen en kolommen in uw brongegevens, en hoe deze te interpreteren
• inclusief gegevensdiagram indien van toepassing.
• Hoe leest u uw kolommen in uw rapporten (dashboard, metrics) en eventuele onderliggende aannames erachter

telkens wanneer een rapport wordt gemaakt (of bijgewerkt), werkt u dit document bij om een nieuw niveau van zakelijke kennis van uw gegevens weer te geven.

We zullen meer details delen over het maken en structureren van dit interne gegevensdocument in een aparte post, dus kijk uit voor deze ruimte!

dat is het!

We hopen dat deze gids nuttig is geweest! Laat ons weten hoe we u kunnen helpen met uw reis om een betrouwbaar datawarehouse te bouwen.