Kuidas kujundada täiuslik andmeladu

Võtmelaotehnikad muudeti lihtsaks

Andmete ladustamine: lihtsustatud

Pinna pealt võib tunduda, et andmete kogumise, säilitamise ja ladustamise osas on viimastel aastatel palju muutunud. NoSQL, „Big Data”, graafikute ja voogesitustehnoloogiate juurutamine ja ülevõtmine võib tunduda muutvat maastikku, kuid mõned põhialused jäävad alles.

Minu praeguses rollis kasutame oma andmete ladustamiseks Amazon Redshifti. Olenemata sellest, kas ehitasime traditsioonilise andmelao Oracle'i abil või Hadoopi andmejärve, jääb tuumarhitektuur samaks.

Tuumarhitektuur koosneb mõnest eeltöötlusest ja kolmest eraldi alast (skeemid, kui kasutate punanihket), mida nimetatakse Staging, Master ja Reporting. Selles postituses räägin neist üksikasjalikult.

Eeltöötlus

Kahjuks ei looda kõiki andmeid võrdselt, kuid need on sellegipoolest andmed ja omavad seetõttu väärtust.

Väliste andmete keerukusega toimetulemiseks on teatav eeltöötlus peaaegu vältimatu, eriti kui andmeid kogutakse paljudest erinevatest allikatest. Eeltöötlusetapi peamine eesmärk on saada andmed ühtlasesse vormingusse, mida saab andmelao abil laadida.

See hõlmab, kuid ei ole nendega piiratud:

  • Exceli arvutustabelite teisendamine CSV-ks
  • JSON-i andmete parsimine (kipume töötlema iga objekti ühes reas ühes veerus ja laskma Redshiftil seda sõeluda, aga ka te saate selle parsida)
  • Vigade või ekslike andmefailide puhastamine

Kui see on valmis, on teil vaja keskset kohta, kus need failid andmete lattu laadimiseks valmis panna.

Üks näide võiks olla kõigi failide paigutamine Amazon S3 ämbrisse. See on mitmekülgne, odav ja integreeritud paljude tehnoloogiatega. Kui kasutate andmelao jaoks Redshifti, on see ka sellega suurepäraselt integreeritav.

Lavastus

Peatuspaik on leiba ja võid mis tahes andmeladu.

Hea andmeladu võtab andmeid paljudest erinevatest allikatest. Igal andmeallikal on oma nüansid, stiilid ja nimetamismeetodid.

Lavastusala on koht, kus see kõik sisse tuua - tõenäoliselt sealt, kuhu pärast eeltöötlemist (kuid mitte alati) - ja seda ajutiselt säilitada, kuni seda töödeldakse veel rida mööda.

Nagu laadimispiirkond tegelikus laos. Kauba mahalaadimise koht ei ole materjalide või toodete lõppsihtkoht ega lõplik vorm. See on lihtsalt hoiuala.
Foto autor Hannes Egler saidil Unsplash

See lihtsalt võimaldab teil esmakordselt saada kõik andmed lao piires edasiseks töötlemiseks ja modelleerimiseks.

Minu isiklik arvamus on, et andmed lavastuspiirkonnas peaksid olema võimalikult lähedal töötlematale (jällegi peate eeltöötlemisel tegema mõned muudatused, kuid see ei tohiks muuta seda, mida lähteandmed teile ütlevad). Võib-olla soovite isegi hoida algsed veerunimed ja tabeli nimed samad. Nii on allikast probleemide uurimisel või neist teatamisel hõlpsam jälitada.

Ka lavastusala tuleks pidada mööduvaks.

Peaksite säilitama valitud perioodi andmed peatuspiirkonnas, pärast mida tuleks need tühjendada. Näiteks võite ebaõnnestunud laadimiste või muu uurimise korral hoida andmeid ühe kuu väärtuses jooksvas aknas.

See on viimane punkt, kus andmeid tuleks pidada töötlemataks. Sellest hetkest alates peaksid andmed vastama andmelao standarditele.

Meister

Peamine piirkond on see, kus sissetulevad andmed saavad reaalse kuju.

Põhiskeem peaks sisaldama õigesti modelleeritud tabeleid, millel on sobiv nimi. Veerunimesid tuleks parandada koos nende andmetüüpidega.

See lihtsustab arusaamist, mis tabelid on ja mida neil on, parandades loomulikult kasutatavust. Täpselt nagu vana kooli dokumentide esitamine.

Foto Drew Beamer saidil Unsplash

Andmete teisaldamisel lavastusest Master tuleks mõelda selle puhastamisele, näiteks:

  • Kõigi kuupäevavormingute ja ajavööndite standardiseerimine samadeks (vajaduse korral)
  • Kui vaja, ümardatakse numbrid väiksema kümnendkoha täpsusega
  • Stringide puhastamine suurtähtede parandamiseks või tühikute tühikute eemaldamiseks
  • Aadresside standardiseerimine sama vorminguga
  • Jagage andmed mitmeks veeruks või ekstraheerige see JSON-ist
Samuti annaksin natuke aega selle tagamiseks, et liitunud veergude veerunimed vastaksid.

Näiteks kui teil on kasutaja andmeid mõnest veebipäevikust, salvestab teie kasutajaandmed MongoDB-s ja võib-olla ka mõnda kasutajate reklaamiandmeid. Loodetavasti sisaldavad need allikad mõnda ainulaadset kasutajatunnust. Kuid kõik ei pruugi seda sama asja nimetada.

Veergude nimede standardiseerimisel on nii teil kui ka teistel teie andmete kasutajatel nii lihtne intuitiivselt aru saada, milliseid andmeid saab omavahel ühendada.

Andmeinsenerina on see ülim eesmärk.

Teil on puhtad ja ärikeele jaoks sobivalt nime saanud andmed, mis on õigesti modelleeritud, et oleks võimalik uurimist või arvutusi teha järgnevas etapis.

Aruandlus

Alusetööd on tehtud. Oleme ette valmistanud ja sisse söönud, modelleerinud ja puhastanud. Nüüd tahame oma säravaid uusi andmeid maailmale paljastada. Siit tuleb aruandluskiht.

Kui kasutate Oracle'is ridapõhist andmeladu, võite sellel ajal luua mõned faktabelid ja andmekaardid. See on aruandluskihi jaoks täiesti mõistlik kasutamise juhtum, kuna võite selle peale kleepida iga korraliku aruandlustööriista ja teil oleks hea minna.

Kuid mõnel neist traditsioonilistest andmete ladustamise tehnilistest lahendustest on tõhusus, pidades silmas näiteks Oracle'il põhinevaid mastireapõhiseid salvestuslahendusi. Need süsteemid on andmete ühendamisel tõhusad, kuid paljude veergudega read on ebaefektiivsed peamiselt seetõttu, et reapõhine lähenemisviis peab hõlmama kogu rida, isegi kui päringu jaoks on vaja ainult mõnda veergu.

Kui kasutate veerupõhist andmeladu nagu Amazon Redshift, peaks teie lähenemisviis olema erinev. Punase tõstukiga ei arvestata laiade tabelitega ning mitmete mõõtmete asemel eelistatakse mõõtmete ja faktide deormaliseerimist ühele lauale.

Andmete sel viisil modelleerimise eelised Redshifti kasutamisel hõlmavad järgmist:

  • Suurem tõhusus, kuna Redshift tegeleb laiade laudadega õnnelikumalt kui paljude liitumiste korral.
  • Kasutusmugavus lõppkasutajate või analüütikute jaoks, kes pole andmemudelis eriti arukad, kuna nad ei pea liitumistega võitlema.
  • Päringut on lihtsam teha, kuna kõik esitatud olemi jaoks vajalikud andmed on ühes kohas.
Foto: Micheile Henderson saidil Unsplash

Näiteks oletame, et soovite oma klientide kohta aru anda. Oma piiksuva puhas põhikihis on teil klientide tabel, tellimustabel, turunduslogi tabel ja mõned veebianalüüsi andmed.

Redshiftis koostaksite aruandluskihis kliendilaua. See sisaldab kõiki kliendi tavapäraseid andmeid (miinus nende isiklikud andmed, kuna neid ei peaks aruandluseks nõudma), näiteks nende registreerimiskuupäev, võib-olla sihtnumber jne.

Võite sisse tõmmata, kas nad registreerusid mobiilseadmes või võib-olla selle, kas nad on installinud teie nutitelefoni või lauaarvuti rakenduse.

Võite liituda tellimuste andmetega ja luua mõned veerud, näiteks praeguseks kulutatud kogusumma, esimese tellimuse kuupäev, viimase tellimuse kuupäev, tellimuste arv.

Turundustabel, mida teeksite sama, ja tekitaks asjakohaseid fakte, näiteks numbritele saadetud e-kirju, avatud ja klõpsatud e-kirju jne.

Veebianalüüsist võite tõmmata nende viimase veebisaidi külastuse kuupäeva, tema lemmikseadme, kõige levinuma seadme tüübi (lauaarvuti, mobiil jne) jne.

Saad pildi.

Carlos Muza “Stabiilsed statistikakaardid läikival pinnal oleva sülearvuti ekraanil” saidil Unsplash

Kõige selle tulemuseks on ülikerge kliendilaud koos kõigi oluliste mõõtmete ja faktidega. Teie analüütikud saavad selle abil arvutada kõike alates omandamismääradest, seadme kasutusharjumuste muutumisest teie kliendibaasis, kõrge väärtusega klientidest (ja kõigist sarnasustest nende vahel), klientide loksumisest ja kaasamisest ning paljust muust.

Kõik see ühest kohast, ilma liitumisteta ja suurem osa raskest tõstmisest tehtud nii, nagu peaks toimuma, kasutades andmelao jõudu.

Andmelaod ei ole tavaliselt odavad ja on sõna otseses mõttes loodud andmete krõbistamiseks. Kasutage maksimaalselt ära, tehke siin nii palju kui saate. Vabastage oma analüütikutel teadmisi kaevama, selle asemel et oodata vähem lihavat aruandlusserverit rasket tööd tegema.

Võib juhtuda, et rohkem kui ainult analüütikud on seda valmis kasutama, kui teete selle piisavalt lihtsaks ja kiireks.

Kokkuvõttes

Seda lihtsat lähenemisviisi järgides usun, et saate luua täielikult toimiva andmelao, mida pole mitte ainult lihtne laiendada, vaid ka mõista.

Võite mõelda oma lavastus-, põhi- ja aruandluskihtidele kui loogilistele asjadele. See võib teie heaks töötada. Ma eelistan hoida neid füüsiliselt eraldi, kuna see mitte ainult ei tundu puhtam, vaid võimaldab teil piirata seda, mida lõppkasutajad saavad eelmistest olekutest kasutada ja näha.