Architektura lambda to architektura przetwarzania danych zaprojektowana do obsługi ogromnych ilości danych poprzez wykorzystanie metod przetwarzania partii i przepływu przetwarzania . Takie podejście do architektury próbuje zrównoważyć opóźnienia, przepustowość i tolerancję na awarie przy użyciu przetwarzania wsadowego, aby zapewnić pełny i dokładny widok danych w partiach, jednocześnie wykorzystując obróbkę w czasie rzeczywistym do przepływu danych, zapewniając podgląd danych online. Dwa wyjścia widoku można połączyć przed prezentacją. Rozwój architektury lambda jest skorelowany ze wzrostemBigData , do analizy w czasie rzeczywistym i chęci złagodzenia opóźnień mapreduce .
Architektura Lambda jest oparta na modelu danych z niezmiennym, dodawanym źródłem danych, które służy jako system rekordów. Jest przeznaczony do pozyskiwania i przetwarzania zdarzeń ze znacznikiem czasu, które są dodawane do istniejących wydarzeń zamiast ich nadpisywania. Stan jest określany na podstawie naturalnego porządku danych w oparciu o czas.
Architektura Lambda to system składający się z trzech warstw: przetwarzania wsadowego, szybkiego przetwarzania (lub w czasie rzeczywistym) oraz warstwy serwerowej odpowiadającej na żądania. . Warstwy przetwarzania pobierają cały zestaw danych z niezmiennej kopii głównej.
Warstwa przetwarzania wsadowego wstępnie oblicza wyniki przy użyciu rozproszonego systemu przetwarzania zdolnego do przetwarzania bardzo dużych ilości danych. Warstwa przetwarzania wsadowego zapewnia doskonałą precyzję, umożliwiając przetwarzanie wszystkich danych dostępnych podczas generowania widoków. Oznacza to, że może korygować błędy, ponownie obliczając wszystkie dane, a następnie aktualizując istniejące widoki. Dane wyjściowe są zwykle przechowywane w bazie danych tylko do odczytu, a aktualizacje całkowicie zastępują istniejące wstępnie obliczone widoki.
Apache Hadoop jest standardowym de facto systemem przetwarzania wsadowego używanym w większości architektur o dużej przepustowości.
Warstwa czasu rzeczywistego przetwarza strumienie danych w czasie rzeczywistym i bez wymagań dotyczących naprawy lub kompletności. Warstwa ta poświęca przepustowość, ponieważ ma na celu zminimalizowanie opóźnień, zapewniając w czasie rzeczywistym widoki najnowszych danych. Zasadniczo warstwa czasu rzeczywistego jest odpowiedzialna za wypełnienie „luki” spowodowanej opóźnieniem warstwy przetwarzania wsadowego w dostarczaniu widoków opartych na najnowszych danych. Widoki w tej warstwie mogą nie być tak dokładne lub kompletne, jak te, które są prawdopodobnie tworzone przez warstwę wsadową, ale są dostępne niemal natychmiast po otrzymaniu danych i mogą zostać nadpisane, gdy widoki w warstwie wsadowej staną się dostępne.
Powszechnie używane technologie przetwarzania strumienia w tej warstwie obejmują Apache Storm , SQLstream, Apache Spark lub Apache Flink . Dane wyjściowe są zwykle przechowywane w szybkich bazach danych NoSQL .
Dane wyjściowe warstw wsadowych i warstw czasu rzeczywistego są przechowywane w warstwie usług, która odpowiada na żądania ad hoc, zwracając wstępnie obliczone widoki lub tworząc widoki z przetworzonych danych.
Jako przykład technologii stosowanej w warstwie usług można przytoczyć Apache Druid , który udostępnia pojedynczy klaster do zarządzania danymi wyjściowymi obu warstw. Inne technologie dla warstwy usług to Apache Cassandra , Apache HBase , MongoDB , VoltDB lub Elasticsearch dla danych wyjściowych warstwy czasu rzeczywistego oraz Elephant DB , Apache Impala , SAP HANA lub Apache Hive dla danych wyjściowych warstwy Batch.
Aby zoptymalizować zbiór danych i poprawić wydajność zapytań, różne techniki zestawiania i agregacji są wykonywane na surowych danych, podczas gdy techniki szacowania są stosowane w celu dalszego zmniejszenia kosztów obliczeniowych. I chociaż pełne i kosztowne ponowne obliczenie jest konieczne w celu zapewnienia odporności na błędy, algorytmy obliczeń przyrostowych mogą być selektywnie dodawane w celu zwiększenia wydajności, a techniki, takie jak obliczenia częściowe i optymalizacja wykorzystania, mogą skutecznie pomóc w zmniejszeniu opóźnień.
Krytyka architektury lambda skupiła się na jej wrodzonej złożoności i ograniczającym wpływie. Strony wsadowe i strumieniowe wymagają innej bazy kodu, którą należy zarządzać i synchronizować, aby przetworzone dane dawały ten sam wynik w obu ścieżkach. Jednak próba odejścia od baz kodu w jednym frameworku powoduje, że wiele narzędzi specjalizujących się w ekosystemach wsadowych i czasu rzeczywistego jest poza zasięgiem.
Podczas technicznej dyskusji na temat korzyści płynących ze stosowania czystego przesyłania strumieniowego zauważono, że korzystanie z elastycznej struktury przesyłania strumieniowego, takiej jak Apache Samza, może zapewnić takie same korzyści, jak przetwarzanie wsadowe bez opóźnień. Taka struktura przesyłania strumieniowego mogłaby umożliwić gromadzenie i przetwarzanie okien danych o dowolnym rozmiarze, dostosowywanie blokowania i zarządzanie stanem.