Systémy řízení proudů dat Tomáš Herceg Dotazovací jazyky I MFF UK 2011
Agenda Motivace Dotazování nad proudy dat a problémy STanford StREam DatA Manager
Datový proud (Data Stream) data přicházejí průběžně (on-line) není kontrola nad pořadím zpracování ať už v rámci 1 nebo více proudů potenciálně neomezená velikost proudu typicky mnohem větší než operační paměť po zpracování se data zahazují nebo archivují nemůžeme se k nim vracet (rozumně rychle)
Motivace nové typy aplikací práce s daty "v reálném čase" Příklady finanční aplikace sledování sítí webové aplikace sítě senzorů
Příklad v každé místnosti jsou 3 pohybová čidla pokud všechna 3 čidla v intervalu 10 sekund zjistí pohyb, v místnosti někdo je pokud během 20 sekund 1 čidlo 2x zjistí pohyb, ale ostatní čidla ve stejné místnosti ne, pak se čidlo porouchalo
Aplikace Traderbot webový vyhledávač nad finančními ukazateli vyhledává v reálném čase ipolicy Networks firewall, detekce útoků a vetřelců v sítích, filtrování na základě URL Clickstream sledování pohybu uživatelů ve velkých webových aplikacích
Zásadní otázka Vyžaduje tento problém specifické řešení? Nestačí použít relační databázi?
Potíže při použití relační databáze Příchozích dat je mnoho velké množství INSERT operace Mají dočasnou platnost velké množství DELETE operací Neustále musíme kontrolovat velké množství SELECT operací
Potíže při použití relační databáze Klasické relační databáze nejsou pro toto chování optimalizovány Zpracování proudů dat vyžaduje dlouhotrvající dotazy nepřetržité dotazy aproximace některé dotazy vyžadují neomezené množství paměti
Příklad Poskytovatel připojení k Internetu B linka v rámci sítě ISP C linka od zákazníka do sítě ISP Paket src IP odesílatele dest... IP příjemce time čas id unikátní ID paketu len délka paketu
Příklad upozornit operátora, pokud za minutu proteče více než dané množství dat SELECT notifyoperator(sum(len)) FROM B GROUP BY getminute(time) HAVING sum(len) > t
Příklad Spočítat data přenesená v rámci "spojení" SELECT flowid, src, dest, sum(len) AS flowlen FROM ( SELECT src, dest, len, time FROM B ORDER BY time) GROUP BY src, dest, getflowid(src, dest, time) AS flowid Agregace a třídění jsou "blokující" operátory
Příklad Počet paketů, které prošly linkami C i B SELECT count(*) FROM C, B WHERE C.src = B.src AND C.dest = B.dest AND C.id = B.id JOIN přes velké sady dat může požadovat neomezené množství paměti pokud chceme přesnou odpověď Přitom drtivá většina paketů se v síti nezdržela
Příklad 5% cest, které přenesly nejvíce dat WITH Load AS ( SELECT src, dest, sum(len) AS traffic FROM B GROUP BY src, dest) SELECT src, dest, traffic FROM Load AS L1 WHERE (SELECT count(*) FROM Load AS L2 WHERE L2.traffic < L1.traffic) > (SELECT 0.95 * count(*) FROM Load) ORDER BY traffic
Existující projekty Tapestry prohledávání e-mailové komunikace podmnožina SQL XFilter filtrování XML dokumentů dotazy v XPath STREAM projekt Stanfordské univerzity
Agenda Motivace Dotazování nad proudy dat a problémy STanford StREam DatA Manager
Typy dotazů Podle délky trvání jednorázové dotazy vrací výsledek ihned výsledek reflektuje okamžitý stav dat dlouhotrvající dotazy výsledek průběžně aktualizuje někdy jej publikuje jako další proud dat výsledek zohledňuje jen data, která již přišla nevrací "absolutní minimum", ale "dosavadní minimum" atd.
Typy dotazů Podle vzniku předdefinované dotazy známé hned od začátku ještě před tím, než přijdou první data ad hoc dotazy zadávány až v průběhu komplikace přesné vyhodnocení může vyžadovat data, která jsme již zpracovali a zahodili
Neomezená paměť Neomezené nároky na paměť nemůžeme si dovolit používat pomalá paměťová média (např. disk) dat je příliš mnoho a není čas typicky když chceme výsledek přesně problém: jak poznat, jestli dotazu stačí omezená paměť JOIN pokud nejsou jednotlivé sady výsledků omezené, můžeme se v budoucnu spojovat s daty, která ještě nevidíme
Řešení aproximace výsledek není úplně přesný ale pro potřeby aplikace dostačuje techniky histogramy vzorkování (sampling) dávkové zpracování (batch processing) posuvné okénko (sliding window)
Posuvné okénko Vyhodnocuje se pouze nad určitým časovým intervalem v nedávné minulosti např. vytížení sítě nás zajímá jen týden nazpět V mnoha situacích lepší co se dělo před 5 lety není tak zajímavé co se dělo před 2 dny má větší vypovídací hodnotu Problém: co když se data v okénku nevejdou do paměti
Vzorkování a dávkové zpracování Proudové zpracování operace update(tuple) a computeanswer() Dávkové zpracování update rychlý, computeanswer pomalý computeanswer se nevolá pokaždé Vzorkování update pomalý update se nevolá na každý záznam, některé se ignorují
Blokující operátory Blokující operátor nemůže začít vracet výsledky, dokud nevidí celý vstup například ORDER BY i agregace AVG, SUM, COUNT, MIN, MAX obtížně realizovatelné vstup je nekonečný Agregace ale potřebujeme velmi často
Blokující operátory Pokud je v kořeni stromu dotazu, řešitelné dotaz vrací stream, výsledek se neustále zpřesňuje Problém: co když ale hodnota sumy závisí na jiném blokujícím operátoru nepřesnosti se násobí operátor musí sledovat, jestli se hodnota jeho operandů nezměnila
Blokující operátory Juggle neblokující třídění snaží se záznamy třídit, ale samozřejmě občas udělá chybu Punctuation speciální podmínky musíme něco vědět o datech, která přijdou např. že datum již bude vždy větší než 1. 1. 2011
Potřeba dat z minulosti ad hoc dotazy již z definice nemusí odpovědět přesnou odpověď většina aplikací se spokojí s tím, že dotaz sleduje jen data od okamžiku, kdy byl položen lze řešit uchováváním statistik o datech v minulosti na jejich základě lze vracet přibližné výsledky je to částečně podobné chybějícímu indexu u relační databáze
Agenda Motivace Dotazování nad proudy dat a problémy STanford StREam DatA Manager
STranford StREam DatA Manager implementace systému pro řízení proudových dat ze Stanfordské univerzity upravený jazyk SQL podpora posuvných okének
Časová razítka implicitní záznamy nemají své vlastní čas záznamu není důležitý, jde jen o rozlišení novějších a starších záznamů, určení pořadí atd. explicitní záznam obsahuje pole s časem události problém: záznamy nemusí přijít ve správném pořadí typicky se řeší bufferingem
Okénka Fyzická odvíjí se od počtu řádků výsledků syntaxe ROWS 50 PRECEDING Logická od časového razítka syntaxe RANGE 15 MINUTES PRECEDING
Příklad datový proud Calls customer_id ID zákazníka type typ hovoru minutes účtovaných minut timestamp doba, kdy hovor skončil
Příklad SELECT avg(s.minutes), S.customer_id FROM Calls S [ PARTITION BY S.customer_id ROWS 10 PRECEDING WHERE S.type = 'Long Distance'] Vrátí průměrnou délku posledních 10 meziměstských hovorů každého zákazníka
Příklad SELECT avg(s.minutes), S.customer_id FROM (SELECT S.minutes, S.customer_id FROM Calls S, Customers T WHERE S.customer_id = T.customer_id AND T.tier = 'VIP') V [ROWS 1000 PRECEDING] Vrátí průměrnou délku posledních 1000 hovorů všech VIP zákazníků
Časová razítka a JOIN Jaké časové razítko má mít záznam, který je vytvořen spojením záznamů ze dvou proudů? buď čas "vytvoření" záznamu operací spojení jednoduché na implementaci přijdeme ale o přesně definované časové okno přidělené časové razítko závisí na aktuálním zatížení systému a mnoha dalších faktorech operace nebude deterministická nebo časové razítko prvního proudu záleží na pořadí proudů v klauzuli FROM potíž se řazením, více záznamů může mít stejné razítko pak se rozlišuje podle časového razítka druhého proudu atd. problém, pokud chceme výsledek operace JOIN setřídit blokující operátor
PRECEDING vs. RECENT U fyzických okének ROWS 1000 PRECEDING striktně vyžadováno řazení podle časového razítka druhý způsob, časově náročnější ROWS 1000 RECENT na pořadí nám tolik nezáleží první způsob, efektivnější Logická okénka vždy používají PRECEDING
Vyhodnocování dotazů
Vyhodnocování dotazů Práce operátorů je přidělována plánovačem jak často provádět vyhodnocování operátoru buď podle času nebo podle počtu záznamů na vstupu operátory jsou adaptivní přesnost vs. dostupná paměť různé politiky plánovače
Shrnutí Motivace Dotazování nad proudy dat a problémy STanford StREam DatA Manager
Zdroje [1] Babcock B., Babu S., Datar M., Motwani R., Widom J.: Models and Issues of Data Stream Systems Dept. of Computer Science, Stanford University, 2002 http://ilpubs.stanford.edu:8090/535/1/2002-19.pdf