GamerAM: Скрининг

Сначала измерьте концентрацию показов: Gini/entropy, долю показов у top 1/10%, покрытие и метрики по exposure buckets. Затем добавьте контролируемый exploration, ограничения на показы, diversity/fairness constraints и cold-start boosts с guardrails по engagement и match quality.

Диагностика начинается с распределения показов: сколько impressions получает каждый профиль, какая доля у top 1% и 10%, Gini/entropy exposure, coverage long tail, exposure by cohort и conversion по exposure buckets. Нужно отделить реальное качество профиля от feedback loop: популярные профили могут быть сильными, но система не должна бесконечно усиливать только их.

Смягчение должно быть контролируемым. Подходы: exploration slots, freshness/cold-start boosts, per-profile exposure caps, diversity constraints, multi-objective ranking или re-ranking, который балансирует expected engagement и coverage. Для matching важно оптимизировать reciprocal outcomes, а не только one-sided likes.

Нельзя просто рандомизировать всю выдачу. Нужен A/B test с guardrails: sessions, likes, messages, retention, complaints/reports, match quality и latency. Цель - расширить здоровое покрытие, не разрушая relevance.

Смотрите позитивные и негативные сигналы вовлечённости, retention и downstream actions по сегментам. Учитывайте position bias, popularity bias, selection bias, clickbait, cold-start группы и то, что общая метрика может скрывать просадку нишевых сегментов.

Для ленты нужна не одна метрика, а набор сигналов. Positive engagement: clicks, dwell time, likes, comments, shares, saves, follows, profile visits. Negative signals: hides, skips, quick backs, reports, unfollows, session exits. Для социального продукта могут быть важнее downstream outcomes: новые связи, диалоги, возвращаемость и качество community.

Метрики нужно смотреть в разрезах: новые/старые пользователи, география, язык, игровые интересы, creator size, content type, cold-start users. Глобальная метрика может расти, пока маленькие communities или новые пользователи получают хуже.

Главные искажения: position bias, popularity bias, selection bias от старого ranker-а, survivorship bias, short-term clickbait и неоднозначность dwell time. Поэтому полезны randomized exploration buckets, counterfactual logging, long-term retention, qualitative review и guardrails по negative feedback.

Сначала отделите задержку scheduler/очереди от узкого места выполнения. Посмотрите историю duration, логи, ресурсы, объём данных, retries и внешние зависимости; затем оптимизируйте IO, shuffle/joins, partitioning, parallelism, timeouts, идемпотентные retries и freshness alerts.

Начинать нужно с фактов: какие tasks стали медленнее, где queue time, где execution time, что в scheduler/worker logs, какие CPU/RAM/disk/network/GPU metrics, не вырос ли объем данных и не появилась ли внешняя задержка. Часто проблема не в Airflow, а в Spark job, базе, object storage, API или выросшем input.

Дальше проверяем форму вычислений: не читаем ли всю историю вместо incremental slice, не фильтруем ли после большого join, нет ли skew, лишних shuffle, маленьких файлов, non-idempotent retries или зависших sensors. Исправления: partitioning, predicate pushdown, caching reused data, batch/chunk parallelism, resource pools, retries/timeouts и backfill policy.

Для надежности нужны SLA/freshness alerts, row-count checks, task duration alerts, runbook и owner. Если DAG уже не помещается в окно даже после оптимизации, нужно либо split/staged publish, либо пересмотреть product freshness requirement.

Batch проще и дешевле, если допустима задержка и нужны backfills. Streaming нужен, когда свежесть в секунды или минуты меняет продуктовое действие: real-time personalization, fraud/risk, counters, triggers или online features.

Batch ETL подходит для регулярных training datasets, offline recommendations, отчетов, агрегатов, периодических feature tables и задач, где freshness в часы или день приемлема. Он проще для отладки, дешевле в эксплуатации и лучше поддерживает backfill.

Streaming оправдан, когда задержка прямо влияет на продукт или риск: свежие клики в ленте, fraud/rate-limit реакции, near-real-time counters, notifications, online features, мониторинг эксперимента или события, которые быстро устаревают. Но streaming добавляет ordering, late events, replay, state management, exactly-once/at-least-once semantics и сложный monitoring.

В production часто нужен hybrid: streaming обновляет свежие фичи и реакции, batch пересчитывает canonical datasets, чинит late data и обучает модели. Выбор надо делать по freshness SLA, correctness requirements, объему, команде и цене эксплуатации.

Надёжный pipeline корректен, идемпотентен, наблюдаем, восстановим и понятен другим людям. Проверяйте его тестами, data-quality checks, freshness alerts, monitoring, backfill/replay drills, rollback и документацией/runbook.

Надежность - это не только зеленый DAG. Pipeline должен стабильно производить корректный результат, безопасно переживать retries, иметь владельца, метрики, alerts, понятный recovery path и документацию. Если его может чинить только один человек, он не надежен организационно.

Проверки нужны на нескольких уровнях: unit tests для transformations, integration tests для зависимостей и schemas, data-quality checks для row counts/nulls/duplicates/distributions/freshness, monitoring для task duration, queue time, failure rate, artifact size и publish status. Для ML добавляются feature schema compatibility, model metric regression, prediction distribution, drift и latency.

Хороший pipeline умеет backfill/replay, не портит данные при повторном запуске, логирует версии входов/выходов и имеет rollback к предыдущему артефакту. Runbook должен объяснять, что делать при падении, stale data и просадке качества.