Внутренняя система · В проде

Платформа данных

Платформа данных торговой компании: сбор из кабинетов площадки по расписанию, архив каждого ответа до разбора, слои raw → staging → core и витрины наружу. Это не «хранилище продаж для расчёта маржинальности», а фундамент: одни и те же витрины кормят дашборды, приложения и ИИ-агентов.

Болело

Каждый отдел выгружал данные площадки сам и считал по-своему, и совещание начиналось со спора, чья таблица правильная. История за прошлый год не сохранялась вовсе.

Стало

Платформа собирает данные по расписанию и раскладывает их по слоям до готовых витрин. Дальше все - люди, приложения и агенты - берут цифры из одних и тех же витрин.

Эффект по шагам

01 · Из хаоса - в систему: Собрал данные площадки в один источник, из которого считают все
02 · Финансы - прозрачнее: Выплаты, комиссии и удержания сверяются с итогами площадки понедельно
03 · Решения - точнее: Цифра в витрине сверена с первоисточником до единицы товара

Что это даёт бизнесу

История сохраняется навсегда, хотя площадка хранит её 90 дней.
Отчёты у всех сходятся, потому что берутся из одних витрин, а не из личных выгрузок.
Расхождение с выплатами площадки видно на неделе, а не в конце квартала.
Строка затрат не пропадает молча: срез по кабинету предупреждает, что данных не хватает, а не дорисовывает маржу.
Новое приложение или ИИ-агент подключается к готовым витринам, а не пишет свой сбор данных.

От источника к результату

API площадок
Архив сырья
raw → staging → core
Витрины
BI · REST API · Claude · MCP-агенты

Каждый ответ площадки уходит в архив до разбора: ошиблись в разборе поля - перечитываем из архива, а не выпрашиваем историю у площадки заново. Площадка хранит её 90 дней, свой архив - навсегда.

Как устроено

Слои разделены осознанно: сырьё - журнал «как пришло», следующий слой снимает дубли, дальше бизнес-сущности, и только потом витрины. Считать по сырью нельзя, поэтому оно закрыто правами, а не договорённостью.

Формат ответа проверяется на входе: новое поле площадки сбор не ломает, а исчезнувшее - приводит к сообщению в Telegram, при этом загрузка не останавливается.

Автоматическая сверка появилась после реального промаха: одно поле логистики читалось из ключа, которого в текущем API уже нет, и молча было нулём - маржа завышалась на всю доставку. Ошибка прожила незамеченной ровно потому, что систему проверяли ей же самой.

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

Кто ведёт систему сейчас

Инженер. Аналитики и приложения компании подключены только на чтение, у каждого своя учётная запись.

Другие кейсы этого шага

Внутренняя система · В проде

Управленческий финансовый контур

Все цифры компании - в одной системе

Болело: Цифры жили в десяти таблицах, личках и головах трёх человек. При уходе ключевых людей терялись и доступы, и контекст.
Стало: Один источник: движение средств, бюджет, заявки, сверка и справочники в одном приложении с ролями и правами.

Срок: месяц
Заменило: десять таблиц и переписку
Охват: ДДС, БДР, заявки, сверка

Та же система даёт эффект ещё по 3 шагам

Внутренняя система · В проде

Учёт ИТ-инфраструктуры

Сервисы, доступы и ответственные - в одном месте

Болело: Учёт жил в унаследованной панели и разрозненных записях: кто к чему подключён, что на каком сервере крутится, кто за это отвечает. Уход человека уносил и доступы, и контекст.
Стало: Одна панель: дерево сервисов, матрица доступов «кто куда», ключи и порталы, задания, проблемы, изменения и аудит. Вход под собственным логином, видимость разделов - по ролям.

Разделы
Срок
Заменило: унаследованную панель на 35 вкладок

Внутренняя система · В проде

Карта унаследованного хранилища

Что лежит в унаследованной базе - теперь известно

Болело: Унаследованное хранилище досталось чёрным ящиком: несколько баз, сотни таблиц и вью, OLAP-куб - и ни одного описания. Каждый вопрос к данным начинался с раскопок.
Стало: Переиспользуемый клиент, CLI для запросов и карта данных, которая пересобирается одной командой: базы, таблицы, вью, колонки, рядом - карта куба. Плюс проверка, что данным можно верить.

Охват карты
Обновление: карта пересобирается одной командой
Проверка данных: свежесть куба и сверка куба с SQL

Тип: Внутренняя система
Статус: В проде
Сбор: 33 домена по расписанию
Двери наружу: BI и SQL, REST API, Claude Code, MCP
Сверка: до единицы товара и до копейки
Архив: сырьё сохраняется до разбора

PythondltdbtPostgreSQLDagsterMinIOFastAPIMCPDocker