Design Pattern #5: Transakční data | Mňamka #165
Transakční data jsou všude kolem nás. Položka objednávky eshopu, nákup v obchodě… jak s nimi “zacvičit” tak, abychom se nemuseli dřív nebo později vracet do transformace a přidávat požadovaný sloupec. Mrkněte na věci, které děláme automaticky… Proč? Protože věřte, že brzo na ně dojde řada.
1. First = yes / no
První výskyt události v datech vždy označíme. Jedná se o první objednávku zákazníka? Označíme ji first_order atributem.
Proč? Pokud si data takto předpřipravíme, vyhneme se tak zbytečně složitým výpočtům. Typicky se hodí pro počty nových zákazníků za určité období (suma first_order sloupce za toto období) a podobně.
2. Datum pro jednotlivé stavy
Změnu stavu objednávky/leadu a podobně zaznamenáváme pomocí datumových sloupců pro jednotlivé stavy. Pro každý stav, který může nastat, existuje samostatný sloupec. Např. objednávka přijatá, expedovaná, uzavřená a další.
Proč? Snadno tak vyhneme zmatku, kdyz se atribut stav mění v rámci jednoho sloupce. Navíc můžeme pro každý záznam snadno sledovat dobu trvání konkrétního stavu. Alternativou je podřízená tabulka s jednotlivými objednávky a datem. Obě řešení můžeme i zkombinovat, podle toho, co je pro daný use case nejvýhodnější.
3. Transpozice ze “sloupečků” na samostatné “řádky”
Typicky používáme pro slevy, dopravu a služby, storno. Ze slev na faktuře vyrobíme samostatný řádek (položku faktury se zápornou cenou). Stejně postupujeme v případě storna nebo dopravy a dalších služeb. A co taková sleva prostřednictvím slevového kupónu na dané objednávce? Jasně, další řádek!
Proč? Místo sčítání a odčítání hodnot v různých sloupcích při výpočtu tržeb, sčítáme jeden sloupec a snadno filtrujeme, jaký typ položek chceme do tržeb zahrnout. Pro zachování referenční integrity doplníme takto vzniklé položky do nadřízené tabulky (např. dopravu od konkrétního dodavatele do tabulky zboží).
Hodně eshopařů rádo vytváří sloupec kde “je všechno”, ten se většinou jmenuje “total price” … nenechte se zmást. Vyplatí se dát si tu práci a celý proces rozklíčovat a následně si vytvořit jednoduché položky, přes které můžete filtrovat. Ve finále si ušetřítě hromadu starostí ve vizualizaci.
Máte nějaký další tip, který děláte “vždycky a všude”?
Zeptej se svých dat: BigQuery vs. Fabric vs. Copilot | Mňamka #558
Je to sen skoro každého manažera: místo čekání na analytika prostě napíšu do chatu „jak nám rostly tržby po regionech za poslední kvartál?" a za pár vteřin mám odpověď, ideálně i s grafem. Říká se tomu konverzační analytika a tři velcí hráči ji dnes nabízejí. My jsme si všechny tři osahali. Tady je upřímné srovnání, co funguje a kde to zatím drhne.
Postavili jsme stejného AI chatbota nad firemními daty v Googlu i v Microsoft Azure. | Mňamka #557
Skoro každá firma dneska sedí na hromadě vlastních dokumentů - produktové listy, FAQ, smlouvy, zápisy z projektů. A skoro každá firma by chtěla to samé: chatbota, kterému napíšete otázku a on odpoví z vašich dat, ne z toho, co si kde přečetl na internetu. Zní to jednoduše. My jsme si to chtěli osahat pořádně, a tak jsme jedno a to samé řešení postavili dvakrát - jednou v Google Cloudu, podruhé v Microsoft Azure. Tady je, co z toho vypadlo.
Microsoft Fabric vs. dbt | Mňamka #556
Když firmy modernizují svou datovou platformu, narazí dřív nebo později na otázku, jaký datový stack zvolit a co je pro jejich byznys nejvhodnější. Migrovat na Microsoft Fabric? Nasadit dbt? Otázka je ale položená trochu zavádějícím způsobem, jde totiž o srovnání dvou věcí, které stojí na jiné úrovni datového stacku: Fabric je platforma, dbt je transformační nástroj, který na takové platformě běží. Přesto má smysl se ptát, jak se tyto dva světy doplňují, kde si uvnitř Fabricu konkurují nativní nástroje a dbt, a kdy se vyplatí sáhnout po dbt jako standardní transformační vrstvě.
