Эволюция схемы извлечённых данных без хаоса в аналитике

Где начинается беспорядок

Беспорядок в аналитике редко начинается в день, когда кто-то добавил новое поле. Обычно он появляется раньше: два человека смотрят на одно и то же значение и понимают его по-разному. Для одного "статус клиента" - это этап заявки, для другого - итог сделки. Название одно, а смысл уже разошелся.

Самый неприятный случай выглядит безобидно. Поле сохраняет старое имя, отчеты продолжают считаться, дашборды не падают. Но внутри поле уже значит другое. Вчера approved означал "проверка пройдена", а сегодня - "договор подписан". На графике видна та же колонка, хотя цифры отвечают уже на другой вопрос.

Такое часто случается после маленькой правки в извлечении данных. Команда уточнила правило, модель стала заполнять поле точнее, и всем кажется, что это просто улучшение качества. Для аналитики это уже смена смысла. Если раньше 15% записей попадали в unknown, а потом начали уходить в other, тренд ломается, даже если система работает без ошибок.

Со словарями та же история. Пока значений мало, команда держит их в голове. Потом приходит новое значение, и его по привычке кладут в старую группу без явного правила. Например, retry, on_hold и manual_review один аналитик относит к "в работе", а другой - к "ошибкам". Через неделю у продукта одна конверсия, у продаж другая, у финансов третья. Все считают честно, но считают разное.

Первые сигналы обычно простые:

• один и тот же показатель расходится в двух отчетах
• у поля есть старое описание в документации и новое в чате
• новые значения словаря появляются без отдельного решения
• аналитики боятся трогать старые запросы

Спор о цифрах почти всегда говорит не о плохом BI, а о том, что команда не зафиксировала контракт данных. Если никто не записал версию схемы и дату изменения, любая договоренность живет в памяти людей. Когда эти люди считают метрики по-разному, обратная совместимость отчетов исчезает не с ошибкой в системе, а с уверенными, но неверными цифрами.

Так и начинается хаос: смысл уже изменился, а схема делает вид, что ничего не произошло.

Что обычно меняют в схеме

Проблемы редко начинаются с большой переделки. Чаще команда меняет одну мелочь в extracted data, а через неделю кто-то замечает, что дашборд считает не так, как раньше. Самые опасные изменения обычно выглядят почти безобидно.

Первый частый случай - переименование поля. В источнике все стало понятнее: было client_type, стало customer_segment. Для разработчика это косметика, а для аналитики - разрыв контракта. Старые запросы не находят колонку, витрины перестают собираться, а часть отчетов тихо показывает пустые значения.

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

Еще один частый шаг - разделение одного поля на два. Например, раньше в одном столбце лежал полный статус заказа, а потом команда решила хранить отдельно "этап" и "причину". Для модели данных это логично. Но старые расчеты, где статус участвовал в фильтре, уже не дают тот же результат. Метрика конверсии, доля отмен и среднее время обработки начинают расходиться с историей.

Словари меняют еще чаще, чем кажется. Вчера были значения new, approved, rejected, а сегодня добавили on_hold. Старые срезы обычно такого не ждут. В одном отчете оно попадет в "прочее", в другом исчезнет, в третьем сломает правило, где аналитик вручную объединил статусы.

Отдельная путаница возникает там, где смешивают пустое значение и ноль. Это не одно и то же. Пусто значит, что данных нет или поле не заполнили. Ноль значит, что значение есть, и оно равно нулю. Если команда сводит оба случая в один, отчеты начинают врать: где-то растет число "нулевых" заказов, а где-то падает полнота данных.

Перед любым изменением достаточно проверить несколько вещей: как называется поле, в каком формате приходит дата, не меняется ли смысл расчета, не расширяется ли словарь и чем пусто отличается от нуля. Если этот короткий проход пропустить, даже аккуратная схема быстро становится источником споров о том, чьи цифры правильные.

Когда лучше добавить новое поле

Новое поле стоит добавлять не тогда, когда старое название кажется неудачным. Его стоит добавлять тогда, когда меняется смысл данных. Если вчера поле описывало один бизнес-факт, а сегодня вы хотите положить туда другой, простое переименование почти всегда ломает логику отчетов.

Допустим, поле source сначала означало источник документа, а потом команда решила хранить в нем канал получения клиента. Название похоже, но смысл уже другой. В такой ситуации безопаснее ввести новое поле и оставить старое как есть.

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

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

Здесь обычно есть два безопасных пути:

• оставить старый словарь неизменным для старого поля
• завести новое поле или новую версию поля для расширенной логики

Это особенно важно, если старые группы участвуют в SLA, бонусах, лимитах или регуляторной отчетности. Молчаливое расширение словаря потом всплывает в самый неприятный момент.

Нужно заранее договориться, что команда считает новым объектом, а что - новой версией того же объекта. Если изменилась сущность, уровень детализации или бизнес-смысл, это новый объект и ему нужно отдельное поле. Если вы лишь исправили нормализацию, формат даты или способ извлечения без смены смысла, чаще хватает новой версии.

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

Как вносить изменения по шагам

Любое изменение схемы лучше вести как маленький релиз, а не как правку "по пути". Если команда меняет поле в ETL, а аналитики узнают об этом из сломанного дашборда, проблема уже случилась.

Рабочий порядок обычно такой:

1. Составьте список всего, что затронет изменение: поля, словари, витрины, отчеты и алерты.
2. Коротко запишите, что именно меняется: имя поля, тип, формат даты, смысл значения или набор статусов.
3. До релиза присвойте версию схеме и, если нужно, отдельную версию словарю.
4. Подготовьте таблицу соответствий между старыми и новыми значениями и прогоните расчеты на одной и той же выборке.
5. Сразу назначьте дату, после которой старое поле перестанет жить, и зафиксируйте это для всех команд.

Первый шаг многие пропускают. Зря. Даже маленькая правка вроде status -> order_status часто цепляет выгрузки в BI, правила сегментации, ручные Excel-отчеты и API, из которого данные берет соседняя команда.

Дальше нужна короткая карточка изменения. Без длинных описаний. Достаточно ответить на четыре вопроса: что было, что станет, почему это меняют и какие расчеты могут поехать. Если поле меняет не только имя, но и смысл, это уже не переименование. Это новое поле, и относиться к нему нужно строже.

Версия схемы до релиза экономит много времени в спорных местах. То же касается словаря. Если сегодня статус заказа имеет пять значений, а завтра вы делите один статус на два, аналитикам нужна явная отметка, с какой версией словаря они работают.

Пока старое и новое живут рядом, между ними должна быть прозрачная таблица соответствий. Например:

• approved -> accepted
• pending_manual_review -> review
• done -> completed

После этого возьмите одну и ту же выборку, например последние 30 дней, и посчитайте старые и новые метрики рядом. Смотрите не только на общий итог, но и на срезы по датам, каналам и сегментам. Часто расхождение видно не в сумме, а в одном узком куске данных.

В командах, где LLM извлекает поля из документов или диалогов, этот шаг особенно полезен. Новая версия промпта или словаря может дать лучший результат на ручной проверке, но сломать привычную группировку в отчетах. На тестовой выборке это видно сразу.

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

Какие правила стоит принять заранее

Беспорядок обычно появляется не после крупной миграции, а после десятка мелких правок. Один человек переименовал поле, другой заменил словарь значений, третий не предупредил команду, что старое значение больше не приходит. Так спор о цифрах возникает почти из ничего.

Поэтому у схемы должен быть один источник правды. Держите реестр полей в одном месте: в общей документации, каталоге данных или таблице, к которой у команды есть постоянный доступ. В реестре нужны не только названия, но и тип поля, допустимые значения, дата изменения, текущий статус и версия. Если поле устарело, это должно быть видно сразу, а не всплывать случайно в старом дашборде.

С именами лучше не умничать. Короткие сокращения кажутся удобными только в день, когда вы их придумали. Через пару месяцев stat_cd или src_tp уже требуют расшифровки. Понятное имя вроде document_status или source_type занимает на пару символов больше, зато не ломает чтение SQL и не заставляет людей гадать.

У каждого поля должно быть описание смысла, а не только формата. Запись "string, nullable" почти ничего не дает. Нужна короткая расшифровка: что именно хранит поле, откуда оно берется, когда оно заполняется и какие значения считаются нормальными. Полезно добавить два-три примера. Если вы извлекаете данные из LLM-ответов, примеры особенно нужны: модель может вернуть похожие по виду, но разные по смыслу значения.

Нужен и владелец схемы. Не комитет из десяти человек, а конкретный человек или небольшая группа, которая согласует спорные правки. Иначе любое изменение полей и словарей проходит по принципу "я так вижу", а последствия разбирает аналитика. Владелец схемы не тормозит работу. Он просто проверяет, не ломает ли новая версия контракт данных и совместимость отчетов.

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

Пример со статусом и словарем

Выглядит как мелочь: вчера поле status хранило три значения - новый, в работе, готов. Сегодня команда добавила еще одно - на проверке. Для продукта это нормальный шаг, а для аналитики именно так и начинается тихая поломка.

Старый отчет по воронке знает только прежний словарь. Если он жестко ожидает три значения, то записи со статусом на проверке могут просто исчезнуть из выборки. В итоге сумма по этапам уже не равна общему числу заявок, а команда спорит, где пропали строки.

Представим простой день: пришло 100 заявок. Из них 25 имеют статус новый, 40 - в работе, 20 - на проверке, 15 - готов. Новый операционный отчет показывает все четыре статуса, и это правильно. Но старый отчет по воронке строился под прежнюю модель и должен сохранить старую логику группировки.

Здесь помогает не переписывание всех отчетов сразу, а таблица соответствий. Она хранит не только исходное значение, но и отчетную группу, в которую его нужно отнести.

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

Новый отчет может работать иначе. Он уже показывает полную детализацию и отдельно выводит на проверке, потому что этот статус важен для текущего процесса. Оба отчета могут жить рядом, если у них есть явный контракт:

• сырое значение хранится как есть
• отчетная группа задается отдельно
• правила соответствия версионируются

В этом и состоит нормальная эволюция схемы. Вы не прячете новое значение и не ломаете старые расчеты. Вы отделяете бизнес-реальность от способа, которым старые отчеты ее агрегируют.

Если делать так каждый раз при изменении словаря, спор о "потерянных" строках обычно заканчивается за пять минут: все видят и исходный статус, и группу, в которую он попал.

Как сохранить старые отчеты рабочими

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

Если поле меняет смысл или имя, не убирайте старое название сразу. Оставьте его как алиас и привяжите к новой структуре через явное правило. Например, если вместо status появились status_code и status_reason, старый status можно временно собирать из нового словаря, чтобы отчеты по группировке статусов продолжали считаться так же, как раньше.

Версионирование схемы тоже лучше делать явно. Поднимайте версию набора данных, а не правьте схему тихо в том же потоке. Тогда аналитик видит, что работает с dataset_v1 или dataset_v2, а не пытается угадать, почему вчерашний запрос дает другой результат. Это обычная дисциплина, а не лишняя бюрократия.

Что стоит заморозить на время перехода

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

Еще одна здравая мера - заранее зафиксировать срок, пока старая версия поддерживается. Обычно этого хватает, чтобы команды перевели дашборды, проверки и выгрузки на новую схему без спешки.

Что сверять после релиза

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

Рост unknown, other или пустых категорий нужно ловить в первый же день. Часто это первый сигнал, что новый словарь не покрыл часть старых значений или извлечение начало возвращать неожиданный код.

Если у команды есть контракт данных, такие правила лучше прописать прямо в нем: когда появляется новая версия, сколько живет старая и какие проверки обязательны перед отключением алиаса. Тогда совместимость отчетов держится не на памяти отдельных людей, а на понятном процессе.

Ошибки, из-за которых цифры расходятся

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

Самая частая ошибка проста: поле переименовали и решили, что это техническая мелочь. Например, было status, стало document_status. Разработчики обновили пайплайн, но аналитики не поменяли запросы, и часть строк начала приходить как null. На графике это выглядит как резкое падение или всплеск, хотя в бизнесе ничего не изменилось.

Не менее опасно менять смысл значения и оставлять старое название. Вчера approved значило "документ проверен оператором", а сегодня оно значит "документ прошел автоматическую проверку". Название то же, отчет тот же, но метрика уже про другой этап процесса. Такие ошибки живут долго, потому что на первый взгляд все сходится.

Отдельная боль - когда в одной колонке смешивают null, пустую строку и 0. Для одного запроса это три разных состояния: нет данных, пришло пустое значение и есть числовой результат ноль. Для другого запроса это может слиться в одну группу. В итоге один отчет показывает 12% пропусков, а другой - 3%, хотя оба смотрят в одну таблицу.

Словари тоже часто расходятся тихо. Команда обновила список статусов в сервисе извлечения, добавила in_review, а справочник в DWH или BI никто не тронул. Новое значение либо падает в "прочее", либо вообще не попадает в агрегацию. Это типичный сценарий для систем, где несколько сервисов обрабатывают LLM-извлечение и каждый хранит свой набор допустимых значений.

Перед выпуском изменений полезно пройти короткий список:

• какие поля переименовали, удалили или добавили
• изменился ли смысл старых значений
• одинаково ли трактуются null, пустая строка и 0
• обновились ли словари и справочники во всех слоях
• совпадают ли агрегаты до и после релиза

Последний пункт часто пропускают. Команда смотрит две-три записи вручную, убеждается, что JSON выглядит нормально, и выкатывает релиз. Но несколько правильных примеров ничего не доказывают. Сверять нужно суммы и распределения: число записей по дням, долю пустых значений, количество объектов в каждом статусе, медиану по сумме или сроку. Если после изменения поле стало лучше на ручной проверке, а недельный итог внезапно просел на 18%, проблема почти всегда в контракте данных, а не в бизнесе.

Быстрая проверка и следующие шаги

Перед любым изменением схемы полезно остановиться на короткой проверке. Она занимает меньше часа, зато потом не приходится неделю разбирать, почему новый отчет не сходится со старым.

Проверьте пять вещей:

• у схемы есть явная версия и дата, с которой она начинает работать в проде
• для каждого измененного словаря есть таблица соответствий между старым и новым значением
• старые отчеты уже прогнали на контрольной выборке и сравнили цифры до и после изменения
• команда знает точную дату, когда старые поля перестанут поддерживаться
• если структуру заполняет LLM, контракт данных живет отдельно от выбора модели

Последний пункт часто упускают. Модель может поменять стиль ответа, порядок полей или назвать статус чуть иначе. Если контракт данных описан отдельно, вы меняете парсер и проверки один раз, а не переписываете пол-аналитики при каждой замене модели.

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

Если вы тестируете извлечение через разные LLM, не смешивайте эксперимент с изменением формата. Сначала зафиксируйте контракт, потом сравнивайте модели внутри одного и того же набора полей. В этом смысле AI Router удобен для команды, которая хочет прогонять один и тот же сценарий через разные модели через один OpenAI-совместимый эндпоинт и не менять интеграцию. Но формат результата все равно должен задавать ваш контракт данных, а не сама модель.

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