Пропуски возникают, когда обязательное значение отсутствует или заполнено формально. Частый кейс — поле не пустое, но там пробел или «0», которые не несут смысла. Такие записи искажают агрегаты и требуют обработки или исключения из аналитики.

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

Ошибки заполнения
Ошибки заполнения связаны с некорректным вводом данных. Типовая ситуация — документ привязан к неправильному контрагенту, хотя другие поля указывают на другое лицо или организацию. Формально запись выглядит «валидной»: поля заполнены, типы совпадают. Но логика неверная.

Такие ошибки часто выявляют через дополнительные признаки. Пример: контрагент в документе один, а телефон или ИНН соответствует другому. Значит, данные надо проверить и исправить по правилу, которое вы заранее согласовали с бизнесом.

Валидация и стандартизация
Валидация проверяет формат значений. Пример с телефоном самый простой: в одной системе номер записывают «+7 (999) 111-22-33», в другой — «9991112233», в третьей — «8-999-111-22-33», а где-то ещё встречаются буквы или лишние символы. Формально это «телефон», но сопоставить такие значения нельзя.

Здесь важно разделить два действия:

• проверка формата (валидно/невалидно);
• приведение к стандарту (единый формат хранения).

Логические связи и структура данных
Проблемы возникают при нарушении связей между справочниками и документами. Записи могут ссылаться на несуществующие объекты или устаревшие значения. В результате аналитика начинает считать «мусорные» сущности как реальные.

Ещё одна частая проблема — структура данных. Для аналитики нужны плоские таблицы. Сводные и иерархические структуры, которые приходят из файлов и выгрузок, не подходят для расчётов. Их сначала разворачивают: делают «плоскую» таблицу, где каждая строка — одна сущность/событие, а поля — её атрибуты.

Подходы к очистке данных

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

• просматривают выборки и находят явные пропуски;
• убирают очевидные дубли;
• проверяют заполнение ключевых полей;
• сверяют значения с допустимыми диапазонами.

Плюс ручной очистки — скорость на маленьком объёме и понятная диагностика. Минус — результат зависит от человека и не воспроизводится. При повторной загрузке данные приходят снова, и всё приходится делать заново.

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

• сложные проверки связей;
• нетипичные преобразования форматов;
• объединение наборов данных по нестандартным ключам;
• обработку «грязных» файлов, где смешаны типы и символы.

Риск скриптов не в том, что «скрипты плохие», а в сопровождении. Без документации и контроля версий со временем сложно понять, почему скрипт делает именно так, и что изменилось от релиза к релизу.

Автоматизированная очистка данных
Автоматизированную очистку используют при регулярной загрузке и больших объёмах данных. Её встраивают в ETL-процесс и задают правила, которые срабатывают при каждой загрузке.
В экосистеме Denvic Tools автоматизированная очистка реализуется через Denvic Visual Transformer (DVT). Инструмент применяют для:

• проверки форматов и типов значений;
• стандартизации (приведения к единому виду);
• фильтрации строк по условиям качества;
• удаления дублей по правилам;
• преобразования структуры данных (pivot/unpivot) для получения плоских таблиц.

Практические ограничения и риски

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

Отдельная сложность — исторические данные. Меняются справочники, структура, правила заполнения. Старые данные начинают конфликтовать с текущими правилами обработки. Если это не учитывать, очистка превращается в бесконечную «погоню за отклонениями».
Ещё один источник проблем — файлы. В них часто встречаются скрытые символы, пробелы, смешанные типы и нестабильные форматы. Визуально всё выглядит нормально, но при обработке начинают «сыпаться» типы, значения и связи.

Этапы работы с данными

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

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

2) Формирование сырого слоя данных.
Извлечённые данные сохраняют в сыром виде. На этом шаге не применяют бизнес-правила и не выполняют очистку. Сырой слой нужен как «точка опоры» для диагностики и повторной обработки.

3) Анализ качества данных.
Проверяют заполненность, форматы, типы, выбросы, нетипичные значения. Здесь же выявляют поля, которые в текущем состоянии нельзя использовать в аналитике.

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

5) Очистка и стандартизация.
Применяют правила в ETL-процессе. На этом шаге данные приводят к единому виду: чистят значения, выравнивают форматы, приводят структуру к плоской таблице, подготавливают ключи и справочники.

6) Загрузка в витрины и отчёты.
Только после очистки данные используют в витринах и отчётности. Если пропустить предыдущие шаги, аналитика начинает «ехать», а проверки превращаются в ручной контроль после факта.