Proč streamy v Orleans?
Existuje již celá řada technologií, které umožňují vytvářet systémy zpracování datových proudů. Mezi tyto systémy patří trvale ukládat streamovaná data (např . Event Hubs a Kafka) a systémy pro vyjádření výpočetních operací přes streamovaná data (např. Azure Stream Analytics, Apache Storm a Streamování Apache Sparku). 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 však nejsou vhodné pro jemně odstupňované bezplatné výpočty nad daty datových proudů. Výše uvedené výpočetní systémy streamování umožňují určit jednotný graf toku dat operací, které se použijí 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. Existují ale i jiné případy použití, kdy potřebujete vyjádřit zásadní různé operace s různými datovými položkami. A v některých z nich v rámci tohoto zpracování někdy potřebujete provést externí volání, například vyvolat některé libovolné rozhraní REST API. Sjednocené moduly pro zpracování datových proudů nepodporují tyto scénáře, podporují je omezeným a omezeným způsobem nebo jsou neefektivní při jejich podpoře. Je to proto, že jsou ze své podstaty optimalizované pro velký objem podobných položek a obvykle jsou omezené z hlediska výraznosti a zpracování. OrleansToky cílit 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 agregace. Jak si můžete představit, to byl jen špička ledu. Potřebovali mnohem víc.
Typickým scénářem pro Orleans Toky 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 jednotlivého uživatele. Možná máme miliony uživatelů, ale některé z nich mají zájem o počasí a mohou se přihlásit k odběru upozornění na počasí pro určitou lokalitu, zatímco někteří mají zájem o sportovní akce; někdo jiný sleduje 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é mají zájem pouze o určitou akci a pouze v případě, že se použije určitá externí podmínka, podmínka, která nemusí nutně být součástí dat datového proudu (a proto je potřeba je při zpracování dynamicky kontrolovat za běhu).
Uživatelé neustále mění zájmy, a proto se jejich odběry mění na konkrétní proudy událostí a dynamicky se mění, takže se streamovaná topologie dynamicky a rychle mění. Kromě toho se logika zpracování na uživatele dynamicky vyvíjí a mění také na základě stavu uživatele a externích událostí. Externí události mohou upravit logiku zpracování pro konkrétního uživatele. Například v systému zjišťování podvádění her, když je zjištěn nový způsob podvádění, musí být logika zpracování aktualizována novým pravidlem, aby bylo možné zjistit toto nové 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 dat nebyly vytvořené tak, aby podporovaly takové scénáře.
Téměř bez toho, aby se říkalo, že takový systém musí běžet na několika počítačích připojených k síti, ne na jednom uzlu. Proto musí být logika zpracování distribuována škálovatelným a elastickým způsobem napříč clusterem serverů.
Nové požadavky
Identifikovali jsme 4 základní požadavky pro náš systém zpracování datových proudů, které umožní cílit na výše uvedené scénáře.
- Logika flexibilního zpracování datových proudů
- Podpora vysoce dynamických topologií
- Členitost jemně odstupňovaného proudu
- Distribuce
Logika flexibilního zpracování datových proudů
Chceme, aby systém podporoval různé způsoby vyjádření logiky zpracování datových proudů. Existující systémy, které jsme zmínili výše, vyžadují, aby vývojář napsal deklarativní výpočetní graf toku dat, obvykle podle funkčního programovacího stylu. To omezuje výraznost a flexibilitu logiky zpracování. Orleans datové proudy jsou pro způsob vyjádření logiky zpracování nezáměrné. Dá se vyjádřit jako tok dat (například pomocí reaktivních rozšíření (Rx) v .NET), jako funkční program, jako deklarativní dotaz nebo obecně imperativní logika. Logika může být stavová nebo bezstavová, může nebo nemusí mít vedlejší účinky a může aktivovat externí akce. Veškerá síla jde vývojáři.
Podpora dynamických topologií
Chceme, aby systém umožňoval dynamicky se vyvíjející topologie. Existující systémy, které jsme zmínili výše, jsou obvykle omezené pouze na statické topologie, které jsou pevné v době nasazení a nemohou se 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 od začátku. Prakticky tyto systémy zkontrolují stávající výpočty a budou se moci 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é, když mluvíme o velkém počtu takových výrazů, které se spouštějí s podobnými, ale odlišnými parametry (podle uživatele, zařízení atd.) a které se neustále mění.
Chceme, aby systém umožnil 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.
Členitost jemně odstupňovaného proudu
V existujících systémech je nejmenší jednotkou abstrakce obvykle celý tok (topologie). Řada našich cílových scénářů ale vyžaduje, aby jednotlivé uzly nebo propojení v topologii byly samy o sobě logickou entitou. Tímto způsobem může být každá entita potenciálně spravovaná nezávisle. Například v topologii velkých datových proudů, která obsahuje více propojení, mohou mít různé odkazy různé charakteristiky a lze je implementovat v různých fyzických přenosech. Některé odkazy můžou přecházet přes sokety TCP, zatímco jiné přes 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". Podobně chceme, aby systém datových proudů umožnil takovou jemně odstupňovanou kontrolu.
Distribuce
A samozřejmě, náš systém by měl mít všechny vlastnosti "dobrý distribuovaný systém". To zahrnuje:
- Škálovatelnost – podporuje velký počet datových proudů a výpočetních prvků.
- Elasticita – umožňuje přidávat nebo odebírat prostředky, které se zvětšují nebo zmenšují na základě zatížení.
- Spolehlivost – odolnost proti chybám
- Efektivita – efektivní využití základních prostředků
- Rychlost odezvy – povolte scénáře téměř v reálném čase.
To byly požadavky, které jsme měli na paměti pro 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 více stavebních bloků nízké úrovně, jak je popsáno zde. Poskytnutí deklarativních výrazů toku dat je naším budoucím cílem.
