Tableau al detall, realment?

El temps per a la presentació d'informes a Excel està desapareixent ràpidament: la tendència cap a eines convenients per presentar i analitzar la informació és visible en tots els àmbits. Hem estat discutint internament la digitalització dels informes des de fa molt de temps i hem escollit el sistema de visualització i anàlisi d'autoservei de Tableau. Alexander Bezugly, cap del departament de solucions analítiques i informes del grup M.Video-Eldorado, va parlar de l'experiència i els resultats de la construcció d'un tauler de combat.

De seguida diré que no es va fer tot el que estava previst, però l'experiència va ser interessant, espero que també us sigui útil. I si algú té alguna idea sobre com es podria fer millor, li agrairia molt els vostres consells i idees.

A sota del tall es parla del que hem trobat i del que hem après.

Per on vam començar

M.Video-Eldorado té un model de dades ben desenvolupat: informació estructurada amb la profunditat d'emmagatzematge requerida i un gran nombre d'informes de forma fixa (vegeu més detalls aquí teniu aquest article). A partir d'aquests, els analistes fan taules dinàmiques o butlletins amb format a Excel, o presentacions de PowerPoint precioses per als usuaris finals.

Fa uns dos anys, en lloc d'informes de forma fixa, vam començar a crear informes analítics a SAP Analysis (un complement d'Excel, bàsicament una taula dinàmica sobre el motor OLAP). Però aquesta eina no va poder satisfer les necessitats de tots els usuaris; la majoria va continuar utilitzant informació processada addicionalment pels analistes.

Els nostres usuaris finals es divideixen en tres categories:

Alta direcció. Demana informació de manera ben presentada i clarament entenedora.

Direcció mitjana, usuaris avançats. Interessat en l'exploració de dades i capaç de crear informes de manera independent si hi ha eines disponibles. Es van convertir en els usuaris clau dels informes analítics a SAP Analysis.

Usuaris massius. No els interessa analitzar dades de manera independent; fan servir informes amb un grau de llibertat limitat, en format de butlletins i taules dinàmiques en Excel.

La nostra idea era cobrir les necessitats de tots els usuaris i donar-los una única eina còmoda. Vam decidir començar amb l'alta direcció. Necessitaven taulers de control fàcils d'utilitzar per analitzar els resultats empresarials clau. Així doncs, vam començar amb Tableau i primer vam triar dues direccions: indicadors de vendes minoristes i en línia amb una profunditat i amplitud d'anàlisi limitades, que cobririen aproximadament el 80% de les dades sol·licitades per l'alta direcció.

Com que els usuaris dels taulers de control eren la direcció superior, va aparèixer un altre KPI addicional del producte: la velocitat de resposta. Ningú esperarà entre 20 i 30 segons perquè les dades s'actualitzin. La navegació s'hauria d'haver fet en 4-5 segons, o millor encara, a l'instant. I nosaltres, per desgràcia, no ho hem aconseguit.

Aquest és el que semblava el disseny del nostre tauler principal:

La idea clau és combinar a l'esquerra els principals indicadors de KPI, dels quals eren 19 en total, i presentar la seva dinàmica i desglossament per atributs principals a la dreta. La tasca sembla senzilla, la visualització és lògica i entenedora, fins que us submergiu en els detalls.

Detall 1. Volum de dades

La nostra taula principal de vendes anuals ocupa uns 300 milions de files. Com que cal reflectir la dinàmica de l'any passat i l'any anterior, només el volum de dades de vendes reals és d'uns mil milions de línies. La informació sobre les dades planificades i el bloc de vendes en línia també s'emmagatzemen per separat. Per tant, tot i que vam fer servir la columna DB SAP HANA a la memòria, la velocitat de la consulta amb la selecció de tots els indicadors durant una setmana des de l'emmagatzematge actual sobre la marxa va ser d'uns 1-15 segons. La solució a aquest problema es suggereix per si mateixa: materialització addicional de dades. Però també té inconvenients, més sobre ells a continuació.

Detall 2. Indicadors no additius

Molts dels nostres KPI estan lligats al nombre de rebuts. I aquest indicador representa COUNT DISTINCT del nombre de files (comprova les capçaleres) i mostra diferents quantitats en funció dels atributs seleccionats. Per exemple, com s'ha de calcular aquest indicador i la seva derivada:

Per fer els càlculs correctes, podeu:

• Calcula aquests indicadors sobre la marxa a l'emmagatzematge;
• Realitzeu càlculs sobre tot el volum de dades a Tableau, és a dir. a petició a Tableau, proporcioneu totes les dades segons els filtres seleccionats a la granularitat de la posició del rebut;
• Crear un aparador materialitzat en el qual es calcularan tots els indicadors en totes les opcions de mostra que donin diferents resultats no additius.

És evident que en l'exemple UTE1 i UTE2 són atributs materials que representen la jerarquia del producte. Això no és una cosa estàtica; la gestió dins de l'empresa es fa a través d'ella, perquè Diferents gestors són responsables de diferents grups de productes. Vam tenir moltes revisions globals d'aquesta jerarquia, quan van canviar tots els nivells, quan es van revisar les relacions i canvis de punts constants, quan un grup es movia d'un node a un altre. En els informes convencionals, tot això es calcula sobre la marxa a partir dels atributs del material; en el cas de la materialització d'aquestes dades, cal desenvolupar un mecanisme per fer el seguiment d'aquests canvis i recarregar automàticament les dades històriques. Una tasca gens trivial.

Detall 3. Comparació de dades

Aquest punt és similar a l'anterior. La conclusió és que quan s'analitza una empresa, s'acostuma a formar diversos nivells de comparació amb el període anterior:

Comparació amb el període anterior (dia a dia, setmana a setmana, mes a mes)

En aquesta comparació, s'assumeix que en funció del període seleccionat per l'usuari (per exemple, la setmana 33 de l'any), hauríem de mostrar la dinàmica a la setmana 32; si seleccionem dades d'un mes, per exemple, maig , llavors aquesta comparació mostraria la dinàmica a l'abril.

Comparació amb l'any passat

El matís principal aquí és que quan es comparen per dia i per setmana, no està prenent el mateix dia de l'any passat, és a dir. no podeu posar l'any actual menys un. Heu de mirar el dia de la setmana que esteu comparant. En comparar mesos, per contra, cal prendre exactament el mateix dia natural de l'any passat. També hi ha matisos amb anys de traspàs. Als repositoris originals, tota la informació es distribueix per dia; no hi ha camps separats amb setmanes, mesos o anys. Per tant, per obtenir una secció transversal analítica completa al tauler, cal comptar no un període, per exemple una setmana, sinó 4 setmanes, i després comparar aquestes dades, reflectir la dinàmica, les desviacions. En conseqüència, aquesta lògica per generar comparacions en dinàmiques també es pot implementar a Tableau o a l'aparador. Sí, i per descomptat vam conèixer i pensar en aquests detalls en l'etapa de disseny, però era difícil predir el seu impacte en el rendiment del quadre de comandament final.

Quan vam implementar el tauler, vam seguir el llarg camí àgil. La nostra tasca era proporcionar una eina de treball amb les dades necessàries per fer proves el més ràpidament possible. Per tant, vam anar a sprints i vam començar per minimitzar el treball al costat de l'emmagatzematge actual.

Part 1: Fe en el tauler

Per simplificar el suport informàtic i implementar canvis ràpidament, vam decidir fer la lògica per calcular indicadors no additius i comparar períodes passats a Tableau.

Etapa 1. Tot està en directe, sense modificacions a la finestra.

En aquesta fase, vam connectar Tableau als aparadors actuals i vam decidir veure com es calcularia el nombre de rebuts per a un any.

Resultat:

La resposta va ser depriment: 20 minuts. Transferència de dades a la xarxa, alta càrrega a Tableau. Ens vam adonar que la lògica amb indicadors no additius s'havia d'implementar a HANA. Això no ens va espantar gaire, ja teníem una experiència similar amb BO i Analysis i vam saber construir vitrines ràpides a HANA que produeixen indicadors no additius calculats correctament. Ara només faltava ajustar-los a Tableau.

Etapa 2. Tunem les vitrines, sense materialització, tot sobre la marxa.

Vam crear un nou aparador independent que va produir les dades necessàries per a TABLEAU sobre la marxa. En general, hem obtingut un bon resultat; hem reduït el temps de generació de tots els indicadors en una setmana a 9-10 segons. I sincerament, esperàvem que a Tableau el temps de resposta del tauler fos de 20-30 segons a la primera obertura i després a causa de la memòria cau de 10 a 12, que en general ens convindria.

Resultat:

Primer tauler obert: 4-5 minuts
Qualsevol clic: 3-4 minuts
Ningú s'esperava un augment addicional de les obres de l'aparador.

Part 2. Submergir-se al quadre

Etapa 1. Anàlisi del rendiment del tauler i ajust ràpid

Vam començar a analitzar on passa el Tableau la major part del temps. I hi ha eines força bones per a això, que, per descomptat, és un avantatge de Tableau. El problema principal que vam identificar eren les consultes SQL molt complexes que estava creant Tableau. Estaven associats principalment a:

- Transposició de dades. Com que Tableau no té eines per transposar conjunts de dades, per crear el costat esquerre del tauler amb una representació detallada de tots els KPI, vam haver de crear una taula amb un cas. La mida de les consultes SQL a la base de dades va arribar als 120 caràcters.

- elecció del període de temps. Aquesta consulta a nivell de base de dades va trigar més temps a compilar que a executar-se:

Aquells. processament de la sol·licitud 12 segons + execució de 5 segons.

Vam decidir simplificar la lògica de càlcul al costat del quadre i traslladar una altra part dels càlculs a l'aparador i a la base de dades. Això va donar bons resultats.

Primer, vam fer la transposició sobre la marxa, la vam fer a través d'una unió exterior completa a l'etapa final del càlcul VIEW, segons aquest enfocament descrit a la wiki Transposar - Viquipèdia, l'enciclopèdia lliure и Matriu elemental - Viquipèdia, l'enciclopèdia lliure.

És a dir, vam fer una taula de configuració: una matriu de transposició (21x21) i vam rebre tots els indicadors en un desglossament fila per fila.

Era:


Es va convertir en:


Gairebé no es dedica temps a la transposició de la base de dades. La sol·licitud de tots els indicadors de la setmana es va continuar processant en uns 10 segons. Però d'altra banda, s'ha perdut flexibilitat pel que fa a la construcció d'un quadre de comandament a partir d'un indicador concret, és a dir. per a la part dreta del tauler on es presenta la dinàmica i el desglossament detallat d'un indicador específic, anteriorment la vitrina funcionava en 1-3 segons, perquè la sol·licitud es basava en un indicador, i ara la base de dades sempre seleccionava tots els indicadors i filtrava el resultat abans de tornar el resultat a Tableau.

Com a resultat, la velocitat del tauler es va reduir gairebé 3 vegades.

Resultat:

1. 5 segons: anàlisi de taulers de control, visualitzacions
2. 15-20 segons: preparació per compilar consultes amb la realització de càlculs previs a Tableau
3. 35-45 segons: compilació de consultes SQL i la seva execució seqüencial paral·lela a Hana
4. 5 segons: processament dels resultats, classificació, recàlcul de visualitzacions a Tableau
5. Per descomptat, aquests resultats no s'adaptaven al negoci i vam continuar amb l'optimització.

Etapa 2. Lògica mínima en Tableau, materialització completa

Vam entendre que era impossible construir un tauler amb un temps de resposta de diversos segons en una botiga que s'executi durant 10 segons, i vam considerar opcions per materialitzar dades al costat de la base de dades específicament per al tauler de control requerit. Però ens hem trobat amb un problema global descrit anteriorment: els indicadors no additius. No hem pogut assegurar-nos que quan es canvien els filtres o els detalls, Tableau canviés de manera flexible entre diferents aparadors i nivells predissenyats per a diferents jerarquies de productes (en l'exemple, tres consultes sense UTE, amb UTE1 i UTE2 generen resultats diferents). Per tant, vam decidir simplificar el tauler, abandonar la jerarquia de productes al tauler i veure com de ràpid podria ser en una versió simplificada.

Així doncs, en aquesta última etapa, vam muntar un repositori separat en el qual vam afegir tots els KPI en forma transposada. Pel que fa a la base de dades, qualsevol sol·licitud a aquest emmagatzematge es processa en 0,1 - 0,3 segons. Al tauler hem rebut els següents resultats:

Primera obertura: 8-10 segons
Qualsevol clic: 6-7 segons

El temps que dedica Tableau consta de:

1. 0,3 segons. — anàlisi del tauler i compilació de consultes SQL
2. 1,5-3 segons. — execució de consultes SQL a Hana per a visualitzacions principals (s'executa en paral·lel amb el pas 1)
3. 1,5-2 segons. — renderització, recàlcul de visualitzacions
4. 1,3 segons. — execució de consultes SQL addicionals per obtenir valors de filtre rellevants (marca, divisió, ciutat, botiga), anàlisi de resultats

Per resumir-ho breument

Ens va agradar l'eina Tableau des d'una perspectiva de visualització. En l'etapa de prototipatge, vam considerar diversos elements de visualització i tots els vam trobar a les biblioteques, inclosa la segmentació complexa de diversos nivells i la cascada de diversos controladors.

Durant la implementació de quadres de comandament amb indicadors clau de vendes, ens hem trobat amb dificultats de rendiment que encara no hem pogut superar. Vam passar més de dos mesos i vam rebre un tauler de control funcionalment incomplet, la velocitat de resposta del qual està a punt de ser acceptable. I vam treure conclusions per nosaltres mateixos:

1. Tableau no pot funcionar amb grans quantitats de dades. Si al model de dades original teniu més de 10 GB de dades (aproximadament 200 milions X 50 files), el tauler de control es reduirà seriosament, de 10 segons a diversos minuts per cada clic. Hem experimentat tant amb la connexió en directe com amb l'extracció. La velocitat de funcionament és comparable.
2. Limitació en utilitzar diversos emmagatzematges (conjunts de dades). No hi ha manera d'indicar la relació entre conjunts de dades mitjançant mitjans estàndard. Si utilitzeu solucions alternatives per connectar conjunts de dades, això afectarà molt el rendiment. En el nostre cas, vam considerar l'opció de materialitzar les dades a cada secció de visualització requerida i fer canvis en aquests conjunts de dades materialitzats tot conservant els filtres seleccionats anteriorment; això va resultar impossible de fer a Tableau.
3. No és possible fer paràmetres dinàmics al Tableau. No podeu omplir un paràmetre que s'utilitza per filtrar un conjunt de dades en un extracte o durant una connexió en directe amb el resultat d'una altra selecció del conjunt de dades o el resultat d'una altra consulta SQL, només l'entrada d'usuari nativa o una constant.
4. Limitacions associades a la creació d'un tauler amb elements OLAP|PivotTable.
   A MSTR, SAP SAC, SAP Analysis, si afegiu un conjunt de dades a un informe, tots els objectes del mateix estan relacionats entre si de manera predeterminada. Tableau no té això; la connexió s'ha de configurar manualment. Probablement això sigui més flexible, però per a tots els nostres taulers de comandament aquest és un requisit obligatori per als elements, de manera que es tracta de costos laborals addicionals. A més, si feu filtres relacionats de manera que, per exemple, en filtrar una regió, la llista de ciutats es limita només a les ciutats d'aquesta regió, immediatament acabeu amb consultes successives a la base de dades o a l'Extracte, la qual cosa alenteix notablement la panell.
5. Limitacions en les funcions. Les transformacions massives no es poden fer ni a l'extracte ni, ESPECIALMENT, al conjunt de dades de Live-connecta. Això es pot fer mitjançant Tableau Prep, però és un treball addicional i una altra eina per aprendre i mantenir. Per exemple, no podeu transposar dades ni unir-les a si mateix. El que es tanca mitjançant transformacions en columnes o camps individuals, que s'han de seleccionar per majúscules o si, i això genera consultes SQL molt complexes, en les quals la base de dades passa la major part del seu temps compilant el text de la consulta. Aquesta inflexibilitat de l'eina s'havia de resoldre a nivell d'aparador, la qual cosa comporta un emmagatzematge més complex, descàrregues addicionals i transformacions.

No hem renunciat a Tableau. Però no considerem Tableau com una eina capaç de crear quadres de comandament industrials i una eina amb la qual substituir i digitalitzar tot el sistema d'informes corporatius d'una empresa.

Ara estem desenvolupant activament un tauler de control similar en una altra eina i, al mateix temps, intentem revisar l'arquitectura del tauler de control a Tableau per simplificar-lo encara més. Si la comunitat està interessada, us informarem dels resultats.

També estem esperant les vostres idees o consells sobre com a Tabeau podeu crear taulers de control ràpids sobre volums de dades tan grans, perquè tenim un lloc web on hi ha moltes més dades que al detall.

Font: www.habr.com