Dotazování nad proudy dat

215 views
149 views

Published on

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
215
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Dotazování nad proudy dat

  1. 1. Dotazování nad proudy dat NDBI001 10.12.2013, Bc. Jan Drozen
  2. 2. O čem bude řeč  Úvod  Motivace  Dotazování  Algoritmy  Shrnutí
  3. 3. Úvod
  4. 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. 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. 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. 7. Motivace
  8. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 21. Dotazování
  22. 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. 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. 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. 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. 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. 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. 28. Aproximace - pokračování  Různé techniky pro aproximace:  Sketch  Náhodné vzorkování  Histogramy  Vlnky (wavelets)  Předmětem výzkumu
  29. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 43. STREAM – klouzavá okna 
  44. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 59. Algoritmy
  60. 60. Algoritmy 
  61. 61. Metriky srovnání algoritmů 
  62. 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. 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. 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. 65. V-Optimální histogram  Zdroj:http://www.mathcs.emory.edu/~cheun g/Courses/584-StreamDB/Syllabus/06Histograms/v-opt1.html
  66. 66. Rovnoměrný histogram 
  67. 67. End-Biased histogram 
  68. 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. 69. Shrnutí
  70. 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. 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. 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. 73. Prostor pro otázky? „Ptejte se mě na co chcete, já na co chci odpovím.“
  74. 74. Děkuji za pozornost.

×