Prezentace se nahrává, počkejte prosím

Prezentace se nahrává, počkejte prosím

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

Podobné prezentace


Prezentace na téma: "Dotazování nad proudy dat NDBI001 10.12.2013, Jan Drozen."— Transkript prezentace:

1 Dotazování nad proudy dat NDBI , 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  Data trvale uložená  Možnost náhodného přístupu  Jednorázové dotazy  Velká sekundární paměť (TB) DSMS  Proudy jsou dočasné  Pouze sekvenční zpracování  Dlouhotrvající dotazy  Omezená primární paměť (GB)

6 Rozdíly DBMS oproti DSMS - pokračování DBMS  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 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

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:  SELECTupozorniOperatora(SUM(delka)) FROMB GROUP BYminuta(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:  SELECTidProudu, zdroj, cil, SUM(delka) AS delkaProudu FROM(SELECTzdroj, cil, delka, cas FROMB ORDER BYcas) GROUP BY zdroj, cil, ziskejIdProudu(zdroj, cil, cas) AS idProudu  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(*) FROMC,B WHEREC.zdroj = B.zdroj AND C.cil = B.cil AND C.id = B.id) / (SELECTCOUNT(*) FROMB)  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 ( SELECTzdroj, cil, SUM(delka) AS provoz FROMB GROUP BYzdroj, cil ) SELECTzdroj, cil, provoz FROMvytizeni AS L1 WHERE(SELECTCOUNT(*) FROM vytizeni AS L2 WHEREL2.provoz (SELECT0.95 * COUNT(*) FROMvytizeni) ) ORDER BYprovoz

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 update a computeAnswer ?  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 DatA Manager  Prototyp implementace DSMS  Dotazovacím jazykem je rozšíření SQL  Umožňuje FROM klauzulí referencovat relace i proudy dat  Podpora dotazů nad klouzavými okny

43 STREAM – klouzavá okna

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 FROM klauzuli  Pomocí hranatých závorek 1. Klauzule rozdělující proud do skupin – okno pro každou skupinu 2. Velikost okna  Ve „fyzických“ jednotkách – např. počet prvků okna  V „logických“ jednotkách – např. počet dní 3. 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 MINUTES PRECEDING )

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) FROMhovory AS S [PARTITION BY S.id_zakaznika ROWS 10 PRECEDING WHERE 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) FROMhovory AS S [PARTITION BY S.id_zakaznika ROWS 10 PRECEDING] WHERES.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.minut FROMhovory AS S, zakaznici AS T WHERES.id_zakaznika = T.id_zakaznika AND 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ě)

51 Časové známky - pokračování  Problém s explicitními známkami prakticky znemožňuje použití s klouzavými okny  Pokud je proud „téměř“ setříděný, menší odchylky lze jednoduše řešit pomocí mezipamětí

52 Časové známky - přidělování  Binární operátory vytvářejí nové prvky – je potřeba jim určit známky.  Neřešit pořadí  Pštrosí taktika  Předpoklad, že dříve příchozí prvky operátor také dříve opustí  Implicitní  Pořadí určí uživatel explicitně  Pořadí odpovídající pořadí proudů ve FROM klauzuli  Může vzniknout více prvků se stejnou známkou

53 Časové známky – příklad  SELECT* FROMS1 [ROWS 1000 PRECEDING], S2 [ROWS 100 PRECEDING] WHERES1.A = S2.B  Výstupní n-tice budou setřídění podle známek S1. Uspořádání vůči S2 je ztraceno  Potenciálně nutnost udržovat data v mezipaměti  Pro zajištění správného pořadí  Může se stát, že přijdou další data v S2, která se spojí s daty v S1, která mají menší známky a patří do současného okna

54 Časové známky - problém  Tento problém se může propagovat stromem dotazu  Použití 1. nebo 2. způsobu přidělování závisí na konkrétní aplikaci  1. způsob pro zvýšení výkonu – použití oken pro aproximaci  2. způsob pro explicitní sémantiku oken

55 Časové známky – rozlišení přidělování  STREAM umožňuje v dotazu určit způsob přidělování známek  Definuje klíčová slova:  PRECEDING  odpovídá 2. způsobu  RECENT  nové klíčové slovo  odpovídá 1. způsobu  DSMS si může sám určit pořadí n-tic  možno použít pouze s fyzickou specifikací velikosti okna

56 STREAM – vykonání dotazu  Exekuční plán (podobně jako v DBMS)  Skládá se z prvků:  Operátory  Fronty (spojují operátory)  Synopse (používají je operátory jako pomocné datové struktury)  Existují i implementace se sdílenou frontou pro všechny operátory (Aurora, Eddies)

57 STREAM – vykonání dotazu – pokrač.  Operátory plánuje centrální plánovač  Během vykonávání dotazu operátor čte data z fronty, aktualizuje synopsi, která mu náleží a zapíše výsledek do výstupní fronty  Operátor pracuje po dobu, kterou mu určí plánovač  Po vypršení této doby předá řízení zpět plánovači

58 STREAM – vykonání dotazu – pokrač.  Protože uvažujeme i dlouhotrvající dotazy, je potřeba zohlednit měnící se stav systému  Např. počet konkurentních proudů, množství dotazů, dostupná paměť  Operátory musí být adaptivní

59 Algoritmy

60

61 Metriky srovnání algoritmů

62 Náhodné vzorkování  Předpokládá se použití v systému, kdy malý vzorek dat zachycuje jejich charakteristiku  V závislosti na požadovaných vlastnostech se používají různé algoritmy pro vzorkování (např stratified sampling)

63 Sketch  Vytváří malý vzorek proudu (v malé paměti)  Používají se hašovací funkce pro výpočty distribuce prvků v proudu

64 Histogramy  Struktura používaná pro sumarizaci dat  Znázorňuje distribuci dat v množině  Dají se použít na odhad velikosti dotazu, aproximativní odpovědi, data mining...  V-Optimální histogram  Rovnoměrný histogram  End-Biased histogram Zdroj: Wikipedia

65 V-Optimální histogram Zdroj:http://www.mathcs.emory.edu/~cheun g/Courses/584-StreamDB/Syllabus/06- Histograms/v-opt1.html

66 Rovnoměrný histogram

67 End-Biased histogram

68 Vlnky (wavelets)  Technika pro sumarizaci dat  Používá projekci hodnot na ortogonální bázový vektor  Je možné data zpět lehce rekonstruovat

69 Shrnutí

70  Viděli jsme množství vlastností a problémů, které s sebou přináší zpracování proudů dat  Položme si na závěr otázky, které souvisejí s motivací:  Je efektinější DSMS nebo DBMS s podporou triggerů, dočasných objektů,...?  Je potřeba vyvíjet univerzální systém nebo je lepší řešit každý problém speciálně?  Existují nějaké „killer apps“ pro DSMS?

71 Shrnutí  Pokud si odpovíme ano, znamená to řešit všechny problémy, se kterými jsme se setkali  Časové známky, klouzavá okna, blokující operátory,...  i nesetkali  Distribuované DSMS  Z pohledu dotazovacího jazyka  je lepší rozšířit SQL nebo použít něco úplně jiného?

72 Zdroje  B. Babcock, S. Babu, M. Datar, R. Motwani, J. Widom: Models and Issues in Data Stream Systems, Stanford University  Data stream management systems na Wikipedii

73 Prostor pro otázky? „Ptejte se mě na co chcete, já na co chci odpovím.“

74 Děkuji za pozornost.


Stáhnout ppt "Dotazování nad proudy dat NDBI001 10.12.2013, Jan Drozen."

Podobné prezentace


Reklamy Google