Dotazovanie nad data streams. Juraj Hámorník, Jan Pešek

Transkript

1 Dotazovanie nad data streams Juraj Hámorník, Jan Pešek

2 Data stream - Monitor siete kde každý sieťový prvok posiela štatistiku - Dopravná situácia...

3 Data stream model - všetky alebo niektoré dáta niesú uložené a prístupné cez random access z disku alebo pamäti - data prichádzajú v podobe 1 alebo viacerých data streamov.

4 Data stream model -rozdiel medzi data stream modelom a stored relation modelom: Data elementy prichádzajú online Systém nemá kontrolu nad poradím príchodu dát Data stream možu mať neobmedzenú velkosť Data element môže byť po spracovaní: zahodený alebo archivovaný, tažko ho spracovať znovu.

5 Data stream model -Spracovávanie nevyžaduje výskyt nejakých dát v uložených v tradyčnom DS -Data stream dotazy môžu joinovať ako aj medzi data stream tak aj medzi uloženými dátami. - Ďalej budeme uvažovať, že uložené dáta budú statické

6 Data stream model

7 Data stream dotazy -podobné ako dotazovanie nad tradičnými databázami Sú tu ale 2 rozdiely medzi : jednorázové dotazy / nepretržité dotazy vopred definované dotazy / ad hoc dotazy

8 Data stream jednorázové dotazy -jednorázové dotazy sú trieda dotazov, ktoré zahŕňajú tradičné DBMS dotazy - vyhodnocujú sa raz za čas nad snapshotom dát, odpoveď je vrátená uživatelovi

9 Data stream nepretržité dotazy -odpoveď nad nepretržitými dotazmi ( continuos queries ) je tvoréná v priebehu času. -vždy odráža prúdiaci data stream -výsledok môže byť uložený, alebo môže taktiež produkovať data stream

10 Data stream preddefinované dotazy -preddefinované dotazy sú poskytované data stream managment systmémom -sú dostupné aj pred príchodom akýchkoľvek dát -sú to spravidla nepretržité dotazy - napr(ibm) : Process details Process specification Process statistics Resource definition specification Resource specification

11 Data stream Ad hoc queries -spúštajú sa až keď data stream započne -môžu byť rovnako jednorázové dotazy ako nepretržité dotazy - znepríjemnujú prácu data stream managment systému -niesú známe predom pre optimalizáciu -výsledok dotazu môže vyžadovať dáta, ktoré už prišli neskôr a už sú zmazané

12 Data stream : príklady použitia Traderbot - webový finančný vyhladávací engine ( :( ) ipolicynetwork firewall support a detekcie nad multi gigabitovimy sietami ( :( )

13 Data stream príklady použitia - network traffic systém veľkej siete - velký počet datastreamov ( packet trace, výkon siete ) - typicky sa používa systém na to navrhnutý, ktorý spúšta jednoduché dotazy alebo sa dotazujú offline logy

14 Data stream príklady použitia - sieť zákazníka ( C ) customer ----> isp - backbone ( B ) isp < > isp src: Ip adresa odosielatela dest: Ip adresa príjmatela id: uniq paketu len : dlžka paketu time: kedy bola nahraná hlavička

15 Data stream príklady použitia - výpočet zaťaženia na linke B priemerne cez jednu minútu. Q: SELECT notifyoperator(sum(len)) FROM GROUP BY getminute(time) HAVING sum(len) cez trigery by to šlo.. ale neefektívne

16 Data stream príklady použitia - izoluje tok na backbone a zistí trafik každého prúdu ( sekvencia dát od rovnakych send -rcv ) Q: 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

17 Data stream príklady použitia -Q2 : obtiažne použit klasické techniki pre prítomnosť GROUP BY a ORDER BY - nastalo by blokovanie pri exekučnom pláne

18 Data stream príklady použitia Ad hoc nepretržité Q3: (SELECT count (*) FROM C, B WHERE C.src = B.src and C.dest = B.dest and C.id = B.id) (SELECT count (*) FROM ) - join medzi streamamy B a C - výsledok je počet spoločných paketov - problemý z nekonečným priestorom ( meobmedzeny delay medzi paketmi ) -riešenie udrziavať konečnú pamäť spojenia streamov - spájať dvojice len v určitom časovom okne

19 Data stream príklady použitia nepretržité - monitorovanie párov ( odosielatel - prijemca ) v top 5% backbone traffic. Q: 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 ORDER BY traffic (SELECT count(*) FROM Load AS L2 WHERE L2.traffic < L1.traffic) >! count(*) FROM Load)

20 Dotazy nad Data streams - dotazy nad data stremom so sebou nesú špecifické problemy Požiadavok na neobmedzenú pamäť Približná odpoveď dotazu Pohiblivé okno dát Dávkové spracovanie Samplovanie Synopses

21 - pre možnú neobmedzenosť data stremu aj priestor na vyhodnotenie dotazu môže neobmedzený - algoritmy na operácie v externej pamäti niesú veľmi dobré na nepretržité dotazy a sú príliš pomalé na real-time respons aplikácie - dotazuje sa nad velkými objemami dát ktoré prichádzajú často aj keď staré ešte spracúvame - latencia algoritmov (aj hw) musí byť nízka Data stream neobmedzená pamäť

22 Data stream neobmedzená pamäť - in memory computing - možnosť rozlišovať dotazy ktoré môžme ohraničit pamäťov a dotazov ktoré musíme approximať ( ak nie je dovolený prístup na disk) - pokus odhadnuť dopredu na základe dotazu jeho požiadavky => neúspešne - otvorený výskumný problém :)

23 Dotazy: približné odpovede - bez neobmedzenej pamäti nemôžme poskytnúť niekedy presné odpovede - je možné výsledok odhadnúť s vysokou presnosťou - zaoberajú sa ňou techniky sketches, random sampling, histograms, wavelet - napr : na histograme založená technika na korelaciu agregovanych dotazov nad data stream

24 Dotazy : Sliding Windows - nedotazovať sa nad celou históriou data streamu - dotazovať sa len nad nedávnou históriou - jednoduché a prirodzené riešenie ktoré sa dá chápať - deterministické - zdôraznuje nedávne dáta, ktoré sú pre real aplikácie najpodstatnejšie - niekedy zastúpi celý dotaz namiesto len

25 Dotazy : Sliding Windows - problémy s označovaním timestamps nad data streamom - rozšíriť SQL alebo relačnú algerbu na sliding window - impelentácia a optimalizácia dotazu je neprebádaná oblasť - nepreskúmané algoritmi, kde sa ani sliding window nevojde do pamäte

26 Dotazy : Sliding Windows - temporárne databázy je primárne na plnú históriu / data stream system je primárne na nové dáta za behu - sekvenčné databázy sa snažia produkovať stream acces ( jeden scan je dostatočný na zistenie plnánu a zdrojov ) tento model predpokladá kontrolou nad poradím dát ( nemožno garantovať v data streame)

27 Batch Sampling Synopses - nespracúvať každú časť dát ale vybrať si - predpokladajme že odpoveďou na dotaz je dátová štruktúra ktorú môžme spravovať postupne - update ( tuple ) - computeanswer() - obe sú relatívne rýchle voči príchodu dát - príde prvok, updatneme štruktúru, vypočítame nový výsledok

28 Batch Processing - update je rýchly / computeanswer je pomalý - prirodzene je spracúvať výsledok v dávkach - namiesto online výsledku spracujeme výsledok periodicky raz za čas - odpoveď je približná nie pre výsledok, ale že nemusí byť presná v aktuálny čas - dobrá metóda na data bursty - algoritmy ktoré nezvládajú peaky môžu bufferovať a počítať v pomalých periódach

29 Sampling - update pomalý / computeanswer rýchli - nemôžme spracovávať všetky dáta = niečo musíme preskočiť - výsledok je vyhodnotený len nad samplom dát - máme približný výsledok, ale občas môžeme stanoviť hranice chyby pri samplovaní - naneštastie pre dotazy s joinom nám sampling nedáva uspokojivé výsledky

30 Synopsis Data Structures - update je rýchli / computeanswer je rýchli - môžme použiť štruktúru ktorá si zachováva synpsis alebo skicu dát namiesto presnej reprezentácie dát - schopnosť uchovať čo najmenší objem dát potrebných na výpočet

31 Blocking Operators - blokovací operátor dotazu - znemožní vyhodnocovanie až kým nedorazia posledné dáta - agregačné operátory ( SUM, COUNT MAX..) - pri nekonečných data streamoch sa nedočkáme výsledku - problémy pri zaradení takýchto operátorov do tradičných stromov dotazu

32 Blocking Operators - keď je bloking operátor v koreni a produkuje malú doménu hodnôt - môže odpovedat v podobe streamu - v prípade usporiadania je výhodné mať výsledok v podobe "aktuálnej čiastočnej" odpovede - v prípade hlbšieho umiestnenia v strome dotazu môžu na ňom závislé dotazy vracat neuspokojivé odpovede v čase kým niesu dostupné všetky dáta

33 Blocking Operators - nahradit bloking operátor nie bloking operátorom, ktorý aproximuje výsledok - sort === juggle operator, lokálne preusporiada dáta - iný prístup je rozlišovať je anotovať data streamy "punctuations" - napr "daynumber >= 10" => do výsledku môžu íst už všetky menšie daynumber

34 Queries Referencing Past Data - v data stream modely :čo bolo streamované, nemôže byť znovu použité - niektoré ad hoc dotazy závislé na dátach, ktoré sme už zahodili nedosiahnu presný výsledok - ad hoc dotazy budú môcť sa dotazovať len na budúce dáta - veľmi omedzujúce pravidlo, ale funguje

35 Queries Referencing Past Data - výhoda pri dlho bežiacich dotazoch je možnosť online optimalizovať plán dotazu - problém meniaceho sa toku dát - spravovať sumárne minulé dáta ( kompromisi pri zdrojoch )

36 Stream: Implementace DSMS - Stanford University: Stream Stanford Stream Data Manager - kód dostupný pod BSD licencí - server pouze pro Linux, klient v Javě - vývoj ukončen - primárně zpracovává online dotazy, ale podporuje i offline (Archive) - HTTP interface, podporuje SOAP

37 Stream: Dotazovací jazyk - modifikované SQL - klauzule FROM se může kromě relací vztahovat také na streamy - možnost definovat sliding window - SQL99 obsahuje analytické funkce, jež umožňují provádět agregační operace nad sliding window, nicméně toto nestačí pro data stream, jelikož se nedá uplatnit na neagregační operace jako JOIN (viz. SELECT... OVER)

38 Stream: Dotazovací jazyk - sliding windows - vyžadují možnost řazení datových prvků - pomocí timestampů: buď implicitních (čas), nebo explicitních (integer,...) - formálně: S = {(s 1, i 1 ),..., (s i, i i )}, kde S je data stream, s i n-tice (data) a i i timestamp - specifikace SQL je rozšířena o možnost specifikace okna - za specifikací streamu v klauzuli FROM, uzavřeno do hranatých závorek

39 Stream: Dotazovací jazyk - sliding windows - Příklad: SELECT AVG(S.minutes) FROM Calls S [PARTITION BY S.customer_id ROWS 10 PRECEDING WHERE S.type = 'Long Distance'] - specifikace okna se skládá z: - volitelné klauzule PARTITION, která dělí data do skupin, a udržuje okna zvlášť pro každou skupinu

40 Stream: Dotazovací jazyk - sliding windows - velikost okna (specifikovaná buď ve "fyzických" jednotkách - počtu prvků v okně, nebo v "logických" jednotkách, např. časový rozsah 30 dnů) - volitelný filtrovací predikát (klauzule WHERE) - velikost okna je specfikována pomocí klíčového slova ROWS (např. ROWS 50 PRECEDING)

41 Stream: Dotazovací jazyk - sliding windows - alternativně je možno udat velikost okna pomocí klíčového slova RANGE (např. RANGE 15 MINUTES PRECEDING) - filtrovací predikát je přidán kvůli efektivitě, viz. následující příklad: - SELECT AVG(S.minutes) FROM Calls S [PARTITION BY S.customer_id ROWS 10 PRECEDING] WHERE S.type = 'Long Distance'

42 Stream: Dotazovací jazyk - sliding windows - SELECT AVG(V.minutes) FROM (SELECT S.minutes FROM calls S, Customers T WHERE S.customer_id = T.customer_id AND T.membership = 'Gold') V [ROWS 1000 PRECEDING]

43 Stream: Dotazovací jazyk - timestamps - implicitní timestampy (tedy takové, jež systém přidává automaticky) se použijí, pokud data nenesou žádnou informaci o jejich pořadí, nebo pokud na přesném čase (pořadí) v souvislosti s daty nezáleží, ale je třeba "porovnávat starší" - explicitní timestampy představují informaci relevantní k zbytku datům v n-tici (např. se vztahují k nějaké vnější události)

44 Stream: Dotazovací jazyk - timestamps - explicitní timestampy mají problém v tom, že n-tice ve streamu nemusí přijít ve stejném pořadí jim odpovídajícím (např. vlivem sítě) - toto prakticky znemožňuje vyvářet sliding windows definovaná vůči explicitním timestampům - nicméně pokud je vstupní stream "prakticky" setříděný, malé odchylky je možné snadno opravit pomocí bufferování

45 Stream: Dotazovací jazyk - timestamps - standartně předpokládáme, že timestamp jednoznačně určuje pořadí prvku ve streamu (ať už se jedná o časový údaj, nebo např. celočíselné číslování) - co když však budou data na výstupu odvozena z více streamů? (např. pokud máme okno nad výstupem dotazu, jež provádí operaci JOIN nad dvojicí streamů) - co přesně pak představuje daný timestamp?

46 Stream: Dotazovací jazyk - timestamps - buď přidělovat n-ticím produkovaným JOINem nové timestampy - předpoklad, že n-tice, které přišli dříve, mají také větší pravděpodobnost skrz tento JOIN projít dříve - tento přístup lépe vyhovuje implicitním timestampům + jednoduchost implementace - nemožnost deterministicky definovat slidingwindow na poddotazech

47 Stream: Dotazovací jazyk - timestamps - druhá možnost: uživatel v dotaze určí, který timestamp se má použít jako výsledný (pro výstupní n-tici) - lze použít pro implicitní i explicitní timestampy - např. jednoduše pomocí pořadí, v jakém jsou streamy v dotazu napsané (v každém JOINu se použijí timestampy prvního napsaného streamu) - problém: více n-tic může mít stejný timestamp

48 Stream: Dotazovací jazyk - timestamps - řešení: v případě, že by se měl přidělit duplicitní timestamp, použije se timestamp n- tice z druhého streamu - přesněji: nejprve se řadí, "stejné" timestampy jsou nahrazeny a dotříděny - např.: SELECT * FROM S1 [ROWS 1000 PRECEDING], S2 [ROWS 1000 PRECEDING] WHERE S1.A = S2.B

49 Stream: Dotazovací jazyk - timestamps - druhý přístup - implementační problém - pokud chceme výstupní data z JOINu setříděné dle timestampu, musíme bufferovat dokud nemáme jistotu, že budoucí vstup nenaruší pořadí odesílaných dat - př.: spojí-li se n-tice z S1 a S2, je stále možné, že budoucí n-tice z S2 se spojí se starší n-ticí z S1, která stále spadá do současného okna

50 Stream: Dotazovací jazyk - timestamps - ve složitějších dotazech se tato chyba může propagovat a zhoršovat - který způsob tedy použít? - záleží na konkrétním dotaze - pokud sliding-window slouží jako prostředek pro zlepšení výkonu, zpravidla stačí použít první "best-effort" způsob -pokud však pořadí n-tic hraje roli ve významu dotazu, je třeba použít druhý způsob

51 Stream: Dotazovací jazyk - timestamps - ve STREAMu jsou k dispozici oba způsoby, pro první ("best-effort") způsob se v definici okna nahradí klíčové slovo PRECEDING slovem RECENT - např. "ROWS 10 PRECEDING" určuje okno předchozích 10 n-tic seřazených striktně podle timestampu, "ROWS 10 RECENT" pak umožňuje v případě potřeby DSMS použít vlastní systém řazení

52 Stream: Dotazovací jazyk - timestamps - klíčové slovo RECENT je možné použít pouze s "fyzickými" velikostmi, není tedy možné specifikovat např. "RANGE 3 DAYS RECENT"

53 Stream: Dotazovací jazyk - provádění dotazu

54 Stream: Dotazovací jazyk - provádění dotazu - operátory - fronty (spojují operátory) - synopse (datové struktury) - paměť je přidělována dynamicky mezi synopse a fronty - narozdíl od jiných systémů (Aurora, Eddies) jsou jednotlivé fronty oddělené - operátor čte ze vstupu, upravuje jemu náležící synopse, a zapisuje výstup

55 Stream: Dotazovací jazyk - provádění dotazu - čas na provádění dostávají operátory od centrálního "plánovače" (scheduler) - doba, kdy může operátor zpracovávat data může být různá - může se jednat o časový úsek, metrikou může být i určitý počet n-tic (na vstupu či na výstupu) - Aurora, Eddies: plánovač vezme n-tici z globální fronty a přidělí čas "jejímu" operátoru - umí i STREAM

56 Stream: Dotazovací jazyk - provádění dotazu - dlouho běžící dotazy => za běhu se měnící parametry streamu => operátory musí být adaptabilní - optimalizace především na dostupnou paměť - run-time paměť může být operátoru kdykoli odebrána a předána jinému - přesnost vs. paměť

57 Stream: Overview - využívá deklarativní jazyk pro dotazy (vycházející z SQL), narozdíl od jiných DSMS (Aurora, Hancock,...) => vyžaduje komplexní plánovač dotazů - rovněž poskytuje možnost přímého zadávání již naplánovaných dotazů (relační algebra) - monitoring běžících dotazů - změny nastavení za jejich běhu (alokace paměti, nastavení scheduleru)

58 Aurora: boxes and arrows

59 Algoritmické problémy Algoritmus datových toků (data streams) příjímá jako vstup sekvenci prvků x 1,... x n,... zvaných data stream, přičemž tato sekvence je vždy čtena pouze jednou ve směru vzrůstajících indexů. Algoritmus musí udržovat hodnotu funkce f na základě přečtených prvků této sekvence.

60 Algoritmické problémy - metriky pro porovnávání algoritmů: - spotřebovaná paměť - čas potřebný na zpracování prvku - čas potřebný na vyhodnocení funkce f z uchovávané datové struktury, pokud algoritmus nějakou má - dle alternativní definice, kde je možné číst stream opakovaně je metrikou rovněž počet průchodů

61 Algoritmické problémy - měřit je možné vzhledem k N, kde N značí počet dosud přečtených prvků - N je neomezené - ideální algoritmus by byl na N nezávislý - problém je považovaný za "efektivně řešitelný", pokud je řešitelný na místě O(poly(log N)) a v čase O(poly(log N)) na prvek - poly značí polynomiální funkci

62 Algoritmické problémy: Random Samples - základní metoda pro tvorbu synopsí - ze streamu bere náhodný vzorek - uniform sample vs. stratified sample - reservoir sampling (nejdříve naplnit pole, následně se snižující se pravděpodobností měním náhodný prvek tohoto pole za nově příchozí)

63 Algoritmické problémy: Sketching Techniques - způsob, jak vytvořit "přehled" o streamu s využitím malého množství paměti - pomocí tohto přehledu je možné poměrně přesně odhadovat některé dotazy

64 Algoritmické problémy: Sketching Techniques - jak to funguje: S=(x 1,..., x n ) x i náleží jedné z domén D={1,..., d} m i = {j x j = i} určuje počet výskytů i v S pro nezáporné k je pak k-tý moment četnosti (kth frequency moment) určen jako

65 Algoritmické problémy: Sketching Techniques - momenty četnosti zachycují rozdělení hodnot v S - např. F 0 je množství odlišných hodnot v sekvenci, F 1 je délka sekvence, F oo je četnost nejčetnější hodnoty - pro výpočet těchto hodnot existuje mnoho různých algoritmů různých výsledků (např. Alon, Matias, Szegedy - F 0 v O(log d), F 2 v O(log d + log N))

66 Algoritmické problémy: Histogramy - histogram = struktura pro sumarizaci dat - zachycuje rozdělení hodnot v množině dat - používají se např. k odhadu velikosti dotazu, aproximaci odpovědi dotazu či k data miningu - existuje několik vhodných typů histogramů

67 Algoritmické problémy: Histogramy V-optimal histogram - aproximuje rozdělení množiny v 1,..., v n pomocí "skokové" konstantní funkce v(i), minimalizuje druhou mocninu odchylky - histogram užívá metodu "věder" (buckets) - rozděluje data do určitých částí - idea: každý čtený prvek je "aktualizací" vektoru délky N, který se snažíme aproximovat histogramem o B "vědrech"

68 Algoritmické problémy: Histogramy V-optimal histogram - na setříděném streamu: místo i čas O(B 2 log N) - na nesetříděném: místo i čas ohraničeno poly(b, log N, 1/e), kde e je připouštěná relativní odchylka

69 Algoritmické problémy: Histogramy Equi-width histogram - počítá kvantily - hodnoty, které děli stream na zhruba stejně velké části - Greenwald, Khanna: O(1/e * log N), garantuje přesnost en

70 Algoritmické problémy: Histogramy End-biased histograms - Iceberg queries - často využívané dotazy jsou na jednoduché agregace určitého atributu v určitém rozsahu (např. počet záznamů) = tzv. Iceberg queries - Manku a Motwani: pro určitý atribut se udržuje množství odlišných hodnot spolu s jejich četností, při přidání nového prvku se zkoumá zda již existuje, prvky s nízkou čeností se mažou

71 Algoritmické problémy: Histogramy End-biased histograms - Iceberg queries - algortmus tedy udržuje přehled o prvcích, jejichž četnost je vysoká(přesněji vyšší než 1/e) - navíc garantuje, že četnost těchto prvků,ač ve skutečnosti menší, než udržovaná hodnota, není menší o více než en - vyžaduje O(1/e log (en)) místa

72 Algoritmické problémy: Wavelets - technika, jak poskytovat přehled o datech - koeficienty jsou projekce daného streamu na ortogonální množinu vektorů - z dané "vlnky" lze celkem přesně rekonstruovat původní množinu (stream)

73 Algoritmické problémy: Wavelets - efektivní např. pro odhady pro výsledky selectu či vícerozměrné agregace - na setříděném streamu lze použít upravený hladový algoritmus s paměťovou náročností O(B + log N) - implementace zůstává otevřeným problémem

74 Algoritmické problémy: Sliding windows - zabraňují "zastaralým" datům ovlivňovat statistiky, slouží jako aproximační nástroj - problém: jak efektivně udržovat statistiky nad určeným oknem - jak nejlépe "implementovat" předcházející algoritmy - Datar a spol.: implementace sketches s místem O(1/e log N), kde e je přesnost, N velikost okna

75 Algoritmické problémy - dále např. data mining - udržování rozhodovacích stromů nad streamem (Domingos: O(N e ) místa a O(poly(log N)) času na prvek) - multiple streams - práce se sjednocením streamů (Gibbons, Tirthapura: lze využít sketching) - zkoumání seřazenosti - užitečné např. pro volbu třídícího algoritmu

76 Algoritmické problémy: zkoumání seřazenosti - odhad počtu inverzí v permutaci - Ajtai a spol.: O(log N log (log N)) místa, O(log N) času na prvek

77 Závěr: zpět na začátek "Meta-otázky" položené Babcockem a spol.: - lze pro efektivní zpracování "on-line" streamů dat udělat lepší systém, než klasické DBMS s jejich triggery, dočasnými strukturami,...? - je potřeba navrhovat další obecné modely, algoritmy a systému pro data streamy? - existuje/í "killer app/s" pro systémy zpracování data streamů?

78 Závěr: budoucnost DSMS - pokud na předcházející otázky odpovíme kladně, je třeba vyřešit několik otázek, především: - distributivita (přesměrovávat vysoce vytížené streamy na centrální bod ke zpracování je neefektivní) - interface DSMS (modifikované SQL vs. jiný přístup) - timestamping

79 Závěr: budoucnost DSMS - efektivnost vyhodnocování dotazů, konstrukce synopsí, správa zdrojů, aproximování zpracování dotazů,... - definování extenze relačních operátorů - "stream algebra"?

80 Závěr: zdroje Babcock, Babu, Datar, Motwani, Widom: Models and Issues in Data Stream Systems Maskei, Madden a spol.: Borealis Distributed Stream Processing Engine Arasu, Babcock, Babu, Datar, Ito, Nishizawa, Rosenstein, Widom: STREAM: The Stanford Stream Data Manager