WikiDer > Лямбда-архитектура

Lambda architecture
Поток данных через уровни обработки и обслуживания общей лямбда-архитектуры

Лямбда-архитектура это обработка данных архитектура, предназначенная для обработки огромных объемов данных, используя преимущества обоих партия и потоковая обработка методы. Такой подход к архитектуре пытается сбалансировать задержка, пропускная способность, и Отказоустойчивость за счет использования пакетной обработки для предоставления комплексных и точных представлений пакетных данных с одновременным использованием потоковой обработки в реальном времени для представления интерактивных данных. Два выхода просмотра могут быть объединены перед презентацией. Рост лямбда-архитектуры коррелирует с ростом большое количество данных, аналитика в режиме реального времени и стремление уменьшить задержки уменьшение карты.[1]

Лямбда-архитектура зависит от модели данных с неизменяемым источником данных только для добавления, который служит системой записи.[2]:32 Он предназначен для приема и обработки событий с отметками времени, которые добавляются к существующим событиям, а не перезаписывают их. Состояние определяется естественным упорядочением данных на основе времени.

Обзор

Лямбда-архитектура описывает систему, состоящую из трех уровней: пакетная обработка, скорость (или обработка в реальном времени) и уровень обслуживания для ответа на запросы.[3]:13 Слои обработки получают из неизменяемой главной копии всего набора данных. Эта парадигма была впервые описана Натаном Марцем в сообщении в блоге под названием «Как превзойти теорему CAP», в котором он первоначально назвал ее «пакетной / реальной архитектурой».[4]

Пакетный слой

Пакетный уровень предварительно вычисляет результаты с помощью системы распределенной обработки, которая может обрабатывать очень большие объемы данных. Пакетный слой нацелен на идеальную точность за счет возможности обработки все доступные данные при генерации просмотров. Это означает, что он может исправить любые ошибки путем пересчета на основе полного набора данных, а затем обновления существующих представлений. Выходные данные обычно хранятся в базе данных, доступной только для чтения, а обновления полностью заменяют существующие предварительно вычисленные представления.[3]:18

Apache Hadoop является ведущей системой пакетной обработки, используемой в большинстве архитектур с высокой пропускной способностью.[5] Новые массивно-параллельные эластичные реляционные базы данных, такие как Снежинка, Redshift, Synapse и Big Query также используются в этой роли.

Слой скорости

Диаграмма, показывающая поток данных через уровни обработки и обслуживания лямбда-архитектуры. Показаны примеры именованных компонентов.

Уровень скорости обрабатывает потоки данных в режиме реального времени и без необходимости исправлений или полноты. Этот уровень жертвует пропускной способностью, поскольку он направлен на минимизацию задержки за счет предоставления в реальном времени просмотра самых последних данных. По сути, уровень скорости отвечает за заполнение «пробела», вызванного запаздыванием пакетного уровня в предоставлении представлений на основе самых последних данных. Представления этого слоя могут быть не такими точными или полными, как те, которые в конечном итоге создаются пакетным слоем, но они доступны почти сразу после получения данных и могут быть заменены, когда становятся доступными представления пакетного слоя для тех же данных.[3]:203

Технологии потоковой обработки, обычно используемые на этом уровне, включают Apache Storm, SQLstream, Apache Spark, Azure Stream Analytics и Azure Cosmos DB. Вывод обычно хранится в быстрых базах данных NoSQL.[6][7]

Слой сервировки

Диаграмма, показывающая лямбда-архитектуру с хранилищем данных Druid.

Выходные данные из уровней пакетной обработки и скорости хранятся на уровне обслуживания, который отвечает на специальные запросы, возвращая предварительно вычисленные представления или создавая представления из обработанных данных.

Примеры технологий, используемых на уровне обслуживания, включают: Друид, который предоставляет единый кластер для обработки вывода с обоих уровней.[8] Специализированные магазины, используемые на обслуживающем уровне, включают: Apache Cassandra, Apache HBase, Azure Cosmos DB, MongoDB, VoltDB или же Elasticsearch для вывода скоростного слоя и Слон БД, Apache Impala, SAP HANA или же Apache Hive для пакетного вывода.[2]:45[6]

Оптимизация

Для оптимизации набора данных и повышения эффективности запросов к необработанным данным применяются различные методы объединения и агрегирования.[8]:23 в то время как методы оценки используются для дальнейшего снижения затрат на вычисления.[9] И хотя для обеспечения отказоустойчивости требуется дорогостоящий полный пересчет, для повышения эффективности могут выборочно добавляться алгоритмы инкрементальных вычислений, а также такие методы, как частичное вычисление а оптимизация использования ресурсов может эффективно снизить задержку.[3]:93,287,293

Лямбда-архитектура в использовании

Metamarkets, который предоставляет аналитику для компаний в области программатик-рекламы, использует версию лямбда-архитектуры, которая использует Друид для хранения и обслуживания как потоковых, так и пакетных данных.[8]:42

Для выполнения аналитики своего хранилища рекламных данных, Yahoo использовал аналогичный подход, также используя Apache Storm, Apache Hadoop, и Друид.[10]:9,16

В Netflix В проекте Suro есть отдельные пути обработки данных, но он не строго следует лямбда-архитектуре, поскольку пути могут быть предназначены для различных целей и не обязательно для предоставления одного и того же типа представлений.[11] Тем не менее, общая идея состоит в том, чтобы сделать выбранные данные о событиях в реальном времени доступными для запросов с очень низкой задержкой, в то время как весь набор данных также обрабатывается через пакетный конвейер. Последний предназначен для приложений, которые менее чувствительны к задержкам и требуют обработки с уменьшением карты.

Критика

Критика лямбда-архитектуры сосредоточена на присущей ей сложности и ограничивающем влиянии. Каждая из сторон пакетной и потоковой передачи требует разной базы кода, которую необходимо поддерживать и синхронизировать, чтобы обработанные данные давали одинаковый результат на обоих путях. Однако попытка абстрагировать кодовые базы в единую структуру делает многие специализированные инструменты в пакетных экосистемах и экосистемах реального времени недоступными.[12]

В ходе технического обсуждения преимуществ использования подхода чистой потоковой передачи было отмечено, что использование гибкой структуры потоковой передачи, такой как Apache Samza может обеспечить некоторые из тех же преимуществ, что и пакетная обработка без задержки.[13] Такая структура потоковой передачи может позволить собирать и обрабатывать произвольно большие окна данных, размещать блокировку и обрабатывать состояние.

Смотрите также

Рекомендации

  1. ^ Шустер, Вернер. «Натан Марц о Storm, неизменяемость в лямбда-архитектуре, Clojure». www.infoq.com. Интервью с Натаном Марцем, 6 апреля 2014 г.
  2. ^ а б Биджненс, Натан. «Архитектура реального времени с использованием Hadoop и Storm». 11 декабря 2013 г.
  3. ^ а б c d Марз, Натан; Уоррен, Джеймс. Большие данные: принципы и лучшие практики масштабируемых систем данных в реальном времени. Публикации Мэннинга, 2013.
  4. ^ Марз, Натан. «Как победить теорему CAP». 13 октября 2011 г.
  5. ^ Кар, Сародж. «Сектор Hadoop будет иметь ежегодный рост на 58% в 2013-2020 годах» В архиве 2014-08-26 в Archive.today, 28 мая 2014 г. Cloud Times.
  6. ^ а б Кинли, Джеймс. «Лямбда-архитектура: принципы построения систем больших данных в реальном времени», получено 26 августа 2014 г.
  7. ^ Феррера Бертран, Пере. «Лямбда-архитектура: самое современное». 17 января 2014 г., Datasalt.
  8. ^ а б c Ян, Фанцзинь и Мерлино, Джиан. «Аналитика в реальном времени с использованием технологий с открытым исходным кодом». 30 июля 2014 г.
  9. ^ Рэй, Нельсон. «Искусство аппроксимации распределений: гистограммы и квантили в масштабе». 12 сентября 2013. Метамаркет.
  10. ^ Рао, Суприт; Гупта, Сунил. «Интерактивная аналитика в человеческом времени». 17 июня 2014 г.
  11. ^ Пэ, Чжэ Хён; Юань, Дэнни; Тонсе, Судхир. «Представляем Suro: основу конвейера данных Netflix», Netflix, 9 декабря 2013 г.
  12. ^ Крепс, Джей. «Ставя под сомнение лямбда-архитектуру». radar.oreilly.com. Oreilly. Получено 15 августа 2014.
  13. ^ Хакерские новости получено 20 августа 2014 г.

внешняя ссылка