Dotazování nad proudy dat

transcript

Dotazování nad proudy datNDBI001 10.12.2013, Bc. Jan Drozen

O čem bude řeč

Motivace

Dotazování

Algoritmy

Shrnutí

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

Data trvale uložená

Možnost náhodného

přístupu

Jednorázové dotazy

Velká sekundární

paměť (TB)

Proudy jsou dočasné

Pouze sekvenční

zpracování

Dlouhotrvající dotazy

Omezená primární

paměť (GB)

Rozdíly DBMS oproti DSMS - pokračování

Data v přesně

definovaném známém

Relativně statická povaha

Menší nároky na rychlost

Očekáváme přesné

deterministické výsledky

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

Motivace

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ů

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

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í

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

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

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

SELECT upozorniOperatora(SUM(delka))FROM BGROUP 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

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

SELECT idProudu, zdroj, cil, SUM(delka) AS delkaProuduFROM (SELECT zdroj, cil, delka, cas

FROM BORDER BY cas)

GROUP BYzdroj, cil, ziskejIdProudu(zdroj, cil, cas) ASidProudu

ziskejIdProudu vrací identifikátor proudu na základě zdroje, cíle a

GROUP BY a ORDER BY klauzule

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

SELECT(SELECT COUNT(*)FROM C,BWHERE 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ěť

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

WITH vytizeni AS (SELECT zdroj, cil, SUM(delka) AS provozFROM BGROUP BY zdroj, cil)SELECT zdroj, cil, provozFROM vytizeni AS L1WHERE ( SELECT COUNT(*)

FROM vytizeni AS L2WHERE L2.provoz < L1.provoz) > (SELECT 0.95 * COUNT(*)

FROM vytizeni))

ORDER BY provoz

Dotazování

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

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

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

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

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á

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í

Ř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

Aproximace - pokračování

Různé techniky pro aproximace:

Sketch

Náhodné vzorkování

Histogramy

Vlnky (wavelets)

Předmětem výzkumu

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

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

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

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

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)

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

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í

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ů

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

Pro DSMS nepoužitelné

Vnitřní uzel

V DSMS možné

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“

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

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

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ů

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

STREAM – klouzavá okna

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í

STREAM – klouzavá okna - pokračování

Fyzická okna

klíčové slovo ROWS (ROWS 50 PRECEDING)

Logická okna

klíčové slovo RANGE (RANGE 15 MINUTESPRECEDING)

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í

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_zakaznikaROWS 10 PRECEDINGWHERE S.typ = ‘Mezimesto‘]

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_zakaznikaROWS 10 PRECEDING]

WHERES.typ = ‘Mezimesto‘

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 TWHERE S.id_zakaznika =

T.id_zakaznikaAND T.kategorie = ‘Gold‘)

AS V [ROWS 1000 PRECEDING]

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

Č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í

Č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

Č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

Č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

Č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

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)

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

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í

Algoritmy

Metriky srovnání algoritmů

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)

Sketch

Vytváří malý vzorek proudu (v malé paměti)

Používají se hašovací funkce pro výpočty

distribuce prvků v proudu

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

V-Optimální histogram

Zdroj:http://www.mathcs.emory.edu/~cheun

g/Courses/584-StreamDB/Syllabus/06-

Histograms/v-opt1.html

Rovnoměrný histogram

End-Biased histogram

Vlnky (wavelets)

Technika pro sumarizaci dat

Používá projekci hodnot na ortogonální bázový

vektor

Je možné data zpět lehce rekonstruovat

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?

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?

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

Prostor pro otázky?„Ptejte se mě na co chcete, já na co chci odpovím.“

Děkuji za pozornost.

Dotazování nad proudy dat

Education