CC BY
9
УДК 004.031
Матвеева П.Р. бакалавр 4 курса
факультет «Информатика и системы управления» научный руководитель: Ревунков Г.И., к.техн.н.
доцент
кафедра «Системы обработки информации и управления» Московский государственный технический университет им. Н.Э. Баумана Россия, г. Москва СРАВНЕНИЕ ЛЯМБДА И ТРАДИЦИОННОЙ АРХИТЕКТУР Аннотация. Современный мир полностью базируется на информации. Как правило, любая информация нуждается в обработке, для чего создаются различные системы, построенные на базе определенных архитектур. В данной статье рассмотрены основные используемые архитектуры: лямбда и инкрементная, а также их основные концепции; проведен сравнительный анализ целесообразности и функциональности использования данных архитектур.
Ключевые слова: большие данные, обработка информации, архитектура системы, лямбда архитектура, инкрементная архитектура.
Matveeva P.R. bachelor
4 year faculty «Informatics and control systems» Bauman Moscow State Technical University
Russia, Moscow
Scientific adviser: Revukov G.I., candidate of technical sciences, associate professor of the department "Information processing and management systems"
Bauman Moscow State Technical University
Russia, Moscow THE COMPARISON OF LAMBDA AND TRADITIONAL ARCHITECTURES Abstract. The modern world is based on information. As a rule, any information needs to be processed, for which different systems based on certain architectures are built. In this article, the following architectures are considered: lambda and incremental, as well as their basic concepts; a comparative analysis of advisability and functionality of using these architectures is made.
Key words: big data, information processing, system architecture, lambda architecture, incremental architecture.
В век развития информационных технологий каждую секунду порождаются гигабайты информации, и темп генерации данных непрерывно растет. [2] Мир уже невозможно представить без больших данных - они присутствуют во всех сферах современной жизни: от социальных сетей до
веб-аналитики. Для работы с ними все чаще разработчики отказываются от реляционных баз данных в пользу NoSQL баз данных. Изменяя архитектуру систем, они пытаются добиться того, чтобы новая архитектура была не только масштабируемой, толерантной к отказу машины и легко рассуждала, но и толерантна к ошибкам человека.
Конечно, реляционная база данных может быть усовершенствована при помощи очередей, горизонтального масштабирования - деления на шарды, репликации или повторных скриптов. Однако рано или поздно система может стать масштабной настолько, что дальнейшее ее расширение с применением этих методов приведет к багам и, как следствие, потере и искажению информации. Проблема в том, что система «не осознает» свой распределенный характер, поэтому вся ответственность за обработку и распределение данных лежит на разработчике. Такая архитектура является неустойчивой к человеческому фактору, а растущий объем информации, большие данные увеличивают сложность работы с приложением.
Многие из систем для работы с большими данными были впервые внедрены Google, включая распределенные файловые системы, платформу вычислений MapReduce и распределенные услуги блокировки. Другой заметной компанией был Amazon, который создал инновационный распределенное хранилище ключ-значение под названием Dynamo. Инновационными проектами в этой области также стали: Hadoop, HBase, MongoDB, Cassandra, RabbitMQ.
В действительности подобные решения зачастую оказываются намного более простыми и эффективными для работы с данными, чем традиционные реляционные системы управления базами данных. Таким альтернативным подходом стала новая парадигма для больших данных -Лямба архитектура. Использование технологий больших данных позволяет снять с разработчика ответственность за горизонтальное масштабирование и репликацию. Логика деления на шарды интернализируется в самой базе данных: то есть при добавлении новых узлов система автоматически перераспределяет нагрузку. Кроме того, система хранит необработанные данные, что позволяет не потерять информацию в случае ошибки. Поэтому лямбда архитектура позволяет создавать масштабируемые системы для произвольных проблем данных с отказоустойчивостью в плане человеческой ошибки и минимальной сложностью.
В основе концепции лямбда архитектуры лежат базовые принципы любой системы данных. Прежде всего, это то, что любая система представима в виде уравнения:
query = function (all data)
т.е. все, что необходимо извлечь из системы может быть представлено как функция от всех имеющихся данных. лямбда архитектура обеспечивает универсальный подход к реализации произвольной функции на произвольном наборе данных, и эта функция возвращает результат с низкой задержкой. Кроме того, она позволяет обеспечить такие свойства как
робастность и отказоустойчивость, возможность чтения и обновления данных с низкой задержкой, масштабируемость, применение для широкого диапазона приложений в различных сферах, возможность расширения функционала и выполнение специализированных запросов. Важно отметить минимизацию технического обслуживания в системах с такой архитектурой, а также отладки - для каждого значения в системе имеется возможность отследить, что именно заставило его иметь такое значение.
Рассмотрим подробнее концепции архитектур и возможные проблемы, которые могут возникнуть при работе с ними. В традиционных системах, как правило, взаимодействуют 2 субъекта: приложение и база данных (рис. 1) [4]. Такие системы полностью инкрементны и наиболее распространены в настоящее время.
Рис. 1. Взаимодействие в полностью инкрементной системе.
Эту архитектуру характеризует использование баз данных для чтения/записи и постоянное сохранение значений в этих базах по мере появления новых данных. Основной проблемой является сложность функционирования, связанная с необходимостью уплотнения. Этот процесс необходим, когда при инкрементном обновлении часть индексов становится неиспользуемой, но хранится в памяти. Неиспользуемые части должны быть восстановлены во избежание переполнения диска. Возвращение пространства, как только оно становится неиспользуемым, достаточно дорого, поэтому это пространство регенерируется в процессе уплотнения. Этот процесс также достаточно затратный в плане нагрузки на сервер, поэтому во время его протекания снижается производительность компьютера. Потери производительности во время компиляции - проблема, которая может вызвать каскадный сбой: если слишком много машин одновременно сжимают данные, то нагрузку, которую они поддерживают, придется обрабатывать другими машинами в кластере. Это может привести к перегрузке остальной части кластера, что приведет к полному сбою. Поэтому такие операции должны быть тщательно распланированы и распределены между узлами. Работа с онлайн-уплотнением - сложность, присущая полностью инкрементным архитектурам, но в лямбда архитектуре первичные базы данных не требуют никакого онлайн-уплотнения.
Другой проблемой систем с инкрементной архитектурой является недостаток высокодоступности - т.е. способности получать запросы и обновления даже в случае отказа машины или части сети. Это свойство обратно пропорционально согласованности при репликации - согласованная система возвращает результаты, учитывающие предыдущие записи. Таким образом, высокодоступная система может возвращать некорректные результаты. Во избежание ошибок необходимо предусмотреть алгоритм, учитывающий значения всех копий при слиянии и восстанавливающий
значение после завершения слияния. Эта сложность является врожденной для полностью инкрементных систем. Лямбда архитектура структурирована по-другому и нацелена на достижение высокодоступных и согласованных систем.
Необходимо также отметить недостаток отказоустойчивости к человеческому фактору в архитектурах с полной инкрементацией. Поскольку такие системы постоянно изменяют значения, хранимые в базе данных, эти изменения могут также быть вызваны и ошибкой. В этом случае неизбежно повреждение достоверной базы данных. Однако эта проблема решается путем внедрения хранилища событий: сохраняя каждое событие, если ошибка человека вызывает повреждение базы данных, есть возможность вернуться в хранилище событий и восстановить правильное состояние для базы данных.
Помимо всего прочего, решение одной и той же задачи системой с полной инкрементацией потребует выполнение большего количества запросов, чем в системе с лямбда архитектурой. А поскольку выполнение каждого запроса более затратно в полностью инкрементной архитектуре и применяемая в обоих случаях аппроксимация использует более низкое приближение, то показатели оценки выполнения задачи: точность, латентность и пропускная способность - будут выше в системе с лямбда архитектурой. Также полностью инкрементная система потребует применения специального оборудования, в котором нет необходимости при использовании лямбда архитектуры.
Основная идея лямбда архитектуры заключается в том, чтобы строить системы больших данных как ряд слоев [1], как показано на рисунке 2. Каждый слой удовлетворяет подмножеству свойств и основывается на функционале, предоставляемом лежащими ниже.
Speed layer
Servia^ layer
Batch layer
Рис. 2 Слои лямбда архитектуры.
Отличительной чертой данной архитектуры является наличие предварительной функции запроса, называемой пакетным представлением. То есть, при выполнении запроса сначала вычисляется это представление, а затем из него читаются конечные результаты. Таким образом, в этой системе сначала запускается функция для всех данных, чтобы получить пакетное представление. Затем, когда необходимо узнать значение для запроса,
запускается функция в этом пакетном представлении. Пакетное представление позволяет быстро получать нужные значения без необходимости сканировать все в нем.
Эта часть лямбда архитектуры носит название уровня пакетной обработки. На уровне пакетной обработки хранится основная копия набора данных и предварительно вычисляется пакетное представление этого базового набора данных. Основной набор данных можно рассматривать как очень большой список записей. Уровень пакетной обработки должен иметь возможность: хранить неизменный, постоянно растущий набор основных данных и вычислять произвольные функции в этом наборе данных. Этот тип обработки лучше всего реализуется в системах с пакетной обработкой.
Уровень пакетной обработки достаточно прост в использовании. Он реализован в виде однопоточных программ, что позволяет реализовать параллельные вычисления.
Функции пакетного слоя должны быть вызваны. Этим занимается уровень обслуживания. Он представляет собой специализированную распределенную базу данных, которая загружается в пакетном режиме и позволяет произвольно считывать информацию. Когда становятся доступными новые виды пакетных представлений, обслуживающий уровень автоматически меняет их для получения актуальных результатов.
Эти два уровня обеспечивают почти все перечисленные ранее свойства. Робастность и отказоустойчивость реализуется за счет того, что при отказе серверов уровень обслуживания использует репликацию, чтобы обеспечить доступ. Уровень пакетной обработки и уровень обслуживания также обеспечивают устойчивость к человеческим ошибками, поскольку всегда можно исправить алгоритм или удалить некорректные данные и перекомпилировать представления с нуля. Масштабирование обоих уровней возможно путем добавления дополнительных машин. Применение архитектуры в различных сферах для различного спектра приложений обусловлено возможностью компиляции произвольных представлений для произвольных наборов данных. Расширяемость функционала может быть реализована путем добавления представления как функции, а также нового типа данных. Специальные запросы реализуются при помощи уровня пакетной обработки при поддержке вложенных запросов. Простая организация работы уровней позволяет минимизировать обслуживание работы системы. Возможность отладки поддерживается уровнем пакетной обработки, поскольку легко отследить входные и выходные данные. Низкая задержка обновлений обеспечивается при помощи уровня ускорения.
Уровень обслуживания обновляется всякий раз, когда уровень пакетной обработки заканчивает предварительное вычисление пакетного представления. Это означает, что единственными данными, не представленными в пакетном представлении, являются данные, которые появились во время выполнения предвычисления. Поэтому необходимо компенсировать эти данные, что является основной задачей уровня
ускорения. Он похож на уровень пакетной обработки, однако просматривает только последние данные и обновляет представления в режиме реального времени, получая новые данные, вместо того, чтобы пересчитывать представления с нуля, как это делает уровень пакетной обработки. Такой подход позволяет лишний раз не обрабатывать все данные, что существенно экономит время и ресурсы. [3]
В результате вместо того, чтобы просто выполнять запросы с использованием функции пакетного представления, рассматриваются как пакетное, так и представление в реальном времени, а результаты объединяются. Преимуществом является то, что данные, обработанные на уровне пакетной обработки отбрасываются и уже не используются на уровне ускорения, что повышает производительность. Это свойство называется изоляцией сложностей. Разделение уровня пакетной обработки и уровня ускорения дает гибкость в использовании точного алгоритма на уровне пакетной обработки и алгоритма аппроксимации на уровне ускорения. Уровень пакетной обработки многократно переопределяет уровень ускорения, поэтому аппроксимация корректируется. Система, которая выполняет точные вычисления на уровне пакетной обработки и приблизительные вычисления на уровне ускорения, является в итоге высокоточной, поскольку уровень пакетной обработки корректирует вычисления уровня ускорения.
Итак, лямбда архитектура и её основные концепции широко применяются в настоящее время. На данном этапе развития техники компьютеры не становятся намного более производительными. Это означает, что для ускорения обработки данных необходимо организовать параллельные вычисления, что возможно при помощи, например, набора MapReduce (основной функционал уровня пакетной обработки). Также широко используются облака (Amazon Web Services), позволяющие арендовать оборудование по требованию: мгновенно увеличивать или уменьшать размер кластера. Они значительно упрощают администрирование системы и предоставляют дополнительные варианты распределения памяти и оборудования, которые могут значительно снизить стоимость вашей инфраструктуры.
Для работы с большими данными используются также пакетные вычислительные системы (Hadoop). Они представляют собой высокопроизводительные системы с высокой задержкой. Такие системы могут выполнять почти произвольные вычисления, но для этого могут потребоваться часы или дни. Помимо этого, применяются базы данных NoSQL с произвольным доступом - за последние несколько лет таких баз было создано множество: Cassandra, HBase, MongoDB, Voldemort, Riak, CouchDB и другие. Такие базы данных специализируются на определенных видах операций и предназначены для использования в определенных целях. Также используются системы расчета в реальном времени. Они обеспечивают высокую пропускную способность и низкую латентность, а
также очень быструю обработку сообщений.
Итак, работа с традиционными системами становится более проблематичной по мере их роста: они становятся более сложными для понимания, трудными для дальнейшего масштабирования и управления. Преимущества систем, построенных на основе принципов лямбда архитектуры, не ограничиваются лишь простотой масштабирования: поскольку системы могут обрабатывать больший объем данных большего количества типов, появляется возможность создать новые методы обработки, анализа и, как следствие, более широкий спектр приложений. При чем еще одним преимуществом является то, что эти приложения будут робастны в сравнении со своими аналогами, построенными на базе традиционной архитектуры. Кроме того, поведение таких систем достаточно предсказуемо и объяснимо, несмотря на их гибкость.
Использованные источники:
1. Лямбда-архитектура: новый подход к анализу данных. [Электронный ресурс] Режим доступа: http://datareview. info/article/lyambda-arhitektura-novyiy-podhod-k-analizu-dannyih/
2. Кудрявцева Е., Журенков К. Лавина данных. // ОГОНЕК, № 42, 2016 г, с. 4 - 5.
3. Строим надёжный процессинг данных — лямбда архитектура внутри Google BigQuery. [Электронный ресурс] Режим доступа: http://www.pvsm.ru/data-mining/115324
4. Nathan Marz, James Warren - Big Data: Principles and best practices of scalable realtime data systems. Manning Publications, 2015. C. 3-23.
