AI-міграція даних: де ламається автоматичне перенесення
Під час перенесення облікових даних між системами відмова рідко надходить із сховища — база прийме будь-який коректний набір рядків. Ламається смислова частина: зіставлення сутностей старої та нової моделі.
Якщо у джерелі клієнт — це юридична особа з розрахунковим рахунком, а в приймачі — контактна особа, автоматичне зіставлення за назвою полів дасть правдоподібний, але хибний результат.
Перше вузьке місце — розбіжність довідників. Класифікатори, одиниці вимірювання, статуси та категорії у двох системах майже завжди різної потужності: у джерелі кілька сотень значень, у приймачі — десятки, частина кодів застаріла, частина заведена вручну.
Зіставлення за схожістю рядка помиляється на близьких формулюваннях, а неправильно перенесений статус облікового запису тихо змінює права доступу.
Друге — обрив зв’язків записів. Перенесення йде таблицями, а посилання між ними тримаються на ідентифікаторах: якщо договір приїхав раніше за контрагента або отримав новий ключ, зв’язки розсипаються.
У приймачі з’являються записи-сироти — платежі без рахунків, заявки без клієнтів, нарахування без договорів.
Третє — ручні правки під час перенесення. Їх роблять у проміжній таблиці «нашвидкуруч», поза регламентом: результат не відтворюється, а під час наступного завантаження правки затираються. Розбираємо, як кожне з цих місць закривається.
Що змінюється після переходу на автоматичне перенесення
Ключова зміна — правила перенесення перестають жити в листуванні та вкладених таблицях.
Зіставлення полів, нормалізація довідників, розбір порожніх і конфліктних значень описуються як конфігурація в репозиторії: одна гілка — одне джерело правди, будь-яка зміна проходить перевірку, а не приїжджає «правкою в останньому файлі».
Частину перетворень зручно тримати на dbt — тоді реєстр правил, тести й опис полів лежать поруч і читаються як один документ.
Із цього виростає повторюваність прогону. Один і той самий набір правил на одному й тому самому зрізі даних дає один і той самий результат: запуск ідемпотентний, повторний прохід не плодить дублі та не дописує записи заднім числом.
З’являється робоча схема — прогнати перенесення на копії, порівняти вивантаження, зафіксувати розбіжності й лише після цього йти в продуктивний контур.
Частка ручних правок падає не тому, що правила «розумніші», а тому що вони застосовуються до всіх записів однаково. Залишок ручної роботи перетворюється на короткий список винятків із причиною: неоднозначний довідник, розірваний зв’язок, відсутнє джерело.
Такий список видно повністю, і він не зростає від прогону до прогону — це і є вимірюваний контроль якості перенесення.
Автоматична верифікація закриває останній розрив: звірка кількості рядків і контрольних сум за ключовими полями, перевірки на втрачені зв’язки, звіт щодо розбіжностей до і після.
Замість «перенесли, начебто все на місці» — відтворюваний протокол кожного запуску, за яким видно, що саме пройшло, що пішло у винятки й які правила до цього призвели.
Способи міграції: потокове перенесення та пакетне завантаження
Вибір режиму визначають дві речі: наскільки критичний простій і як влаштоване навантаження на джерело. Потокове перенесення читає журнал змін і віддає кожну транзакцію отримувачу майже одразу — джерело продовжує приймати запис, вікна обслуговування не потрібні.
Пакетне завантаження працює узгодженими знімками за розкладом: простіше у відлагодженні та повторному запуску, але потребує вікна, у якому запис у джерело зупинено.
Між цими крайнощами майже завжди стоїть гібридна схема — вона й закриває основний сценарій переїзду. Нижче порівняння за застосовністю та обмеженнями.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Потокове перенесення за журналом змін | Джерело не можна зупиняти; дані потрібні в новому контурі з мінімальною затримкою | Потрібні права на читання журналу; за масового оновлення всієї таблиці потік відстає; відкат складніший |
| Пакетне завантаження знімками | Разова зміна платформи, звітний контур, простій допустимий у вікні обслуговування | Перенесення без простою неможливе: запис зупиняють на зняття знімка та добирання дельти |
| Знімок плюс потік змін | Переїзд працюючого контуру: знімок роблять заздалегідь, зміни накопичуються паралельно, перемикання займає хвилини | Точку старту потоку потрібно жорстко пов’язати зі знімком, інакше рядки розходяться |
Чим би не закінчилося перенесення, воно закривається не перемиканням, а покроковою звіркою: спочатку кількість рядків за кожною таблицею, потім контрольні суми, потім вибірка за ключами на межах діапазонів.
Розбіжності розбирають до переведення навантаження на новий контур — після перемикання шукати їх помітно дорожче.
Етапи впровадження: від розбору схеми до передачі в роботу
Кожен етап закінчується артефактом, який перевіряють до того, як наступний почне змінювати дані. Тому правила зіставлення й точку повернення готуємо заздалегідь — помилка міграції ловиться на зрізі, а не на бойовому контурі.
- Інвентаризація джерел. Обходимо бази, вивантаження облікових систем і таблиці у файлах, фіксуємо обсяги, формати, дублі та «брудні» поля. Результат — реєстр джерел із картою сутностей.
- Схема відповідності полів. Зіставляємо поля джерела та приймача, описуємо перетворення типів і довідники. Модель пропонує варіанти, спірні місця інженер затверджує з власником даних.
- Складання конвеєра перенесення. Налаштовуємо вилучення, нормалізацію, дедуплікацію та запис; правила версіонуються, щоб будь-яку зміну можна було пояснити й скасувати.
- Тестовий прогін. Прогоняємо потік на зрізі даних і рахуємо частку полів, зіставлених автоматично, та кількість розбіжностей. Звіт за ними — основа доналаштування правил.
- Приймання даних. Звіряємо контрольні суми й агрегати за ключовими сутностями, критичні записи перевіряємо вибірково вручну. Критерії фіксуємо до прогону, а не після.
- План відкату. Готуємо знімок приймача й точку повернення: якщо звірка не зійдеться, повертаємося до вихідного стану без втрати записів.
- Передача в роботу. Віддаємо регламент запуску, моніторинг розбіжностей і документацію за схемою — потік супроводжується вже без нашої участі.
Артефакти проєкту: що залишається в замовника після здачі
Здачею проєкту ми вважаємо не звіт про перенесення, а комплект матеріалів, з яким ваша команда далі працює сама. Усе, що використовували наші інженери, передається у вигляді, придатному для правки: конфігурації, схеми, журнали й документація.
- Конфігурації правил зіставлення — словники синонімів, пріоритети джерел, обробка неоднозначних випадків. Змінюються правкою файлів, без втручання в код.
- Схеми перенесення — яке джерело, у якому порядку та через які довідники проходить запис, де стоять точки обов’язкової звірки.
- Журнали перевірок — протоколи за кожною ділянкою: частка записів, що пройшли автоматично, що пішло на ручний розбір, які розбіжності залишилися відкритими.
- Регламент відкату — порядок повернення сховища до попереднього стану, умови запуску, точки контролю та відповідальні.
- Інструкції супроводу — як перезапустити ділянку перенесення, додати правило, підключити нове джерело, оновити модель зіставлення.
- Набір контрольних запитів і тестових вибірок — щоб повторно перевірити дані після будь-якої зміни правил.
Матеріали оновлюються під час робіт, а не пишуться перед здачею, тому до фіналу вже перевірені на реальних прогонах. Ви отримуєте не опис системи, а робочий комплект: за ним новий інженер входить у проєкт за дні, а не за місяці.
Кейс: перенесення довідників і залишків у нову систему
Дистриб’ютор переносив довідник номенклатури та складські залишки з історичної SAP у нову облікову систему. У контурі — 1,4 млн карток товару, 380 тис. рядків залишків за 42 складами та сім джерел, кожне зі своїми одиницями вимірювання, групами й кодами постачальників.
Перше перенесення робили вивантаженнями з ручною звіркою, і розбіжності спливали вже після закриття періоду — коли правити щось дорого.
Зіставлення за збігом артикула провалилося: у джерелах артикули писалися з різними розділювачами та без провідних нулів, через що 210 тис. позицій потребували рішення людини. Повний прогін займав близько 14 годин, а правка одного правила означала перезапуск цілком.
Що змінили
Нормалізацію поставили до порівняння: артикули, одиниці вимірювання та найменування приводяться до канонічної форми, і лише потім зіставляються за назвою та атрибутами з оцінкою впевненості.
Пари вище порога переносяться автоматично, решта потрапляє в чергу розбору з підсвічуванням відмінностей, а рішення аналітика записується й використовується повторно в наступних прогонах.
Результат у цифрах
Ручний розбір скоротився з 210 тис. записів до 11 тис. — 5% від обсягу. Повний прогін укладається в 38 хвилин, повторний після правок — у 7, бо перераховуються лише зачеплені гілки довідника.
Верифікація за контрольними сумами — кількість залишків за кожним складом і групою до та після перенесення — звела розбіжності до нуля на прийманні, а конфліктів мапінгу залишилося 0,4% проти 12% за першої спроби.
Чим відрізняється автоматичне зіставлення полів від ручного?
Автоматичне зіставлення спирається на два сигнали: структуру (тип, довжину, ім’я поля) і вміст — частку збіжних значень.
Кожній парі «джерело — приймач» присвоюється оцінка впевненості: точний збіг імен дає високу, нечіткий збіг за схожістю рядків і спільними значеннями довідника — проміжну.
Далі спрацьовує поріг впевненості. Вище верхнього порога пара застосовується автоматично, між порогами потрапляє до списку пропозицій, нижче — у карантин. Дворівнева схема не дає автоматиці мовчки зіпсувати дані й водночас не змушує розбирати все вручну.
Ручне зіставлення потрібне там, де сенс не виводиться з даних: одне поле в джерелі розкладено на два в приймачі, відрізняються одиниці вимірювання, ключ складений, а в 1С накопичилися історичні дублі номенклатури, які треба згорнути до перенесення.
Експертна перевірка — це не суцільна звірка, а розбір карантину плюс підтвердження вибірки з автозастосованих пар.
Частка ручного розбору стає робочою метрикою: вона падає з повного обсягу полів до одиниць відсотків, а кожне рішення експерта повертається в правила й підвищує точність наступного прогону.
Межа проходить за природою рішення: автоматика звужує простір варіантів і бере на себе обсяг, людина відповідає за смислові домовленості — які сутності вважати однією та як трактувати розбіжності. Тому поріг впевненості й правила налаштовуються під конкретний облік, а не беруться універсальними.
Технічні сумніви: точність, відкати, контроль якості
Цілісність підтверджується не вибірковою перевіркою «очима», а звіркою на рівні наборів: кількість записів до і після, контрольні суми за числовими полями, зріз за первинними ключами.
Розбіжність одразу прив’язується до вихідного запису й до правила, за яким вона виникла, — так видно, це помилка зіставлення чи конфлікт довідників.
Кожна невідповідність і кожна пара дублів потрапляють у звіт із рішенням: прийняти, об’єднати, відкласти. Поки за записом немає рішення, до цільової системи вона не йде — перенесення відбувається хвилями, і кожна хвиля закривається звіркою.
Як підтверджується цілісність даних?
Трьома звірками: за кількістю, за контрольними сумами числових полів і за зрізом первинних ключів. Додатково розбираються зв’язки «батько — нащадок» — так ловляться записи, які формально перенеслися, але втратили посилання. Звіт звірки зберігається разом із прогоном.
Що робити з невідповідностями записів і дублями в довідниках?
Модель пропонує варіант об’єднання та обґрунтування, рішення ухвалює відповідальний. Спірні пари йдуть у карантин — окремий набір, який доопрацьовують після перенесення, не блокуючи решту записів.
Чи можна відкотити перенесення?
Так. Запис до цільової системи йде з міткою прогону, тому відкат — це видалення набору за міткою, а не відновлення з резервної копії. Відкат окремої хвилі не зачіпає дані, вже прийняті та підтверджені.
Що фіксує журналювання операцій?
Кожне перетворення: вихідне значення, спрацьоване правило або рішення моделі, підсумкове значення, автора правки й час. Журнал незмінний — за ним відновлюється історія будь-якого запису, навіть якщо його правили вручну після перенесення.
Обговоримо вашу задачу і повернемося з оцінкою та планом
Щоб оцінка була робочою, а не приблизною, інженерам потрібні вхідні дані щодо даних і контуру. Чим конкретніші вихідники, тим менше припущень у плані робіт і тим реалістичніші строки.
- Перелік джерел: бази даних, файлові вивантаження, зовнішні інтерфейси, черги повідомлень — з обсягами та періодичністю оновлення.
- Схеми таблиць або знеособлені зразки вивантажень — за ними перевіряємо автоматичний мапінг полів на реальних значеннях, а не на здогадках.
- Бізнес-правила: що вважається дублем, які поля обов’язкові, як трактувати порожні та конфліктні значення.
- Вимоги до цільової системи: підтримувані типи, унікальні ключі, довідники, обов’язкові зв’язки між сутностями.
- Критерії верифікації: які розбіжності критичні, яку частку записів допустимо перевіряти вручну на прийманні.
- Обмеження щодо доступів і контуру: де дозволено розгортати обробку, чи потрібен закритий контур без виходу назовні.
- Історія минулих перенесень: де рвалися зв’язки, що не сходилося у звітах, які сценарії вже пробували й чому відмовилися.
У відповідь ми повертаємо план робіт, а не загальні обіцянки: етапи, порядок прогонів на тестовому наборі, схему верифікації, оцінку строків і склад команди — хто відповідає за мапінг, хто за перевірку даних, хто за приймання результату.
Опишіть задачу у вільній формі та додайте те, що вже є, — повернемося з оцінкою та планом.
