Лямбда архитектура что это
Строим надёжный процессинг данных — лямбда архитектура внутри Google BigQuery
В этой статье хочу поделиться способом, который позволил нам прекратить хаос с процессингом данных. Раньше я считал этот хаос и последующий ре-процессинг неизбежным, а теперь мы забыли что это такое. Привожу пример реализации на BiqQuery, но трюк довольно универсальный. 
У нас вполне стандартный процесс работы с данными. Исходные данные в максимально сыром виде регулярно подгружаются в единое хранилище, в нашем случае в BigQuery. Из одних источников (наш собственный продакшн) данные приходят каждый час, из других (обычно сторонние источники) данные идут ежедневно.
В последствии данные обрабатываются до состояния пригодного к употреблению разнообразными пользователями. Это могут быть внутренние дашборды; отчёты партнёрам; результаты, которые идут в продакшн и влияют на поведение продукта. Эти операции могут быть довольно сложными и включать несколько источников данных. Но по большей части мы с этим справляется внутри BigQuery с помощью SQL+UDF. Результаты сохраняются в отдельные таблицы там же.
Очевидным способом организации этого процессинга является создание расписания операций. Если данные подгружаются ежедневно в час ночи, то мы настроим процессинг на 01:05. Если этот источник данных подгружается в районе 5й минуты каждого часа, то настроим процессинг на 10ю минуту каждого часа. Промежутки в 5 минут для пользователей не критичны и предполагается, что всё должно работать.
Но мир жесток! Данные не всегда приходят вовремя. Или вообще не приходят, если не починить. Если твоя часовая загрузка закончилась на 11й минуте, а трансформация запускалась на 10й – то пожалуйста, жди ещё час чтобы увидеть эти данные в дэшборде. А если операция использует несколько источников, то ситуация будет ещё веселее.
Более того, подгружаемые сырые данные не всегда верны (данные вообще всегда не верны!). Периодически данные приходится чистить или перезагружать. И тогда нужно перезапустить все операции и с корректными параметрами, чтобы всё починилось.
Это всё, конечно, проблемы с сырыми данными и нужно именно их и решать. Но это та война, в которой нельзя окончательно победить. Что-то всё равно будет поломано. Если источник данных внутренний – то ваши разработчики будут заняты новыми крутыми фичами, а не надёжностью трекинга. Если это сторонние данные, тогда вообще труба. Хотелось бы, чтобы по крайней мере процессинг не мешался по дороге и как только сырые данные починены — все клиенты сразу видели корректные результаты.
Это реально большая проблема. И как же ещё решить?
Решение №1 – убрать проблемные детали
Если процессинг приводит к проблемам, то не надо его делать! Не надо делать вообще никакой процессинг и хранить промежуточные результаты. Как только пользователю нужны результаты, всё должно вычисляться на лету из сырых данных. Учитывая скорость BigQuery это вполне реалистично. Особенно если все что вы делаете с данными это GROUP BY date и count(1), и нужны только данные за последние 14 дней.
Большинство аналитики работает именно с такими запросами. Поэтому мы данное решение активно используем. Но этот подход не работает со сложными трансформациями.
Одна проблема – это сложность кода. Если сложить все операции в один SQL запрос, то его будет не прочитать. К счастью это решается за счёт таблиц типа view (представления). Это логические таблицы в BigQuery, данные в них не хранятся, а генерируются из SQL-запроса на лету. Это сильно упрощает код.
Но другая проблема – это производительность. Здесь всё плохо. Не важно какие быстрые и дешёвые современные базы данных. Если запустить сложную трансформацию на одном годе исторических данных, это займёт время и будет стоить денег. Других вариантов нет. Эта проблема делает данную стратегию неприменимой в довольно большом проценте случаев.
Решение № 2 – построить сложную систему
Если нет возможности обойтись без системы управления процессингом, то нужно построить эту систему хорошо. Не просто расписание выполнения скриптов в cron, а система мониторинга загрузки данных, которая определяет когда и какие трансформации запускать. Наверное паттерн pub/sub тут очень подходит.
Но есть проблема. Если построить сложную систему более менее просто, то вот поддерживать её и ловить баги – это очень сложно. Чем больше кода, тем больше проблем.
По счастью есть и третье решение.
Решение № 3 – лямбда архитектура! …ну, типа того
Лямбда архитектура – это знаменитый подход к процессингу данных, который использует преимущества обработки данных по расписанию и в реальном времени:
*Как нормально перевести на русский не знаю, batch job – это что пакетное задание? Кто знает, подскажите!
Обычно это все строится с использованием нескольких решений. Но мы используем по сути тот же трюк просто внутри BigQuery.
И вот как это работает:
Процессинг по расписанию (Batch layer). Мы ежедневно выполняем SQL-запросы, которые трансформируют данные имеющиеся на текущий момент, и сохраняем результаты в таблицы. У всех запросов следующая структура:
Результаты этого запроса будут сохранены в table_static (перезапишут её). Да, BigQuery позволяет сохранять результаты запроса в таблице, которая использовалась в этом запросе. В итоге мы берём старые, уже посчитанные данные (чтобы их не пересчитывать) и соединяем с новыми данными. X дней – это выбранный период, за который мы хотим пересчитать данные, чтобы учесть все возможные корректировки сырых данных. Предполагается что за X дней (сколько – это индивидуально для источника) все корректировки уже будут внесены, всё что сломалось починится и данные уже больше не будут меняться.
Доступ в реальном времени (Speed layer + Serving layer). Эти обе задачи объединены в один SQL-запрос:
Да, это тот же самый запрос! Его мы сохраняем как представление (view) с именем table_live и все пользователи (дэшборды, другие запросы, и т.п.) тянут результаты из этого представления. Так как представления в BigQuery хранятся на логическом уровне (только запрос, не данные), каждый раз при обращении он будет пересчитывать последние X дней на лету и все изменения в изначальных данных будут отражены в результатах.
Так как запрос в обоих случаях одинаковый, то в реальности, чтобы избежать дупликации кода, ежедневный запрос (из batch layer) выглядит так:
(и сохраняем результаты в table_static)
PS Если любите использовать таблицы разбитые по датам в BigQuery (мы очень любим), то есть решение и для этого. Но это тема для другого поста. Подсказка – функции для работы с этими таблицами не ругаются, если часть таблиц – это только представления.
PPS Если бы представления в BigQuery поддерживали кешинг (как это работает с обычными запросами), это было бы реально круто. Это по сути сделало бы их материализованными (materialized views). И эффективность нашего подхода стала бы ещё выше. Если вы согласны – здесь можно поставить звёздочку, чтобы эту фичу быстрее реализовали.
Лямбда архитектура что это
Вчера мы рассказали, что такое лямбда-архитектура. Сегодня рассмотрим Каппа – альтернативный подход к проектированию Big Data систем. Читайте в нашей статье, зачем нужна эта концепция, каковы ее достоинства и недостатки, чем Каппа отличается от Лямбда, где это используется на практике и при чем тут Apache Kafka с Machine Learning.
Зачем нужна Каппа-архитектура и как она устроена
При всех достоинствах Лямбда-архитектуры, главным недостатком этого подхода к проектированию Big Data систем считается его сложность из-за дублирования логики обработки данных в холодном и горячем путях. Поэтому в 2014 году была предложена Каппа – альтернативная модель, которая потребляет меньше ресурсов, но отлично подходит для обработки событий в режиме реального времени [1].
В отличие от лямбда, в Каппа-архитектуре потоковые данные проходят по одному пути. Все данные принимаются как поток событий в распределенном и отказоустойчивом едином журнале – логе событий. Там события упорядочиваются, и текущее состояние события изменяется только при добавлении нового события. Аналогично уровню ускорения лямбда-архитектуры, вся обработка событий выполняется во входном потоке и сохраняется как представление в режиме реального времени. Если необходимо повторно вычислить весь набор данных, как на пакетном уровне в лямбда-архитектуре, поток воспроизводится заново. Для своевременного завершения вычислений используется параллелизм [2].
Функциональное уравнение, которое определяет запрос Big Data, в Каппа-архитектуре будет выглядеть так [1]:
Query = K (New Data) = K (Live streaming data)
Это уравнение означает, что все запросы могут быть обработаны путем применения функции Каппа (К) к real-time потокам данных на скоростном уровне.
Таким образом, можно сказать, что Каппа-архитектура – это упрощение Лямбда-подхода к проектированию Big Data систем, когда из модели удален уровень пакетной обработки данных. При этом каноническое хранилище данных представляет собой неизменяемый журнал только для добавления информации. Из журнала данные сразу передаются в систему потоковых вычислений, по необходимости обогащаясь данными из неканонического хранилища (сервисный уровень). Цель сервисного уровня – предоставить оптимизированные ответы на запросы. Однако эти хранилища не являются каноническими (неизменяемыми): их можно в любой момент стереть и восстановить из канонического Data Store [3].
Для реализации Каппа-архитектуры используются следующие технологии Big Data [3]:
Где используется K-подход и причем здесь Apache Kafka
Итак, Kappa-архитектура целесообразна для таких корпоративных моделей обработки данных, где [1]:
Все эти сценарии отлично покрываются брокером сообщений Apache Kafka – быстрой, отказоустойчивой и горизонтально масштабируемой системой сбора и агрегации больших данных. Поэтому Каппа-архитектура на базе Kafka активно используется LinkedIn и другими Big Data проектами, где требуется сохранить большой объем данных для обслуживания запросов, которые являются простой копией друг друга [1].
Lambda или Kappa: что и когда выбирать
Прежде всего отметим, что при общих целях построения надежной и быстрой системы обработки больших данных, подходы лямбда и каппа не конкурируют друг с другом, а могут использоваться вместе для разных случаев. В частности, для надежной работы с озером данных (Data Lake) на базе Apache Hadoop и моделями машинного обучения для прогнозирования будущих событий на основе исторических данных, следует выбрать Лямбда-подход. С другой стороны, если необходимо недорого развернуть Big Data систему для эффективной обработки уникальных событий в реальном времени без исторического анализа, Каппа-архитектура отлично справится с этой задачей. Каппа подходит для тех алгоритмов Machine Learning, которые обучаются в режиме онлайн и не нуждаются в пакетном уровне. Таким образом, для Kappa характерны следующие достоинства [1]:
Тем не менее, отсутствие пакетного уровня может привести к ошибкам при обработке информации или при обновлении базы данных. Поэтому в Каппа-архитектуре возникает потребность в диспетчере исключений для повторной обработки данных или сверки [1]. В следующей статье мы поговорим про процессы и инструменты обеспечения качества больших данных с помощью Apache Spark, Airflow и других Big Data фреймворков. А тему архитектуры продолжим здесь.
Чем отличается Каппа от Лямбда архитектуры
Как реализовать Лямбда или Каппа-архитектуру на базе Apache Kafka, Spark и других фреймворках больших данных, вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Лямбда архитектура что это
Рассматривая основы больших данных, сегодня мы расскажем лямбда-архитектуру, одну из двух главных подходов к построению Big Data систем. Читайте в нашей статье, зачем нужна эта концепция и как она работает, а также при чем тут машинное обучение, интернет вещей, Apache Spark и Hadoop.
Что такое Лямбда-архитектура и зачем она нужна
Рассмотрим типичный кейс по рассылке контекстной рекламы о скидках в ближайшем офлайн-магазине. Для повышения конверсии необходимо персонализировать маркетинговое предложение. Для этого следует быстро и точно сегментировать каталог клиентов с учетом анализа исторических данных по каждому из них, одновременно определив местоположение конкретного абонента в режиме реального времени. За сегментирование и предиктивную аналитику клиентских потребностей отвечают алгоритмы машинного обучения (Machine Learning). При этом реклама становится нерелевантной при физическом перемещении потребителя, поэтому нужно успеть сообщить потенциальному покупателю маркетинговое предложение, пока он находится в зоне пешей досягаемости торгового объекта. Таким образом, требуется выполнить онлайн-анализ непрерывного потока геоданных.
Этот пример отлично иллюстрирует задачи Big Data системы, когда есть потребность в интерактивной предиктивной аналитике на базе исторического бэкграунда. Разумеется, большие данные предполагают высокую скорость их обработки. Однако, на практике, некоторые операции, в частности, классический MapReduce на Hadoop, могут выполняться достаточно долго. В ряде случаев подобная задержка приведет к устареванию информации и потери ее актуальности. Чтобы предупредить эту проблему, необходимо объединить потоковую обработку данных в режиме реального времени с результатами пакетной аналитики. Для этого была предложена лямбда-архитектура, когда обработка данных разделяется на 2 пути [1]:
В этой архитектуре также выделяют сервисный уровень (или уровень обслуживания), который индексирует пакетное представление – результаты пакетного уровня для эффективного выполнения запросов. За счет индексации и обработки поступающей информации, результаты немного отстают во времени. Уровень ускорения обновляет уровень обслуживания, отправляя ему добавочные обновления с учетом последних данных [1].
Лямбда-архитектура Big Data систем
Таким образом, лямбда – это архитектурный подход, при котором произвольная функция применяется к произвольному набору данных за минимальное время. Универсальность концепции обеспечивает быстроту решения любых задач, в т.ч. сложных [2]. Если формализовать этот подход в виде функционального уравнения, которое определяет любой запрос в большой области данных, оно будет выглядеть так [3]:
Query = λ (Complete data) = λ (live streaming data) * λ (Stored data)
Это уравнение означает, что все связанные с данными запросы могут обрабатываться путем объединения результатов из исторического хранилища в форме пакетов и потоковой передачи в реальном времени с помощью скоростного уровня [3].
Где и как используется λ-подход в Big Data
Итак, лямбда-архитектура позволяет обрабатывать большие данные в режиме, близкому к реальному времени. При этом этот подход является отказоустойчивым и масштабируемым. Благодаря функциям пакетного и скоростного уровней можно добавлять новые данные в основное хранилище, обеспечивая при этом сохранность существующих данных. Поэтому лямбда-архитектура широко используется на практике, во многих Big Data проектах, в частности, Twitter, Netflix и Yahoo [3].
Обобщая кейсы применения λ-архитектуры, можно сказать, что она актуальна для тех корпоративных моделей обработки данных, где [3]:
Таким образом, лямбда-подход актуален не только для бизнес-приложений с пакетной и потоковой обработкой Big Data, но и для систем интернета вещей (Internet of Thing, IoT), в т.ч. промышленного (Industrial IoT, IIoT). Напомним, архитектура таких систем предполагает сбор малых данных со множества различных датчиков, их сохранение, агрегацию и облачную обработку в т.ч. с использованием алгоритмов Machine Learning.
С прикладной точки зрения интересно использование Apache Spark в построении λ-архитектуры, т.к. этот фреймворк позволяет обрабатывать большие данные как в пакетном, так и в потоковом режиме. Справедливости ради здесь стоит отметить, что Spark реализует не строго потоковую обработку данных, а микро-пакетный подход (micro-batch), однако, эти вычисления укладываются в концепцию near real-time. Кроме того, библиотека машинного обучение Spark MLLib включает расширенный набор современных алгоритмов Machine Learning. А средства Spark SQL дает возможность работать с данными с помощью привычных инструментов BI-аналитики: структурированных запросов реляционной логики.
Поэтому Apache Spark используется во множестве Big Data систем на базе лямбда-архитектуры, в частности, в Azure Cosmos DB – распределенной многомодельной базе данных, интегрированной с аналитической платформой HDInsight [4]:
Достоинства и недостатки архитектуры
Итак, лямбда-архитектура предоставляет следующие преимущества для Big Data системы [3]:
Однако, λ-подходу свойственны следующие недостатки [2]:
Впрочем, это частично данные недостатки компенсируются с помощью Apache Spark. Однако, для быстрой обработки событий в режиме реального времени без пакетного представления более целесообразен другой подход – Каппа-архитектура, о чем мы поговорим в следующей статье.
Больше практических подробностей про архитектуры больших данных и Apache Spark вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Русские Блоги
Проблемы с традиционными системами
—— Ма Юн, председатель совета директоров Alibaba.
Однако, когда число посещений пользователей продолжает увеличиваться, необходимо учитывать архитектуру технологии разделения чтения-записи (Master-Slave), как показано на следующем рисунке, технологию базы данных и таблицы. Теперь архитектура становится все более сложной, добавляя логику обработки, такую как очереди, разделы и репликация. Приложение должно понимать схему базы данных, чтобы получить доступ к правильным данным.
Это выглядит довольно хорошо, но это все еще традиционный пакетный метод со всеми известными недостатками, основная причина в том, что данные клиента, когда пакетная обработка занимает много времени для завершения предыдущей обработки данных, вводят новые данные Причиной устаревания данных.
Введение в лямбда-архитектуру
Потребность в недорогом масштабировании побудила людей начать использовать распределенные файловые системы, такие как HDFS и пакетные вычислительные системы (задания MapReduce). Но этой системе сложно добиться низкой задержки. Технология потоковой обработки в реальном времени, разработанная Storm, может помочь решить проблему задержки, но она не идеальна. Одна из причин заключается в том, что Storm не поддерживает семантику «точно один раз», поэтому он не может гарантировать точность данных о состоянии и не поддерживает обработку на основе событий. Пользователи с вышеуказанными требованиями должны добавить эти функции в свой код приложения. Позже появился гибридный метод анализа, который объединил две вышеупомянутые схемы, чтобы обеспечить как низкую задержку, так и корректность. Этот метод называется архитектурой Lambda и обеспечивает отложенные вычисления с пакетными заданиями MapReduce, но с точными результатами. В то же время результаты последних данных первоначально отображаются в Storm.
Ключевые особенности архитектуры Lambda
Марц считает, что системы больших данных должны иметь следующие ключевые характеристики:
Суть системы данных
Чтобы спроектировать систему, которая отвечает вышеупомянутым ключевым характеристикам больших данных, нам необходимо глубокое понимание системы данных. Мы можем упростить систему данных, чтобы:
Чтобы понять суть системы больших данных из двух аспектов данных и запросов.
Характеристики данных: когда и что
Хранение данных: храните все необработанно
Согласно приведенному выше анализу основных характеристик данных, способ хранения данных в архитектуре Lamba: данные являются неизменными, и все данные хранятся.
Храня все данные в неизменном виде, вы можете получить следующие преимущества:
В отрасли существует множество примеров использования моделей неизменяемых данных для хранения всех данных. Например, распределенная база данных Datomic, основанная на неизменяемой модели данных для хранения данных, таким образом, упрощает проектирование. Kafka, межплатформенное программное обеспечение для обмена сообщениями, хранит сообщения в режиме «только добавление» на основе журналов журнала.
Характер запроса
Какова концепция запроса? Marz дает запросу простое определение следующим образом:
Следствием этого уравнения является то, что запрос является функцией, применяемой к набору данных. Определение кажется простым, но оно охватывает почти все области баз данных и систем данных: СУБД, индекс, OLAP, OLTP, MapReduce, EFL, распределенная файловая система, NoSQL и т. Д. Могут быть выражены этим уравнением.
Давайте подробнее рассмотрим характеристики функции, чтобы проанализировать характеристики самой функции для выполнения запроса. Существует класс функций, называемых моноидальными функциями, которые широко используются. Понятие Monoid происходит от теории категорий, важной характеристикой которой является удовлетворение ассоциативного закона. Например, добавление целых чисел удовлетворяет характеристикам Monoid:
Функции, которые не удовлетворяют характеристикам Monoid, часто можно преобразовать в операции нескольких функций, которые удовлетворяют характеристикам Monoid. Например, функция Avg среднего значения нескольких чисел, несколько средних значений нельзя напрямую объединить для получения окончательного среднего значения, но ее можно разделить на знаменатель и числитель. Знаменатель и числитель являются целочисленными сложениями для соответствия характеристикам моноида.
Закон комбинирования Monoid чрезвычайно важен в распределенных вычислениях. Удовлетворение характеристики Monoid означает, что мы можем разложить вычисления на несколько машин для параллельной работы, а затем объединить результаты их соответствующих операций для получения окончательного результата. Это также означает, что часть результатов операции может храниться и совместно использоваться другими операциями (если операция также содержит те же частичные подоперации), тем самым уменьшая нагрузку на повторяющиеся операции.
Трехъярусная архитектура лямбды
Приведенное выше обсуждение природы систем данных, давайте обсудим ключевые проблемы систем больших данных: как выполнять запросы к любому большому набору данных в режиме реального времени? Большие данные в сочетании с расчетами в реальном времени усложняют задачу.
Архитектура Lambda решает эту проблему с помощью разложенной трехуровневой архитектуры: пакетного уровня, скоростного уровня и обслуживающего уровня.
Batch Layer
В идеале любой доступ к данным может начинаться с выражения Query = function (all data), но если данные достигают довольно большого уровня (например, PB) и должны поддерживать запрос в реальном времени, это будет стоить больших денег Ресурсы. Одним из решений является предварительно вычисленная функция запроса. Эта функция запроса предварительного вычисления в книге называется Batch View (A), поэтому, когда запрос должен быть выполнен, результат можно прочитать из Batch View. Такое предварительно вычисленное представление может быть проиндексировано, поэтому оно может поддерживать случайное чтение (B). Тогда система становится:
（A）batch view = function(all data)
（B）query = function(batch view)
В архитектуре Lambda часть, которая реализует (A) пакетное представление = функция (все данные), называется пакетным уровнем. Существует две основные функции Batch Layer:
Набор данных для хранения
В соответствии с вышеупомянутым обсуждением данных «Когда и что», Batch Layer использует неизменяемую модель для хранения всех данных. Поскольку объем данных относительно велик, можно использовать большие решения для хранения данных, такие как HDFS. Если вам нужно хранить данные в том порядке, в котором они были сгенерированы, вы можете рассмотреть решение для хранения базы данных временных рядов (TSDB), такое как InfluxDB.
Построить запрос View
Как упомянуто выше, в соответствии с уравнением Query = Function (All Data), выполнение функции запроса для всего набора данных для получения результата является слишком дорогим. Но если мы вычислим и сохраним результат функции запроса на наборе данных заранее, результат может быть возвращен непосредственно во время запроса (или результат может быть получен с помощью простой операции обработки) без необходимости повторного вычисления полного и трудоемкого вычисления. Здесь вы можете думать о пакетном слое как о процессе предварительной обработки данных. Мы называем результаты, предварительно рассчитанные и сохраненные для запроса, как View. Представление является основной концепцией архитектуры Lambda. Она оптимизирована для запросов. Результаты запроса могут быть быстро получены с помощью View.
Работа кажется простой, а вещество очень мощным. Любые человеческие или машинные ошибки могут быть исправлены путем исправления ошибок и последующего пересчета для получения правильных результатов.
Понимание зрения
Представление является концепцией, которая более актуальна для бизнеса. Создание представления должно начинаться с потребностей самого бизнеса. В общей системе запросов к базе данных соответствующая функция запроса постоянно меняется и не может быть исчерпывающей. Однако, если вы исходите из потребностей самого бизнеса, вы можете обнаружить, что запросы, требуемые бизнесом, часто ограничены. Важная задача, которую необходимо выполнить пакетному слою, состоит в том, чтобы исследовать различные запросы, которые могут потребоваться в соответствии с потребностями бизнеса, и определить соответствующие представления в наборе данных в соответствии с запросом.
Неизменяемая модель данных и представления пакетного слоя
Как показано на рисунке ниже, человек с идентификатором агента = 50023 имеет статус вызова в 10:00:06 и статус ожидания в 10:00:10. В традиционной схеме базы данных записи, расположенные непосредственно за ними, охватывают предыдущие записи, а в модели неизменных данных исходные данные не будут изменены, но записи истории будут изменены в форме вставки измененных записей.
Упомянутое выше представление является связанным видом, предварительно рассчитанным на приведенном выше рисунке, например:2016-06-21Количество всех агентов, которые подключились к сети в тот день, количество агентов, которые каждая горячая линия и компания отключили. В соответствии с потребностями бизнеса, результаты рассчитываются заранее. Этот процесс эквивалентен прикладному уровню традиционного моделирования хранилища данных.Прикладной уровень также является предварительно обработанным представлением в соответствии с бизнес-сценарием.
Speed Layer
Пакетный слой может очень хорошо обрабатывать автономные данные, но существует много данных сцены, которые непрерывно генерируются в реальном времени и требуют обработки запросов в реальном времени. Speed Layer используется для обработки добавочных данных в реальном времени.
Speed Layer и Batch Layer относительно похожи. Данные рассчитываются и генерируется представление в реальном времени. Основные различия:
Таким образом, Speed Layer является дополнением к пакетному слою в режиме реального времени. Слой скорости можно суммировать как:
（C）realtime view＝function(realtime view，new data)
Обратите внимание, что представления в реальном времени основаны на новых данных и существующих представлениях в реальном времени.
Лямбда-архитектура разделяет обработку данных на Batch Layer и Speed Layer, что имеет следующие преимущества:
Как упоминалось ранее, любой входящий запрос должен получить ответ путем объединения результатов из пакетного представления и представления в реальном времени, поэтому эти представления должны соответствовать характеристикам ассоциативности Monoid. Следует отметить, что представление в реальном времени является функцией предыдущего представления в реальном времени и нового приращения данных, поэтому можно использовать инкрементные алгоритмы. Пакетное представление является функцией всех данных, поэтому здесь следует использовать алгоритм пересчета.
Serving Layer
Обслуживающий уровень архитектуры Lambda используется для ответа на пользовательские запросы и объединения результирующих данных в пакетном просмотре и реальном времени в окончательный набор данных.
Это включает вопрос о том, как данные объединяются. Ранее мы обсуждали свойство Monoid функции запроса.Если функция запроса удовлетворяет свойству Monoid, то есть закону объединения, необходимо просто объединить результирующие наборы данных в Batch View и Realtime View. В противном случае вы можете преобразовать функцию запроса в несколько операций функции запроса, которые удовлетворяют свойству Monoid, и объединить наборы данных результатов в Batch View и Realtime View для каждой функции запроса, которая соответствует свойству Monoid, а затем вычислить окончательный результат. набор данных. Кроме того, данные результатов в Batch View и Realtime View могут быть объединены в соответствии с характеристиками самого бизнеса с использованием правил самого бизнеса.
Таким образом, обслуживающий уровень выражается следующим уравнением:
（D）query＝function(batch view, realtime view)
Выбор компонентов лямбда-архитектуры
Три уровня архитектуры Lambda обсуждались выше: пакетный уровень, скоростной уровень и обслуживающий уровень. Подводя итог, лямбда-архитектура состоит из следующих трех уравнений:
На рисунке ниже показан полный вид и процесс создания архитектуры Lambda.
После того, как поток данных поступает в систему, он отправляется на пакетный уровень и на скоростной уровень для обработки. Batch Layer хранит все наборы данных в автономном режиме в неизменяемой модели и непрерывно пересчитывает Batch Views, соответствующие запросу для всего набора данных. Speed Layer обрабатывает инкрементные потоки данных в реальном времени и постоянно обновляет представления реального времени, соответствующие запросам. Обслуживающий уровень отвечает на запрос пользователя и объединяет результирующий набор данных в пакетном режиме и режиме реального времени в окончательный набор данных.
Выбор компонентов
Еще одна версия реализации:
В соответствии с характеристиками пакетного уровня, Hadoop с хранилищем (HDFS) и вычислениями (MapReduce), очевидно, является первым выбором, и пакетное представление может быть hdfs самого Hadoop или хранилищем, подобным кусту, построенному на основе hdfs. Для обеспечения своевременности используется потоковая система в реальном времени, такая как потоковая передача с потоковой передачей или искрой, а представление скорости может существовать в HBase или других подобных базах данных Nosql. Уровень сервера предоставляет методы пользовательских запросов, использующих унифицированную входную заявку с открытым исходным кодом Impala от Facebook. Или самостоятельно реализуйте унифицированный запрос Hive и HBase. Это статья два года назад. В то время искра не была так популярна. Теперь кажется, что искра может быть использована непосредственно в качестве заменителя для периодических и скоростных слоев.
Принцип выбора
подводить итоги
В прошлом архитектура данных Lambda стала незаменимой архитектурой для платформы больших данных каждой компании, которая решала потребности пакетной обработки больших данных в автономном режиме и обработки данных в реальном времени. Типичная лямбда-архитектура выглядит следующим образом:
Данные начинаются с базового источника данных, поступают на платформу больших данных в различных форматах и собираются компонентами данных, такими как Kafka и Flume на платформе больших данных, а затем разделяются на две строки для расчета. Одна строка вводит потоковую вычислительную платформу (такую как Storm, Flink или Spark Streaming) для вычисления некоторых индикаторов в реальном времени, другая строка вводит платформу для автономной обработки пакетной обработки данных (такую как Mapreduce, Hive, Spark SQL) для вычисления T + 1 Связанные бизнес-показатели, эти показатели нужно видеть через день.
Лямбда-архитектура имеет многолетний опыт разработки, и ее преимущество заключается в стабильности. Стоимость вычислений вычислительной части в реальном времени является управляемой. Пакетная обработка может использовать ночное время для пакетных вычислений в целом. Это отделяет вычисления в реальном времени от пиков автономных вычислений. Эта архитектура поддерживает данные. Раннее развитие отрасли, но она также имеет некоторые фатальные недостатки, и в эпоху больших данных 3.0 она все больше не подходит для нужд бизнеса по анализу данных. Недостатки заключаются в следующем:
Проблема с калибром данных, вызванная несоответствием между результатами расчетов в реальном времени и партиями: Поскольку для пакетных вычислений и вычислений в режиме реального времени используются две структуры вычислений и программы вычислений, результаты вычислений часто отличаются. Часто число рассматривается как данные за день, но данные за вчерашний день изменились на следующий день.
Пакетный расчет не может быть завершен в окне расчета: В эпоху IOT объем данных становится все больше и больше, часто обнаруживается, что существует только 4 или 5 часовое временное окно ночью, и больше невозможно завершить накопленные данные в течение более 20 часов в течение дня. Головная боль для команды данных.
Сложность разработки и сопровожденияАрхитектура Lambda требует, чтобы одна и та же бизнес-логика программировалась дважды в двух разных API (интерфейс прикладного программирования): один раз для системы ETL для пакетных вычислений и один раз для потоковой системы для потоковых вычислений. Для одной и той же бизнес-задачи были созданы две базы кода, каждая с различными уязвимостями. Такая система на самом деле очень сложно поддерживать
Большое серверное хранилищеТипичный дизайн хранилища данных будет генерировать большое количество промежуточных таблиц результатов, вызывая быстрое расширение данных и увеличивая нагрузку на серверное хранилище.
То есть из-за вышеуказанных ограничений архитектуры Lambda появилась Kappa, более гибкая и оптимизированная, чем архитектура Lambda, которая будет представлена в другой статье.