Jak postavit datový sklad pro e-shop

Postavit datový sklad znamená sedm kroků: napojit zdroje, vybrat databázi, rozběhnout dopravu dat, uspořádat je do vrstev, postavit datový model, nad ním dashboardy — a všechno otestovat a předat. U typického e-shopu to trvá do šesti týdnů, první dashboardy vidíte za 2–4 týdny. Žádná magie ani roční IT projekt. Tady je celý postup, jak postavit datový sklad pro e-shop — krok za krokem, přesně tak, jak sklady stavíme my.

1. Napojení zdrojů: odkud data potečou

Než sáhneme na první systém, potřebujeme vědět, jaká čísla váš byznys skutečně řídí. Marže, PNO, obrátkovost zásob, podíl vracejících se zákazníků — od hlavních metrik se odvíjí, které zdroje sklad potřebuje a v jakém detailu. Tahle úvodní analýza zabere pár hodin rozhovoru, ne týdny workshopů.

Typický český e-shop přitom žije v předvídatelné sestavě:

• e-shop — Shoptet,
• účetnictví — Pohoda nebo Money S3,
• fakturace — iDoklad,
• reklama — Sklik, Meta, Google Ads.

Na tyhle systémy máme hotové konektory, takže napojení není výzkum, ale rutina. Shoptet a iDoklad mají API, Pohoda umí XML komunikaci, reklamní platformy nabízejí reportingová rozhraní. Méně obvyklý zdroj — skladový systém, Heureka, věrnostní program — se přidává stejným postupem, jen konektor vzniká na míru.

2. Kde sklad poběží: PostgreSQL, nebo Databricks

Standardní odpověď zní: datový sklad na PostgreSQL, na vašem serveru (varianta Growth, 149 000 Kč jednorázově). PostgreSQL je open-source databáze bez licenčních poplatků, prověřená desítkami let produkčního provozu. Objem dat běžného e-shopu — statisíce objednávek, miliony řádků položek — utáhne i na menším serveru: žádný speciální hardware, běžný virtuální server za pár stovek měsíčně stačí. Cloudový sklad typu Snowflake nebo BigQuery byste na tomhle objemu ani nevytížili — platili byste za připravenost, kterou nevyužijete. Data jsou navíc fyzicky u vás a nic vás nedrží u konkrétního dodavatele.

Dvě situace vedou jinam. Menší e-shopy často nechtějí vlastní server vůbec řešit — pro ně sklad provozujeme jako službu na naší infrastruktuře (Starter, 23 000 Kč měsíčně), technologie zůstává stejná. A pro firmy s vlastním ERP nebo s objemy, které relační databázi přerostou, stavíme na Azure Databricks (Pro, 439 000 Kč). Postup je ve všech třech případech totožný, mění se platforma pod ním, ne logika. Co přesně v jednotlivých cenách je a kdy se investice vrátí, rozebírá článek o ceně datového skladu.

3. Python pipeline: doprava dat

Databáze sama o sobě je prázdná skořápka — život do ní přináší pipeline. U nás je to sada Python skriptů, která běží podle rozvrhu, typicky každou noc, a má tři úkoly:

1. stáhnout nová data ze všech napojených zdrojů,
2. uložit je do skladu přesně tak, jak přišla,
3. transformovat — vyčistit, propojit mezi systémy a spočítat metriky.

Pořadí je záměrné a říká se mu ELT (extract, load, transform). Surová data se uloží dřív, než se na ně sáhne. Když se v transformaci najde chyba, opraví se výpočet a pustí znovu nad původními daty — nic se neztratilo, historie zůstává.

Běžné stahování je přírůstkové: každý běh bere jen to, co od minula přibylo nebo se změnilo, takže zdrojové systémy nezatěžuje. Při prvním spuštění se naimportuje i historie, jak hluboko ji zdroje dovolí — meziroční srovnání tak v reportech máte od prvního dne, ne až za rok.

Pipeline má i druhou, méně viditelnou roli: hlídá. Každý běh zapisuje, kolik záznamů odkud stáhl. Když zdroj nevrátí data, změní se struktura API nebo čísla vypadnou z obvyklých mezí, dozvíme se to z upozornění my — ne vy v pondělí na poradě z podezřele vypadajícího reportu.

4. Vrstvy: od surových dat k metrikám

Uvnitř skladu data neleží na jedné hromadě. Vedeme je vrstvami — od surových záznamů přes vyčištěná a propojená data až po hotové byznysové metriky. Každá vrstva má jeden úkol, a když něco nesedí, dá se každé číslo v reportu dohledat zpátky až ke zdrojovému záznamu. Tomuhle uspořádání se říká medailonová architektura (bronze, silver, gold) — odkud se vzala a proč funguje, rozebíráme v samostatném článku. Pro stavbu je podstatné jedno: vrstvy jsou důvod, proč se sklad nerozsype při první změně zdroje a proč se mu dá věřit.

5. Datový model: tvar, nad kterým se reportuje

Hotové metriky ještě nejsou report. Aby šla čísla filtrovat a skládat podle libosti — tržby podle kanálu, marže podle kategorie, obojí po měsících — musí mít data správný tvar. Nejdřív se určí „zrno”: co znamená jeden řádek, jestli celá objednávka, nebo jedna její položka. Pak se volí tvar podle reportovacího nástroje — hvězdicové schéma pro Power BI, ploché široké tabulky pro Superset. Rozdíly obou přístupů a podle čeho vybíráme popisujeme v článku hvězdicové schéma, nebo jedna velká tabulka.

6. Dashboardy: teprve teď přijde vizualizace

Dashboardy stavíme jako poslední — a schválně. Graf nad špatně připravenými daty je jen hezky zabalená nejistota. Nad hotovým modelem naopak vzniká dashboard rychle: obchodní přehled s tržbami a maržemi, marketingový pohled s PNO podle kanálů, skladový report s obrátkovostí a ležáky. Dashboardů bývá víc podle toho, kdo s nimi pracuje: majitel řeší marži a cash flow, marketér výkon kanálů, nákupčí zásoby. Stavíme je na metrikách, kterými firmu skutečně řídíte, ne na generické šabloně. Aktualizace běží automaticky — ráno otevřete přehled a vidíte včerejší stav, bez exportů a bez čekání, až čísla někdo ručně sestaví. Kolik čerstvosti doopravdy potřebujete — a proč většině firem stačí noční dávka — rozebíráme zvlášť.

7. Testování a předání

Než sklad předáme, čísla se musí potkat se zdrojovými systémy: tržby ve skladu proti účetnictví, počty objednávek proti e-shopu — konkrétní měsíc, na korunu přesně. Rozdíly se nezametají — každý se dohledá a vysvětlí, ať jde o dobropisy, časování plateb, nebo DPH. K tomu ve skladu běží automatické kontroly na vstupu: duplicity, chybějící záznamy, nesjednocené formáty. Jak se kvalita dat pozná a měří, máme popsané zvlášť.

Samotné předání u varianty Growth znamená, že sklad je celý váš: server, databáze, kód pipeline, dokumentace i přístupy. Součástí dokumentace je definice každé metriky — co přesně znamená marže, co všechno se počítá do nákladů na objednávku. Právě tahle jednoznačnost později šetří hodiny dohadů nad reporty. Zaškolíme lidi, kteří budou s reporty pracovat, a domluvíme se na podpoře a rozvoji — technicky vám ale nic nebrání pokračovat bez nás. To je záměr, ne opomenutí.

Jak dlouho stavba trvá

U standardní sestavy zdrojů vypadá harmonogram takhle:

• Týden 1–2 — analýza metrik, přístupy ke zdrojům, napojení konektorů, první surová data ve skladu.
• Týden 2–4 — vrstvy, datový model, první dashboardy. Od téhle chvíle s čísly reálně pracujete.
• Do 6 týdnů — testování proti zdrojům, doladění metrik, zaškolení a předání.

Nejčastější zdržení přitom nebývá technické. Čeká se na přístupy k systémům a na rozhodnutí, jak přesně se má počítat marže — obojí umíte ovlivnit vy. U varianty Pro s nestandardními systémy je harmonogram individuální, konektory na míru zaberou déle.

---

Chcete vidět, jak by tenhle postup vypadal nad vaším e-shopem? Ozvěte se — projdeme vaše systémy a řekneme rovnou postup, termín i cenu.