.jpg)
.
Haskel Financial Data Modeling and Predictive Analytics
Friss meleg nyomdaszagú könyv:) Csak 165 oldal és így is annyira kemény a témája, hogy csak hírt vagyok képes adni róla, kutyafuttában, egyéb teendők miatt.
Mennyi, de mennyi rossz érzésem volt a funkcionális nyelvek irányába, minden erényük elismerése mellet, mit vitatkoztam az ügyben, árral szembemenve :)
Az ellenérzéseim perdöntően abból fakadtak, hogy
* Ki fogja ezeket megtanulni (na és melyiket: Scala, Clojure, Erlang etc.)?
* Na pláne ki fog módosítani, egy korábbi fejlesztést?
* Mennyire átjárhatók egy C/PASCAL analógiában?
* Mennyire zavar be az OO-paradigma támogatása?
* Mennyire elég, ami belőlük a Pythonban van implementálva, limitáltan?
* Mennyi hozzáadott érték van, effektíve pros-cons alapon számbavehető módon?
* Mennyiben intellektuális onanizálás az egész?
* Mennyiben l'art pour l'art -> valami mesterséges absztrakt szépség ideálért?
* Mennyiben hype?
Ami a véleményemmel szemben zavart_
* A párhuzamos feldolgozás látványos támogatása kezdettől fogval nyugtalanító volt számomra :)
* Tömörség,
* Lambda-kalkulus tömör ám kifejező ereje
* A hírek szerint, jobban működő programok írhatók, értsd
valószínűbben csinálják azt, amire írták
* Ehhez jött a MapReduce paradigmában betöltött életerős szerepük.* És most már a prediktív analitika ajtaján is dörömbölnek a funkcionális nyelvek.
* Alkalmazás is van már láttam Clojure-wrappert java-s data mining libraryhez.
* Könyv is jelenik meg még ha első körben csak 165 oldalban
Érdekesség: a 165 oldalba még install-folyamat, nyelvi bevezető és text-feldolgozás is belefért.
Az első "igazi" topik, a Grubb's test outlier analízishez.
Igazándiból a Kálmán-filter-t lett volna érdekes kiemelni, mert az jóval közismertebb, de kedvezzünk az egyszerűségi elvnek. :)
Bemásolom ide alább a vontkozó kódot, elmékedésre, és én elhallgatok. ;)
module Grubbs (
grubbs
) where
import qualified Data.Vector.Unboxed as U
import Statistics.Sample
grubbs :: [Double] -> Maybe Double
grubbs xs
| numOfOutliers > 0 = Just $ fst $ U.maximumBy cmpByG outliers
| otherwise = Nothing
where n = fromIntegral $ length xs
gCritical = (n-1)/(sqrt n)
v = U.fromList xs
(m,s) = meanVarianceUnb v
stddev = sqrt s
getGtuple x = (x, (abs (x - m))/stddev)
isOutlier (_, g) = g > gCritical
outliers = U.filter isOutlier $ U.map getGtuple v
numOfOutliers = U.length outliers
cmpByG (_, a) (_, b) = compare a b
2013. november 24., vasárnap
2013. november 23., szombat
Blackbox adatbázis kifehérítése üzleti felhasználóknak
.
FELADAT: Adva van egy üzleti felhasználók számára totálisan black box Oracle adatbázis. Nem scope annak fejtegetése, hogy ez hogyan eshetett meg a XXI.századra. ;) Természetesen az üzleti felhasználók, szeretnék tudni mi van benne, sőt módosítási igényeik is vannak, sőt ráadásul - horribile dictu - gyorsan szeretnének módosulási eredményeket látni. Azaz dokuemntálni kéne visszamenőleg és minél használhatóbb módon előrefele. Van pénzük a projektre, mi legyen a javasolt technológia?
1.
Erre az egyik kézenfekvő megoldás gyári szoftver vásárlása, horribilis pénzekért végtelenül limitált funkcionalitással. Ilyen például Busines Objects Universum Designere. Aki ezirányban akarna továbbolvasni, annak más site javasolt, nem ez a blogposzt. ;) Magam részéről ezt a megoldást teljességgel elutasítom.
2.
Marad tehát valamiféle "custom" megoldás. Ami nekem hirtelenjében eszembejut az két lehetőség: egy minimális ám gyorsan implementálható brute force megoldás és egy maximális hiperintelligens. Mindkét megoldás ipari standardeket használna, de csak részben state-of-art termékekkel, részben egyedi fejlesztésűekkel.
Alapelv: elsőrendű prioritás, hogy minél inkább gombnyomásra automatikusan up-to-date legyen a dokumentáció.
(1) A minimális ám gyorsan implementálható brute force megoldás
Oracle adatszótárában megvannak a tárolt-eljárás és táblák függései. Feltehető, hogy egyéb Oracle objektumtípus nincs.
Tegyük fel, hogy elkészül egy alap kifehérítő dokumentáció valahogyan.
Bármilyen ("mérföldköves") fejlesztés elött és után csinálunk (text-alapú) snapshotot
- a struktúrákról.
- a függésekről.
Az érintett módosuló kódokat péládul SVN-be rámoljuk (programból)
SVN-diff programból való hívásának segítségével dokumentáljuk a változásokat, minden változástípusnál értelemszerűen.
Fontos látni, hogy nem-feltétlen csak az Oracle belső adatszótárára/dependenciáira lehetne csak támaszkodni: Külön (meta)sémába lehetne hozzáadott értékekkel kiegészíteni, egyedi custom-fejlesztés révén.
Fontos látni, hogy univerzális terméket nem így kell fejleszteni, viszont a megrendelői igények lokális-specifikus lefedését a legkönnyebb így támogatni.
Mindez relatíve egyszerű, gyors fejlesztésű, gombnyomásra aktualizálható, de ha én üzleti user lennék, bizony húznám a számat rá, hiszen erősen IT-alapú, nekem üzleti userként, üzleti alapú kéne nekem.
(2) A maximális hiperinteligens megoldás
Intelligens „master/meta data management”-es univerzum-építés, jó szoftver hiányában, custom-fejlesztéssel.
A fejlesztés végén, múlhatatlan üzleti igény esetén persze bevethető ilyesmi is, például ha rajzolgatni szeretne az ügyfél (aminek én sose láttam értelmét, a modern kor mennyiségi és komplexitási igényeit nézve).
Blackbox adatbázisunkban
- Vannak az alapadatok és a származtatott adatok.
- Minden adat alapadat, ami kívülről interface-n keresztül jön és nem módosul sose rendszeren belül.
- Minden más származtatott adat.
- Ha egy táblában mindkettő van, azt szét kell bombázni kétfelé (minimum logikai értelemben), az én értelmezésem szerint
El kell kezdeni üzleti objektumokat definiálni, amik egymásra épülnek (hierarchiába).
Akkor jó egy üzleti objektum, ha
- könnyű olvasni és egyértelműen értelmezni (az implementált logikát)
- a ráépülés során komoly hozzáadott érték képződik.
Az üzleti objektum tartalmaz
- Nevet (fizikai és üzleti)
- Kulcsokat, ddl-definiciókat.
- Logikát
- Szöveges leírást
- Data Profile-ingot (NULL, kategória-e, stb).
- Ki határozza meg a számosságot: csomó left join esetén nyilván a base tábla, amihez joinolunk.
- Stb. (mindez rendszerszervezési kérdés)
Ami egyedül fontos,hogy azonosítani kell, mi az ami programból tud jönni, és mi az ami manualitást igényel.
Az üzleti objektum üzleti logikája jellemzően SQL (+opcionálisan 3GL kód)
Az SQL-nek minél egyszerűbbnek kell lennie, de nem feltétlen minden határon túlmenően, csak a józan ész szerint (ez az például, amit a kereskedelmi szoftverek a belátható jövőben NEM fognak tudni univerzálisan támogatni)
- Lehet benne UNIO, de csak akkor ha garantáltan diszjunkt
- Lehet benne összetett logikai feltétel, de csak ha átlátható.
- Lehet benne több join is, de lehetőleg csak egyfélék.
- Meg kell különböztetni a törzsadatokat a tranzakciós adatoktól.
- Master-Detail join például nem lehet már (elvi alapokon se), azt szét kell szedni ketté.
- Lehet két- vagy többféleféle „átlagegyenleg”-típusú üzleti logika (pl.: egy termékfejlesztési és egy riskes), viszont különbséget kell tudni képezni új objektum bevezetésével (dekomponálás).
- Lehet többféle tranzakcióleválogatás, de mindegyiknek legyen értelme, neve.
- Nem baj, ha érkezik egy újabb „átlagegyenleg”-definició, de valami korábbira hasonlítania kell és különbséget kell tudni képezni hozzá.
- Garantálni a konszolidált állapothoz való konvergálást, szabályokkal, szabályrendszerrel
stb.
Az üzleti objektumnok jellemzően JOIN-okkal kapcsolódnak.
Ezek után egy új funkcionalitás úgy tudhat kinézni, hogy egy hierarchia közepén lévő üzleti objektumba jellemzően ÚJ attribútum képződik.
Aki eljárások ezt olvassák azokat ez nem szabad zavarja.
Tehát csak lefelé érdekes a hierarchia
Azonosítani kell az alapadatokat, miből származik
Ha új adatféleség kerül egy lentebbi üzleti objektumba lásd előbbi eljárást.
Az összes módosításos származtatást szintén azonosítani kell.
Alapelv inkább legyen több kisebb (horribile dictu diszjunkt) üzleti objektum, mint kevesebb (na pláne összefüggő/mellékhatásos) komplex
Az iteráció a konszolidált állapotig való eljutásban (top-down és bottom-up kombináltan):
- Veszünk egyetlen nagy blackbox-ot
- Daraboljuk a blackboxokat, és kölcsönhatásokat térképezünk fel (funkcionális klaszterek).
- Ha sikerül azonosítani egy kellően fontos, kellően kicsi, kellően egyszerű funkcionális klaszter, azt meg kell próbálni alulról felépíteni üzleti objektumokból (hierarchiát építve).
Előnyök:
- Igyekszik egymáshoz a lehető legközelebb hozni az egyértelműsítő IT valamint a "projekt-finanszírozó" üzleti személetet.
- Up-To-Date-ség
- Az üzleti objektumok hierarchiája mentén teszőleges lineárisan olvasható olvasmány kigenerálható, tetszőlegesen új kollégának
- Jól-kereshető tud lenni a dokumentum.
- A változásmenedzsmentjének dokumentálása könnyedén megoldható.
A feladat legnehezebb, legrázósabb része - nemkicsit megdöbbentő módon - az üzleti objetumok fizikai és üzleti elnevezése (de ez kereskedelmi szoftver használatánál is így lenne).
Szerintem..........
FELADAT: Adva van egy üzleti felhasználók számára totálisan black box Oracle adatbázis. Nem scope annak fejtegetése, hogy ez hogyan eshetett meg a XXI.századra. ;) Természetesen az üzleti felhasználók, szeretnék tudni mi van benne, sőt módosítási igényeik is vannak, sőt ráadásul - horribile dictu - gyorsan szeretnének módosulási eredményeket látni. Azaz dokuemntálni kéne visszamenőleg és minél használhatóbb módon előrefele. Van pénzük a projektre, mi legyen a javasolt technológia?
1.
Erre az egyik kézenfekvő megoldás gyári szoftver vásárlása, horribilis pénzekért végtelenül limitált funkcionalitással. Ilyen például Busines Objects Universum Designere. Aki ezirányban akarna továbbolvasni, annak más site javasolt, nem ez a blogposzt. ;) Magam részéről ezt a megoldást teljességgel elutasítom.
2.
Marad tehát valamiféle "custom" megoldás. Ami nekem hirtelenjében eszembejut az két lehetőség: egy minimális ám gyorsan implementálható brute force megoldás és egy maximális hiperintelligens. Mindkét megoldás ipari standardeket használna, de csak részben state-of-art termékekkel, részben egyedi fejlesztésűekkel.
Alapelv: elsőrendű prioritás, hogy minél inkább gombnyomásra automatikusan up-to-date legyen a dokumentáció.
(1) A minimális ám gyorsan implementálható brute force megoldás
Oracle adatszótárában megvannak a tárolt-eljárás és táblák függései. Feltehető, hogy egyéb Oracle objektumtípus nincs.
Tegyük fel, hogy elkészül egy alap kifehérítő dokumentáció valahogyan.
Bármilyen ("mérföldköves") fejlesztés elött és után csinálunk (text-alapú) snapshotot
- a struktúrákról.
- a függésekről.
Az érintett módosuló kódokat péládul SVN-be rámoljuk (programból)
SVN-diff programból való hívásának segítségével dokumentáljuk a változásokat, minden változástípusnál értelemszerűen.
Fontos látni, hogy nem-feltétlen csak az Oracle belső adatszótárára/dependenciáira lehetne csak támaszkodni: Külön (meta)sémába lehetne hozzáadott értékekkel kiegészíteni, egyedi custom-fejlesztés révén.
Fontos látni, hogy univerzális terméket nem így kell fejleszteni, viszont a megrendelői igények lokális-specifikus lefedését a legkönnyebb így támogatni.
Mindez relatíve egyszerű, gyors fejlesztésű, gombnyomásra aktualizálható, de ha én üzleti user lennék, bizony húznám a számat rá, hiszen erősen IT-alapú, nekem üzleti userként, üzleti alapú kéne nekem.
(2) A maximális hiperinteligens megoldás
Intelligens „master/meta data management”-es univerzum-építés, jó szoftver hiányában, custom-fejlesztéssel.
A fejlesztés végén, múlhatatlan üzleti igény esetén persze bevethető ilyesmi is, például ha rajzolgatni szeretne az ügyfél (aminek én sose láttam értelmét, a modern kor mennyiségi és komplexitási igényeit nézve).
Blackbox adatbázisunkban
- Vannak az alapadatok és a származtatott adatok.
- Minden adat alapadat, ami kívülről interface-n keresztül jön és nem módosul sose rendszeren belül.
- Minden más származtatott adat.
- Ha egy táblában mindkettő van, azt szét kell bombázni kétfelé (minimum logikai értelemben), az én értelmezésem szerint
El kell kezdeni üzleti objektumokat definiálni, amik egymásra épülnek (hierarchiába).
Akkor jó egy üzleti objektum, ha
- könnyű olvasni és egyértelműen értelmezni (az implementált logikát)
- a ráépülés során komoly hozzáadott érték képződik.
Az üzleti objektum tartalmaz
- Nevet (fizikai és üzleti)
- Kulcsokat, ddl-definiciókat.
- Logikát
- Szöveges leírást
- Data Profile-ingot (NULL, kategória-e, stb).
- Ki határozza meg a számosságot: csomó left join esetén nyilván a base tábla, amihez joinolunk.
- Stb. (mindez rendszerszervezési kérdés)
Ami egyedül fontos,hogy azonosítani kell, mi az ami programból tud jönni, és mi az ami manualitást igényel.
Az üzleti objektum üzleti logikája jellemzően SQL (+opcionálisan 3GL kód)
Az SQL-nek minél egyszerűbbnek kell lennie, de nem feltétlen minden határon túlmenően, csak a józan ész szerint (ez az például, amit a kereskedelmi szoftverek a belátható jövőben NEM fognak tudni univerzálisan támogatni)
- Lehet benne UNIO, de csak akkor ha garantáltan diszjunkt
- Lehet benne összetett logikai feltétel, de csak ha átlátható.
- Lehet benne több join is, de lehetőleg csak egyfélék.
- Meg kell különböztetni a törzsadatokat a tranzakciós adatoktól.
- Master-Detail join például nem lehet már (elvi alapokon se), azt szét kell szedni ketté.
- Lehet két- vagy többféleféle „átlagegyenleg”-típusú üzleti logika (pl.: egy termékfejlesztési és egy riskes), viszont különbséget kell tudni képezni új objektum bevezetésével (dekomponálás).
- Lehet többféle tranzakcióleválogatás, de mindegyiknek legyen értelme, neve.
- Nem baj, ha érkezik egy újabb „átlagegyenleg”-definició, de valami korábbira hasonlítania kell és különbséget kell tudni képezni hozzá.
- Garantálni a konszolidált állapothoz való konvergálást, szabályokkal, szabályrendszerrel
stb.
Az üzleti objektumnok jellemzően JOIN-okkal kapcsolódnak.
Ezek után egy új funkcionalitás úgy tudhat kinézni, hogy egy hierarchia közepén lévő üzleti objektumba jellemzően ÚJ attribútum képződik.
Aki eljárások ezt olvassák azokat ez nem szabad zavarja.
Tehát csak lefelé érdekes a hierarchia
Azonosítani kell az alapadatokat, miből származik
Ha új adatféleség kerül egy lentebbi üzleti objektumba lásd előbbi eljárást.
Az összes módosításos származtatást szintén azonosítani kell.
Alapelv inkább legyen több kisebb (horribile dictu diszjunkt) üzleti objektum, mint kevesebb (na pláne összefüggő/mellékhatásos) komplex
Az iteráció a konszolidált állapotig való eljutásban (top-down és bottom-up kombináltan):
- Veszünk egyetlen nagy blackbox-ot
- Daraboljuk a blackboxokat, és kölcsönhatásokat térképezünk fel (funkcionális klaszterek).
- Ha sikerül azonosítani egy kellően fontos, kellően kicsi, kellően egyszerű funkcionális klaszter, azt meg kell próbálni alulról felépíteni üzleti objektumokból (hierarchiát építve).
Előnyök:
- Igyekszik egymáshoz a lehető legközelebb hozni az egyértelműsítő IT valamint a "projekt-finanszírozó" üzleti személetet.
- Up-To-Date-ség
- Az üzleti objektumok hierarchiája mentén teszőleges lineárisan olvasható olvasmány kigenerálható, tetszőlegesen új kollégának
- Jól-kereshető tud lenni a dokumentum.
- A változásmenedzsmentjének dokumentálása könnyedén megoldható.
A feladat legnehezebb, legrázósabb része - nemkicsit megdöbbentő módon - az üzleti objetumok fizikai és üzleti elnevezése (de ez kereskedelmi szoftver használatánál is így lenne).
Szerintem..........
SQL-forgatás
.
FELADAT: Adva van egy forrásrendszer, amire töménytelen mennyiségű, különböző komplexitású (pl.: inline view-s) lekérdezéseket írtak eddig üzleti felhasználók. Menetközben elkészült egy adattárház és hozzá egy riporting adatpiac (aminek ez a forrásrendszer csak az egyik forrása) úgy, hogy a forrásrendszer és az adatpiac között VAN egyértelmű leképezés (séma, tábla és mező-szinten, de nyilván más nevekkel). Hogyan könnyítsük meg az üzleti felhasználók életét a riporting adatpiacra való átállásban?
LEHETŐSÉGEK (amik nekem eszembe jutnak):
I. LEHETŐSÉG: CÉLIRÁNYOS SQL-PARSE LIBRARY
(A) ANTLR
http://www.antlr.org/download.html
http://www.antlr3.org/grammar/list.html
Előnye:
- open source (free)
- van oracle nyelvtan hozzá (több is)
Hátránya:
- Kérdés mennyire követődnek le az Oracle SQL-verziók, mennyire megbízhatóan. Éles enterprise könyezetben én szívesebben alapoznék támogatott, aktuálisan követett megoldást.
(B) http://www.sqlparser.com/
Ez ugyan pénzes, de az enterprise verzió is csak 90.000 forint. Nem éppen kibírhatatlan, ha egy Oracle Total Recallt könnyedén ki tudnak csengetni.
Az Oracle-verzió csak 30.000 forint (de az IBM DB2 miatt érdemes az enterprise-ban gondolkodni.
Ez supportos, karbantartott, jó cucc, csak használni kell.
(C) Oracle-specifikus:
Előnye, hogy "ingyen" van, hátránya, hogy azért küzdeni kell vele. ;)
CREATE GLOBAL TEMPORARY TABLE plans AS
SELECT * FROM TABLE(dbms_xplan.display_cursor());
DECLARE
c NUMBER;
i VARCHAR2(30);
l NUMBER;
stmt VARCHAR2(4000);
BEGIN
DELETE FROM plans;
stmt:='SELECT z.* FROM z, skew1 WHERE z.z=skew1.fillblocks';
l:=LENGTH(stmt);
c:=dbms_sql.open_cursor();
dbms_sql.parse (c, stmt,dbms_sql.native);
SELECT DISTINCT sql_id
INTO i
FROM v$open_cursor
WHERE
sid IN
(
SELECT sid
FROM v$mystat
) AND
SUBSTR(sql_text,1,l)=SUBSTR(stmt,1,l)
;
INSERT INTO plans
SELECT *
FROM TABLE(dbms_xplan.display_cursor(i));
dbms_output.put_Line ('sql_id:'||i);
END;
(D) Egyéb idevágó okosságok, ha ennyi nem lenne elég :)
Parser for Oracle SQL
II.LEHETŐSÉG: QUERY BUILDER-ES FRONT-END
Ha nem akarunk parse-olgatni, és pláne, ha KEVÉS tábla van, akkor lehetne írni egy checkbox klikkelgető kicsi front-end alkalmazást á lá "SQL-Builder". Ez lehetne limitált vagy teljes funkcionalitású.
Kirakjuk front-endre az ÖSSZES táblát. Be lehet pipálni ki legyen a join-ban, ebből már azonnal kiesik egy működő sql. Persze a front-end alkalmazásunk az oszlop-megfeleltetésekkel is tisztában lehet könnyedén, így a szükséges érdemi felhasználói "where feltételrendszer" is bele konstruálható az output SQL-be. Order by meg könnyedén konstruálható.
Group by-having-es, uniós, hierarchikus, analitikus, etc összetett lekérdezéseket meg rakják össze a felhasználók a front-endből kinyert mozaik darabkákból (feltéve, hogy költségesebb ezt implementálni és jellemzően nem ezek fedik le a felhasználói igények perdöntő részét) .
Teljes funkcionalitás megcélzása esetén, itt is lehet külső "query builder" könyvtárat bevetni, például : Active Query Builder
Ennek a II.lehetőség komoly hátránya, hogy from scratch zöldmezősen kell az sql-eket létrehozni, nem meglévő sql-eket fordít át.
Ilyen alkalmazás szerintem helyes programozási környezete: Free Pascal/Lazarus, és nem lehet túl nagy meló.
Megjegyzés: én alapból nem szeretem a query buidereket, de ennél a topiknál muszáj volt említeni, a minél jobb teljeskörűség érdekében.
III.LEHETŐSÉG: KOPASZ STRING-CSERE, MANUÁLIS PARSE-SZAL
Limited manuális parse (pláne, ha egyszerűek az SQL-ek), stringcserével pl.: tábláknál: "SOURCE" -> "TARGET", esetleg némi case whennel megspékelve.
Tábla alias alapján select-listát módosítása, oszlop-megfeleltetés közbeiktatásával.
Kiegészítve a plusz konstans wherekkel.
Pl.: WHERE DATE '2013-09-30' BETWEEN valid_from AND valid_to
Én ezt a metódust támogatnám legkevésbé, nem véletlen, hogy a végére hagytam..Ez csak erősen limitált tudna lenni, számomra értelmetlen erőforráspocsékolás, kétes várható eredménnyel.A komolyabb hozzáadott értékű korábbi megoldások, alig kerülnek többe.
KONKLÚZIÓ (ÉN SORRENDEM)
(1) www.sqlparser.com
(2) antlr
(3) dbms sql-parse
(4) korlátozott front-end, egyszerű zöldmezős sql-konstruálásra (join-where-ig csak)
(5) teljes active query builderes megoldás
(6) limited manuális SQL-parse
FELADAT: Adva van egy forrásrendszer, amire töménytelen mennyiségű, különböző komplexitású (pl.: inline view-s) lekérdezéseket írtak eddig üzleti felhasználók. Menetközben elkészült egy adattárház és hozzá egy riporting adatpiac (aminek ez a forrásrendszer csak az egyik forrása) úgy, hogy a forrásrendszer és az adatpiac között VAN egyértelmű leképezés (séma, tábla és mező-szinten, de nyilván más nevekkel). Hogyan könnyítsük meg az üzleti felhasználók életét a riporting adatpiacra való átállásban?
LEHETŐSÉGEK (amik nekem eszembe jutnak):
I. LEHETŐSÉG: CÉLIRÁNYOS SQL-PARSE LIBRARY
(A) ANTLR
http://www.antlr.org/download.html
http://www.antlr3.org/grammar/list.html
Előnye:
- open source (free)
- van oracle nyelvtan hozzá (több is)
Hátránya:
- Kérdés mennyire követődnek le az Oracle SQL-verziók, mennyire megbízhatóan. Éles enterprise könyezetben én szívesebben alapoznék támogatott, aktuálisan követett megoldást.
(B) http://www.sqlparser.com/
Ez ugyan pénzes, de az enterprise verzió is csak 90.000 forint. Nem éppen kibírhatatlan, ha egy Oracle Total Recallt könnyedén ki tudnak csengetni.
Az Oracle-verzió csak 30.000 forint (de az IBM DB2 miatt érdemes az enterprise-ban gondolkodni.
Ez supportos, karbantartott, jó cucc, csak használni kell.
(C) Oracle-specifikus:
Előnye, hogy "ingyen" van, hátránya, hogy azért küzdeni kell vele. ;)
CREATE GLOBAL TEMPORARY TABLE plans AS
SELECT * FROM TABLE(dbms_xplan.display_cursor());
DECLARE
c NUMBER;
i VARCHAR2(30);
l NUMBER;
stmt VARCHAR2(4000);
BEGIN
DELETE FROM plans;
stmt:='SELECT z.* FROM z, skew1 WHERE z.z=skew1.fillblocks';
l:=LENGTH(stmt);
c:=dbms_sql.open_cursor();
dbms_sql.parse (c, stmt,dbms_sql.native);
SELECT DISTINCT sql_id
INTO i
FROM v$open_cursor
WHERE
sid IN
(
SELECT sid
FROM v$mystat
) AND
SUBSTR(sql_text,1,l)=SUBSTR(stmt,1,l)
;
INSERT INTO plans
SELECT *
FROM TABLE(dbms_xplan.display_cursor(i));
dbms_output.put_Line ('sql_id:'||i);
END;
(D) Egyéb idevágó okosságok, ha ennyi nem lenne elég :)
Parser for Oracle SQL
II.LEHETŐSÉG: QUERY BUILDER-ES FRONT-END
Ha nem akarunk parse-olgatni, és pláne, ha KEVÉS tábla van, akkor lehetne írni egy checkbox klikkelgető kicsi front-end alkalmazást á lá "SQL-Builder". Ez lehetne limitált vagy teljes funkcionalitású.
Kirakjuk front-endre az ÖSSZES táblát. Be lehet pipálni ki legyen a join-ban, ebből már azonnal kiesik egy működő sql. Persze a front-end alkalmazásunk az oszlop-megfeleltetésekkel is tisztában lehet könnyedén, így a szükséges érdemi felhasználói "where feltételrendszer" is bele konstruálható az output SQL-be. Order by meg könnyedén konstruálható.
Group by-having-es, uniós, hierarchikus, analitikus, etc összetett lekérdezéseket meg rakják össze a felhasználók a front-endből kinyert mozaik darabkákból (feltéve, hogy költségesebb ezt implementálni és jellemzően nem ezek fedik le a felhasználói igények perdöntő részét) .
Teljes funkcionalitás megcélzása esetén, itt is lehet külső "query builder" könyvtárat bevetni, például : Active Query Builder
Ennek a II.lehetőség komoly hátránya, hogy from scratch zöldmezősen kell az sql-eket létrehozni, nem meglévő sql-eket fordít át.
Ilyen alkalmazás szerintem helyes programozási környezete: Free Pascal/Lazarus, és nem lehet túl nagy meló.
Megjegyzés: én alapból nem szeretem a query buidereket, de ennél a topiknál muszáj volt említeni, a minél jobb teljeskörűség érdekében.
III.LEHETŐSÉG: KOPASZ STRING-CSERE, MANUÁLIS PARSE-SZAL
Limited manuális parse (pláne, ha egyszerűek az SQL-ek), stringcserével pl.: tábláknál: "SOURCE" -> "TARGET", esetleg némi case whennel megspékelve.
Tábla alias alapján select-listát módosítása, oszlop-megfeleltetés közbeiktatásával.
Kiegészítve a plusz konstans wherekkel.
Pl.: WHERE DATE '2013-09-30' BETWEEN valid_from AND valid_to
Én ezt a metódust támogatnám legkevésbé, nem véletlen, hogy a végére hagytam..Ez csak erősen limitált tudna lenni, számomra értelmetlen erőforráspocsékolás, kétes várható eredménnyel.A komolyabb hozzáadott értékű korábbi megoldások, alig kerülnek többe.
KONKLÚZIÓ (ÉN SORRENDEM)
(1) www.sqlparser.com
(2) antlr
(3) dbms sql-parse
(4) korlátozott front-end, egyszerű zöldmezős sql-konstruálásra (join-where-ig csak)
(5) teljes active query builderes megoldás
(6) limited manuális SQL-parse
Egy ETL-es komment margójára (Budapest BI Fórum)
.
Budapest BI Fórum - első nap ("Open Analytics")
A blogoszféra ezen eldugott sarkában, mindig különleges érzés (érdemi) hozzászólással találkozni, köszönet érte. :)
A téma meg annyira nagy és fontos, hogy azt gondolom megérdemel külön blogposztot. Nehezítő körülmény számomra, hogy mostanság teljesen más témákban mozgom, így extra kihívás összeszedettnek lennem, de megpróbálom.
Jó volt-e Sidló Csaba előadása?
Mielőtt az érdemi, lényegi mondandóra térünk, álljunk meg itt is egy percre. Mitől jó egy előadás (számomra)? A Budapest BI Fórum második napjáról szóló - sötét tónusú - blogposztomban bőségesen kitértem erre is (igaz nem fókuszáltan). De ha már explicit felmerült most, akkor szedjük pontokba is:
- A legfontosabb ismérv, hogy az előadás végén szomorúan konstatálljam, hogy vége, illetve fogalmazódjék meg bennem, hogy egy szinttel mélyebbre menve, tartson mégegyszer annyi ideig. :)
- Foglalkoztassa a téma a szakmai közvéleményt, ha lehet már az előadás elött.
- Ezzel szemben az előadás konkrét mondandója meg legyen minél újszerűbb, akár csak kontextusában.
- Állítson valamit az előadás, de olyat, hogy lehessen róla vélemény - horribile dictu ellenvélemény - a közönség soraiban. Ez nekem kardinális kérdés, itt a blogon is. Óriási (parallel létező) információtömeg vesz körül minket, elolvasni, feldolgozni sincs időnk rá. Viszont élni, valamilyen ösvényen haladni azt mindannyiunknak kell. Ha új információ érkezik azt meg kell vizsgálni, azt be kell építeni vagy éppenséggel el kell vetni, azaz valamit csinálni kell vele. Ezért a vélemények számomra nem l'art pour l'art párhuzamosan léteznek bele a világba, hanem kőkemény versenyt vívnak egymással, ahol a jobb vélemény előkelőbb helyezést ér el. Ez maga után vonja, hogy a véleményt vállalni kell, még ha egy későbbi ellenvélemény felül is írja. Ha nincs vélemény, akkor nincs ugyan "bukás" se, de nézetem szerint, némi extrapolációval, kár volt a témával foglalkozni.
- Legyen nagyon nagy személyes varázsa az előadónak. Mivel kevés kiemelkedően jó előadót ismerek, hajlamos vagyok azt feltételezni, hogy ez valami istenadta - tanulhatatlan - adottságból fakadhat. A konferencián az én fogalmaim szerint Arató Bence és Földi Tamás ilyen kvalitású előadó. Vagy éppen Sidló Csaba munkatársa ifj.Benczúr András, aki sajnos nem volt itt.
- Végül legyen szellemes, humorral fűszerezett. Ez olyan mint a só a bográcsgúlyáshoz. El lehet hagyni, de érdemes? ;)
Számomra Csaba előadása:
- Fontos "hottopic" témát vesézett, fogalmazódtak meg kérdések is a közönség soraiban. ;)
- Újszerű mondandója volt az előadásnak
- Sajnáltam az előadás végén, hogy vége volt, mentem volna tovább a mélyebb részletek felé.
- Őszinte véleményt formált, meg indokolt is (amennyire ideje engedte), kevés ilyen előadó volt a konferencián.
- Emlékeim szerint némi poén is volt. :)
Rosszak a kereskedelmi tool-ok
Ez bizony az én általánosító megállapításom is. Több összetevője van ennek:
- Maga a műfaj kelt egy kvázi kivédhetetlen hátrányt, nevezetesen, hogy úgy generál komoly overheadet egy cég életében (licence, fejlesztés, üzemeltetés), hogy ezenközben a hozzáadott érték roppant kicsi.
- Sokszor rossz elvek mentén fejlesztették őket (például adatbázis repository alapokra)
- Az ETL-eszközöknek sok-sok évük volt, hogy fejlődjenek, de valamiért megrekedtek egy nagyon alacsony szinten. Tudomásom szerint szakmai konszenzus van abban, hogy minden ETL eszköznek van (védhetetlen) hülyesége.
- Az ETL-eszközökhöz órási - számomra visszataszító - marketing tartozott mindig is, ami horibilissé tette alkalmazásuk költségeit.
- Az ember nehezen tudja elképzelni, hogy ne lehessen szerethető ETL-eszközt írni. Az hogy jó adatmodellező szoftvert nagyon nehéz írni, azt el tudom fogadni a magam részéről, de egy ETL-eszköz fejlesztése azért mégse egy "rocket science".
- És akkor egy szót sem szóltam a konkrétumokról. ;)
* OWB-vel 2.1-es korában találkoztm először. A generált kódja hibás volt (le sem fordult). Milyen "élmény" volt utána kézzel ráhackelni. Arról az inkorrekt Oracle-s hozzáállásról nem beszélve, hogy a vásárlóival fizetette meg az OWB fejlesztési költségeit az Oracle. Kiadott egy használhatatlan ipari hulladékot pre alpha állapotban és a fizető vásárlók idegrendszerén zongorázva javította éveken át. Majd az ODI-akvizició után halálra is ítéli.
* ODI. Nem lenne őszinte/hiteles véleményt formálnom róla, mert éles projektben nem találkoztam vele (hiába tűnt első ránézésre szimpinek). Aki OWB-zett kollégám, az mind utálta (teljesen más logikája miatt). A horribilis árképzése miatt viszont nálam végérvényesen leírta magát.
* Business Objects Data Services, a híres nevezetes BODS. Egy komplett ipari hulladék, nullához közeli fórumos élettel, horribilis áron. Életem egyik legrettenetesebb fejezete a vele való éles projekt.
* IBM Datastage. Első ránézésre egy szimpi ezsköznek tűnik. Csak ne kelljen vele éles projektet csinálni. Zavaros, hiányos, logikátlan.
* A témában a legígéretesebbek még az open source eszközök. Igen pont az open source eszközök. pl.: Talend. Na nem mintha annak memóriaigényén, bugmentesítésén ne lenne például faragnivaló.
Majd ők megmutatják
Csaba elmondása szerint ők csak dolgozni akartak eredendően, eszükben nem volt újat írni. Meg is vizsgáltak (kimértek) néhány eszközt, megpróbáltak többükkel eredményt elérni, de számukra fontos dolgokban korlátokba ütköztek. Ennyi rálátásom még nekem is van a Sztaki-tevékenységekre (korábbi évekből), hogy ezt kívülről érkezve validáljam magam is.
Mindazonáltal a "majd ők megmutatják"-ban sem látok kivetnivalót. Hiszen a végtermék hitelesít úgyis.
Több év alatt írtak egy egygépes(!), "jól skálázódó" eszközt
Ezt sajnos nem tudom tárgyilagosan elemezni, érdemi információk hiányában.
Nem tudom miért írod az "egygépes"-t. Legalább csak a mérések párhuzamos környezetet igényeltek. Vagy te résztvettél benne, és konkrét infóid vannak?
A mi adóforintjainkból
Nem szeretnék politizálni pláne ezen a blogon nem. De ezzel a felütéssel ugyanúgy nem értek egyet, mint a "lélegeztetőgép-valutával".
Aztán én biztos nem érzem magamat hivatott személynek arra, hogy eldöntsem, hogy mely témákkal érdemes vagy nem érdemes mennyire foglalkozni, Még a magam számára sem tudom eldönteni, hogy például egy SVM-paraméterezésbe, mennyi időt lenne ildomos feccölni. :)
Sztaki meg ráadásul nemcsak adóforintokból él, hanem kőkemény piaci versenyző, ráadásul tudtommal meglehetősen "vastag ceruzával". Magyarán e nélkül éhen halnának.
Ha meg csak a szakmát nézzük, ifj. Benczúr András meg Lukács András személye számomra igazi garancia a minőségi munkára, megújulásra. Tudnék ellenpéldát mondani, az egyetemi szférából.
2013-mat írunk, nem baj
Én egy jó ETL-eszköznek 2015-ben is tudnék örülni. ;)
Open source-á tették, mert manapság az a trendi..csak minek...
Ezt az ellenérzést viszont sehová nem tudom tenni. Kicsit olyan nekem (extrapolációval), mint "adakozott az árváknak a szemét".
Mi baj van avval, hogy open source-szá tették. Örüljünk neki, ez semmit nem von le az élvezeti értékéből, sőt. Ha nem lenne Knime/RapidMiner/Weka, most is tízmilliókért lehetne csak adatbányászkodni.
Külön érdemes összevetni a "mi adóforintjaink"-ellenérzéssel. Pont hogy visszaosztottak valamit a közösség felé általa. Nem pedig "sales"-osztályt hoztak létre, gigantikus overheadet generálva. Lásd még idevágóan, hogy a tudósok által írt cikkek csak nagy nehezen lassan férhetők hozzá szabadon az őket támogató közösség számára.
Budapest BI Fórum - első nap ("Open Analytics")
A blogoszféra ezen eldugott sarkában, mindig különleges érzés (érdemi) hozzászólással találkozni, köszönet érte. :)
A téma meg annyira nagy és fontos, hogy azt gondolom megérdemel külön blogposztot. Nehezítő körülmény számomra, hogy mostanság teljesen más témákban mozgom, így extra kihívás összeszedettnek lennem, de megpróbálom.
Szerinted jó volt a Sidló előadása a Sztakiból? Persze, rosszak a kereskedelmi ETL tool-ok, majd ők megmutatják. Több év alatt írtak egy egygépes(!), "jól skálázódó" eszközt, (többek között a mi adóforintjainkból). 2013-mat írunk, nem baj. Open source-á tették, mert manapság az a trendi..csak minek...
Jó volt-e Sidló Csaba előadása?
Mielőtt az érdemi, lényegi mondandóra térünk, álljunk meg itt is egy percre. Mitől jó egy előadás (számomra)? A Budapest BI Fórum második napjáról szóló - sötét tónusú - blogposztomban bőségesen kitértem erre is (igaz nem fókuszáltan). De ha már explicit felmerült most, akkor szedjük pontokba is:
- A legfontosabb ismérv, hogy az előadás végén szomorúan konstatálljam, hogy vége, illetve fogalmazódjék meg bennem, hogy egy szinttel mélyebbre menve, tartson mégegyszer annyi ideig. :)
- Foglalkoztassa a téma a szakmai közvéleményt, ha lehet már az előadás elött.
- Ezzel szemben az előadás konkrét mondandója meg legyen minél újszerűbb, akár csak kontextusában.
- Állítson valamit az előadás, de olyat, hogy lehessen róla vélemény - horribile dictu ellenvélemény - a közönség soraiban. Ez nekem kardinális kérdés, itt a blogon is. Óriási (parallel létező) információtömeg vesz körül minket, elolvasni, feldolgozni sincs időnk rá. Viszont élni, valamilyen ösvényen haladni azt mindannyiunknak kell. Ha új információ érkezik azt meg kell vizsgálni, azt be kell építeni vagy éppenséggel el kell vetni, azaz valamit csinálni kell vele. Ezért a vélemények számomra nem l'art pour l'art párhuzamosan léteznek bele a világba, hanem kőkemény versenyt vívnak egymással, ahol a jobb vélemény előkelőbb helyezést ér el. Ez maga után vonja, hogy a véleményt vállalni kell, még ha egy későbbi ellenvélemény felül is írja. Ha nincs vélemény, akkor nincs ugyan "bukás" se, de nézetem szerint, némi extrapolációval, kár volt a témával foglalkozni.
- Legyen nagyon nagy személyes varázsa az előadónak. Mivel kevés kiemelkedően jó előadót ismerek, hajlamos vagyok azt feltételezni, hogy ez valami istenadta - tanulhatatlan - adottságból fakadhat. A konferencián az én fogalmaim szerint Arató Bence és Földi Tamás ilyen kvalitású előadó. Vagy éppen Sidló Csaba munkatársa ifj.Benczúr András, aki sajnos nem volt itt.
- Végül legyen szellemes, humorral fűszerezett. Ez olyan mint a só a bográcsgúlyáshoz. El lehet hagyni, de érdemes? ;)
Számomra Csaba előadása:
- Fontos "hottopic" témát vesézett, fogalmazódtak meg kérdések is a közönség soraiban. ;)
- Újszerű mondandója volt az előadásnak
- Sajnáltam az előadás végén, hogy vége volt, mentem volna tovább a mélyebb részletek felé.
- Őszinte véleményt formált, meg indokolt is (amennyire ideje engedte), kevés ilyen előadó volt a konferencián.
- Emlékeim szerint némi poén is volt. :)
Rosszak a kereskedelmi tool-ok
Ez bizony az én általánosító megállapításom is. Több összetevője van ennek:
- Maga a műfaj kelt egy kvázi kivédhetetlen hátrányt, nevezetesen, hogy úgy generál komoly overheadet egy cég életében (licence, fejlesztés, üzemeltetés), hogy ezenközben a hozzáadott érték roppant kicsi.
- Sokszor rossz elvek mentén fejlesztették őket (például adatbázis repository alapokra)
- Az ETL-eszközöknek sok-sok évük volt, hogy fejlődjenek, de valamiért megrekedtek egy nagyon alacsony szinten. Tudomásom szerint szakmai konszenzus van abban, hogy minden ETL eszköznek van (védhetetlen) hülyesége.
- Az ETL-eszközökhöz órási - számomra visszataszító - marketing tartozott mindig is, ami horibilissé tette alkalmazásuk költségeit.
- Az ember nehezen tudja elképzelni, hogy ne lehessen szerethető ETL-eszközt írni. Az hogy jó adatmodellező szoftvert nagyon nehéz írni, azt el tudom fogadni a magam részéről, de egy ETL-eszköz fejlesztése azért mégse egy "rocket science".
- És akkor egy szót sem szóltam a konkrétumokról. ;)
* OWB-vel 2.1-es korában találkoztm először. A generált kódja hibás volt (le sem fordult). Milyen "élmény" volt utána kézzel ráhackelni. Arról az inkorrekt Oracle-s hozzáállásról nem beszélve, hogy a vásárlóival fizetette meg az OWB fejlesztési költségeit az Oracle. Kiadott egy használhatatlan ipari hulladékot pre alpha állapotban és a fizető vásárlók idegrendszerén zongorázva javította éveken át. Majd az ODI-akvizició után halálra is ítéli.
* ODI. Nem lenne őszinte/hiteles véleményt formálnom róla, mert éles projektben nem találkoztam vele (hiába tűnt első ránézésre szimpinek). Aki OWB-zett kollégám, az mind utálta (teljesen más logikája miatt). A horribilis árképzése miatt viszont nálam végérvényesen leírta magát.
* Business Objects Data Services, a híres nevezetes BODS. Egy komplett ipari hulladék, nullához közeli fórumos élettel, horribilis áron. Életem egyik legrettenetesebb fejezete a vele való éles projekt.
* IBM Datastage. Első ránézésre egy szimpi ezsköznek tűnik. Csak ne kelljen vele éles projektet csinálni. Zavaros, hiányos, logikátlan.
* A témában a legígéretesebbek még az open source eszközök. Igen pont az open source eszközök. pl.: Talend. Na nem mintha annak memóriaigényén, bugmentesítésén ne lenne például faragnivaló.
Majd ők megmutatják
Csaba elmondása szerint ők csak dolgozni akartak eredendően, eszükben nem volt újat írni. Meg is vizsgáltak (kimértek) néhány eszközt, megpróbáltak többükkel eredményt elérni, de számukra fontos dolgokban korlátokba ütköztek. Ennyi rálátásom még nekem is van a Sztaki-tevékenységekre (korábbi évekből), hogy ezt kívülről érkezve validáljam magam is.
Mindazonáltal a "majd ők megmutatják"-ban sem látok kivetnivalót. Hiszen a végtermék hitelesít úgyis.
Több év alatt írtak egy egygépes(!), "jól skálázódó" eszközt
Ezt sajnos nem tudom tárgyilagosan elemezni, érdemi információk hiányában.
Nem tudom miért írod az "egygépes"-t. Legalább csak a mérések párhuzamos környezetet igényeltek. Vagy te résztvettél benne, és konkrét infóid vannak?
A mi adóforintjainkból
Nem szeretnék politizálni pláne ezen a blogon nem. De ezzel a felütéssel ugyanúgy nem értek egyet, mint a "lélegeztetőgép-valutával".
Aztán én biztos nem érzem magamat hivatott személynek arra, hogy eldöntsem, hogy mely témákkal érdemes vagy nem érdemes mennyire foglalkozni, Még a magam számára sem tudom eldönteni, hogy például egy SVM-paraméterezésbe, mennyi időt lenne ildomos feccölni. :)
Sztaki meg ráadásul nemcsak adóforintokból él, hanem kőkemény piaci versenyző, ráadásul tudtommal meglehetősen "vastag ceruzával". Magyarán e nélkül éhen halnának.
Ha meg csak a szakmát nézzük, ifj. Benczúr András meg Lukács András személye számomra igazi garancia a minőségi munkára, megújulásra. Tudnék ellenpéldát mondani, az egyetemi szférából.
2013-mat írunk, nem baj
Én egy jó ETL-eszköznek 2015-ben is tudnék örülni. ;)
Open source-á tették, mert manapság az a trendi..csak minek...
Ezt az ellenérzést viszont sehová nem tudom tenni. Kicsit olyan nekem (extrapolációval), mint "adakozott az árváknak a szemét".
Mi baj van avval, hogy open source-szá tették. Örüljünk neki, ez semmit nem von le az élvezeti értékéből, sőt. Ha nem lenne Knime/RapidMiner/Weka, most is tízmilliókért lehetne csak adatbányászkodni.
Külön érdemes összevetni a "mi adóforintjaink"-ellenérzéssel. Pont hogy visszaosztottak valamit a közösség felé általa. Nem pedig "sales"-osztályt hoztak létre, gigantikus overheadet generálva. Lásd még idevágóan, hogy a tudósok által írt cikkek csak nagy nehezen lassan férhetők hozzá szabadon az őket támogató közösség számára.
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. ;)
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. ;)
Esetem egy éles MapReduce projekttel
.
Ha életemben valaha is volt értelme annak a mondásnak, hogy "betévedtem, mint Pilátus a krédóba", az a minapokban esett meg velem. :)
A munkahelyem jelmondata, hogy "lehetetetlent is megcsináljuk, az elérhető legjobb piaci áron".
Na ez személyes életemben úgy csapódott le, hogy megnyertem egy angol nyelvű szövegbányászati (méretesebb) projekt projekttagságát (szerencsére immáron már múltidőben), amiről némi ügyféloldali agilis kapkodás után kiderült, hogy mindent kell csinálni, csak éppen szövegbányászatot nem, mert ahhoz tilos hozzányúlni, fekete dobozként funkcionál (hiába, rossz, többtíz gigabyte nagyságrendben helypazarló, brutális többnapos futási idejű, nem szabványos custom hackelés az egész).
Cserébe amit kellett csinálni, ott minden, de tényleg minden vadonatúj volt számomra, nulla felkészülés idővel, hatalmas időnyomással. Még az iroda is (bővülés miatti átépítés),meg a projektteam is.
- Éles map-reduce programozás. Hiába írtam már korábban (demo)Map Reduce kódot, itt a blogomon is korábban említett "Data Science" kurzus keretében: az életben és élesben azért "kicsit" más a történet. ;)
Ha életemben valaha is volt értelme annak a mondásnak, hogy "betévedtem, mint Pilátus a krédóba", az a minapokban esett meg velem. :)
A munkahelyem jelmondata, hogy "lehetetetlent is megcsináljuk, az elérhető legjobb piaci áron".
Na ez személyes életemben úgy csapódott le, hogy megnyertem egy angol nyelvű szövegbányászati (méretesebb) projekt projekttagságát (szerencsére immáron már múltidőben), amiről némi ügyféloldali agilis kapkodás után kiderült, hogy mindent kell csinálni, csak éppen szövegbányászatot nem, mert ahhoz tilos hozzányúlni, fekete dobozként funkcionál (hiába, rossz, többtíz gigabyte nagyságrendben helypazarló, brutális többnapos futási idejű, nem szabványos custom hackelés az egész).
Cserébe amit kellett csinálni, ott minden, de tényleg minden vadonatúj volt számomra, nulla felkészülés idővel, hatalmas időnyomással. Még az iroda is (bővülés miatti átépítés),meg a projektteam is.
- Git. Sose volt dolgom vele eddig. Eddig például egy Subversionbe könnyebb volt életet lehelni, meg könnyebb is volt a munka vele, kétség nem férhet hozzá. De el kell ismerni, a Gitnek is megvan a maga létjogosultsága, mégha a szívás most perpillanat több is volt vele, mint megérte. ;)
- Olyan statisztikai modellekről, amik arcus sinust
használnak, még csak hallani sem hallottam korábban. Bevallom lestem, mint Rozi a moziban, és a tátott szájam sehogy sem tudott becsukodni, mert a reverse engine-je a dolog értelmének túl nagy kihívás volt számomra. ;) Az biztos, hogy statisztika témában is látnivalóan van fejlődési potenciál, személyes perspektívámat illetően. ;)
- MsSql 2012. 6-700 MB vastag kliense kevéssel marad el az Oracle mögött, méretben legalábbis. ;) Elég jó a a kappott felület, de lenne még mit hegeszteni rajta. ;)
- Talend (opens source ETL), ráadásul v5.3 enterprise verzióval, aminek már van komolyabb MapReduce támogatása
- Datastax Cassandra (értelmezésemben egy ipari hulladék NoSql adatbáziskezelő). Félreértés ne essék, amire kitalálták jó, csak ne kelljen benne értelmes táblát létrehozni, mert összezagyválja a mezősorrendet, amit nem hagy sehogy se befolyásolni a user által. Nemkicsit hajmaresztő ez nekem a XXI.században.
- Teammunkás, Netbeans-es Java-fejlesztés. Nagyon kellemes eszköz ez a Netbeans, csak a legjobbakat tudom mondani róla. Egy élmény benne a Java-fejlesztés.
- Időnyomásos agilis módszertan (sose csináltam korábban,
abban látatlanban biztos voltam, ultrabrutál kegyetlen nagy marhaság tud lenni, ha rosszul csinálják). Ráadásul - ügyfél által megkövetelten - a vonatkozó manifesztum értelmében nulla projektdokumentálással, 100%-os szóbeli kommunikációval. Én értem, hogy mindent az ügyfélért, de, hogy ezt nem tudtam egészségesnek látni, az is biztos.
- Hive (fékezett habzású SQL-származék). Eléggé funkciógazdag, szépen dokumentált is, Java-ban könnyedén lehet UDF-et (=User-Defined Function) írni. De a performanciája az finoman szólva is hagy maga után kívánnivalót. Maradjunk abban nem Oracle-ekvivalens. ;) Nem véletlen, hogy a Pivotal One nekifeküdt a témának, és Hawq néven fejleszt egy jóval gyorsabb verziót.
Ennek a projektnek köszönhetem az SqlDbx-re való rácsodálkozásomat.
Ez egy pici, C-ben írt, single exe, SQL Front-Endre.
Imádnivalóan gyors, használható.
Pont mint a Tableau, aszimptótikusan nullához kovergáló overheadet rak az SQL-végrehajtásra.
Egy másik szimpi tool - AQT (=Advanced Query Tool) - nagyságrendileg 10x lassabb végrehajtási/megjelenítési időket produkál.
Döbbenetesen stabil a működése, például egy Squirel+Vectorwise kombóhoz képest.
Minden ODBC SQL-adatforrást meg tud hajtani, a standard adatbázisokon felül, így Hive-ot, Cassandrát, Vectorwise-t.
Personal Edition-je ingyenes, ráadásul.
Erősen ajánlott eszköz, nézetem szerint.
Az mindenesetre szimpatikus volt, hogy brute force Map Reduce mindig működőképes (0 MAP-fázis, 100% Reduce-fázis). Nyilván minél több minden tud MAP-be kerülni,annál jobb lesz a performancia.
A másik fontos észrevétel: nem szabad beeröltetni mindent egyetlen MapReduce-ba. Kellhet particionálni a problémateret.
- Kézműves módszerekkel optimalizált SQL2MapReduce "konverzió":
A Hive-os SQL-ek, mint említettem egyrészt lassúak voltak, másrészt üzleti igény volt, hogy csak prototípus-készítésre (kommunikációra) volt használható, éles production környezetben 100%-ban ignorálni kellett. Ez magával rántotta azt a feladatot, hogy sql2mapreduce konverziót kellett csinálni.
Na ettől a konverziótól eléggé megrémültem, amikor először szembesültem vele, de aztán nagyon megszerettem. De csak teoretikus alapon.
Na ezt megmagyarázom. :)
Van egy szenzációs, friss (2012-es) szakkönyv:
Ez a könyv egyrészt nagyszerűen érzékelteti, hogy micsoda erő van a Map Reduce-ban, nem véletlen a robbanásszerű terjedése, másrészt sokmindenre kiterjedően ad recepteket, mozaikockákat, amikből építkezni lehet (sajnos csak elvben). További adalék,hogy hihetetlen nagy optimalizálási tartalék van a témában.
Eddig a lelkesedésem. :(
A gond az, hogy a HDFS-olvasás, kegyetlen lassú, brutálisan erőforrásigényes művelet. Nem is értem miért, hiszen semmi nem indokolja. Hawq-nak lesz lehetősége megtalálni a piaci rést ;)
Ez a tény egészen egyszerűen kinyírja, hogy design patternek szerint építőkockákból építkezzünk, Mivel minimalizálni kell a HDFS-olvasást, így übtre vonódnak össze mapreduce kódok. Amik egyre áttekinthetetlenebbek, kevésbé módosíthatók lesznek, miközben bármikor jöhet üzleti igény, ami miatt át kell szabni a Map Reduce-olást.
A komplexitás exponenciálisan nő, egyetlen szempont/KPI (performancia) tragikusan alacsony értéke miatt. Tiszta deja vu érzés, mintha optimalizált befaragott assembly programot akarnnánk lépten-nyomon team-munkában módosítgatni, majd újraoptimalizálni.
Ne haragudjon meg rám a világ, de ez nekem nagyon nem tetszik. Amikor olyan programozási nyelvcsodák vannak, mint Ruby vagy Scala, ne menjünk már vissza 20+ évet, hogy ki tud olvashatatlanabb kódot írni versenyekbe. ne menjünk vissza már a programozás Proterozoikum korába. ;)
Breaking News: Kijött a Tableau v8.1
.
Kijött a Tableau v8.1 :)
Letölthető a doksi is, és egy újabb hiányosság pipálódhat ki. Kisebb lett 866 oldal, 1.000 oldal helyett (redundanciák remélhetőleg kevesebben vannak), illetve szervezettebb, és olvashatóbb lett. Az R integration-t viszont first look-ra nem találtam. :(
Ígéret szerint van már full 64-bit. fel is raktam. 420 MB a tárfogalalása (v8.0-nak csak 300 MB volt). Kulcsot nem kér pluszba, de regisztrálni kell.
Ígéret szerint van benne R Integration.
Íme alul a gyönyörűségesen szépségesen szép képek
1.K-Means
2-3. Outlier-analízis.
Na innentől klasszikus értelmet nyer a Visual Data Mining És meglehet a Datameer-típusú versenytásaknak is fel van adva ezáltal a lecke.
;)
.
Kijött a Tableau v8.1 :)
Letölthető a doksi is, és egy újabb hiányosság pipálódhat ki. Kisebb lett 866 oldal, 1.000 oldal helyett (redundanciák remélhetőleg kevesebben vannak), illetve szervezettebb, és olvashatóbb lett. Az R integration-t viszont first look-ra nem találtam. :(
Ígéret szerint van már full 64-bit. fel is raktam. 420 MB a tárfogalalása (v8.0-nak csak 300 MB volt). Kulcsot nem kér pluszba, de regisztrálni kell.
Ígéret szerint van benne R Integration.
Íme alul a gyönyörűségesen szépségesen szép képek
1.K-Means
2-3. Outlier-analízis.
Na innentől klasszikus értelmet nyer a Visual Data Mining És meglehet a Datameer-típusú versenytásaknak is fel van adva ezáltal a lecke.
;)
.
Feliratkozás:
Bejegyzések (Atom)
Bejegyzések
