Как проверить целостность данных после миграции из облачного сервиса — 4 способа

Почему данные повреждаются при миграции между облачными сервисами

Мы неоднократно сталкивались с ситуациями, когда клиент завершает перенос, радуется скорости, а через неделю обнаруживает, что 12 000 записей в таблице заказов потеряли значение в поле created_at, или что вложенные JSON-структуры обрезались на уровне вложенности выше трёх. Миграция между облачными сервисами — это не просто копирование файлов. Это трансформация схем, конвертация типов данных, перекодировка символов и пересборка связей между таблицами. И на каждом из этих этапов возможны потери.

Типичные причины повреждений:

1. Несовместимость типов данных. PostgreSQL хранит timestamp с микросекундами, MySQL — без них при стандартных настройках. При переносе из одного сервиса в другой дробная часть может отбрасываться, и вы получите миллионы записей с округлённым временем.

2. Обрезка строковых полей. Облачные платформы устанавливают разные лимиты на длину VARCHAR. Если целевой сервис допускает максимум 255 символов, а исходный — 10 000, длинные записи будут усечены без предупреждения.

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

4. Разрыв внешних ключей. Если в исходной базе есть связь orders.user_id → users.id, а при миграции таблица пользователей переносится после таблицы заказов, ссылки окажутся висеть в воздухе.

5. Проблемы с кодировкой и локализацией. Дата в формате DD.MM.YYYY при автоматическом распознавании интерпретируется как MM.DD.YYYY, если целевой сервис ориентирован на американский формат.

По данным отчёта Gartner за 2024 год, 83% миграций данных между облачными сервисами сопровождаются хотя бы одним инцидентом потери или искажения данных, при этом среднее время обнаружения проблемы составляет 11 рабочих дней.

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

4 способа проверки целостности: от ручного сравнения до автоматических скриптов

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

Способ 1. Сверка контрольных сумм (хешей)

Это самый быстрый способ убедиться, что данные не изменились. Суть: вы вычисляете хеш-сумму (например, SHA-256) для каждого важного столбца или целой таблицы в источнике и в приёмнике, а затем сравниваете результаты.

Как выполнить:

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

SELECT MD5(ROW(t.*)::text) FROM orders t ORDER BY id;

2. Экспортируйте результат в CSV-файл.

3. Повторите тот же запрос в целевом сервисе.

4. Сравните два файла с помощью утилиты diff или скрипта на Python.

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

Когда применять: после каждой партии перенесённых данных, особенно если объём превышает 1 ГБ.

Способ 2. SQL-запросы для подсчёта и сверки записей

Контрольная сумма подтверждает, что данные не изменились, но не говорит, сколько именно записей перенеслось. SQL-запросы закрывают эту задачу.

Что проверять:

1. Количество записей в каждой таблице — SELECT COUNT(*) FROM <table> в обоих сервисах.

2. Количество уникальных значений в ключевых столбцах — SELECT COUNT(DISTINCT user_id) FROM orders.

3. Диапазоны значений — SELECT MIN(id), MAX(id) FROM orders — чтобы убедиться, что не потеряны ни первые, ни последние записи.

4. Распределение по датам — SELECT DATE(created_at), COUNT(*) FROM orders GROUP BY 1 — для выявления пропущенных временных периодов.

Когда применять: сразу после завершения миграции каждой таблицы. Занимает от 30 секунд до 5 минут в зависимости от размера базы.

Способ 3. Выборочная ручная проверка ключевых полей

Автоматика не видит логических ошибок. Если при миграции поле phone попало в столбец email, ни хеш, ни подсчёт записей не покажут проблему — количество совпадает, формат валиден, но данные на месте.

Что делать:

1. Выберите 20–50 случайных записей из каждой критичной таблицы (используйте ORDER BY RANDOM() LIMIT 50).

2. Откройте каждую запись в обоих сервисах и визуально сравните 5–7 ключевых полей.

3. Обратите внимание на форматы дат, десятичные разделители, направление текста и нулевые значения.

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

Способ 4. Автоматические скрипты-валидаторы

Для повторяющихся миграций или больших объёмов (от 100 ГБ) ручная проверка нерациональна. Мы рекомендуем писать скрипт, который автоматически проходит все три предыдущих уровня.

Пример структуры валидатора на Python:

import hashlib, psycopg2, json
def compare_tables(source_conn, target_conn, table, key_column):
# 1. COUNT
src_count = execute(source_conn, f"SELECT COUNT(*) FROM {table}")
tgt_count = execute(target_conn, f"SELECT COUNT(*) FROM {table}")
assert src_count == tgt_count, f"Count mismatch: {src_count} vs {tgt_count}"
# 2. HASH
src_hash = execute(source_conn, f"SELECT MD5(ROW(t.*)::text) FROM {table} t ORDER BY {key_column}")
tgt_hash = execute(target_conn, f"SELECT MD5(ROW(t.*)::text) FROM {table} t ORDER BY {key_column}")
assert src_hash == tgt_hash, "Hash mismatch detected"
# 3. SAMPLE
sample = execute(source_conn, f"SELECT * FROM {table} ORDER BY RANDOM() LIMIT 30")
for row in sample:
assert row_exists(target_conn, table, row), f"Missing row: {row[key_column]}"

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

Таблица проверки: какой метод выбрать по типу данных и объёму

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

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

Риски: что можно пропустить даже при тщательной проверке

Даже при применении всех четырёх методов остаются слепые зоны. Мы собрали наиболее частые ловушки, с которыми сталкивались на практике.

1. Индексы и первичные ключи. Данные на месте, но индексы не пересозданы. Запросы работают, но в 50–200 раз медленнее. Проверьте план выполнения запросов (EXPLAIN ANALYZE) в целевом сервисе после миграции.

2. Хранимые процедуры и триггеры. При переносе через стандартные инструменты экспорта/импорта хранимые процедуры часто не мигрируют. В PostgreSQL 16 и старше используйте pg_dump с флагом --section=pre-data --section=post-data.

3. Нулевые значения vs NULL. Многие сервисы конвертируют пустые строки в NULL и наоборот. Это не ошибка в привычном смысле, но может сломать бизнес-логику, если приложение различает состояния.

4. Часовые пояса. Записи с TIMESTAMP WITH TIME ZONE при миграции в сервис без поддержки таймзон могут быть конвертированы в локальное время сервера. Разница в 3 часа не будет заметна при подсчёте записей, но исказит аналитику.

5. Вложенные и полуструктурированные данные. JSONB-столбцы, массивы, типы — всё это может быть сериализовано в строку при миграции и десериализовано обратно с потерей типизации.

Рекомендация: после завершения проверки сохраните логи сравнения и хеш-суммы. В случае судебного или аудиторского разбирательства (особенно по 152-ФЗ) это станет доказательством надлежащей Due Diligence.

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

Чек-лист проверки после миграции данных

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

1. Экспорт хешей из источника. Запустите запрос на вычисление MD5 или SHA-256 для каждой таблицы. Сохраните результат в файл с датой и меткой среды.

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

3. Подсчёт записей. Выполните COUNT(*) для каждой таблицы в обоих сервисах. Зафиксируйте результаты.

4. Сравнение хешей. Сверьте экспортированные хеш-суммы с вычисленными в целевом сервисе. Любое расхождение — сигнал к детальной проверке.

5. Проверка диапазонов. Сравните MIN и MAX значений первичных ключей и временных меток.

6. Распределение по категориям. Выполните группировку по ключевым полям (статус, категория, регион) и сравните профили.

7. Выборочная ручная сверка. Откройте 30–50 случайных записей и проверьте 5–7 полей визуально.

8. Проверка связей. Убедитесь, что внешние ключи ссылаются на существующие записи. Запрос: SELECT COUNT(*) FROM orders o LEFT JOIN users u ON o.user_id = u.id WHERE u.id IS NULL.

9. Тестирование бизнес-логики. Запустите ключевые отчёты и дашборды. Сравните цифры с отчётами из исходного сервиса за тот же период.

10. Проверка индексов. Выполните EXPLAIN ANALYZE для 5–10 типичных запросов. Убедитесь, что время выполнения не выросло более чем на 20%.

11. Валидация форматов. Проверьте, что даты, числа и строки отображаются корректно. Особое внимание — десятичные разделители и форматы дат.

12. Финальный отчёт. Составьте документ с результатами проверки: таблица «источник vs приёмник» по каждой метрике, список обнаруженных расхождений и статус их устранения.