Architecture
Tradycyjna architektura lambda:
-
Batch layer This is the historical archive used to hold all of the data ever collected. This is usually a “data lake” system, such as Hadoop, though it could also be an online analytical processing (OLAP) data warehouse like Vertica or Netezza. The batch layer supports batch queries, which compute historical predefined and ad hoc analytics.
-
Speed layer The speed layer supports computing real-time analytics on fast-moving data as it enters the system. This layer is a combination of queuing, streaming, and operational data stores.
-
Serving layer This layer caches results from batch-layer computations so they are immediately available to answer queries. Computing batch layer queries can take time. Periodically, these analytics are re-computed and the cached results are refreshed in the serving layer.
Koncepcją jaką wprowadza niniejszy projekt jest ujednolicenie tego systemu i połączenie jego funkcjonalnosci w jedno. Wykorzystując technologię Apache Spark możemy połączyć warstwy Speed oraz w Batch w jeden system. Zadanie to znacznie ułatwi wykorzystanie bazy danych klasy NewSQL, która dostarczy niezawodnosci w funkcjonowaniu systemu oraz pozwoli pozbyć się warstwy serving ze względu na pełne wsparcie dla zapytań SQL
Koncepcja systemu:
Jak widać przewidywane elementy systemu to klaster spark, baza danych, oraz jakiego rodzaju frontend. System jest spajany komunikacją poprzez SQL oraz przekazywaiem opisu zapytań z frontend do sprak (Najpewniej za pomocą REST). Przeływ danych przez system jest prosty i zobrazowany poniżej:
Patrząc całkowicie wysokopoziomowo dane wchodzą do bazy z jedenj strony a wychodzą z 2. Dodatkowo zapytania płyną w kierunku przeciwnym do danych.
Nieco dogłębniejsza analiza architektury:
