Лямбда-архитектура — один из новейших трендов работы с данными, не так давно перекочевавший из кулуаров конференций по вопросам Data Science в офисы самых современных и дальновидных компаний.
Что такое лямбда-архитектура?
О том, что анализа «исторических» данных для целей компаний в скором времени уже будет недостаточно, всерьез заговорили примерно в начале 2010-х. Действительно: сегодня, когда рынки как никогда динамичны и данные имеют свойство устаревать иногда за считанные секунды, информация, поступающая в реальном времени, бывает куда важнее для компании, чем та, что кропотливо собирается и «раскладывается по полочкам», чтобы потом простаивать «до востребования» в КХД.
Примером может служить задача рассылки контекстной рекламы мобильным оператором: с одной стороны, необходимо быстро и точно сегментировать каталог клиентам (организовав доступ к большим историческим данным для дальнейшего их анализа) и одновременно определить местоположение каждого конкретного абонента в режиме реального времени, чтобы успеть сообщить последнему о некоем объекте, пока тот находится в зоне его досягаемости (как результат анализа непрерывного потока данных).
Именно такой доступ к «большим и быстрым» данным призвана обеспечить лямбда-архитектура – не такое уж и новое (с точки зрения технологии), но все-таки существенное слово в области анализа данных. Строго говоря, основные свойства этой архитектуры укладываются в одну фразу: «Лямбда представляет собой общий подход, направленный на применение произвольной функции к произвольному набору данных, при этом обеспечивая минимальный период ожидания возвращения функцией искомого значения.» То есть подразумевается, что это такой общий механизм, способный решать задачи «повышенной сложности» за счет своей универсальности. Давайте разберемся, до чего же конкретно «дошел прогресс».
Как это работает?
Лямбда-архитектура имеет структуру, состоящую из трёх уровней:
1. Пакетный уровень – архив сырых исторических данных. Чаще всего, это «озеро данных» на базе Hadoop, хотя встречается и в форме OLAP-хранилища данных, например, Vertica. Этот уровень, как понятно из названия, поддерживает и оперирует пакетной передачей данных. Важно заметить, что старые данные здесь остаются неизменными – происходит лишь добавление новых.
2. Сервисный уровень индексирует пакеты и обрабатывает результаты вычислений, происходящих на пакетном уровне. За счёт индексации и обработки поступающей информации, результаты немного отстают во времени.
3. Уровень ускорения отвечает за обработку данных, поступающих в систему в реальном времени. Представляет собой совокупность складов данных, в которых те находятся в режиме очереди, в потоковом или в рабочем режиме. На этом уровне компенсируется разница в актуальности данных, а в отдельные представления реального времени добавляется информация с коротким жизненным циклом (чтобы исключить дублирование данных). Эти представления параллельно с сервисным уровнем обрабатывают свои запросы.
Итак, актуальность информации не теряется, целостность данных не нарушается, дублирование и, соответственно, «захламление» КХД не происходит. Плюс ко всему, такая система невосприимчива к единичным случаям потери или повреждения данных, а еще есть замечательная возможность перевычисления на исходных данных, которые никуда не деваются.
В чём подвох?
С первого взгляда это неочевидно, но даже у такой стройной и продуманной архитектуры обнаруживается ряд слабых мест:
а) Упор на конечную непротиворечивость данных делает невозможным отправку данных обратно на пакетный уровень, поэтому поменять стратегию анализа «на ходу» не получится – можно только провести вычисления заново.
б) NoSQL – большинство инструментов, ориентированных на лямбда-архитектуру, не поддерживает ни SQL-запросов, ни привычных средств бизнес-аналитики.
в) «Сложносочинённость» — на текущий момент типичная лямбда-архитектура состоит из множества разнородных компонентов, передающих данные от одного к другому (в пределах каждого из уровней, в том числе). Понятно, что это часто служит помехой вычислениям в реальном времени, для которых, в общем-то, архитектура и создавалась.
Резюме:
Лямбда-архитектура не является каким-то революционным подходом. Подобные решения, например, предвычисленные временные таблицы, использовались для ускорения обработки запросов к большим объемам данных. Правда, эти решения скорее служили для узкоспециализированных, локальных задач.
Лямбда же — архитектура с претензией на универсальность, которую она, в общем-то, оправдывает: несмотря на существенные ограничения, ту самую дилемму «скорость vs надёжность» она решает с наименьшими потерями. Несомненно, в ближайшее время появятся все новые и новые предложения по усовершенствованию – а свою нишу архитектура уже точно завоевала.
| Обработка данных |
