Jak v Liftagu ověřujeme hypotézy na datech pomoci Omnisci

 V minulém článku jsem psal o tom, jak necháváme lidi pracovat s daty, aby si mohli ověřit nápady přímo na nich a nemuseli tak čekat na typicky přehlcené BI oddělení.

Abyste si mohli analyzovat všelijaké nápady, musíte projít dvěma kroky:

1. Předpřipravit si data, používáme je ve formě super table
2. Začít skládat nápady do grafů a začít ověřovat svoje hypotézy

Plachta aka super-table

Visualizace v OmniSci jsou silné nad jednou tabulkou. Neumí to dělat vůbec žádné joiny. Což se nakonec ukazuje jakou featura a ne bug.

Fungujeme tak, že máme jednu obrovskou tabulku, kde je všechno pro danou doménu, třeba objednávky či uživatele. Každá řádka má typicky dvě části:

1. Data spojená s danou entitou. Třeba objednávkou. Její datum, čas, idčka, souřadnice, adresy, platby atp.
2. Napočítaná data k určitým atributům entity. Např. k příslušnému pasažerovi u objednávky máme napočítaný celkový počet objednávek, které udělal za poslední dobu, počet jízd za poslední dobu, průměrný nabídnutý tarif za poslední dobu atp.

Sloupců prvního typu máme tak 80, druhého 150. Vtip je v tom, že ty dopočítané atributy časem přidáváme podle toho jak hluboko se dostáváme k jádru daného problému.

V tomhle bodě je důležité lidem nebránit v tom, aby si k dané plachtě připočítali cokoliv dle libosti. V tom je ten point rychlého ověření v datech.

Napočítání řešíme takhle:

1. Všechno máme ideálně v jednom view tak, aby ho šlo snadno upravovat. A časem i refactorovat. Svoje změny tak vidíte ihned v datech.
2. Výpočet view běží nad Snowflake. Nepotřebujete řešit indexy, Snowflake umí window funkce, takže můžete dělat i velmi složité věci pro připočítaná data. Např. agregace pro objednávky v časovém okolí.
3. Přes S3 potom data putují do Omnisci.

OmniSci core database je optimalizovaná pro miliony řádků a zjevně stovky sloupců. Za realtimu. GPU podporu zatím vynechme, k tomu se můžeme vrátit později.

Event oriented přístup

Výše jsem nakousl strukturu plachty. Časem se nám velmi osvědčilo podvolit se přístupu OmniSci, takže to rád rozeberu do detailů.

Jak jsem již zmiňoval, jednotlivé plachty mají dva druhy fieldů: ty přímo spojené s doménou a ty dopočítané pro určitou vlastnost.

Lze na to koukat i jiným způsobem: daná entita je event v systému. Například jedna konkrétní vygenerovaná objednávka v určitém čase, místě atp. K němu vy potom lepíte v čase a místě platné informace.

Co to přesně znamená? Uvedu příklad.

Objednávka vznikla v daném čase a místě pro dané pasažéra. Tento pasažér v daném momentu měl určité statistiky. Dejme tomu za předchozích 90 dní k tomuto datu udělal deset objednávek a z nich bylo pět jízd. Zároveň těch pět jízd bylo odjeto s průměrným tarifem 24,5 czk. Těchto dopočítaných hodnot platných pro daný čas máme hromadu.

Jak s tím pracovat? Pojďme do části použití v OmniSci.

Bádání nad problémem

V OmniSci lze pár kliknutími přidávat grafy do boardu. Nemusíte nic předpočítávat ani sestavovat. Všechno si uděláte hezky za online a realtime.

Začínám vždycky tím, že si vyberu nějaký datum či den. Třeba úterý za několik posledních týdnů. Na histogramu mohu vybrat třeba jen dopoledne.

Protože mě zajímá jen pražské centrum, tak přidám mapu.

Dál se chci zaměřit na objednávky, které hodnotíme jako populární.

A celé jsem to dělal, abych podíval, jak dlouhé jízdy naši zákazníci jezdí a čím je platí.

Tady teď mohu zapojit ten eventový přístup. Na předchozích grafech máme vybrané určité objednávky pro určitý typ lidí. Pokud mám u každé z nich napočítané určité statistiky, mohu se hravě podívat, jací pasažéři to jsou. Tedy jaké vzdálenosti běžně jezdí a zda se liší od těch, které vidíme teď.

Jak to funguje doopravdy?

No, úplně stejně. Začnete s nějakou hypotézou a přidáváte a přidáváte grafy. V nich pak vybíráte segmenty, které vás nejvíc zajímají. Dokud nedojdete ke kořenu tohoto problému.

Naposled jsme takhle koukali na to jak se nám daří ve špičče a zda naše chování můžeme vylepšit. Nejdříve si vyberete opět datum, čas, místo na mapě. Potom si přidáte určité charakteristiky řidičů. Do druhého grafu vedle si dáte poptávku. A pomocí dopočítaných statistik se koukáte co a jak se v ty dané časy děje, kdo jezdí, jakou má dostupnost a jak se třeba akceptuje.

Celkem snadno se takhle doberete odpovědi na vaši otázku, zda má smysl programovat featuru XYZ, která řeší problém ABC. A nebo obráceně: zda ten problém vůbec máte. Ale to je námět na další článek 🙂