Архитектуры обработки больших данных
В этом модуле мы рассмотрели основные идеи, лежащие в основе механизмов распределенного программирования и аналитики, а также трудности крупномасштабной обработки больших данных. Мы рассмотрели несколько платформ, включая MapReduce, Spark и GraphLab, а также платформы потоковой обработки. В завершение обсудим некоторые предпринимаемые попытки определить архитектурную парадигму для создания систем, которые смогут обрабатывать как текущие, так и исторические данные: лямбда- и каппа-архитектуры.
Например, цифровые помощники, такие как Кортана от Майкрософт, часто используют сложные алгоритмы машинного обучения для распознавания речи и понимания запросов пользователей. Входящие запросы пользователей можно рассматривать как поток, требующий ответов с низкой задержкой. При этом со временем исторические данные запросов пользователей могут пригодиться для переобучения системы машинного обучения, чтобы улучшить распознавание речи и понимание запросов. Для обновления моделей машинного обучения под дальнейшие запросы можно использовать определенную систему потоковой обработки.
Лямбда-архитектура
Лямбда-архитектура — это архитектура обработки данных, предназначенная для обработки больших объемов данных c применением методов и пакетной, и потоковой обработки. Лямбда-архитектура пытается найти баланс между задержкой, пропускной способностью и отказоустойчивостью, используя пакетную обработку для того, чтобы обеспечить полные и точные представления пакетных данных, а потоковую обработку в режиме реального времени — чтобы обеспечить представления данных в сети.
Лямбда-архитектура описывает систему, состоящую из трех слоев: пакетного слоя, слоя скоростной обработки (или обработки в режиме реального времени) и служебного слоя для ответа на запросы.
Рис. 16. Система потоковой обработки должна обрабатывать данные в потоке с отдельным конвейером для хранилища на случай необходимости, расположенным не на "критическом пути".
Поток данных в лямбда-архитектуре показан на рисунке. Для этого необходимо выполнить следующие шаги:
- Все поступающие в систему данные отправляются на обработку в пакетный и скоростной слои.
- Пакетный слой управляет основным набором данных и выполняет предварительный расчет пакетных представлений.
- Служебный слой индексирует пакетные представления, чтобы периодически отправлять им запросы с низкой задержкой.
- Скоростной слой создает представления входящих данных в режиме реального времени намного быстрее, чем пакетный и служебный слои, но не всегда с той же точностью.
- Любой входящий запрос может быть выполнен за счет объединения данных их пакетных представлений и представлений в режиме реального времени.
Пакетный слой
Пакетный слой выполняет в лямбда-архитектуре важные функции.
- Во-первых, пакетный слой, как правило, управляет основным набором данных. Основной набор данных служит в лямбда-архитектуре источником достоверных сведений и может использоваться для воссоздания любых обслуживаемых системой данных в случае отказа сбоев в любом из слоев системы. Данные в пакетном слое обычно собираются в журнал, в который новые данные добавляются по мере поступления в систему, но вносить в них изменения нельзя.
- Во-вторых, пакетный слой формирует пакетные представления данных. Пакетный слой стремится к для идеальной или почти идеальной точности, имея возможность обрабатывать все доступные данные при создании пакетных представлений. Это означает, что он может устранять любые ошибки, пересчитывая весь набор данных заново, а затем обновляя существующие пакетные представления. Выходные данные из пакетного слоя сохраняются в служебный слой.
Большинство архитектур с высокой пропускной способностью обычно используют в качестве системы пакетной обработки Apache Hadoop. Эту же платформу, как правило, выбирают для реализации пакетного слоя. Обработка может выполняться с применением MapReduce или любой из систем пакетной обработки более высокого уровня, созданной на основе Hadoop.
Служебный слой
Выходные данные пакетных слоев (пакетные представления) сохраняются в служебный слой и становятся доступны для запросов от приложений. Они тесно привязаны к пакетному слою. Для обеспечения масштабируемости служебный слой обычно распределяется между множеством компьютеров. Как правило, служебный слой представляет собой какую-либо базу данных, обычно NoSQL. Требования к служебному слою:
- Пакетная запись: пакетные представления для слоя обслуживания создаются с нуля. Как только становится доступной новая версия представления, она должна полностью заменять более старую версию в обновленном представлении. В связи с этим системы служебного слоя не требуется оптимизировать для быстрых произвольных записей в отличие от традиционных систем баз данных.
- Масштабируемая: база данных уровня обслуживания должна быть способна обрабатывать представления произвольного размера. Как и в случае с распределенными файловыми системами и платформой пакетных вычислений, которую мы обсуждали ранее, она должна быть распределена между несколькими компьютерами.
- Случайные операции чтения: база данных уровня обслуживания должна поддерживать случайные операции чтения, с индексами, обеспечивающими прямой доступ к небольшим частям представления. Это нужно для того, чтобы запросы выполнялись с низкой задержкой.
- Отказоустойчивость. Так как база данных уровня обслуживания распределена, она должна быть терпимой к сбоям компьютера.
Как правило, для хранения данных в служебном слое используются хранилища Apache Hive, HBase и Impala.
Скоростной слой
Скоростной слой обрабатывает потоки данных в режиме реального времени с минимальной возможной задержкой, что позволяет получать представления данных в режиме реального времени. По сути, скоростной слой отвечает за заполнение "пробела", который возникает, пока пакетный слой создает предоставления на основе самых актуальных данных.
Представления этого слоя могут быть не такими точными или полными, как те, что со временем выдаст пакетный слой, зато доступны практически сразу после получения данных и могут заменяться представлениями пакетного слоя для тех же самых данных, как только они станут доступны. Методы инкрементной или потоковой обработки, которые мы обсуждали ранее в этом модуле, позволяют эффективнее выполнять обработку в случаях, когда вычисления можно выразить функцией от предыдущего представления в режиме реального времени и последних данных и получить, таким образом, обновленные представления в режиме реального времени.
Рис. 17. Система потоковой обработки должна обрабатывать данные в потоке с отдельным конвейером для хранилища на случай необходимости, расположенным не на "критическом пути".
Обычно в этом слое используются такие технологии пакетной обработки, как Apache Samza, Apache Storm, SQLstream и Apache Spark. Выходные данные обычно хранятся в базах данных типа NoSQL, что позволяет выполнять запросы с низкой задержкой.
Каппа-архитектура
Рис. 18. Система потоковой обработки должна обрабатывать данные в потоке с отдельным конвейером для хранилища на случай необходимости, расположенным не на "критическом пути".
Каппа-архитектура, популяризируемая компанией LinkedIn, показана на рисунке. Одной из важных целей каппа-архитектуры было избегание необходимости обслуживать две отдельные базы кодов для пакетного и скоростного слоев. Основная идея в том, чтобы выполнять и обработку данных в режиме реального времени, и непрерывную повторную обработку данных, используя один и тот же механизм потоковой обработки.
Повторная обработка данных необходима для того, чтобы изменения в коде отражались в результатах. В связи с этим каппа-архитектура состоит всего из двух слоев: слоя потоковой обработки и служебного слоя.
Слой потоковой обработки выполняет задания потоковой обработки. Обычно для обработки данных в режиме реального времени выполняется одно единственное задание потоковой обработки. Повторная обработка данных выполняется только в том случае, если нужно изменить часть кода задания потоковой обработки. Для этого запускается другое, измененное, задание потоковой обработки и воспроизводятся все предыдущие данные. Служебный слой, как и в лямбда-архитектуре, используется для запроса результатов.
Лямбда-архитектура vs. Каппа — это продолжающаяся дискуссия в сообществе для обработки больших данных. Выбор архитектуры зависит от некоторых характеристик реализуемого приложения. Ericsson предлагает следующий простой подход.
- Если для исторических данных и данных в режиме реального времени используются одинаковые алгоритмы, лучше всего выбрать каппа-архитектуру. Для начальной загрузки представлений может требоваться определенная форма пакетного вычисления — это зависит от объема имеющихся исторических данных и частоты поступления новых данных.
- В некоторых типах приложений, таких как приложения машинного обучения, выходные данные систем пакетной обработки и систем реального времени имеют разную точность из-за разного объема данных, с которыми производятся вычисления. Это затрудняет объединение результатов пакетной обработки и обработки в режиме реального времени в согласованное представление, а значит, для таких приложений лучше подходит лямбда-архитектура.
- В некоторых случаях алгоритм пакетной обработки можно оптимизировать, поскольку он имеет доступ к полному набору исторических данных и, таким образом, может превзойти алгоритм обработки в режиме реального времени по эффективности (с точки зрения скорости обработки). В этом случае выбор между лямбда- и каппа-архитектурами зависит от того, что важнее — эффективность пакетной обработки или простота базы кодов.