Your SlideShare is downloading. ×
Dotazování nad proudy dat
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Dotazování nad proudy dat

58
views

Published on

Lehký úvod do problematiky dotazování nad data streamy.

Lehký úvod do problematiky dotazování nad data streamy.

Published in: Education

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
58
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Dotazování nad proudy dat NDBI001 10.12.2013, Bc. 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  Data trvale uložená  Proudy jsou dočasné  Možnost náhodného přístupu  Pouze sekvenční zpracování  Jednorázové dotazy  Dlouhotrvající dotazy  Velká sekundární paměť (TB)  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 DSMS  Data závislá na pořadí na vstupu  Velmi velmi častý zápis  Relativně statická povaha  Rychlost velmi důležitá  Menší nároky na rychlost   Očekáváme přesné deterministické výsledky 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ý  Vlastní systém pouze pro danou úlohu ř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–  cil– IP adresa odesilatele IP adresa příjemce – identifikační číslo generované odesilatelem, aby příjemce mohl jednoznačně identifikovat paket  id  delka – délka daného paketu – informace o tom, kdy byl daný paket zaznamenán  cas
  • 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 B GROUP BY minuta(cas) HAVING SUM(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 delkaProudu FROM (SELECT zdroj, cil, delka, cas FROM B ORDER BY cas) 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 (SELECT COUNT(*) FROM C,B WHERE C.zdroj = B.zdroj AND C.cil = B.cil AND C.id = B.id) / (SELECT COUNT(*) 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 V monitorovat páry zdroj – cíl 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 provoz FROM B GROUP BY zdroj, cil ) SELECT zdroj, cil, provoz FROM vytizeni AS L1 WHERE ( SELECT COUNT(*) FROM vytizeni AS L2 WHERE L2.provoz < L1.provoz) > (SELECT 0.95 * COUNT(*) FROM vytizeni) ) ORDER BY 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é  Zahrnují  dotazy (one-time queries) i zmiňované DBMS dotazy Rozlišujeme, protože existují i jiné dotazy  Dlouhotrvající  Přidaná dotazy (continuous queries) 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é  Vytvořené (ad-hoc) 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  Pro navržené na dlouhotrvající dotazy 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í Typické  aktuální data 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  Typicky malá  Menší  nebo sketch (skica) 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í V uzel 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   3. 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 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 pořadí cas je časovou známkou určující
  • 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  SELECT AVG(S.minut) FROM hovory 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  SELECT AVG(S.minut) FROM hovory AS S [PARTITION BY S.id_zakaznika ROWS 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“  SELECT AVG(V.minut) FROM (SELECT S.minut FROM hovory AS S, zakaznici AS T WHERE S.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 * FROM S1 [ROWS 1000 PRECEDING], S2 [ROWS 100 PRECEDING] WHERE S1.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á  DSMS si může sám určit pořadí n-tic  možno okna 1. způsobu použít pouze s fyzickou specifikací velikosti
  • 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. Algoritmy 
  • 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/06Histograms/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. Shrnutí  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.