Лямбда архитектура что это

Обновлено: 05.07.2024

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

Но в статьях про лямбда архитектуру говорится что к процессу работающему с базой так же возможны запросы + возможно сравнение данных из процесса с базой с данными в реал-тайм процессе. На фига? Какой в этом смысл?

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

ты хоть бы ссылки указал

первое похоже на production + standby БД

Ну вот собственно и у меня такое же впечатление сложилось но остаются вопросы которые я описал в первом посте. И если в лямбда архитектуре за счет чего достигается быстрая обработка понятно то с каппа архитектурой ни фига не понятно.

Ссылки это гугл, википедия и ютуб поиск по фразам kappa architecture, lambda architecture. И да все на английском.

Я изучаю архитектуру lambda и понимаю, как ее можно использовать для создания отказоустойчивых систем больших данных.

Мне интересно, как пакетный слой полезен, когда все можно хранить в режиме реального времени и генерировать из него результаты? это потому, что хранилище в реальном времени не может быть использовано для хранения всех данных, тогда оно не будет в реальном времени, так как время, затраченное на извлечение данных, зависит от пространства, которое потребовалось для хранения данных.

3 ответа

Я просто хочу реализовать пользовательский слой для принятия нормы l2 двух векторов (конечно, совпадающих размеров), которые были выведены 2 различными моделями в keras. Я использую функциональный метод API написания функций keras, поэтому у меня есть такие вещи, как: inp1 = Input(someshape) X =.

В дополнение к ответу, предоставленному @karthik manchala , обработка данных может осуществляться тремя способами - пакетным, интерактивным и потоковым в режиме реального времени .

Я полагаю, что ваша ссылка на реальное время больше связана с интерактивным ответом, чем с потоковой передачей, поскольку не все варианты использования связаны с потоковой передачей.

Интерактивные ответы-это когда ответ можно ожидать в любом месте от секунды до нескольких секунд или минут, в зависимости от варианта использования. Ключ здесь в том, чтобы понять, что обработка выполняется на данных в rest, т. е. уже хранится на носителе. Пользователь взаимодействует с системой во время обработки и, следовательно, ожидает ответа. Все усилия Hive по Tez, Impala, Spark core и т. Д. Направлены на решение этой проблемы и как можно более быстрое реагирование.

Потоковая передача с другой стороны-это то, где потоки данных поступают в систему в режиме реального времени - например, каналы twitter, потоки щелчков и т. Д., И обработка должна выполняться сразу же после создания данных. Фреймворки, такие как Storm, Spark Streaming, адресуют это пространство.

В случае пакетной обработки необходимо рассмотреть сценарии, в которых необходимо выполнить некоторую тяжелую работу с огромным набором данных, чтобы пользователь мог поверить, что ответы, которые он видит, находятся в режиме реального времени. Например, индексирование огромной коллекции документов в Apache Solr-это пакетное задание, в котором индексирование будет выполняться в течение нескольких минут или, возможно, часов в зависимости от набора данных. Однако пользователь, запросивший индекс Solr, получит ответ с задержкой в менее секунды. Как вы можете видеть, индексация не может быть достигнута в режиме реального времени, так как могут быть большие объемы данных. То же самое относится и к поиску Google, где индексация будет выполняться в пакетном режиме, а результаты будут представлены в интерактивном режиме.

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

Чтобы сэкономить время и деньги!

Он в основном имеет две функции,

Для управления основным набором данных (предполагается, что он является неизменяемым)
Для предварительного вычисления пакетных представлений для специальных запросов

Все может быть сохранено в режиме реального времени и генерировать результаты из него - НЕПРАВДА

Вышесказанное, безусловно, возможно, но неосуществимо, поскольку данные могут составлять 100's..1000's петабайт, а получение результатов может занять некоторое время.. много времени!

Ключевым моментом здесь является выполнение запросов с низкой задержкой по большому набору данных . Пакетный слой используется для создания пакетных представлений (запросы обслуживаются с низкой задержкой), а слой реального времени используется для последних/обновленных данных, которые обычно невелики. Теперь на любой специальный запрос можно ответить, объединив результаты из пакетных представлений и представлений в реальном времени, а не вычисляя по всему основному набору данных.

Кроме того, подумайте о запросе (тот же запрос?) снова и снова работает над огромным набором данных.. потеря времени и денег!

Наша архитектура-это подход FAAS, где весь наш бэкэнд основан на лямбдах. Уровень персистентности-это управляемый кластер Cloud Mongo, так называемый Atlas . Лямбды в кластере VPC разговаривают с монго, используя пиринговое соединение VPC. Мне нужен VPC с включенным Lambda , потому что Lambda.

Как вы знаете, архитектура Каппа-это своего рода упрощение архитектуры Lambda. Каппа не нуждается в пакетном слое, вместо этого скоростной слой должен гарантировать точность вычислений и достаточную пропускную способность (подробнее parallelism/resources) о повторном вычислении исторических.

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

Если вы хотите пересчитать, вы можете запустить новое задание потоковой обработки, пересчитать представление из Кафки в базу данных и заменить старое представление. Можно использовать только представление в реальном времени в качестве основного хранилища для запроса adhoc, но, как уже упоминалось в других ответах, это быстрее, если у вас много данных для пакетной обработки и потоковой обработки отдельно, а не для выполнения пакетных заданий как потоковое задание. Это зависит от размера ваших данных. Кроме того, дешевле иметь хранилище типа hdfs вместо базы данных для пакетных вычислений.

И последний момент во многих случаях у вас разные алгоритмы пакетной и потоковой обработки, поэтому вам нужно делать это отдельно. Но в принципе можно использовать "realtime view" только в качестве пакетного и потокового слоя, также не используя Кафку в качестве мастер-набора. Это зависит от вашего случая использования.

Задача: графики посещения web-страниц в реальном времени

Может быть сотни и тысячи событий в минуту
Нужна агрегация по ~10 измерениям, их количество будет увеличиваться
Пользователи хотят видеть новые данные сразу
В поступающих данные содержится не вся нужная информация

date	user	url	browser	os	device
12.03.17 10:01	1	www.ya.ru	Opera	Windows	DT
12.03.17 13:44	4	www.st.com	UC	Android	Samsung
12.03.17 15:23	2	www.ya.ru	Safari	iOS	iPhone

Традиционный подход: реляционные БД

Слишком много данных чтобы работать напрямую
Вычислять промежуточные view - замедление в доставке данных
Для быстрой работы запросов нужны индексы по каждому полю
И даже так это слишком медленно.
А еще сложно добавить логику по обогащению данных

Альтернативный подход: NoSQL

Обычно поддерживают поиск только по одному ключу
Проблемы с надежностью
Все еще сложно добавить логику по обогащению данных

Альтернативный подход: MapReduce

Легко добавлять логику!
Но медленные ответы на запросы

. есть ли магический молоток?

Быстрые ответы на запросы
Пользователь сразу видит новые данные
Надежно
Просто

Три основных слоя приложения: Batch Layer, Serving Layer, Speed Layer
Batch Layer и Speed Layer дополняют друг друга в обработке данных
Данные возвращаются пользователю с помощью Query Layer

Ключевая предпосылка

Пользователь А посетил страницу ххх в 22:30 12.03.17

Пользователь B посетил страницу yyy в 14:15 13.03.17

Пользователь А посетил страницу yyy в 15:27 13.03.17

Важно

Raw Data неизменны и верны по умолчанию
Все остальные представления вычисляются на основе Raw Data

Алгоритмы: recomputational vs incremental

Recomputational: чтобы учесть новые данные, нужно повторить вычисления с нуля

И является ли отдельный пакетный уровень быстрее, чем пересчет с механизмом потоковой обработки для пакетной аналитики?

2 ответа

Отдельный пакетный и потоковый слой
Более высокая сложность кода
Более высокая производительность с отдельной партией / потоком
лучше для разных алгоритмов в пакетном и потоковом
дешевле с хранилищем данных для пакетных вычислений вместо базы данных

только слой обработки паром
проще в обслуживании, меньшая сложность, единый алгоритм для пакетного и потокового
слишком много данных будет дорого, если пересчитать из базы данных для партии
слишком много данных будет обрабатываться медленнее, если пересчитать из базы данных или из kafka для пакета

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

Читайте также: