Використання Microsoft Copilot для прискорення аналізу складного SQL-коду: реальний кейс
Аналіз великих обсягів SQL-коду є надзвичайно складним завданням, оскільки реальні запити рідко бувають чистими, послідовними або структурованими передбачуваним чином. Хоча такі інструменти, як Microsoft Copilot, можуть значно прискорити цю роботу, вони дають реальну цінність лише тоді, коли їх спрямовують за допомогою правильної методології та предметної експертизи. Сьогодні я хотів би поділитися реальним прикладом того, як Copilot допоміг мені виконати складне завдання з аналізу даних усього за два дні — завдання, яке зайняло б понад 30 днів у разі повністю ручного виконання.
Контекст: Основи Data Mapping
У цій статті я хотів би поділитися своїм першим досвідом використання штучного інтелекту для аналізу великого обсягу SQL-коду в контексті сопоставлення даних (Data Mapping). Перш ніж перейти до практичної частини, я коротко поясню, що таке Data Mapping.
Як випливає з назви, Data Mapping (сопоставлення даних) — це процес вирівнювання або зіставлення даних. Найчастіше він використовується тоді, коли дані необхідно зіставити між кількома системами. Уявіть успадковану (Legacy) систему, яка розроблялася протягом багатьох років і дані якої споживаються іншими програмами. Тепер припустимо, що ця Legacy-система замінюється новою системою, яка повністю або частково покриває функціонал старої. Виникає природне запитання: як ми можемо впровадити нову систему та вивести з експлуатації стару так, щоб усі залежні системи продовжували працювати без збоїв?
Один із підходів полягає у створенні проміжного шару між новою системою та системами, що залежать від Legacy-платформи. Цей шар трансформує дані та їхню структуру з нової системи у формат, очікуваний старою, що дозволяє залежним системам продовжувати функціонувати як і раніше. Реалізація такого шару передбачає Data Mapping — процес зіставлення моделі даних нової системи з моделлю даних старої.
У класичному проекті з міграції моя роль полягала в тому, щоб визначити об'єкти (таблиці та поля) в базі даних Legacy-системи, знайти їхні еквіваленти в новій системі, описати необхідні трансформації та задокументувати прогалини (gaps) — сценарії, коли нова система не може повністю відтворити дані зі старої.
Проблема
Моїм завданням було визначити, які саме об'єкти Legacy-системи використовувалися однією із суміжних (downstream) систем, що покладалася на дані Legacy як на основне джерело для аналізу та звітності. Ця інформація була необхідна для визначення того, які об'єкти Legacy потрібно зіставити з їхніми аналогами в новій системі в першу чергу. На жаль, жодної документації для суміжного додатка не існувало. Єдиним доступним артефактом був його SQL-код — і аналіз цього коду за допомогою ШІ став основою мого підходу.
Мені надали список із 78 SQL-файлів, які загалом містили понад 12 000 рядків SQL-коду.
Мета полягала в наступному:
Визначити всі таблиці та поля, що використовуються в запитах
Визначити, де саме в кожному запиті використовувалися ці таблиці та поля
Розрахувати, як часто кожна таблиця та поле з'являлися в усій базі коду
Цей тип аналізу зазвичай вимагає дуже багато часу та схильний до помилок при ручному виконанні, особливо в таких масштабах.
Початковий підхід із Copilot та виклики
Ураховуючи обмеження Copilot щодо обсягу файлів, я об'єднав усі 78 SQL-файлів в один файл і попросив Copilot проаналізувати його. Я запросив результат у форматі Excel із такими колонками:
Назва колонки | Опис
|
DB Name | Назва цільової бази даних |
Schema Name | Назва схеми бази даних |
Table Name | Назва знайденої таблиці |
Field Name | Назва знайденого поля |
Statement | Тип/контекст SQL-оператора |
Frequency | Частота появи в кодовій базі |
Хотя Copilot і видав результат, він виявився недостатнім та суперечливим. Вихідні дані містили дуже мало таблиць і полів, а результати не відповідали моєму розумінню кодової бази, заснованому на попередньому досвіді.
Я декілька разів перезапускав аналіз із тим самим промптом, але кожна спроба давала різні й усе одно неповні результати. Ця нестабільність швидко стала одним із найбільших викликів. Неможливість отримати стабільні результати з одного й того самого входу та промпту значно знизила довіру до вихідних даних.
Після кількох спроб я зрозумів, що Copilot намагався сприймати SQL-код як добре структурований текст, значною мірою покладаючись на різні шаблони регулярних виразів для його парсингу. Однак SQL-код — особливо великий, реальний SQL — не є послідовно структурованим, що призводило до ненадійного парсингу та втрачених об'єктів.
Коригування стратегії: Направлення Copilot
На цьому етапі я дійшов висновку, що не повинен повністю покладатися на стандартний аналітичний підхід Copilot. Замість цього мені потрібно було спрямувати Copilot до правильної методології.
Ключові спостереження:
Увесь SQL-код використовував об’єкти з єдиної базі даних.
Повний словник даних (Data Dictionary) для цієї бази даних уже існував.
У мене був документ зі словником даних, але я вирішив не покладатися на нього напряму. Замість цього я створив допоміжну довідкову таблицю, що містила повний список усіх таблиць і полів, доступних у базі даних. Написання SQL-запиту для витягування всіх об'єктів бази даних та їхніх атрибутів було простим завданням. Згенерувавши цей список, я надав його Copilot і відповідним чином оновив постановку завдання.
Попросити Copilot визначати лише ті таблиці та поля, які є в наданому словнику
Використати гібридний підхід:
Сприймати SQL як неструктурований текст там, де це необхідно
Використовувати словник даних для перевірки реального використання таблиць і полів
Використовувати регулярні вирази вибірково, лише там, де вони мали сенс
Як тільки Copilot було налаштовано на правильний аналітичний підхід, результати кардинально покращилися. Виявлені таблиці та поля нарешті відповідали моїм очікуванням та досвіду роботи з кодовою базою.
Ключові висновки
Не покладайтеся сліпо на підхід, який пропонує Copilot. Copilot часто робить припущення щодо структури, які можуть не відповідати реальним даним.
Експертиза людини має критичне значення. Ваші предметні знання є необхідними для спрямування Copilot до правильного рішення.
Перевіряйте результати, використовуючи власні знання та очікування. Якщо у вас немає обґрунтованого очікування щодо того, як має виглядати результат, не використовуйте вихідні дані Copilot як основне джерело для прийняття рішень.
Очікуйте варіативності та перезапускайте аналіз за потреби. Запуск одного й того самого аналізу кілька разів може давати різні результати.
Використовуйте пам'ять та контекст Copilot. Ставтеся до кожної успішної ітерації як до «точки збереження» у комп'ютерній грі. Розвивайте успіх далі на основі того, що працює, замість того, щоб сліпо починати все спочатку.
Від редакції: Якщо хочете поглибити свої технічні знання, зверніть увагу на
Новини та статті з бізнес-аналізу:
