Az elemzői útmutató a modern adattárház tervezéséhez

ezért felkérik, hogy építsen adattárházat a vállalata számára. Hatékony, skálázható és megbízható adattárház. Ha a cég komolyan elindulna végrehajtási adatszolgáltatás kulcsfontosságú stratégiai eszköz az üzleti, épület egy adattárház végül jön fel a beszélgetést.

de egy adattárház építése nem könnyű és nem triviális. Az adattárház-projektek több mint 50 százaléka korlátozott elfogadással rendelkezik, vagy egyenesen kudarc lesz.

hogyan kezdje el az adattárház tervezését és építését? Mik a buktatók, és hogyan kell optimalizálni? A legfontosabb, hol kezdjem?

Ez a bejegyzés magas szintű útmutatót nyújt arról, hogyan gondoljon az adattárház beállítására, hogy elkerülje a gyakori buktatókat.

mi az adattárház?

a modern üzleti jellemzően tárolt adatok különböző helyeken (adatforrások). Ezek a következő adatok lehetnek:

• alkalmazási adatbázisok: az induló vállalkozások számára ez valószínűleg az alapvető termékalkalmazásuk. Más vállalkozások számára ez lehet az értékesítési pont alkalmazás,
• webes alkalmazások: Ez lehet olyan alkalmazás, amelyre szükség van egy vállalkozás méretezéséhez vagy az üzleti műveletek fenntartásához. Ilyen lehet például az e-mail marketing szoftver, például a Mailchimp, a webanalitikai alkalmazások, például a Google Analytics vagy a Mixpanel, vagy akár a számviteli szoftverek, például a Xero és a Quickbooks.
• táblázatok: ez lehet asztali táblázatok (Excel, CSV) vagy online táblázatok, például a Google táblázatok formájában. Ezeket az adatokat manuálisan frissítheti valaki, vagy frissítheti egy Zapier tevékenység.

egy adattárház szinkronizálja a különböző forrásokból származó adatokat egyetlen helyre az összes adatszolgáltatási igényhez.

megbízható adatokat szolgáltat, és képes kezelni a vállalat összes alkalmazottjának lekérdezési terhelését.

adattárház tervezése

olvassa el még: mikor kell adattárházat szereznie?

így néz ki egy tipikus adattárház-beállítás:

az adattárházat a jelentési követelmények alapján tervezheti és építheti fel. Miután azonosította a szükséges adatokat, úgy tervezi meg az adatokat, hogy információkat áramoljon az adattárházba.

hozzon létre egy sémát minden adatforráshoz

Hozzon létre egy adatbázis sémát minden olyan adatforráshoz, amelyet szinkronizálni szeretne az adatbázisával. Ez a

1. segít gyorsan azonosítani az adatforrást, amelyből az egyes táblák származnak, ami segít az adatforrások számának növekedésében. A jövőbeni adatelemzők és az üzleti csapat tagjai, akik csatlakoznak a vállalatához, gyorsan megtudhatják, hogy mi az egyes adatforrások.

A

2. lehetővé teszi, hogy minden adatforráshoz külön engedélyeket rendeljen (olvasás/írás). Például egy adatmérnök nem akarja engedélyezni, hogy egy junior elemző csak olvasson, de ne írjon egy adott sémára.

Ez különösen akkor hasznos, ha az adatforrások száma idővel növekszik. Csak nézd meg a források száma, hogy az adatok lehetnek.

beállíthat például egy mailchimpxerovagy fbads nevű sémát az e-mail marketing, pénzügyi és hirdetési adatokhoz, amelyeket ezekből az alkalmazásokból importálni szeretne a raktárába.

amikor importálja a kapcsolatok tábla Mailchimp az adatbázisba, akkor
lehet lekérdezni őket:

SELECT name, email FROM mailchimp.contacts

Hogyan hozzunk létre egy sémát

a séma létrehozása egyszerű. Csak be kell írnia egy sort egy új séma létrehozásához. Valójában ez csak 3 szó Postgres.

CREATE SCHEMA 

példa:

CREATE SCHEMA mailchimp

Megjegyzés 1: Az új elemzők összezavarodhatnak egy adatbázis séma között. Vannak 2 séma definíciók. A séma leírható vagy

1. hogyan kapcsolódnak egymáshoz az adatbázis táblái és mezői, vagy
2. egy mappa az adatbázis táblákhoz, csakúgy, mint a mappák rendszerezése a fájlok

2. megjegyzés: a mySQL adatbázisok nem támogatják a sémát, ezért érdemes elnevezési konvenciót használni az importált táblák megnevezéséhez, például mailchimp_contacts stb. Ez az egyik oka annak, hogy arra ösztönözzük ügyfeleinket, hogy a PostgreSQL-t használják jelentési adatbázisukhoz.

forrásadatok áthelyezése az adattárházba

a következő lépés a forrásadatok szinkronizálása az adattárházba. A mérnökei talán tudják, hogy ez egy ETL szkript.

tervezze meg az import szkriptet a következő megfontolásokkal:

1. távolítsa el a nyilvánvalóan felesleges oszlopokat. Nem olyan nehéz később hozzáadni őket, ha rájössz, hogy szükséged van rájuk.
2. nevezze át az oszlopneveket, hogy azok leíróbbak vagy adatbázis-barátabbak legyenek (például kisbetűvel vagy teve-t használva.
3. szűrje ki a nyilvánvalóan felesleges rekordokat. Ez lehet rögzíti a belső felhasználók teszt a termelési rendszer (néha a felhasználók hozzá adatokat, mint [email protected]
4. térkép rekord értékeket, hogy azok jobban olvasható. Ezzel megtakaríthatja az elemzők erőfeszítéseit, hogy átnevezzék őket a jelentés során a CASE-IFs később). Például egyes rekordok numerikus kulcsokat (1,2,3, 99 stb.) vagy rövidített neveket tárolhatnak, amelyeket a szervezet többi része nem ismer. Ezekben az esetekben előfordulhat, hogy ezeket a kulcsokat az importálási folyamat során a tényleges értékekhez szeretné hozzárendelni.
5. az importálás után alkalmazza az adatbázis-indexeket a céltáblára. Megjegyzés: egy korábbi bejegyzésben írtunk arról, hogy milyen adatbázis-indexek vannak.
6. hibakezelés: e-mailek beállítása//Slack riasztási üzenetet kell küldeni az érintett érdekelt feleknek (különösen az adatelemzőknek) részletes hibanaplókkal, amikor a feladat sikertelen. Előfordulhat, hogy automatikus újrapróbálkozási kísérleteket (vagy automatizált helyreállítási folyamatokat) szeretne beállítani egy adott időtartamon belül, hogy ebben az esetben csökkentse a hamis pozitív eredmények számát.

át kell alakítania a forrás (nyers) adatait?

az egyik kérdés, amelyet gyakran feltesznek nekünk, az, hogy hogyan alkalmazzuk az adatátalakításokat, mielőtt az adatokat a raktárba költöztetnénk.

via GIPHY

általános tanácsunk az, hogy ne tegyük meg. Legalábbis nem az elején. Különösen, ha ez az első adattárház projekt. Ennek több oka is van.

a. Nem valószínű, hogy egyértelmű követelményei vannak az adatátalakítási igényekkel kapcsolatban

még akkor is, ha “egyértelmű követelményeket” kapnak, valószínű, hogy ez a követelmény megváltozik a projekt során, vagy elavulttá válik.

nem akarsz időt tölteni az ETL szkript felülvizsgálatával annak alapján, hogy a különböző érdekeltek mit akarnak a különböző időpontokban.

a (nem átalakított) forrásadatok áthelyezése segít elkülöníteni az ETL szkript függőségét az “üzleti követelményektől”.

b. Valószínűleg más esetekhez is szüksége van a forrásadatokra

gondoljon a forrásadatokra olyan interakció alapjaként, amely több származtatott táblába származtatható, akár különböző dimenziók mentén összesítve, akár más forrásokból származó táblákkal összekapcsolva őket.

Lásd az alábbi példát az eladó konverziójának hatékonyságának nyomon követésére.

az adatok átalakításakor elveszíti a forrásadatokból azokat a részleteket, amelyekre szükség lehet a jövőbeni jelentési Felhasználási esetekhez.

például, amikor az árbevételt időszakonként összegzi, elveszíti azon konkrét tranzakciós rekordok részleteit, amelyeket egy másik felhasználónak más jelentésekkel kell korrelálnia.

a nem átalakított forrásadatok áthelyezése rugalmasságot biztosít a más adatforrásokkal való kombináláshoz.

a forrásadatok iránti igény egyre fontosabbá válik, amikor újrafelhasználható adatmodellek készítésével kezd foglalkozni a különböző kérdések megválaszolásához. Lásd az alábbi példát a kohorsz jelentés épül egy sor poszt-transzformált adatok. Ez nehezebb lesz, ha nem

c. Csökkentse a forrásrendszerek terhelését

a forrásrendszerben az adatátalakítások futtatása jelentős erőforrásokat igényelhet, különösen akkor, ha van olyan adatbázisa, amely világszerte kiszolgálja az ügyfeleket.

nem akarja túlterhelni hosszú távú adatátalakítási feladatokkal, mielőtt áthelyezné őket.

van néhány olyan eset, amelynek értelme lehet az adatok átalakítása az áthelyezés előtt, de ezek az esetek általában azoknak a vállalatoknak szólnak, akik már telepítettek egy megbízható adattárházat, és tovább szeretnék javítani.

adatok átalakítása egy adott probléma megoldásához

az adatok átalakításának gondolkodása összetett lehet. Ha nincs bejelölve, akkor sok időt tölthet olyan adatok optimalizálásával, amelyek nem adnak értéket a vállalkozás számára.

az adatátalakítások tervezése, tervezése és végrehajtása egyértelmű eredmény nélkül megoldást keres a problémára.

az egyik jó ökölszabály az, hogy a végét szem előtt tartva kezdjük. Az adatátalakításokat csak a jelentésből származó gyakorlati felhasználási eset vagy probléma kezelésére szabad létrehozni.

jó módja annak, hogy megtalálja (és rangsorolja) ezeket a gyakorlati felhasználási eseteket, ha elkezdi építeni a jelentéseket és az irányítópultokat az importált adatokkal.

amikor a felhasználók elkezdenek lekérdezési teljesítményproblémákat felvetni, akkor megvizsgálhatja az adatok átalakítását.

ezt olyan jelentések okozhatják, amelyek vagy
(a) beágyazott alkereséseket vagy egyéni táblázatkifejezéseket (CTE) tartalmaznak

(b), vagy több (drága) illesztéssel rendelkeznek több táblán keresztül.

itt hasznos az SQL-alapú jelentések rugalmassága, hogy segítsen azonosítani azokat a problémákat, amelyeket az adatátalakítás megoldhat.

bármely elemző könnyen azonosíthatja a hosszú futású lekérdezésekkel kapcsolatos jelentések kiváltó okait, és kezdeményezheti azok teljesítményének optimalizálását.

ez nagyrészt az adatok automatikus előzetes összesítésével történik. Ez megvalósítható materializált nézetekkel, ahol olyan adatátalakítási feladatokat hozhat létre, amelyek:

1. nagy tranzakciós táblákat Összesítenek a lekérdezés teljesítményének felgyorsítása érdekében.
2. hozzon létre származtatott táblákat különböző adatforrásokból származó oszlopokkal
3. cserélje ki / maszkolja az érzékeny adatokat a kiválasztott felhasználói csoportokhoz.

egy másik javaslat az, hogy hozzon létre egy új adatbázis-sémát az adattárházban az átalakított (vagy utólag feldolgozott) táblák tárolására.

Az egyes adatforrások sémák szerinti elválasztásának korábbi megközelítéséhez hasonlóan egy adott séma létrehozása segíthet azonosítani a származtatott/átalakított adattáblák listáját. Ez később hasznos lesz, amikor elkezdi az adatimportok sorozatát, az adatok átalakítják a feladatokat egymás után, ahogy az adatok érettsége növekszik.

készítse el belső adatdokumentumait

Ez fontos, különösen, ha nem akarja, hogy az adattárház fekete doboz legyen, ahol csak néhány mérnök érti a használatát. Ha a felhasználók nem értik, akkor nem lesznek biztosak abban, hogy lekérdezik.

először is létrehozhat egy megosztott dokumentumot (lehet Google Doc), amely leírja a forrásadatok

• táblázatainak és oszlopainak közös megértését, valamint azok értelmezését
• tartalmazzon adatdiagramot, ha van ilyen.
• Hogyan olvassuk el a jelentések oszlopait (irányítópult, mutatók) és a mögöttük álló feltételezéseket

minden jelentés létrehozásakor (vagy frissítésekor) frissítse ezt a dokumentumot, hogy tükrözze az adatok üzleti ismeretének új szintjét.

további részleteket fogunk megosztani arról, hogyan lehet létrehozni és strukturálni ezt a belső adatdokumentumot egy külön bejegyzésben, ezért vigyázzon erre a helyre!

ez az!

reméljük, hogy ez az útmutató hasznos volt! Tudassa velünk, hogyan segíthetünk utazásában egy megbízható adattárház felépítésében.