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

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

• Создавайте глубокую сквозную аналитику;

• Рассмотреть возможность интеграции аналитических решений;

• Создайте внутреннюю аналитическую инфраструктуру.

Чем мы должны поделиться?

1. Новая архитектура и переход на Apache Kafka. Почему мы начали разработку новой архитектуры сервиса и как это влияет на развитие наших решений?

2. Сравним предыдущую и новую версии сервисов;

3. Система мониторинга и оповещения об инцидентах. Как мы построили систему уведомлений и быстрого реагирования и почему на это важно обращать внимание при выборе стриминга;

4. Как мы работаем со случаями потери данных.

О DataGo!

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

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

Как гарантировать достоверность маркетинговых и товарных данных?

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

Что такое достоверные данные?

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

С чего все началось? Предварительные условия

В портфолио DataGo! более 80 крупных клиентов в электронной коммерции, розничной торговле, финансах и других сегментах. Это создает высокую нагрузку на нашу внутреннюю инфраструктуру: практически все клиентские проекты используют мобильное приложение и сайт, которые получают трафик из нескольких источников (таргетированная и контекстная реклама, CPA-платформы, баннеры и медийная реклама и т. д.).

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

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

Как это было? Древняя архитектура

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

Старое потоковое устройство:

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

• Каждая виртуальная машина получала необработанные данные;

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

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

• Недостаток физических ресурсов для реализации более сложной логики;

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

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

• Масштабирование. Каждая новая потоковая ВМ увеличивала нагрузку на ClickHouse — формировались небольшие партии, что приводило к высокому RPS;

• Выпускать. Обновление требовало развертывания новой версии сервиса на всех машинах, независимо от степени изменений;

• Надежность. Любая ошибка при обработке запроса может привести к его потере, тем самым создавая риск потери данных.

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

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

Новое потоковое устройство

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

• Получать входящие запросы и сохранять их в очереди на обработку;

• Анализировать попадания и извлекать значения параметров;

• Обогащение данных;

• Преобразование в окончательную структуру;

• Загрузка в базу данных.

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

• Повышена стабильность системы;

• Возможность внесения изменений в отдельные компоненты системы;

• Упрощение локализации ошибок при обработке потоков данных.

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

1. Все данные записываются в «сыром» виде. Потоковая передача не является изолированным процессом; на результат напрямую влияет полнота и корректность поступающих запросов. Наличие «сырых» данных дает возможность определить причины и источник ошибок при их возникновении, а также существенно ускоряет процесс исправления;

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

3. Резервное хранилище S3 подключается при сохранении входящего потока. Получение и обработка входящих запросов — наиболее важный уровень сервиса; для повышения стабильности этого процесса помимо достаточно стабильной Kafka в качестве резерва используется S3 от YC. Хранилище данных S3 имеет условно неограниченный, динамически расширяемый ресурс, репликацию и высокую пропускную способность сети, что решает потенциальные проблемы с «перегрузкой» или недоступностью Kafka по различным причинам.

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

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

Система мониторинга и оповещения об инцидентах

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

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

1. Обнаружение проблемы. Мониторинг позволяет быстро выявить проблему и сообщить команде о необходимости вмешательства в процесс, тем самым минимизируя риск потери данных;

2. Оптимизация производительности. С помощью мониторинга инцидентов вы можете анализировать производительность системы и обнаруживать узкие места: загрузку процессора, использование памяти и другие параметры;

3. Прогноз. Мониторинг текущего состояния позволяет собирать данные для прогнозирования будущих нагрузок и планирования ресурсов;

4. БАС. Мониторинг помогает отслеживать соглашения об уровне обслуживания и обеспечивать их соблюдение.

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

Как мы можем заметить аномалии в данных?

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

2. Настройте автоматические оповещения позволяющий следить за стабильностью всех ВМ, расположенных в архитектуре проекта. Оповещение настроено на список метрик, отражающих стабильность системы (основные показатели ВМ: ЦП, использование памяти, размер свободного диска, сеть), а также метрик, учитывающих специфику продукта (RPS и его динамика, коды ответов, скорость обработки запросов и т.д.)

3. Данные не остаются без присмотра: ответственные сервисные агенты контролировать работу всего процесса и при необходимости исправлять возникающие инциденты.

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

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