.jpg)
Előző blogposztom után ért néhány impulzus, ami további tárgybeli téma-firtatásra sarkallt.
MTA-workshop ~ A nagyság átka: nagyméretű hálózatok, adatok és szoftverek problémái
(1) Kovács Gyula az Andego Kft szineiben publikált egy nagyszerű blogposztot, ha mást nem nézünk csak az ábráját, akkor is sokkal érthetőbb lett a megközelítés és precízebb megvilágításba helyezte az egész témát - pláne adatbányász kontextusban -, mint nekem sikerült a vázlatommal.
Modellek nyugdíjban
(2) Gyula megosztotta az MTA-esemény eredeti meghívó linkjét. Ezt most én is megteszem:a teljesség kedvéért.
Tudományos ülésszak „A nagyság átka: nagyméretű hálózatok, adatok és szoftverek problémái” címmel
A meghívón láthatóan volt tehát a hatodik záróelőadás a friss Akadémia-díjas előadó által:
Gyimóthy Tibor, az MTA doktora: Karbantartási problémák millió sor felett.
Két további lényeges impulzus ért a témában:
(A) A Java levelezési listán lévő közös gondolkodás, ami odáig "fajult", hogy elkezdtem keresni az eredeti előadás alapját képező cikke(ke)t.
(B) Nagy küzdés után megtalált cikk világos, szép, igényes, módszertana adatbányász szívnek kedves.
Columbus: A Reverse Engineering Approach
New Conceptual Coupling and Cohesion Metrics for Object-Oriented Systems
Akik nem akarnak elmerülni a részletekbe azok számára (meglehet torzított) rövid értelmezésem az alábbi.
A cikk előtt én az alábbit gondoltam a csatolásokról:
Csatolás/Coupling, szoros klasszikus értelemben és OO paradigmában - minden osztályok közötti metódus hívás-, mező/property-elérés-, öröklés-, argumentum/paraméter-, visszatérési érték-, kivétel-érintettség (ha Eiffelben lennénk, akkor ideírnám a szabály-érintettséget is) és ha valamit kihagytam akkor bocs.
Csatolás tágabb értelemben minden, információt hordozó, valamilyen erősséget reprezentáló és adott hatást generáló összefüggés/kapcsolat, számomra a legközelebbi angol terminus: a linking.
Adott a szegedi egyetem által több éve kifejlesztett Columbus nevű, C/C++ - szoftverminőséget 58 db metrikán keresztül mérő - reverse engine framework. Az előadáson vesézett Nokia Symbianra is ezt engedték rá tehát.
Az előadás egy picit félrevezető volt, mert ott sokkal bonyolultabb matek látszott. Ezek a cikkek egyszerűbb matekúak, azaz minden téma iránt érdeklődőt buzdítok olvassa el a cikket, mert tényleg érthető)
Az újabb cikk két új metrikát vezet be a régiekből kiindulva
(1) Conceptual Coupling between Object classes (CCBO)
(2) Conceptual Lack of Cohesion on Methods (CLCOM5)
Folyamat:
* Reverse Engine Columbus-szal (cikkben Mozilla projektre)
* Korpusz-építés az alábbiakra (+stoplista)
(1) comments
(2) local and attribute variable names
(3) user defined types
(4) methods names
(5) parameter lists and
(6) names of the called methods.
* Latent Semantic Indexing (LSI) szövegbányászati metódus alkalmazása
* Metrika-kalkulálás, -alkalmazás
* Ezután megkaphatók a releváns kapcsolatok
* Elő kell venni a Mozilla hibaadatbázisát
* Meg kell nézni, hogy a metrikák (azon belül releváns kapcsolatok) hogyan függnek össze a hibákkal
* Prediktív analitika széles tárházával (Weka, 12 algoritmus) szembesítették az immáron 61 db szoftver metrikát -> melyik metrika a legjobb hibaelőrejelző (hibahajlam-feltáró)
* Ez vezet a végső előadói konklúzióhoz: túl sok csatolás túl sok hibához vezethet, ami jobban valószínűsíti a kiváltást.
Konklúzióm (még ha egyedül is maradok vele a világban)
Tiszta világos gondolatmenet a fenti. Az egyedüli meggondolandó az érvényességi tartomány.
Lehet "lázadni" az ellen, hogy a hibák azért vannak, hogy kiküszöböljük őket, meg amúgy is csak az egyszerű emberek raknak rendet, mint tudjuk a "zsenik uralják a káoszt".
Én mégis azt mondom, ahogy a való életben a túl sok hiba elbocsátáshoz vezet a munkahelyen, úgy a szoftverben lévő kritikus tömegű hiba a szoftver kiváltási presszióját növeli. Ennyi. Nem több és nem kevesebb.
A hibákat meg nemcsak kinyilatkoztatás szintjén kell kerülni, hanem rásegíteni hasznos eszközökkel.
Szükséges, de nem elégségesen hasznos, ha a hibákat elektronikusan dokumentáljuk. Ha "ezrével" rögzítünk be hibákat ezt támogató rendszerekbe, az önmagában már deprimálóan hat és rontja a hibajavítás hatékonyságát. Én voltam nem egyszer résztvevője olyan projekteknek (harmadik legutóbbi itthon Magyarországon(!) 1.400 ETL-job verzióváltásos migrálása, 10.000-es nagyságrendű tárolt eljárással, olykor többezer kódsorral elég kevés emberhónap alatt, de legutóbbi két projektem is ilyen alapokon volt problémás redesignjai elött: valahogy tehát én vonzom ezeket) ==> ahol túl sok hiba merült fel túl kevés idő alatt az egész projektet alapjaiban megrengetve.
A tárgyalt potenciális eredmény/lehetőség, a csatolások számának csökkentése. Egybevág az eddigi szemlélettel (nem kell paradigmaváltás), kárt nem okoz, maximum valamennyi ráfordítási igénye van. Analóg módon, például ahogy egy B+ fába se elég elemet beszúrni, utána a fát ki kell egyensúlyozni.
Mindenki mérlegelheti ezt cost-benefit alapon, támogatja-e ezt a munkájában.
Én a magam részéről letettem a voksomat (már régóta akkor még pusztán csak intuitiv alapon), hogy megéri a "lineáris" erőforrásigényű befektetést, potenciálisan progresszíven növekedő komplexitás és hibaszaporodás elkerülése érdekében.
További elágazás Wikipediából kiindulva:
Coupling
Cohesion
Static code analysis
Dynamic program analysis
2012. május 19., szombat
2012. május 17., csütörtök
MTA-workshop ~ A nagyság átka: nagyméretű hálózatok, adatok és szoftverek problémái
Tegnap délután volt szerencsém ottlenni a Magyar Tudományos Akadémia kistermében rendezett félnapos workshopon, amin hat nagyszerű, nagy hatású előadást, prezentációt lehetett élvezni.
Igyekszem (kulcsszavakra, "mémekre" koncentrálva) minél kevesebb betűt írni az elhangzott hatalmas és nehéz információáradatból, ráadásul bulvárosítva, hogy könnyebb legyen olvasni, egyébként is a cél csak a figyelem felkeltése.A mondatokra kiegészítést az olvasóra bízom, akit érdekel az adott téma ezt úgy is megteszi.. Részletekért érdemes az irodalom linkjeire klikkelni.
Ami angolul hangzott el, angolul adom vissza, ami magyarul, azt magyarul, a minél kisebb torzítás érdekében.
Tudományos ülésszak "A nagyság átka: nagyméretű hálózatok, adatok és szoftverek problémái"
Időpont: 2012. 05. 16.
Helyszín: MTA Székház, Kisterem (II. emelet)
Üléselnök: Pálfy Péter Pál osztályelnök
Program
13.30 A Matematikai Tudományok Osztálya 2012. évi díjainak ünnepélyes átadása
Ezen a ponton három fiatal negyven év alatti matematikus kapott díjat, különböző területekről.Részletes 10-10 perces felvezető után.Esély nem volt jegyzetelni....
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
14.00 ifj. Benczúr András, PhD: "Big Data": amikor a probléma az adat mérete maga.
* Nagyságrendek
- Google Sorts 1 PB in 33 minutes - 2011.09.07-i adat
- Amazon Store 726 billion objects - 2012.01.31-i adat (exponenciálisan nő)
- Walmart 100 million objects real-time monitor - 2011.09.12-i adat
- New Relic (ezt már nem tudtam leírni)
(Blogírói megjegyzés, itt bizony érdekes lett volna mondjuk egy eBay is, pláne üzleti intelligencia vonzata miatt)
* Koordináta-rendszerben függőleges tengelyen a real-time sebesség, vízszintes tengelyen a méret. Nem méretarányosan és csak pár név/márka a 40-50-ből.
^
| | | | ITlogs
| | |SPSS |
| | |SAS |
| |Matlab |Netezza |
| |R |Hadoop |
| |Greenplum |
| |Progress |
|MySql|
---------------------------------------->
* Big Dataról szólt a kötelmúltban:
(1) VLDB 2011 konferencia
(2) SigMod 2011 konferencia
(3) Gartner
Stb.
* Nagy kérdés miért most lett hype?!
- De rossz hír a lineárisnál lassabb algoritmusoknak
- Managing Gigabytes könyv. Régen íródott (1994) ez a címében is látszik :o)), de ma is aktuális dolgok vannak benne.
* Moore-törvény
- Eddig 18 havonta sebesség duplázódás
- Innentől 18 havonta mag-duplázódás (CPU,GPU) /Sebesség már nem tud nőni, elméleti okokból/
* Nevezéktan:
- Multi Core -> CPU
- Many Core -> GPU
* Technológiában még:
- Cloud
- Flash Diskes külső tárak terjedése
* Régóta létező közismert gráf-probléma, minimális feszítőfa keresése
- Még mindig nyitott kérdés, hogy van-e lineáris idejű determinisztikus algoritmus általános élsúlyokra.
- A feladatot párhuzamosított algoritmussal is sikerült megoldani. 8 processzoron mára már ötször gyorsabb, mint egy optimalizált szekvenciális algoritmus (2003-as adat).
- A legelső tárgybeli cikk 1980-ra datálódik, de az előadó szerint lehet még ennek is van előzménye.
És hogy miért érdekes a minimális feszítőfa?
* Mert az azonosság-feloldástól (entity-resolution, record linkage, deduplikálás) a képszegmentálásig csomó probléma erre vezethető vissza. Ezek közös jellemzői, hogy igen sok adat bír fegyülemleni, amit ugye lineáris műveletigénnyel kéne feldolgozni.
* Az előadó csapata egy biztosítónál három módszert is összevetett.
- Distributed key-value store http://project-voldemort.com/
- MapReduce, Hadoop https://hadoop.apache.org/
- Bulk Synchronous Parallel http://en.wikipedia.org/wiki/Bulk_synchronous_parallel
* Vannak még
- Superstep
- Apacha Hama
- Google Pregel
- Graphlab
* Van a híres háromszög a Fox Brewer CAP-tétel kapcsán
http://en.wikipedia.org/wiki/CAP_theorem
A háromszög csúcsaiban
- Elérhetőség
- Konzisztencia
- Particiónálási hibatűrés
Elosztott rendszerben egyszerre csak (bármelyik) kettő garantálható a fenti háromból, mind a három nem.
* Nem jók osztott memóriára
- DeDup közismert blocking algoritmusai
- Locality Sensitive Hashing
Blogírói megjegyzés: ettől még van MapReduce implementáció a deduplikálásr, tudtommal.
* Big Data
- Adatbányászat
- Keresés
- Gépi tanulás
- Hálózatelmélet
* Mai terep jellemzői
- Korlátok
- Hibatűrési problémák
- Adatintenzív műveletek
- Kiforratlan algoritmusok (Hama, Bulk Synchronous Parallel, stb.)
Irodalom:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
14.25 Huszti Andrea PhD: Biztonságos e-alkalmazások.
(1) E-szavazás
* Elvárások:
- Jogosultság
- Titkosság
- Csak egyszer lehessen szavazni
- Individuum-ellenőrzés (megnézhessem, az látszik-e amit adtam)
- Univerzális ellenőrzés (passzív külső szemlélő is ellenőrizhessen)
- Igazságosság
- Megvesztegethetetlenség
(2) E-vizsgáztatás
- Eléggé azonos az e-szavazással
- Demó projekt az egyetemen
- Titkos a vizsgázó is, vizsgáztató is
- Plusz dolog: visszaállítható anonimitás (ki adott végül jegyet -> leckekönyvben már nevesíteni kell)
További lehetőségek:
(3) E-kérdőv
(4) E-közvéleménykutatás
(5) E-aukció
(6) E-pályáztatás (ne lehessen tudni ki a pályázó és ki bírál)
Irodalom:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
14.50 Jelasity Márk PhD: Kollektív tanulás milliós hálózatokban.
* iPhone, iPad exponenciálisan nő 100 milliós nagyságrendben
* Szenzorok, gazdag kontextus. Egyenes út a kollaboratív adatbányászatig és inkrementális tanulásig
* Felhasználási terület
(1) Egészségügy: járványtól akár cukorbetegség-előrejelzésig
(2) Smart City: forgalom optimalizálás, balesetveszélyes helyzetekre előrejelzés
(3) Földrengés előrejelzés
(4) Pénzügyi alkalmazások
* Architektúra: p2p, grid
* Három problémával kalkulálni kell:
(1) Késhet adat kommunikációnál
(2) Veszhet el adat
(3) Cserélődhet a sorrend
* Kaotika megjelenése
* Teljesen elosztott modell. Horizontális az elosztottság
- Kevés adat a csomópontokon, adott esetben egyetlen rekord
- Adatmozgás nincs, se csomopontok között, se big data szerverre fel (adatvédelem)
- Csak modell-adatok (paraméterek) közlekednek, cserélődnek a csomópontok között
- Annyi kell, hogy az újabb csomópontokon a bejövő modelladatok, és az adott csomóponton képződő kevés lokális adat alapján
(1) Rekonstruálható legyen a teljes addigi modell.
(2) Eldönthető legyen, hogy ez új lokális adat javítja-e modellt avagy ignorálandó.
(3) A permanens szavazás (inkrementális tanulás) révén megszülető predikciót meg lehessen tenni a csomópont kijelzőjén.
* Mindezt un. online algoritmussal. Jellemzők:
(1) Egyszerre egyetlen rekord (véletlen)
(2) Modell-javítás például súlyfüggvény módosítással á lá SVM.
* Sztochaisztikus Gradiens módszer közismert módszer
* Az előadó csapata által kidolgozott módszer alapja:
(1) Pletyka tanulás (Gossip Learning)
(2) Véletlen séták (csomópontok között)
(3) Eközben történik a modell javítása
* Algoritmus-részletek:
(1) Például alábbi demo-választással: Z=merge(x,y)=(x+y)/2 (átlagolás)
(2) Adaline Perceptron
(3) Exponenciálisan nöhet a propagált modellek száma, időben lineárisan
(4) Szavaztatás, például többosztályos boosting vonalán
Blogírói megjegyzés: ez az egész valami eszméletlen szép gondolatkör, óriási potenciállal.Időben lineárisan propagált exponenciálisan növekvő számú modellek melleti gépi tanulás, adatvédelem mellett: GYÖNYÖRŰ.
* Hallgatóság soraiból:
Kérdés: mekkora az érzékenység "rémhír" terjesztésre
Válasz: Ez valóban kritikus pont, szakirodalom intenzíven foglalkozik a témával.
Irodalom:
Asynchronous peer-to-peer data mining with stochastic gradient descent. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
15.15 Kávészünet
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
15.45 Pataricza András, az MTA doktora: Modellezés az informatikai rendszerek komplexitásának uralására.
* Tele van a folyamat kőkemény matematikával
- Specification
- Transformation
- Design modell
(1) Parametrization
(2) Simulation
(3) verification, validation (consystency)
(4) optimization
(5) Partitioning
(6) Scheduling
- Communication Synthesis
- Behavior Modell & Implementation, testing - Hardware & Software Synthesis
* Szemantikus modellezés, ontologiák
- Catalog->Glossary->Thesaurus->Informal->...->Metamodell
- A fentire analóg, hogy népi építészet elvei fogásai öröklődtek generációkon át, ezt kéne matematikai formalizmusba önteni
- Kritikus folyamatoknál, repülésirányítás, megkövetelnek matematikai helyességbiznyítást
* Analóg példa, régen minden gyárnak saját generátortelepe volt, majd jött az áramszolgáltató, ma mindenkinek saját architektúra, jön a Cloud
* Cloudban egyenként sokszor 200 millió rekord, benne ha 6000 rossz, az már panaszt generálhat: hatásában olyan, mint a PC-t hirtelen áramtalanítani.
* Régen minden jól működjön, ha a részek működnek, ma már, ha a részek nem működnek jól, akkor is működjön.
* Dependability
- online algoritmusok, inkrementális tanulás itt is előjött
- "All in the runtime" - nyitott a matekja
- "Be ready for change" - kis változásnál ne kelljen mindent újraszámolni.
- "A matematika az intelligencia forrása"
- Fókusz: test, maintenance, memory, speed, energy
Irodalom:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
16.10 Beszédes Árpád PhD: Függőség elemzés nagy rendszerekben.
* VÁLTOZÁS menedzselése a szoftver életciklusában
(1) Változás igénye, költségbecslés
(2) Változás helyeinek azonosítása a forráskódban
(3) Változás hatásanalízise, ami egy keresési feladat, nincs tutiság (hatékony és egyúttal biztonságos mód, vannak egyszerűbbek és szofisztikáltabb módszerek) rá, rejtett összefüggés is lehet sajnos. (A blogírói olvasat az, hogy dekomponálás és kicsi komponensekre helyességi bizonyítás egy alternatív életképes lehetőség)
(4) Változás elvégzése
(5) Változás propagálása
(6) Ellenörző és regressziós tesztelés
* Függőségelemzés lépései
(1) Entitásazonosítás
(2) Függőségi gráf konstruálása
(3) Függőségi gráf bejárása (programszeletelés=program slicing)
(4) Dinamikus futásidejű infók is gyűjthetők
* Léteznek (nagy) függőségi klaszterek, amiket jó lenne eliminálni tudni
* Hatásanalízis. Irányok:
(1) Felfele milyen hatásokat generál a tesztelés felé.
(2) Lefele: milyen érintett eljárások vannak a változás kapcsán
* Létezik a "tesztkönyvtárban"
(1) Tesztszelekció, csak azt kell tesztelni ami érintve van
(2) Tesztpriorizálás
* Az említett függőségi gráf általánosítható (nem csak programok körében müködik). Blogírói olvasat, ez az említett függőségi gráf/hálózat egy irányított gráf, hálózati analizist is megérdemelhet.
* Mozilla-projekt függőségi gráfjának futási ideje 113 perc, ami már hatékonynak mondható, innentől már az elemzés is gyors.
* Webkit-projekt
(1) 2.000.000 kódsor
(2) 90.000 eljárás
(3) 25.000 teszteset
(4) 113.000 revizió
(5) 33.000 revizió pár (romlott, ami aztán kijavult)
Irodalom:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
16.35 Gyimóthy Tibor, az MTA doktora: Karbantartási problémák millió sor felett.
* A szoftver öregszik, erodálódik.
* OK: folyamatos változás. Az blogíró adatbányász énje ehhez hozzáteszi, hogy az változás nélkül pusztán az adat is tönkremehet az idő során a szoftver/modell alatt. Ezért kell "change point detection", hogy behatárolható legyen az adatbányászati modell invaliddá válása, a legrövidebb időn belük, a veszteségek minimalizálása érdekében.
* Szoftverváltozás fajtái:
(1) Új dolgok
(2) Hibajavítások
* A változást kezelni, uralni kell, a kulcs hozzá a változásmanagement.
- A túl sok változás vége sokszor a szoftver kidobása, kiváltása mással.
- A változások uralásához egy (szellemes) könyvcím: Waltzing with Bears: Keringő a medvékkel.
* Változási gondjai:
(1) Indokolatlan kapcsolatok szaporodása
(2) Felesleges kód
(a) unreachable.
(b) dead code (ami már taposó akna lehet)
(3) Copy-paste arány romlása
* Változás költségét, időigényét nehéz becsülni.
* Symbian, 30 millió C++ kódsor, az indokolatlanul elszaporodott kapcsolatok miatt "halt meg".
* Ha nézünk egy kódsort, akkor ennek a kódsornak
(1) lefelé is van hatása mely kódsorokat érinti a változása, illetve
(2) adott kódsorok változása őt is érinthetik.
Lásd elöző prezi: mindkét irány fontos.
* Pointer tömbök szaftos problémákat tudnak generálni.
* Programszeletelés fajtái
(1) Statikus
(2) Dinamikus, könnyen gyorsan nagyon nagy lehet a kezelendő függőségi gráf
* Programszeletelés nehezen skálázható, 100.000 kódsor felett már gond van.
* METRIKÁK:
(1) Eljárás kódsorainak száma
(2) Komplexitás: hány if jellegű
(3) Kohézió
(4) Csatolási
(5) Bad smell @ copy-paste
(6) Kódolási szabálysértés
* Kérdés melyik metrika a legjobb (hiba)előrejelző? Kijött, hogy a CBO, vagyis a csatolási metrika. Az előadó elmondása szerint, aki most kapott Akadémiai díjat egyébként, óriási azonnali impactja volt ennek. Egy friss konferencia fő cikkei, keynote előadása is hivatkozta az eredményt és azonnali 300 független hivatkozást generált a tudományos kutató közösségben. Magyarán a csatolási metrikára nagyon érdemes odafigyelni. :o)))
* Konkrét projekt: Mozilla
(1) 3000 osztály
(2) 250.000 hiba.
Irodalom:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
2011. június 17., péntek
Mi predesztinál sikerre egy adatbányászprojektet?
.
Szakmai társblogon olvastam az imént a tárgybeli témában egy friss posztot.
A 7.sikerkritérium
* Én például jobban szoktam vágyni kevesebb, de nagyobb magyarázó erővel bíró attribútum(kombináci)okra. Az KDD-s Orange-verseny is rámutatott, hogy nagyon gyorsan el tudnak szabadulni a potenciális magyarázó-változók.
* Bár jóféle technikák vannak kezelésükre, mégis alapból hálás tud lenni, ha (1) kitöltöttek ("missing value"-mentesség) valamint (2) minél inkább mentesek a kiugró értékektől (outlier)az attribútumok. A nagyobb/jobb kitöltöttségért olykor nagyon meg kellhet küzdeni, az én tapasztalatom szerint
* Nagy öröm volt olvasni a "jól mérhető ROI"-ról. Részint mert nincs triviálisan a köztudatban (szerintem) a dolog nehézsége, másrészt az adatbányász komfortérzetét is nagyban javítja a korrekt mérés/visszamérés lehetősége.
* Az akcióképesség ilyetén hangsúlyozása engem elsőre megdöbbentett. Értem persze a felvetés jogosságát (amúgy se jó sose az öncélú l'art pour l'art játszadozás, nemcsak az adatbányászatban), de azért felveti a kérdést (pláne az eggyel korábbi "börtönfenyegetettséges" blogposztommal összhangban), hogy meddig terjed az adatbányász hatóköre. Számomra sokkal fontosabb idevágóan az adatbányász(-projekt) hitelessége, meg ennek hangsúlyozása, aminek alapján a menedzsment megbízik az eléje tálalt infókban majd dönt a további lépések mikéntjéről, másfelöl, hogy ne vállalati klikkharcok martaléka legyen egy értékes adatbányászati elemzés, azaz legyen motiváció a menedzsmentben az objektív mérlegelésre .
* Nagyon hasznos felvetés volt az eredeti blogposztban a "feketedoboz-effektus" mérlegelése. Én azt a példát hoznám, hogy a potenciális - kézzel leellenőrízendő - csalók listájára pénzügyi szektorban is el tudok képzelni feketedoboz-os adatbányász algoritmust, a minél teljesebbkörű azonosítás érdekében és valóban ügyfél-szegmentációra vagy guide-technológia esetén sokkal kevésbé "adható el" a feketedoboz.
* A legérdekesebb viszont kétségtelenül a poszt-címadó 7.sikerkritérium. ;)
- Így első belegondolásra és nagy százalékban a válaszidő és a pontosság többnyire egymás kárára tuningolható leginkább. Magyarán létezhet "optimum" a két szempontra.
- Van egy harmadik aspektusa a rövid válaszidőnek méghozzá a skálázhatóság. Ugyanis a gyakorlat az az, hogy úgy nőnek az adatok (az "égig"), hogy a már egyszer implementált megszokott válaszidőket implicite el is várjuk. Azaz durva példával élve kétszer akkora adattömegre elég legyen még egy gépet beállítani, hogy minden funkcionalitás tudjon a régi válaszidőkkel menni.
Tipikus példa lehet egy Netflix (rohamosan növekvő ügyfél- és filmbázissal).
- Én ha választhatok jobban szeretem a pontosságot választani, mint a rövidebb válaszidőt, de el kell fogadni, hogy az "idő pénz". De ekkor is felhasználóként / ügyfélként szeretném látni, hogy a rövidebb válaszidő tényleg nagyobb profitot hoz (nem öncélú a rövidebb válaszidő a "látványért" magáért)
Update
Talán idevág a fociból vett analógia, hogy az edzők 2-3 évre szeretnek tervezni úgymond csapatot építeni, de elég lehet 1-2 vereeég a bajnokságban, hogy aztán mégis iziben repüljön az edző.
Valóban nehéz egyeztetni a folyamatos azonali sikeréhséget a hosszabbtávú stratégiai tervszerűséggel.
Szakmai társblogon olvastam az imént a tárgybeli témában egy friss posztot.
A 7.sikerkritérium
"Egy népszerű ökölszabály alapján egy jó adatbányászati projektnek hat sikerkritériuma van: legyenA téma nagyon jó (a hét mesterlövészre utalás különösen szellemes telitalálat), a poszt helyből és azonnal hozzászólásra inspirált, plusz van akkora fontossága/jelentősége a kiinduló felvetésnek, hogy "replikáljam" ide is. Pláne, hogy egy blogposztban nem lehet mindent és teljeskörűen leírni, biztos lehet kiegészítéseket tenni egyéni megfontolásokból... ;)
(1) sok sorból álló
(2) attribútumokban gazdag adathalmazunk, melyben legyenek az adatok egyrészt
(3) tiszták, másrészt
(4) jól reprezentálják a prediktív modellekben körüljárt eseményt. Ezen túlmenően fontos, hogy a projektre
(5) jól mérhető legyen a ROI, illetve a vállalati környezet olyan legyen, hogy a kapott eredmények alapján a menedzsment ténylegesen változtathasson a korábbi folyamatokon, azaz
(6) akcióképes legyen a vizsgált tématerület.
(7) rövid válaszidő"
* Én például jobban szoktam vágyni kevesebb, de nagyobb magyarázó erővel bíró attribútum(kombináci)okra. Az KDD-s Orange-verseny is rámutatott, hogy nagyon gyorsan el tudnak szabadulni a potenciális magyarázó-változók.
* Bár jóféle technikák vannak kezelésükre, mégis alapból hálás tud lenni, ha (1) kitöltöttek ("missing value"-mentesség) valamint (2) minél inkább mentesek a kiugró értékektől (outlier)az attribútumok. A nagyobb/jobb kitöltöttségért olykor nagyon meg kellhet küzdeni, az én tapasztalatom szerint
* Nagy öröm volt olvasni a "jól mérhető ROI"-ról. Részint mert nincs triviálisan a köztudatban (szerintem) a dolog nehézsége, másrészt az adatbányász komfortérzetét is nagyban javítja a korrekt mérés/visszamérés lehetősége.
* Az akcióképesség ilyetén hangsúlyozása engem elsőre megdöbbentett. Értem persze a felvetés jogosságát (amúgy se jó sose az öncélú l'art pour l'art játszadozás, nemcsak az adatbányászatban), de azért felveti a kérdést (pláne az eggyel korábbi "börtönfenyegetettséges" blogposztommal összhangban), hogy meddig terjed az adatbányász hatóköre. Számomra sokkal fontosabb idevágóan az adatbányász(-projekt) hitelessége, meg ennek hangsúlyozása, aminek alapján a menedzsment megbízik az eléje tálalt infókban majd dönt a további lépések mikéntjéről, másfelöl, hogy ne vállalati klikkharcok martaléka legyen egy értékes adatbányászati elemzés, azaz legyen motiváció a menedzsmentben az objektív mérlegelésre .
* Nagyon hasznos felvetés volt az eredeti blogposztban a "feketedoboz-effektus" mérlegelése. Én azt a példát hoznám, hogy a potenciális - kézzel leellenőrízendő - csalók listájára pénzügyi szektorban is el tudok képzelni feketedoboz-os adatbányász algoritmust, a minél teljesebbkörű azonosítás érdekében és valóban ügyfél-szegmentációra vagy guide-technológia esetén sokkal kevésbé "adható el" a feketedoboz.
* A legérdekesebb viszont kétségtelenül a poszt-címadó 7.sikerkritérium. ;)
- Így első belegondolásra és nagy százalékban a válaszidő és a pontosság többnyire egymás kárára tuningolható leginkább. Magyarán létezhet "optimum" a két szempontra.
- Van egy harmadik aspektusa a rövid válaszidőnek méghozzá a skálázhatóság. Ugyanis a gyakorlat az az, hogy úgy nőnek az adatok (az "égig"), hogy a már egyszer implementált megszokott válaszidőket implicite el is várjuk. Azaz durva példával élve kétszer akkora adattömegre elég legyen még egy gépet beállítani, hogy minden funkcionalitás tudjon a régi válaszidőkkel menni.
Tipikus példa lehet egy Netflix (rohamosan növekvő ügyfél- és filmbázissal).
- Én ha választhatok jobban szeretem a pontosságot választani, mint a rövidebb válaszidőt, de el kell fogadni, hogy az "idő pénz". De ekkor is felhasználóként / ügyfélként szeretném látni, hogy a rövidebb válaszidő tényleg nagyobb profitot hoz (nem öncélú a rövidebb válaszidő a "látványért" magáért)
Update
Az eredeti blogposztot író Gáspár-Papanek Csaba kommentje:Nyilván nagyobb az esély a sikerre, ha hamarabb jelentkezik a(z) (esélyes) pozitív visszajelzés.
Lehet, hogy nem írtam le teljesen egyértelműen, a válaszidő alatt nem a modellezés futási idejét értem, hanem azt, hogy egy modell való életben történő használatáról milyen hamar kap visszajelzést maga a megrendelő. Szóval ez nem az adatbányászati folyamat belsejében megjelenő technikák, hanem magának a feladatnak a tulajdonsága.
Tényleg nem akartam végtelen hosszú blogbejegyzést írni, ezért talán nem is emeltem ki eléggé, hogy itt a sikerkritériumoka valójában a környezetről szólnak: mikor lesz sikeres egy adatbányászati projekt, milyen feladatok alkalmasak arra, hogy sikeres projektet csináljunk belőlük.
Talán idevág a fociból vett analógia, hogy az edzők 2-3 évre szeretnek tervezni úgymond csapatot építeni, de elég lehet 1-2 vereeég a bajnokságban, hogy aztán mégis iziben repüljön az edző.
Valóban nehéz egyeztetni a folyamatos azonali sikeréhséget a hosszabbtávú stratégiai tervszerűséggel.
2011. május 26., csütörtök
Prediktálás börtönfenyegetettség árnyékában?
.
Új minőség az adatbányászat horizontján?
Nem jósolták meg a földrengést, perlik őket
(1) Ilyen megbízhatóak mára az adatbányász/prediktálási protokollok, hogy börtönnel is számonkérhetők?
(2) Attól még hogy
(a) egy ember
(b) magas százalékos valószínűséggel
lát egy bekövetkező földrengést onnan még nem hosszú az út egy "kicsit"?
(Hogy szakmai konszenzus legyen, továbbá a döntéshozók is megfelelő lépések útjára lépjenek)
Nekem analógiaként a 2008-as pénzügyi válság jut eszembe. Egészen biztosan voltak kockázatelemzők, akik látták akkor is a bajt elemzéseik konklúziójaként, a válság mégis nagyon durván ráomlott az USÁ-ra, meg aztán a világra.
Adatbányászat és etika témához meg egy újabb érdekes adalék lehet a sztori: az én érzékelésemben nagyon hosszúnak látszik még az út, amikor az adatbányászaton kívüli közvéleményben kialakul a helyes arányérzék: mit lehet várni az adatbányászattól, milyen követelmények/elvárások a reálisak. Pro és kontra.
UPDATE-1
Befutott egy érdekes és inspiráló komment, köszönet érte. :o)
Az adatbányászatnak van tárgy-(domain-), jelenesetben geológusi/szeizmológusi-, függése. Amihez én nem értek. Rögtön nem tudnék például arra a kérdésre válaszolni, hogy a földrengés-előrejelzés analóg-e az időjárás előrejelzéssel a tekintetben, hogy minél közelebbi időpontra történik az előrejelzés, annál pontosabb. Időjárásnál így van tudtommal, földrengésnél egyáltalán nem biztos. A hírek szerint a minapi japán földrengés-előrejelzés is vetett fel komoly szakmai kérdéseket.
Így van ahogy mondod, a nagy kérdés az az, hogy egy előrejelzés, milyen alapon / implikációk révén, milyen tevékenységláncolatot indítson be. Az előrejelzés információtömege elért-e kellő kritikus tömeget, mekkora hordereje van a tevékenységláncolatnak stb. (adott esetben lehet "farkast kiáltani" sokszor, ahogy esernyő is sokszor van nálunk, miközben süt a nap, mert nincs nagy rezsije. Míg a pénzügyi válság elkerüléséhez olyan döntés- és tevékenységsorozatra lett volna szükség, amire esélytelen volt az emberiség)
Az idevágó paradoxont én úgy szoktam megfogalmazni, hogy nem elég előrejelezni, az előrejelzést alá kell tudni támasztani, hitelt kell tudni neki adni, akkor ér valamit. Az hogy az éterbe millióan beleböfögnek valamit és aztán mindig valakinek/másnak igaza van (kitalálhatatlanul); egy adott (teszemazt közgazdasági) előrejelzési kérdésben, ez így ebben a formában használhatatlan zaj.
A dolgot megfordítva: ha egy előrejelzőt "fizetnek", akkor börtönnel kell jótállnia az előrejelzéseiért?
Deja vu, nagyon fontos, ráadásul hazai analógia a tárgyban, amit ennek a fenti kommentnek köszönhetek. amikor volt a pár évvel ezelötti (szél)viharos, fakidöntéses tüzijáték, emberhalállal (Budapesten).
Kit akartak felelősségre vonni? A meteorológiai előrejelzőt, avagy a politikust, aki engedte a tüzijátékot?Meddig terjed az előrejelző felelőssége? Előrejelzés pontosságáig? Döntéshozó meggyőzéséig? Egy érdekes idevágó gondolatmenet a témában, jogi szemszögből:
A budapesti tűzijáték tragédia és a vezetői felelősség kérdése
Az árvízvédelem, védekező mechanizmusainak lépései fontosak valóban a tárgyunk szempontjából is. "Milyen előrejelzés alapján, mi történjen?"
Új minőség az adatbányászat horizontján?
Nem jósolták meg a földrengést, perlik őket
"Hét olasz tudós és szakértő ellen gondatlanságból elkövetett emberölés miatt emeltek vádat szerdán, mert nem figyelmeztettek a háromszáz halálos áldozatot követelő 2009-es földrengésre. A védelem visszautasítja a vádat, mondván, lehetetlenség megjósolni a földrengéseket."Azért ez felvethet pár érdekes kérdést még laikusokban is.
(1) Ilyen megbízhatóak mára az adatbányász/prediktálási protokollok, hogy börtönnel is számonkérhetők?
(2) Attól még hogy
(a) egy ember
(b) magas százalékos valószínűséggel
lát egy bekövetkező földrengést onnan még nem hosszú az út egy "kicsit"?
(Hogy szakmai konszenzus legyen, továbbá a döntéshozók is megfelelő lépések útjára lépjenek)
Nekem analógiaként a 2008-as pénzügyi válság jut eszembe. Egészen biztosan voltak kockázatelemzők, akik látták akkor is a bajt elemzéseik konklúziójaként, a válság mégis nagyon durván ráomlott az USÁ-ra, meg aztán a világra.
Adatbányászat és etika témához meg egy újabb érdekes adalék lehet a sztori: az én érzékelésemben nagyon hosszúnak látszik még az út, amikor az adatbányászaton kívüli közvéleményben kialakul a helyes arányérzék: mit lehet várni az adatbányászattól, milyen követelmények/elvárások a reálisak. Pro és kontra.
UPDATE-1
Befutott egy érdekes és inspiráló komment, köszönet érte. :o)
* Nem tudom, ezek az előrejelzések mennyiben adatbányász feladatok?Én úgy gondolom, hogy ami nagy tömegű és/vagy historikus adatokon alapuló, matematikai algoritmusokkal kiszámolt előrejelzés az minden esetben adatbányászfeladat: nevében is benne van, nagy adattömegből kell kibányászni értékes kevés ("lesz-e földrengés: igen/nem") információt.
* A konkrét eset sem teljesen egyértelmű. Ugyanis azt írja, hogy voltak akkoriban kisebb rengések, és abból talán tudtak volna következtetni... Persze itt felmerül, hogy minden ilyen esetben ezentúl kilakoltatják a települést, és nem jön be az előrejelzés, akkor egy idő után hiteltelenné válhat, és már maga a lakosság lenne, akik nem hinnének...
* meg aztán ahogy olvasom, őket ezért fizették :))) "nagy veszélyek bizottsága" :)))
* Ami ennek kapcsán még az eszembe jutott, nálunk az árvízveszély. Épp nemrégiben olvastam, hogy itthon is akarnak valami katasztrófavédelmi tanfolyamot, amin kötelező lenne a részvétel az állampolgároknak, és azt tanítanák, hogyan kell szervezkedni árvíz esetén....
Az adatbányászatnak van tárgy-(domain-), jelenesetben geológusi/szeizmológusi-, függése. Amihez én nem értek. Rögtön nem tudnék például arra a kérdésre válaszolni, hogy a földrengés-előrejelzés analóg-e az időjárás előrejelzéssel a tekintetben, hogy minél közelebbi időpontra történik az előrejelzés, annál pontosabb. Időjárásnál így van tudtommal, földrengésnél egyáltalán nem biztos. A hírek szerint a minapi japán földrengés-előrejelzés is vetett fel komoly szakmai kérdéseket.
Így van ahogy mondod, a nagy kérdés az az, hogy egy előrejelzés, milyen alapon / implikációk révén, milyen tevékenységláncolatot indítson be. Az előrejelzés információtömege elért-e kellő kritikus tömeget, mekkora hordereje van a tevékenységláncolatnak stb. (adott esetben lehet "farkast kiáltani" sokszor, ahogy esernyő is sokszor van nálunk, miközben süt a nap, mert nincs nagy rezsije. Míg a pénzügyi válság elkerüléséhez olyan döntés- és tevékenységsorozatra lett volna szükség, amire esélytelen volt az emberiség)
Az idevágó paradoxont én úgy szoktam megfogalmazni, hogy nem elég előrejelezni, az előrejelzést alá kell tudni támasztani, hitelt kell tudni neki adni, akkor ér valamit. Az hogy az éterbe millióan beleböfögnek valamit és aztán mindig valakinek/másnak igaza van (kitalálhatatlanul); egy adott (teszemazt közgazdasági) előrejelzési kérdésben, ez így ebben a formában használhatatlan zaj.
A dolgot megfordítva: ha egy előrejelzőt "fizetnek", akkor börtönnel kell jótállnia az előrejelzéseiért?
Deja vu, nagyon fontos, ráadásul hazai analógia a tárgyban, amit ennek a fenti kommentnek köszönhetek. amikor volt a pár évvel ezelötti (szél)viharos, fakidöntéses tüzijáték, emberhalállal (Budapesten).
Kit akartak felelősségre vonni? A meteorológiai előrejelzőt, avagy a politikust, aki engedte a tüzijátékot?Meddig terjed az előrejelző felelőssége? Előrejelzés pontosságáig? Döntéshozó meggyőzéséig? Egy érdekes idevágó gondolatmenet a témában, jogi szemszögből:
A budapesti tűzijáték tragédia és a vezetői felelősség kérdése
Az árvízvédelem, védekező mechanizmusainak lépései fontosak valóban a tárgyunk szempontjából is. "Milyen előrejelzés alapján, mi történjen?"
2011. február 2., szerda
Beszéd, mint a sikeres párkapcsolat prediktora?
.
Sikerült egy "igazgyöngyöt" találnom a hatalmas indexes napi forgatagban, mondhatni "zajban". :o)
Mire nem jó (még) a (szöveg)bányászat. :o) Ha már itt a blogon oly hangsúlyos volt többször is a szerelem meg társkeresés jövőjének fürkészése, nemcsak és főleg nem teoretice, hanem konkrét egyedi párkapcsolatok vonatkozásában, matematikai/numerátori alapokon, akkor röviden szót ejtek erről is.
A beszédstílus a jó párkapcsolat alapja
A dolgot ugye nem tudom leellenőrizni, maximum csak fejben végiggondolni. És részben pozitív gondolkodásomból fakadóan, részben tapasztalatom alapján azt kell mondjam: erősen el tudom képzelni, mint reális lehetőséget.
* A kutatásnak értelme is van, lásd csökkenő házasodási és gyerekvállalási kedv (fejlett nyugaton).
* Nem "brittudósi" hülyeség, már első olvasatban sem. Például mert egybevág a józan paraszti ész tapasztalatával.
* Ha én állítanék fel csapatot társkeresési honlap alapításához, én is nagyon támaszkodnék pszichológusokra. Már az óriási segítség lehet, hogy mik lehetnek a releváns felteendő kérdések.
* Négyszeres szorzó az már nagyon komolyan hangzik (ha valós). Ez előrevetíti minden adatbányász örök álmát, a talált prediktor erős magyarázóerejét.
* A említett indikátor tipikusan nem az a prediktor, amit az emberek oly könnyen befolyásolni tudnak. De még ha igen, akkor sem látszik, hogy milyen irány lenne jó stratégiailag/taktikailag. Azaz a prediktor eléggé ígéretes módon őszintének tűnik, mint a hormonok is, dr. Helen Fishernél, nehéz vele hazudni. ;) Ez az én olvasatomban talán a legkritikusabb pont, bármiféle algoritmusokkal támogatott társkeresésnél.
* Egy dolog látszik csak problémásnak számomra: hogy lehet számokkal mérhetővé tenni a beszédmodort.
Társkeresés és adatbányászat témát érintő blogpostjaim:
Társkeresés adatbányász alapokon
Társkeresés - Numerátorok
Dr. Helen Fisher mint a szerelem "brittudósa"?
Dr. Helen Fisher kérdőíve társkereséshez
Dr. Helen Fisher - Zárszó
Társkeresés adatbányászati támogatással
Beszéd, mint a sikeres párkapcsolat prediktora?
COMMENT:COM: "Házasság első látásra"
Sikerült egy "igazgyöngyöt" találnom a hatalmas indexes napi forgatagban, mondhatni "zajban". :o)
Mire nem jó (még) a (szöveg)bányászat. :o) Ha már itt a blogon oly hangsúlyos volt többször is a szerelem meg társkeresés jövőjének fürkészése, nemcsak és főleg nem teoretice, hanem konkrét egyedi párkapcsolatok vonatkozásában, matematikai/numerátori alapokon, akkor röviden szót ejtek erről is.
A beszédstílus a jó párkapcsolat alapja
Az érintettek beszédmódja alapján nagy biztonsággal megjósolható egy párkapcsolat jövője, állítják az új módszert kidolgozó pszichológusok.
Azok a párok, akiknek beszédje szinkronban van, négyszer nagyobb valószínűséggel szeretnének máskor is találkozni, mint azok, akik nem egy nyelvet beszéltek, derült ki a Texasi Egyetemen diákok bevonásával végzett vizsgálatból. A kutatók a szavak mondatokká fűzéséhez nélkülözhetetlen funkcionális szavakra koncentráltak.
A kutatás első fázisában 40 pár gyors, mindössze négyperces randevút bonyolított le, és beszélgetésüket rögzítették. A második fázisban már rendszeresen találkozgató párok hétköznapi beszélgetéseit és üzenetváltásait vizsgálták 10 napon át, és a kutatók arra a következtetésre jutottak, hogy a beszédmodor és az írás stílusa jó indikátor lehet arra nézve, hogy sikeres lesz-e vagy sem egy kapcsolat.
A dolgot ugye nem tudom leellenőrizni, maximum csak fejben végiggondolni. És részben pozitív gondolkodásomból fakadóan, részben tapasztalatom alapján azt kell mondjam: erősen el tudom képzelni, mint reális lehetőséget.
* A kutatásnak értelme is van, lásd csökkenő házasodási és gyerekvállalási kedv (fejlett nyugaton).
* Nem "brittudósi" hülyeség, már első olvasatban sem. Például mert egybevág a józan paraszti ész tapasztalatával.
* Ha én állítanék fel csapatot társkeresési honlap alapításához, én is nagyon támaszkodnék pszichológusokra. Már az óriási segítség lehet, hogy mik lehetnek a releváns felteendő kérdések.
* Négyszeres szorzó az már nagyon komolyan hangzik (ha valós). Ez előrevetíti minden adatbányász örök álmát, a talált prediktor erős magyarázóerejét.
* A említett indikátor tipikusan nem az a prediktor, amit az emberek oly könnyen befolyásolni tudnak. De még ha igen, akkor sem látszik, hogy milyen irány lenne jó stratégiailag/taktikailag. Azaz a prediktor eléggé ígéretes módon őszintének tűnik, mint a hormonok is, dr. Helen Fishernél, nehéz vele hazudni. ;) Ez az én olvasatomban talán a legkritikusabb pont, bármiféle algoritmusokkal támogatott társkeresésnél.
* Egy dolog látszik csak problémásnak számomra: hogy lehet számokkal mérhetővé tenni a beszédmodort.
Társkeresés és adatbányászat témát érintő blogpostjaim:
Társkeresés adatbányász alapokon
Társkeresés - Numerátorok
Dr. Helen Fisher mint a szerelem "brittudósa"?
Dr. Helen Fisher kérdőíve társkereséshez
Dr. Helen Fisher - Zárszó
Társkeresés adatbányászati támogatással
Beszéd, mint a sikeres párkapcsolat prediktora?
COMMENT:COM: "Házasság első látásra"
2011. január 18., kedd
Egy SQL-verseny elvi és gyakorlati problémái
.
Ha valaki rákeres SQL kulcsszóval milyen állásokat hirdetnek ilyen tárgyú site-okon (Profession, Jobmonitor, stb.), akkor bármely, akár "punnyadásos", időpillanatban is egyfelöl jó eséllyel fog találni több nyitott poziciót, másfelöl könnyen valószínűsítheti, hogy "trendi" és ígéretes szakma általános követelménye, aminek következtében, megint csak könnyen valószínűsíthetően, jó sok jelölt pályázhat meg egy-egy állást, ahol SQL-lel kell dolgozni.
Ilyen esetekben munkáltató oldalról felmerül az (1) alkalmasság(előszűrés) illetve a (2) legjobb jelölt (versenyszerű) kiválasztásának triviális igénye. Kérdés van-e - és ha igen, akkor mennyire jó - módszertan ilyen jellegű kérdések megválaszolására? Könnyű-e annyira az SQL-tudás mérése, mint a nyelvtudásé (ahol pár perc diskurzus után megbízhatóan érzékelhető, ki mennyire jó nyelvből -> feltéve persze, hogy a munkaadó bír releváns nyelvtudással, ugye).
Nyelvtudás témájából is blogposzt-hegyeket lehetne írni (itt egy friss aktuális példa: Miért kérnek idegen nyelveket?), de most fókuszáljunk csak az SQL-tudásra és mérésére.
Első nehézség, mik a legfontosabb ismérvei egy jó SQL-esnek. Biztosan vitatható lesz amit mondok, én úgy vélem, hogy az alábbi öt dolog:
(1) Megbízhatóság, hogy egy megírt SQL-parancs tényleg azt csinálja, amit a fejlesztője akart. Komoly, aggregált, nagy futási idejű SQL-lekérdezést nem nagyon lehet sokszor futtatni (adott esetben még egy rossz futást lelőni is probléma lehet), és debugolni sem olyan könnyű, mint egy 3GL kódot.A dolog hatványozottan fontos tud lenni meglévő kódok módosítása esetén. Egy-egy rontáson nagyon sok múlhat, miközben a tesztelési költségek behatároltak, pláne nagyon nagy adatbázisoknál.
(2) Gyorsaság: ki kell tudni használni a deklaratív programozás fejlesztési előnyeit.Pláne figyelembevéve az RDBMS-ek magas alap és támogatási bekerülési költségeit, amik az SQL fejlesztési és végrehajtási előnyeit biztosítják.
(3) Komplex - például inline view-s - sql-ek olvasási, írási és módosítási készsége
(4) Logikai műveletek minél hibamentesebb értelmezése. Magam részéről nem pártolom az összetett logikai kifejezések eröltetését, a hibázási valószínűség robbanásszerű növekedésének lehetősége miatt, de ettől még mások preferálhatják és olvasni kell tudni az ő SQL-jeiket.
(5) Képes legyen kölcsönös kétirányú leképezésre/változtatásra (agyban) a fejlesztő, az SQL és a resultset között. Elismerem ez így nagyon homályos és képlékeny, ha analógiát akarnék keresni, akkor valami olyasmire gondolok, hogy a programozó sem soronként "nulláról" ír programkódot illetve képesnek kell lennie a gép "fejével" gondolkodnia. SQL-nél "kevesebb" karakter kell ugyan a kódoláshoz, viszont a resultset "elképzelése" szerintem nélkülözhetetlen követelmény, a hatékony SQL-parancs megfogalmazásához (sőt mindezt végrehajtási aspektusokkal vegyítve)
Magam részéről - egészen a mai napig - úgy gondoltam, hogy, ha nekem kéne valaki jó SQL-est kiválasztanom több emberből, akkor én például a magyar nyelvű szakmai SQL-levlistáról választanék egy-egy problémát és arról beszélgetnék a jelöltekkel. (Ezt előzetesen jelezném is feléjük.) A kiválasztott probléma lehet elméleti is, gyakorlat is (hibakeresés, sql-módosítás, resultsetes sql elemzés, stb.)
Ily módon,
(1) legalább valamennyire "zárt" a tudásbázis (még ha zajos is).
(2) de kellően "nyitott" is (hiszen régóta van sokezer hozzászólás, feladat, és így nehéz - végeredményt befolyásolóan - célraorientáltan készülni)
(3) aki a levlistán van (erőforrást fektet olvasásába/írásába), annak legyen ennyi "természetes" előnye
(4) a jelölteket felmérő is "(meg)dolgozik", hiszen közreműködik a kiválasztásban: persze nézőpont kérdése, hogy ez mennyire előny -> az én szememben az.
(5) végeredmény konvergálhat a kiválasztás jóságához, például azzal is, hogy a való életből választódik probléma.
Na, de mi a helyzet, ha
(1) több tíz potenciális jelentkezőre kéne minél megbízhatóbban sorrendet alkotni
(2) papír-ceruza alapon kéne dolgozni
(3) nem klasszikus alkalmassági-/vizsgamegfelelés, hanem versenyszerű alapokon való kiválasztás a cél?
Amióta egyre intenzívebben mozgok adatbányász világban, azóta ternmészetes módon izgatnak a verseny-aspektusok. Na ez most ezennel begyűrűzött az SQL-világba is. :o) Annyira azért nem tartom triviálisnak az SQL-versenyzést, de jó játék lehet belegondolni, hogyan lenne érdemes ilyesmit lebonyolítani.
Lehetséges felvetések/problémák egy egyáltalán nem futurisztikus SQL-verseny kapcsán:
* Kezdem egy elméleti (definiciós) kérdéskörrel: létezik SQL-re "rátermettség"? Aki jó 3GL-es, abból feltétlen "implikálódik" jó SQL-ezés képessége? Stb.
* Legyen OCA/OCP típusú (angol) feleletválasztós teszt a versenyzés alapja? Ez jó lehet disztingválásra, kiválasztásra? Mennyire él egy angol nyelvvizsga feleletválasztós tesztjével való analógia (állítólag az a mondás és ezért preferálják, hogy a jobb angolos jobban tölti ki őket, az én saját tapasztalatom, hogy az ilyen teszteket jobban töltöm ki, mint amennyire jó angolosnak tartom magamat. Avagy a ceruza-papír alapú és/vagy felelet-választós módi leginkább csak alkalmassági előszűrésre alkalmas, versenyzésre nem igazán?
* A győztes jósága mennyiben korrelál az kiválasztás jóságával (elsőfajú hibázás lehetőségei)?
* Létezik-e (és mennyire) olyan SQL-teszt, amit ha valaki nem kellően jól tölt ki (és bukik), attól még érdemes lenne alkalmazni (másodfajú hibázás lehetőségei)?
* Mennyire legyen "nyitott" az anyag? Lehessen rá készülni valahogy előzetesen? Erről célszerű-e bármit egyeztetni a jelöltekkel?
* Mennyire fontos a (help/internet nélküli) precíz szintaxis szempontja versenyzésnél? Ha az a feladat, hogy írjon be valaki például natív dinamikus ciklusos select feldolgozást pár sorban, abban "lehet-e" hibát ejteni? Lehet-e, jó sql-es, aki helpből másolgat átírásra kódot?
* Az Oracle pszeudó-, sor- és analitikus függvényei, hierarchikus lekérdezései mennyire erős/ütős szempontok képességmérésben? Egyáltalán mi a helyzet az ANSI szabvány vs. Oracle-specifikumokat illetően?
* Sql-performancia? Hintek?
* Sql vs PlSql? Ha PlSql (3GL) is, akkor ott azért már komoly versenyfeladatok képzelhetők el, kérdés persze, hogy az RDBMS-világtól mennyire elszakadóan.
* Meg lehetne-e tölteni egy könyvet jó versenyfeladatokkal?
Na most itt abbahagyom a további kérdés-kigenerálást. :o)
UPDATE-1.
Némileg revideálnom szükséges álláspontomat, azután, hogy tegnap este, nulla rákészülés után, éles körülmények között kitöltöttem otthon, egy gyári, hivatalos, angol nyelvű 1Z0-047 kódú Oracle SQL Expert tesztet. Egy ilyen teszt során 70 kérdésre kell válaszolni, két óra leforgása alatt. 60%-nyi jó válasz után sikeres a vizsga. Nem síma feleletválasztós volt a teszt (mint nyelvvizsga teszteknél), mert van, hogy több jó megoldás is lehetséges volt egy-egy kérdésnél (viszont meglepő módon előre jelzik a tényt is, sőt, hogy hány jó választ várnak el az adott kérdésnél).A két óra is bőven elegendő volt (sőt szerintem túlméretezett), mégha eléggé meg is terhelő a teszt-kitöltés maga.
Parádés módon nagyszerű (plusz élvezetes) volt az a teszt, amit kitöltöttem. 100%-ban olyan dolgokra kérdezett rá, amit szerintem is tudnia kell egy jó SQL-esnek, egyetlen "aljasság" és/vagy vitatható dolog nem volt a tesztkérdések között (nem úgy, mint nyelvvizsga teszteknél). Rendkívüli módon kiváló "vérfrissítésre" is alkalmas, jó tréningnek tartom ezt a fajta tesztet.
Nagyon tetszett a tesztben az is, hogy rengeteg kérdés volt SQL-olvasásra. Vagyis adtak adatmodellt és/vagy SQL create&insert scripteket, és az ezekre megírt közel nem triviális SQL-eket kellett elemezni a kérdés megválaszolásához (alapvetően ANSI SQL-eseket). Én az ilyen típusú feladatokat tartom a legegészségesebbnek.
A teszt alkalmas lehet a szakmai angol tesztelésére is (esetleg szükség esetén némileg tuningolva, mert a teszt angolja tényleg nagyon egyszerű volt). Továbbá szerintem megoldja azt a problémát is, hogy feltétlen kelljen papír-ceruza alapon kódokat írni (help nélkül).A teszt-kiértékelés is tudhat menni könnyedén.
Szóval nem biztos, hogy fel kell találni a meleg vizet még egy versenyszerű kiválasztáshoz sem. Ilyen tesztekből bárki össze tud állítani magának egy jó tesztet saját használatra,sőt bővítheti feladatbankját saját SQL-olvasási/-módosítási példákkal. Esetleg PlSql-tesztekből is át lehet emelni példákat szükség esetére. Kiváncsi lennék hányan élnek ilyen módival.
Nekem mindig is voltak kifogásaim egy OCP-vizsgával, leginkább olyan téren, hogy szükséges volt hozzájuk valami nem éppen jó, olcsó és/vagy hasznos Oracle eszköz(ök) precíz tudása. Márpedig abból, hogy az Oracle jó és sikeres RDBMS-t tudott fejleszteni, nem következik, hogy jó és sikeres front-end eszközöket is tud(ott). Sőt. Ezt a fajta Oracle-specifikumot (és eröltetését) én perdöntő módon inkorrektnek tartom, ami alkalmas lehet súlyos aránytévesztésre/megtévesztésére is a vizsgára befizetők, valamint a jóhiszemű potenciális munkadók körében. Na ez a mostani Oracle SQL-Expert teszt hálistennek visszaadott némi jó szájízt.
UPDATE-2.
Hali,
Itt egy kilenc feladatos, Papír-ceruzás SQL-teszt. Kidolgozási idő szigorúan egy óra. Emlékezetből írom, nem kizárt, hogy hibázok. Ezért előre is elnézést kérek.
Ügyfél(ügyfél_id,ügyfél_név)
Számla(ügyfél_id,számla_id,egyenleg_dátum,számla_egyenleg)
Tranzakció(tranzakció_id,ügyfél_id,számla_id,tranzakció_ideje,tranzakció_összeg)
Ügyfélkapcsolat(id,ügyfél_id1,ügyfél_id2)
1. Listázandók az inaktív ügyfelek, akik az elmúlt 30 napban nem tranzaktáltak.
2. Az ügyfeleknek hány számlájuk van?
3. Az aktuális számlaegyenlegekből meghatározandó a 30 nappal ezelötti számlaegyenlegek, a tranzakciós adatok révén.
4. Itt volt egy 30 napi forgalmi adat alapján valami kiválasztás. Egyszerű volt, de már nem emlékszem rá vissza pontosan. :o(
5. Akkor nem tekinthető sikeresnek egy napi zárás, ha a tranzakció táblán a napi összesítés nem fut ki nullára. Mely napokon nem volt sikeres zárás?
6. Listázandók azon ügyfelek, akiknél van legalább egy 45 napos intervallum, amikor több mint 100.000 fórint jóváírás érkezett.
7. Egy ügyfél közvetlenül és közvetetten is kapcsolódhat egy másik ügyfélhez (egy másik ügyfélen keresztül). A tranzitivitási lánc tetszőleges hosszú lehet. Egy-egy ügyfélnek hány (közvetlen és közvetett) kapcsolata van?
8. Készítendő egy output, ahol ügyfél_id-nként az első, második, harmadik számlához tartozó pozitív előjelű tranzakció összegek végösszege jelenik meg, 2010.11.01 utáni tranzakciókra.
9. Listázandók azon ügyfelek, akiknek legalább 7 negatív összegű tranzakciója van 2010.11.01-től kezdve, ezen tranzakciók átlaga kell ügyfelenként, úgy, hogy a három legkisebb és legnagyobb összegű tranzakció nem számolódik bele az átlagba.
Azt gondolom ez egy igazi emberkínzós "teszt"(?), mind megírni, mind kijavítani (pláne nagyüzemben). Főleg annak ismeretében, hogy az én kézírásom csúnyább, mint a világ legcsúnyább nője, a néhai Zámbó Jimmy....
;)
Az egy óra is elég kevés érzésem szerint, én legalábbis kihasználtam a rendelkezésre álló időt.
A feladatok viszont zseniálisak, szvsz. Ezért is osztom meg őket, tanulságképpen.
UPDATE-3.
Szerintem a legfontosabb azonosítani, hogy szakmailag mitől jó egy SQL-es, ahogy ezt fentebb is megkíséreltem. A további kérdésekre az én válaszkezdeményeim:
* Szvsz, aki (ösztönösen) jó 3GL-ben, nem feltétlen jó SQL-ben is. De van komoly esélye jónak lennie benne, leginkább avval, ha sikerül érdemben ráéreznie az ízére. Sokkal nehezebbnek érzem az átmenetet 3GL és SQL között, mint két 3GL nyelv között. Valamint én megkülönböztetek OLTP-s és adattárházas (analitikus) SQL-est is. Az elöbbi lényegesebben könnyebb műfaj, szvsz.
* Immáron azt vélem, hogy a feleletválasztós teszt csomó előnyén túl, a versenyszerű kiválasztásra is alkalmas (legalkalmasabb?). Főleg, hogy a kiválasztásnál egyéb szempontok is vannak, más véleményekkel összhangban. Azt nehezen tudom elképzelni, hogy aki jól tud olvasni/módosítani kemény komplex SQL-eket, az ne tudna írni is jól SQL-eket. (Nyelvnél ez például távolról sincs így, szvsz). De befolyásolható vagyok a kérdésben. ;)
* Az elsőfajú hibázást sokkal valószínűbbnek tartom mint a másodfajú hibázást. Analógia: szerelembe könnyebb esni, mint komoly, tartós, boldog házasságba lépni. Illetve, ha valaki első körben ellenszenves, nehéz lesz lesz másodjára szerelemre kiválasztani, még ha jó sok hálivúdi film is szól ilyesmiről. ;)
* Én pártolom, hogy minél zártabb legyen az anyag, amiről szólna a verseny (előzetes informálással), de nyilván nem publikus tesztsor alapján versenyeztetnék.
* Én nem vagyok híve a precíz szintaxis számonkérésének (tőlem még a hierarchikus query vázát is lehet helpből másolni, az analitikus függvényekről nem is beszélve). Például mert hasznosabb agyi tevékenységek elöl veheti el az erőforrást. De el tudom fogadni az ellenvéleményt is.
* Tetszik nem tetszik, az ANSI-szabvány "tudása" nehezen megkerülhető. Olvasni mindenképpen kell tudni ilyen SQL-eket, szvsz.
* Oracle-specifikumok nálam opcionális kategória. Szerintem fontosabbak az eddigi szempontok, illetve ezek a specifikumok menetközben felszedhetők, külön tanfolyam nélkül is. De el tudom képzelni, hogy valaki munkaadó igényelje ezt kiválasztásnál valamilyen (rákérdezési) szinten.
* Nem OLTP-s, hanem analitikus SQL-ezésnél, szerintem érdemes firtatni performancia-kérdéseket, ahogy PlSql-es kérdéseket is, de ez az esetemben lehet, hogy már az agykárosodás kategóriája. :o)
* Hogy mennyire vendorspecifikus kell legyen a kiválasztás? Én inkább úgy teszem fel a kérdést, hogy drágább RDBMS-hez, talán drágább alkalmazottak tartoznak jellemzőbben (hogy mennyire indokoltan az lehet vita tárgya). MySQl 3.2-höz nem feltétlen alkalmaznék Oracle 11g profit (most így extrapolálva). Viszont, ha MySql-s OLTP-s tudás kell, engem nem zavarna, hogy valaki PostgreSQL-ben szerezte a tapasztalatát (vagy fordítva).
* Azt én is jónak tartanám, ha lennének jó, strukturált és karbantartott feladatbankok SQL/PlSql-re. Bennem a kérdés immáron az, hogy mennyire inkább az önképzéshez tartozóan, és mennyire a versenyszerű kiválasztást támogatva.
* Az emberi és egyéb képességek szerintem is nagyon fontosak (szakmain túl és persze perspektivikusan is). És akkor tényleg ott van még a fizetésigény kérdése is. ;)
Ha valaki rákeres SQL kulcsszóval milyen állásokat hirdetnek ilyen tárgyú site-okon (Profession, Jobmonitor, stb.), akkor bármely, akár "punnyadásos", időpillanatban is egyfelöl jó eséllyel fog találni több nyitott poziciót, másfelöl könnyen valószínűsítheti, hogy "trendi" és ígéretes szakma általános követelménye, aminek következtében, megint csak könnyen valószínűsíthetően, jó sok jelölt pályázhat meg egy-egy állást, ahol SQL-lel kell dolgozni.
Ilyen esetekben munkáltató oldalról felmerül az (1) alkalmasság(előszűrés) illetve a (2) legjobb jelölt (versenyszerű) kiválasztásának triviális igénye. Kérdés van-e - és ha igen, akkor mennyire jó - módszertan ilyen jellegű kérdések megválaszolására? Könnyű-e annyira az SQL-tudás mérése, mint a nyelvtudásé (ahol pár perc diskurzus után megbízhatóan érzékelhető, ki mennyire jó nyelvből -> feltéve persze, hogy a munkaadó bír releváns nyelvtudással, ugye).
Nyelvtudás témájából is blogposzt-hegyeket lehetne írni (itt egy friss aktuális példa: Miért kérnek idegen nyelveket?), de most fókuszáljunk csak az SQL-tudásra és mérésére.
Első nehézség, mik a legfontosabb ismérvei egy jó SQL-esnek. Biztosan vitatható lesz amit mondok, én úgy vélem, hogy az alábbi öt dolog:
(1) Megbízhatóság, hogy egy megírt SQL-parancs tényleg azt csinálja, amit a fejlesztője akart. Komoly, aggregált, nagy futási idejű SQL-lekérdezést nem nagyon lehet sokszor futtatni (adott esetben még egy rossz futást lelőni is probléma lehet), és debugolni sem olyan könnyű, mint egy 3GL kódot.A dolog hatványozottan fontos tud lenni meglévő kódok módosítása esetén. Egy-egy rontáson nagyon sok múlhat, miközben a tesztelési költségek behatároltak, pláne nagyon nagy adatbázisoknál.
(2) Gyorsaság: ki kell tudni használni a deklaratív programozás fejlesztési előnyeit.Pláne figyelembevéve az RDBMS-ek magas alap és támogatási bekerülési költségeit, amik az SQL fejlesztési és végrehajtási előnyeit biztosítják.
(3) Komplex - például inline view-s - sql-ek olvasási, írási és módosítási készsége
(4) Logikai műveletek minél hibamentesebb értelmezése. Magam részéről nem pártolom az összetett logikai kifejezések eröltetését, a hibázási valószínűség robbanásszerű növekedésének lehetősége miatt, de ettől még mások preferálhatják és olvasni kell tudni az ő SQL-jeiket.
(5) Képes legyen kölcsönös kétirányú leképezésre/változtatásra (agyban) a fejlesztő, az SQL és a resultset között. Elismerem ez így nagyon homályos és képlékeny, ha analógiát akarnék keresni, akkor valami olyasmire gondolok, hogy a programozó sem soronként "nulláról" ír programkódot illetve képesnek kell lennie a gép "fejével" gondolkodnia. SQL-nél "kevesebb" karakter kell ugyan a kódoláshoz, viszont a resultset "elképzelése" szerintem nélkülözhetetlen követelmény, a hatékony SQL-parancs megfogalmazásához (sőt mindezt végrehajtási aspektusokkal vegyítve)
Magam részéről - egészen a mai napig - úgy gondoltam, hogy, ha nekem kéne valaki jó SQL-est kiválasztanom több emberből, akkor én például a magyar nyelvű szakmai SQL-levlistáról választanék egy-egy problémát és arról beszélgetnék a jelöltekkel. (Ezt előzetesen jelezném is feléjük.) A kiválasztott probléma lehet elméleti is, gyakorlat is (hibakeresés, sql-módosítás, resultsetes sql elemzés, stb.)
Ily módon,
(1) legalább valamennyire "zárt" a tudásbázis (még ha zajos is).
(2) de kellően "nyitott" is (hiszen régóta van sokezer hozzászólás, feladat, és így nehéz - végeredményt befolyásolóan - célraorientáltan készülni)
(3) aki a levlistán van (erőforrást fektet olvasásába/írásába), annak legyen ennyi "természetes" előnye
(4) a jelölteket felmérő is "(meg)dolgozik", hiszen közreműködik a kiválasztásban: persze nézőpont kérdése, hogy ez mennyire előny -> az én szememben az.
(5) végeredmény konvergálhat a kiválasztás jóságához, például azzal is, hogy a való életből választódik probléma.
Na, de mi a helyzet, ha
(1) több tíz potenciális jelentkezőre kéne minél megbízhatóbban sorrendet alkotni
(2) papír-ceruza alapon kéne dolgozni
(3) nem klasszikus alkalmassági-/vizsgamegfelelés, hanem versenyszerű alapokon való kiválasztás a cél?
Amióta egyre intenzívebben mozgok adatbányász világban, azóta ternmészetes módon izgatnak a verseny-aspektusok. Na ez most ezennel begyűrűzött az SQL-világba is. :o) Annyira azért nem tartom triviálisnak az SQL-versenyzést, de jó játék lehet belegondolni, hogyan lenne érdemes ilyesmit lebonyolítani.
Lehetséges felvetések/problémák egy egyáltalán nem futurisztikus SQL-verseny kapcsán:
* Kezdem egy elméleti (definiciós) kérdéskörrel: létezik SQL-re "rátermettség"? Aki jó 3GL-es, abból feltétlen "implikálódik" jó SQL-ezés képessége? Stb.
* Legyen OCA/OCP típusú (angol) feleletválasztós teszt a versenyzés alapja? Ez jó lehet disztingválásra, kiválasztásra? Mennyire él egy angol nyelvvizsga feleletválasztós tesztjével való analógia (állítólag az a mondás és ezért preferálják, hogy a jobb angolos jobban tölti ki őket, az én saját tapasztalatom, hogy az ilyen teszteket jobban töltöm ki, mint amennyire jó angolosnak tartom magamat. Avagy a ceruza-papír alapú és/vagy felelet-választós módi leginkább csak alkalmassági előszűrésre alkalmas, versenyzésre nem igazán?
* A győztes jósága mennyiben korrelál az kiválasztás jóságával (elsőfajú hibázás lehetőségei)?
* Létezik-e (és mennyire) olyan SQL-teszt, amit ha valaki nem kellően jól tölt ki (és bukik), attól még érdemes lenne alkalmazni (másodfajú hibázás lehetőségei)?
* Mennyire legyen "nyitott" az anyag? Lehessen rá készülni valahogy előzetesen? Erről célszerű-e bármit egyeztetni a jelöltekkel?
* Mennyire fontos a (help/internet nélküli) precíz szintaxis szempontja versenyzésnél? Ha az a feladat, hogy írjon be valaki például natív dinamikus ciklusos select feldolgozást pár sorban, abban "lehet-e" hibát ejteni? Lehet-e, jó sql-es, aki helpből másolgat átírásra kódot?
* Az Oracle pszeudó-, sor- és analitikus függvényei, hierarchikus lekérdezései mennyire erős/ütős szempontok képességmérésben? Egyáltalán mi a helyzet az ANSI szabvány vs. Oracle-specifikumokat illetően?
* Sql-performancia? Hintek?
* Sql vs PlSql? Ha PlSql (3GL) is, akkor ott azért már komoly versenyfeladatok képzelhetők el, kérdés persze, hogy az RDBMS-világtól mennyire elszakadóan.
* Meg lehetne-e tölteni egy könyvet jó versenyfeladatokkal?
Na most itt abbahagyom a további kérdés-kigenerálást. :o)
UPDATE-1.
Némileg revideálnom szükséges álláspontomat, azután, hogy tegnap este, nulla rákészülés után, éles körülmények között kitöltöttem otthon, egy gyári, hivatalos, angol nyelvű 1Z0-047 kódú Oracle SQL Expert tesztet. Egy ilyen teszt során 70 kérdésre kell válaszolni, két óra leforgása alatt. 60%-nyi jó válasz után sikeres a vizsga. Nem síma feleletválasztós volt a teszt (mint nyelvvizsga teszteknél), mert van, hogy több jó megoldás is lehetséges volt egy-egy kérdésnél (viszont meglepő módon előre jelzik a tényt is, sőt, hogy hány jó választ várnak el az adott kérdésnél).A két óra is bőven elegendő volt (sőt szerintem túlméretezett), mégha eléggé meg is terhelő a teszt-kitöltés maga.
Parádés módon nagyszerű (plusz élvezetes) volt az a teszt, amit kitöltöttem. 100%-ban olyan dolgokra kérdezett rá, amit szerintem is tudnia kell egy jó SQL-esnek, egyetlen "aljasság" és/vagy vitatható dolog nem volt a tesztkérdések között (nem úgy, mint nyelvvizsga teszteknél). Rendkívüli módon kiváló "vérfrissítésre" is alkalmas, jó tréningnek tartom ezt a fajta tesztet.
Nagyon tetszett a tesztben az is, hogy rengeteg kérdés volt SQL-olvasásra. Vagyis adtak adatmodellt és/vagy SQL create&insert scripteket, és az ezekre megírt közel nem triviális SQL-eket kellett elemezni a kérdés megválaszolásához (alapvetően ANSI SQL-eseket). Én az ilyen típusú feladatokat tartom a legegészségesebbnek.
A teszt alkalmas lehet a szakmai angol tesztelésére is (esetleg szükség esetén némileg tuningolva, mert a teszt angolja tényleg nagyon egyszerű volt). Továbbá szerintem megoldja azt a problémát is, hogy feltétlen kelljen papír-ceruza alapon kódokat írni (help nélkül).A teszt-kiértékelés is tudhat menni könnyedén.
Szóval nem biztos, hogy fel kell találni a meleg vizet még egy versenyszerű kiválasztáshoz sem. Ilyen tesztekből bárki össze tud állítani magának egy jó tesztet saját használatra,sőt bővítheti feladatbankját saját SQL-olvasási/-módosítási példákkal. Esetleg PlSql-tesztekből is át lehet emelni példákat szükség esetére. Kiváncsi lennék hányan élnek ilyen módival.
Nekem mindig is voltak kifogásaim egy OCP-vizsgával, leginkább olyan téren, hogy szükséges volt hozzájuk valami nem éppen jó, olcsó és/vagy hasznos Oracle eszköz(ök) precíz tudása. Márpedig abból, hogy az Oracle jó és sikeres RDBMS-t tudott fejleszteni, nem következik, hogy jó és sikeres front-end eszközöket is tud(ott). Sőt. Ezt a fajta Oracle-specifikumot (és eröltetését) én perdöntő módon inkorrektnek tartom, ami alkalmas lehet súlyos aránytévesztésre/megtévesztésére is a vizsgára befizetők, valamint a jóhiszemű potenciális munkadók körében. Na ez a mostani Oracle SQL-Expert teszt hálistennek visszaadott némi jó szájízt.
UPDATE-2.
Hali,
Itt egy kilenc feladatos, Papír-ceruzás SQL-teszt. Kidolgozási idő szigorúan egy óra. Emlékezetből írom, nem kizárt, hogy hibázok. Ezért előre is elnézést kérek.
Ügyfél(ügyfél_id,ügyfél_név)
Számla(ügyfél_id,számla_id,egyenleg_dátum,számla_egyenleg)
Tranzakció(tranzakció_id,ügyfél_id,számla_id,tranzakció_ideje,tranzakció_összeg)
Ügyfélkapcsolat(id,ügyfél_id1,ügyfél_id2)
1. Listázandók az inaktív ügyfelek, akik az elmúlt 30 napban nem tranzaktáltak.
2. Az ügyfeleknek hány számlájuk van?
3. Az aktuális számlaegyenlegekből meghatározandó a 30 nappal ezelötti számlaegyenlegek, a tranzakciós adatok révén.
4. Itt volt egy 30 napi forgalmi adat alapján valami kiválasztás. Egyszerű volt, de már nem emlékszem rá vissza pontosan. :o(
5. Akkor nem tekinthető sikeresnek egy napi zárás, ha a tranzakció táblán a napi összesítés nem fut ki nullára. Mely napokon nem volt sikeres zárás?
6. Listázandók azon ügyfelek, akiknél van legalább egy 45 napos intervallum, amikor több mint 100.000 fórint jóváírás érkezett.
7. Egy ügyfél közvetlenül és közvetetten is kapcsolódhat egy másik ügyfélhez (egy másik ügyfélen keresztül). A tranzitivitási lánc tetszőleges hosszú lehet. Egy-egy ügyfélnek hány (közvetlen és közvetett) kapcsolata van?
8. Készítendő egy output, ahol ügyfél_id-nként az első, második, harmadik számlához tartozó pozitív előjelű tranzakció összegek végösszege jelenik meg, 2010.11.01 utáni tranzakciókra.
9. Listázandók azon ügyfelek, akiknek legalább 7 negatív összegű tranzakciója van 2010.11.01-től kezdve, ezen tranzakciók átlaga kell ügyfelenként, úgy, hogy a három legkisebb és legnagyobb összegű tranzakció nem számolódik bele az átlagba.
Azt gondolom ez egy igazi emberkínzós "teszt"(?), mind megírni, mind kijavítani (pláne nagyüzemben). Főleg annak ismeretében, hogy az én kézírásom csúnyább, mint a világ legcsúnyább nője, a néhai Zámbó Jimmy....
;)
Az egy óra is elég kevés érzésem szerint, én legalábbis kihasználtam a rendelkezésre álló időt.
A feladatok viszont zseniálisak, szvsz. Ezért is osztom meg őket, tanulságképpen.
UPDATE-3.
Szerintem a legfontosabb azonosítani, hogy szakmailag mitől jó egy SQL-es, ahogy ezt fentebb is megkíséreltem. A további kérdésekre az én válaszkezdeményeim:
* Szvsz, aki (ösztönösen) jó 3GL-ben, nem feltétlen jó SQL-ben is. De van komoly esélye jónak lennie benne, leginkább avval, ha sikerül érdemben ráéreznie az ízére. Sokkal nehezebbnek érzem az átmenetet 3GL és SQL között, mint két 3GL nyelv között. Valamint én megkülönböztetek OLTP-s és adattárházas (analitikus) SQL-est is. Az elöbbi lényegesebben könnyebb műfaj, szvsz.
* Immáron azt vélem, hogy a feleletválasztós teszt csomó előnyén túl, a versenyszerű kiválasztásra is alkalmas (legalkalmasabb?). Főleg, hogy a kiválasztásnál egyéb szempontok is vannak, más véleményekkel összhangban. Azt nehezen tudom elképzelni, hogy aki jól tud olvasni/módosítani kemény komplex SQL-eket, az ne tudna írni is jól SQL-eket. (Nyelvnél ez például távolról sincs így, szvsz). De befolyásolható vagyok a kérdésben. ;)
* Az elsőfajú hibázást sokkal valószínűbbnek tartom mint a másodfajú hibázást. Analógia: szerelembe könnyebb esni, mint komoly, tartós, boldog házasságba lépni. Illetve, ha valaki első körben ellenszenves, nehéz lesz lesz másodjára szerelemre kiválasztani, még ha jó sok hálivúdi film is szól ilyesmiről. ;)
* Én pártolom, hogy minél zártabb legyen az anyag, amiről szólna a verseny (előzetes informálással), de nyilván nem publikus tesztsor alapján versenyeztetnék.
* Én nem vagyok híve a precíz szintaxis számonkérésének (tőlem még a hierarchikus query vázát is lehet helpből másolni, az analitikus függvényekről nem is beszélve). Például mert hasznosabb agyi tevékenységek elöl veheti el az erőforrást. De el tudom fogadni az ellenvéleményt is.
* Tetszik nem tetszik, az ANSI-szabvány "tudása" nehezen megkerülhető. Olvasni mindenképpen kell tudni ilyen SQL-eket, szvsz.
* Oracle-specifikumok nálam opcionális kategória. Szerintem fontosabbak az eddigi szempontok, illetve ezek a specifikumok menetközben felszedhetők, külön tanfolyam nélkül is. De el tudom képzelni, hogy valaki munkaadó igényelje ezt kiválasztásnál valamilyen (rákérdezési) szinten.
* Nem OLTP-s, hanem analitikus SQL-ezésnél, szerintem érdemes firtatni performancia-kérdéseket, ahogy PlSql-es kérdéseket is, de ez az esetemben lehet, hogy már az agykárosodás kategóriája. :o)
* Hogy mennyire vendorspecifikus kell legyen a kiválasztás? Én inkább úgy teszem fel a kérdést, hogy drágább RDBMS-hez, talán drágább alkalmazottak tartoznak jellemzőbben (hogy mennyire indokoltan az lehet vita tárgya). MySQl 3.2-höz nem feltétlen alkalmaznék Oracle 11g profit (most így extrapolálva). Viszont, ha MySql-s OLTP-s tudás kell, engem nem zavarna, hogy valaki PostgreSQL-ben szerezte a tapasztalatát (vagy fordítva).
* Azt én is jónak tartanám, ha lennének jó, strukturált és karbantartott feladatbankok SQL/PlSql-re. Bennem a kérdés immáron az, hogy mennyire inkább az önképzéshez tartozóan, és mennyire a versenyszerű kiválasztást támogatva.
* Az emberi és egyéb képességek szerintem is nagyon fontosak (szakmain túl és persze perspektivikusan is). És akkor tényleg ott van még a fizetésigény kérdése is. ;)
2010. december 2., csütörtök
A bizalom egyes adatbányász aspektusai
A minapi elöző Projektvezetés és scope-menedzsment posztomhoz egy hosszabb komment érkezett nemrég, és mivel izgalmas inspiráló felvetések voltak a kommentben, ezért külön posztban igyekszem reagálni.
A bizalommal kapcsolatban fentebb írtakkal nagyon egyetértek, illetve sok minden továbbit is lehetne még említeni. Tényleg jóval nehezebb elnyerni pláne visszanyerni, mint eljátszani a bizalmat, és a mai modern pörgésben a rövidtávú nyereség vágya (aka kapzsiság) sokszor gátja a hosszútávó stabil bizalomnak.
Ami a tárgyunk szempontjából viszont izgalmas, hogy a bizalom (1) alapvetően "intuicióorientált", (2) bár közvetlenül nem derült ki az előző posztból, de én alkatilag elsődlegesen "analizisorientált" személyiség vagyok. Engem pont az izgat, hogy hogyan lehet lehetőleg minél praktikusabban "objektívvé" tenni a bizalmat, hogy milyen stratégia mentén érdemes bizalmat adni.Egyszer jó lenne erről is hosszabban beszélni.
A bizalommal kapcsolatos másik fontos momentum - a létén, nemlétén kívül -, hogy megérte-e. És itt is nagyon hiányzik a visszamérés, az én analizisorientált szemléletemnek.
Bizalom kapcsán, meg ha már adatbányászatról van szó külön szót kell ejteni a Jevons paradoxonról is (szabad szóhasználattal élve hiába ez egységnyi hatékonyságnövekedés, ha mennyiségi összességében sokszorosra nő a veszteség).
Ha volt valaha valami unszimpatikus nekem az adatbányászatot illetően, az az, hogy az adatbányászeszközöket nem reális termékelőállítói profitra méretezve árulták, hanem a vásárló ügyfelek várható hasznának léptékére (magyarán indokolatlan extraprofitra). A vásárló ügyfelek aztán "előre a medve bőrére" címszóval megvették - előre kifizetve - ezeket az eszközöket. Az adatbányász konzulensek aztán például első körös logisztikus regresszióval "csodákat" varázsoltak a megrendelőiknek. És a legcsúnyább, hogy mivel ez eléggé gyorsan megvolt minden egyes alkalomra, ezért mindezt a többi - iparágon belüli - konkurens cégnél is elsütötték.
Tehát a megrendelők kvázi még a komparativ előnyüket sem tudták kihasználni a nagy felpörgésben. Kik jutottak extraprofithoz a szabad piac farkastörvényei alapján? Az eszközgyártók, meg a konzulensek. És relatíve kinél volt a legkisebb lecsapódó haszon, akik megelőlegezték a bizalmat, és megfinanszírozták az egészet előre.
A dolog ott üt vissza, hogy a megrendelők előbb-utóbb megtanulnak számolni és visszamérni következésképpen egyre nehezebben egyre munkaigényesebb (akár nullához konvergáló profittartalmú) projektekhez lehet csak hozzájutni, pláne így válságokkal terhelt időkben. Számomra mindebből az a tanulság, hogy mind a bizalmat, mind a munkakapcsolatot új alapokra (mint a farkastörvények) kell helyezni a jövőben. Az előző posztomban is ennek szerettem volna hangot adni (más megközelítésben).
Az új termék és marketingje egy érdekes téma az adatbányászatban is. E. Rogers 1975-ös tankönyve a vásárlók alábbi kategóriáit különbözteti meg. Az egy érdekes adatbányász-feladat, hogy minél hatékonyabban megtalálni az innovátorokat, akik (1) szívesen kipróbálják az újat, sőt vállalják a kezdeti nehézségeket is vele (2) pozitív valamint intenzív mennyiségű & minőségű üzeneteket adnak tovább a náluk lassabb - nagyobb tehetetlenségi erővel rendelkező - többieknek.
03% innovators (venturesome);
14% early adopters (respectable);
33% early majority (deliberate);
33% late majority (sceptical);
16% laggards (traditional).
* Azt hiszem ami a legfontosabb lenne a BIZALOM ami a mai világban egyre inkább kiveszőben látszik.
* ...elveszíteni a bizalmat sokkal könnyebben, gyorsabban lehet, mint visszanyerni
Sőt megnyerni is könnyebb a bizalmat, mint visszanyerni.
*...pillanatnyi előnyökért változtatnak...
A bizalommal kapcsolatban fentebb írtakkal nagyon egyetértek, illetve sok minden továbbit is lehetne még említeni. Tényleg jóval nehezebb elnyerni pláne visszanyerni, mint eljátszani a bizalmat, és a mai modern pörgésben a rövidtávú nyereség vágya (aka kapzsiság) sokszor gátja a hosszútávó stabil bizalomnak.
Ami a tárgyunk szempontjából viszont izgalmas, hogy a bizalom (1) alapvetően "intuicióorientált", (2) bár közvetlenül nem derült ki az előző posztból, de én alkatilag elsődlegesen "analizisorientált" személyiség vagyok. Engem pont az izgat, hogy hogyan lehet lehetőleg minél praktikusabban "objektívvé" tenni a bizalmat, hogy milyen stratégia mentén érdemes bizalmat adni.Egyszer jó lenne erről is hosszabban beszélni.
A bizalommal kapcsolatos másik fontos momentum - a létén, nemlétén kívül -, hogy megérte-e. És itt is nagyon hiányzik a visszamérés, az én analizisorientált szemléletemnek.
Bizalom kapcsán, meg ha már adatbányászatról van szó külön szót kell ejteni a Jevons paradoxonról is (szabad szóhasználattal élve hiába ez egységnyi hatékonyságnövekedés, ha mennyiségi összességében sokszorosra nő a veszteség).
Ha volt valaha valami unszimpatikus nekem az adatbányászatot illetően, az az, hogy az adatbányászeszközöket nem reális termékelőállítói profitra méretezve árulták, hanem a vásárló ügyfelek várható hasznának léptékére (magyarán indokolatlan extraprofitra). A vásárló ügyfelek aztán "előre a medve bőrére" címszóval megvették - előre kifizetve - ezeket az eszközöket. Az adatbányász konzulensek aztán például első körös logisztikus regresszióval "csodákat" varázsoltak a megrendelőiknek. És a legcsúnyább, hogy mivel ez eléggé gyorsan megvolt minden egyes alkalomra, ezért mindezt a többi - iparágon belüli - konkurens cégnél is elsütötték.
Tehát a megrendelők kvázi még a komparativ előnyüket sem tudták kihasználni a nagy felpörgésben. Kik jutottak extraprofithoz a szabad piac farkastörvényei alapján? Az eszközgyártók, meg a konzulensek. És relatíve kinél volt a legkisebb lecsapódó haszon, akik megelőlegezték a bizalmat, és megfinanszírozták az egészet előre.
A dolog ott üt vissza, hogy a megrendelők előbb-utóbb megtanulnak számolni és visszamérni következésképpen egyre nehezebben egyre munkaigényesebb (akár nullához konvergáló profittartalmú) projektekhez lehet csak hozzájutni, pláne így válságokkal terhelt időkben. Számomra mindebből az a tanulság, hogy mind a bizalmat, mind a munkakapcsolatot új alapokra (mint a farkastörvények) kell helyezni a jövőben. Az előző posztomban is ennek szerettem volna hangot adni (más megközelítésben).
Emlékszem olyan saját tapasztalatra, amikor egy cég új terméket hozott be, és a többi, már neves termékhez képest fél! áron adta. Ez jó is volt, és egyben rossz is... jó, mert így talán könnyebben meri kipróbálni az ember, mert úgy gondolja, hogy ennyit még szán rá, ha ki is dobja végül, viszont rossz, mert talán épp a "túl olcsósága" miatt nem meri kipróbálni, mondván, ebből az összegből minőségi termék nem állítható elő.
Az új termék és marketingje egy érdekes téma az adatbányászatban is. E. Rogers 1975-ös tankönyve a vásárlók alábbi kategóriáit különbözteti meg. Az egy érdekes adatbányász-feladat, hogy minél hatékonyabban megtalálni az innovátorokat, akik (1) szívesen kipróbálják az újat, sőt vállalják a kezdeti nehézségeket is vele (2) pozitív valamint intenzív mennyiségű & minőségű üzeneteket adnak tovább a náluk lassabb - nagyobb tehetetlenségi erővel rendelkező - többieknek.
03% innovators (venturesome);
14% early adopters (respectable);
33% early majority (deliberate);
33% late majority (sceptical);
16% laggards (traditional).
...nem megtartani akarják a kuncsaftot, hanem elcsábítani...A helyzet az, hogy mind az ügyfélmegtartás, mind az ügyfélmegszólítás komoly adatbányászati iparág, hatalmas arzenállal. Mindkét végről megy a harc az ügyfelekért. ;)
Feliratkozás:
Bejegyzések (Atom)
Bejegyzések
