Sci-fi aneb Cesta k applience pro vyhodnocování událostí

Úvod:

Prosím berte s mírnou rezervou, čestně prohlašuji, že jsem před napsáním tohoto příspěvku nepožil žádný alkohol ani omamné látky, je to výsledek přemýšlení a k zamyšlení...

V jednom svém projektu na zlepšení logistiky na papíře resp. do šuplíku jsem řešil, sledování velkého množství vozidel v geografickém kontextu (silnice, oblast, zeme atd).

Jde o obecnou úlohu, objekt, jeho stav, jeho pohyb a vazba mezi objektem a geografickym kontextem (vsem vozidlum na dane silnici v useku x-y (oblast) posli zpravu).

Rád bych se s Vámi podělil, jak jsme dopadl, když jsme zkoušel na toto aplikovat hadoop…(na papíře a v pár malých testech).

O čem je Hadoop zde nebudu rozebírat, na to najdete odkazů dost.

Co zajílao mě, že data jsou v rámci zajištění dostupnosti bez HW redundance v systému celkem 3x (na 3 uzlech). Bohužel se jedná o identické kopie (což je ostatně důvodem). Jenže, když si vezmete, jak by ve výše uvedeném případu mohla vypadat vypadat vstupní datová věta:

<timestamp> <object> <action event> <GPS> <direction vector> <object instance info> <aditional structured info>

Když použiji geolokace, tak GPS mi dává k dispozici možnost přiřadit jeden nebo více GIS objektů (úsek silnice, silnice, město, region, země -zjednodušeně).

Vazba mezi objektem a GIS objektem je dynamická, resp. jak se objekt pohybuje, vznikají a zanikají vazby mezi sledovaným objektem a GIS objektem.

Zároveň je třeba zachovávat “instančnost objektu” kdyz daným místem projiždím dvěma jízdami, abych měl možnost data rozlišit.

Když budu toto ukládat do HDFS, tak super, mám tam uloženo, rozdistribuováno víceméně náhodně, resp. jaké jsou zde možné “partitioning” strategy ?

• Objekt - tento se přímo nabízí, ale objekt může jet přes půl Evropy, takže když budu dělat statistiky typu které objekty mi projeli danou oblastí v rozmezí dnů X-Y, tak prohledávám všechna data na přítomnost oblasti, k tomu je třeba určit instanční start a cíl (kontext jízdy).
• Oblast či jiný GIS objekt - podobně, jen když sleduji objekt, opět bych musel číst vše (čímž rozumíme číst na úrovni uzlů)

Když si představíte objem dat pro 100.000 vozidel, s 10ti vteřinovou periodou za 3 roky, tak máte velmi zajímavé číslo…x3 (redundance hadoop) - tak to je tak na 50ti uzlový cluster…(nemám nějak přesně vypočteno). Toto bych musel živit investičně a energeticky….

Protože potřebuji objekty sledovat near-real time, uvažoval jsme i o Sharku, resp. tupples v paměti….ale tam jsme narazil na problém sdílení tupples mezi úlohami…nějak nedomyšleno….

Jak z toho ven….potřebuji mít v paměti resp. rychle dostupné informace o aktivních objektech, statistické reporty ať jdou klidně na disk…

Připomnělo mi to boj s telco CDR záznamy a použitím MPP systémů….jedna dimenze distribuce dat je prostě málo…

Každý výrobce se s tím popral po svém (appliance systémy), které na řadu úloh představují opravdu 100 násobné zrychlení, ale v okamžiku konkurent objemných dotazů ( sada dotazů per sledovaný objekt a sada dotazů per GIS objekt by potřebovali opravdu silné trubky….). Trošku vyjímkou je Oraclovská Exadata, které to vyřešila šalamounsky tzv. inteligentní storage (Oracle Exadata Storage server), který umožňuje pushdown základních filtrů na tzv. chytrou storage (CPU, disky, a hoodně drahý Oracle software, který filtruje datové bloky, případně počítá parciální výsledky a až ty posílá ke konsolidaci do DB serveru (nepřipomíná Vám to něco ? :o)) )

Jenže jak udržet v paměti 100tisíce instancí objektů (vyřešit jejich persistenci) atd…to už by musela být pěkná farma…

Tak jsme přemýšlel, jak by se dalo vyřešit:

• Distribuce dat pro redundanci, ale současně využitelnou pro více partitioning strategy, tj. jednou záznam distribuovat v kontextu objektu, a podruhé /resp. vícekrát hiearchcky) v geo kontextu…abych neměl data 6x (3x přes objekt, 3x přes geo)
• Jak to uživit výkonově, jak umožnit distribuované výpočty, resp. udržení instancí objektů, on-event alerty pro komunikaci s objektem atd…
• Jak by to mohlo fungovat, aby to nepotřebovalo druhý Temelín…(to by se našim Rakouským sousedům nelíbilo…)

Vyšla mi z toho hypotetická architektura:

• Inteligentní distribouvaná storage s vlastní výpočetní kapacitou pro push down filtra (základní selektivita) - typická úloha, načti mi posledních 1000 událostí daného objektu, načti mi události objektů, které se v daném čase měli vazbu na daný GEO objekt….šlo by realizovat jednotlivými uzly distribuovaného výpočetního systmu na bázi PC, ale to mi připadá šíleně neefektivní…
• Využití grafických karet s rozšířenou pamětí - GPUček to má dost (s jejich běžnou rychlostí by dokázalo jedno GPU obsluhovat stovky či tisíce instancí objektů, pamět by musela být trošku větší), persistence (stav objektu v čase opět na iteligentní storage do třetí  kopie dat, organizovaná instančně)
• Alternativa ke grafickým kartám - ARM procesory ve velmi vysoké hustotě typu HP MoonLight…ale i tak by to bylo na několik racků…zase kvůli nižšímu výkonu procesorů

Technické řešení:

• Z pohledu inteligentni storage se mi jeví jako nejlepší jednoúčelové počítače (SSD disk cca 256GB, 4core CPU, RAM 16GB a centrální napájení, 10GbE, nebo PCI-e - zkrátka jednoúčelová krabička s velmi vysokou výpočetni a storage hustotou - CPU nemusí být high-tech, ale zase to nesmí být pomalá potvůrka, OS na bázi Linuxu…velmi velmi ořezaného…(ideálně ala blade šasi, kam se jen strkají další moduly….což je blízko IBM Netezee, i když ta teď integruje na jedné kartě jak storage (disk), tak výpočetní výkon (programovatelná hradla)). Volání API storage (inteligentní API - dej mi události a parametry, persistuj stav, vrať mi stav instance objektu v čase - po určitou dobu pro fail-over). SSD uvažuji kvůli trendu klesající ceny, velmi nízké spotřebě (ono už se zaplatí jen z pohledu dimenzování zdroje, úspory energie a chlazení), i když nic asi nebrání tiered storage (6TB disk jako archív pro data ageing) ušetří několik SSD, ale několikanásobně zpomalí odezvu při historických dotazech na tyto data
• Jeden výpočetní uzel obsahuje v sobě tolik storage modulů, kolik mu umožní sběrnice PCI-e, případně síťový protokol (privátní síť) a propustnost
• Stejně tak obsahuje výpočetní uzel jednu nebo více grafických karet, které umí adresovat resp. volat služby inteligentní storage - případně je zde možné uvažovat právě o specifikcýh řešeních pro distribuovaný computing…ale to už není úplně moje doména…
• A to celé může běžet na Linuxu jako black box…

Je to nejspíš hudba budoucnosti, ale narůstající exploze dat nás k něčemu takovému povede…zkrátka inteligentní applience stroj pro zpracování událostí (eventů, na instancích objektů s možností near real-time vyhodnocování). Vše s nízkou spotřebou, velkou hustotou osazení, a obrovskou datovou kapacitou…

Využití pro další úlohy:

• Pohyb lidí ve městě, optimalizace městské dopravy, dopravní proudy v rámci města, uživatelům nabízí plný komfort (ala navigace s aktuální dopravou - nasedni na tramvaj č.3, která dojede na zastávku xx za 3 minuty, poloha tramvaje,obsazenost, atd)
• Internet věcí - predikce spotřeby energií (elektrická i plyn)  v kontextu regionu GIS oblast - ulice, městská část,  ve vazbě na počasí v daném místě, a především vazba na připojenou rozvodnu - energetici omluví za zkratku)
• Logistika zboží - multimodal, sledování zásilky, od kamionových přeprav, přes kontejnerové, vagóny, až po kusové zásilky (e-shop)
• Válečná resp. vojenská logistika - kvalitní armádní logistika vyhrává války….informační podpora je jeden z nejdůležitějších faktorů - plynulé zásobování (tanky v pohybu, četa v pohybu, nahlášené požadavky na doplnění (spotřeba střeliva  a pohonných hmot od tanku), záchranné operace, po monitoring jednotek (v kontaktu, přesun na pozici, komunikace, kooperace, enemy detection s využitím UAV - pohybující se objekt, můj není, je to nepřítel :o)  atd) 

Zkrátka je hodně lidských i strojových činností, které když se překlopí na události (stavový diagram) a v kontextu Geo dávají velké využití.

Takže hurá do budoucnosti…