Systémy řízení proudů dat

Transkript

1 Systémy řízení proudů dat Tomáš Herceg Dotazovací jazyky I MFF UK 2011

2 Agenda Motivace Dotazování nad proudy dat a problémy STanford StREam DatA Manager

3 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)

4 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ů

5 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

6 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

7 Zásadní otázka Vyžaduje tento problém specifické řešení? Nestačí použít relační databázi?

8 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í

9 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

10 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

11 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

12 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

13 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

14 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

15 Existující projekty Tapestry prohledávání ové komunikace podmnožina SQL XFilter filtrování XML dokumentů dotazy v XPath STREAM projekt Stanfordské univerzity

16 Agenda Motivace Dotazování nad proudy dat a problémy STanford StREam DatA Manager

17 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.

18 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

19 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

20 Ř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)

21 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

22 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í

23 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

24 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

25 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ž

26 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

27 Agenda Motivace Dotazování nad proudy dat a problémy STanford StREam DatA Manager

28 STranford StREam DatA Manager implementace systému pro řízení proudových dat ze Stanfordské univerzity upravený jazyk SQL podpora posuvných okének

29 Č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

30 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

31 Příklad datový proud Calls customer_id ID zákazníka type typ hovoru minutes účtovaných minut timestamp doba, kdy hovor skončil

32 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

33 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ů

34 Č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

35 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

36 Vyhodnocování dotazů

37 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

38 Shrnutí Motivace Dotazování nad proudy dat a problémy STanford StREam DatA Manager

39 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,