Ghidul analistului pentru proiectarea unui depozit de Date Modern

deci vi se cere să construiți un depozit de date pentru compania dvs. Un depozit de date eficient, scalabil și de încredere. Dacă compania dvs. se angajează serios să implementeze raportarea datelor ca un activ strategic cheie pentru afacerea dvs., construirea unui depozit de date va apărea în cele din urmă în conversație.

dar construirea unui depozit de date nu este ușor și nici banal. Peste 50 la sută din proiectele de depozit de date au o acceptare limitată sau vor fi eșecuri directe.

cum ar trebui să începeți proiectarea și construirea depozitului de date? Care sunt capcanele și cum ar trebui să le optimizați? Cel mai important, de unde ar trebui să încep?

această postare oferă un ghid la nivel înalt despre cum să vă gândiți la configurarea depozitului de date pentru a evita unele capcane comune.

ce este un depozit de date?

o afacere modernă are de obicei date stocate în diferite locuri (surse de date). Acest lucru poate fi de date de la:

• baze de date de aplicare: pentru Start-Up, Acest lucru este probabil aplicarea lor produs de bază. Pentru alte companii, acesta poate fi punctul lor de aplicare de vânzare,
• aplicatii Web: acest lucru poate fi aplicații care este necesar fie la scară o afacere sau menține operațiunile de afaceri. Exemple ar putea fi software de marketing prin e-mail precum Mailchimp, aplicații de analiză web precum Google Analytics sau Mixpanel sau chiar software de contabilitate precum Xero și Quickbooks.
• foi de calcul: aceasta poate fi sub formă de foi de calcul desktop (Excel, CSV) sau foi de calcul online, cum ar fi foi de calcul Google. Aceste date pot fi actualizate manual de către cineva sau actualizate de o activitate Zapier.

un depozit de date sincronizează datele din diferite surse într-un singur loc pentru toate nevoile de raportare a datelor.

acesta oferă date care pot fi de încredere pentru a fi de încredere, și se pot ocupa de volumul de muncă interogarea de la toți angajații din companie.

proiectarea unui depozit de date

Citește și: când ar trebui să obțineți un depozit de date?

Iată cum arată o configurare tipică a depozitului de date:

proiectați și construiți depozitul de date pe baza cerințelor dvs. de raportare. După ce ați identificat datele de care aveți nevoie, proiectați datele pentru a transmite informații în depozitul dvs. de date.

creați o schemă pentru fiecare sursă de date

creați o schemă de bază de date pentru fiecare sursă de date pe care doriți să o sincronizați cu baza de date. Acest

1. vă ajută să identificați rapid sursa de date din care provine fiecare tabel, ceea ce vă ajută pe măsură ce numărul de surse de date crește. Viitorii analiști de date și membrii echipei de afaceri care se alătură companiei dvs. pot, de asemenea, să învețe rapid ce are fiecare sursă de date.
2. vă permite să atribuiți permisiuni specifice (citire/scriere) pentru fiecare sursă de date. De exemplu, este posibil ca un inginer de date să nu dorească să permită unui analist junior să citească, dar să nu scrie la o schemă specifică.

acest lucru este util mai ales atunci când numărul de surse de date crește în timp. Uită-te la numărul de surse în care ar putea fi datele tale.

de exemplu, puteți configura o schemă numită mailchimpxero sau fbads pentru datele de marketing prin e-mail, finanțe și publicitate pe care doriți să le importați din aceste aplicații în depozitul dvs.

când importați tabelul de contacte din Mailchimp în baza de Date,
le puteți interoga ca:

SELECT name, email FROM mailchimp.contacts

cum se creează o schemă

crearea unei scheme este ușoară. Trebuie doar să tastați o linie pentru a crea o nouă schemă. De fapt, este doar 3 cuvinte în Postgres.

CREATE SCHEMA 

exemplu:

CREATE SCHEMA mailchimp

Nota 1: noii analiști se pot confunda între o schemă a bazei de date. Există 2 Definiții ale schemei. O schemă poate fi utilizată pentru a descrie fie

1. modul în care tabelele și câmpurile dintr-o bază de date sunt legate între ele, fie
2. un folder pentru tabelele bazei de date, la fel ca modul în care folderele vă organizează fișierele

Nota 2: bazele de date mySQL nu acceptă schema, deci poate doriți să utilizați o convenție de denumire pentru a denumi tabelele pe care le importați, cum ar fi mailchimp_contacts etc. Acesta este unul dintre motivele pentru care încurajăm clienții noștri să utilizeze PostgreSQL pentru baza lor de date de raportare.

mutarea datelor sursă în depozitul de date

următorul pas este sincronizarea datelor sursă în depozitul de date. Inginerii dvs. pot ști acest lucru ca un script ETL.

proiectați scriptul de import cu următoarele considerații:

1. eliminați coloanele care sunt evident inutile. Nu este atât de dificil să le adăugați mai târziu dacă vă dați seama că aveți nevoie de ele.
2. redenumiți numele coloanelor pentru a le face mai descriptive sau mai prietenoase cu baza de date (cum ar fi utilizarea minusculelor sau a casetelor de cămilă.
3. filtrați înregistrările evident inutile. Acest lucru poate fi înregistrări utilizatorii interne de testare pe sistemul de producție (uneori utilizatorii pot adăuga date cum ar fi [email protected] sau setarea prenumelui lor ca teste)
4. harta valori de înregistrare pentru a le face mai ușor de citit. Acest lucru vă salvează efortul analiștilor redenumindu-i în timpul raportului cu CASE-IFs mai târziu). De exemplu, unele înregistrări pot stoca chei numerice (1,2,3, 99 etc) sau nume abreviate care pot să nu fie cunoscute de restul organizației. În aceste cazuri, poate doriți să mapați aceste chei la valorile lor reale în timpul procesului de import.
5. aplicați indexurile bazei de date la tabelul de destinație după efectuarea importului. Notă am scris despre ce indexuri de baze de date sunt într-un post anterior.
6. eroare de manipulare: e-mailuri de configurare/ / mesaj de alertă Slack pentru a fi trimise părților interesate relevante (în special analiștii de date) cu jurnale de eroare detaliate atunci când lucrarea nu reușește. Poate doriți să configurați încercări de reîncercare automată (sau procese de recuperare automată) într-o anumită perioadă de timp pentru a reduce numărul de fals pozitive în acest caz.

ar trebui să vă transformați datele sursă (raw)?

o întrebare pe care o punem adesea este cum să aplicăm transformările de date înainte de a muta datele în depozit.

via GIPHY

sfatul nostru general este să nu o facem. Cel puțin nu la început. Mai ales dacă acesta este primul dvs. proiect de depozit de date. Sunt câteva motive pentru asta.

a. Este puțin probabil să aveți cerințe clare cu privire la nevoile dvs. de transformare a datelor

chiar dacă vi se oferă „cerințe clare”, este probabil ca această cerință să se schimbe pe parcursul proiectului sau să devină depășită.

nu veți dori să petreceți timp revizuind scriptul ETL pe baza a ceea ce își doresc diferitele părți interesate în diferite momente ale timpului.

mutarea datelor sursă (netransformate) vă ajută să separați dependența scriptului ETL de „cerințele de afaceri”.

b. Este posibil să aveți nevoie de datele sursă pentru alte cazuri

gândiți-vă la datele sursă ca la o bază de interacțiune care poate fi derivată în mai multe tabele derivate, fie agregându-le de-a lungul unor dimensiuni diferite, fie alăturându-le cu tabele din alte surse.

A se vedea exemplul de mai jos cu privire la modul de a urmări eficiența conversiei vânzătorului.

la transformarea datelor, pierdeți detalii din datele sursă care ar putea fi necesare pentru cazurile de utilizare viitoare de raportare.

de exemplu, când rezumați veniturile din vânzări în funcție de perioada de timp, pierdeți detalii despre înregistrările specifice ale tranzacțiilor pe care un alt utilizator ar putea avea nevoie să le coreleze cu alte rapoarte.

mutarea datelor sursă netransformate vă va oferi flexibilitate pentru a le combina cu alte surse de date.

nevoia de date sursă devine mai importantă atunci când începeți să căutați modele de date reutilizabile pentru a răspunde la diferite întrebări. A se vedea un exemplu de mai jos pe un raport de cohorta este construit cu o serie de date post-transformate. Acest lucru va fi mai dificil de făcut dacă nu aveți

c. Reducerea sarcinii pe sistemele sursă

rularea transformărilor de date în sistemul sursă poate necesita resurse considerabile, mai ales dacă aveți o bază de date care deservește clienții din întreaga lume.

nu veți dori să o supraîncărcați cu lucrări de transformare a datelor de lungă durată înainte de a le muta.

există câteva cazuri care ar putea avea sens pentru dvs. să transformați datele înainte de a le muta, dar aceste cazuri sunt de obicei pentru companiile care au instalat deja un depozit de date fiabil și doresc să-l îmbunătățească în continuare.

transformarea datelor pentru a rezolva o problemă specifică

gândirea la modul de transformare a datelor poate fi complexă. Dacă este lăsat necontrolat, puteți ajunge să petreceți mult timp optimizând datele care nu oferă valoare afacerii.

planificarea, proiectarea și implementarea transformărilor de date fără un rezultat clar este o soluție care caută o problemă.

o regulă bună de degetul mare este de a începe cu sfârșitul în minte. Transformările de date ar trebui create numai pentru a aborda un caz de utilizare practică sau o problemă din raportarea dvs.

o modalitate bună de a găsi (și prioritiza) acele cazuri practice de utilizare este să începeți să construiți rapoartele și tablourile de bord cu datele pe care le-ați importat.

când utilizatorii încep să ridice probleme de performanță de interogare, puteți căuta apoi în transformarea datelor.

Acest lucru poate fi cauzat de rapoarte care fie
(a) conține Subinterogări imbricate sau expresii de tabel personalizate (CTEs)

(b) sau au mai multe (scumpe) se alătură în mai multe tabele.

aici flexibilitatea rapoartelor bazate pe SQL este utilă pentru a ajuta la identificarea problemelor pe care transformarea datelor le poate aborda.

este ușor pentru orice analist să identifice rapid cauza principală a rapoartelor cu interogări de lungă durată și să inițieze optimizarea performanței acestora.

acest lucru se face în mare parte prin pre-agregarea automată a datelor. Acest lucru se poate face cu vizualizări materializate în care puteți crea joburi de transformare a datelor care fie:

1. agregă tabele mari de tranzacții pentru a accelera performanța interogării.
2. creați tabele derivate cu coloane din diferite surse de date
3. înlocuiți / mascați datele sensibile pentru grupurile selectate de utilizatori.

o altă recomandare este să creați o nouă schemă de baze de date în depozitul dvs. de date pentru a stoca tabelele transformate (sau post-procesate).

ca și abordarea anterioară de separare a fiecărei surse de date prin scheme, crearea unei scheme specifice vă poate ajuta să identificați Lista tabelelor de date derivate / transformate. Acest lucru va fi util mai târziu, atunci când începe să șir o serie de importuri de date, date transforma locuri de muncă în ordine ca maturitatea datelor crește.

creați documentele de date interne

Acest lucru este important, mai ales dacă nu doriți ca depozitul dvs. de date să fie o cutie neagră în care doar câțiva ingineri înțeleg cum să o folosească. Dacă utilizatorii dvs. nu o înțeleg, nu vor avea încredere să o interogheze.

puteți începe prin crearea unui document partajat (poate fi Google Doc) care descrie o înțelegere comună a:

• tabele și coloane din datele sursă și cum să le interpretați
• includeți diagrama de date dacă există.
• cum să citiți coloanele din rapoartele dvs. (tablou de bord, valori) și orice ipoteze care stau la baza acestora

de fiecare dată când este creat (sau actualizat) un raport, actualizați acest document pentru a reflecta orice nou nivel de înțelegere comercială a datelor dvs.

vom împărtăși mai multe detalii despre cum să creați și să structurați acest document de date interne într-o postare separată, așa că aveți grijă la acest spațiu!

asta e!

sperăm că acest ghid a fost de ajutor! Spuneți-ne cum vă putem ajuta în călătoria dvs. pentru a construi un depozit de date fiabil.