Dotazování nad proudy dat
•Als PPTX, PDF herunterladen•
0 gefällt mir•328 views
Lehký úvod do problematiky dotazování nad data streamy.
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Dotazování nad proudy dat
Ähnlich wie Dotazování nad proudy dat (20)
Dotazování nad proudy dat
- 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
- 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
- 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.“