Data Factory у Microsoft Fabric: оркестрація даних без зайвого болю

Коротко: Data Factory у Microsoft Fabric — це вбудований інструмент для побудови ETL/ELT-пайплайнів і оркестрації потоків даних усередині єдиної платформи. Він об’єднує Data Pipelines, Dataflow Gen2 і Copy Activity/Copy Job без потреби в окремому Azure-ресурсі. Стаття для дата-інженерів і аналітиків, які хочуть розібратися з оркестрацією в Fabric практично.

Вступ

Сучасні data-команди рідко працюють з одним джерелом даних і одним сховищем. Є бази, API, файлові сховища, SaaS-системи — і все це треба збирати, трансформувати та доставляти за розкладом або за подією. Саме тут з’являється потреба в оркестрації.

Data Factory у Microsoft Fabric — це відповідь платформи на цей запит. Він дозволяє будувати надійні пайплайни через low-code інтерфейс, нативно інтегруватися з Lakehouse, Warehouse і Dataflow Gen2, і при цьому не виходити за межі єдиного робочого простору.

У цій статті розберемо: чим Fabric Data Factory відрізняється від Azure Data Factory, як влаштовані ключові сутності, як налаштувати перший пайплайн і яких помилок варто уникати з самого початку.

Що таке Data Factory у Fabric і навіщо він потрібен?

Оркестрація як базова навичка сучасного дата-інженера

Запустити Python-скрипт вручну — це нормально для прототипу. У продакшн-середовищі це вже проблема: скрипт може впасти, ніхто не дізнається, дані не оновляться, дашборд покаже вчорашні цифри.

Оркестрація даних — це управління послідовністю, залежностями та розкладом виконання задач. Вона відрізняється від простого ETL тим, що відповідає не лише за трансформацію, а за весь lifecycle запуску: коли стартувати, що робити при помилці, як повторити невдалий крок.

Чим Data Factory у Fabric відрізняється від Azure Data Factory?

Це питання виникає у більшості команд, які вже знайомі з ADF. Відповідь не очевидна — інструменти схожі концептуально, але відрізняються архітектурно.

Архітектурні відмінності: окремий ресурс vs вбудований компонент

Azure Data Factory — це окремий Azure-сервіс із власним ресурсом, власним білінгом і власним порталом управління. Ти створюєш ADF-інстанс, налаштовуєш Linked Services, Integration Runtime, і керуєш усім через Azure Portal або ARM-шаблони.

Fabric Data Factory живе всередині Fabric Workspace. Немає окремого ресурсу, немає окремого білінгу — все включено в Fabric Capacity (F-SKU). Це знижує операційний overhead, але накладає обмеження на кастомізацію.

Що залишилось спільним, а що змінилось принципово

Спільне: концепція Pipeline, Activity, тригери (Schedule, Event-based), Copy Activity. Якщо ти працював з ADF — базова логіка знайома.

Відмінності суттєві:

• Linked Services замінені на Connections — спрощена модель з централізованим управлінням
• Mapping Data Flows замінені на Dataflow Gen2 на базі Power Query
• Нативна інтеграція з Lakehouse і Warehouse без додаткових конекторів
• Моніторинг вбудований у Fabric Workspace, а не в окремий портал

Порівняльна таблиця: Azure Data Factory vs Fabric Data Factory

Практична позиція: якщо ти вже на Fabric і будуєш data-платформу всередині екосистеми Microsoft — Fabric Data Factory є логічним вибором. Якщо у тебе складний enterprise-стек з on-premise джерелами, кастомними Integration Runtime і розвиненим CI/CD на ADF — переходити зараз не обов’язково. Концепція data pipeline orchestration залишається однаковою в обох інструментах, змінюється лише модель розгортання.

Як влаштований ETL пайплайн у Fabric: ключові сутності та їх роль

Pipeline: серце оркестрації в Fabric

Pipeline — основна одиниця оркестрації. Всередині нього будується граф активностей: що виконується послідовно, що паралельно, що залежить від результату попереднього кроку.

Ключові активності Pipeline:

• Copy Data — переміщення даних між джерелом і призначенням
• Copy Job — окремий легковаговий артефакт для простого переміщення даних між джерелом і призначенням без необхідності створювати повноцінний Pipeline.
• Dataflow — виклик Dataflow Gen2 для трансформації
• Invoke Pipeline — запуск дочірнього пайплайну
• Script — виконання SQL-скриптів або команд у підтримуваних SQL-сховищах
• Notebook — запуск Fabric Notebook для Python/PySpark/SQL-логіки
• Stored Procedure — виклик процедури в базі даних
• Lookup — отримання значення для подальшого використання в пайплайні
• ForEach — ітерація по колекції об’єктів
• If Condition — розгалуження логіки залежно від умови
• Wait — пауза між кроками

Окремо в Data Factory доступні Apache Airflow Jobs — Fabric workload для запуску Airflow DAGs у межах платформи. Це не прямий аналог звичайної pipeline activity, а окремий сценарій для команд, які хочуть використовувати Airflow-підхід усередині Fabric.

Dataflow Gen2: трансформація даних без написання коду

Dataflow Gen2 базується на Power Query і виконує трансформації у Fabric capacity; користувач описує кроки low-code способом, а платформа бере на себе виконання.

Це зручно для аналітиків, які знають Power Query, але хочуть будувати відтворювані трансформації. Для складних сценаріїв з великими обсягами даних або нестандартною логікою краще розглянути Spark Notebooks.

Практичне правило вибору:
– Dataflow Gen2 — коли трансформація відносно проста, команда знайома з Power Query, і обсяг даних помірний
– Pipeline з Script або Notebook — коли потрібна складна логіка, версіонування коду або обробка великих обсягів

Copy Activity та інші вбудовані активності

Copy Activity — найпоширеніша активність для переміщення даних. Вона підтримує різні режими запису залежно від цільового сховища: append, overwrite, а для окремих конекторів — upsert або bulk insert

З якими типами сховищ і джерел інтегрується Data Factory

Data Factory підтримує понад 100 конекторів: реляційні бази даних, файлові сховища (ADLS, S3, Blob), SaaS-системи (Salesforce, SharePoint), REST API.

Цільові сховища всередині Fabric: Lakehouse (Delta tables або файли), Warehouse (SQL-endpoint), KQL Database для аналітики часових рядів.

Якщо ти будуєш надійну ETL-архітектуру системно і хочеш розібратися з повним стеком — спеціалізація Analytics & Data Engineer охоплює саме ці практики: від проєктування пайплайнів до деплою в продакшн.

Як налаштувати перший data pipeline у Microsoft Fabric: покроковий огляд

Створення Pipeline у Fabric Workspace

Відкрий Fabric Workspace, обери розділ Data Factory і створи новий Data Pipeline. Ти потрапляєш у canvas-редактор, де перетягуєш активності і з’єднуєш їх стрілками залежностей.

Перший пайплайн краще будувати з мінімальною логікою: одна Copy Activity, одне джерело, одне призначення. Це дозволяє перевірити підключення і схему даних до того, як додавати складнішу логіку.

Налаштування Copy Activity: джерело, призначення, маппінг

Copy Activity налаштовується в три кроки:

1. Source — вибір Connection і джерела даних (таблиця, запит або файл)
2. Destination — вибір цільового сховища і режиму запису
3. Mapping — відповідність колонок між джерелом і призначенням

Нижче — спрощена концептуальна схема, що показує логіку налаштування Source, Destination і Mapping.

{
  "name": "CopyFromSQLToLakehouse",
  "type": "Copy",
  "inputs": [
    {
      "source": {
        "type": "AzureSqlSource",
        "sqlReaderQuery": "SELECT * FROM dbo.orders WHERE updated_at >= '@{pipeline().parameters.start_date}'"
      },
      "connection": "SqlServerConnection"
    }
  ],
  "outputs": [
    {
      "destination": {
        "type": "LakehouseTable",
        "tableName": "orders_raw",
        "writeMode": "Append"
      },
      "connection": "LakehouseConnection"
    }
  ],
  "columnMappings": [
    { "source": "order_id", "destination": "order_id" },
    { "source": "customer_id", "destination": "customer_id" },
    { "source": "total_amount", "destination": "total_amount" }
  ]
}

{
  "name": "CopyFromSQLToLakehouse",
  "type": "Copy",
  "inputs": [
    {
      "source": {
        "type": "AzureSqlSource",
        "sqlReaderQuery": "SELECT * FROM dbo.orders WHERE updated_at >= '@{pipeline().parameters.start_date}'"
      },
      "connection": "SqlServerConnection"
    }
  ],
  "outputs": [
    {
      "destination": {
        "type": "LakehouseTable",
        "tableName": "orders_raw",
        "writeMode": "Append"
      },
      "connection": "LakehouseConnection"
    }
  ],
  "columnMappings": [
    { "source": "order_id", "destination": "order_id" },
    { "source": "customer_id", "destination": "customer_id" },
    { "source": "total_amount", "destination": "total_amount" }
  ]
}

Важливий момент: типи даних у маппінгу. Якщо джерело повертає VARCHAR, а призначення очікує INT — пайплайн або впаде, або мовчки запише некоректні дані. Перевіряй схему на старті.

Тригери: за розкладом, подієво або вручну

Три варіанти запуску пайплайну:

• Schedule Trigger — запуск за розкладом (cron-синтаксис або простий UI)
• Event-based Trigger — запуск при появі файлу в сховищі або іншій події
• Manual Run — запуск вручну через UI або API

На практиці більшість batch-пайплайнів стартують за розкладом. Event-based тригери корисні для сценаріїв, де дані надходять нерегулярно.

Моніторинг запусків і контроль якості пайплайнів

Fabric має вбудований монітор запусків: Activity Runs і Pipeline Runs з детальним логом кожного кроку. Тут видно час виконання, кількість оброблених рядків і текст помилки при збої.

Моніторинг пайплайнів тісно пов’язаний із Data Governance та якістю даних — без контролю того, що і коли завантажилось, складно гарантувати якість даних у downstream-системах.

На що звертати увагу при першому налаштуванні: перевір, чи є retry-логіка на рівні активності, чи налаштовані алерти при збої, і чи є параметризація для дат і фільтрів — це заощадить час при переробці пайплайну пізніше.

Типові помилки та обмеження Data Factory у Fabric: що варто знати заздалегідь

Обмеження платформи, про які не пишуть у документації

Dataflow Gen2 має продуктові й capacity-залежні обмеження, а також може поводитися гірше на дуже великих або складних трансформаціях. Перед продакшеном варто тестувати на реальних обсягах і перевіряти актуальні limits у документації.

CI/CD у Fabric суттєво розвинувся у 2025–2026 роках. Зараз доступні: Git-інтеграція з Azure DevOps і GitHub, вбудовані Deployment Pipelines для просування контенту між Dev/Test/Prod, GA-статус CI/CD для Dataflow Gen2, а також офіційно підтримувана Microsoft бібліотека fabric-cicd для автоматизації між робочими просторами. Повністю замінити ADF-підхід на ARM-шаблони вона ще не може в усіх сценаріях, але для більшості команд інструментарій вже достатній для enterprise-рівня. Перевіряйте список підтримуваних item-типів у документації — деякі ще в preview.

Дебагінг обмежений. Дебагінг у low-code pipeline-сценаріях менш гнучкий, ніж у code-first оркестраторах на кшталт Airflow: часто доводиться аналізувати activity runs, input/output і логи окремих кроків.

Найпоширеніші помилки при побудові пайплайнів

Помилка 1: змішування Pipeline і Dataflow Gen2 без чіткої логіки. Pipeline відповідає за оркестрацію, Dataflow Gen2 — за трансформацію. Якщо ти вкладаєш складну трансформаційну логіку прямо в Script Activity Pipeline замість Dataflow, або навпаки — намагаєшся оркеструвати через Dataflow — архітектура стає заплутаною.

Помилка 2: ігнорування типів даних при маппінгу. Це причина більшості runtime-помилок. Перевіряй схему джерела і призначення до запуску.

Помилка 3: відсутність retry-логіки. Мережеві помилки, тимчасова недоступність джерела — без retry і алертів пайплайн може впасти, а команда дізнається про це із запізненням.

Помилка 4: запуск важких Dataflow Gen2 без урахування Fabric Capacity. Якщо capacity завантажена іншими задачами, Dataflow може потрапити в throttling і виконуватись набагато довше очікуваного.

Fabric Data Factory — зрілий інструмент для batch-оркестрації, але в деяких сценаріях (складний CI/CD, глибока кастомізація, code-first підхід) зрілі рішення типу Apache Airflow або Azure Data Factory дають більше контролю.

FAQ: питання про Data Factory у Microsoft Fabric

Питання: Що таке Data Factory у Microsoft Fabric?
Відповідь: Data Factory у Microsoft Fabric — це вбудований сервіс оркестрації та інтеграції даних, який дозволяє будувати ETL/ELT-пайплайни без написання інфраструктурного коду. Він об’єднує можливості Pipeline і Dataflow Gen2 в єдиному хмарному середовищі Fabric. За допомогою нього можна переміщати, трансформувати та завантажувати дані між сотнями джерел і сервісами Fabric — Lakehouse, Warehouse, KQL Database — без виходу за межі робочого простору.

Питання: Як налаштувати перший пайплайн у Data Factory в Microsoft Fabric?
Відповідь: Відкрий Fabric Workspace, обери розділ Data Factory і створи новий Data Pipeline. Додай Copy Activity, налаштуй підключення до джерела і призначення, перевір маппінг колонок і встанови тригер або розклад запуску. Після збереження пайплайн можна запустити вручну або налаштувати для запуску за розкладом/подією. Для першого пайплайну краще починати з простої схеми — одне джерело, одне призначення — і поступово додавати складнішу логіку після перевірки базового сценарію.

Питання: Data Factory у Fabric vs Azure Data Factory — чим відрізняються?
Відповідь: Azure Data Factory — окремий хмарний сервіс Azure з власним ресурсом, білінгом і широкими можливостями кастомізації. Data Factory у Microsoft Fabric є нативно інтегрованим компонентом платформи, що спрощує роботу всередині єдиної екосистеми без додаткових підключень і окремої тарифікації. Fabric-версія орієнтована на зручність і швидкий старт, тоді як ADF краще підходить для складних enterprise-сценаріїв із кастомними Integration Runtime, розвиненим CI/CD і інфраструктурою поза Fabric.

Питання: Скільки коштує використання Data Factory у Microsoft Fabric?
Відповідь: Data Factory входить до складу Microsoft Fabric, який працює за моделлю Fabric Capacity — ти платиш за обчислювальні ресурси (F-SKU), а не за кожен сервіс окремо. Доступна безкоштовна пробна версія Fabric на 60 днів із обмеженою потужністю. Вартість залежить від обраного рівня capacity та регіону розгортання — детальний калькулятор є на сайті Microsoft Azure.

Питання: Які типові помилки роблять при роботі з Data Factory у Fabric?
Відповідь: Найпоширеніша помилка — відсутність retry-логіки і обробки помилок у пайплайнах, що призводить до мовчазних збоїв у даних. Також часто плутають Dataflow Gen2 і Data Pipeline, використовуючи їх не за призначенням: Pipeline для оркестрації, Dataflow для трансформації. Ще одна проблема — ігнорування типів даних при маппінгу і відсутність моніторингу запусків із алертами, через що помилки виявляються із запізненням.

Підсумок і що далі: як рухатись після першого пайплайну у Fabric

Ключові висновки про оркестрацію в Microsoft Fabric

Data Factory у Microsoft Fabric — зрілий інструмент для batch-оркестрації з низьким порогом входу. Він добре підходить командам, які вже працюють в екосистемі Microsoft і будують data-платформу на Fabric: нативна інтеграція з Lakehouse і Warehouse, єдиний моніторинг, відсутність окремого білінгу за сервіс.

Практична рекомендація: починай з простого Copy Activity Pipeline, перевіряй схему і маппінг на малих обсягах, додавай Dataflow Gen2 і складнішу логіку поступово. Налаштуй retry і моніторинг з першого пайплайну — переробляти це пізніше дорожче.

Що далі: наступні кроки для практичного освоєння

Після першого пайплайну варто розібратися з Fabric Lakehouse і Delta tables, Spark Notebooks для складніших трансформацій і Eventstreams у Real-Time Intelligence для real-time сценаріїв.

Спробуй безкоштовний Fabric Trial на 60 днів і побудуй перший пайплайн самостійно — це найкращий спосіб перевірити, чи підходить платформа для твоїх задач.