Microsoft Fabric Warehouse: IDENTITY Columns (GA) та Migration Assistant для SQL — повний розбір

Коротко: Microsoft Fabric Data Warehouse отримав IDENTITY columns у статусі General Availability. Вони автоматично генерують унікальні BIGINT-значення для surrogate keys без ручної логіки. Паралельно Fabric Migration Assistant спрощує перенесення схем і даних із SQL Server та інших джерел у Fabric Data Warehouse. Разом ці можливості роблять міграцію класичних аналітичних SQL-сховищ у Fabric помітно практичнішою.

Вступ

У серпні 2026 року Microsoft перевела IDENTITY columns у Fabric Data Warehouse в General Availability. Для команд, які звикли до surrogate keys у SQL Server, це важливий крок: Fabric тепер нативно генерує унікальні числові ключі без окремих таблиць-лічильників або додаткової логіки завантаження.

Другий важливий напрям — Fabric Migration Assistant for Data Warehouse. Це вбудований guided migration experience, який допомагає оцінити сумісність схеми, автоматично перетворити частину об’єктів і перенести metadata та data в новий Warehouse.

У цій статті розберемо синтаксис і обмеження IDENTITY, сценарії міграції з SQL Server, роль Migration Assistant і те, як перевіряти результат після переходу в Microsoft Fabric.

Що таке Microsoft Fabric Data Warehouse і чому це важливо для міграцій?

Fabric Data Warehouse — enterprise-scale relational warehouse на основі lake architecture. Дані зберігаються у Delta tables у OneLake, а розробники працюють із ними через T-SQL, транзакції, views, stored procedures та звичну реляційну модель.

Це робить Warehouse природним напрямом для команд, які переносять аналітичні workloads із SQL Server або Azure Synapse: SQL-підхід зберігається, але storage і compute переходять у керовану Fabric-архітектуру.

Що таке IDENTITY Columns у Fabric Data Warehouse?

IDENTITY column автоматично генерує нове унікальне числове значення під час вставки рядка. Типовий сценарій — surrogate key у dimension або fact table, де ключ не залежить від бізнес-полів і керується системою.

У Fabric реалізація IDENTITY має власні правила, пов’язані з розподіленою архітектурою Warehouse:

• IDENTITY підтримується тільки для типу BIGINT;
• Seed і increment задавати не можна — Fabric керує діапазонами значень самостійно;
• Значення гарантовано унікальні, але не обов’язково послідовні або впорядковані;
• У таблиці може бути одна IDENTITY column;
• Після explicit inserts через IDENTITY_INSERT потрібно виконувати DBCC CHECKIDENT(…, RESEED).

Базовий синтаксис IDENTITY у Fabric Warehouse

CREATE TABLE dbo.Orders (
    OrderID BIGINT IDENTITY NOT NULL,
    CustomerID BIGINT NOT NULL,
    OrderDate DATE NOT NULL,
    Amount DECIMAL(10,2)
);

CREATE TABLE dbo.Orders (
    OrderID BIGINT IDENTITY NOT NULL,
    CustomerID BIGINT NOT NULL,
    OrderDate DATE NOT NULL,
    Amount DECIMAL(10,2)
);

Fabric автоматично призначає OrderID під час INSERT. На відміну від SQL Server, синтаксис IDENTITY(1,1) тут не використовується: початкове значення й крок не задаються користувачем.

INSERT INTO dbo.Orders (CustomerID, OrderDate, Amount)
VALUES (101, '2026-09-01', 249.90);

INSERT INTO dbo.Orders (CustomerID, OrderDate, Amount)
VALUES (101, '2026-09-01', 249.90);

Чи можна використовувати IDENTITY як primary key?

IDENTITY добре підходить як surrogate key, але сам факт IDENTITY не створює enforced primary key. У Fabric Data Warehouse PRIMARY KEY, FOREIGN KEY та UNIQUE constraints підтримуються як NOT ENFORCED metadata constraints.

Наприклад, primary key можна додати окремо:

ALTER TABLE dbo.Orders
ADD CONSTRAINT PK_Orders
PRIMARY KEY NONCLUSTERED (OrderID) NOT ENFORCED;

ALTER TABLE dbo.Orders
ADD CONSTRAINT PK_Orders
PRIMARY KEY NONCLUSTERED (OrderID) NOT ENFORCED;

Тому під час міграції перевірка referential integrity залишається відповідальністю pipeline, source system і validation-процедур.

Явна вставка значень: IDENTITY_INSERT

Під час міграції часто потрібно зберегти старі ключі з SQL Server. Для цього Fabric підтримує SET IDENTITY_INSERT.

SET IDENTITY_INSERT dbo.Orders ON;

INSERT INTO dbo.Orders (OrderID, CustomerID, OrderDate, Amount)
VALUES (50001, 101, '2025-01-15', 99.00);

SET IDENTITY_INSERT dbo.Orders OFF;

DBCC CHECKIDENT('dbo.Orders', RESEED);

SET IDENTITY_INSERT dbo.Orders ON;

INSERT INTO dbo.Orders (OrderID, CustomerID, OrderDate, Amount)
VALUES (50001, 101, '2025-01-15', 99.00);

SET IDENTITY_INSERT dbo.Orders OFF;

DBCC CHECKIDENT('dbo.Orders', RESEED);

DBCC CHECKIDENT у Fabric підтримує RESEED без ручного значення. Warehouse сам сканує використані й зарезервовані identity ranges та визначає наступні безпечні значення.

Чому значення IDENTITY можуть мати пропуски

Fabric Warehouse використовує distributed compute. Для високої паралельності система резервує діапазони identity values на різних compute nodes. Через це ID можуть мати пропуски й не відображати хронологічний порядок вставок.

Для surrogate keys це нормальна поведінка. Якщо бізнес-процес вимагає юридично значущої безперервної нумерації документів, IDENTITY не варто використовувати як такий номер.

Що таке Fabric Migration Assistant for Data Warehouse?

Fabric Migration Assistant — це вбудований у Fabric guided migration experience для перенесення metadata та data в Fabric Data Warehouse. Для SQL Server він може працювати з DACPAC або через supported source connection, аналізувати схему, конвертувати підтримувані об’єкти й допомагати виправляти incompatibilities.

Інструмент орієнтований насамперед на migration of analytical workloads. Microsoft окремо рекомендує планувати архітектурні відмінності між SQL Server і Fabric Warehouse, а не сприймати міграцію як повністю прозорий lift-and-shift.

Який workflow використовує Migration Assistant?

Що Migration Assistant не робить автоматично

Автоматизація скорочує ручну роботу, але складні SQL Server environments усе одно потребують engineering review. Особливої уваги вимагають:

• Об’єкти або T-SQL-конструкції, яких немає у Fabric Warehouse;
• Enforced constraints і referential actions;
• Indexes, які не мають прямого еквівалента в distributed Fabric engine;
• CLR, XML або інші platform-specific features;
• Операційна логіка, яка фактично належить OLTP-системі, а не аналітичному warehouse;
• Identity migration, якщо потрібно зберегти старі surrogate keys.

Як правильно мігрувати таблиці з IDENTITY із SQL Server

Для таблиць, де identity values уже використовуються у foreign-key relationships або downstream systems, Microsoft рекомендує зберегти історичні значення.

Практична послідовність:

• Створити destination table із BIGINT IDENTITY;
• Увімкнути IDENTITY_INSERT або використати COPY INTO з IDENTITY_INSERT = ON для bulk loads;
• Перенести існуючі identity values;
• Виконати DBCC CHECKIDENT(…, RESEED);
• Перевірити, що нові inserts отримують унікальні значення без collision;
• Окремо перевірити referential integrity, оскільки key constraints у Warehouse не enforced.

Яка роль SQL analytics endpoint після міграції?

У Fabric Warehouse основна робота з DDL і DML виконується через сам Warehouse і його T-SQL endpoint. Окремо Fabric автоматично створює SQL analytics endpoint як read-optimized SQL surface над Delta data у OneLake.

Для аналітичних сценаріїв це дає стандартний T-SQL/TDS-доступ із Power BI, SSMS, Visual Studio Code та інших клієнтів. SQL analytics endpoint корисний для read-oriented analytics і reporting, тоді як запис і повні transactional capabilities залишаються у Warehouse.

Як перевірити якість міграції

Після automated migration важливо проводити не лише технічний smoke test, а й data validation. Мінімальний набір перевірок:

• Порівняти row counts для ключових таблиць;
• Перевірити min/max/sum та контрольні агрегати для критичних числових полів;
• Звірити NULL distribution та precision/scale після type conversion;
• Перевірити explicit identity values і нові generated IDs після reseed;
• Валідувати зв’язки між parent/child tables;
• Прогнати основні BI/ETL workloads і порівняти результати зі source system;
• Перевірити performance і оновити statistics після значних load operations.

FAQ: IDENTITY Columns та Migration Assistant у Fabric

Питання: Що таке IDENTITY Columns у Fabric Warehouse?

Відповідь: Це GA-функція автоматичного генерування унікальних BIGINT-значень під час вставки рядків. Вона зручна насамперед для surrogate keys у data warehouse.

Питання: Чи підтримує Fabric IDENTITY(1,1)?

Відповідь: Ні. У Fabric Data Warehouse використовується BIGINT IDENTITY без custom seed та increment. Діапазонами значень керує система.

Питання: Чи гарантовано послідовний номер без пропусків?

Відповідь: Ні. Значення гарантовано унікальні, але через distributed architecture вони можуть бути непослідовними й мати gaps.

Питання: Як перенести існуючі identity values із SQL Server?

Відповідь: Використовуйте SET IDENTITY_INSERT або COPY INTO з IDENTITY_INSERT ON, а після завантаження виконайте DBCC CHECKIDENT(…, RESEED).

Питання: Що робить Fabric Migration Assistant?

Відповідь: Він допомагає імпортувати або зчитати source metadata, оцінити schema compatibility, автоматично конвертувати підтримувані об’єкти, застосувати fixes і перенести data в Fabric Data Warehouse.

Питання: Чи міграція повністю автоматична?

Відповідь: Ні. Unsupported T-SQL, constraints, platform-specific objects і business logic потрібно переглядати вручну, а результат — обов’язково валідовувати.

Питання: Чи потрібно окремо платити за IDENTITY?

Відповідь: Окремої плати саме за IDENTITY немає. Вартість визначається Fabric capacity, storage і фактичним compute consumption відповідно до моделі Microsoft Fabric.

Висновок

GA для IDENTITY columns закриває одну з помітних прогалин Fabric Data Warehouse для класичних dimensional models. Команди тепер можуть нативно генерувати surrogate keys, зберігати старі identity values під час міграції й безпечно продовжувати генерацію після reseed.

Fabric Migration Assistant, зі свого боку, зменшує обсяг ручної роботи при переході з SQL Server і суміжних аналітичних платформ: автоматизує assessment, conversion і перенесення підтримуваних об’єктів, але не скасовує архітектурного review та data validation.

Для команд, які вже оцінюють перехід із класичних SQL-сховищ у Microsoft Fabric, це хороший момент протестувати Warehouse на реальній схемі. Якщо хочете системно розібратися з Warehouse, Data Factory, OneLake та іншими компонентами платформи, курс «Microsoft Fabric у дії» від Data Lab дає практичний фундамент за один місяць навчання.