1 / 74

Dotazování nad proudy dat

Dotazování nad proudy dat. NDBI001 10.12.2013, Jan Drozen. O čem bude řeč. Úvod Motivace Dotazování Algoritmy Shrnutí. Úvod. Systém řízení proudu dat. DBMS > DSMS DSMS je nadmnožina DBMS Dají se simulovat pomocí procedurálních prostředků v DBMS. Rozdíly DBMS oproti DSMS. DBMS. DSMS.

bob
Download Presentation

Dotazování nad proudy dat

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

More Related