Лямбда-архітектура

Потоки даних через шари обробки та сервісний шар загальної лямбда-архітектури

Лямбда-архітектура — це архітектура обробки даних, розроблена для роботи з великими обсягами даних, використовує переваги як пакетної, так і потокової обробки.

Цей архітектурний підхід прагне збалансувати затримку, пропускну здатність і стійкість до відмов, застосовуючи пакетну обробку для отримання всебічних і точних пакетних даних, а також обробку потоків в реальному часі для онлайн-даних.

Два отриманих представлення можна об'єднати перед поданням клієнту в шар візуалізації.

Розвиток лямбда-архітектури пов'язаний із розвитком Big Data, аналітикою в реальному часі та прагненням зменьшити затримки при map-reduce підході. Цю парадигму вперше описав Натан Марц у своєму дописі в блозі під назвою «Як подолати теорему CAP» (англ. «How to beat the CAP theorem»), де він спочатку назвав її «архітектурою пакетної/обробки в реальному часі».

Огляд

Лямбда-архітектура поділяється на три шари (layer):

• Пакетний шар: Зберігає всі дані в незмінному вигляді та обробляє їх пакетно. Цей шар забезпечує високу точність та узгодженість даних.
• Шар обробки потоків: Обробляє дані в реальному часі, генеруючи поточні представлення даних. Цей шар використовується для задач, де критична швидкість, а не точність.
• Сервісний шар: Зберігає результати обробки з обох шарів та надає доступ до них для візуалізації та аналітики.

Шар пакетної обробки

Шар пакетної обробки попередньо обчислює результати за допомогою розподіленої системи обробки, яка може працювати з дуже великими обсягами даних. Шар пакетної обробки прагне до абсолютної точності, оскільки він може обробити всі доступні дані під час генерації представлень. Це означає, що він може виправити будь-які помилки шляхом перерахунку на основі повного набору даних, а потім оновити існуючі представлення. Результат зазвичай зберігається в базі даних лише для читання, при цьому оновлення повністю замінюють існуючі попередньо обчислені представлення. В 2014 році, Apache Hadoop вважався провідною системою пакетної обробки. Пізніше в цій ролі також почали використовувати інші реляційні бази даних, такі як Snowflake, Redshift], Synapse і BigQuery.

Шар швидкої обробки

Шар швидкої обробки обробляє потоки даних в реальному часі без необхідності виправлень чи забезпечення повноти. Цей шар жертвує пропускною здатністю, оскільки його метою є мінімізація затримки шляхом надання представлень у реальному часі для найновіших даних. По суті, шар швидкої обробки відповідає за заповнення «прогалини», спричиненої затримкою пакетного шару в наданні представлень на основі найновіших даних. Представлення цього шару можуть бути не такими точними чи повними, як ті, що зрештою генеруються пакетним шаром, але вони стають доступними майже відразу після отримання даних і можуть бути замінені, коли стають доступними представлення пакетного шару для тих самих даних.

Типовими технологіями обробки потоків, що використовуються в цьому шарі, є Apache Kafka, Amazon Kinesis, Apache Storm, SQLstream, Apache Samza, Apache Spark, Azure Stream Analytics. Результат зазвичай зберігається в швидких базах даних NoSQL або як інший журнал підтвержених дій.

Сервісний шар

Результати пакетного та швидкісного шарів зберігаються в сервісному шарі, який відповідає на ad-hoc-запити, повертаючи попередньо обчислені представлення або створюючи представлення з оброблених даних. Сервісний шар об'єднує результати з пакетного та шара швидкої обробки, надаючи користувачам єдиний інтерфейс для доступу до даних.

Прикладами технологій, що використовуються в сервісному шарі, є Apache Druid, Apache Pinot, ClickHouse. Вони надають єдину платформу для обробки вихідних даних з обох шарів. Додатково в сервісному шарі можуть використовуватись спеціалізовані сховища. Наприклад, для вихідних даних швидкісного шару можуть використовуватись Apache Cassandra, Apache HBase, Azure Cosmos DB, MongoDB, VoltDB або Elasticsearch. Для вихідних даних пакетного шару можуть використовуватись Apache Impala, SAP HANA або Apache Hive.