2014. január 19., vasárnap
Coursera: Machine Learning course - DONE :)
Ha félév halasztása után is, de csak sikerült elvégeznem a tárgybeli második (utolsó?) - időtartamát tekintve 10 hetes - Machine Learning-es Coursera-s kurzusumat, a tavaly nyári Data Science kurzus után. Elvben egyben akartam megcsinálni mindkettőt, de aztán a munka bedarált, esélyem sem volt rá végül. Most viszont végre sikerült: munka mellett, ráadásul észrevétlenül: még a kollégáim, főnökeim sem tudtak róla.
Hogy miért volt fontos számomra a kurzus? Van pár ok:
* Az egy dolog, hogy én szeretem az adatbányászatot, és az meg egy másik, hogy ezt elhiszi-e valaki nekem, egyáltalán azt, hogy ez nemcsak plátói - távolról érzett - (szakmai) szerelem ez. :) Nyilván ahogy házasságkötés nélkül is lehetséges igazi tartalmas párkapcsolat, nem a papír adja a garanciát hozzá, mégis valamilyen (tőlem) független kritérium-rendszer szerint teljesíteni szerettem volna valamit, a - mondjuk most így - l'art pour l'art érdeklődés felett.
* Ne felejtsük el, mivel lassan őskövületként 50 éves elmúltam, amikor én egyetemre jártam (ELTE programtervező matematika szakra), akkor nemhogy nem tanították (szisztematikusan) az adatbányászatot, de még a fogalom sem volt ismert itthon. Megboldogult nagyszerű Nemetz Tibor professzor úgy mesélt nekem tananyagon kívül a k-NN szépségeiről, hogy még véletlenül sem ejtett ki még csak hasonló fogalmat sem. Mindez maga után vonta, hogy (1) voltak hiányosságaim a témában, kvázi csak azok voltak (2) a lyukakat érdemes lenne valahogy szisztematikusan betömni.
Mindazonáltal nem javaslom senki hozzám hasonlatos "túlélőnek", hogy első lépéseit az adatbányászatban evvel a kurzussal tegye meg (nekem sem ezek voltak az első lépéseim). Maximum csak, ha valaki nagyon tehetséges, meg a matek iránt erősen affinis. Ugyanis mellbeverő a kurzus nehézsége, komplexitása (nekem legalábbis).
* Ha csak szimplán a felhasználói/üzleti vetületét nézem az adatbányászatnak, még ebben is csak 50%-osnak értékelem magam (maximum). Abban az értelemben mindenképpen, hogy projektszinten beérkező - akár szakmán kívülről jött - ötletek jelentős hányada egyszerűen nem jut eszembe (amikor kéne). És ezt maximum avval tudom kiegalizálni, hogy cserébe viszont mára már nekem is vannak olyan ötleteim, amik meg másoknak nem jutnak eszébe :) Mindez egyébként számomra - ensemble technikák analógiájára - erősen kidomborítja az adatbányászat csapatsport jellegét. A kurzus nagyban növelte a nagyon hiányzó 50% legalább valamelyest befogásának esélyét.
* Azt gondolom ez az a kurzus, ami nélkül a szó szoros értelmében nem halhat meg - ;) - adatbányász (feltéve, hogy nem tanulta korábban a tárgyat). Érdemes lehet idevágóan Kaggle-s fórumokat böngészni, (1) mennyi hálás tanítványa van Andrew Ng-nek. De ha ez nem lenne elég, (2) volt olyan verseny, amit az ő 2011-es cikke alapján nyert meg a győztes ("black box challange"). Mind szemléletében, mind konkrétumaiban, példamutató értékű a professzor tanár hozzáállása (számomra mindenképpen).
* Paradox módon ugyan, de a téma (avagy mitől és hogyan döglik a(z adatbányászatos) légy; az algoritmusok kontextusában) legnehezebb része tanítható a legkönnyebben, leguniverzálisabban. Ehhez nem kell más "csak" le kell menni a pokol tornácára (a matekhoz, vagyis az adatbányászat "assembly" nyelvéhez). Ez adja aztán a szükséges alapot ahhoz, hogy az adatbányász pontosabban tudja érzékelni, milyen feladatban mennyi potenciál van, mi az, amit már nem érdemes eröltetni és/vagy módszertant váltani hozzá. Amikor az adatbányász nemcsak bele a világba "klikkelget", hanem megalapozott értelemmel munkálkodik.
* Octave/Matlab hihetetlenül erős nyelv, nem is gondolná az ember, megadja a problémára fókuszálás maximális élményét (90%-10%), tömörséggel, élvezettel, nagy hatékonysággal
* Említésre méltók a számonkéréses feladatok. Egyrészt voltak tesztkérdések (kb.: 90-100 darab), másrészt voltak programozási feladatok (kb.: 40-50 darab). A neurális hálóknál volt 90 pontos brutális nehézségű feladat is, illetve voltak bónusz feladatok is (hogy lehessen plusz pontok szerzése révén határidő-csúszásokat kiegalizálni). És voltak törtpontok (legkisebb megszerezhető a 0.2 volt). Bónusz-feladatok nélkül a maximális elérhető pontszám 890 volt a két feladattípusban (ennyi kellett a 100%-hoz), bónuszokkal együtt 940 pont. Én ez utóbbit értem el 106% erejéig. Azért volt annak feelingje (számomra), hogy 0.2 pontot sem hagytam veszendőbe :)
* Angol nyelvi aspektusok. Mivel nem a nyelvzsonglőrök osztályát erősítem, így érthető módon öröm, meg sikerélményt adó volt érdemben és értelmesen gyakorolni az angol nyelvet. Külön élvezet volt a teszteknél a nyelvi finomságokra is figyelni. De nem hallgathatom el a hátrányát is. Egyfelöl sok-sok fogalomnak, definiciónak nem is tudom a magyar megfelelőjét, teljességgel angolul rögzül bennem. Másfelöl mivel angolul tanultam, így ugyanakkora erőbefektetés mellett az angol nyelven való tanulás sokkal kevésbé tud mély lenni (számomra), mintha ugyanezt magyarul tenném meg (saját tapasztalatom alapján).
* Végére hagytam a gépi tanulás "beskatulyázásának" aspektusát. Azt gondolom az adatbányászati szaktudásnak két nagy vetülete van (háromféle megközelítésben).
- Algoritmikus és nem-algoritmikus (értsd: adott esetben vajákolásosan misztikus)
- Domain-free és domain-specific, ahol az utóbbi mindig jobb eredményeket fog adni egy rablló-pandúr játék keretében (jelenlegi infók alapján illetve szerintem).
- Kutatói és üzleti adatbányászat.
Hallom az általános felhördülést "lelki füleimmel", hogy a visual streames szoftverhasználatot miért hagyom ki. Hát ennek a nem hangsúlyozásnak több oka is van:
- Egy Clementine-t még egy Microsoft Office-nál is könnyebb használni, annyira kézreáll.
- Csak "hangulatkeltéshez" elég, érdemi módon megalapozott adatbányászathoz nem.
- Ha lenne valós részesedése, akkor az 1-2%-nál többet nálam nem tudna elérni a másik kettőhöz képest, ami lássuk be mikroszkópikusan kicsi.
- Ha szigorúan vesszük, akkor az adatbányászat/machine-learning nem más mint egy pár új transzformációs oszlop egy meglévő dataset-hez, execute gomb megnyomás után. Jó egy kis paraméter pótméterezéssel. ;) Lássuk be az érdemi hozzáadott érték az alap dataset előállásában, a paraméterezésben, és az eredmények interpretálásában van, nem pedig abban, hogy hogyan kell az execute gombot megnyomni.
Azaz ezek mindegyike külön (nagy) tudomány:
- Adatbányász célú adatpiac építés
- Machine learning algoritmuselmélete
- Vizualizálás
- Prezentálás (sok infóból, a kellőt, célbaérően megmutatni)
És persze jó lenne a szakmába belemenve a konkrét részletekről is írni, de akkor sose fejezem be ezt a blogposztot ;)
2013. december 8., vasárnap
Adatvizualizálási oknyomozás
.
Alcím: Adatvizualizálási hazugságok, hamisítások :)
Steve Jobs elhíresült prezentációs diája látható fenn (azóta már oktatási anyagokba is került az "adatvizualizálási hazugság faktorok" fejezetbe. :)
Mit is látunk? Egy tortadiagramot, és Steve Jobs úgy intézte, hogy az Apple 19.2%-a szemre nagyobb legyen, mint az "egyéb" 21.2%-a ;) Nyilván pénzről, profitról, expanzióról szól a történet, ennyi turpisság bele "kell" férjen a várható haszon tükrében. Steve Jobs tehát nem tudhat rosszul kijönni a sztoriból, még a konkrétumok szintjén sem. ;)
Mi áll a dolog elméleti hátterében? Az hogy az emberi szem a négyzetek/téglalapok területi arányait sokkal-sokkal gyorsabban és pontosabban érzékeli, nagyobb tömegben végzett vizsgálatnál is. Míg a körnél/körcikknél meg ugyanezt nagyon, értsd nagggggggggggyon rosszul. Ezért favorizáltabb a szakmában például az oszlopdiagramok, hiszen ott ilyen megtévesztési/befolyásolási mókákra kevesebb lehetőség nyílik. Más kérdés, hogy van ahol célkitűzés az illuzionizmus. ;)
És mi lenne a hamisítás, a hazudással szemben? Mármint az én olvasatomban. Ha kör helyett "ellipszizálnánk", akárcsak icipici mértékben is. Hiszen akkor már az ívhosszak önmagukban is hazugságfaktorok tudnak lenni.
Steve Jobs csak hazudott-e avagy hamisított is? Sajnos a fényképezés torzít, mondhatni önmagában "ellipszizálhat". Utólag meg igen nehéz rekonstruálni a történteket. Én azt valószínűsítem, hogy SJ megelégedett a finomabb hazugság-módszerrel, nem akart túl sokat markolni.Azaz az előadásában tényleg rendes tortadiagram lehetett. Evvel maximalizálta is a sztori a hasznát is. Azt meg nem feltételezem, hogy SJ nem volt tisztában az egész történet ezen finom részleteivel. ;)
Alcím: Adatvizualizálási hazugságok, hamisítások :)
Steve Jobs elhíresült prezentációs diája látható fenn (azóta már oktatási anyagokba is került az "adatvizualizálási hazugság faktorok" fejezetbe. :)
Mit is látunk? Egy tortadiagramot, és Steve Jobs úgy intézte, hogy az Apple 19.2%-a szemre nagyobb legyen, mint az "egyéb" 21.2%-a ;) Nyilván pénzről, profitról, expanzióról szól a történet, ennyi turpisság bele "kell" férjen a várható haszon tükrében. Steve Jobs tehát nem tudhat rosszul kijönni a sztoriból, még a konkrétumok szintjén sem. ;)
Mi áll a dolog elméleti hátterében? Az hogy az emberi szem a négyzetek/téglalapok területi arányait sokkal-sokkal gyorsabban és pontosabban érzékeli, nagyobb tömegben végzett vizsgálatnál is. Míg a körnél/körcikknél meg ugyanezt nagyon, értsd nagggggggggggyon rosszul. Ezért favorizáltabb a szakmában például az oszlopdiagramok, hiszen ott ilyen megtévesztési/befolyásolási mókákra kevesebb lehetőség nyílik. Más kérdés, hogy van ahol célkitűzés az illuzionizmus. ;)
És mi lenne a hamisítás, a hazudással szemben? Mármint az én olvasatomban. Ha kör helyett "ellipszizálnánk", akárcsak icipici mértékben is. Hiszen akkor már az ívhosszak önmagukban is hazugságfaktorok tudnak lenni.
Steve Jobs csak hazudott-e avagy hamisított is? Sajnos a fényképezés torzít, mondhatni önmagában "ellipszizálhat". Utólag meg igen nehéz rekonstruálni a történteket. Én azt valószínűsítem, hogy SJ megelégedett a finomabb hazugság-módszerrel, nem akart túl sokat markolni.Azaz az előadásában tényleg rendes tortadiagram lehetett. Evvel maximalizálta is a sztori a hasznát is. Azt meg nem feltételezem, hogy SJ nem volt tisztában az egész történet ezen finom részleteivel. ;)
Tableau Data Visualization Cookbook
.
Én értékelésemben minden idők legrosszabb szakkönyve jelent meg 2013 augusztusában (elektronikusan 20, míg papírkötésben 40 USD):
Pact Publishing: Tableau Data Visualization Cookbook
Pedig a könyvkiadót a szakkönyveivel nagyon szeretem. Nagyon frissen cuppannak rá, nagyon aktuális témákra.
Ennél a könyvnél ráadásul a kiadó inkorrektnek tűnik első ránézésre, mert a tartalomjegyzéknél nem látszanak oldalszámok. Ez a cookbook írd és mondd, az index utolsó oldalával együtt 156.oldal(!). A könyv "overview"-jánál meg egyenesen 172 oldal látszik.
Már ennyiből is látszik, hogy nehéz komolyan venni a könyvet, leginkább azért, mert nincs minősítés (kezdő-haladó).
Azt el tudom (nagy nehezen) képzelni, hogy haladó fogások egy halmazára elég legyen 156 oldal, de ilyesmiről itt nincs szó.
Azt is el tudom képzelni, hogy egy bevezető "szakácskönyv" legyen 156 oldal - hiszen egyébként pártolom a minél kevesebb betűre való törekvést, itt a blogomon is :)
Chapter 1: Connecting to Data Sources
Chapter 2: Creating Univariate Charts
Chapter 3: Creating Bivariate Charts
Chapter 4: Creating Multivariate Charts
Chapter 5: Creating Maps
Chapter 6: Calculating User-defined Fields
Chapter 7: Customizing and Saving
Chapter 8: Exporting and Sharing
Chapter 9: Exploring Advanced Features
Hogyan lehet egy ilyen tartalomjegyzékkel megúszni a témát? A legdurvább, legutolsó advanced feature a "create parameter". Ezt mégis hogyan tudja komolyan gondolni egy ember? A könyvnek egyetlen érdemi értéke van, hogy az egyes tippeknél vannak "there's more" szekciók, valós, nagyon jó linkekkel. A könyv egyedül emiatt lehet esetleg érdekes, meg ha azt vesszük annyira nem drága (szigorúan csak elektronikus verzióban).
Személyes adalék:
Jövőre, 30 éves pályám során (20 évesen kezdtem lyukkártyás R-11-es IBM360-as KGST-klónon), mindösszesen csak három téma kapcsán fordult meg bennem, hogy de jó lenne tanítani, meg milyen nagy dolog lenne.
(1) SQL. Ezt elsősorban azért, mert meggyőzödésem, hogy világszerte rosszul tanítják, rossz elvek és rossz tankönyvek alapján. Én magam mondhatni egyetlen jó SQL-tankönyvet nem láttam (referencia nem tartozik ide, hiszen az nehezen tud rossz lenni). Ezt tudom nagyon hihetetlenül/morbidan hangzik, egy alaptémánál, de akkor is így van. Az én határozott véleményem az, hogy jobb tanítási módszerekkel, sokkal többet hozhatnának ki a felhasználók az sql-ből, sokkal "funny"-bb módon.
(2) Adatbányászat. Nyilván. :) Itt persze elsősorban az izgat, hogy hogyan lehetne kedvet csinálni hozzá, hogyan kellene a hatalmas anyagból válogatni, rendszerezni, mondjuk 1 másfélórás előadásra vagy 1 féléves főiskolai kurzusra. Hogyan lehetne közelhozni az egészet, érdekes és nem triviális módon (ami a legtöbb tananyag nagy hibája olvasatomban).
(3) Tableau. Szintén nyilván :) Tableau-val egy nagy gondom van e téren, hogy az idő múlásával párhuzamosan amint belekeveredek egyre "durvább" Tableau-s projektekbe, veszem észre, hogy egyre több mindent kéne még tudnom, egyre több van hátra. ;) Pedig egy egyszerű, felhasználóbarát szoftvernek néz csak ki, amit imádnak az üzleti userek.
Mindez pedig azért gond, mert egy oktató felé minimális elvárás, értelmezésemben, hogy legalább valamilyen szinten ontopik módon meg tudjon válaszolni minden - oktatás során - felmerülő kérdést. Na ettől én még messze érzem magamat, igazándiból csak egyetlen embert ismerek, aki megfelel ennek a kritériumnak. Azt gondolom egyébként, hogy nagyon nagy erőfeszítést igényel a 90%-ról a 99%-ra lépni.(ezért is lenne jó hivatalos Tableau oktatási anyagokat látni, amire eddig nem volt még módom).
Én értékelésemben minden idők legrosszabb szakkönyve jelent meg 2013 augusztusában (elektronikusan 20, míg papírkötésben 40 USD):
Pact Publishing: Tableau Data Visualization Cookbook
Pedig a könyvkiadót a szakkönyveivel nagyon szeretem. Nagyon frissen cuppannak rá, nagyon aktuális témákra.
Ennél a könyvnél ráadásul a kiadó inkorrektnek tűnik első ránézésre, mert a tartalomjegyzéknél nem látszanak oldalszámok. Ez a cookbook írd és mondd, az index utolsó oldalával együtt 156.oldal(!). A könyv "overview"-jánál meg egyenesen 172 oldal látszik.
Már ennyiből is látszik, hogy nehéz komolyan venni a könyvet, leginkább azért, mert nincs minősítés (kezdő-haladó).
Azt el tudom (nagy nehezen) képzelni, hogy haladó fogások egy halmazára elég legyen 156 oldal, de ilyesmiről itt nincs szó.
Azt is el tudom képzelni, hogy egy bevezető "szakácskönyv" legyen 156 oldal - hiszen egyébként pártolom a minél kevesebb betűre való törekvést, itt a blogomon is :)
Chapter 1: Connecting to Data Sources
Chapter 2: Creating Univariate Charts
Chapter 3: Creating Bivariate Charts
Chapter 4: Creating Multivariate Charts
Chapter 5: Creating Maps
Chapter 6: Calculating User-defined Fields
Chapter 7: Customizing and Saving
Chapter 8: Exporting and Sharing
Chapter 9: Exploring Advanced Features
Hogyan lehet egy ilyen tartalomjegyzékkel megúszni a témát? A legdurvább, legutolsó advanced feature a "create parameter". Ezt mégis hogyan tudja komolyan gondolni egy ember? A könyvnek egyetlen érdemi értéke van, hogy az egyes tippeknél vannak "there's more" szekciók, valós, nagyon jó linkekkel. A könyv egyedül emiatt lehet esetleg érdekes, meg ha azt vesszük annyira nem drága (szigorúan csak elektronikus verzióban).
Személyes adalék:
Jövőre, 30 éves pályám során (20 évesen kezdtem lyukkártyás R-11-es IBM360-as KGST-klónon), mindösszesen csak három téma kapcsán fordult meg bennem, hogy de jó lenne tanítani, meg milyen nagy dolog lenne.
(1) SQL. Ezt elsősorban azért, mert meggyőzödésem, hogy világszerte rosszul tanítják, rossz elvek és rossz tankönyvek alapján. Én magam mondhatni egyetlen jó SQL-tankönyvet nem láttam (referencia nem tartozik ide, hiszen az nehezen tud rossz lenni). Ezt tudom nagyon hihetetlenül/morbidan hangzik, egy alaptémánál, de akkor is így van. Az én határozott véleményem az, hogy jobb tanítási módszerekkel, sokkal többet hozhatnának ki a felhasználók az sql-ből, sokkal "funny"-bb módon.
(2) Adatbányászat. Nyilván. :) Itt persze elsősorban az izgat, hogy hogyan lehetne kedvet csinálni hozzá, hogyan kellene a hatalmas anyagból válogatni, rendszerezni, mondjuk 1 másfélórás előadásra vagy 1 féléves főiskolai kurzusra. Hogyan lehetne közelhozni az egészet, érdekes és nem triviális módon (ami a legtöbb tananyag nagy hibája olvasatomban).
(3) Tableau. Szintén nyilván :) Tableau-val egy nagy gondom van e téren, hogy az idő múlásával párhuzamosan amint belekeveredek egyre "durvább" Tableau-s projektekbe, veszem észre, hogy egyre több mindent kéne még tudnom, egyre több van hátra. ;) Pedig egy egyszerű, felhasználóbarát szoftvernek néz csak ki, amit imádnak az üzleti userek.
Mindez pedig azért gond, mert egy oktató felé minimális elvárás, értelmezésemben, hogy legalább valamilyen szinten ontopik módon meg tudjon válaszolni minden - oktatás során - felmerülő kérdést. Na ettől én még messze érzem magamat, igazándiból csak egyetlen embert ismerek, aki megfelel ennek a kritériumnak. Azt gondolom egyébként, hogy nagyon nagy erőfeszítést igényel a 90%-ról a 99%-ra lépni.(ezért is lenne jó hivatalos Tableau oktatási anyagokat látni, amire eddig nem volt még módom).
Címkék:
Adatvizualizálás,
blog,
interactive,
software,
tableau,
Tableau8,
visualization,
vizualizálás,
windows
2013. november 26., kedd
RapidMiner v6: verzió-upgrade-k negatív guinness-rekordja
.
Hát ilyen rosszul kevés verzió-upgrade esett jól nekem, pedig még csak nem is vagyok célközönsége a terméknek, nem volt még pénzes projektem a tárgybeli data mining tool-lal.
Ezért "kár" volt 5 millió dollár tőkét invesztálni a termék cégébe, beletaposva a RapidMiner közösség erre - a durva árskálázós lépésre - érzékeny részébe.
A verzió legnagyobb ujdonsága, ugye a kommercializálódása:
Press Kit | RapidMiner
- Kiváncsi lennék az 1 GB-os verzió célközönségére. Mondjuk egyetemeken talán lehet tanítani vele, de ismerve az eszköz memóriaéhségét ebben sem vagyok biztos. Mintha ingyen se kéne az embernek, kár bele az erőfeszítés és idő is. Ez a STARTER dolog egyébként egy rossz emlékű deja vu-t is felidéz, a Microsoft Windowsnak van ilyen használatatlannak érzett starter verziója.
- Azért az szép teljesítmény a nyugati transzparancia híveinek, hogy az Enterprise-verzió árát ki sem merték írni, ami listaáron 6-7-8.000 USD lehet minimum. Az én konteóm szerint egyébként lesz akinek olcsóbb és lesz akinek drágább lesz, a demokrácia legnagyobb dicsőségére. Én az ilyen terméket ab ovo szeretem kerülni.
- A legnagyobb baj/szomorúság, hogy a böhöm mamutok (pl.:SAS) malmára hajtja a vizet ez a durva árskálázós lépés, szvsz. Annyira még nincs jó híre, meg nem egyenszilárd a RapidMiner, hogy például egy SPSS Modelerrel versenyezzen enterprise kategóriában, ráadásul ugye az IBM/SPSS megteszi azt a tudván-tuhatóan szintén inkorrekt lépést, hogy nagy cégeknek akár 80%-os árkedvezményt is ad termékeiből. Egy Modelet 25.000 dolláros listaára így 5.000 dollárra csökken, ami már egyenesen versenyképes a RapidMiner áraival.
- Akinek nélkülözhetetlen a visual stream, annak megmarad:
Knime
RapidMiner v5.3
Weka
Python-Orange
- Érdemes megvizsgálni a kérdést, mennyire létkérdés a visual stream használata az adatbányászatban. Az egyik szétbontás szerint vannak céges és vannak magánzó(kutató/data scientist) adatbányászok. Egy másik felbontás szerint van a core adatbányászat és van a mindenféle pre meg post tevékenység - pl.:vizualizálás, ugye ;)
- Egy kutató/magánzó data scientist gyönyörűen elvan az SQL/Python/R/Octave négyessel (esetleg C/Java kiegészítéssel), nagyon jó eséllyel. Ha valakinek, akkor neki aztán semmi szüksége visual stream-re. Enterprise könyezetben egyelőre a visual stream-ek lehetnek a nyerők, de perdöntően inkább csak a modell-fejlesztésnél, ezért is tud szárnyalni egy SAS is. Hogy lesz-e paradigmaváltás az ügyben, azt szerintem még korai elemezni, érdemben. Kicsit analógnak érzem a Linux elterjedését server és desktop gépeken. Előbbi kategóriában egyértlműen sikerült neki, utóbbin meg nem. A visual streamek a windows-os desktop gépeknek felelnek meg, kérdés tudnak-e "linuxosodni".
- A visual stream-ek nagy hátránya, hogy elsősorban az egyéni munkát támogatja jobban (avval, hogy segíti a programozni nem tudó, de klikkelgetni szerető üzleti emberek munkáját). Kvázi mint az Excel. Egy vállalatnak viszont komplex adatbázisai, folyamatai vannak, amiknek komoly integrációs impactjai vannak. Na és ezt a visual streamek világa már rosszul támogatja (költségek, és nem technikai korlátok szempontjából). A core adatbányászat (mondjuk most így dataset-ből dataset-be transzformálás), az viszont bőven megvan visual stream nélkül.
Hát ilyen rosszul kevés verzió-upgrade esett jól nekem, pedig még csak nem is vagyok célközönsége a terméknek, nem volt még pénzes projektem a tárgybeli data mining tool-lal.
Ezért "kár" volt 5 millió dollár tőkét invesztálni a termék cégébe, beletaposva a RapidMiner közösség erre - a durva árskálázós lépésre - érzékeny részébe.
A verzió legnagyobb ujdonsága, ugye a kommercializálódása:
Press Kit | RapidMiner
- Starter Edition, with 1 GB of memory, access to MS Excel and Access data, and no licensing fee;
- Personal Edition, with 4 GB of memory, access to most common data files and open source databases, 14 days of support, priced at $999;
- Professional Edition, with 8 GB of memory, access to most common data files and databases, 14 days of support, priced at $1,999/$2.999; and
- Enterprise Edition, with unlimited memory, access to all files and databases, (including HDFS, SAS, SPSS, and SAP), full support, with pricing available on request.
- Kiváncsi lennék az 1 GB-os verzió célközönségére. Mondjuk egyetemeken talán lehet tanítani vele, de ismerve az eszköz memóriaéhségét ebben sem vagyok biztos. Mintha ingyen se kéne az embernek, kár bele az erőfeszítés és idő is. Ez a STARTER dolog egyébként egy rossz emlékű deja vu-t is felidéz, a Microsoft Windowsnak van ilyen használatatlannak érzett starter verziója.
- Azért az szép teljesítmény a nyugati transzparancia híveinek, hogy az Enterprise-verzió árát ki sem merték írni, ami listaáron 6-7-8.000 USD lehet minimum. Az én konteóm szerint egyébként lesz akinek olcsóbb és lesz akinek drágább lesz, a demokrácia legnagyobb dicsőségére. Én az ilyen terméket ab ovo szeretem kerülni.
- A legnagyobb baj/szomorúság, hogy a böhöm mamutok (pl.:SAS) malmára hajtja a vizet ez a durva árskálázós lépés, szvsz. Annyira még nincs jó híre, meg nem egyenszilárd a RapidMiner, hogy például egy SPSS Modelerrel versenyezzen enterprise kategóriában, ráadásul ugye az IBM/SPSS megteszi azt a tudván-tuhatóan szintén inkorrekt lépést, hogy nagy cégeknek akár 80%-os árkedvezményt is ad termékeiből. Egy Modelet 25.000 dolláros listaára így 5.000 dollárra csökken, ami már egyenesen versenyképes a RapidMiner áraival.
- Akinek nélkülözhetetlen a visual stream, annak megmarad:
Knime
RapidMiner v5.3
Weka
Python-Orange
- Érdemes megvizsgálni a kérdést, mennyire létkérdés a visual stream használata az adatbányászatban. Az egyik szétbontás szerint vannak céges és vannak magánzó(kutató/data scientist) adatbányászok. Egy másik felbontás szerint van a core adatbányászat és van a mindenféle pre meg post tevékenység - pl.:vizualizálás, ugye ;)
- Egy kutató/magánzó data scientist gyönyörűen elvan az SQL/Python/R/Octave négyessel (esetleg C/Java kiegészítéssel), nagyon jó eséllyel. Ha valakinek, akkor neki aztán semmi szüksége visual stream-re. Enterprise könyezetben egyelőre a visual stream-ek lehetnek a nyerők, de perdöntően inkább csak a modell-fejlesztésnél, ezért is tud szárnyalni egy SAS is. Hogy lesz-e paradigmaváltás az ügyben, azt szerintem még korai elemezni, érdemben. Kicsit analógnak érzem a Linux elterjedését server és desktop gépeken. Előbbi kategóriában egyértlműen sikerült neki, utóbbin meg nem. A visual streamek a windows-os desktop gépeknek felelnek meg, kérdés tudnak-e "linuxosodni".
- A visual stream-ek nagy hátránya, hogy elsősorban az egyéni munkát támogatja jobban (avval, hogy segíti a programozni nem tudó, de klikkelgetni szerető üzleti emberek munkáját). Kvázi mint az Excel. Egy vállalatnak viszont komplex adatbázisai, folyamatai vannak, amiknek komoly integrációs impactjai vannak. Na és ezt a visual streamek világa már rosszul támogatja (költségek, és nem technikai korlátok szempontjából). A core adatbányászat (mondjuk most így dataset-ből dataset-be transzformálás), az viszont bőven megvan visual stream nélkül.
2013. november 24., vasárnap
Kell-e adattárház ODS és DATA MART közé?
.
Egy teljesen természetes interakciós folyamat lehet az, hogy
- STAGE/ODS rétegben gyűlnek a forrásrendszerek napi snapshotjai
- STAGE/ODS rétegből képződik egy adattárház, mondjuk VAULT módszertan szerint.
- VAULT adattárházból készülnek pl.: riporting adatpiacok.
- Ki kell mutatni, hogy az ODS/STAGE minden szükséges adata 100%-ban megjelenik az adatpiacban.
- Mivel a felhasználó csak az adatpiaccal érintkezik, azonnal felmerül benne a laikus kérdés, minek adattárházat finanszírozni fejlesztési és üzemeltetési költségekkel. Neki elég az adatpiac is, úgymond.
- Korrekt STAGE/ODS, korrekt DATA MART valamint korrekt leképezés mellett minek adattárház?
KÉRDÉS: Lehet-e, szabad-e egyből DATA MART-o(ka)t építeni? Mi a hozzáadott értéke egy adattárháznak, mennyiben tekinthető szükséges rossznak?
Pro érvek lehetnek az adattárház ignorálására:
- Elképzelhető olyan scenárió, amikor egyszerű forrásrendszerek, komoly adattárházépítési logika felmerülési igénye nélkül kvázi egymás mellé önthetők egyetlen adatpiacban. Ilyenkor valóban tűnhet felesleges overhead-nek egy közbülső adattárház.
- Sajnos még mindig sokszor csillagrombolós költségvetésű egy-egy adattárház-fejlesztése, és mellé nagyon lassú, nehézkes, költséges tud lenni az organikus fejlődése, up-to-date-n tartása.
- Felelőtlen forrásrendszer-felelősök könnyen haza tudnak vágni egy adattárházat (használhatóságilag) nem körültekintő fejlesztésekkel, ahogy általában is az OLTP forrásrendszerek könnyen jutnak nagyobb budgethez, nagyobb prioritáshoz üzleti fejlesztések keretében.
- Tipikus forgatókönyv szokott lenni ilyen fent említett adattárház-elmászásoknál, hogy az üzleti user gyorsan megneszeli a problémát, majd a gépén lévő Access/Excel-lel rácsattan a forrásrendszerre, lehúzza a gépére az adatait és kis magászigetecskéjén elemez. Ennél már a versengő adatpiacok is jobb gondolat. ;)
- Az üzleti élet pörög és egyre jobban csak pörög egyre több dolgozónak van szüksége egyre nagyobb mennyiségű adat átfésülésére a napi munkájához, a gyorsítás igénye folyamatosan napirenden szokott lenni, aminek logikus következménye az adattárház létszükségletének megkérdőjelezése.
- Miért ne lehetne "versengő" adatpiacok egymás mellett élése egy vállalatban, szabályozott redundancia és környezet mellett?
Pro érvek lehetnek az adattárház mellett:
- Régen rossz, ha forrásrendszerek úgymond "összege" kiadja az "analitikus" igények, adatszármaztatási vonzatának 100%-át, ott valami nem kerek jó eséllyel, látatlanban is.
- Képződ(het)nek új adatok, tudni kell aktuálisan még nem is létező új forrásrendszereket integrálni.
- Talán a legfontosabb, hogy az enterprise MDM (mind a master data ~, mind a meta data management) leginkább ebben az esetben tartható valamiféle mederben. A versengő adatpiacok sokkal könnyebben csábítanak vállalaton belüli fegyelmezetlenségekre, dokumentálatlanságokra, párhuzamosságokra, inkonzisztenciákra (lásd pl.: ügyféldeduplikálási problémák => könnyebb káoszt eredményezni, mint rendbetenni).
- A VAULT módszertan már komoly hozzáadott értéket ad az adattárházépítés rugalmasságához, tulajdonképpen kevés overheaddel. Komoly érv kell tehát az ignorálására: nem tűnik triviálisnak a dolog.
Én négy dolgot állítok, konklúzióként:
- Mindkét forgatókönyv lehet életképes, komoly megalapozott tervezés eredményeként csak, persze
- Nincs hüvelykujjszabály melyik a jobb: lokális specifikumok határozzák meg döntéshozatal alapját.
- Az élet hozhatja úgy, hogy bár jó volt az eredeti választási döntés, de át kell térni a másik verzióra.
- Az a vállalat működik jól üzleti intelligencia értelemben, ahol
* jó adatokkal, jól számolnak az üzleti userek, konszenzusos válaszidőkkel
* nincs divergálás az adatok között DQM-problémákat generálva
* organikus és konszenzusosan gyors a fejlődés
* adatpiacok üzleti intelligencia produktumai össze tudnak adódni vállalati értékké.
* a maximalizált vállalati üzleti intelligencia érték optimális további növelése csak nagy befektetéssel növelhető (magyarán nem éri meg).
Egy teljesen természetes interakciós folyamat lehet az, hogy
- STAGE/ODS rétegben gyűlnek a forrásrendszerek napi snapshotjai
- STAGE/ODS rétegből képződik egy adattárház, mondjuk VAULT módszertan szerint.
- VAULT adattárházból készülnek pl.: riporting adatpiacok.
- Ki kell mutatni, hogy az ODS/STAGE minden szükséges adata 100%-ban megjelenik az adatpiacban.
- Mivel a felhasználó csak az adatpiaccal érintkezik, azonnal felmerül benne a laikus kérdés, minek adattárházat finanszírozni fejlesztési és üzemeltetési költségekkel. Neki elég az adatpiac is, úgymond.
- Korrekt STAGE/ODS, korrekt DATA MART valamint korrekt leképezés mellett minek adattárház?
KÉRDÉS: Lehet-e, szabad-e egyből DATA MART-o(ka)t építeni? Mi a hozzáadott értéke egy adattárháznak, mennyiben tekinthető szükséges rossznak?
Pro érvek lehetnek az adattárház ignorálására:
- Elképzelhető olyan scenárió, amikor egyszerű forrásrendszerek, komoly adattárházépítési logika felmerülési igénye nélkül kvázi egymás mellé önthetők egyetlen adatpiacban. Ilyenkor valóban tűnhet felesleges overhead-nek egy közbülső adattárház.
- Sajnos még mindig sokszor csillagrombolós költségvetésű egy-egy adattárház-fejlesztése, és mellé nagyon lassú, nehézkes, költséges tud lenni az organikus fejlődése, up-to-date-n tartása.
- Felelőtlen forrásrendszer-felelősök könnyen haza tudnak vágni egy adattárházat (használhatóságilag) nem körültekintő fejlesztésekkel, ahogy általában is az OLTP forrásrendszerek könnyen jutnak nagyobb budgethez, nagyobb prioritáshoz üzleti fejlesztések keretében.
- Tipikus forgatókönyv szokott lenni ilyen fent említett adattárház-elmászásoknál, hogy az üzleti user gyorsan megneszeli a problémát, majd a gépén lévő Access/Excel-lel rácsattan a forrásrendszerre, lehúzza a gépére az adatait és kis magászigetecskéjén elemez. Ennél már a versengő adatpiacok is jobb gondolat. ;)
- Az üzleti élet pörög és egyre jobban csak pörög egyre több dolgozónak van szüksége egyre nagyobb mennyiségű adat átfésülésére a napi munkájához, a gyorsítás igénye folyamatosan napirenden szokott lenni, aminek logikus következménye az adattárház létszükségletének megkérdőjelezése.
- Miért ne lehetne "versengő" adatpiacok egymás mellett élése egy vállalatban, szabályozott redundancia és környezet mellett?
Pro érvek lehetnek az adattárház mellett:
- Régen rossz, ha forrásrendszerek úgymond "összege" kiadja az "analitikus" igények, adatszármaztatási vonzatának 100%-át, ott valami nem kerek jó eséllyel, látatlanban is.
- Képződ(het)nek új adatok, tudni kell aktuálisan még nem is létező új forrásrendszereket integrálni.
- Talán a legfontosabb, hogy az enterprise MDM (mind a master data ~, mind a meta data management) leginkább ebben az esetben tartható valamiféle mederben. A versengő adatpiacok sokkal könnyebben csábítanak vállalaton belüli fegyelmezetlenségekre, dokumentálatlanságokra, párhuzamosságokra, inkonzisztenciákra (lásd pl.: ügyféldeduplikálási problémák => könnyebb káoszt eredményezni, mint rendbetenni).
- A VAULT módszertan már komoly hozzáadott értéket ad az adattárházépítés rugalmasságához, tulajdonképpen kevés overheaddel. Komoly érv kell tehát az ignorálására: nem tűnik triviálisnak a dolog.
Én négy dolgot állítok, konklúzióként:
- Mindkét forgatókönyv lehet életképes, komoly megalapozott tervezés eredményeként csak, persze
- Nincs hüvelykujjszabály melyik a jobb: lokális specifikumok határozzák meg döntéshozatal alapját.
- Az élet hozhatja úgy, hogy bár jó volt az eredeti választási döntés, de át kell térni a másik verzióra.
- Az a vállalat működik jól üzleti intelligencia értelemben, ahol
* jó adatokkal, jól számolnak az üzleti userek, konszenzusos válaszidőkkel
* nincs divergálás az adatok között DQM-problémákat generálva
* organikus és konszenzusosan gyors a fejlődés
* adatpiacok üzleti intelligencia produktumai össze tudnak adódni vállalati értékké.
* a maximalizált vállalati üzleti intelligencia érték optimális további növelése csak nagy befektetéssel növelhető (magyarán nem éri meg).
Breaking News: Haskel Financial Data Modeling and Predictive Analytics
.
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
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 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..........
Feliratkozás:
Bejegyzések (Atom)
.jpg)



