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

Этот материал будет полезен проектам, которые:

Выстраивают глубинную сквозную аналитику;
Рассматривают возможность интеграции аналитических решений;
Выстраивают аналитическую инфраструктуру инхаус.

Чем поделимся?

Новая архитектура и переезд на apache Kafka. Почему мы пошли в разработку новой архитектуры сервиса, и как это влияет на развитие наших решений;
Сравним прошлую и новую версии сервисов;
Система мониторинга и алертинга инцидентов. Как мы выстроили систему уведомлений и быстрого реагирования на них, и почему на это важно обращать внимание при выборе стриминга;
Как мы работаем с кейсами потери данных.

Про DataGo!

Команда DataGo! (ex. OWOX в РФ) предоставляет прозрачные и удобные инструменты для построения маркетингового DWH.

Наша платформа помогает аналитикам получать качественные данные, а маркетологам — строить прикладную отчетность.

Как мы обеспечиваем надежность маркетинговых и продуктовых данных?

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

Что такое надежные данные?

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

С чего все началось? Предпосылки

В портфеле DataGo! более 80 крупных клиентов из e-com, retail, finance и других сегментов. Это создает высокую нагрузку на нашу внутреннюю инфраструктуру: почти на каждом клиентском проекте используется мобильное приложение и сайт, на которые поступает трафик из нескольких источников (таргетированная и контекстная реклама, СРА-площадки, баннерная и медийная реклама и др.)

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

С целью защиты данных текущих клиентов и обеспечения качественного сервиса при подключении новых проектов, мы приняли решение о переезде на новую архитектуру аналитического проекта apache Kafka.

Как было? Старая архитектура

Компания DataGo! была основана в 2022 году. Создание DataGo! стало ответной реакцией на уход зарубежных аналитических инструментов из РФ: многие проекты вынужденно мигрировали на альтернативный аналитический стек, спасая свои данные от высокого риска безвозвратной потери.

Устройство старого стриминга:

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

Почему была реализована такая архитектура?

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

Сложности поддержки старой архитектуры:

Масштабирование. Каждая новая ВМ стриминга увеличивала нагрузку на ClickHouse - формировались мелкие батчи, приводящие к высокому rps;
Релиз. Обновление требовало разворачивать новую версию сервиса на всех машинах, вне зависимости от масштаба изменений;
Надежность. Любая ошибка в процессе обработки запроса могла привести к его потере, что создавало риск потери данных.

Эти ограничения потребовали радикального пересмотра подходов к обработке входящего потока

Переход на новую архитектуру

Устройство нового стриминга

Архитектура проекта была разбита на несколько микросервисов, выстроенных в единую цепочку, где каждое звено выполняет небольшую часть работы:

Прием входящих запросов и их сохранение в очередь на обработку;
Разбор хитов и извлечение значений из параметров;
Обогащение данных;
Трансформация в конечную структуру;
Загрузка в БД.

Изолированные процессы:

Повышение стабильности системы;
Возможность внесения правок в отдельные компоненты системы;
Упрощение локализации ошибок при обработке потока данных.

Переход на новую архитектуру обеспечил DataGo! решение сразу нескольких кейсов:

Все данные сохраняются в “сыром” виде. Стриминг это не изолированный процесс, на результат напрямую влияет полнота и корректность входящих запросов. Наличие “сырых” данных помогает определять причины и источник ошибок при их возникновении, а также значительно ускоряет процесс их исправления;
Исключена обработка данных до их сохранения. Это практически исключает вероятность того, что данные от клиента не дойдут или не сохранятся из-за программных ошибок;
Подключено резервное хранилище S3 при сохранении входящего потока. Получение и обработка входящих запросов наиболее критичный слой сервиса, для повышения стабильности этого процесса, помимо достаточно стабильной Kafka, используется в качестве резерва S3 от YC. Хранилище данных S3 имеет динамически расширяемый условно безграничный ресурс, репликацию и высокую пропускную способность сети, что решает потенциальные сложности с “перегрузкой” Кафки или ее недоступностью по различным причинами

Важно отметить!

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

Система мониторинга и алертинга инцидентов

В случае возникновения сложностей с [некорректной] доставкой данных до клиента, мы оперативно реагируем для выяснения причины возникшей ситуации и стараемся ее исправить. Например, сложности могут возникнуть из-за увеличения нагрузки на сервис, из-за проблем у хостинг провайдера и пр.

Для чего мы используем мониторинг инцидентов?

Обнаружение проблем. Мониторинг позволяет быстро выявить проблему и уведомить команду о необходимости вмешаться в процесс, минимизируя риски потери данных;
Оптимизация производительности. С помощью мониторинга инцидентов можно анализировать производительность систем и находить bottle necks: нагрузка процессоров, использование памяти и других параметров;
Прогнозирование. Мониторинг текущего состояния позволяет собирать данные для прогнозирования будущих нагрузок и планирования ресурсов;
SLA. Мониторинг позволяет контролировать выполнение соглашений об уровне обслуживания и обеспечивать соответствие требованиям.

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

Как мы замечаем, что с данными происходят аномалии?

Мониторинг. Сформированные внутренние процессы позволяют отслеживать объем хитов и трафика по каждому клиенту. В текущей версии валидация расхождений происходит в полуавтоматическом режиме.
Настроили автоматический алертинг, позволяющий отслеживать стабильность работы всех ВМ, находящихся в архитектуре проекта. Алертинг настроен на список метрик, отражающих стабильность системы (базовые показатели ВМ: CPU, Memory usage, Free disk size, Network), а также метрики, учитывающие специфику продукта (RPS и его динамику, коды ответов, скорость обработки запросов и др.)
Данные не остаются без присмотра: ответственные дежурные следят за работой всего процесса и, в случае необходимости, исправляют возникающие инциденты.

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

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

Переход на новую архитектуру проекта: как это влияет на надежность стриминга web-данных