Stáhnout prezentaci
Prezentace se nahrává, počkejte prosím
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 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
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.
Podobné prezentace
© 2024 SlidePlayer.cz Inc.
All rights reserved.