Milyen napjaink menő adattárházas szakembere?

.
Na evvel a blogposzttal tuti biztos kivágom a biztositékot.
De egy életem, egy halálom én bizony megírom, mit gondolok a témáról aktuálisan. :)
Természetesen az alábbiak nemzetközi környezetre  vonatkoznak. A magyar piaccal annak nagyságrendje és speciális visszásságai miatt nem kívánnék foglalkozni (most sem).

A téma (nálam) rögtön kettéágazik
- menedzserre
- fejlesztőre

A menedzserről kevesebbet szeretnék most beszélni.
Részint triviálisabb, részint emiatt kevésbé izgalmas.


Nálam a követelmények egy jó adattárház-menedzser felé 

- Perfekt angol tudás, nem szimplán "tárgyalóképes", hanem bizalmat keltően jó, használója képes megfelelő árnyaltsággal érvelni, vitatkozni. Amit én megfelelően perfekt angol tudásnak képzelek, ha valaki bármilyen pénzes angol szakmábavágó tanfolyamot, kurzust képes megtartani (úgy, hogy felkérik rá).

- Képes érdemben megszólítani (egy személyben) mind az üzleti területet (akik biztosítják általában a projekthez a budgetet), és persze mind a szakmai területet is. Az üzleti terület megszólítása külön nagy kihívás, hiszen az adattárház-építés a legelső és legnagyobb falat a vállalati üzleti intelligencia megalapozásában, ami a legtöbb pénzt szokta vinni, legkevésbé látványos és közvetlenül használható eredmények nélkül.

- Van fedezet a mondandója mögött, azaz le tud vezényelni sikeresen egy adattárház-építési projektet.

Én hosszú ~30 éves pályámon, 2, azaz kettő ilyen emberrel találkoztam csak (és sajnos én nem tartozom közéjük). Természetesen nem mondok neveket. ;)


Nálam (én fogalmaim szerint) a következő követelményeknek kell megfelelnie egy jó adattárházas szakembernek:

- A legminimálisabban értenie kell angol szakszövegeket (minél kevesebb szótározással), és minimálisan chatelnie kell tudnia angolul.

- Tetszőleges SQL, tárolt eljárások (4GL) olvasása, írása. Nálam ez második helyen van. ;) Megfordítva: nem tudok elképzelni jó adattárházast, jó SQL-tudás nélkül.Sőt én igazándiból ezt üzleti emberektől is szeretem megkövetelni az egzakt kommunikáció jegyében (más jó alternatíva hiányában). Az olvasás egyre inkább tért követel egyébként magának, hiszen ma már éppen annyit kell hegeszteni meglévő adattárházakat, mint újat építeni, ha nem éppen egyenesen jóval többet.

- Bármilyen SQL-t 90% ban egy napon belül meg kell tudnia írnia. Kb. 10% maradhat csak az igazán durva, napon túlnyúló SQL-eknek.

- Mainstream RDBMS-ektől nem szabad "megijednie", de jó, ha az egzotikumok irányába is nyitott (Hive, NoSql, XML etc). Szerethet különféle adatbázisokat elérő toolokat, de a fontosabbakat jó, ha már párszor aktívan használta.

- Tetszik nem tetszik, a világ abba az irányba halad (szvsz), hogy valaki ne egy valamihez értsen nagyon jól (bár van ma is akinek ez kell és meg is fizeti), hanem mielőbb, minél kisebb overheaddel be tudjon kapcsolódni, minél több típusú projektbe. Azaz nem OWB, ODI, Datastage van/számít, hanem GUI-s ETL-workbench ;) Ráadásul, ahogy én érzékelem, örvendetes módon már hódítanak az open source cuccok.

- Komoly reverse engine képességek birtoklása, gyakran tapasztalható hányadék (módon megírt és/vagy formázott) SQL-ekre is, vagy például tetszőleges riportoló eszközben adatforráshoz jutás. Sőt Data Lineage visszakövetése riportból forrásrendszerig. Sőt! Ennek vége, hogy valaki üzleti logikát is fel tudjon deríteni, aluldokumentáltság esetén is.

- ETL-jobot kell tudni módosítani, írni ugyanabban a "stílusban", ahogy a projektben szokás (verziókövetéssel, csoportmunkatámogatással), QA-ra PROD-ra menedzseléssel.

- Meg kell tudja mondani szabványos eszközök használatával, hogy maradt-e ki valamilyen futásra előírt töltés. (Adathiány, adatminőségi problémák felderítésének támogatása)

- Ismételhető futás felismerése tetszőleges ETL-job esetén (pl.: inkrementálissal szemben). Ennek vége, hogy a konzisztens jó állapothoz való teendők azonosításra kerülnek.

- Adatreplikálás minél több módjának ismerete.

- Operációs rendszer ügyben én csak egyet állítanék/követelnék: unix/linux esetén vi/vim-mel tudjon valaki file-t szerkeszteni, ne valamiféle Windowsos workarounddal.

- A durván Custom ETL-es követelményekkel szemben én megengedőbb vagyok. Ugyanis nem szeretem őket támogatni. Mindenféle további munkák erőforrásigényét, sikerességét exponenciálisan rongálják. Ezért is maradt ez a szempont a legvégére. ;)