Поделиться
Поделиться

Продукт без данных — это UI. Продукт с грязными данными — это UI плюс ложные решения. Data Engineering в продуктовой разработке не обязан выглядеть как «озеро данных на 50 петабайт». Часто это аккуратные события, контракты между сервисами, надёжный PostgreSQL и понятный ETL с телеметрии.

В OtherCode data-контуры проходят через Synapse Stream (гео и realtime на PostGIS), игровой Game API, промышленную телеметрию (Typhoon/Modbus, Galvatec), документные потоки URAP AI, очереди Redis, клиенты Diom (Flutter) и веб на Next.js, контент в Content Factory (Telegram). Ниже — как мы проектируем пайплайны, качество и аналитику.

Зачем продукту data engineering

| Задача | Без DE | С DE | |--------|--------|------| | Фича «статистика» | SELECT на горячей OLTP без индексов | Отдельные витрины / агрегаты | | Интеграция сервисов | «Как получится» JSON | Версионированный контракт | | Телеметрия станков | Логи в файл на USB | Нормализованный поток + алерты | | Аналитика продукта | Только GA, пока доступен | Свои события + Метрика |

Цель — доверенные данные вовремя, а не максимальный зоопарк инструментов.

Событийные пайплайны

Большинство продуктовых фактов удобно моделировать как события: user.signed_up, geo.checkin, modbus.alarm, document.processed.

Типовой поток:

[Producer: API / device / bot]
        ↓
[Валидация схемы / контракт]
        ↓
[Очередь Redis / брокер]
        ↓
[Consumer / worker]
        ↓
[PostgreSQL (+ PostGIS)] → [агрегаты / витрины]
        ↓
[Аналитика / алерты / API чтения]

Почему Redis-очереди часто достаточно

На старте и среднем масштабе Redis lists/streams закрывают:

  • сглаживание пиков (загрузка документов в URAP, всплески гео-чекинов);
  • retry и backoff;
  • разделение API (быстрый ответ) и тяжёлой обработки.

Когда нужен именно кэш и очереди — см. Redis: кеширование и очереди. Kafka и аналоги подключаем, когда появляются жёсткие требования к retention, множеству независимых consumer group и audit на огромном потоке — не «потому что в вакансиях пишут Kafka».

PostgreSQL и PostGIS как ядро правды

Для Synapse Stream и Game API геоданные — не «ещё одна колонка lat/lon», а полноценная модель:

  • точки, полигоны зон, проверки вхождения;
  • индексы GIST/SP-GIST под реальные запросы;
  • аккуратная схема миграций в GitLab CI до деплоя.

OLTP-база остаётся источником операционной правды. Аналитические тяжёлые сканы по возможности выносим:

  • в ночные агрегаты;
  • в read-replica;
  • в отдельные таблицы витрин (daily_zone_stats, device_uptime_by_hour).

Практики производительности БД: PostgreSQL оптимизация.

Микросервисы и данные

Если сервисов несколько, enticement «своя БД на сервис» без контрактов заканчивается хаосом. Мы начинаем с ясных границ и событий; дробление БД — когда команда и нагрузка это оправдывают. Базовый взгляд: Микросервисы: с чего начать.

ETL / ELT для промышленной телеметрии

Typhoon (STM32 + Modbus) и контуры Galvatec дают другой профиль данных:

| Особенность | Следствие для пайплайна | |-------------|-------------------------| | Периодический poll регистров | Идемпотентность, watermark времени | | Пропадания связи | Буфер на шлюзе, late events | | Шум и выбросы | Правила качества до «умной» аналитики | | OT / IT разделение | DMZ, не торчать Modbus в публичный интернет |

Упрощённый ETL:

  1. Extract — шлюз читает Modbus/OPC, пишет сырой кадр (timestamp, device_id, regs).
  2. Validate — диапазоны, тип, последовательность sequence id.
  3. Transform — инженерные единицы, статусы, дедуп.
  4. Load — PostgreSQL + при необходимости объектное хранилище сырых кадров.
  5. Serve — API для Diom/веб-дашбордов, алерты в Telegram/почту.

ML здесь вторичен: сначала стабильный поток и словарь сигналов, потом аномалии. Иначе модель учится на мусоре.

Качество данных: не «потом приберём»

Качество встраиваем в контракт, а не в квартальный субботник.

Практики OtherCode

  • Схема на входе (JSON Schema / Zod / Pydantic) — отвергаем или карантинируем битое.
  • Dead-letter queue — ядовитые сообщения не блокируют всю ленту.
  • Идемпотентные consumer — повтор доставки не создаёт дубли фактов.
  • Data tests — в CI или nightly: null-rate, уникальность ключей, свежесть watermark.
  • Владелец набора данных — кто отвечает за geo_events, кто за ocr_results.

| Проверка | Пример | Действие при fail | |----------|--------|-------------------| | Freshness | Нет событий device X > 15 мин | Алерт смене | | Completeness | Пустой zone_id > 2% | Карантин + тикет | | Consistency | Сумма частей ≠ целому | Блок витрины | | Uniqueness | Дубли event_id | Дедуп + лог |

Для URAP качество ещё и полевое: confidence OCR, доля ручных правок — это data quality метрики продукта, не только «модель плохая».

Контракты данных между сервисами

Контракт — версия сообщения или таблицы, которую продюсер обещает, а потребитель может тестировать.

Минимум в контракте:

  • имя события / сущности;
  • semver или schema_version;
  • обязательные поля и типы;
  • семантика null и единиц измерения;
  • гарантии доставки (at-least-once → нужен idempotency key);
  • PII-флаги (что маскировать в логах).

Пример: Game API публикует player.location_updated v1; Synapse-аналитика и пуш-уведомления потребляют одно и то же, не парся «как получится» из чужой таблицы.

Ломающие изменения — только через v2 + период двойной записи или feature flag. Тот же дух дисциплины, что в API-дизайне и деплоях через GitLab на docker runners.

Аналитика: не только Google Analytics

Для продуктов в РФ и для устойчивости к внешним сбоям мы не ставим всё на один зарубежный счётчик.

| Слой | Инструмент | Зачем | |------|------------|-------| | Маркетинг / веб | Яндекс Метрика | Воронки, источники, РФ-реальность | | Продуктовые события | Свои таблицы в PostgreSQL | Полный контроль, join с биллингом | | Операционка | Логи + метрики хоста | Инфраструктура, PM2, Docker | | AI/OCR | Eval + feedback URAP | Качество моделей | | Контент | Метрики бота Content Factory | Доставка и вовлечённость в Telegram |

Next.js-сайт othercode.ru и клиентские веб-части шлют события осознанно (без PII в URL), мобильный Diom — через backend, чтобы схема была одна. GA может дополнять картину, но не быть единственным источником правды.

Как это живёт в инфраструктуре студии

  • Сбор и обработка — Docker-workers, деплой через GitLab CI, production на VPS RU / Yandex Cloud.
  • Очереди — Redis рядом с API.
  • Хранение — PostgreSQL/PostGIS, бэкапы по расписанию.
  • Доставка — PM2 для Node-слоя, compose для воркеров.
  • Секреты и доступы — раздельно staging/prod; промышленные контуры изолированы.

Data engineering здесь — часть DevOps-дисциплины: миграции в CI, откат образа, мониторинг лагов consumer.

Слои хранения: operational, serving, archive

Не всё должно жить в одной горячей таблице.

| Слой | Примеры | SLA | |------|---------|-----| | Operational | Текущие сессии Game API, активные задачи URAP | Низкая latency, строгая консистентность | | Serving / витрины | Суточная статистика зон Synapse, uptime линий Galvatec | Быстрые чтения для дашбордов | | Archive | Сырые Modbus-кадры, старые PDF | Дешёвое object storage, редкий доступ |

Ошибка новичка — тащить год таймсерий в тот же инстанс, что обслуживает чекины в реальном времени. Правило: горячий путь продуктовый, холодный — отдельно, с политикой retention.

Время и идемпотентность

В распределённых пайплайнах часы врать любят. Мы фиксируем:

  • event_time (когда случилось в домене) и ingested_at (когда приняли);
  • monotonic id или hash полезной нагрузки для дедупа;
  • политику late events (телеметрия с устройства, которое неделю было offline).

Без этого графики «вчера» пляшут после догрузки — и бизнес перестаёт верить витринам.

PII, маскирование и доступ

Документы URAP, геолокация игроков Synapse, переписка в Telegram Content Factory — разные классы чувствительности.

Практика:

  • классификация полей на этапе контракта (pii: true);
  • маскирование в логах workers;
  • отдельные роли БД: app-runtime без DROP, аналитик — read-only на витринах;
  • для enterprise — возможность держать корпус документов в контуре заказчика, а в облако отдавать только агрегаты.

Data engineering без privacy — риск, который не лечится «ещё одним дашбордом».

Пример: от сигнала станка до экрана Diom

  1. STM32/шлюз Typhoon читает регистры по Modbus.
  2. Кадр валидируется и кладётся в очередь.
  3. Worker пишет нормализованную точку в PostgreSQL.
  4. Правило алерта («температура > порога N минут») создаёт событие.
  5. Mobile Diom получает push/API; веб-дашборд на Next.js читает витрину.
  6. Раз в сутки агрегат uptime уходит в отчёт заказчику.

На каждом шаге есть контракт и метрика свежести. «ИИ предсказал аварию» может появиться позже — поверх чистого потока, а не вместо него.

Команда и ритм работы с данными

Раз в спринт (или раз в две недели) смотрим:

  • лаг consumer и DLQ;
  • null-rate критичных полей;
  • рост диска и необходимость archive;
  • новые события без документации в каталоге.

Это короткий ритуал, но он дешевле месячной «миграции на озеро», когда уже никто не понимает, откуда цифра в отчёте.

Связка аналитики продукта и инфраструктуры

Данные о продукте бесполезны в вакууме. Мы смотрим рядом:

  • конверсию воронки (Метрика + свои события) и error rate API после деплоя;
  • рост числа документов URAP и длину очереди Redis;
  • активность зон Synapse и p95 геозапросов PostGIS;
  • число алертов Typhoon/Galvatec и долю ложных срабатываний после смены порогов.

Так data engineering стыкуется с GitLab-релизами и PM2/compose-деплоями: изменение в коде всегда можно сопоставить с изменением метрик. Если витрина «отвалилась» после миграции — это инцидент данных той же важности, что 5xx на othercode.ru.

Отдельно документируем определения метрик («активный игрок», «обработанный документ», «онлайн устройства»). Без словаря каждое подразделение заказчика рисует свой график и спорит на статусе.

Антипаттерны

  1. Считать логи приложений аналитикой — нет схемы, нет SLA.
  2. Тяжёлые отчёты на primary OLTP в рабочий день.
  3. Смена формата события без версии.
  4. Сваливать ПДн в сырые озера «на будущее».
  5. Строить Kafka + data lake до первого стабильного контракта.

Чеклист зрелости данных в продукте

  • [ ] Есть каталог ключевых сущностей и событий
  • [ ] Есть владелец и schema_version
  • [ ] Очередь + idempotency для асинхронщины
  • [ ] Проверки freshness/completeness
  • [ ] Витрины отделены от горячего пути
  • [ ] Аналитика не зависит от одного внешнего счётчика
  • [ ] ПДн классифицированы

Итог

В OtherCode data engineering — это события, контракты, PostgreSQL/PostGIS для Synapse, Redis для сглаживания нагрузки, ETL телеметрии для Typhoon/Galvatec, feedback-петли URAP и аналитика с Метрикой и своими витринами. Масштаб инструментов растёт вместе с продуктом, а не вместо него.

Нужны пайплайны и витрины под ваш продукт — оставьте заявку.