Průvodce analytiky pro navrhování moderního datového skladu

takže budete vyzváni k vytvoření datového skladu pro vaši společnost. Datový sklad, který je efektivní, škálovatelný a důvěryhodný. Pokud se vaše společnost vážně pustí do implementace výkaznictví dat jako klíčového strategického aktiva pro vaše podnikání, budování datového skladu se nakonec objeví v konverzaci.

ale budování datového skladu není snadné ani triviální. Více než 50 procent projektů datových skladů má omezené přijetí, nebo to budou přímé selhání.

Jak byste měli začít navrhovat a budovat svůj datový sklad? Jaké jsou úskalí a jak byste je měli optimalizovat? A co je nejdůležitější, kde mám začít?

tento příspěvek poskytuje průvodce na vysoké úrovni, jak přemýšlet o nastavení datového skladu, abyste se vyhnuli některým běžným nástrahám.

co je datový sklad?

moderní podnik má obvykle data uložená na různých místech (zdroje dat). Mohou to být data z:

• aplikační databáze: pro startupy je to pravděpodobně jejich hlavní produktová aplikace. Pro jiné podniky, to může být jejich point of sale aplikace,
• Webové aplikace: To může být aplikace, které je potřeba buď měřítku podnikání nebo udržovat obchodní operace. Příkladem může být software pro e-mailový marketing, jako je Mailchimp, webové analytické aplikace jako Google Analytics nebo Mixpanel, nebo dokonce účetní software jako Xero a Quickbooks.
• tabulky: může to být ve formě stolních tabulek (Excel, CSV) nebo online tabulek, jako jsou Tabulky Google. Tato data mohou být aktualizována ručně někým, nebo aktualizován aktivitou Zapier.

datový sklad synchronizuje data z různých zdrojů do jednoho místa pro všechny potřeby hlášení dat.

poskytuje data, která lze důvěřovat, že jsou spolehlivá, a zvládne vytížení dotazování od všech zaměstnanců ve společnosti.

navrhování datového skladu

Přečtěte si také: kdy byste měli získat datový sklad?

typické nastavení datového skladu vypadá takto:

navrhujete a stavíte datový sklad na základě vašich požadavků na podávání zpráv. Poté, co jste identifikovali potřebná data, navrhnete data pro tok informací do datového skladu.

vytvořte schéma pro každý zdroj dat

vytvořte schéma databáze pro každý zdroj dat, který chcete synchronizovat s databází. Tento

1. Vám pomůže rychle identifikovat zdroj dat, ze kterého každá tabulka pochází, což pomáhá s rostoucím počtem zdrojů dat. Budoucí analytici dat a členové obchodního týmu, kteří se připojí k Vaší společnosti, se také mohou rychle dozvědět, co má každý zdroj dat.
2. umožňuje přiřadit konkrétní oprávnění (čtení/zápis) pro každý zdroj dat. Například datový inženýr nemusí chtít umožnit juniorskému analytikovi pouze číst, ale nezapisovat do konkrétního schématu.

to je zvláště užitečné, když váš počet datových zdrojů roste v průběhu času. Stačí se podívat na počet zdrojů, ve kterých by vaše data mohla být.

například, můžete nastavit schéma se nazývá mailchimpxero nebo fbads pro e-mail marketing, finance a inzertní data chcete importovat z těchto aplikací do vašeho skladu, resp.

když importujete tabulku kontaktů z Mailchimp do databáze, můžete je
dotazovat jako:

SELECT name, email FROM mailchimp.contacts

jak vytvořit schéma

vytvoření schématu je snadné. Chcete-li vytvořit nové schéma, stačí zadat řádek. Ve skutečnosti je to jen 3 slova v Postgres.

CREATE SCHEMA 

příklad:

CREATE SCHEMA mailchimp

Poznámka 1: Noví analytici mohou být zmateni mezi schématem databáze. Existují 2 Definice schématu. Schéma může být použit k popisu buď

1. Jak tabulek a polí v databázi jsou vztaženy k sobě navzájem, nebo
2. složky pro databáze, tabulky, stejně jako, jak složky uspořádejte své soubory

Poznámka 2: mySQL databáze nepodporují schéma, takže možná budete chtít použít konvenci pojmenování pro jméno tabulky importu, jako mailchimp_contacts atd. To je jeden z důvodů, proč doporučujeme našim zákazníkům používat PostgreSQL pro svou reportingovou databázi.

Pohybující se zdroj dat do datového skladu

dalším krokem je synchronizace zdrojových dat do datového skladu. Vaši inženýři to mohou znát jako skript ETL.

Navrhněte skript importu s následujícími úvahami:

1. odstraňte sloupce, které jsou zjevně zbytečné. Není pro vás tak těžké je přidat později, pokud si uvědomíte, že je potřebujete.
2. přejmenujte názvy sloupců tak, aby byly popisnější nebo databázově přívětivější (například pomocí malých písmen nebo velbloudů.
3. odfiltrujte zjevně nepotřebné záznamy. To může být zaznamenává své interní uživatele test na své výrobní systém (někdy uživatelé mohou přidat data jako [email protected] nebo nastavení jejich křestní jméno jako testy)
4. Mapa rekordní hodnoty, aby byly lépe čitelné. Tím ušetříte úsilí analytiků, kteří je přejmenují během zprávy na CASE-IFs později). Například některé záznamy mohou ukládat číselné klíče (1,2,3, 99 atd.) nebo zkrácené názvy, které nemusí být známy zbytku organizace. V těchto případech budete chtít tyto klíče zmapovat na jejich skutečné hodnoty během procesu importu.
5. Po dokončení importu použijte databázové indexy do cílové tabulky. Poznámka: napsali jsme o tom, jaké indexy databáze jsou v dřívějším příspěvku.
6. zpracování chyb: nastavení e-mailů / / Slack výstražná zpráva, která má být zaslána příslušným zúčastněným stranám (zejména analytikům dat) s podrobnými protokoly chyb, když úloha selže. Možná budete chtít nastavit automatické pokusy o opakování (nebo automatizované procesy obnovy) v určitém časovém období, abyste v tomto případě snížili počet falešných pozitiv.

měli byste transformovat zdrojová (surová) data?

jednou z otázek, které se často ptáme, je, jak aplikovat datové transformace před přesunem dat do skladu.

přes GIPHY

naše obecná rada není dělat to. Alespoň ne na začátku. Zvláště pokud je to váš první projekt datového skladu. Má to několik důvodů.

a. Je nepravděpodobné, že máte jasné požadavky na potřeby transformace dat

i když dostanete „jasné požadavky“, je pravděpodobné, že se tento požadavek v průběhu projektu změní nebo bude zastaralý.

nebudete chtít trávit čas revizí skriptu ETL na základě toho, co různé zúčastněné strany chtějí v různých časových okamžicích.

přesunutí (netransformovaných) zdrojových dat vám pomůže oddělit závislost skriptu ETL od „obchodních požadavků“.

b. Je pravděpodobné, že budete potřebovat zdroj dat pro jiné případy

Přemýšlejte o tom, váš zdroj dat jako základní interakce, které mohou být odvozeny do více odvozené tabulky, buď agregací je podél různých rozměrů nebo jejich spojení s tabulkami z jiných zdrojů.

viz příklad níže, jak sledovat účinnost konverze prodávajícího.

při transformaci dat ztratíte podrobnosti ze zdrojových dat, které mohou být potřebné pro budoucí případy použití hlášení.

když například shrnete tržby podle časového období, ztratíte podrobnosti o konkrétních transakčních záznamech, které může jiný uživatel potřebovat ke korelaci s jinými zprávami.

přesunutí netransformovaných zdrojových dat vám poskytne flexibilitu pro jejich kombinaci s jinými zdroji dat.

potřeba zdrojových dat se stává důležitější, když se začnete zabývat vytvářením opakovaně použitelných datových modelů pro zodpovězení různých otázek. Viz příklad níže na kohortové zprávě je vytvořen s řadou post-transformovaných dat. To bude obtížnější, pokud nemáte

c. Snižte zatížení zdrojových systémů

spuštění datových transformací ve zdrojovém systému může zabrat značné prostředky, zejména pokud máte databázi, která obsluhuje zákazníky po celém světě.

nebudete ji chtít přetížit dlouho běžícími úlohami transformace dat před jejich přesunutím.

existuje několik případů, které mohou mít smysl pro transformaci dat před jejich přesunem, ale tyto případy jsou obvykle pro společnosti, které již nastavily spolehlivý datový sklad a chtějí jej dále vylepšit.

transformace dat k vyřešení konkrétního problému

přemýšlení o tom, jak transformovat data, může být složité. Pokud není zaškrtnuto, můžete nakonec strávit spoustu času optimalizací dat, která nepřinášejí firmě hodnotu.

plánování, navrhování a implementace datových transformací bez jasného výsledku je řešením, které hledá problém.

jedním dobrým pravidlem je začít s koncem v mysli. Transformace dat by měla být vytvořena pouze pro řešení praktického případu použití nebo problému z vašeho hlášení.

dobrým způsobem, jak najít (a upřednostnit) tyto praktické případy použití, je začít vytvářet sestavy a řídicí panely s importovanými daty.

Když uživatelé začnou zvyšovat problémy s výkonem dotazu, můžete se podívat na transformaci dat.

To může být způsobeno tím, hlásí, že buď
(a) Obsahuje vnořené poddotazy nebo vlastní výrazy tabulka (CTEs)

(b), Nebo více (drahé) se připojí přes více tabulek.

zde se hodí flexibilita sestav založených na SQL, která pomůže identifikovat problémy, které může transformace dat řešit.

pro každého analytika je snadné rychle identifikovat hlavní příčinu zpráv s dlouhými běžícími dotazy a zahájit optimalizaci jejich výkonu.

To se z velké části provádí automatickou předběžnou agregací dat. To lze provést pomocí zhmotněných pohledů, kde můžete vytvářet úlohy transformace dat, které buď:

1. agregují velké transakční tabulky pro urychlení výkonu dotazu.
2. Vytvořte odvozené tabulky se sloupci z různých zdrojů dat
3. nahradit/maskovat citlivá data pro vybrané skupiny uživatelů.

dalším doporučením je vytvoření nového schématu databáze ve vašem datovém skladu pro uložení transformovaných (nebo pozpracovaných) tabulek.

stejně jako dřívější přístup k oddělení každého zdroje dat schématy, vytvoření konkrétního schématu vám může pomoci identifikovat seznam odvozených / transformovaných datových tabulek. To bude užitečné později, když začnete řetězec řadu importů dat, data transformovat úlohy v pořadí, jak vaše data zralosti roste.

Vytvořte interní datové dokumenty

to je důležité, zejména pokud nechcete, aby váš datový sklad byl černou skříňkou, kde jen několik inženýrů chápe, jak jej používat. Pokud tomu vaši uživatelé nerozumí, nebudou si jisti dotazem.

můžete začít tím, že vytvoří sdílený dokument (může být Google Doc), který popisuje společné chápání:

• Tabulky a sloupce ve zdroji dat, a jak je interpretovat
• Obsahují data, diagram, pokud existuje.
• Jak číst vaše sloupců v přehledech (palubní deska, metriky) a nějaké základní předpoklady, za nimi

pokaždé, když je zpráva vytvořena (nebo aktualizované), tento dokument aktualizovat, aby odrážel novou úroveň podnikání pochopení vaše data.

budeme sdílet další podrobnosti o tom, jak vytvořit a strukturovat tento interní datový dokument v samostatném příspěvku, takže pozor na tento prostor!

to je ono!

doufáme, že tato příručka byla užitečná! Dejte nám vědět, jak vám můžeme pomoci s vaší cestou k vybudování spolehlivého datového skladu.