Dotazování nad proudy dat NDBI , Jan Drozen

O čem bude řeč  Úvod  Motivace  Dotazování  Algoritmy  Shrnutí

Úvod

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

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

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í

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

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

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

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

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

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

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

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ěť

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

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

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

Ř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  List  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 MINUTES PRECEDING )

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  SELECTAVG(S.minut) FROMhovory AS S [PARTITION BY S.id_zakaznika ROWS 10 PRECEDING WHERE 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  SELECTAVG(S.minut) FROMhovory AS S [PARTITION BY S.id_zakaznika ROWS 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“  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]

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

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

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: 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.