Документ задаёт приоритеты развития песочницы и детальное ТЗ-направления (из продуктового бэклога TechMart) на ближайшее время. Дополнительно — блок D: канал доставки сводок инвестору через мессенджер (три уровня зрелости). Текущий стек, DAG и схемы DWH: PROJECT_SUMMARY.md, PIPELINES.md, diagrams/dwh-schemas.md.
Описание: интернет-магазин электроники в модели marketplace. Аналитическая платформа призвана закрывать:
- анализ продаж в реальном времени;
- рекомендательные сценарии;
- antifraud-задачи;
- управление остатками;
- аналитику эффективности продавцов.
Источники (логически):
- OLTP PostgreSQL (
orders,users,products,sellers); - потоковые события (clickstream, корзина, поиск);
- внешние API (курсы валют, трекинг доставок);
- CSV/файлы обновлений каталога от продавцов.
Слойность (упрощённо): источники → ingestion → storage → transformation → serving → monitoring (детализация в ARCHITECTURE.md).
- P0 — Стек поднимается и доступен: Schema Registry, Kafka Connect (Debezium), Atlas в основном
docker-compose.yml; ingress и портал без пометки «опционально» для этих сервисов; шаблоны curl для REST; единая документация; Node-RED в стеке сadminAuthиз.env. - P1 — Репликация и наблюдаемость: регистрация Debezium-коннекторов воспроизводимо (скрипт, Makefile, one-shot init или DAG); проверяемые слоты PostgreSQL; lag и метрики на Grafana / шаблон алертов.
- P2 — Каталог и lineage: регулярная публикация сущностей в Atlas (Airflow DAG или cron в compose); связка артефактов dbt / витрин с Atlas (минимум — существующие YAML + автозапуск); DQ gates Atlas ↔ Prometheus в runbook как обязательный шаг после деплоя.
- P3 — Интеграция SR в контурах данных: Avro (или иной формат) и использование Schema Registry в коннекторах и потребителях; согласование имён топиков
cdc_*со Spark/streaming примером. - P4 — Зрелый lineage: OpenLineage/Marquez или аналог, сквозной граф от источника до marts; политики доступа к каталогу; SLO на задержку CDC.
- P0: Стабильный core (Postgres, Kafka, MinIO, Airflow, dbt-rest, dbt Docs, портал, базовая observability) — текущая база репозитория.
- P1: Node-RED — типовые flow (алерт, заглушка дашборда, webhook); расширения generators/profile по одному сценарию.
- P2: Выборочные пункты блоков A/B Roadmap (ETL/ML MVP) без раздувания области.
- P3: Блоки C/D дорожной карты (мессенджер инвестору, RAG-ограждения) — после стабильности данных.
Ниже — подробные постановки: цель, требования, ориентиры по хранению. Имена схем/таблиц — целевые для эволюции стенда; фактическая реализация по мере сил.
Цель: собрать единый профиль клиента из нескольких источников (идея — до 7 в полной постановке).
Требования:
- Ingest: PostgreSQL (OLTP), в перспективе внешние API (например CRM), Kafka
events.auth(по сценарию), S3/MinIO raw; - дедупликация: deterministic → probabilistic (например, сходство TF-IDF для ФИО/адреса);
- хранилище: зона curated (в полной постановке — Iceberg
curated.customer_360; в стенде — эквивалент витрин/слоя marts); - инкрементальность: CDC (Debezium) + merge-on-read или watermark-паттерн, совместимый с текущими DAG;
- ориентир по SLA: менее 15 минут от события до актуального профиля (цель дизайна, не гарантия стенда).
Цель: привести выручку к сопоставимому виду в разных валютах.
Требования:
- источники: OLTP
orders, внешнее API курсов; - инкрементальность: курсор по
updated_at/ граница пересчёта; - обработка отложенных/исправленных заказов через очередь перерасчёта (логически);
- выходные поля:
revenue_converted,fx_gap,fx_type; - запись:
analytics.revenue_daily(илиdwh_marts/ соглашения проекта).
Цель: связать touchpoint → session → conversion.
Требования:
- источники: Kafka (витрина web/mobile), сырые события в S3, конверсии из CRM-эквивалента;
- join: окно 7 дней, watermark 48 ч (как дизайн-ориентир);
- реализация: Spark Structured Streaming или batch с тем же смыслом;
- выход:
mart.attribution_first_touch(имя витрины — согласовать сdbt).
Цель: отражать фактическую доступность товаров для поиска и ML.
Требования:
- агрегировать
warehouse.stockиwarehouse.reservations(или эквиваленты в стенде); - метрика
inventory_score, обновление с throttling (например, только изменившиеся SKU, цикл 5 минут); - destination: Redis + Iceberg/витрина (в стенде — marts + при необходимости Redis).
Цель: подготовка признаков для real-time antifraud (или near-real-time).
Требования:
- источники: Kafka
transactions,login_events,device_fingerprint(по сценарию); - признаки: frequency, velocity,
unusual_device,ip_novelty; - справочники: GeoIP, BIN lookup (подключаемо внешними справочниками);
- выход:
features.risk_factors(feature store / marts в упрощении).
Цель: контроль задержек потоковых пайплайнов.
Требования:
- метрики: consumer lag, возраст watermark, p90 processing time;
- интеграция: Prometheus + Grafana;
- вебхуки: PagerDuty/Slack при нарушении SLA (в стенде — шаблон алертов);
- хранение:
monitoring.streaming_sla(илиmeta+ витрина).
Цель: восстанавливать иерархию товаров из разрозненных тегов.
Требования:
- источники: ручные теги, категории поставщиков, ML-предсказания;
- алгоритм: greedy tree rebuild + rule-based overrides;
- ночной batch;
- хранение:
dim.product_taxonomy_v2(или marts-эквивалент в dbt).
Цель: единая модель жизненного цикла заказа по событиям.
Требования:
- join: оплаты, доставка, возвраты, тикеты поддержки;
- state machine: created → paid → shipped → delivered → closed;
- SLA: сутки batch + микро-batch почасово (ориентир);
- destination:
mart.order_lifecycle.
Цель: качество поставщиков (своевременность, дефекты, отмены).
Требования:
- KPI: on-time delivery, defect ratio, cancellation ratio;
- источники: логистика, QC,
supply_contracts(в упрощении — из доступных сущностей); - инкрементальность: курсор по
event_time; - хранение:
analytics.supplier_kpi/ marts.
Цель: автоматически находить аномалии в операционных метриках.
Требования:
- источник: экспорт метрик Prometheus;
- подход: STL + z-score (или сопоставимый);
- Airflow: периодичность, например 30 мин;
- сигналы: Slack +
monitoring.metric_anomalies(таблица/витрина).
- датасет: поведенческие события + история оплат;
- выход:
churn_score[0, 1]; - модель: LightGBM (или аналог);
- retrain: еженедельно (расписание в Airflow/MLflow).
- метрика: изменение спроса при изменении цены;
- модель: Bayesian Elasticity Regression (или упрощённый регрессионный бейзлайн);
- выход:
features.price_elasticity/ marts.
- источники: исторические доставки, погодные/нагрузочные факторы (по мере появления);
- модель: CatBoost Regressor (пример);
- целевое качество: MAE менее 18 минут (целевой ориентир).
- генерация кандидатных правил через ML;
- модель: Decision Tree, глубина ≤ 4;
- экспорт правил в YAML для согласования с бизнесом.
- модель: DistilBERT (или лёгкий энкодер в стенде);
- классы:
billing,product_bug,logistics_issue,general_question(расширяемо); - выход:
predicted_categoryв feature/marts слое.
Связь с репо: точки входа ML.md, DAG dag_ml_train_spark, PIPELINES.md.
- тесты:
freshness,unique,not_nullна критичных моделях; - для критичных:
severity: error(см.dbt_project); dbt docsв CI, артефакты;- dbt Docs за ingress (статика
dbt/target/, см. WEB_UI_ACCESS.md).
- SLA: задержка ingestion, обнаружение дрейфа схем;
- мониторинг метаданных: row count, min/max, null%;
- агрегаты в
monitoring.data_qualityилиmeta/dwh_dq(согласовать с diagrams/dwh-schemas.md).
- OpenLineage (или аналог) для data lineage end-to-end;
- алерты Prometheus: lag, падения микро-batch;
- SLA-дашборды в Grafana.
Контекст: доставка ключевых цифр и коротких объяснений в Telegram или WhatsApp (бот), без обязательного входа в BI — типичный запрос для регулярной сводки перед инвесторами. Данные готовятся платформой (витрины, DQ, мониторинг); бот отвечает за расписание, форматирование, доверенных получателей и постепенно — за диалог.
Связь с стендом: источник метрик — те же витрины / meta.* / экспорт из Superset или SQL к OLAP; не дублировать расчёт логики в боте на v1. Каталог (Atlas) и портал остаются слоями доверия и навигации (см. business/platform_value.md).
Цель: по расписанию (например, ежедневно / еженедельно) отправлять фиксированный набор KPI: выручка, заказы, рост к прошлому периоду, 1–2 тревожных индикатора из DQ или графиков.
Требования:
- шаблон сообщения (текст + опционально одна картинка графика из отчёта);
- конфигурация: расписание (cron), список chat_id / номеров, секреты API мессенджера;
- источник: заранее согласованные запросы или materialized views (без произвольного SQL из бота);
- логирование отправок и контроль идемпотентности (не дублировать алерт при повторном запуске).
Ограничение: нет свободного текста от пользователя — только подписка на дайджест.
Цель: пользователь (ограниченный whitelist) пишет короткие вопросы в свободной форме; бот отвечает из заранее одобренного набора сценариев (кнопки / ключевые слова → тот же SQL или заготовленные ответы) либо эскалирует «вопрос вне охвата».
Требования:
- явный список интентов и политика: что бот может, чего не может (без выдачи сырых персональных данных в чат);
- rate limiting и audit log (кто спросил, какой сценарий сработал);
- по возможности не парсить произвольный русский в SQL на этом этапе — только маршрутизация к безопасным запросам.
Отличие от v1: есть диалог в рамках белого списка, а не только push.
Цель: один локальный или контролируемый языковой слой (SLM / небольшой LLM) отвечает на вопросы на естественном языке, генерирует или уточняет SQL по согласованной схеме (NL2SQL) и подмешивает контекст из документов (политики метрик, определения KPI, выдержки из runbook) — RAG.
Требования:
- жёсткая песочница SQL: только read-only, только whitelist схем/таблиц, лимит строк, таймаут;
- валидация сгенерированного SQL (блокировка DDL/DML, многотабличные join только из allowlist);
- хранилище для RAG: фрагменты глоссария, описания витрин, Atlas / dbt docs в нарезке;
- контроль утечек: не отправлять в облако чужой API без решения по ИБ (on-prem SLM как опция стенда);
Отличие от v2: шире охват формулировок пользователя при сохранении guardrails; выше требования к наблюдаемости и тестам на подсказки.
Связь: v3 не отменяет v1 — дайджест по расписанию остаётся полезным; RAG усиливает объяснимость («почему такая метрика»).
| Приоритет | Фокус |
|---|---|
| P0 | Стабильный compose, ingress, dbt Docs и API; dbt-тесты и store_failures в dwh_dq; meta.* (прогоны, watermarks); базовые дашборды. Без надёжной базы детальные пункты 1–15 не демонстрируются. |
| P1 | Поэтапная реализация блока A (1–10) и блока B (11–15) в виде MVP: один-два сценария ETL, один ML-пилот, расширение Generators.md и business/use_cases.md. |
| P2 | Блок C в полноте: OpenLineage, сильный CI, каталог метрик, алерты в мессенджеры, model registry, мультиарендность не требуется. Блок D: по желанию — v1 (push-сводка) как демо канала к инвестору; v2/v3 — после стабильности данных и политик ИБ. |
Как читать ближайшее время: в первую очередь — стабилизация P0, затем выбранные пункты из блоков A и B (не все 15 сразу), параллельно наращивать блок C по мере зрелости.
| Документ | Назначение |
|---|---|
| PROJECT_SUMMARY.md | Стек и поток данных |
| PIPELINES.md | Текущие DAG |
| GAPS_AND_PRODUCTION_READINESS.md | Явные разрывы до production-ready и приоритеты |
| FAQ.md | Короткие ответы для бизнеса и инженеров |
| business/value.md | Ценность песочницы |
| business/platform_value.md | Atlas, портал, мессенджер для инвестора (бизнес-смысл) |
Обновляйте дорожную карту вместе с крупными PR: по мере внедрения закрывайте отдельные подпункты и ссылайтесь на коммит/релиз.