Proč živá vysílání v Orleans?

Pro vytváření systémů zpracování datových proudů již existuje celá řada technologií. Patří sem systémy pro trvale ukládat streamovaná data (například Event Hubs a Kafka) a systémy pro vyjádření výpočetních operací přes streamovaná data (například Azure Stream Analytics, Apache Storm a Apache Spark Streaming). Jedná se o skvělé systémy, které umožňují vytvářet efektivní kanály zpracování datových proudů.

Omezení stávajících systémů

Tyto systémy ale nejsou vhodné pro jemně definované výpočetní úkony nad datovými proudy. Výše uvedené výpočetní systémy streamování umožňují určit jednotný graf toku dat, který se používá stejným způsobem pro všechny položky datového proudu. Jedná se o výkonný model, pokud jsou data jednotná a chcete vyjádřit stejnou sadu transformací, filtrování nebo agregačních operací nad daty. Jiné případy použití ale vyžadují vyjádření zásadních různých operací s různými datovými položkami. V některých z těchto případů může být v rámci zpracování někdy potřeba provést externí volání, například vyvolání libovolného rozhraní REST API. Moduly pro zpracování datových proudů ve sjednocených systémech buď tyto scénáře nepodporují, podporují je omezeným způsobem, nebo jsou neefektivní v jejich podpoře. Je to proto, že jsou ze své podstaty optimalizované pro velký objem podobných položek a jsou obvykle omezené z hlediska výraznosti a zpracování. Orleans Streamy cílí na tyto další scénáře.

Motivace

Vše začalo s požadavky od Orleans uživatelů na podporu vrácení posloupnosti položek z volání metody grain. Jak si můžete představit, že to byl jen špička ledu; Potřebovali mnohem víc.

Typickým scénářem pro Orleans streamy je situace, kdy máte datové proudy pro jednotlivé uživatele a chcete pro každého uživatele provádět jiné zpracování v kontextu daného uživatele. Můžete mít miliony uživatelů, ale někteří mají zájem o počasí a přihlásit se k odběru upozornění na počasí pro určitou lokalitu, zatímco jiné se zajímají o sportovní akce; někdo jiný může sledovat stav konkrétního letu. Zpracování těchto událostí vyžaduje jinou logiku, ale nechcete spouštět dvě nezávislé instance zpracování datových proudů. Někteří uživatelé můžou mít zájem jenom o určitou skladovou kopii a pouze v případě, že se určitá externí podmínka použije – podmínka, která nemusí nutně být součástí dat datového proudu (a proto musí při zpracování dynamicky kontrolovat za běhu).

Uživatelé neustále mění své zájmy, takže jejich odběry konkrétních proudů událostí přicházejí a dynamicky odcházejí. Proto se topologie streamování dynamicky a rychle mění. Kromě toho se logika zpracování na uživatele vyvíjí a dynamicky se mění na základě stavu uživatele a externích událostí. Externí události můžou upravit logiku zpracování pro konkrétního uživatele. Například v systému detekce podvádění her při zjištění nové metody podvádění potřebuje logika zpracování aktualizovat pomocí nového pravidla, aby bylo zjištěno toto porušení. To je potřeba provést samozřejmě bez přerušení probíhajícího kanálu zpracování. Moduly pro zpracování datových proudů hromadného toku nebyly vytvořené tak, aby podporovaly takové scénáře.

Téměř bez nutnosti říct, že takový systém musí běžet na několika počítačích připojených k síti, nejen na jednom uzlu. Proto musí být logika zpracování distribuovaná škálovatelná a elastická napříč clusterem serverů.

Nové požadavky

Pro systém Zpracování datových proudů byly identifikovány čtyři základní požadavky, které cílí na výše uvedené scénáře:

1. Logika flexibilního zpracování datových proudů
2. Podpora vysoce dynamických topologií
3. Granularita jemného proudu
4. Distribuce

Logika flexibilního zpracování datových proudů

Systém by měl podporovat různé způsoby vyjádření logiky zpracování datových proudů. Existující systémy uvedené výše vyžadují, aby vývojáři napsali deklarativní výpočetní graf toku dat, který obvykle sleduje funkční programovací styl. To omezuje výraznost a flexibilitu logiky zpracování. Orleans datové proudy jsou lhostejné k tomu, jak je vyjádřena logika zpracování. Dá se vyjádřit jako tok dat (např. pomocí reaktivních rozšíření (Rx) v .NET), funkčního programu, deklarativního dotazu nebo obecné imperativní logiky. Logika může být stavová nebo bezstavová, může nebo nemusí mít vedlejší účinky a může aktivovat externí akce. Veškerá moc patří vývojáři.

Podpora dynamických topologií

Systém by měl umožňovat dynamicky se vyvíjející topologie. Existující systémy uvedené výše jsou obvykle omezené na statické topologie opravené v době nasazení, které se nemohou vyvíjet za běhu. V následujícím příkladu výrazu toku dat je všechno pěkné a jednoduché, dokud ho nebudete muset změnit:

Stream.GroupBy(x=> x.key).Extract(x=>x.field).Select(x=>x+2).AverageWindow(x, 5sec).Where(x=>x > 0.8) *

Změňte podmínku Where prahové hodnoty ve filtru, přidejte Select příkaz nebo přidejte do grafu toku dat jinou větev a vytvořte nový výstupní datový proud. V existujících systémech to není možné bez odstranění celé topologie a restartování toku dat úplně od začátku. Prakticky tyto systémy kontrolují stávající výpočty a můžou se restartovat z nejnovějšího kontrolního bodu. Přesto je takový restart rušivý a nákladný pro online službu, která vede k výsledkům v reálném čase. Takové restartování se stává obzvláště nepraktické při zpracování velkého počtu takových výrazů spuštěných s podobnými, ale různými parametry (podle uživatele, zařízení atd.), které se neustále mění.

Systém by měl umožnit vývoj grafu zpracování datových proudů za běhu přidáním nových propojení nebo uzlů do výpočetního grafu nebo změnou logiky zpracování v výpočetních uzlech.

Granularita jemného proudu

V existujících systémech je nejmenší jednotkou abstrakce obvykle celý tok (topologie). Mnoho cílových scénářů však vyžaduje, aby jednotlivé uzly nebo propojení v topologii byly samotnou logickou entitou. Tímto způsobem se může každá entita spravovat nezávisle. Například ve velké topologii datových proudů, která obsahuje více propojení, mohou mít různé odkazy různé charakteristiky a mohou být implementovány v různých fyzických přenosech. Některá spojení můžou procházet přes sokety TCP, zatímco jiná používají spolehlivé fronty. Různé odkazy můžou mít různé záruky doručení. Různé uzly můžou mít různé strategie vytváření kontrolních bodů a jejich logika zpracování se dá vyjádřit v různých modelech nebo dokonce v různých jazycích. Tato flexibilita obvykle není v existujících systémech možná.

Jednotka abstrakce a argument flexibility je podobná porovnání SoA (Service Oriented Architectures) vs. Actors. Systémy actor umožňují větší flexibilitu, protože každý aktér je v podstatě nezávisle spravovaná "drobná služba". Systém datových proudů by měl podobně umožňovat takovou jemně odstupňovanou kontrolu.

Distribuce

A samozřejmě, systém by měl mít všechny vlastnosti "dobrý distribuovaný systém". To zahrnuje:

1. Škálovatelnost: Podporuje velký počet datových proudů a výpočetních prvků.
2. Elasticita: Umožňuje přidávat nebo odebírat prostředky, aby se zvětšily nebo zmenšily na základě zatížení.
3. Spolehlivost: Odolnost proti chybám.
4. Efektivita: Efektivně používá podkladové prostředky.
5. Rychlost odezvy: Umožňuje scénáře téměř v reálném čase.

To byly požadavky na vytváření Orleans streamování.

Vysvětlení: Orleans V současné době nepodporuje přímo zápis deklarativních výrazů toku dat, jako je v příkladu výše. Aktuální Orleans rozhraní API pro streamování jsou stavební bloky nízké úrovně, jak je popsáno v Orleans rozhraních API pro streamování.

Viz také

Orleans Programovací rozhraní API pro toky