Magamról

Saját fotó
Főiskolai, majd egyetemi diplomamunkáimtól kezdve világ életemben, adatok, adatbázisok, adattárházak (leginkább Oracle) környékén mozogtam. Mostanság adattárházasként, adatbányászként élem napjaimat.

2013. november 21., csütörtök

Tableau: Lehet-e egy vizualizálás "lassú"?

.
Bizony lehet - mily meglepő... ;) A dolog háttere, orvosságai viszont nem egyszerű topik.

Az én tapasztalatom szerint az üzleti userek, perdöntően nem szeretik az SQL-t, viszont tetszőleges mennyiségben szeretnek kattingatni. Nem véletlen, hogy annó SQL-alternatívaként létrejöttek különféle query-builderek, amik elfedték az SQL-t a felhasználó elöl, és megadták a kattingatás élményét.

Én mindig is nagy ellensége voltam ezeknek a query-buildereknek (ahogy szerintem az sql-ezni szeretők többsége is), mert általában éles környezetben sok adatra elengedett összeklikkelgetett query-k finoman szólva sem voltak optimálisak, súlyosabb esetben kvázi felsírt a szerver a végrehajtás során.

Ami még ezt is überelte, amikor "drag and drop"-pal tudtak valami soseem lefutó kifagyáshoz vezető csodát összehozni, teljesen torz szemléletet kölcsönözve az egész témának, hamisan értelmezett "ügyfélért mindent" elv alkalmazásaként. Ebben a műfajban a legelviselhetetlenebb szoftver az Oracle Discoverer volt.

Külön "szép" az idevágó Oracle Exadata sztori, ami úgy rettenetes pénzbe kerülő, hogy a problémakört nem oldja meg, csak egy kicsit jobban lazít a tárgybeli szorításon. Tipikusan az az út, amikor gondolkodás/tervezés helyett ablakon lehet kidobni zsákszámra a pénzt, vitatható megtérüléssel.

Volt olyan munkahelyem, ahol egyenesen tiltották is ezeket az adhoc összeklikkelgetett lekérdezéseket. Az a felhasználói kívánság még vágyálom, hogy ne kelljen foglalkozni ilyen aspektusokkal, csak csinálja meg a gép - és persze gyorsan - amire szükség van.



Na most a Tableau-ban is van ilyen eldugott query-builder, kerülöm is saját munkám során. ;) És ha van ilyen, akkor ebből a tényből triviálisan következik, hogy van ügyfélpanasz arra, hogy "lassú a Tableau".

Szegény Tableau két rossz között választhat: egy rossz és egy még rosszabb között. Elviseli igazságtalanul a vádat, hogy ő lassú lenne (ráadásul "gyorsuló idő" közepette), noha csak azt csinálja, amire utasítják. Vagy pedig lebeszéli a usereket az észnélküli adhoc lekérdezés-klikkelgetésről, potenciális ügyfeleket veszítve.

A poén az, hogy a Tableau-ban egy II.generációs intelligensebb query-builder van. Magyarán lehet úgy kattingatni az adatoforrások között, hogy okosabb kattingatáshoz gyorsabb vizualizálás tartozhat. Mit is jelent ez?

Például vizualizálás elötti adatforrás-definiáló "kattingatáshoz" érdemes tudni
- Hogy számít a filterek sorrendje.
- Hogy érdemes contextet használni, hogy ne full táblás joinok legyenek szűrések elött
- Hogy érdemes nem denormalizált táblákkal dolgozni (súlyos distinctes allekérdezéseket feleslegesen generálva), hanem a dimenziókat rendesen behúzni.
- Hogy nem mindegy live-e az adatkapcsolat.
- Hogy érdemes riportálási adatpiacra rácsattani, lényegesen jobb felhasználói élményért.
- És itt egy szót sem szólva olyan lehetőségekről, hogy szerver odlalon meg lehet nézni a Tableau által kigenerált SQL és végrehajtási tervét. Pedig mekkora okosság ám ez.

És akkor ezek csak a kattingatós trükkök. Most képzeljük el,hogy mennyivel jobb eredmény/feeling érhető el SQL segítségével. ;)

Nincsenek megjegyzések:

Megjegyzés küldése