Na és mi a helyzet a CQRS-szerverekkel

.
Command/Query Responsibility Segregation lenne ennek a posztnak a témája (ES=Event Sourcing nyomán), de alapvetően jelzésértékkel csak. Nagyon sok, komoly pozitív impulzus ért a témában, de muszáj leülepednie, érlelődnie bennem, ahogy a VirtDB-nek is, Alteryx-nek is.

A legjobb hír, hogy már ebben a korai fázisban is látható, hogy minden mindennel (jó értelemben) összefügg, valós problémák detektálódnak, és ezek valid válaszokat váltanak ki az iparból. A fókusz egyre inkább elmozdul a "hogyan vegyünk ki sok pénzt ügyfeleink zsebéből"-ről "hogyan oldjuk meg legjobban a legkínzóbb problémákat"

Nyilván most is lehetnek tévedések, túlspilázások (lásd a Pivotal Hawq esetét, ami máig feldolgozatlan sebet ütött rajtam például, dacára, hogy nem nagyon volt szó róla itt a blogban). De egy masszívabb közösség jobban ellenáll a vadhajtásoknak.

Többféle nyomás van az analitikában érdekelt kollégákon
* Marha drágák az adattárházak, nehezen térülnek meg, cserébe gyorsan avulnak és/válnak inkonzisztenssé, még nehezebb cserélni/aktualizálni őket (túl fájdalmas az operáció).
Hányszor láttam már életemben 2000 óta, hogy ott a "remek" adattárház, aztán a kollégák MS-Access-szel küzdenek az adattárház megkerülésével. Ilyenkor a lelkem egy kis darabja mindig meghalt.
* Miközben dőlnek ránk az adatok, extenzíven-intenzíven exponenciálisan növekedve.
* Ordít a elosztott rendszeres skálázás jól kitalált lehetősége, igénye. Nemcsak szimplán hardver, hanem ad absurdum szervezet-skálázás szinjén is.
* Megkerülhetetlen kérdés az agilitás mellett a szinkron-aszinkron feature korrekt szemlélete. Analógia: nem mindegy, hogy egy (globális) meetingen szinkron módon egyszerre kell ottlennie mindenkinek, avagy aszinkron módon például mail-váltással történik az információcsere.
* Többé-kevésbé erősen, de érezzük, hogy manapság már több kell DW címszó alatt, mint E-T-L, query-támogató restrukturálással, ha azt akarjuk ne nőjenek fejünkre a problémák.

Alapvető tévedés/illúzió:
* Nem az a lényeg, hogy minden egy helyen legyen, hanem minden elérhető legyen mindaz (és csak az?), amit használunk.
* Különböző típusú, minőségű adatokat elméletileg is más-más metódus szerint kell információ-kiaknázás alá vetni, más-más optimalizálási eljárás révén. Van ahol az idő, van ahol a komplexitás kezelése, van ahol a változásmanagement kapja a fő fókuszt. Ahol egy jó dashboard elégséges, ne akarjuk már felesleges egyéb körökkel megterhelni előállását.
* Számolatlanul öntöttük a pénzt különféle pl.: MQ/ETLeszközökbe, hogy így úgy replikáljunk éppen legfontosabb központi "egyetlen" szinkron módon elérhető helyre, jelentősen diverzifikálva az erőforrásokat, sokszor a használhatóság rovására. Ahol statikus az adattömeg léptéke, ott még ma is lehet ez a megközelítés életképes, mondjuk korszerűbb technológiákkal (pl.: VirtDB)
*Ahol az adatnövekedés léptéke átlépett egy kritikus tömeget, ott már alapjaiban új megközelítések kellhetnek.Szándékosan kerülöm egyébként a homályos undefinit ám már devalválódott "Big Data" fogalmát.

Apache Kafka + InfluxDB új szemlélete:
* DW-nk adatainkra tekintsünk úgy, mint log-olódó eventek sorozatára. Sőt nemcsak sorozatára, hanem időrendbe vágott sorozatára, ha már skálázni is szeretnénk ugye. Fontos a precíz megközelítés, itt nem símán a megszokott logokról beszélünk, annál minőségileg sokkal többről van szó. Több helyen felhasználható potenciálisan több/fontosabb információt hordozó adatokról beszélünk. Másik oldalról csupán csak más szemüvegen keresztül tekintünk DW-ben levő adatainkra.
* Ez az időrendbevágás bizony kulcskérdés és bizony mind elméletileg, mind gyakorlatilag nagyon nehéz probléma. Van aki logikai tervezési úton keresi a megoldást (Apache Kafkánk), de a Google a fizikai megközelítést erölteti a Spannerében.
* Egy Oracle RDBMS-nél ma már sokszor fel sem merül bennünk annak a nagyszerűsége,hogy egyszerre, totálisan egy időben párhuzamosan tud sok ember db-be rögzíteni, és bármikor selectálunk belőle, jól tudunk selectálni.
*A sorrendbe vágáshoz az elosztott rendszerek kontextusában létezik a "primary backup" metódus, amikor egyidejű tranzakcióknál egy vezér választódik ki és létezik a "state-machine replication" az "active-active" tanzakciók kezelésére. Teoretikusan is biztosítható , hogy a "consensus" meg tudja oldani az idősorok lineáris sorrendbe vágását.
* Ezekkel a problémákkal már a CDC(=Change Data Capture) technológiáknál is lehetett küzdeni korábban, de az elosztott (heterogén) rendszerek skálázási igénye új - tegyük hozzá sok mindent rendbetevő - dimenziót képes adni az egész problémakörnek.
* Mert ha már itt tartunk, akkor a jól előkészített log-ok nagyon jól hadra foghatók okosságok kinyerésére, az "új" idődimenzió bevonódásával, a könnyebb aszinkron utakon is.

Kafka-Alternatíva többek közt, jelezve a hot topic jelleget.
* Datomic
* Clojure atyjától, ami Clojure az Apache Kafka DSL nyelveként is előkerül
* Architecture
* Teljes sztori(Database Deconstructing), youtube-videón, 30.000+ megtekintéssel, 1% dislike-kal, 66 percben.

DW-Architect-ek új kiinduló pontja
Az egyik mindenképpen a lambda-architektúra. Ez egyszerre rendkívül problémás, közösséget megosztó, nagyon nehéz topik, ami halmozottan generálja a naprakészség igényét is. Magyarán minden ellene szól ;) Mégis a komplexitás uralására az egyik legjobb "framework".
Az a legfrissebb újoncnak is kell látszódjon belőle, hogy a DW-architect szerepköre "kicsinykét" újraértelmeződik benne.

Az adatbányásznak alkalmazás oldalról meg ott a terülj-terülj asztalkám:
- Stream Miningtól elkezdve
- Process Mining-ig (minap fejeződött be a Coursera-n egy kurzusa)
az új és régi eszközök teljes arzenálja.
De ez már egy másik poszt témája kell legyen mindenképpen.

Konklúzió:
* Lehet tobzódni az élvezetekben wing2wing teljes "skálán", ahol még a tévedés is funny.
* Más megközelítésben az egész hóbelevancot lehet újratanulni. Mert a 3GL-hez képest egy SQL-re átállás kismiska, egy Clojure-ben való programozásra való átálláshoz.
;)