← Все курсы · Все руководства · Серия «Миграция данных»

Этап 2. Профилирование источника

Этап 2 из 8 · Узнайте, что там на самом деле, прежде чем обещать даты · Часть Analyst Prep Kit

К Майкл Носито, аналитик данных · Опубликовано 30 июля 2026 г.

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

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

Почему это отдельная сцена

Как вы думаете, в чем разница между профилированием и очисткой? Ответьте, прежде чем читать дальше.

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

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

Семь проверок

Запустите их для каждой таблицы. Все они представляют собой несколько строк SQL, и большинство из них представляют собой СЧИТАТЬ с помощью GROUP BY.

1. Количество строк. Сколько строк в каждой таблице. Запишите их. Все, что вы делаете позже, сравнивается с этим числом, и это базовый уровень для Примирение.

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

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

4. Дубликаты на идентификационном поле. Группируйте по тому, что должно быть уникальным, и учитывайте все, что появляется более одного раза. Это первый взгляд на работу по дедупликации.

5. Сироты. Дети без родителей. Документы без клиента, визиты без сотрудника. Их находит левое соединение, где правая часть равна нулю.

6. Форматы. Даты, номера телефонов, идентификаторы. Посмотрите на фактические строки, а не на тип столбца. Столбец даты, хранящийся в виде текста, будет содержать как минимум три формата и как минимум одну невозможную дату.

7. Диапазоны и выбросы. Минимум и максимум на каждую дату и число. Там указаны дата рождения в 1899 году и дата посещения в 2087 году, и оба будут отклонены загрузчиком в самый неподходящий момент.

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

Превращение результатов в решения

Находка, которая останется в ваших заметках, ничего не стоит. Каждый становится ровно одной из трех вещей.

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

Решение по объему. Исправление требует, чтобы человек что-то решил. Четыреста текстовых статусов, объединенных в шесть, означают, что кто-то должен сказать, что есть что, и что кто-то является клиентом. Это решение с указанием даты.

Риск. На открытие может потребоваться время, но вы пока не можете этого сказать. Поместите это на план, назвав напротив него. Риск, который был в плане со второй недели, является обычным событием проекта. Тот же риск, о котором говорилось на восьмой неделе, — это провал.

Что чаще всего меняет план

Три вывода в порядке того, как часто они переносят дату.

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

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

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

Запишите это вот так

Этот стол — ворота. Он закрывается, когда у каждой строки есть владелец и дата, и отправляется клиенту как часть электронного письма с подведением итогов этапа.

Откуда это взялось

Модель процесса миграции, построенная Халлером, Маттесом и Шульцем, ставит этап анализа перед проектированием по той же причине, что и здесь: предполагается, что результаты должны служить основой для плана, но они не могут этого сделать, если они появятся после него. В более широкой литературе по качеству данных это рассматривается как пригодность для использования (от Ванга и Стронга). Данные не являются хорошими или плохими в абстрактном смысле. Этого достаточно для определенной цели, и целью здесь являются правила целевой системы.

Одна привычка

Никогда не обещайте дату, пока не посчитаете ряды. Счет дешевый, а обещание - нет.

Что самое худшее вы нашли в исходной системе, когда действительно посмотрели?

Ссылки

1. Халлер К., Маттес Ф. и Шульц К. (2012). Подробная модель процесса для крупномасштабных проектов миграции данных. Системы бизнес-информации (BIS 2012), Конспекты лекций по обработке бизнес-информации, 117. Спрингер.
2. Ван, Р.Ю., и Стронг, Д.М. (1996). За пределами точности: что качество данных означает для потребителей данных. Журнал информационных систем управления, 12(4), 5–33.