ERP · NDA-safe case
ClickHouse / Evotor Analytics Migration
Book&Track analytics layer: Evotor + CRM/Gizmo + клубные источники → ClickHouse raw/facts/marts/views → API → аналитические экраны.
00 · КЕЙС ЗА 30 СЕКУНД
Кейс за 30 секунд
Данные по выручке, клиентам, игровому времени, удержанию, RFM, магазину и загрузке PC/PS были разнесены между кассой, CRM/Gizmo и клубными базами.
Разложил контур на C4-уровни, источники, data planes, lineage, runtime и quality gates; связал загрузку, витрины и UI-решения.
C4 Architecture · Data Lineage · Quality Gates · Runbook
Появился повторяемый аналитический слой продукта: от источника факта до управленческого экрана Book&Track
Контроль: строки / checksumАвтоматизация: фабрика миграцииРешение: gates переключенияРегламент: повторяемый запуск
- Данные по выручке, клиентам, игровому времени, удержанию, RFM, магазину и загрузке PC/PS были разнесены между кассой, CRM/Gizmo и кл...
- решение зависело от ручных сверок, чатов и отдельных файлов
- владельцы исключений и критерии приемки были неочевидны
- Появился повторяемый аналитический слой продукта: от источника факта до управленческого экрана Book&Track
- артефакты: C4 Architecture · Data Lineage · Quality Gates · Runbook
- Row count validation после загрузки.
00B · ПРОЕКТНЫЙ ПАКЕТ
Такой проект можно адаптировать под ваш бизнес
Точный объем зависит от источников, качества справочников, количества владельцев и глубины UAT.
- карта текущего процесса и целевая модель
- BRD/ТЗ, data model, расчетные правила и UAT checklist
- дашборд, отчет, Google Sheets-контур или разбор артефактов
- список управленческих решений и владельцев действий
- аудит текущей отчетности и ручных операций
- проектирование справочников, правил учета и проверок
- передача результата через приемку, регламент и runbook
01 · КОНТЕКСТ
Бизнес-контекст
Проект поддерживает аналитику компьютерных клубов: выручка, клиенты, удержание, RFM, маркетинг, нагрузка PC/PS, магазин, остатки и прогноз.
02 · ПРОБЛЕМА
Проблема
Данные по выручке, клиентам, игровому времени, удержанию, RFM, магазину и загрузке PC/PS были разнесены между кассой, CRM/Gizmo и клубными базами.
03 · РОЛЬ
Что я сделал
Разложил контур на C4-уровни, источники, data planes, lineage, runtime и quality gates; связал загрузку, витрины и UI-решения.
04 · БИЗНЕС-ПРАВИЛА
Бизнес-логика и правила
- Контур разделен на real-time/operational plane для текущего состояния клуба и historical/aggregated plane для тяжелой аналитики.
- Evotor webhook не смешивается с ночной batch-загрузкой: оперативные документы проходят свой ETL-flow и incremental refresh.
- Quality gates отделяют raw-факт от управленческой витрины: mapping, freshness, dedup, reconciliation, normalization и final validation.
05 · АРХИТЕКТУРА
Архитектура данных
Architecture Explorer · C4 matryoshka · NDA-safe demo
NDA-safeBook&Track Analytics Architecture
Как кассовые, CRM и операционные данные клубов превращаются в быстрые аналитические витрины Book&Track.
Quality gatesmapping · freshness · dedup · reconciliation · normalization · validation
Decision readiness
Как данные становятся пригодными для решения?
Evotor, CRM и Gizmo сохраняются в raw-слое без потери детализации.
Сырые данные превращаются в facts, marts и views внутри ClickHouse.
Business-key validation, dedup, freshness, reconciliation и service-layer normalization.
Book&Track показывает готовые витрины: выручка, клиенты, удержание, RFM, загрузка и прогноз.
Слои подробнее
Источники
- Evotor Cloud API
- Evotor Webhook
- Gizmo / CRM DB
- club operational DB
Загрузка
- batch ELT
- webhook ETL
- mapping
- validation / dedup
Хранилище
- ClickHouse raw
- ClickHouse facts
- ClickHouse marts/views
- quality logs
Витрина
- Book&Track Analytics UI
- Revenue / Retention / RFM
- Host Load / Inventory / Predictive
06 · МОДЕЛЬ ДАННЫХ
Модель данных / витрины
evotor_* / crm_* / gizmo_*rawсырые события кассы, CRM и клубных систем
evotor_sales_fct / crm_payments_fct / gizmo_user_sessions_fctfactнормализованные факты для управленческой аналитики
mart_revenue_daily / mart_host_load_daily / mart_user_retentionmartвитрины для экранов Book&Track Analytics
07 · МЕТОДОЛОГИЯ
Методология, процедуры, модель и эффект
Методология
- Переупаковал миграционный контур в Architecture Explorer: L0 бизнес-контекст, L1 C4 Context, L2 data planes, L3 components, L4 lineage, L5 runtime, L6 quality gates.
- Связал каждый dashboard-экран с backend/service layer и источником данных, чтобы архитектура читалась как продуктовый analytics layer.
- Развел raw, facts, marts/views и service normalization, чтобы UI не получал невозможные или технически сырые значения.
Что перенесено в систему
- Batch ELT: cron, импорт CRM/Evotor/Gizmo, пересборка facts/marts и финальная сверка.
- Webhook ETL: прием Evotor event, проверка доступа, flatten documents/positions/payments, raw insert и incremental refresh.
- Validation/Dedup: business-key checks, clean-table rebuild, post-fact dedup, final validation и row counts.
Модель и критерии
- Data lineage показывает цепочки Evotor sales, CRM payments и Gizmo sessions от raw tables до конкретных экранов аналитики.
- ClickHouse semantic layer разделяет facts, marts, views и dimensions вместо прямого чтения сырых таблиц в интерфейсе.
- Service-layer normalization защищает UI от невозможных значений, например host load выше 100%.
Измеримый эффект
- Аналитика Book&Track получила читаемую архитектуру: sources → ClickHouse analytics layer → API → UI → decisions.
- Ошибки качества обнаруживаются до публикации витрин, а не после просмотра dashboard пользователем.
- Руководитель видит готовые срезы по выручке, клиентам, удержанию, RFM, нагрузке, магазину и прогнозу.
08 · ПЕРЕХОД К ДЕМО-СЛОЮ
Демо-слой вынесен в лабораторию
На странице кейса оставлены контекст, проблема, архитектура, правила, валидация и импакт. Интерактивный слой вынесен отдельно, чтобы кейс не смешивался с демо-интерфейсом.
Что проверять в дашборде?
Открой отдельный экран, не теряя контекст кейса
- Какое управленческое решение должен поддержать дашборд?
- Какие правила учета и контроля защищают расчет?
- Какие исключения требуют владельца и SLA?
- Что должно быть принято через UAT перед использованием?
09 · ДОКАЗАТЕЛЬСТВА
Артефакты, валидация и эффект
Артефакты
Рабочий артефакт проекта: постановка, логика, проверка или демонстрационный слой.
Row count validation после загрузки.Рабочий артефакт проекта: постановка, логика, проверка или демонстрационный слой.
Row count validation после загрузки.Рабочий артефакт проекта: постановка, логика, проверка или демонстрационный слой.
Row count validation после загрузки.Порядок запуска, проверки, диагностики и передачи процесса владельцу.
Row count validation после загрузки.Валидация
- Row count validation после загрузки.
- Checksum validation для критичных полей.
- Benchmark query suite для оценки производительности.
- Hardware sizing report до роста объема.
Бизнес-импакт
Появился повторяемый аналитический слой продукта: от источника факта до управленческого экрана Book&Track
- Аналитика Book&Track получила читаемую архитектуру: sources → ClickHouse analytics layer → API → UI → decisions.
- Ошибки качества обнаруживаются до публикации витрин, а не после просмотра dashboard пользователем.
- Руководитель видит готовые срезы по выручке, клиентам, удержанию, RFM, нагрузке, магазину и прогнозу.
10 · ВЫВОДЫ
Выводы и улучшения
- Discovery и DDL generation снижают ручные ошибки миграции.
- Validation должна быть частью pipeline, а не отдельной ручной задачей.
- Sizing полезен до продового роста нагрузки.
NDA-safe discussion
Обсудить похожую задачу?
Напишите в Telegram: за 30 минут разберем вашу похожую ситуацию без закрытых доступов — источники, платежи, P&L, ручные таблицы, проверки и первый управленческий шаг.
Можно начать с описания текущего Excel/ERP/Sheets-контура и главной боли собственника.