Расскажи про опыт работы с Clickstream

Расскажи про опыт работы с Clickstream

Clickstream — это один из самых объемных и сложных типов данных в аналитике. Это последовательность событий пользователей при взаимодействии с приложением.

Масштаб данных

В компании, где я работал, на e-commerce сайте с 2 млн активных пользователей:

• Page views: 50 млн/день
• Клики: 30 млн/день
• Другие события: 40 млн/день
• Итого: 120 млн событий/день, 1,400 events/sec в среднем
• В пики: 5,000 events/sec
• Size per event: 300 bytes
• Daily volume: 36 GB

Архитектура сбора

Frontend JavaScript SDK батчит события и отправляет на /api/v1/events каждые 30 сек или по 50 событий.

Backend Pipeline

API -> Validation -> Kafka raw_events
                        |
                        v
                 Spark Streaming
                   - Deduplicate
                   - Enrich
                   - Filter bots
                        |
                        v
                  Kafka processed_events
                        |
                        +-> S3 Data Lake (daily parquets)
                        +-> Snowflake Warehouse
                        +-> Real-time dashboards

Основные вызовы

Late-arriving events Браузер offline -> event отправляется с задержкой. Решение: двойное временное окно для real-time (< 1h) и batch обработки (> 1h).

Дедупликация Сетевые retry могут отправить event дважды. Используем уникальный event_id с ON CONFLICT DO NOTHING в SQL.

Session reconstruction Группируем события по 30-минутному timeout:

window_spec = Window.partitionBy('user_id').orderBy('event_timestamp')
time_gap = unix_timestamp('event_timestamp') - lag('event_timestamp').over(window_spec)
is_new_session = time_gap > 1800  # 30 minutes
session_id = concat_ws('_', 'user_id', sum(is_new_session).over(window_spec))

Bot filtering Фильтруем по user_agent: bot patterns, crawler, spider, scraper. Также удаляем invalid timestamps (будущее, > 1 года назад) и отсутствующие user_id.

Event enrichment Добавляем user properties (country, signup_date, ltv) и geolocation (ip -> city, lat, lng). Вычисляем derived fields типа days_since_signup.

Аналитические задачи

Funnel analysis - отслеживаем drop rate на каждом шаге: browse -> add_to_cart -> checkout -> purchase.

User journeys - строим пути пользователей через STRING_AGG(event_type) для анализа поведения.

Cohort analysis - группируем пользователей по когортам (месяц регистрации) и отслеживаем их поведение.

Performance optimization

1. Partitioning: event_date, event_hour, event_type
2. Bucketing: по user_id для join'ов
3. Compression: Snappy (balance скорости и размера)
4. Dedicated Kafka partitions для каждого event_type

Best Practices

1. Версионируй schema - version_id в каждом событии
2. Валидируй на entry point - catching bad data early
3. Мониторь качество: duplicate ratio, late arrival %, validation failure %
4. Архивируй старые данные (> 1 года) в cold storage
5. Используй idempotent обработку даже если system гарантирует exactly-once

При правильной архитектуре и процессах можно обрабатывать сотни миллионов событий в день с хорошей latency и качеством.