Dotazování nad proudy dat

1. Dotazování nad proudy dat NDBI001 10.12.2013, Jan Drozen

2. O čem bude řeč • Úvod • Motivace • Dotazování • Algoritmy • Shrnutí

3. Úvod

4. Systém řízení proudu dat • DBMS > DSMS • DSMS je nadmnožina DBMS • Dají se simulovat pomocí procedurálních prostředků v DBMS

5. Rozdíly DBMS oproti DSMS DBMS DSMS Proudy jsou dočasné Pouze sekvenční zpracování Dlouhotrvající dotazy Omezená primární paměť (GB) • Data trvale uložená • Možnost náhodného přístupu • Jednorázové dotazy • Velká sekundární paměť (TB)

6. Rozdíly DBMS oproti DSMS - pokračování DBMS DSMS Data závislá na pořadí na vstupu Velmi velmi častý zápis Rychlost velmi důležitá Mohou (musí) stačit pouze aproximované výsledky • Data v přesně definovaném známém stavu • Relativně statická povaha • Menší nároky na rychlost • Očekáváme přesné deterministické výsledky

7. Motivace

8. Příklady • Tradebot – webový finanční vyhledávač, vyhodnocuje dotazy vůči aktuálním datům • Dnes už neaktivní • iPolicyNetworks – uplatňování různých pravidel ve velkých sítích • Také nedostupné • Synchronizace distribuovaných systémů – Yahoo • Monitorování senzorů

9. Sledování síťového provozu - příklad • Podrobnější motivační příklad • Mějme poskytovatele připojení k Internetu (ISP) • Disponuje rozsáhlou páteřní sítí • Požadavek na trasování paketů a monitorování provozu

10. Sledování síťového provozu – pokr. • Řešení • Specializovaný systém pouze pro danou úlohu • Vlastní řešení • Logování a zpětné offline vyhodnocování

11. Sledování síťového provozu – pokr. • Model sítě: • Linka C propojuje páteřní síť ISP se sítí koncového zákazníka • Linka B propojuje dva routery uvnitř páteřní sítě ISP • B a C označíme proudy trasovacích dat odpovídající provozu na těchto linkách

12. Sledování síťového provozu – pokr. • Trasovací data obsahují hlavičku formátu: • zdroj– IP adresa odesilatele • cil– IP adresa příjemce • id– identifikační číslo generované odesilatelem, aby příjemce mohl jednoznačně identifikovat paket • delka – délka daného paketu • cas – informace o tom, kdy byl daný paket zaznamenán

13. Sledování síťového provozu – pokr. • Chceme umět formulovat dotaz Q1 takový, že: • Spočítá vytížení linky B průměrovaný po minutových intervalech • Pokud vytížení překročí určitou míru t, tak informuje operátora

14. Sledování síťového provozu – pokr. • Q1: • SELECT upozorniOperatora(SUM(delka))FROM BGROUPBYminuta(cas)HAVINGSUM(delka) > t • Možno simulovat pomocí triggerů • Pokud by byl provoz velký (např. optická linka), mohlo by dojít k problémům

15. Sledování síťového provozu – pokr. • Chceme umět formulovat dotaz takový, že: • Filtruje provoz pouze v páteřní síti • Rozdělí provoz na jednotlivé proudy • Určí intenzitu provozu v každém proudu • Proud definujeme jako sekvence paketů mezi určitým zdrojem a cílem

16. Sledování síťového provozu – pokr. • Q2: • SELECT idProudu, zdroj, cil, SUM(delka) AS delkaProuduFROM (SELECTzdroj, cil, delka, casFROM BORDERBY cas)GROUPBYzdroj, cil, ziskejIdProudu(zdroj, cil, cas) ASidProudu • ziskejIdProudu vrací identifikátor proudu na základě zdroje, cíle a času • GROUP BY a ORDER BY klauzule

17. Sledování síťového provozu – pokr. • Chceme umět formulovat dotaz takový, že: • Zjistíme, jakou část provozu páteřní linky můžeme přiřadit síti zákazníka

18. Sledování síťového provozu – pokr. • Q4: • SELECT(SELECTCOUNT(*)FROM C,BWHERE C.zdroj = B.zdroj AND C.cil = B.cil ANDC.id = B.id)/(SELECTCOUNT(*)FROM B) • Operace spojení • Nad proudy dat nemusí stačit paměť

19. Sledování síťového provozu – pokr. • Chceme umět (naposledy) formulovat dotaz takový, že: • Bude monitorovat páry zdroj – cíl • V páteřní síti • Pouze pro 5 procent s nejvyšším vytížením

20. Sledování síťového provozu – pokr. • Q4: • WITH vytizeni AS(SELECT zdroj, cil, SUM(delka) AS provozFROM BGROUPBY zdroj, cil)SELECT zdroj, cil, provozFROM vytizeni AS L1WHERE (SELECTCOUNT(*)FROM vytizeni AS L2WHERE L2.provoz < L1.provoz) > (SELECT 0.95 * COUNT(*)FROM vytizeni) )ORDERBY provoz

21. Dotazování

22. Problémy při dotazování • Prvky proudu dat přicházejí online • Systém nemá kontrolu nad pořadím, v jakém data přicházejí • Potenciálně neomezená velikost • Jakmile je prvek proudu dat zpracován, je archivován nebo zahozen • Pokud chceme jinak, musíme to explicitně vyjádřit

23. Typy dotazů • V klasickém DBMS spustíme dotaz a ten po vykonání vrací výsledky, které zpracujeme • To lze v DSMS samozřejmě také • Jednorázové dotazy (one-time queries) • Zahrnují i zmiňované DBMS dotazy • Rozlišujeme, protože existují i jiné dotazy • Dlouhotrvající dotazy (continuous queries) • Přidaná hodnota DSMS

24. Dělení dotazů • Podle zpracování • Jednorázové • Dlouhotrvající • Podle pokládání • Předdefinované • Známé před začátkem proudu • Jednoúčelové (ad-hoc) • Vytvořené v průběhu

25. Problémy s pamětí • Proudy dat jsou potenciálně neomezené -> proto i dotazy pro zpracování mohou požadovat neomezeně velkou paměť • DBMS pracují s externí (sekundární) pamětí – optimalizované algoritmy • Pro DSMS nemusí být použitelné • Nejsou navržené na dlouhotrvající dotazy • Pro vyhodnocování v reálném čase velká latence • DSMS typicky pro takové aplikace

26. Problémy s rychlostí • V DBMS dotazování nad známými daty • V DSMS při vykonávání dotazu přicházejí nová data • Rychlost zpracování musí být dostatečně vysoká • Jinak velká latence • Hrozí, že budou data zahozena ještě před zpracováním • Dále se omezíme pouze na práci s primární pamětí

27. Řešení problémů - aproximace • Pokud upustíme od požadavku na exaktní odpověď, můžeme se zbavit problémů • Ale omezíme si i výrazovou sílu dotazovacího jazyka • Dotazy vykonávány v omezeně velké paměti • Odpovědi aproximované • Kvalitní aproximace může pro většinu aplikací bez problémů dostačovat

28. Aproximace - pokračování • Různé techniky pro aproximace: • Sketch • Náhodné vzorkování • Histogramy • Vlnky (wavelets) • Předmětem výzkumu

29. Klouzavá okna • Základní myšlenka aproximovaných odpovědí • Nebudeme se dotazovat nad kompletními daty (celá historie proudu), ale pouze nad nějakým aktuálním úsekem • Např. data za poslední hodinu, týden,... • Řada výhod: • Dobře definovaná • Jednoduchá sémantika

30. Klouzavá okna - pokračování • Deterministická • Upřednostňují aktuální data • Typické pro reálné nasazení • Použitelné nejen pro aproximaci, ale i explicitně pro sémantiku • Právě omezení na určitý časový úsek

31. Klouzavá okna - pokračování • Ale i zde přetrvávají problémy: • Co když se ani okno nevejde do paměti? • Náročná implementace • Rozšíření SQL a relační algebry o práci s okny • Předmětem výzkumu

32. Dávkové zpracování, vzorkování, synopse • (batch processing, sampling, synopses) • Další techniky pro aproximativní dotazování • Budeme uvažovat datovou strukturu, do které můžeme zapisovat (inkrementálně se zvětšuje) • Potřebujeme operace: • update(n-tice) • Aktualizuje strukturu, když přijdou nová data • computeAnswer() • Vrátí nové nebo aktualizované výsledky dotazu

33. Operace • Jaká je rychlost updateacomputeAnswer? • Pokud je jedna z nich pomalejší (obě), než je průměrná doba mezi příchozími daty, nastává problém • Zpracování „neudrží krok“ s proudem • Není možné vrátit přesnou odpověď (relativně k uvažované podmnožině proudu)

34. Dávkové zpracování • Update je rychlá, computeAnswer pomalá • Přirozeným řešením je zpracovávat data v dávkách • Data jsou ukládána do mezipaměti (buffering) • Odpovědi jsou spočteny jednou za určitou dobu • Aproximativní v tom ohledu, že odpovědi nejsou v reálném čase

35. Vzorkování • Update pomalá, computeAnswer rychlá • Není možné pro výpočet odpovědi použít všechna potřebná data – přicházejí rychleji, než jsou zpracovávána • Některé příchozí n-tice jsou přeskočeny • Pouze omezená kvalita výsledků • Pro některé aplikace nevyhovující

36. Synopse • Chceme update i computeAnswer rychlé • Aproximativní datová struktura • Synopse nebo sketch (skica) • Typicky malá • Menší než přesná reprezentace • Opět předmětem výzkumů

37. Blokující operace • Blokující operátor je pro dotaz takový operátor, který potřebuje pro svůj výpočet znát všechna data, dříve než vydá jakýkoli výstup. • Např. třídění, COUNT, SUM, MIN, MAX, AVG,... • Záleží na pozici ve stromě dotazu • List • Pro DSMS nepoužitelné • Vnitřní uzel • V DSMS možné

38. Blokující operace - pokračování • Jako kořen může vracet průběžné výsledky dalším operátorům • Pokud je odpovědí jedna hodnota nebo je dostatečně malá - odpovídá jako proud dat – pokud se agregovaná hodnota změní, vrátí ji jako další prvek proudu • Pokud je odpověď delší, je vhodné udržovat datovou strukturu s „aktuálním stavem odpovědi“

39. Blokující operátory - řešení • Namísto blokujících operátorů jako vnitřních uzlů použít neblokující alternativy, které fungují stejně (ale aproximativně) • Např. JUGGLE operátor • Neblokující verze třídění • Přerovnává lokálně data • Negarantuje správný výsledek

40. Blokující operace – řešení pokračování • Punctuation • Rozhodnutí, že s některými daty se již nebude pracovat a mohou být poslána na výstup • Např. den >= 10 • „všechny další atributy den budou mít hodnotu alespoň 10“ • Data s menší hodnotou mohou být zpracována a odeslána

41. Dotazování na starší data • Data nejsou persistentně ukládána • Problém pro jednoúčelové dotazy – některá data již mohla být zahozena – nemožné odpovědět na dotaz přesně • Omezení dotazů pouze do budoucnosti • Omezující, ale v praxi použitelné • Možné udržovat agregované informace o proudu ve specializované struktuře • Zdroj dalších problémů

42. DSMS Stanford STREAM • Stanford StREam DatAManager • Prototyp implementace DSMS • Dotazovacím jazykem je rozšíření SQL • Umožňuje FROMklauzulí referencovat relace i proudy dat • Podpora dotazů nad klouzavými okny

43. STREAM – klouzavá okna • Klouzavá okna potřebují definované uspořádání na elementech proudu • Často dostačují časové známky příchozích dat (implicitní časová známka) • V mnoha případech je třeba definovat explicitně jako součást proudu • Formálně: • Proud dat S sestává z množin dvojic (n-tice, časová známka):

44. STREAM – klouzavá okna - pokračování • Časovou známkou může být čas (nečekaně), ale i identifikátor pořadí • Požadavkem je totálně uspořádaná doména s metrikou • Rozšíření SQL o volitelnou specifikaci okna ve FROMklauzuli • Pomocí hranatých závorek • Klauzule rozdělující proud do skupin – okno pro každou skupinu • Velikost okna • Ve „fyzických“ jednotkách – např. počet prvků okna • V „logických“ jednotkách – např. počet dní • predikát pro filtrování

45. STREAM – klouzavá okna - pokračování • Fyzická okna • klíčové slovo ROWS(ROWS 50 PRECEDING) • Logická okna • klíčové slovo RANGE(RANGE 15 MINUTESPRECEDING)

46. STREAM - příklady • Pro následující příklady uvažujme schéma: • záznamy o telefonních hovorech • atributy: id_zakaznika, typ, minut, cas • atribut cas je časovou známkou určující pořadí

47. STREAM – příklad I • Chceme spočítat průměrnou délku hovoru, uvažujíc pouze 10 posledních meziměstských hovorů pro každého zákazníka • SELECTAVG(S.minut)FROM hovory AS S [PARTITIONBYS.id_zakaznikaROWS 10 PRECEDINGWHERE S.typ = ‘Mezimesto‘]

48. STREAM – příklad II • Chceme spočítat průměrnou délku hovoru, uvažujíc pouze meziměstské z deseti posledních hovorů pro každého zákazníka • SELECTAVG(S.minut)FROM hovory AS S [PARTITION BY S.id_zakaznikaROWS 10 PRECEDING]WHERE S.typ = ‘Mezimesto‘

49. STREAM – příklad III • Chceme zjistit průměrnou délku posledních 1000 hovorů, které uskutečnili zákazníci z kategorie „Gold“ • SELECTAVG(V.minut)FROM (SELECT S.minutFROM hovory AS S, zakaznici AS TWHERE S.id_zakaznika = T.id_zakaznikaAND T.kategorie = ‘Gold‘)AS V [ROWS 1000 PRECEDING]

50. Časové známky • Jsou velmi důležité • V předchozích příkladech jsme používali implcitní • Co se stane, když jsou n-tice původem z různých proudů? • Např. použití operátorů spojení – jakou známku má dostat výsledek? • Explicitní známky mají jiný problém • Data nemusejí přijít v pořadí podle známek (např. vlivem stavu sítě)