Dlaczego w systemie Orleans są strumienie?

Istnieje już wiele technologii do tworzenia systemów przetwarzania strumieniowego. Obejmują one systemy umożliwiające trwałe przechowywanie danych strumienia (na przykład usługi Event Hubs i Kafka) oraz systemy do wyrażania operacji obliczeniowych za pośrednictwem danych strumienia (na przykład azure Stream Analytics, Apache Storm i Apache Spark Streaming). Są to doskonałe systemy, które umożliwiają tworzenie wydajnych potoków przetwarzania strumienia danych.

Ograniczenia istniejących systemów

Jednak te systemy nie są odpowiednie do szczegółowego i swobodnego przetwarzania danych strumieniowych. Systemy obliczeniowe przesyłania strumieniowego wymienione powyżej umożliwiają określenie ujednoliconego grafu przepływu danych operacji stosowanych w taki sam sposób, jak we wszystkich elementach strumienia. Jest to zaawansowany model, gdy dane są jednolite i chcesz wyrazić ten sam zestaw operacji przekształcania, filtrowania lub agregacji na tych danych. Jednak inne przypadki użycia wymagają wyrażenia zasadniczo różnych operacji na różnych elementach danych. W niektórych z tych przypadków w ramach przetwarzania może być czasami konieczne wykonanie wywołania zewnętrznego, takiego jak wywołanie dowolnego interfejsu API REST. Ujednolicone aparaty przetwarzania strumienia danych nie obsługują tych scenariuszy, obsługują je w ograniczony i utrudniony sposób lub są nieefektywne w ich obsłudze. Jest to spowodowane tym, że są one z natury zoptymalizowane pod kątem dużej ilości podobnych elementów i są zwykle ograniczone pod względem ekspresywności i przetwarzania. Orleans Strumienie są skierowane na te inne scenariusze.

Motywacja

Wszystko zaczęło się od próśb użytkowników Orleans dotyczących wsparcia zwracania sekwencji elementów z wywołania metody ziarna. Jak można sobie wyobrazić, to tylko wierzchołek góry lodowej; potrzebowali o wiele więcej.

Typowy scenariusz dla Orleans usługi Streams polega na tym, że masz strumienie dla poszczególnych użytkowników i chcesz wykonywać różne operacje przetwarzania dla każdego użytkownika w kontekście tego pojedynczego użytkownika. Być może masz miliony użytkowników, ale niektóre są zainteresowane pogodą i subskrybować alerty pogodowe dla określonej lokalizacji, podczas gdy inne są zainteresowane wydarzeniami sportowymi; ktoś inny może śledzić stan określonego lotu. Przetwarzanie tych zdarzeń wymaga innej logiki, ale nie chcesz uruchamiać dwóch niezależnych wystąpień przetwarzania strumienia. Niektórzy użytkownicy mogą być zainteresowani tylko określonymi akcjami i tylko wtedy, gdy ma zastosowanie określony warunek zewnętrzny — warunek, który nie musi być częścią danych strumienia (i w związku z tym wymaga dynamicznego sprawdzania w czasie wykonywania w ramach przetwarzania).

Użytkownicy zmieniają swoje zainteresowania przez cały czas, więc ich subskrypcje na określone strumienie zdarzeń zmieniają się dynamicznie. W związku z tym topologia przesyłania strumieniowego zmienia się dynamicznie i szybko. Ponadto logika przetwarzania na użytkownika ewoluuje i zmienia się dynamicznie na podstawie stanu użytkownika i zdarzeń zewnętrznych. Zdarzenia zewnętrzne mogą modyfikować logikę przetwarzania dla określonego użytkownika. Na przykład w systemie wykrywania oszustw w grze po odnalezieniu nowej metody oszukiwania logika przetwarzania wymaga aktualizacji przy użyciu nowej reguły w celu wykrycia tego naruszenia. Należy to zrobić, oczywiście, bez zakłócania bieżącego procesu przetwarzania. Aparaty przetwarzania strumieniowego przepływu danych zbiorczych nie zostały opracowane w celu obsługi takich scenariuszy.

Niemal nie mówi się, że taki system musi działać na kilku maszynach połączonych z siecią, a nie tylko na jednym węźle. W związku z tym logika przetwarzania musi być skalowalna i elastyczna w klastrze serwerów.

Nowe wymagania

Zidentyfikowano cztery podstawowe wymagania dotyczące systemu przetwarzania strumieniowego do realizacji wymienionych powyżej scenariuszy.

1. Elastyczna logika przetwarzania strumieniowego
2. Obsługa topologii wysoce dynamicznych
3. Szczegółowa granularność strumienia
4. Dystrybucja

Elastyczna logika przetwarzania strumieniowego

System powinien obsługiwać różne sposoby wyrażania logiki przetwarzania strumieniowego. Istniejące systemy wymienione powyżej wymagają od deweloperów napisania deklaratywnego grafu obliczeniowego przepływu danych, zwykle zgodnie z funkcjonalnym stylem programowania. Ogranicza to ekspresywność i elastyczność logiki przetwarzania. Orleans strumienie są obojętne na sposób wyrażenia logiki przetwarzania. Można je wyrazić jako przepływ danych (np. przy użyciu reaktywnych rozszerzeń (Rx) na platformie .NET), programu funkcjonalnego, zapytania deklaratywnego lub ogólnej logiki imperatywnej. Logika może być stanowa lub bezstanowa, może lub nie ma skutków ubocznych i może wyzwalać akcje zewnętrzne. Cała moc trafia do dewelopera.

Obsługa topologii dynamicznych

System powinien umożliwiać dynamiczne rozwijanie topologii. Istniejące systemy wymienione powyżej są zwykle ograniczone do statycznych topologii stałych w czasie wdrażania, które nie mogą ewoluować w czasie wykonywania. W poniższym przykładzie wyrażenia przepływu danych wszystko jest miłe i proste, dopóki nie trzeba go zmieniać:

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

Zmień warunek progu w filtrze Where , dodaj instrukcję Select lub dodaj inną gałąź na grafie przepływu danych i utwórz nowy strumień wyjściowy. W istniejących systemach nie jest to możliwe bez usuwania całej topologii i ponownego uruchamiania przepływu danych od podstaw. Praktycznie te systemy sprawdzają istniejące obliczenia i mogą być uruchamiane ponownie z najnowszego punktu kontrolnego. Mimo to takie ponowne uruchomienie jest destrukcyjne i kosztowne dla usługi online, co daje wyniki w czasie rzeczywistym. Takie ponowne uruchomienie staje się szczególnie niepraktyczne w przypadku czynienia z dużą liczbą takich wyrażeń wykonywanych z podobnymi, ale różnymi parametrami (na użytkownika, na urządzenie itp.), które stale się zmieniają.

System powinien umożliwić ewolucję grafu przetwarzania strumienia w czasie wykonywania przez dodanie nowych łączy lub węzłów do grafu obliczeniowego lub zmianę logiki przetwarzania w węzłach obliczeniowych.

Szczegółowa granularność strumienia

W istniejących systemach najmniejszą jednostką abstrakcji jest zwykle cały przepływ (topologia). Jednak wiele scenariuszy docelowych wymaga pojedynczego węzła/łącza w topologii jako jednostki logicznej. W ten sposób każda jednostka może być potencjalnie zarządzana niezależnie. Na przykład w dużej topologii strumienia składającej się z wielu łączy różne linki mogą mieć różne cechy i mogą być implementowane w różnych transportach fizycznych. Niektóre łącza mogą przechodzić przez gniazda TCP, podczas gdy inne używają niezawodnych kolejek. Różne linki mogą mieć różne gwarancje dostarczania. Różne węzły mogą mieć różne strategie tworzenia punktów kontrolnych, a ich logika przetwarzania może być wyrażona w różnych modelach, a nawet w różnych językach. Taka elastyczność zwykle nie jest możliwa w istniejących systemach.

Jednostka abstrakcji i argument elastyczności jest podobna do porównania architektury SoA (architektury zorientowanej na usługi) względem aktorów. Systemy aktorów umożliwiają większą elastyczność, ponieważ każdy aktor jest zasadniczo niezależną "małą usługą". Podobnie system strumieniowy powinien zezwalać na taką precyzyjną kontrolę.

Dystrybucja

I oczywiście system powinien mieć wszystkie właściwości "dobrego systemu rozproszonego". Obejmuje to:

1. Skalowalność: obsługuje dużą liczbę strumieni i elementów obliczeniowych.
2. Elastyczność: umożliwia dodawanie/usuwanie zasobów w celu zwiększania/zmniejszania na podstawie obciążenia.
3. Niezawodność: Odporność na błędy.
4. Wydajność: efektywnie używa podstawowych zasobów.
5. Czas odpowiedzi: umożliwia scenariusze niemal w czasie rzeczywistym.

Były to wymagania dotyczące tworzenia Orleans przesyłania strumieniowego.

Wyjaśnienie: Orleans obecnie nie obsługuje bezpośredniego zapisywania wyrażeń deklaratywnych przepływu danych, takich jak w powyższym przykładzie. Bieżące Orleans interfejsy API przesyłania strumieniowego są bardziej niskopoziomowymi elementami składowymi, zgodnie z opisem w Orleans interfejsach API przesyłania strumieniowego.

Zobacz także

Orleans API strumieniowego przetwarzania