Kursusel oli kokku 9 moodulit, kus iga juurde anti ka ports kohustuslikku kirjandust lugeda. Loomulikult sel ajal ma seda ei jõudnud lugeda, kuid võtan nüüd eesmärgiks kuu aega järjest lugeda. Vaatame, kuhu jõuame. Lugemine suvalises järjekorras.
Tim Hiebenthal: How to structure your data transformations moodulist 3: andmete integreerimine. Jällegi huvitav lugemine, kuidas kihte ülesehitada ja annab "õiguse" neid üles ehitada enda vajaduste järgi. Soovitan.
Andmetorus on meil andmete sissevõtukiht, transformatsioonikiht, esitluskiht. Medaljoni arhidektuur (Databricks) kasutab mõisteid. "pronks", "hõbe" ja "kuld" kiht. dbt seevastu räägib staging (ettevalmistus), indermediate (äriloogika) ja marts (esitlus) kihist. Miks räägitakse kihtidest/etappidest? Nii eraldame erinevad osad pikast ahelast, protsessist:
- lõhume keerukuse väiksemateks osadeks
- hõlpsam mõista ja kirjutada vajalikke töökäske
- korduvkasutada väiksemaid osi
- veakoha välja selgitamine on lihtsam ja kiirem.
Traditsiooniliselt on andmetorus järgmised etapid, mil igaühel kindel roll:
- allikas (souce), kust toorandmed toome
- sissevõtt (staging), meie hallatav koht, kuhu andmed toome
- mudelid (modeling), andmetes muudatuste tegemine, et neid saaks kasutada
- esitlus (presentation), andmete tegelik kasutamine (aruanded, visuaalid).
Artikli autor on veendumusel, et transformatsiooni kiht vajab veel eraldi jaotamist mitmeks etapiks. Pole mõeldav, et kõik 100 muudatust on ainult ühe kihi sees. Laias laastus jaotab ta oma andmetoru kolmeks: toorkiht (raw), mudeldamine ja kasutuskiht (aruanded, analüüs, masinõpe jm). Keskmise mudeldamiskihi, kus toimub andmete muutmine, jaotab ta omakorda neljaks kihiks.
Puhastamine (Clean)
Toorandmete muutmine vastavalt meie ettevõtte standarditele. Kõik need tabelid sisaldavad eesliidet ja on kujul clean_allikas_customers.sql ning asuvad vastava allika kaustas. Iga toortabel omab ainult ühte puhastatud andmetega tabelit. Sellega tagame järjepidevuse puhastamise põhimõtete kasutamisel. Clean on konkreetsem nimi kui laiema tähendusega staging, mis kasutusel dbts. Väldime JOINe, äriloogikat, mida rakendame hilisemates faasides. Eesmärk on ühe korra puhastada tüüpe, nimesid. Vaatame üle:
- arvulised väärtused vs stringid?
- mida tähendavad tühjad väljad ja kuidas neid märgistame?
- testandmeid on kaasas, mida kunagi ei kasutata?
- veergude sisus olevad lühendid, mida need tegelikult tähendavad?
- veergude nimed on üheselt mõistetavad?
- JSON fail on lahti pakitud?
- jne
Ja teine eesmärk puhastuskihis on andmete olemasolu tagamine.
Ettevalmistamine (Prep)
Alati tuleb tehnilised muudatused andmetes teha enne ja seda me eelmises kihis tegimegi. Nüüd liigume edasi äriloogika lisamisega, et andmed muuta järjest kastutatavamaks ja mõistetavamaks äri jaoks. Selles kihis:
- toorandmete struktuurist kaugeneme ja kasutame meile vajalikku mudelit
- võib tabeleid ühendada JOINidega
- kaardistame väärtused, mis on küll olemas ja õiged, aga sisuslist väärtust äri jaoks ei oma
- tegeleme duplikaatkirjetega
- igasugused täpsustused, mis kuulub ühte gruppi, alamkategooriasse jne
Muudatusi ei pea tegema ühe sammuna, vaid meie ettevalmistuskiht võib sisaldada mitmeid ettevalmistuskihte enda sees. Nii on lihtsam mõista, testida, parandada. Tabelite nimetamisel võiks lähtuda:
- mida loome? prep_customer_oder
- mida andmetega teeme? prep_dedup_employees
- kasuta nimesid ainsuses
Tuumkiht (Core)
See on ettevõtte ühene tõekiht. Iga põhivara kohta on üks tabel. Ja selle granulaarsus on võimalikult detailsel tasemel. Põhivarasid ja granulaarsust haldame selle kihi kaudu. Kui hakkab tekkima tabelite ahel, tuleb tagasi minna eelmisesse etappi ja seal seda rakendada. Eesmärgiks on, et tuumkihi tabelid on võimalikult selged, arusaadavad ja korrastatud, et võib anda analüüsi.
Tabelite nimetamine sõltub lähenemisviisist dim_/fct_, core_product, entity_product, product.
Ärikiht (Mart)
Sihiks on pakkuda valmis andmekogusid, mis katavad ära kõige tüüpilisemad kasutusvajadused nii äripoolele kui ka tehnilisematele meeskondadele. Samad andmed võivad erineval kujul kasutust leida finants-, turunduse-, personali- või müügiosakonnas. Kas nad teevad kergemaid muudatusi ise või need valmistatakse neile ette, sõltub juba võimalustest.
Lihtsamal juhul piisab tuumkihi tabelite agregeeritud versioonidest. Samuti kui kasutatakse BI tööriistu, mis tähtskeemide alusel suudavad ise seosed luua. Siis võib kasutad põhikihi tabeleid või luua taas eelagregeeritud versioonid jõudluse parandamiseks.
Kui BI tööriistad vajavad laiemaid tabeleid (andmed koos ühes tabelis, mitte JOINidega), siis denormaliseerimine tehakse taas antud kihis. Ning vajadusel tabelite ühendamine omavahel mingi tunnuse abil, kui ei ole võimalik JOINE kasutada. Salvestame need tulemused selles kihis vastavasse tabelisse. Loodud mart-tabelid võib kasutada teiste mart-tabelite aluseks.
Allikas: https://handsondata.substack.com/p/how-to-structure-your-data-transformations