IoT Hub, prosta implementacja architektury Lambda
Architektura referencyjna Microsoftu pokazuje, że IoT Hub jest naszym gatewayem - furtką wejściową do dalszego rozwiązania chmurowego. I właśnie do tego się przygotowywaliśmy IoT Hub zajmuje się komunikacją z urządzeniem, autentykacją, ustawieniami i zbieraniem danych. Ale potem coś musi się stać z tymi danymi.
Po to mamy Message routing aby przekazać dane dalej.
Oba wzorce różnią się przechowywaniem. Lambda ma dwa osobne miejsca przechowywania dla szybkiej i wolnej ścieżki przetwarzania. Natomiast Kappa przechowuje raz, natomiast reszta pozostaje niezmienna.
Która architektura jest lepsza i z jakich zasobów korzystać zależy od konkretnego przypadku użycia.
Druga część implementacji to np. przechowanie danych z telemetrii w Cosmos DB. Jednak nie ma takiego bezpośredniego połączenia z IoT Hub do Cosmos DB, więc wciśniemy tam sobie funkcję. Oczywiście implementacja gorącej ścieżki wymaga również jakiegoś przetwarzania, ja tego robić nie będę, ale funkcje to idealne miejsce na jakąś analizę oraz podjęcie akcji.
Warto ponownie spojrzeć na poprzedni artykuł i umożliwić przekazywanie wiadomości nie tylko do Storage Account ale również na wbudowany endpoint.
Teraz tworzymy sobie funkcję. Trigger na IoT Hub, output na CosmosDB. Ciało naszej funkcji to wysłanie na output tego co przyszło. That's it.
Na gifie widać niestety że nowy interface nie jest dopracowany.
Po to mamy Message routing aby przekazać dane dalej.
Architektura Lambda oraz Kappa
Gdy wyrzucimy z referencyjnej architektury proponowanej przez Microsoft cały szum informacyjny powodowany przez mnogość zasobów Azurowych możliwych do wykorzystanie w projekcie IoT, pozostaniemy z architekturą Lambda. Jest to jeden z dwóch wzorców architektonicznych przeznaczony do tworzenia rozwiązań typu Big Data. Drugi wzorzec to architektura Kappa.Oba wzorce różnią się przechowywaniem. Lambda ma dwa osobne miejsca przechowywania dla szybkiej i wolnej ścieżki przetwarzania. Natomiast Kappa przechowuje raz, natomiast reszta pozostaje niezmienna.
Która architektura jest lepsza i z jakich zasobów korzystać zależy od konkretnego przypadku użycia.
Najprostsza implementacja architektury Lambda
Najprostsza implementacja chłodnej bądź też zimnej ścieżki (w zależności od nazewnictwa) to zapisanie danych na 'dysku' czyli Azure Storage Account. Tak zapisane dane można potem wykorzystać np. do przetwarzania z wykorzystaniem Machine Learning. Dla dobrego rezultatu tak naprawdę musimy długo zbierać dane, aby potem wyciągnąć z nich informacje, więc najlepiej je przechowywać tanio.Druga część implementacji to np. przechowanie danych z telemetrii w Cosmos DB. Jednak nie ma takiego bezpośredniego połączenia z IoT Hub do Cosmos DB, więc wciśniemy tam sobie funkcję. Oczywiście implementacja gorącej ścieżki wymaga również jakiegoś przetwarzania, ja tego robić nie będę, ale funkcje to idealne miejsce na jakąś analizę oraz podjęcie akcji.
Cold path
To już zrobiliśmy. W message route dodaliśmy endpoint dla storage account a potem route. I to tyleHot path
Nie możemy bezpośrednio z IoT Huba wysłać telemetrii do Cosmos DB. Musimy dodać jakiś zasób służący do przetwarzania i przekazywania wiadomości dalej. Zrobimy to przez Function App i jedną funkcję, która wszystkim się zajmie. Wszystkim to znaczy funkcja wywoła się za każdym razem, gdy przyjdzie jakaś wiadomość do IoT Huba i przekaże tą wiadomość do Cosmos DB.Warto ponownie spojrzeć na poprzedni artykuł i umożliwić przekazywanie wiadomości nie tylko do Storage Account ale również na wbudowany endpoint.
Teraz tworzymy sobie funkcję. Trigger na IoT Hub, output na CosmosDB. Ciało naszej funkcji to wysłanie na output tego co przyszło. That's it.
Na gifie widać niestety że nowy interface nie jest dopracowany.
Dobrze rozpisane, dzięki za rozwiązanie problemu przez ten prosty poradnik:) Chętnie wrócę na tego bloga;)
OdpowiedzUsuń