Информации и данных в современном мире с каждой секундой становится все больше, но как работать с поступающей информацией? Способов много, и в этой статье мы рассмотрим один из них. Чтобы подготовить почву, мы начнем с изучения потенциальных проблем, с которыми может столкнуться процесс масштабирования системы.
Представьте ситуацию, у нас есть огромный поток данных, и пользователи хотят видеть информацию в режиме реального времени. Нам нужно время для возможной постобработки, используем Машинное обучение для обогащения и фильтрации данных, а пользователь не всегда готов ждать этого времени.
Соответственно, нам может помочь такой паттерн, как Lambda Architecture, описанный в книге Озеро данных для предприятий.
Основная суть этого подхода в том, что вместо одного слоя обработки данных мы делим этот слой на два независимых: Скоростной слой и Пакетный слой. Уровень скорости производит предварительную обработку данных без каких-либо дополнительных вычислений, а уровень пакетной обработки параллельно производит фильтрацию и обновление информации для конечного пользователя. Таким образом, Пакетный слой — это своего рода место истины, потому что он может заменить предварительную обработку данных, ранее сделанную Скоростным слоем.
Модульный подход можно представить в виде нескольких абстракций:
- Уровень приема — это первый уровень обработки данных, отвечающий за преобразование и пересылку на уровень Lambda.
- Уровень скорости —поддерживает быстрый поиск и быструю запись в режиме реального времени.
- Пакетный уровень —последовательное чтение и запись данных, а также обработка, моделирование и вычисления на основе необработанных данных с возможностью построения сложных запросов и дополнительной фильтрации.
- Уровень обслуживания — сбор и агрегация данных в зависимости от условия запроса. Этот уровень должен решить, следует ли брать данные из Пакетного слоя или Скоростного слоя.
В ходе исследования у меня возникло недопонимание с представленным стеком для реализации. Было описано, как реализовать поток данных на стеке Apache, но после дальнейших исследований стало ясно, что я умею использовать любые известные методы хранения. Следовательно, для Speed Layer я взял Redis, а для Batch Layer — ClickHouse.
После первоначального анализа диаграммы возникают следующие вопросы:
- Нужно ли дублировать логику вычислений на обоих слоях обработки событий? К сожалению, да, также мы столкнемся с проблемой языковых переводов.
- Как уровень обслуживанияопределитьгде получить информацию для конечного пользователя? В случае получения агрегатов, не требующих сложных аналитических вычислений, мы можем использовать уровень скорости, в противном случае нам нужен уровень пакетной обработки с Поддержка диалекта SQL.
Наличие двух слоев для обработки данных увеличивает вероятность ошибки, потому что код пишут люди. Пакетный уровень должен иметь возможность перезаписывать данные, которые были рассчитаны ранее на скоростном уровне. Поскольку Batch Layer имеет достаточную глубину данных, есть безграничные возможности для пересчета/добавления новых метрик.
Подводя итог, опишу основные критерии, которые, на мой взгляд, должны быть обязательными при реализации:
- Уровень скорости —логика должна быть максимально простой.
- Уровень скорости — должен быть готов к тому, что данные будут перезаписаны уровнем пакетной обработки.
- Пакетный уровень —должен поддерживать сложные запросы и диалект SQL.
Следует ли использовать этот подход при проектировании системы? Я думаю, что это слишком дорого для реализации и есть дополнительные точки отказа, которые не маловажны, но с другой стороны, пользователь получает актуальные данные в режиме реального времени. Подход актуален, если просмотр данных в режиме реального времени является ключевым фактором.
Ниже я прикрепил докеризованную и упрощенную реализацию Node JS. У вас есть опыт работы с этим шаблоном?
