Miért útálom oly nagyon a TOAD-ot?

v2.0 2013-06-21

2012 Szeptember 28-án a DELL megvette szőrüstől-bőrüstől a Quest céget, ami (mint a SAS is) független gyártóként kétszámjegyű éves múltra tekint vissza. Az ember azt hinné, hogy a független gyártókat jobban szereti az ember a mammutoknál,  vagy szakmaibban szólva megavendoroknál,  (amilyen az Oracle is), de nem: én a Questet is, a SAS-t is útálom, mind a céget magát is, mind a termékvonalatukat és árképzésüket is.

Árlistája szerint a TOAD for Oracle egyes kiadásai 1.000-8.700 euró (300.000-2.600.000 forint) közé esnek licencenként. Most az útálatomtól függetlenül is, 2008-as válság után nem tűnik életszerűnek az ilyetén árképzéses üzleti modell, logikusan várható volt ez a Dell-es akvizició. Ellenpontként a PlSql Developer jelenleg 216 USD, ~40.000 forint.

Öröktől fogva, amióta a világ világ, vagy legalábbis napvilágra került a két termék (Quest TOAD for Oracle és PlSql Developer) felhasználói kvázi kibékíthetetlen ellentétben állnak egymással. Mindegyik az általa használt termékre esküszik. Egyébként én is. ;)
Olyan a szembenállás, mint a Windows kontra Linux. Vagy még annál is durvább. Merthogy én Windows-ban dolgozóként abszolút értelmes és életképes alternatívaként élem meg a Linuxot, de a TOAD-ra például már fújok.  ;)

Ráadásul ami külön szép, hogy abban a Delphiben írták mindkettőt, ami számomra annó a legkedvesebb fejlesztőkörnyezetem volt, és mára széles körben teljesen lenézetté vált, egyébként teljesen jogosan, köszönhetően a Borland "okostojásainak", akik évek szívós és felhasználóellenes munkájával tönkretették a terméket (el is kellett adniuk, hogy ne termeljen további veszteséget, és azóta már ki tudja hanyadik tulajdonosnál vegetál az egyébként jobb sorsra érdemes cucc)

Legyünk rendesek kezdjük a TOAD előnyeivel. ;)

(1) Séma-exportja ritka flexibilis, ez mondjuk tud nehézkes is lenni, ha valaki gyorsan akarna egyet exportálni, annyi - olykor nem is trivális - dialógusablakon kell keresztül verekednie magát az embernek. De az biztos, hogy ennél többet még én sem nagyon tudnék beleképzelni a funkcióba. Persze csak alapértelmezésben... ;)

(2) SQL/DB-tuningolásra abszolút és verhetetlenül ideális. Saját szememmel láttam, hogy egy kollégám milyen hatékonyan támogatta meg egy 8 órába mindenképpen beleférő (SLA) 1400 job-os adattárháztöltést.

(3) DBA-Admin feladatokat remekül támogat. Egy Oracle Enterprise Manager úgy marad el felületében, használhatóságában, teljeskörűségében, hogy árban talán összemérhetőek egymással.

(4) SQL-monitorja egyenesen szenzációs. Gyönyörűen és használhatóan tudtam nézni, hogy a Business Objects Data Services (világ egyik legnagyobb ipari hulladéka, egyébként ETL-eszköz), milyen SQL-ekkel támadja meg az Oracle adatbázist. Segített felderíteni a "természetesen" nem dokumentált repositoryjának kulcsfontosságú részleteit, amiből aztán értékes üzleti funkcinalitást lehetett elérni.

(5) Table-rebuild. Megkreálódik a script, átnevezéssel, constraint-es ki-bekapcsolásokkal, particionálással, indexeléssel, jogosultságokkal, stc. De egyébként is pikk-pakk könnyű a legkülönfélébb reverse engine-s scriptekhez hozzájutni.

(7) Nagyon tetszik a gombra varrt Sql*Plus hívás lehetősége

(6) Session-browser. Fájó elismerni, de sokkal jobb, mint a PlSql Developeré. De tetszik az is, ahogy egyáltalán elválik a Session-, Schema-, Database-browser.

(8) Scheduler-funkcionalitás kidolgozottabb, mint a PlSql Developeré.


Na és akkor miért útálom a TOAD-ot:

(1) A béka-hang. Az első, amit az options-ben kikapcsolok, ha TOAD-oznom kell. ;)

(2) A világ legocsmányabbul formázott SQL-kódját adja ki magából alapértelmezésben, az én értelmezésem szerint.Ha kapok mailben egy SQL-t, rögtön tudom, hogy ha TOAD-dal lett összerakva - a hányingeremből;)

Ebben a témában én egyébként is "perben-haragban" vagyok a világgal.

Valamelyik "vicces" kedvű IT-s figura annó kitalálta (a világ meg bamba módon átvette), hogy az SQL-eket középre kell zárni, mert milyen "jópofa" középen a függöleges space-oszlop. Én meg ha ilyet meglátok, sírhatnékom támad, annyira szörnyűnek, visszataszítónak, problémákat gernerálónak találom.

A másik ilyen hülyeség, hogy az oszlopokat (másodiktól kezdve) vesszővel kell kezdeni a select-listában (illetve and/or-ral az elemi feltételeket a where-clause-ban). Mondván, hogy a vesszőt hajlamos a fejlesztő lehagyni a végéről így könnyebb a fejlesztőnek bővíteni a select-listát. Igen ám, de ez a fejlesztőnek pillanatnyi időre érdekes csak, szemben az SQL teljes életciklusával, mert az SQL-eket majd olvasók igényeivel. A szem fókuszt a vessző prioritása fogja vezérelni, nem pedig a mögötte lévő lényeg. A vessző vagy az AND az csak overhead az SQL-ben kis túlzással, legjobb lenne, ha nem is látszódna, mert hiszen nincs neki semmiféle üzleti tartalma.

Én ezzel szemben azt mondom hogy
- balra kell zárni,
- törekedni kell a minél kevesebb sorra, soronbelüli karakterszámra,
- az inline view-s struktúráknak első pillantásra jól kell látszódniuk,
- normális épelméjű legyen a zárójelezés az olvasó/visszafejtő számára,
- az SQL-formázásnak az átláthatóságot, a biztonságos módosítást kellene támogatnia, nem ilyen vizuális hülyeségeket mint a függőleges space-oszlopot.
Az ész megáll. ....

Nem értelemes fegyelmezett formázással lehetetlen biztonságosan és kultúráltan komplexebb, többszörösen beágyazott SQL-eket írni, amilyet nekem is kellett írni nem is olyan régen (132 KB, 3050 soros SQL)

(3) PlSql Developeresként  számomra rendkívül taszító volt a TOAD-ban mindig is, hogy egy lekérdezés COUNT(*) /rekordszám/-infójáért külön kell klikkelgetnem, amit én mindig azonnal kézhez kaptam azonnal.

(4) A TOAD számomra feleslegesen nagy monstrum (már az indulásánál is látszik, és utána is csak a szívás van vele), mindent összehányva tartalmaz, ami funkciókból - Pareto szabály szerint - 80%-ban használom a 20%-át, amivel szemben mindent ki is kell fizetnem, olvasatomban erősen túlárazott kalkulálás alapján (érdekes módon mint a SAS-nál is).
A PlSql Developer csak a 20%-ot tudja, de azt könnyedén, lightosan, barátságosan, és töredékáron.

(5) Ki merem jelenteni, hogy a TOAD nem fejlesztő eszköz. Csak van neki fejlesztői modulja is. Olyan is az egyébként. ;) TOAD-hívők is mindig csodálkoznak a PlSql Developer elegáns debuggerén, ami valóban támogatja a tárolt eljárások, hogy ne mondjam VIEW-k fejlesztését. (Nem mintha ő sem tudna befagyni, de ez más tészta)

(6) A TOAD-nak lehetne egy nagyszerű, világon egyedülálló feature-e, a lockolásos, csoportos szoftverfejlesztés, verziókontrollal. Ez lenne ugye a Team Coding. Ha nem lenne olyan használhatatlanul lassú és/vagy bug-os, hogy 2 percig(!) tartson (egyébként i5 procis, 8GB RAM-os desktopon) egy checkout-checkin session, olyan hibákkal, hogy a VIEW-k ablakai konkréten semmilyen módon nem bezárthatók utána (TOAD-reboot szükségessége). Az látszik, hogy küszködnek a témával a fejlesztők is,mert az UPDATE-k nagyrészt szólnak Team Coding BugFix-ekről.

Egyrészt én ezt a Team Codingot így használhatatlannak tartom a (jelenlegi formájában), ráadásul semmi mással nem is együttműködésképes csak a Quest termékek szintjén

Másrészt a funkciónak ezt a formáját sem tartom létkérdésnek. Azt gondolom biztonságosan lehet még Subversion-nel vagy SVCO-val is megoldani a problémát/funkciót, ha már az Oracle van olyan "szíves" és 40+ év után sem képes ilyesmit érdemben támogatni RDBMS-ében. ;) Persze jobban szeretem a Microsoft Visual SourceSafe lockolásos módszertanát.

A "2 perc" némi magyarázatra szorul. Életemben sok év után újra egy újabb projekt keretében ismét kellett használnom a General Eletric(=GE) VPN-hálózatát. Sok VPN-t láttam már, dolgoztam bennük, mindközül toronymagasan a legsz*rabb a GE-é.

Régen olyan lassú volt, hogy távolról mailben való karakter-leütés megoldhatatlan problémát jelentett neki (timeout).

A mostani friss élményem, hogy 2013-ban is továbbra is csak az ActiveX-s Internet Explorer-t támogatják. De olyan szinten, hogy a látszatra böngészőfüggetlen Juniper NetWork Connect mélyében is ez a szutyok IE van. Na de hogyan? Az IE 10-es verziót ismeretlen böngészőként ismerik fel (nemdeterminisztikus módon egyébként, van akinek sikerült ezt elkerülnie, de nem tudja, hogyan, miért), ami azonnal "restricted"-használatot von maga után. És persze a Microsoft megteszi azt a "szívességet", hogy a Windows8-ba beégeti az IE10-et, onnan kivakarhatatlan módon. Magyarán mind a Microsoft, mind a GE "jelszava" olvasatomban az, hogy a Windows8-as felhasználók rohadjanak meg, miközben az IE a kötelező standard.

Képezheti-e csoda tárgyát, hogy a TOAD Team Codingja ebben a GE-VPN-ben nem képes felülmúlni saját magát? ;)

Data Science: Amazon Web Services(=AWS) kihívások

v1.1 (2013.06.03, 18:50)

Az elmúlt 1-2 napban volt módom közelebbről is szemügyre venni  a tárgybeli AWS-cuccot.

Legelőször is, ezúton is köszönöm egyik kollégám inicializáló segítségét hozzá. Minden - olykor hülye - kérdésemre türelmesen válaszolt, amikor elveszettnek hittem magamat az információs káoszban. Múlhatatlan érdemei vannak abban, hogy egyrészt az élvezkedős fázisig hamar eljutottam, illetve, hogy egyáltalán az egész AWS egyik kedvenc topikom lett :)

Minden (adatbányász)kollégának aki még nem látta közelebbről ajánlom, akkor is, ha fizetni kell érte (10-20 USD-ből már egész sok mindent lehet csinálni), akkor is, ha maga a fizetés nem éppen sportszerű az Amazonnál.

Ínycsiklandozásként:
Apache Mahout: létezik egy elég hosszú k-means-es tutorial, ha valaki Amazon Elastic MapReduce-szal akarna adatbányászkodni. Csak annyit akartam evvel jelezni előljáróban, hogy adatbányász szemmel sem hülyeség a cucc. ;) Sőt, ha belegondolunk csupa számokból álló security igényeket is kielégítő dataseteken tudhatunk AWS-sel adatbányászkodni.

Az egész AWS-ben tulajdonképpen csak ez az egyetlen kifogásom volt: a fizetés, végül nem is a saját pénzemből lubickoltam az élvezetekben, hanem a munkahelyem accountjának terhére, amiben nyilván nem az összeg nagysága, meg a lehetőség nagyvonalúsága az elsődlegesen érdekes feature, hanem, hogy ilyen AWS-accountja volt/van a munkahelyemnek, instant használhatóan. :)

Szóval a fizetést illető kifogásaim:
- Visa Electron logos bankkártyával lehet fizetni korlátlanul, csak sajnos nekem nem olyan van.
- Maestro logos kártyával lehet fizetni, ha UK kibocsátású.Mi ez a kétszeres diszkrimináció?
- Nincs fizetési folyamatban feltüntetve, hogy mely bankkártyákkal lehet fizetni, kuglizni kell egy eldugott helyig
- Megtévesztő hibaüzenet (ami arra utal, hogy nálam van a hiba, hogy nem tudok fizetni, holott nem is). Emiatt volt egy tökfelesleges banki köröm, hogy minden limit jól van-e beállítva, van-e elérhető pénz, stb. És persze, hogy nem nálam volt a hiba.

Ami még lehet nem szimpatikus az AWS-ben:
- Ami nekem kellett Amazon Elastic MapReduce (EMR) és Pig az nincs trial verzióban kipróbálhatóan.
Amazon Webservices - Free-FAQ
- A free accounthoz is kell érvényes bankkártyaszám, lásd ehhez szintén a fenti problémát.Viszont ha valaki diák, akkor 100 USD-ig tudhat kerethez jutni:
AWS in Education
- Kézzel le kell állítani (nem elfelejteni) a munkamenetet,különben ketyeg a számla orrvérzésig és amihez nem elég a kliensoldali böngészőt bezárni természetesen. Lehet játszani a kis bankkártya-limit megadásával is,de az meg más kényelmetlenséggel üthet vissza.
Hogy ennek a szivatásnak - az ügyfél-kopasztási célzaton felül - mi értelme, azt nem igazán értem. Nem riasztja el a felhasználókat ez a durva eljárás? Nem cél, hogy jöjjenek a felhasználók? Nem az volt eddig mindig a trendi, hogy ha valami jól működött az pont a fizetés?

Az hogy mennyire éri meg az AWS használata, az nem lehet tárgya ennek a blogposztnak, hiszen ez jóval nagyobb téma, különben sem látok rá egyelőre a magam részéről a szükséges mértékben a cost-benefit topik lényeget érintő részleteire.

Nyilván sokféle fizetési konstrukció van, nyilván van bőven költségoptimalizálásra lehetőség, sőt még olyan is van, hogy erőforrás lehet licitálni.Hogy egy adott konfigurációért csak egy adott összeget akar az ügyfél fizetni és inkább kivárja, amíg ez rendelkezésére áll.

Az AWS használatbavétele így tehát minimum három lépésből áll:

1.lépés: URL-től - AWS grafikus consolig, plusz saját username, saját jelszó. Ugye ennek a legutálatosabb része a taglalt fizetési eljárás kiépítése.És ahogy említettem vagy saját maga csinálja végig az ember, vagy kap a munkahelyi AWS-rendszergazdástól egy levelet a fenti (+egyéb) infókkal.
Viszont ennek a lépésnek a végső jutalma az alábbi gyönyörűséges képernyő:

2.lépés:
Én csak töredékét használtam ki az AWS-nek: Elastic Mapreduce (Hive és Pig), S3, IAM

Az utóbbi IAM-re (felhasználó+jogosultság) egy szót sem vesztegetnék a továbbiakban, részint percekre álltam csak meg ott, doksinézegetéssel együtt is, részint mert annyira most nem volt fontos nekem.

Az S3 az hétköznapian szólva tárhely(szolgáltatás), én elsősorban idementettem az elemzéseim outputját. Akinek saját dataset-je van, az nyilván fel is akar tölteni ide, aztán innen dolgozni.

Megjegyzendő,hogy az S3-nak van egy kényelmetlenebb vonása: nem igazán támogatott a rekurzív könyvtár- / file-tartatalom mozgatása. Windows alá ami free S3-browsert kipróbáltam az mind hulladék volt, egyik sem működött nálam. Igaz, hogy a működő fizetősek sem drágák (pár 10 dollárért már komolyat lehet kapni), de akkor megint kezdődik a fizetés sztori, amit az AWS után nagyon megutáltam 1-2 hét perspektivájában ;)

Az S3-browser használatához/konfigjához három dolog kell
- a S3-bucket címe, amit az Amazon ad
- Az accountunkhoz tartozó "access" illetve "secret" key. Ezt mailben kapjuk vagy közvetlenül az Amazontól, vagy a munkahelyi AWS rendszergazdától.

És akkor jöjjön az Amazon Elastic MapReduce előkészületek:

Windows 8-as kliens PC-ről dolgoztam, free eszközökkel:
(1) Mozilla Firefox v21.0 böngésző
(2) Putty (elsősorban, mint SSH-klienssel). Ezt lehet GUI-n keresztül konfigolni, nekem szimpatikusabb volt a mellékelt plink-es parancssori verzió használata.Továbbá ugyan a plink mindenhez elég lehet, hiszen mint említettem a Putty, mint SSH-kliens miatt szükséges, de a Putty terminál kicsit felhasználóbarátabb, mint a cmd.exe, így érdemesebb lehet a kombinált használat.
(3) WinSCP(filetranszrfer célból)
 (+1) Hive-hoz létezik jelenleg v0.8.1-es verziójú JDBC-driver, aminek befaragása után egy SQL Workbench/J vagy SQuirreL-lel gyönyörűen lehet SQL-ezni is.

Sajnos pluszba kell egy "key pair", ahhoz, hogy Putty-olni lehessen az AWS használatát illetően.
Getting a Key Pair
Ez nem megkerülhető, ráadásul az Amazon által adott .pem file-t konvertálni kell a Putty segédprogramjával (Puttygen), de ez nem olyan drámai a valóságban, mint ahogy hangzik.

Mondjuk a mögötte lévő technikai magyarázat már tényleg komplikáltabb: a plink segítségével egy tunnelt építünk, azaz a localhost egy portját mappeljük evvel az Amazon szerverének egy portjára. Az architektúra érdekessége/sajátossága, hogy a monitorozás proxybeállításaival jó esetben nem kell küzdeni pluszban, de ha igen akkor előkerülhet például az okos foxyproxy (Mozilla Firefox Add-On).

Foxyproxy
General fül: csillag helyére a saját master dns címe kerül:
ec2*.compute-1.amazonaws.com
Proxy details-fül:
localhost
Socks proxy
Port: 8888
SOCKS v5
URL-patterns-fül:
1.
Pattern name: *ec2*.amazonaws.com*
URL-pattern: *ec2*.amazonaws.com*
2.
Pattern name: *ec2.internal*
URL-pattern: *ec2.internal*
plink.exe -D 8888 hadoop@MY_AMAZON_MASTER_DNS -i my_private.ppk

Putty-konfig portabilitása:
Még egy technikai apróság, ha valaki költöztetni akarja a konfigurálást, akkor mivel a Putty Windows-registry-be tárol (nem elég .rnd-file-t hordozni), ezért hackelni kell (Putty help-ben le van írva a "store configuration in file" szekcióban):
@ECHO OFF
regedit /s putty.reg
regedit /s puttyrnd.reg
start /w putty.exe
regedit /ea new.reg HKEY_CURRENT_USER\Software\SimonTatham\PuTTY
copy new.reg putty.reg
del new.reg
regedit /s puttydel.reg 

AWS-grafikus konzolon Elastic MapReduce jobflow kreálása
Hive-ra vagy Pig-re (amiket én próbáltam).
Lehet HBase és más is.
Pár kérdésre kell válaszolni:
* Név
* Pig
* Interactive (nem batch)
* Key pairhez tartozó név megadása (Puttyoláshoz)
* 1 master, 19 core, 2 tmp small-node (a maximum, amit én értem el)
* bootstrap action lehet "memory-intensive"
* OK-zás
Türelmesnek kell lenni, mert eltart egy darabig a flow-kreálás.
Amint WAITING lesz a flow-status, akkor lehet a Puttyal elkezdeni dolgozni.
Sajnos nem triviális, hogy a flow létrejöjjön, símán lehet FAILED is.
Itt kell TERMINATE-re kattintani, ha már nem dolgozunk és nem akarjuk, hogy ketyegjen a dolláróra.
Alsó képernyőfélen, jobb oldalt látható a MASTER DNS url-je.

A monitorozás eléréséhez (jobtracker:9100 és hadoop filesystem aka hdfs: 9101 ):
plink.exe -L  9100:localhost:9100 -L  9100:localhost:9100 -L 9101:localhost:9101 hadoop@MY_AMAZON_MASTER_DNS -i mprivate.ppk

Ekkor böngészőből a http://localhost:9100 és  http://localhost:9101 címen eléhetők a logok.
Óriási élmény bit szinten permanensen nyomon követni egy lekérdezést: óriási ígéret ez egy Oracle párhuzamos lekérdezés futás-monitorozásához képest.

Foglaljuk össze hol tartunk:
- Van egy accountunk (username+password) az AWS grafikus konzolhoz
- Van mailben érkezett "access" és "secret" key-ünk a username mellé, S3 kliens-odlali eléréséhez
- Van egy fentebb konfigurált kliensünk, ahol "hadoop" a standard Amazon-username, a jelszó a Puttygen-es konvertálásnál általunk megadott jelszó.
- Van egy  MASTER_DNS url-címe

3.lépés: Ez már a csodaország-rész :)

Eljutottunk oda, hogy a Putty-unkban van egy prompt.
PWD(unix): /home/hadoop
Pig (és hadoop-cluster) indítása után:
PWD(hadoop): ip-cim/hdfs

Azaz három filerendszeren keresztül dolgozunk (kliens PC-nket is természetesen beleértve)
A Pig-output az utóbbin keletkezik meg, azt át kell hozni unix-oldalra, onnan WinSCP-vel áthozható már a lokál gépenkre. Vagy S3-ra lehet menteni és onnan például az említett S3-browserrel lehet lementeni.
Pig "grunt"-promptnál fs a kulcsszó evvel lehet: -mkdir, -ls, -rmr (rekurzív könytártörlés), copyToLocal, copyFromLocal, etc parancsokat kiadni.

Grafikus konzolon felül Rubyból és Pythonból is lehet vezérelni scriptekkel az AWS-t
Sokkal több opció érhető el így, mint grafikus konzolon keresztül:
OReilly-Python and AWS Cookbook, 2011.10

Ha valaki jó bevezető anyagot akar Pig-ről (angolul), természetesen ezen a blogposzton felül :)
Apache Pig - 2012.június 21-i 81 diás remek prezentáció
Amazon Pig-tutorial: Parsing Logs with Apache Pig and Elastic MapReduce 
Apache Pig-doksi (v0.9.1, amit az Amazon támogat, egyébként v11.1 is van már)
Van benne Cookbook, Tutorial, Pig Latin nyelv referenciája, stb.

Hogy én mit mondanék először a Pig-ről:
- Irgalmatlan tömör magasszintű nyelv, ezt mindenki ki is hangsúlyozza, ráadásul ez nem megy az érthetőség illetve használhatóság rovására.
- A Pig Latin referencia ha tartalmaz 50 kulcsszót sokat mondok. Szóval nem egy Java gigakomplexum, azaz kicsi kompakt teljes :)
- Bár nem SQL, de imádja az is, aki szereti az SQL-t, legalább is én.

Adott egy 0.5TB=500 GB-os gráfadatbázis (subject,predicate,object,context attribútumokkal)
Billion Triples Challenge 2010 Dataset
Lehet feltölteni is datasetet, mint említettem. Én a fentebb linkelt eleve fennlévőt használtam.Három verziója is van: Az első 1000 soros kicsi állomány, homokozónak, a második már 10 millió rekordos, a harmadik a 0.5TB-os. Vigyázzunk mikor mire engedjük el Pig-programunkat. ;)
lines = LOAD 's3n://uw-cse-344-oregon.aws.amazon.com/cse344-test-file' USING TextLoader as (line:chararray);
lines = LOAD 's3n://uw-cse-344-oregon.aws.amazon.com/btc-2010-chunk-000' USING TextLoader as (line:chararray);
lines = LOAD 's3n://uw-cse-344-oregon.aws.amazon.com/btc-2010-chunk-*' USING TextLoader as (line:chararray);

Csak azért, hogy lássuk milyen szép és hatékony a Pig, itt egy kidolgozott feladat:
Feladat:
- Vegyük a fenti gráf-adatbázisból az első három attribútumot (triples), és tisztítsuk is meg egy e célra írt Java-s User-Define Function-nel (s3n://uw-cse344-code/myudfs.jar)
- Szűrjük meg a subject-et: '.*rdfabout\\.com.*'
- Keressük meg az összes két hosszú (egyedi) subject-re illeszkedő részgráfot, azaz kell egy attribútum-hatos (subject,predicate,object,subject2,predicate2,object2), ahol subject=object2
- Azaz SQL-eseknek lefordítva, szűrés, self-join, distinct-álás, index nélkül.
- A 10milliósoros datasetre, 1master-19core-2temp small node-ra, 8 percig futott, hozzáértve, hogy teljességgel könnyedén monitorozható volt az egész elejétől a végéig.Úgyhogy van, medium, large, extra-large, hiperszupermegagiga-large konfig is.

Megoldás:
REGISTER s3n://uw-cse344-code/myudfs.jar
lines = LOAD 's3n://uw-cse-344-oregon.aws.amazon.com/cse344-test-file' USING TextLoader as (line:chararray);
--lines = LOAD 's3n://uw-cse344/btc-2010-chunk-000' USING TextLoader as (line:chararray);
ntriples = FOREACH lines GENERATE FLATTEN(myudfs.RDFSplit3(line)) as (subject:chararray,predicate:chararray,object:chararray);
rdfabout = FILTER ntriples by (subject matches '.*rdfabout\\.com.*');
rdfabout_copy = FOREACH rdfabout generate $0 as subject2:chararray, $1 as predicate2:chararray, $2 as object2:chararray PARALLEL 50;
join_result = JOIN rdfabout by object, rdfabout_copy by subject2 PARALLEL 50;
distinct_join_result = DISTINCT join_result;
distinct_join_result_ordered = ORDER distinct_join_result by (predicate);
STORE distinct_join_result_ordered INTO 's3n://ec2-MY_BUCKET.us-west-2.compute.amazonaws.com/join';

Adatbányászat és sikerdíjas projekt

A legfontosabb, hogy aktualitásként és csak úgy l'art pour l'art, minden laikusnak és szakmabelinek ajánlom az Andengo-blog legfrissebb blogposztját: Pi és a prímek üzenete
Számomra  élmény volt olvasni, annyira szívemből szólt. Az említett mindkét  forrás számomra is releváns élmények.De nem erről szeretnék a továbbiakban írni :)

A sikerdíj-tárgyra térve nagyszerű és inspiráló blogposzt jelent meg a minap az említett blogon:
Kis pénz kis foci, nagy pénz nagy foci?
Az ebben foglaltakkal is, meg főleg az üzenetével alapvetően egyetértek, én az alábbiakban egy másik (egyébként jóval drasztikusabb) olvasatot szeretnék megosztani a témával kapcsolatban..

(1) Az egész IT-iparban az adatbányászatnak kéne a legtisztább ágnak lennie, a visszamérhetősége miatt, legalábbis az osztályozásnál mindenképpen (ami alapján ugye tárgyilagosan kiértékelhető versenyek is rendezhetők), mégis itt történnek talán a legtöbb és/vagy legnagyobb inkorrektségek meg lyukrafutások az én tapasztalatom szerint mind megrendelői, mind szállítói oldalról. Azért érdekes egy ellentmondás, érdemes lehet ebbe belegondolni.

(2) A sikerdíj analógiájára én definiálnám a kudarcdíj fogalmát is. ;) Óriási vesztesége az iparnak a sok rosszul felépített és/vagy menedzselt adatbányász-projekt. Sokszor van, hogy mindenki anyáz mindenkit (akár pusztán "csak" az ember háta mögött), az őszinte konklúzió levonására alig-alig látni példát. Az üzleti-projektes adatbányászat nem akkora sikersztori, olvasatomban, hogy ne igényelné a számvetést..

(3) Én a magam részéről amennyire tőlem telik egyenesen szabotálni akarom a sikerdíjas projekt-konstrukciókat, a korrekt feltételek definitive is létező hiányának okán. Ha versenyezni akarok, meg sikerdíjra vágyom, akkor ott a Kaggle :) Ha a többi szakmabeli is így tesz, akkor a megrendelők esetleg elgondolkoznak, hogy mennyire üdvözítő az út amit kitűztek maguk elé evvel (némi visszaélés feelinggel).

Miben lehetnek sárosak a beszállítók (hogy a saját portám felöl induljak):
- Előrejelzés címén kopasz logisztikus regresszió, pláne horribilis díjazásért. Pláne, hogy van olyan feladat, ahol nagyon gyengén teljesít a logisztikus regresszió, hiába szereti mindenki.
- Pár magyarázó változóra pár histogram végeredmény, zajként a nagy összképen belül. Adott esetben a komoly üzleti tartalmú összefüggések teljes mellőzésével.
- Egy-két hónapig működik a modell, gyenge prediktálási stabilitás miatt.
- Csak egy prezentáció a végtermék, folyamatintegráció legteljesebb hiányával.
- Nincs monitoring, nincs faltól-falig visszamérés (költség-haszonelemzéssel),
- Sikertelenség nem korrekt konkludálása, ami másoktól is elveheti a levegőt (meg sem születendő hasznos projektek formájában)
- Ugyanazt másutt is eladva: megfosztva a megrendelőket témából származó specifikus comparativ előnyüktől (amiért részben legalábbis fizettek).

Miben lehetnek sárosak a megrendelők?
- Konkréten láttam, hogy egy multicég kb. 28 éves marketing menedzserhölgye, aki Churn-elemzés elött a liftről sem hallott, nemhogy bármilyen minőségi mutatót meg tudott volna fogalmazni, projekt közben 20-40-szeres lifteknél - súgás alapján - kevesellte a modell-recall-t. De olyannyira, hogy képes volt kijelenteni, hogy nem fizeti ki a projektet, sőt belehajszolja a beszállítót a szerződés-nemteljesítés miatti kötbérezésbe. A szállító mehet a bíróságra, ha egyébként minden mást korrekten leszállított.
- Mindezt természetesen eBid után, hogy végletekig menjen lejjebb természetesen a költség. Persze idő nincs, belső vállalati erőforrás nincs, mert más fontosabb (dolgozzon a szállító, majd legfeljebb nem lesz jó és/vagy elszállnak a szállítói költségek).
- Az eBid-hez láthatóan nagyon értenek a megrendelők, de utána a "kegyből megkapott" projektért aztán meg a szállítónak a csillagos eget is le kell hoznia és természetesen iziben, de ami persze adott esetben még mindig elégtelen lehet az elégedettség eléréséhez.
- A titkossági igények miatt alapvető információk el vannak zárva, blackbox alapon kell tenderezni.
- Semmilyen előzetes rugalmas játéktérre általában nincs lehetőség: értelmezésemben ez az adatbányászat halála. Blackbox-ba fejes ugrás sokszr az egész projekt, egy-egy tender megnyerése után is.
- Természetesen kellő távlatú idősoros adatok is hiányozni szoktak, hogy a prediktálási stabilitás sztorija még nehezebb legyen, nem elég ha csak önmagában nehéz.
- Na és a fentiekhez kapcsolódik az újabb adatbányászt potenciálisan tovább zsigerelő sikerdíjazás.

Én azt az utat választottam, hogy nem vagyok hajlandó belemenni a sikerdíjas konstrukciókba. Eddigi - koromból is fakadó - nem rövid pályám során rengeteg üzleti visszásságot voltam kénytelen lenyelni, csak annak az egy dolognak az apropóján is, hogy a pénz mindig az üzletnél van, ugyanakkor ezáltal a projekthez szükséges perdöntő információk és a pénz nem egy kézbe koncentrálódik az esetek döntő hányadában.

De persze vannak jobbító szándékú javaslataim, hogy ne ennyire tragikus hangvételű legyen a posztom, pláne, hogy optimista derüs ember lennék vagy mifene. :)

- Játékteret kell korrekten specifikálni. Ez így túl általános, de talán érthető mire akarok kilyukadni. És konstruktívan kell benne résztvenni. Ha ebben például a megrendelő nem partner, akkor tudni kell megálljt mondani. Ott egyéb lappangó inkorrektségek is esélyesen tudnak később napvilágra kerülni.

- A megrendelőnél legyen (1) vagy idő, (2) vagy értelmes költségkeret (például Kaggle-versenyre), vagy a fentebb rugalmas játéktér, lehessen például kiszállni, ha a korai fázisban kudarcosnak látszik a sztori.

- Ne a szállító feleljen mindenért, állja az összes költséget, stresszet, létezik felelősségmegosztás elve is..

- Válasszuk szét az adatbányászatot klasszikus bevált egzakt valamint inegzakt részekre. Az én jelenlegi álláspontom szerint az elsőre hajlandó vagyok hagyományosan módon tendert is beadni, "győzzön a jobb" jeligével, az utóbbi inegzakt részt viszont kizárólag csak tesztelten megbízható partnernél vagyok hajlandó elvállalni, perdöntően esélyesen inkább csak külföldön.

- Az is egy lehetőség e szétválasztásra, hogy egyik projekt fázisban álljon elő csak az akár versenyzésre is alkalmas egyébként security igényeket is kielégítő csupán számokból álló dataset, frameworkkel, folyamatintegrációval, stb., aztán második inegzakt fázisban induljon a modellezési-hajrá! :)

- Csökkentsük a black-box effektust, ez jót tehet mind a megrendelő, mind a szállító idegrendszerének egyaránt. :).

- Legyen dataset amiben van idősorral: prediktálási stabilitást is lehessen mérni.

- Ha fontos a sikerdíjas koncepció meg a minőségbiztosítás (az inegzakt rész mutatóinál), akkor kedves megrendelő tessék Kaggle-versenyt csinálni, vagy hasonlót saját erőből szervezni.

- Szakadjunk el a lift mágikus primátusától. Nemcsak egy mutató a világ. Annyi okosság van a szakmában: kezdve a klasszikus recall-lal, aztán prediktálási-stabilitás,  valódi erős és esetleg időben állandó változók megtalálása valós erő kimutatásával, changepoint detection, öntanuló folyamat javaslat pl.: churn modell váltására (már ez sem sci-fi).

- Vagy legyenek értelmesebb az adatbányász-projektek szerződések jogi szövegezései, vagy nőjön a felek közti "gentleman agreement" hatásfoka, kerülendő a "nem fizetünk" felállást.

- Megjegyzem eddig egy szó sem hangzott el a domain-specifikumról. Ami alaposan ellene dolgozik a sikerdíjnak, ahonnan ugye az egész poszt-felbuzdulás indult. Nem lehet összevetni látatlanba még két biztosítós churn-modell-t sem. Lehet, hogy a gyengébb liftű modellben több a komoly szakmai tartalom, mint a másikban. A Kaggle-versenyek ezért jók, mert ott megvan az összevethetőség.

Összefüggések :)

Most csak egy gyors kép, semmi más, és megint csak Bill Howe-tól (University Washington)

Data Science MapReduce-feladatok

Ígérem nem lesz rendszer a napi két blogposzt. :)

És hogy necsak, a vakvilágba, l'art pour l'art beszéljünk a Data Science-be bimbózó, sőt szárbaszőkő vidámságokról, a Python és Sql után könnyen adódik a MapReduce szépségeiben való elmerülés.

Arra nem vállalkoznék, hogy számszerűsítsem a 2004-es Google ernyője alól kikerült algoritmus jelentőségét, de hogy a világ egyik legjobb mókája vele dolgozni az biztos (és bizton mondhatom evvel nem vagyok egyedül). Hozzá talán egyedül az SQL-t tudnám hasonlítani, az bír ennyire élvezetes lenni még talán (leszámítva és ide nem értve az SQL-nyelvjárások nyűgjeinek kerülgetését).

Magyar anyag nincs oly sok fenn a neten, ez az alábbi frissebb és nagyon szimpatikus (25 diás prezentáció)
CAP, mapreduce, Hadoop

A feladatok Bill Howe(University Washington) feladataiból egy válogatás, ahogy egyébként a múltkori Pythonos és SQL feladatok is tőle származtak eredendően.

1.feladat: http://jsmapreduce.com/

Ez egy kiváló eszköz, hogy  nulla overheaddel, maximális élvezettel gyakoroljuk a MapReduce-t. Fizetni sem kell az Amazonas-nak egy centet sem, az csak egy további opció, ha addiktívvá váltunk az eszköz hatására. :)

Először is - minő meglepetés - telepíteni kell hozzá vagy egy Mozilla Firefox, vagy egy Google Chrome böngészőt, merthogy Internet Explorer alatt nem megy. Én nem fogadnék rá nagy pénzben, hogy valaha is elérhető lesz IE alatt is, azaz erre nem érdemes várni... :)

Másodszor kell regisztrálni, ha valaki például a Pythonos menüpontokat a maguk teljességében akarja élvezni. Első gondolkodtató kérdés: vajon a honlap miért sújtja regisztrációs átokkal a Python-t? ;)

Harmadszor, használati utasítás gyanánt, meg lehet nézni - egy szerintem borzalmas minőségű - közel 15 perces - természetesen angol nyelvű - videót a vonatkozó cucchoz. Én ezt ugrottam pár perc után, annyira elviselhetetlennek találtam, különben is eléggé intuitív az egész eszköz, nem kell hozzá semmilyen videó, szvsz.
Introduction to JSMapreduce

És akkor a feladat:
Módosítsuk a pókeranalízist (Sample 2 vagy Sample 4), hogy például a valóságban nemlétező négyes sorokat (4cardstraights) is kalkulálja. Azaz a figurákból (A,2,3,4,5,6,7,8,9,T,J,Q,K,A) tetszőleges négy egymás mellett legyen, bármilyen szín(treff,káró,kőr,pikk) eloszlással. Erősséget tekintve a 4-es sor nyilván gyengébb az 5-ös sornál, és persze kerülni kell, hogy a teljes sor "straight" beleszámolódjon bármelyik 4-es sorba.

Bónusz-kérdések:
- Melyik verziónak érdemes nekiesni? Javascript-esnek, vagy Python-osnak?
- Megfordítva: miért sokkal lassabb a Pythonos? Ennyivel lassabb kód futna esetében?

2.feladat: Klasszikus HelloWorld-jellegű szószámlálás  MapReduce-ban (teljes megoldással):

Feladat: számoljuk meg Python programmal, mely szavak hányszor szerepelnek a szövegekben!

Íme book.json file részlete, doc_id-text párokkal.
["milton-paradise.txt", "Book I Of Man ' s first disobedience"]
["edgeworth-parents.txt", "Near the ruins of the castle of Rossmore"]
["austen-emma.txt", "Emma Woodhouse , handsome , clever , and rich"]
["chesterton-ball.txt", "The flying ship of Professor Lucifer sang through the skies like"]
["bible-kjv.txt", "The Old Testament of the King James Bible The First Book of Moses"]
["shakespeare-caesar.txt", "Enter Flauius , Murellus , and certaine Commoners ouer the Stage"]
["melville-moby_dick.txt", "The pale Usher -- threadbare in coat , heart , body , and brain"]

Fog kelleni egy - feladatosztályt érintően nem változó - MapReduce.py, osztály-definicióval, ha szimulálni akarjuk a MapReduce működését egyszerű eszközökkel (megírandó programjaink mellé).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
import json

class MapReduce:
    def __init__(self):
        self.intermediate = {}
        self.result = []

    def emit_intermediate(self, key, value):
        self.intermediate.setdefault(key, [])
        self.intermediate[key].append(value)

    def emit(self, value):
        self.result.append(value)

    def execute(self, data, mapper, reducer):
        for line in data:
            record = json.loads(line)
            mapper(record)

        for key in self.intermediate:
            reducer(key, self.intermediate[key])

        #jenc = json.JSONEncoder(encoding='latin-1')
        jenc = json.JSONEncoder()
        for item in self.result:
            print(jenc.encode(item))
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Illetve kell egy wordcount.py, ami a feladatot megoldja:
Futtatás: python wordcount.py books.json
 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
import MapReduce
import sys

mr = MapReduce.MapReduce()

def mapper(record):
    key = record[0]
    value = record[1]
    words = value.split()
    for w in words:
      mr.emit_intermediate(w, 1)

def reducer(key, list_of_values):
    total = 0
    for v in list_of_values:
      total += v

    mr.emit((key, total))

if __name__ == '__main__':
  inputdata = open(sys.argv[1])
  mr.execute(inputdata, mapper, reducer)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

3.feladat: Adott továbbra is a book.json bemeneti file.
Módosítsuk az előbbi szószámláló progit (inverted_index.py), úgy, hogy minden szó mellé listában irassuk ki mely (doc_id-val azonosított) szövegekben fordul elő az adott szó.
Kimeneti minta:
["all", ["milton-paradise.txt", "blake-poems.txt", "melville-moby_dick.txt"]]

4. feladat: Adott egy records.json bemeneti file, alábbi mintával.
Ez tartalmazza a rendeléseket, és a rendelések tételeit.
A második oszlop (mindkét rekordtípusnál) az order_id, utána még teszőlegesen sok attribútum lehet.
Írjuk át MapReduce-ra az alábbi SQL-lekérdezés: join.py

SELECT *

FROM Orders, LineItem

WHERE Orders.order_id = LineItem.order_id

["Orders", "1", "36901"...]
["LineItem", "1", "155190"...]

5.feladat: Adott egy friends.json bemeneti file, alábbi mintával.
Mindenki nyilatkozott kit tekint barátjának. Ebből következik, hogy a barátság nem kommutatív. Ha "A" barátjának érzi "B"-t, abból nem következik, hogy "B" barátja "A"-nak. Listázzuk ki MapReduce-szal az asszimmetrikus barátságokat: asymmetric_friendships.py
["Myriel", "Geborand"]
["Myriel", "Champtercier"]

6.feladat: Adott egy dna.json, génszekvencia-id illetve génszekvencia-string párokkal.
MapReduce segítségével töröljük minden génszekvenciából az utolsó 10 karaktert, majd deduplikáljuk az összes génszekvenciát (minden csonka génszekvenciából egy maradjon a kimenetre): unique_trims.py

7.feladat Adott egy matrix.json bemeneti-file, alábbi mintával.
Két ritka mátrix (a,b) valós, nem-nulla elemeit tartalmazza (sor,oszlop,érték)
MapReduce segítségével számoljuk ki a szorzat mátrixot: multiply.py
["a", 0, 0, 63]
["b", 0, 0, 61]

Mi a különbség a Data Miner("adatbányász") és a Data Scientist("adattudós") között?

v1.5 (utolsó módosítás: 2015.05.14

Létezik a címbeli kérdésre egzakt válasz? Kötve hiszem, de az biztos, hogy én nem tudom.
Mindenesetre blogposztot írni lehet róla azért, főleg ha egyre többet bukkan fel ez a "Data Science"-cucc, lépten-nyomon. ;)
Magam annyira régen végeztem az ELTE programtervező matematikusi szakán, hogy nemhogy a "Data Scientist", de még a "Data Miner" sem hangzott el a képzés alatt (1987-ben kezdtem az egyetemet)

Három megközelítés:

(1)
Egy amerikai eredetű slide egyike ez volt:
 - What are the abstractions of data science?
- “Data Jujitsu” + “Data Wrangling” + “Data Munging” = Translation: “We have no idea what this is all about”
Big Data Curricula at the UW eScience

Az én saját értelmezésem szerint:

Data Jujitsu: Az amikor nem a feladatot nyers konkréten azonnal felmerült formájában oldjuk meg, hanem találunk a feladatnak egy másik megfogalmazását, ami nagyjából ugyanazt az outputot adja, ami nekünk kell, csak sokkal kevesebb erőfeszítéssel. Röviden feladat-átfogalmazás. Az adatbányászatot leginkább ennek részének érzem.

Data Wrangling Általános véve olyan data-prepocessing adattranszformációs lépése egy iteratív folyamaton belül, ami a jobb felhasználást/modellezést segíti elő. Adattisztítás éppúgy része, mint a data mining feature extraction.

Data Munging Általános véve zajos adatok tisztábbá tétele, mind rekord, mind mező szinten. Jobb/tisztább inputon való modellezés esélyesebben ad értékesebb outputot.

(2)
Egy másik slide-on ez a Venn-diagram volt, három gombóccal:

(3)
Egy harmadik slide-on meg ez:
Empirical + Theoretical + Computational

Azt gondolom ezek mind érdekes észrevételek, de csak kapargatják a felszínt a kérdésünk megválaszolásának kísérletéhez.

Anno az én eredeti megközelítésem az volt, hogy az adatbányászatnak négy aspektusa van:
- Matematikai (statisztikával, mátrixokkal, mesterséges interlligenciával, etc.)
- Mérnöki/Műszaki (operációkutatással, kombinatorikus optimalizálással, tanuló algoritmusokkal, nagy tömegű értékes és értéktelen adatokkal etc)
- Informatikai (adatbázisokkal, korszerű programozási nyelvekkel, üzleti intelligenciával, etc)
- Közgazdászi (üzleti kommunkikációval, adatvizualizálással, tálalással, eladással, projekt-/pályázat-nyeréssel, üzleti aspektusokkal, (mikró-/makró-)ökonomiával, ökonometriával, stb.)

Ahogy jelenleg én ezt a kérdést látom - ebben a gyorsan változó világban - a Data Scientist felülről kompatibilisnek "van szánva" az adatbányásznak. A Data Scientist tudáskészletének valós részhalmazává válik az adatbányász tudáskészlete. Nem lesz olyan "skill", ami csak az adatbányászé lenne, a Data Scientisté nem, kérdés, hogy mi a helyzet a fordítottjával.

A tévedés jogának fenntartásával azt vélelmezem, hogy egy adatbányásznak nem feltétlen kell tudnia a párhuzamos programozást tudnia. Főleg Magyarországon (az ehhez szükséges "big data" datasetek hiányában például). Következésképpen a Hadoop és az infrastruktúrája, akárcsak a 2004-es MapReduce algoritmus részletei bőven hidegen hagyhatja az adatbányászt, tudhat dolgozni nélkülük.

Hasonlóan az adatbányásznak elég lehet a black-box cuccok alkalmazása (pl.: neurális háló), nem kell neki feltétlen megértenie a black box működését - maximum magyaráznia :). A Data Scientist meg esélyesen válhat addiktivvá, hogy a black box mélyére ásson, hogy kifehérítse azt. Tágabb kontextusban pedig az is lehet egy vízió, hogy egyre több Data Scientist számára válik egyre inkább napi gyakorlattá a kutatás - implementálás - (angol) szakmai cikk/tanulmány publikálás, ami (legalábbis itthon Magyarországon) eddig jellemzően az egyetemi/akadémiai szféra sajátja volt.

Ugyanígy egy adatbányásztól - jelenleg semmiképpen - nem elvárás (idő és komplexitás rendben) például (az alap Java-n felül) a Python, Ruby, Clojure, Scala, Haskell, Erlang programozási nyelvek effektív használata. Azt jelenleg nem tudom, hogy a Data Scientisttől én elvárnám-e, illetve a jövőben elvárás lesz-e, de sejtés szinten azt vélelmezem, hogy el kéne várni. Ahogy az egyetemen is sok száraz matekot tanultunk, amit aztán ugyan közvetlenül nem használtunk ki a való életben, de persze másképp azért kamatozott az, hogy ilyesmikkel is "vívtunk" (absztrahálás, látókör-bővülés, agyműködés-serkentés, stb.)

Vagy éppen adatperzisztenciánál elég lehet text-állományok, vagy relációs adattáblák olvasása, írása, miközben evvel párhuzamosan az eddig megszokott szemléletekkel gyökeresen szakító NoSql- vag gráf-adatbázisok világa is egyre inkább forrong napjainkban. A bonyolultabb struktúrálatlan adatokról már nem is beszélve....

Végül az is lehet egy vízválasztó szempont, hogy míg az adatbányász Amazon S3-ig is elmenően tudhat önjáró lenni, addig a Data Scientist-re esetleg még további csoportmunka és/vagy folyamatvezérlésből adódó követelmények is várnak

Ahogy én érzékelem az elmúlt nagyjából 10 (magyarországi) év alapján: az adatbányász, eddig bőven megélt, ha a fent vázolt négy aspektusból legalább az egyikben erős volt, egy Data Scientist-től lehet, hogy elvárás lesz egyformán erősnek lennie mind a négyben, hogy egyre mélyebben értse az egyes aspektusokat egy egyre szélesebben vett interdiszciplináris tudományágban.

A végére maradt a legizgalmasabb aspektus. Van-e különbség Data Miner és Data Scientist között, ha nevezetesen ugyanazt a személyt takarja mindkettő :)

Azt gondolom igen és perdöntő különbség lehet. Még pedig a domain vonatkozásában.

A domain-függetlenség világa az adatbányászversenyek világa, ahol egyetlen pillanatban kell a legjobbat produkálni, az adatok mögött lévő tartalom firtatása nélkül.

Az üzleti világban
- Nem elég egyetlen pillanatban gondolkodni, hiszen ez az éhenhalás útja lenne (a prediktálási stabilitásról már nem is beszélve).
- Nagyon kell tudni érteni az adatok mögötti világhoz.
- Olyan kérdéseket kell tudni megfogalmazni, kicsikarni, ami tízből kilencszer nem jut eszébe az embernek, sőt még a megrendelőnek/szakértőnek sem.
- Úgy kell tálalni (vizualizálni, prezentálni, etc.), hogy ne aludjanak el rajta a hallgatók.
- Olyan üzleti vitákat kell megvívni, ahol nincs jogorvoslati út, nincs bíróság, hogy igazságot tegyen.

Az én nagy kérdésem a jövőt illetően, hogy az egyre komplexebbé váló Data Scientist hogyan fog tudni érdemben kommunikálni a rajta kívül eső világgal.

Update-1: Ahogy olvasom vissza a blogposztot felmerült bennem a kérdés, mennyiben helyes angol "Data Scientist"-et írni a magyar "adatbányász"-szal párbaállítva.  De nem egységesítek. Talán ez is mutatja, hogy míg az "adatbányász" egyre közkeletűbb(en érthető) fogalom, addig a Data Scientist még úgy újabb, hogy magyar megfelelője nem igazán alakult ki.

Update-2: Találtam egy érdekes ábrát. Annyira nem nagy merészség az adatbányászatot a BI részeként tekinteni. Ha ez jogos, akkor máris érdekes kérdés, hogy a BI hogyan viszonyul a Data Science-hez.

Steve Miller: Data Science - Part 2 (2011-05-03)

Data Science-s SQL és Python gondolkodtató feladatok

1.
Kollégáim meg hajdanvolt szép emlékű SQL-levlistások körében tudott dolog volt, hogy mindig szerettem és gyűjtöttem a frappáns (demó, állásinterjús) SQL-feladatokat, amiknek ismérvei:
- Könnyű és rövid legyen elmondani
- Ne legyen benne félreértési lehetőség (egyértelműség mindenek elött)
- Rövid ám elegáns legyen a megoldás
- Annyira azért ne legyen triviális.
- stb.

Sikerült beleszaladnom egy nagyon szép SQL-feladatba.

- Adott két - egyszerűség kedvéért - 10.000 x 10.000 négyzetes, ritka, nem-negatív mátrix.
Mivel ritkák a mátrixok így csak a nullától különböző elemeket tároljuk (sor,oszlop,érték)

- Írjunk egy - akár Sqlite-ban is futni tudó - SQL-t, amelyik tetszőleges általunk választott elemét megadja a szorzat-mátrixnak.


2. És egy komplementer nem-SQL (hanem Python-) feladat is, ha az előbbi túl gyorsan meglenne :)

- Szedjük le a Twitter forgalmának (egy részét)!

- Ignoráljuk a nem angol nyelvű üzeneteket!

- Ignoráljuk az USÁ-n kívül feladott üzeneteket!

- Rendeljük hozzá az üzenetek szavaihoz egy-egy érzelmi koefficienst (szótár alapján)

- Kreáljunk a szótárban nem létező egyéb szavakra - lehetőség szerint minél intelligensebben - érzelmi koefficienst (ha a szöveg környezetben inkább pozitív szavak vannak, akkor nagyobbat, ha inkább negatívak, akkor kisebbet)

- Határozzuk meg , hogy a Twitter-üzeneteket melyik USA-államban adták fel (ugye a mobiltelefon meghatároz egy geolokációs kódot, abból kell valahogy kitalálni az USA-államot).

- Mindezt azért, hogy végül megmondhassuk, hogy melyik a legboldogabb USA-állam, a lekapott Twitter-adatforgalom pillanatában (vagyis, ahol összesítés után a legtöbb pozitív érzelmű twitter-üzenetet adták fel és egyúttal legkevesebb negatívat)