Toky dat (Data Streams) Martin Zeman, Pavel Celba, Miroslav Pich

Data Stream Model (1) Nový model zpracování dat Data nejsou uložena jako relace, ale přicházejí po jednotlivých elementech z jednoho či více streamů

Data Stream Model (2) Není možný přímý přístup ke všem datům Data přicházejí průběžně Systém nemá kontrolu nad pořadím v jakém data přicházejí Nekonečně veliký stream Datový prvek bývá po zpracování zahozen nebo uložen (problém s místem)

Proč? Vyvstaly požadavky na nové aplikace, které by byly schopny zpracovávat velké objemy dat online Oblasti Finanční (analýza trhu/burzy) Zdravotnické systémy (monitoring pacientů) Armádní systémy (navádění u raket) IT (bezpečnostní aplikace, monitoring logů na velkých webech– Google, Yahoo)

Dotazy (1) Jednorázové dotazy Průběžné dotazy (continuous query) 1 zpracování z konkrétní množiny dat 1 odpověď pro uživatele Průběžné dotazy (continuous query) průběžně počítány na základě nově přicházejících dat Odpověď ukládána + udpateována posílána do vlastního streamu

Dotazy (2) Předdefinované dotazy Ad hoc dotazy Známé ještě před příchodem jakýchkoliv dat Obecně continuous queries Ad hoc dotazy Jsou zadávány online Obtížně optimalizovatelné Odpověď může být závislá na datech, která již byla zahozena

Motivační příklad Sledování provozu na páteřní síti ISP Data o paketech sbírána z mnoha úseků sítě C – customer link, mezi zákazníkem a ISP B – backbone link, mezi 2 routery páteřní sítě C, B bude potažmo označovat i odpovídající toky dat Zjednodušené hlavičky paketů (src, dest, id, len, time)

Příklad 1 Upozornění na přetížení sítě SELECT notifyoperator(sum(len)) FROM B GROUP BY getminute(time) HAVING sum(len) > t

Příklad 2 Jak velký provoz způsobují jednotlivé toky paketů SELECT flowid, src, dest, sum(len) AS flowlen FROM (SELECT src, dest, len, time FROM B ORDER BY time) GROUP BY src, dest, getflowid(src, dest, time) AS flowid

Příklad 3 Ad hoc continuous query Dotaz spouštěný při přetížení sítě zjistí, zda je zákazníkova síť důvodem přetížení (SELECT count(*) FROM C, B WHERE C.src = B.src AND C.dest = B.dest AND C.id = B.id) / (SELECT count(*) FROM B)

Příklad 4 – nejnákladnějších 5% WITH Load AS (SELECT src, dest, sum(len) AS traffic FROM B GROUP BY src, dest) SELECT src, dest, traffic FROM Load AS L1 WHERE (SELECT count(*) FROM Load AS L2 WHERE L2.traffic < L1.traffic) > (SELECT 0.95*count(*) FROM Load) ORDER BY traffic

Data stream projekty - příklady Tapestry XFilter Xyleme OpenCQ NiagaraCQ Telegraph Aurora

Klíčové problémy Neomezené požadavky na paměť Aproximované odpovědi Sliding Window (posuvné okénko) Techniky aproximace dat Blokující operátory Dotazování na data z minulosti

Požadavek neomezené paměti Data streams mohou být nekonečně veliké, čímž roste i potřeba neomezené paměti, kam by se data uožila (cheme-li přesnou odpověď) Problém pomalého přístupu na disk – zájem o algoritmy, které se omezí na hlavní paměť

Aproximované odpovědi Často stačí ne úplně přesná odpověď Vývoj algoritmů na aproximaci dat

Sliding Windows Dotazy se zodpovídají na úseku dat, za nějaké období V reálném světě je často užitečnější koukat na poslední data, než na celková

Techniky aproximace dat Dávkové zpracování Vzorkování Synopse - vytváření přehledů, obsahů, osnov Máme stream, který podporuje operace Update() a ComputeAnswer() Problém nastává, když nejsme schopni některou operaci zpracovat dostatečně rychle

Dávkové zpracování Hodí se pro případ, kdy je: Operace Update() rychlá Operace ComputeAnswer() pomalá Příchozí data jsou bufferována a výsledek se spočítá, jak čas dovoluje Výsledek nemusí být vždy aktuální Výhodné pro velké množství dat v krátkých časových intervalech

Vzorkování Hodí se pro případ, kdy je: Operace Update() pomalá Operace ComputeAnswer() rychlá Není čas počítat výsledek ze všech dat, protože data přicházejí rychleji, než mohou být zpracována Problém se spolehlivostí výsledku

Synopse Hodí se pro případy, kdy je: Operace Update() i ComputeAnswer() pomalá Struktura dat je různorodá Update() a ComputeAnswer() se neprovádí nad původní reprezentací Je vytvořena alternativní datová reprezentace, nad kterou se operace Update() a ComputeAnswer() dají rychle provádět

Blokovací operátory Blokovací operátory jsou operátory, které nejsou schopné dát výsledek dříve, než vidí všechny svoje parametry Př.: Sum, Count, Avg, Min, Max, Sort, ...

Blokovací operátory (2) Operátory, které jsou v kořeni dotazu jsou jednodušeji zpracovatelné než operátory, které jsou „hlouběji“ v dotazu (vnořený dotaz, join, ...) Výsledkem operátoru v kořeni je: Málo hodnot – je dobré odpověď na dotaz posílat vždy znovu Velké množství hodnot – je dobré spravovat strukturu s aktuální odpovědí

Blokovací operátory (3) Možné přístupy řešení: Nahradit blokovací operátory analogickými operátory, které nejsou blokovací Umístit do proudu dat oddělovače (puctuations)

Neblokovací operátory Jsou aproximací blokovacích operátorů Přinášejí chybu, nepřesnosti Př. Juggle Nahrazuje operátor Sort Lokálně přeuspořádává prvky

Oddělovače v proudu dat Informují o tom, že určité hodnoty atributů v proudu dat se už znovu nevyskytnou Př.: Den >= 10 Můžou se vyhodnotit všechny odpovědi pro data s atributem Den < 10 Join může zapomenout na všechny záznamy s atributem Den < 10

Oddělovače v proudu dat (2) Jsou vhodné pro: Odblokování blokovacích operátorů Snížení paměťových nároků na vyhodnocení dotazu Otázkou k výzkumu zůstává, jak často je nutné vkládat oddělovače do proudu dat?

Dotazování na data z minulosti Chtěli bychom se dotazovat na data z minulosti, která už ale nemusí být dostupná Možné přístupy: Nedovolit dotazu, aby se ptal na data z minula Sumarizovat data z minula pro budoucí dotazi

Sumarizace dat z minula Vyžaduje to rozhodnout se, jakým způsobem budeme data uchovávat Otázka je stejná jako u indexování s tím rozdílem, že jakmile si vzpomeneme, že bychom nějaký nový index potřebovali, tak ho již není možné vytvořit

Rozšíření SQL pro streamy Rozšíření klauzule FROM v SQL, aby se bylo možné odkazovat, jak na streamy, tak na statická data Rozšíření SQL o zpracování dat v posuvném okénku (sliding window) Rozšíření o vlastní časová razítka

Rozšíření klauzule FROM Nepovinná specifikace posuvného okénka obsahuje: Volitelnou rozdělovací (partition) klauzuli Rozděluje data do oddělených tříd Každá třída má své vlastní posuvné okénko Velikost okénka Ve fyzických jednotkách – např. počet záznamů V logických jednotkách – např. počet dní Volitelný filtrovací predikát

Příklady dotazů v rozšířeném SQL Stream záznamů telefonních hovorů – customer_id, type, minutes, timestamp

Příklady dotazů v rozšířeném SQL (2) Průměrná délka posledních 10 meziměstských hovorů: SELECT Avg(S.Minutes) FROM Calls S [ PARTITION BY S.Customer_id ROWS 10 PRECEDING WHERE S.type = ‘Long distance’ ]

Příklady dotazů v rozšířeném SQL (3) Průměrná délka meziměstských hovorů v posledních 10 záznamech: SELECT Avg(S.Minutes) FROM Calls S [ PARTITION BY S.Customer_id ROWS 10 PREDEDING ] WHERE S.type = ‘Long distance’

Příklady dotazů v rozšířeném SQL (4) Průměrná délka posledních 1000 telefonních rozhovorů zákazníků typu „Gold“: SELECT Avg(V.minutes) FROM (SELECT S.minutes FROM Calls S, Customers T WHERE S.customer_id = T.customer_id AND T.tier = ‘Gold’) V [ ROWS 1000 PRECEDING ]

Časová razítka Implicitní X explicitní časová razítka Kdy jsou explicitní časová razítka potřeba? Distribuované proudy dat, které mají vytvořit jeden proud dat Distribuované systémy obecně, např. senzorové sítě

Časová razítka (2) Explicitní časová razítka je výhodné použít, když záznam koresponduje s reálnou událostí ve světě Implicitní časová razítka je výhodné použít, když nás nezajímá přesná doba vzniku záznamu, ale obecné úvahy jako (např. minulé, nedávné záznamy) by nás mohly zajímat

Časová razítka (3) Další problémy: Explicitní časová razítka nemusí přicházet v uspořádaném pořadí Jaké časové razítko přiřadit záznamům výstupního proudu, který je poskládán z několika dalších proudů?

Časová razítka výstupních proudů Možné přístupy k řešení: Předpokládáme, že záznamy, které přicházejí dříve, se v joinu dříve vyhodnotí. Přiřazujeme nová časová razítka výsledkům vyhodnocení. Vhodné pro implicitní časová razítka. Necháme zvolit uživatele, která časová razítka chce zachovat. Např. zachováme časová razítka prvního proudu, který se vyskytne v klauzuli FROM. Vhodné pro implicitní i explicitní časová razítka.

Časová razítka výstupních proudů - příklad SELECT * FROM S1 [ROWS 1000 PRECEDING] S2 [ROWS 100 PRECEDING] WHERE S1.A = S2.B Pro případ uspořádání výsledku při stejných časových razítcích S1 se použije setřídění pomocí časových razítek z S2

Časová razítka výstupních proudů (2) Striktní seřazení podle časových razítek způsobuje prodlevu. Zavedením klíčového slova RECENT nepožadujeme striktní seřazení podle časových razítek.

Architektura zpracování dotazů Plán zpracování dotazů se skládá z operátorů propojených frontami Ke každému operátoru a frontě je přidružena synopsis. Paměť jednotlivým frontám a synopsim se přiděluje dynamicky.

Architektura zpracování dotazů (2) Operátory jsou naplánovány k provedení pomocí centrálního plánovače. Operátor během vyhodnocení načte data z fronty, updatuje synopse a zapíše výsledek do výstupní fronty. Jestliže není dostatek paměti pro výpočet, přechází se k aproximacím.

Architektura zpracování dotazů (3) Otevřené problémy: Jak operátory aproximující výsledek pracující v omezené paměti? Jak maximalizovat přesnost odpovědí při omezené paměti? Jak a kdy realokovat paměť? Jak efektivně najít plán plánovačem, který splňuje požadavky (uvedené výše)?

Algoritmy nad DSMS Hlavním kritériem pro porovnávaní složitosti algoritmů bude prostorová náročnost a rychlost zpracovaní jednoho elementu streamu.

Data-Stream Processing Model Požadavky pro algoritmy nad streamy: - Jednoprůchodové - Zabírají málo místa - Real-Time - Delete-Proof

Náhodné vzory (Random Samples) Používá se jako shrnující struktura v mnoha případech, kdy stačí málo vzorů na zachycení podstatných charakteristik dat. Je to nejjednodušší forma shrnutí Jiné souhrny (synopse) jsou postavené na této metodě

Sketching techniques Cílem je vytvořit výběr zabírající málo místa pro distribuční vektor f(i)(i=1,…,N) Základní konstrukce: Náhodná lineární projekce funkce f() se rovná projekci do skalárního součinu vektorů f, viz vzoreček. ξ = vektor náhodných hodnot z vhodného rozdělení

Binary-Join COUNT Query Příliš náročné řešení na prostor O(N).

Sketching Techniques Použije se náhodná projekce funkce f() pro definování náhodné veličiny X pro kterou platí, že: - je snadno spočitatelná nad streamovanými daty - E[X] = COUNT(R JoinA S) - Var[X] je malá Hlavní myšlenka: - Definuje se množina “4-wise independent” {+1, -1} náhodných hodnot: {ξi: i=1,…,N } - Pr[ξi=+1] = Pr[ξi=-1]=1/2 - Očekávaná hodnota každého ξi, E[ξi]=0 - Proměně ξi jsou “4-wise independent” - očekávaná hodnota součinu čtyř rozdílných ξi je rovná 0.

Sketch Construction Spočítá se náhodná veličina: a Definujeme X = XRXS jako odhad pro “COUNT query”

Dôkaz

Histogramy Histogramy dokáží stručně zachytit distribuci hodnot v datové množině. Jsou využívány pro odhady velikosti dotazu, přibližné odpovědi a datamining. Používané histogramy v data stream modelech: - V-Optional Histogram - Equi-Width Histogram - End-Biased Histogram

V-Optimal Histogram Aproximuje po částech konstantní funkci f množinou hodnot v1,...,vn, tak aby se minimalizovala chyba:

Equi-Width Histogram Všechny sloupce mají stejnou šířku. MaxErr (<X) = 0.5Freq(XB) Je jednoduchý na vytvoření a udržování

End-Biased Histograms Sloupce s frekvenci větší než je práh jsou zobrazeny přesně, zbytek je aproximován do jednoho sloupce Je jednoduchý na vytvoření a udržování Vhodný pro mnoho aplikací jako je Data Mining, Market Basket Analysis, Data Warehouse, Information Retrieval, ...

Wavelety Wavelety jsou často používány jako technika na vytvoření shrnujících dat Koeficienty waveletu jsou projekcí daného signálu do ortogonální množiny bázových vektorů Pro DB jsou z důvodu jednoduchého výpočtu používaný Haarovi wawelety Používají se při počítaní multi-dimensionálních agregací, „data cube“ aproximací, selektivních odhadů, apod.

Sliding Windows (posuvná okénka) Zabrání starým datům ovlivnit analýzy a statistiky Poskytuje nástroj na omezení použité paměti

Další algoritmy Data Mining: - Decision Tree – určený pro predikci - Klastrování – K-Mean Multiple streams – řeší problém počítaní jednoduchých funkcí, jako například počet různých elementů na sdruženém datovém toku

Další algoritmy Měření uspořádaní – využívá se pro správné vybrání třídicího algoritmu Testování vlastností – algoritmy, které jedním průchodem a za pomoci malého místa určí správnost streamovaných dat

Závěr Je téměř nemožné dostat přesnou odpověď na dotaz nad datovým tokem. Běží několik projektů, které řeší dotazy nad datovým tokem. Nejznámějším je asi Aurora Project http://www.cs.brown.edu/research/aurora/

Odkazy Babcock, Brian, S Babu, M Datar, R Motwani, J Widom “Models and Issues in Data Stream Systems.” In Proc. ACM SIGMOD/PODS 2002. June 3-5, 2002. Madison, Wisconsin. Minos Garofalakis “Sketching techniques for Massive Data Streams”