Что сравнить после переноса данных: период, число записей и ключевые итоги, чтобы не принять успешную загрузку за верный отчёт.
Почему успешная загрузка не гарантия
Сообщение «загрузка завершена» обычно означает, что технический шаг отработал без обнаруженной ошибки. Оно не доказывает, что в итоговом отчёте оказались все нужные заказы. Часть записей могла прийти позже, попасть в другой период или исчезнуть из-за неожиданного правила отбора. Пользователь видит красивую таблицу и может принять решение по неполному набору. Поэтому после переноса нужен отдельный вопрос: совпадает ли результат с тем, что должно было попасть в отчёт?
Google SRE описывает случаи, когда отдельные этапы обработки считают свою работу правильной, но сведения теряются между ними. Проверка только статуса этапов не обнаружит такое расхождение. Сверка источника и итога помогает увидеть проблему с точки зрения читателя отчёта.
Что именно сравнивать
Начните с границ: один и тот же период, одинаковое правило включения записей и понятный момент обновления. Затем сравните число строк или уникальных событий там, где это имеет смысл. Добавьте контрольный итог — например, общую сумму заказов до и после переноса. Один показатель недостаточен: число строк может совпасть, хотя часть заказов исчезла, а вместо неё появились дубли. Сумма тоже может случайно совпасть при нескольких компенсирующих ошибках.
Сравнение должно учитывать преобразования. Если итоговый отчёт объединяет несколько строк одного заказа, простое равенство числа строк ошибочно. Тогда сравнивают число уникальных заказов и сумму по согласованному признаку. Обязательно записывают, какие исключения допустимы: отменённые операции, незавершённые записи и запаздывающие события.
Условный пример с заказами
Допустим, источник содержит за вчера 120 подтверждённых заказов. В отчёте отображается 118. Разница в два заказа сама по себе не говорит о поломке: один мог быть отменён, другой поступил после закрытия периода. Но без объяснения считать отчёт проверенным нельзя. Команда прослеживает идентификаторы отсутствующих заказов и выясняет, на каком шаге их исключили. Если исключение соответствует правилу, его документируют; если нет — исправляют перенос или отчёт.
После исправления стоит повторить сверку за тот же период и проверить соседние дни. Иначе можно убрать видимое расхождение за вчера, оставив ту же ошибку на более раннем интервале. Если загрузка успешна, а вывод всё равно неверен, пригодится материал о диагностике неверного отчёта.
Почему сравнение бывает нечестным
Два источника могут фиксировать время по-разному. Один считает заказ по моменту оплаты, другой — по моменту создания. Один обновляется каждые несколько минут, другой формирует итог ночью. При таком различии честная сверка возможна только после согласования времени и значения показателя. Сначала формулируют одинаковый вопрос обеим сторонам, затем сравнивают ответы.
Отдельная ловушка — группировка. Если отчёт показывает по одной строке на город, а источник хранит каждую покупку отдельно, одинакового числа строк ожидать не следует. Нужно сравнить итог для каждого города и общий итог. Как исходные строки превращаются в группы, объясняется в статье о группировке данных. Документация Azure Data Factory также показывает, почему при частичной загрузке важна сохранённая граница уже перенесённого периода.
Кто разбирает расхождение
Когда проверка обнаружила разницу, нужно сохранить её численное значение, период, время запуска и несколько примеров записей. Инженер данных выясняет, на каком переходе она появилась; владелец показателя решает, допустимо ли различие по смыслу. Отчёт нельзя тихо объявлять верным только потому, что система не показала ошибку. Если решение срочное, пользователю лучше явно сообщить, что итог ещё проверяется.
Сверка источника и отчёта — узкая, но важная часть надёжного процесса. Она не заменяет проверку каждого поля и всех бизнес-правил. Если интересна работа с такими задачами, программа «Data Engineer для начинающих» поможет оценить направление обучения.
