Analyytikon opas nykyaikaisen tietovaraston suunnitteluun

joten sinua pyydetään rakentamaan tietovarasto yrityksellesi. Tehokas, skaalautuva ja luotettava tietovarasto. Jos yrityksesi on vakavasti aloittamassa tietojen raportoinnin toteuttamista liiketoimintasi keskeisenä strategisena voimavarana, tietovaraston rakentaminen nousee lopulta keskusteluun.

mutta tietovaraston rakentaminen ei ole helppoa eikä triviaalia. Yli 50 prosenttia tietovarastoprojekteista on hyväksytty vain vähän tai tulee olemaan suoranaisia epäonnistumisia.

miten tietovaraston suunnittelu ja rakentaminen kannattaa aloittaa? Mitkä ovat sudenkuopat ja miten se pitäisi optimoida? Mikä tärkeintä, mistä aloittaisin?

tämä viesti tarjoaa korkean tason oppaan siitä, miten ajatella perustaa oman tietovaraston välttää joitakin yleisiä sudenkuoppia.

mikä on tietovarasto?

nykyaikaisella yrityksellä on tyypillisesti eri paikkoihin tallennettuja tietoja (tietolähteitä). Tiedot voivat olla:

• Sovellustietokannoista: startupeille tämä on todennäköisesti heidän ydintuotesovelluksensa. Muille yrityksille se voi olla niiden myyntipiste sovellus,
• Web-sovellukset: Tämä voi olla sovelluksia, joita tarvitaan joko skaalata liiketoimintaa tai ylläpitää liiketoimintaa. Esimerkkejä voisivat olla sähköpostimarkkinointiohjelmisto, kuten Mailchimp, web analytics-sovellukset, kuten Google Analytics tai Mixpanel, tai jopa kirjanpito-ohjelmisto, kuten Xero ja Quickbooks.
• taulukkolaskenta: tämä voi olla pöytäkoneiden taulukkolaskenta (Excel, CSV) tai online-taulukkolaskenta, kuten Google Sheets. Nämä tiedot voidaan päivittää manuaalisesti joku, tai päivittää Zapier toimintaa.

tietovarasto synkronoi eri lähteistä peräisin olevat tiedot yhteen paikkaan kaikkia tietojen raportointitarpeita varten.

se tarjoaa luotettavaa tietoa ja pystyy hoitamaan kyselytaakan kaikilta yrityksen työntekijöiltä.

tietovaraston suunnittelu

Lue myös: milloin tietovarasto kannattaa hankkia?

tältä näyttää tyypillinen tietovaraston asetelma:

suunnittelet ja rakennat tietovarastosi raportointivaatimustesi perusteella. Kun olet tunnistanut tarvitsemasi tiedot, suunnittelet tiedot virtaamaan tietovarastoosi.

luo skeema jokaiselle tietolähteelle

luo tietokantarakenne jokaiselle tietolähteelle, jonka haluat synkronoida tietokantaan. Tämä

1. auttaa tunnistamaan nopeasti, mistä tietolähteestä kukin taulukko on peräisin, mikä auttaa tietolähteiden määrän kasvaessa. Yritykseesi liittyvät tulevat data-analyytikot ja liiketoimintatiimin jäsenet voivat myös nopeasti oppia, mitä kussakin tietolähteessä on.
2. voit määrittää kullekin tietolähteelle tietyt käyttöoikeudet (luku / kirjoitus). Esimerkiksi datainsinööri ei välttämättä halua antaa nuoremman analyytikon vain lukea, mutta ei kirjoittaa tiettyyn skeemaan.

Tämä on erityisen hyödyllistä, kun tietolähteiden määrä kasvaa ajan myötä. Vain katsoa useita lähteitä, että tiedot voisivat olla.

esimerkiksi mailchimpxero, tai fbads sähköpostimarkkinointi -, Rahoitus-ja mainontatiedoille, joita haluat tuoda näistä sovelluksista varastoosi.

kun tuot Yhteystietotaulukkosi Mailchimpistä tietokantaasi, voit
kysellä niitä:

SELECT name, email FROM mailchimp.contacts

skeeman luominen

skeeman luominen on helppoa. Sinun tarvitsee vain kirjoittaa rivi luoda uusi skeema. Itse asiassa se on vain 3 sanaa Postgres.

CREATE SCHEMA 

esimerkki:

CREATE SCHEMA mailchimp

Huomautus 1: Uudet analyytikot saattavat sekoittua tietokantakaavion välillä. Skeemamääritelmiä on 2. Skeemaa voidaan käyttää kuvaamaan joko

1. sitä, miten tietokannan taulukot ja kentät liittyvät toisiinsa, tai
2. tietokantataulukoiden kansiota, aivan kuten kansioiden järjestelemät tiedostot

Huomautus 2: mySQL-tietokannat eivät tue skeemaa, joten voit käyttää nimeämiskäytäntöä tuomiesi taulukoiden nimeämiseen, kuten mailchimp_contacts jne. Tämä on yksi syy, miksi kannustamme asiakkaitamme käyttämään PostgreSQL: ää raportointitietokannassaan.

lähdetietojen siirtäminen tietovarastoon

seuraava vaihe on synkronoida lähdetietosi tietovarastoon. Insinöörisi saattavat tietää tämän ETL: n skriptinä.

Suunnittele tuontikommentisi seuraavin perustein:

1. Poista sarakkeet, jotka ovat ilmeisen tarpeettomia. Ei ole niin vaikeaa lisätä niitä myöhemmin, jos tajuat tarvitsevasi niitä.
2. nimeä sarakenimet uudelleen, jotta ne olisivat kuvailevampia tai tietokantaystävällisempiä (kuten käyttämällä pienaakkosia tai kamelikoteloita.
3. suodattaa pois ilmeisen turhat tietueet. Tämä voidaan tallentaa sisäinen käyttäjätesti tuotantojärjestelmän (joskus käyttäjät voivat lisätä tietoja, kuten [email protected] tai asettamalla etunimensä testeiksi)
4. Karttaennätysarvot, jotta ne olisivat helpommin luettavissa. Tämä säästää analyytikot vaivaa uudelleennimeäminen niitä aikana raportin CASE-IFs myöhemmin). Jotkin tietueet saattavat esimerkiksi tallentaa numeronäppäimiä (1,2,3, 99 jne.) tai lyhennettyjä nimiä, jotka eivät välttämättä ole muiden organisaation jäsenten tiedossa. Näissä tapauksissa haluat ehkä kartoittaa nämä avaimet niiden todellisiin arvoihin tuontiprosessin aikana.
5. käytä tietokannan indeksejä kohdetaulukkoon, kun tuonti on tehty. Huomaa olemme kirjoittaneet siitä, mitä tietokanta indeksit ovat aikaisempi viesti.
6. virheenkäsittely: Setup sähköpostit/ / Slack hälytysviesti lähetetään asianomaisille sidosryhmille (erityisesti data-analyytikot) yksityiskohtainen virhe Lokit Kun työ epäonnistuu. Voit perustaa automaattisen uudelleenyritysyrityksen (tai automaattisen palautusprosessin) tietyn ajan kuluessa vähentääksesi väärien positiivisten määrää tässä tapauksessa.

pitäisikö sinun muuttaa lähdetietojasi?

yksi usein kysytty kysymys on, miten datamuunnoksia sovelletaan ennen datan siirtämistä varastoon.

via GIPHY

yleinen neuvomme on olla tekemättä sitä. Ei ainakaan alussa. Varsinkin, jos tämä on ensimmäinen tietovarastoprojektisi. Tähän on muutama syy.

a. On epätodennäköistä, että sinulla on selkeät vaatimukset tietojesi muutostarpeille

Vaikka sinulle annettaisiin ”selkeät vaatimukset”, on todennäköistä, että tämä vaatimus muuttuu projektin aikana tai vanhentuu.

ETL: n komentosarjan tarkistamiseen ei kannata käyttää aikaa sen perusteella, mitä eri sidosryhmät eri ajankohtina haluavat.

(kääntämättömien) lähdetietojen siirtäminen auttaa erottamaan ETL-komentosarjan riippuvuuden pois ”liiketoiminnan vaatimuksista”.

b. On todennäköistä, että tarvitset lähdeaineistoa muille tapauksille

ajattele lähdeaineistoasi vuorovaikutuksen pohjana, joka voidaan johtaa useisiin johdettuihin taulukoihin, joko yhdistämällä ne eri ulottuvuuksia pitkin tai liittämällä ne muista lähteistä peräisin oleviin taulukoihin.

katso alla oleva esimerkki myyjän muuntamisen tehokkuuden seuraamisesta.

tietoja muutettaessa menetetään lähdeaineistosta yksityiskohtia, joita voidaan tarvita myöhempiä raportointikäyttötapauksia varten.

esimerkiksi, kun myyntituotot summataan ajanjaksoittain, menetät tiedot tietyistä tapahtumatiedoista, joita toinen käyttäjä saattaa tarvita korreloidakseen muiden raporttien kanssa.

Kääntämättömien lähdetietojen siirtäminen antaa sinulle joustavuutta yhdistää ne muihin tietolähteisiin.

lähdeaineiston tarve korostuu, kun aletaan tutkia uudelleenkäytettävien tietomallien rakentamista vastaamaan erilaisiin kysymyksiin. Katso alla oleva esimerkki kohorttiraportista, joka on rakennettu sarjalla jälkikäteen muunnettuja tietoja. Tämä on vaikeampaa, jos sinulla ei ole

c.

lähdejärjestelmien kuormituksen vähentäminen voi viedä huomattavia resursseja, varsinkin jos käytössäsi on tietokanta, joka palvelee asiakkaita ympäri maailmaa.

sitä ei kannata ylikuormittaa pitkillä datamuunnostöillä ennen niiden siirtämistä.

on olemassa muutamia tapauksia, joissa voi olla järkevää muuttaa tietoja ennen niiden siirtämistä, mutta nämä tapaukset ovat tyypillisesti yrityksille, jotka ovat jo perustaneet luotettavan tietovaraston ja haluavat parantaa sitä edelleen.

muuntaa dataa tietyn ongelman ratkaisemiseksi

ajattelu datan muuntamisesta voi olla monimutkaista. Jos jätetään valitsematta, saatat päätyä viettää paljon aikaa optimoimalla tietoja, jotka eivät tuota arvoa liiketoiminnalle.

Datamuunnosten Suunnittelu, Suunnittelu ja toteutus ilman selkeää lopputulosta on ongelmaan etsivää ratkaisua.

yksi hyvä nyrkkisääntö on aloittaa loppu mielessä. Datamuunnokset tulee luoda vain raportoinnin käytännön käyttötapauksen tai ongelman käsittelemiseksi.

hyvä tapa löytää (ja priorisoida) nämä käytännön käyttötapaukset on alkaa rakentaa raportteja ja kojelautoja tuomastasi datasta.

kun käyttäjät alkavat nostaa kyselyn suorituskykyyn liittyviä ongelmia, voit sitten tarkastella tietojen muuttamista.

Tämä voi johtua raporteista, jotka joko
(a) Sisältää sisäkkäisiä alijonoja tai custom table expressions (CTEs)

(b) tai joissa on useita (kalliita) liittymiä useiden taulukoiden välillä.

tässä on SQL-pohjaisten raporttien joustavuus, joka auttaa tunnistamaan ongelmat, joihin tietojen muuntaminen voi puuttua.

jokaisen analyytikon on helppo tunnistaa nopeasti pitkillä kyselyillä tehtyjen raporttien perussyy ja aloittaa niiden suorituskyvyn optimointi.

tämä tapahtuu suurelta osin siten, että tiedot kootaan automaattisesti valmiiksi. Tämä voidaan tehdä materialisoiduilla näkymillä, joissa voit luoda datamuunnostöitä, jotka joko:

1. kokoavat suuria tapahtumataulukoita nopeuttaakseen kyselyn suorituskykyä.
2. luo johdettuja taulukoita, joissa on sarakkeita eri tietolähteistä
3. korvaa / naamioi herkät tiedot valituille käyttäjäryhmille.

toinen suositus on luoda tietovarastoosi Uusi tietokantarakenne, johon voit tallentaa muunnetut (tai jälkikäsitellyt) taulukosi.

kuten aikaisempi lähestymistapa erottaa kunkin tietolähteen skeemoilla, tietyn skeeman luominen voi auttaa tunnistamaan johdettujen / muunnettujen datataulukoiden luettelon. Tämä on hyödyllistä myöhemmin, kun aloitat merkkijono joukko tietojen tuonti, data muuttaa työpaikkoja järjestyksessä tietojen kypsyys kasvaa.

luo sisäiset tietoasiakirjat

Tämä on tärkeää, varsinkin jos et halua tietovarastosi olevan musta laatikko, jossa vain harvat insinöörit ymmärtävät käyttää sitä. Jos käyttäjät eivät ymmärrä sitä, he eivät ole varmoja kysyä sitä.

voit aloittaa luomalla jaetun dokumentin (voi olla Google Doc), joka kuvaa yhteistä käsitystä:

• taulukoita ja sarakkeita lähdeaineistossasi, ja miten niitä tulkitaan
• sisältävät datakaavion, jos sellaisia on.
• kuinka lukea raporttien sarakkeita (kojelauta, Mittarit) ja niiden taustalla olevia oletuksia

aina, kun raportti luodaan (tai päivitetään), Päivitä tämä asiakirja vastaamaan tietojesi uutta liiketoimintaymmärrystä.

jaamme lisätietoja siitä, miten tämä sisäinen tietoasiakirja luodaan ja jäsennetään erilliseen postaukseen, joten varo tätä tilaa!

That ’ s it!

toivomme, että tästä oppaasta on ollut apua! Kerro meille, miten voimme auttaa sinua rakentamaan luotettavan tietovaraston.