Jump to content

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

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

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

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

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

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

[ редактировать ]

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

К 2014 году Apache Hadoop считался ведущей системой пакетной обработки. [5] Позже другие, реляционные базы данных, такие как Snowflake в этой роли стали использоваться и , Redshift, Synapse и Big Query.

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

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

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

Технологии потоковой обработки, обычно используемые на этом уровне, включают Apache Kafka , Amazon Kinesis , Apache Storm , SQLstream , Apache Samza , Apache Spark , Azure Stream Analytics , Apache Flink . Вывод обычно сохраняется в быстрых базах данных NoSQL. [6] [7] или как журнал фиксации. [8]

Уровень обслуживания

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

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

Примеры технологий, используемых на уровне обслуживания, включают Apache Druid , Apache Pinot , ClickHouse и Tinybird , которые предоставляют единую платформу для обработки выходных данных обоих уровней. [9] Выделенные хранилища, используемые на уровне обслуживания, включают Apache Cassandra , Apache HBase , Azure Cosmos DB , MongoDB , VoltDB или Elasticsearch для вывода на быстром уровне, а также Elephant DB , Apache Impala , SAP HANA или Apache Hive для вывода на пакетном уровне. [2] : 45  [6]

Оптимизации

[ редактировать ]

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

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

[ редактировать ]

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

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

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

Критика и альтернативы

[ редактировать ]

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

Каппа архитектура

[ редактировать ]

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

См. также

[ редактировать ]
  1. ^ Шустер, Вернер. «Натан Марц о Storm, неизменности в лямбда-архитектуре, Clojure» . www.infoq.com . Интервью с Натаном Марцем, 6 апреля 2014 г.
  2. ^ Jump up to: а б Бийненс, Натан. «Архитектура реального времени с использованием Hadoop и Storm» . 11 декабря 2013 г.
  3. ^ Jump up to: а б с д Марз, Натан; Уоррен, Джеймс. Большие данные: принципы и лучшие практики масштабируемых систем данных реального времени . Публикации Мэннинга, 2013.
  4. ^ Марз, Натан. «Как обойти теорему CAP» . 13 октября 2011 г.
  5. ^ Кар, Сародж. «Сектор Hadoop будет иметь годовой рост на 58% в 2013–2020 годах». Архивировано 26 августа 2014 г. на archive.today , 28 мая 2014 г. Cloud Times .
  6. ^ Jump up to: а б Кинли, Джеймс. «Архитектура Lambda: принципы построения систем больших данных реального времени». Архивировано 4 сентября 2014 г. на Wayback Machine , получено 26 августа 2014 г.
  7. ^ Феррера Бертран, Пере. «Лямбда-архитектура: современное состояние» . 17 января 2014, Датасалт.
  8. ^ Сливающийся. «Kafka и Events – пары ключ/значение» , получено 6 октября 2022 г.
  9. ^ Jump up to: а б с Ян, Фанджин и Мерлино, Джиан. «Аналитика в реальном времени с использованием технологий с открытым исходным кодом» . 30 июля 2014 г.
  10. ^ Рэй, Нельсон. «Искусство аппроксимации распределений: гистограммы и квантили в масштабе» . 12 сентября 2013. Метарынки.
  11. ^ Рао, Суприт; Гупта, Сунил. «Интерактивная аналитика в человеческом времени» . 17 июня 2014 г.
  12. ^ Пэ, Джэ Хён; Юань, Дэнни; Тонсе, Судхир. «Анонсируем Suro: основу конвейера данных Netflix» , Netflix , 9 декабря 2013 г.
  13. ^ Jump up to: а б Крепс, Джей. «Под вопросом лямбда-архитектура» . радар.oreilly.com . Орейли . Проверено 15 августа 2014 г.
  14. Hacker News получено 20 августа 2014 г.
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 82dc21a8f84cb0493e988d81584de5d3__1720744320
URL1:https://arc.ask3.ru/arc/aa/82/d3/82dc21a8f84cb0493e988d81584de5d3.html
Заголовок, (Title) документа по адресу, URL1:
Lambda architecture - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)