Tableau u maloprodaji, stvarno?

Vrijeme za izvještavanje u Excelu ubrzano nestaje - trend ka praktičnim alatima za prezentiranje i analizu informacija vidljiv je na svim područjima. Dugo smo interno razgovarali o digitalizaciji izvještavanja te smo odabrali sustav za vizualizaciju i samouslužnu analitiku Tableau. Alexander Bezugly, voditelj odjela za analitička rješenja i izvješćivanje grupe M.Video-Eldorado, govorio je o iskustvima i rezultatima izgradnje borbene nadzorne ploče.

Odmah ću reći da nije realizirano sve što je planirano, ali iskustvo je bilo zanimljivo, nadam se da će i vama biti od koristi. I ako netko ima bilo kakvu ideju kako bi se to moglo bolje napraviti, bio bih jako zahvalan na savjetima i idejama.

Tableau u maloprodaji, stvarno?

Ispod presjeka je ono s čime smo se susreli i što smo naučili.

Gdje smo počeli?

M.Video-Eldorado ima dobro razvijen podatkovni model: strukturirane informacije sa potrebnom dubinom pohrane i veliki broj izvješća u fiksnom obliku (vidi više detalja ovaj članak). Od njih analitičari izrađuju ili zaokretne tablice ili formatirane biltene u Excelu ili prekrasne PowerPoint prezentacije za krajnje korisnike.

Prije otprilike dvije godine, umjesto izvješća u fiksnom obliku, počeli smo stvarati analitička izvješća u SAP Analysis (dodatak za Excel, u biti zaokretna tablica preko OLAP motora). No ovaj alat nije mogao zadovoljiti potrebe svih korisnika, većina je nastavila koristiti informacije koje su analitičari dodatno obradili.

Naši krajnji korisnici dijele se u tri kategorije:

Top menadžment. Traži informacije na dobro prezentiran i jasno razumljiv način.

Srednji menadžment, napredni korisnici. Zanima me istraživanje podataka i može samostalno izraditi izvješća ako su dostupni alati. Postali su ključni korisnici analitičkih izvješća u SAP Analysisu.

Masovni korisnici. Ne zanima ih samostalna analiza podataka, koriste se izvješćima s ograničenim stupnjem slobode, u formatu newslettera i pivot tablica u Excelu.

Naša ideja je bila pokriti potrebe svih korisnika i dati im jedinstven, praktičan alat. Odlučili smo započeti s top menadžmentom. Trebale su im nadzorne ploče jednostavne za korištenje za analizu ključnih poslovnih rezultata. Dakle, započeli smo s Tableauom i prvo odabrali dva smjera: maloprodajne i online pokazatelje prodaje s ograničenom dubinom i širinom analize, koji bi pokrili približno 80% podataka koje traži top menadžment.

Budući da su korisnici nadzornih ploča bili top menadžment, pojavio se još jedan dodatni KPI proizvoda - brzina odziva. Nitko neće čekati 20-30 sekundi da se podaci ažuriraju. Navigacija je trebala biti obavljena u roku od 4-5 sekundi, ili još bolje, obavljena odmah. A mi to, nažalost, nismo uspjeli postići.

Ovako je izgledao izgled naše glavne nadzorne ploče:

Tableau u maloprodaji, stvarno?

Ključna ideja je kombinirati glavne KPI pokretače, kojih je bilo ukupno 19, na lijevoj strani i prikazati njihovu dinamiku i raščlambu po glavnim atributima na desnoj strani. Zadatak se čini jednostavnim, vizualizacija je logična i razumljiva, sve dok ne uronite u detalje.

Detalj 1. Količina podataka

Naša glavna tablica za godišnju prodaju zauzima oko 300 milijuna redaka. Budući da je potrebno prikazati dinamiku za prošlu i pretprošlu godinu, obujam podataka samo o stvarnoj prodaji iznosi oko 1 milijardu redaka. Zasebno se pohranjuju i podaci o planiranim podacima i bloku online prodaje. Stoga, iako smo koristili stupčasti in-memory DB SAP HANA, brzina upita s odabirom svih indikatora za jedan tjedan iz trenutne memorije u hodu bila je oko 15-20 sekundi. Rješenje ovog problema se nameće samo po sebi – dodatna materijalizacija podataka. Ali ima i zamki, više o njima u nastavku.

Detalj 2. Neaditivni indikatori

Mnogi od naših KPI-jeva vezani su uz broj računa. I ovaj indikator predstavlja COUNT DISTINCT od broja redaka (provjerite zaglavlja) i prikazuje različite količine ovisno o odabranim atributima. Na primjer, kako bi se ovaj pokazatelj i njegova derivacija trebali izračunati:

Tableau u maloprodaji, stvarno?

Kako bi vaši izračuni bili točni, možete:

  • Izračunajte takve pokazatelje u hodu u pohrani;
  • Izvršite izračune na cijeloj količini podataka u Tableau, tj. na zahtjev u Tableau dostaviti sve podatke prema odabranim filterima u granularnosti pozicije prijema;
  • Stvorite materijalizirani izlog u kojem će se izračunati svi pokazatelji u svim opcijama uzorka koji daju različite neaditivne rezultate.

Jasno je da su u primjeru UTE1 i UTE2 materijalni atributi koji predstavljaju hijerarhiju proizvoda. To nije statična stvar, kroz to se odvija upravljanje unutar poduzeća, jer Za različite grupe proizvoda odgovorni su različiti menadžeri. Imali smo mnogo globalnih revizija ove hijerarhije, kada su se mijenjale sve razine, kada su se revidirali odnosi i stalne promjene točaka, kada je jedna grupa prelazila iz jednog čvora u drugi. U konvencionalnom izvješćivanju sve se to izračunava u hodu iz atributa materijala, au slučaju materijalizacije tih podataka potrebno je razviti mehanizam za praćenje takvih promjena i automatsko ponovno učitavanje povijesnih podataka. Vrlo netrivijalan zadatak.

Detalj 3. Usporedba podataka

Ova točka je slična prethodnoj. Zaključak je da je pri analizi poduzeća uobičajeno formirati nekoliko razina usporedbe s prethodnim razdobljem:

Usporedba s prethodnim razdobljem (iz dana u dan, iz tjedna u tjedan, iz mjeseca u mjesec)

U ovoj usporedbi pretpostavlja se da ovisno o razdoblju koje je odabrao korisnik (npr. 33. tjedan u godini) treba prikazati dinamiku do 32. tjedna; ako smo odabrali podatke za mjesec, npr. svibanj , tada bi ova usporedba pokazala dinamiku do travnja.

Usporedba s prošlom godinom

Glavna nijansa ovdje je da kada se uspoređuje po danu i po tjednu, ne uzimate isti dan prošle godine, tj. ne možete samo staviti tekuću godinu minus jedan. Morate pogledati dan u tjednu koji uspoređujete. Kada uspoređujete mjesece, naprotiv, trebate uzeti točno isti kalendarski dan prošle godine. Postoje i nijanse s prijestupnim godinama. U izvornim repozitoriju sve su informacije raspoređene po danima; nema zasebnih polja s tjednima, mjesecima ili godinama. Stoga, da biste dobili potpuni analitički presjek u panelu, morate računati ne jedno razdoblje, na primjer tjedan dana, već 4 tjedna, a zatim usporediti te podatke, odražavati dinamiku, odstupanja. Sukladno tome, ova logika za generiranje usporedbi u dinamici također se može implementirati u Tableau ili na strani izloga. Da, i naravno da smo znali i razmišljali o tim detaljima u fazi dizajna, ali bilo je teško predvidjeti njihov utjecaj na performanse konačne ploče s instrumentima.

Prilikom implementacije nadzorne ploče slijedili smo dugi Agile put. Naš zadatak je bio što brže osigurati radni alat s potrebnim podacima za testiranje. Stoga smo krenuli u sprinteve i krenuli od minimiziranja rada na strani trenutnog skladišta.

1. dio: Vjera u Tableau

Kako bismo pojednostavili IT podršku i brzo implementirali promjene, odlučili smo napraviti logiku za izračun neaditivnih pokazatelja i usporedbu prošlih razdoblja u Tableau.

Faza 1. Sve je uživo, bez izmjena prozora.

U ovoj smo fazi povezali Tableau s trenutnim izlozima i odlučili vidjeti kako će se izračunati broj potvrda za jednu godinu.

Rezultat:

Odgovor je bio deprimirajući – 20 minuta. Prijenos podataka preko mreže, veliko opterećenje na Tableau. Shvatili smo da logiku s neaditivnim indikatorima treba implementirati na HANA-u. To nas nije puno uplašilo, već smo imali slično iskustvo s BO i Analysis i znali smo kako izgraditi brze vitrine u HANA-i koje proizvode ispravno izračunate neaditivne indikatore. Sada je još samo ostalo prilagoditi ih Tableauu.

Faza 2. Ugađamo vitrine, nema materijalizacije, sve u hodu.

Stvorili smo zaseban novi izlog koji je u hodu proizvodio potrebne podatke za TABLEAU. Općenito, dobili smo dobar rezultat, smanjili smo vrijeme za generiranje svih indikatora u jednom tjednu na 9-10 sekundi. I iskreno smo očekivali da će u Tableau vrijeme odziva nadzorne ploče biti 20-30 sekundi pri prvom otvaranju, a zatim zbog cachea od 10 do 12, što bi nam općenito odgovaralo.

Rezultat:

Prvo otvaranje nadzorne ploče: 4-5 minuta
Bilo koji klik: 3-4 minute
Nitko nije očekivao toliko dodatno povećanje rada izloga.

Dio 2. Uronite u Tableau

Faza 1. Analiza izvedbe Tableau i brzo ugađanje

Počeli smo analizirati gdje Tableau provodi najviše vremena. I za to postoje prilično dobri alati, što je, naravno, plus Tableaua. Glavni problem koji smo identificirali bili su vrlo složeni SQL upiti koje je Tableau gradio. Prvenstveno su bili povezani s:

— prijenos podataka. Budući da Tableau nema alate za transponiranje skupova podataka, da bismo izgradili lijevu stranu nadzorne ploče s detaljnim prikazom svih KPI-jeva, morali smo izraditi tablicu pomoću slučaja. Veličina SQL upita u bazi podataka dosegnula je 120 znakova.

Tableau u maloprodaji, stvarno?

- izbor vremenskog razdoblja. Takvom upitu na razini baze podataka trebalo je više vremena za kompajliranje nego za izvršenje:

Tableau u maloprodaji, stvarno?

Oni. obrada zahtjeva 12 sekundi + 5 sekundi izvršenje.

Odlučili smo pojednostaviti logiku izračuna na strani Tableaua i premjestiti drugi dio izračuna na razinu izloga i baze podataka. To je donijelo dobre rezultate.

Prvo smo izvršili transpoziciju u hodu, učinili smo to kroz potpuno vanjsko spajanje u završnoj fazi VIEW izračuna, u skladu s ovim pristupom opisanim na wikiju Transponirati - Wikipedia, besplatna enciklopedija и Elementarna matrica - Wikipedia, besplatna enciklopedija.

Tableau u maloprodaji, stvarno?

Odnosno, napravili smo tablicu za postavljanje - matricu transpozicije (21x21) i primili sve pokazatelje u raščlambi red po red.

Bilo je:
Tableau u maloprodaji, stvarno?

Postalo je:
Tableau u maloprodaji, stvarno?

Gotovo se ne troši vrijeme na samu transpoziciju baze podataka. Zahtjev za sve pokazatelje za tjedan nastavio se obrađivati ​​za oko 10 sekundi. No, s druge strane, izgubljena je fleksibilnost u smislu konstruiranja nadzorne ploče na temelju određenog pokazatelja, tj. za desnu stranu nadzorne ploče gdje je prikazana dinamika i detaljna raščlamba određenog pokazatelja, prije je prikaz radio za 1-3 sekunde, jer zahtjev se temeljio na jednom indikatoru, a sada je baza podataka uvijek odabirala sve indikatore i filtrirala rezultat prije vraćanja rezultata u Tableau.

Kao rezultat toga, brzina nadzorne ploče smanjila se gotovo 3 puta.

Rezultat:

  1. 5 sekundi – analiziranje nadzornih ploča, vizualizacije
  2. 15-20 sekundi - priprema za sastavljanje upita uz izvođenje predizračunavanja u Tableau
  3. 35-45 sec - kompilacija SQL upita i njihovo paralelno-sekvencijalno izvršavanje u Hani
  4. 5 sec – obrada rezultata, sortiranje, preračunavanje vizualizacija u Tableau
  5. Naravno, takvi rezultati nisu išli na ruku poslovanju te smo nastavili s optimizacijom.

Faza 2. Minimalna logika u Tableauu, potpuna materijalizacija

Shvatili smo da je nemoguće izgraditi nadzornu ploču s vremenom odgovora od nekoliko sekundi na prodajnom izlogu koji radi 10 sekundi, te smo razmotrili opcije za materijalizaciju podataka na strani baze podataka posebno za traženu nadzornu ploču. Ali naišli smo na gore opisani globalni problem - neaditivni pokazatelji. Nismo se uspjeli uvjeriti da se Tableau prilikom mijenjanja filtara ili detaljnih analiza fleksibilno prebacivao između različitih prodajnih izloga i razina unaprijed dizajniranih za različite hijerarhije proizvoda (u primjeru, tri upita bez UTE, s UTE1 i UTE2 generiraju različite rezultate). Stoga smo odlučili pojednostaviti nadzornu ploču, napustiti hijerarhiju proizvoda na nadzornoj ploči i vidjeti koliko bi to moglo biti brzo u pojednostavljenoj verziji.

Dakle, u ovoj posljednjoj fazi, sastavili smo zasebno spremište u koje smo dodali sve KPI-jeve u transponiranom obliku. Na strani baze podataka, svaki zahtjev za takvu pohranu obrađuje se za 0,1 - 0,3 sekunde. Na nadzornoj ploči dobili smo sljedeće rezultate:

Prvo otvaranje: 8-10 sekundi
Bilo koji klik: 6-7 sekundi

Vrijeme koje Tableau provodi sastoji se od:

  1. 0,3 sek. — parsiranje nadzorne ploče i kompilacija SQL upita
  2. 1,5-3 sek. — izvršavanje SQL upita u Hani za glavne vizualizacije (radi paralelno s korakom 1)
  3. 1,5-2 sek. — renderiranje, ponovno izračunavanje vizualizacija
  4. 1,3 sekunde — izvršavanje dodatnih SQL upita za dobivanje relevantnih vrijednosti filtera (Brand, Division, City, Store), rezultati analize

Da ukratko sumiramo

Svidio nam se alat Tableau iz perspektive vizualizacije. U fazi izrade prototipa razmotrili smo različite elemente vizualizacije i sve smo ih pronašli u bibliotekama, uključujući složenu segmentaciju na više razina i vodopad s više pokretača.

Prilikom implementacije nadzornih ploča s ključnim pokazateljima prodaje, naišli smo na poteškoće u izvedbi koje još nismo uspjeli prevladati. Potrošili smo više od dva mjeseca i dobili funkcionalno nedovršenu nadzornu ploču čija je brzina odziva na rubu prihvatljivog. I sami smo izvukli zaključke:

  1. Tableau ne može raditi s velikim količinama podataka. Ako u izvornom podatkovnom modelu imate više od 10 GB podataka (otprilike 200 milijuna X 50 redaka), tada je nadzorna ploča ozbiljno usporena – od 10 sekundi do nekoliko minuta za svaki klik. Eksperimentirali smo s live-connectom i ekstraktom. Radna brzina je usporediva.
  2. Ograničenje pri korištenju više pohrana (skupova podataka). Ne postoji način da se naznači odnos između skupova podataka pomoću standardnih sredstava. Ako koristite zaobilazna rješenja za povezivanje skupova podataka, to će uvelike utjecati na izvedbu. U našem slučaju, razmotrili smo opciju materijaliziranja podataka u svakom potrebnom odjeljku prikaza i uključivanje tih materijaliziranih skupova podataka uz očuvanje prethodno odabranih filtara - pokazalo se da je to nemoguće učiniti u Tableau.
  3. U Tableau nije moguće napraviti dinamičke parametre. Ne možete ispuniti parametar koji se koristi za filtriranje skupa podataka u ekstraktu ili tijekom povezivanja uživo rezultatom drugog odabira iz skupa podataka ili rezultatom drugog SQL upita, samo izvornim korisničkim unosom ili konstantom.
  4. Ograničenja povezana s izradom nadzorne ploče s elementima OLAP|PivotTable.
    U MSTR, SAP SAC, SAP Analysis, ako dodate skup podataka u izvješće, tada su svi objekti na njemu povezani jedni s drugima prema zadanim postavkama. Tableau to nema; veza se mora konfigurirati ručno. Ovo je vjerojatno fleksibilnije, ali za sve naše nadzorne ploče ovo je obavezan zahtjev za elemente - tako da su to dodatni troškovi rada. Štoviše, ako napravite povezane filtre tako da je, na primjer, prilikom filtriranja regije popis gradova ograničen samo na gradove te regije, odmah ćete završiti s uzastopnim upitima prema bazi podataka ili Ekstraktu, što osjetno usporava nadzorna ploča.
  5. Ograničenja u funkcijama. Masovne transformacije ne mogu se napraviti niti na ekstraktu niti, POSEBNO, na skupu podataka iz Live-connecta. To se može učiniti kroz Tableau Prep, ali to je dodatni posao i još jedan alat za učenje i održavanje. Na primjer, ne možete prenijeti podatke niti ih spojiti sami sa sobom. Ono što se zatvara kroz transformacije na pojedinim stupcima ili poljima, koja se moraju odabrati kroz case ili if, a to generira vrlo složene SQL upite, u kojima baza najviše vremena troši na sastavljanje teksta upita. Ova nefleksibilnost alata morala se riješiti na razini izloga, što dovodi do složenije pohrane, dodatnih preuzimanja i transformacija.

Nismo odustali od Tableaua. Ali Tableau ne smatramo alatom koji može izgraditi industrijske nadzorne ploče i alatom s kojim bi se mogao zamijeniti i digitalizirati cijeli sustav korporativnog izvještavanja tvrtke.

Sada aktivno razvijamo sličnu nadzornu ploču u drugom alatu i istovremeno pokušavamo revidirati arhitekturu nadzorne ploče u Tableauu kako bismo je još više pojednostavili. Ako je zajednica zainteresirana, obavijestit ćemo vas o rezultatima.

Također čekamo vaše ideje ili savjete kako u Tabeauu možete izgraditi brze nadzorne ploče nad tako velikim količinama podataka, jer imamo web stranicu na kojoj ima puno više podataka nego u maloprodaji.

Izvor: www.habr.com

Dodajte komentar