Миграция данных, OLTP и OLAP

Миграция данных и различие OLTP и OLAP — темы, на которых видно, работал ли кандидат на реальном внедрении.

OLTP — системы для операций: много коротких транзакций, запись и чтение отдельных записей. OLAP — системы для анализа: тяжёлые запросы по большим объёмам, агрегаты и срезы.

Вопрос 1. Чем OLTP отличается от OLAP и зачем разделять?

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

Признак	OLTP	OLAP
Типичный запрос	прочитать/изменить одну-две записи	агрегат по миллионам строк
Модель данных	нормализованная	звезда или снежинка, денормализованная
Объём за запрос	байты и килобайты	гигабайты
Свежесть данных	реальное время	обычно с задержкой: час, сутки
Пользователи	тысячи одновременно	десятки аналитиков
Метрика качества	время отклика транзакции	время построения отчёта
Хранение	построчное	чаще колоночное

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

Схема «звезда» в двух словах

Аналитические витрины строят вокруг таблицы фактов (события: продажа, отгрузка) с измерениями (справочники: товар, клиент, дата, регион). Такая структура специально денормализована, чтобы отчёт собирался минимальным числом соединений.

        dim_date         dim_customer
             \                /
              \              /
            [ fact_sales ]  ← факты: сумма, количество, скидка
              /              \
             /                \
        dim_product        dim_region

Факт = измеримое событие с числовыми показателями.
Измерение = «в разрезе чего» смотрим: по дате, товару, региону.

Вопрос 2. Как вы планируете миграцию данных из старой системы?

Что проверяют. Это вопрос уровня middle+ и он про дисциплину. Ждут план по этапам и — обязательно — про сверку и откат.

Инвентаризация и профилирование. Какие сущности переносим, сколько записей, какое качество данных: дубли, пустые обязательные поля, битые ссылки, разные форматы телефонов и дат. Профилирование делают до оценки сроков, иначе оценка будет неверной в разы.
Правила преобразования (mapping). Таблица «поле-источник → поле-приёмник → правило преобразования → что делать с исключениями». Это главный документ аналитика на миграции.
Правила очистки. Что считаем дублем и как схлопываем, чем заполняем пропуски, что делаем с записями, которые не проходят валидацию: отбрасываем, переносим в карантин или чиним вручную.
Пробные прогоны на копии. Минимум два-три, с замером времени: сколько займёт миграция в окне простоя.
Сверка. Контрольные суммы: число записей по каждой сущности, суммы по деньгам, контрольные выборки для ручной проверки. Критерии приёмки миграции формулируются заранее в цифрах.
План отката. Что делаем, если после переключения выяснилось, что данные битые: как быстро вернуться на старую систему и до какого момента это возможно.
Стратегия переключения. Разом в окно простоя или параллельная работа двух систем с последующей досинхронизацией.

Фрагмент карты преобразования (mapping)

Источник               Приёмник           Правило
────────────────────── ────────────────── ─────────────────────────────
CLIENT.FIO (одно поле) customer.last_name  разбор по пробелам:
                       customer.first_name первое слово → фамилия,
                       customer.middle_name второе → имя, третье → отчество
                                            если слов < 2 → карантин
CLIENT.PHONE           customer.phone      нормализация к +7XXXXXXXXXX,
                                            невалидные → NULL + флаг
CLIENT.BIRTH (текст)   customer.birth_date парсинг ДД.ММ.ГГГГ;
                                            «00.00.0000» → NULL
CLIENT.STATUS 'A'/'B'  customer.status     A → active, B → blocked,
                                            иное → карантин

Критерии приёмки:
• число клиентов в приёмнике = число в источнике минус карантин
• сумма задолженности совпадает до копейки
• 50 случайных карточек проверены вручную

Вопрос 3. Что такое ETL и чем он отличается от ELT?

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

Типичные ошибки кандидатов

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

Как ответить кратко

OLTP — короткие транзакции по отдельным записям на нормализованной модели, OLAP — тяжёлые агрегаты по большим объёмам на денормализованной звезде, обычно с лагом в час или сутки. Разделяют, чтобы отчёты не мешали работе боевой системы; вместе с бизнесом заранее договариваюсь о допустимой свежести данных. Миграцию планирую по шагам: профилирование качества данных до оценки сроков, карта преобразования полей с правилами и карантином, правила очистки и дедупликации, два-три пробных прогона с замером времени, сверка по контрольным суммам и ручной выборке, план отката и стратегия переключения. Критерии приёмки формулирую в цифрах заранее.