Коротко: Lakehouse і Warehouse у Microsoft Fabric — це два різні артефакти з різними движками, але спільним сховищем OneLake. Lakehouse орієнтований на data engineering і ML-пайплайни через Spark, Warehouse — на структуровану аналітику і BI через T-SQL. У більшості реальних проєктів вони доповнюють одне одного, а не конкурують.
Вступ
Microsoft Fabric об’єднав під одним дахом інструменти, які раніше існували як окремі продукти. Тепер у кожного проєкту є вибір, якого раніше просто не існувало: Lakehouse чи Warehouse — і обидва живуть в одному workspace.
Проблема в тому, що назви схожі, платформа нова, а відмінності неочевидні — особливо для тих, хто приходить із класичного BI або data engineering без досвіду з Fabric.
Ця стаття пояснює, чим Lakehouse відрізняється від Warehouse під капотом, в яких сценаріях кожен із них виграє, і які помилки найчастіше трапляються при виборі архітектури.
Чим відрізняються Lakehouse і Warehouse у Fabric під капотом?
OneLake як спільна основа: де різниця, якщо дані в одному місці?
OneLake — це єдине хмарне сховище для всього Microsoft Fabric. Усі Fabric data items зберігають дані в OneLake, але формат залежить від типу даних і артефакту. Табличні дані Lakehouse і Warehouse зберігаються у Delta Parquet, тоді як секція Files у Lakehouse може містити довільні файли: CSV, JSON, XML, Parquet та інші формати.
Різниця між Lakehouse і Warehouse — у движку, який стоїть зверху, і в моделі взаємодії з цими даними. Саме тут і починається все важливе.
Lakehouse: Delta Lake, Spark і відкритий формат даних
Lakehouse у Microsoft Fabric будується навколо Apache Spark як основного движка обробки. Дані зберігаються у форматі Delta Lake — відкритому форматі на базі Parquet з підтримкою ACID-транзакцій на рівні файлів.
Структура Lakehouse складається з двох частин:
- Files — секція для сирих файлів: CSV, JSON, Parquet та інших форматів. Spark може читати їх напряму, але для стабільних production-пайплайнів схему краще задавати явно, а не покладатися лише на inference.
- Tables — Delta-таблиці з визначеною структурою, доступні через Spark SQL або PySpark.
Додатково кожен Lakehouse має SQL Endpoint — автоматично згенерований read-only SQL-доступ до Delta-таблиць. Це зручно для швидких запитів, але важливо розуміти його обмеження — про це далі.
Warehouse: T-SQL движок, ACID-транзакції і знайомий SQL-досвід
Fabric Warehouse — це SQL-first аналітичний артефакт із широкою підтримкою T-SQL: DDL, DML, views, stored procedures і транзакцій. Але це не повний SQL Server, тому перед міграцією складної DWH-логіки варто перевіряти актуальні T-SQL limitations у документації Microsoft.
Для команди з SQL-бекграундом це знайоме середовище: пишеш таблиці, визначаєш схему, будуєш views для Power BI — і все це без Spark, без Python, без нотбуків.
За роллю в архітектурі Fabric Warehouse близький до класичного cloud data warehouse і частково нагадує сценарії Synapse SQL, але реалізований як SaaS/serverless workload Fabric із даними в OneLake у форматі Delta Parquet. Водночас Warehouse керує цими таблицями як власним SQL-артефактом: користувач працює через T-SQL і metadata Warehouse, а фізичні Delta-файли доступні в OneLake з певними особливостями.
Таблиця порівняння: Lakehouse vs Warehouse у Fabric
| Критерій | Lakehouse | Warehouse |
|---|---|---|
| Основний движок | Apache Spark | T-SQL (serverless) |
| Мова запитів | PySpark, Spark SQL, SQL Endpoint (read-only) | T-SQL (повноцінний) |
| Формат зберігання | Delta Lake (Parquet) | Delta Parquet (OneLake) |
| Підтримка DDL/DML | DDL через Spark; DML через Spark або Dataflow | Повноцінний DDL/DML через T-SQL |
| ACID-транзакції | На рівні Delta Lake (Spark) | Нативні T-SQL транзакції для Warehouse-таблиць, із Fabric-specific isolation/concurrency limitations. |
| Підтримка ML/Spark | Так, нативно | Обмежено (через зовнішні підключення) |
| SQL Endpoint | SQL Endpoint | Read-only: тільки SELECT, без DDL, без DML, без stored procedures; views — лише read-only, створені автоматично | Повноцінний, з views і procedures |
| Цільова аудиторія | Data engineers, ML-інженери, Python-розробники | Аналітики, BI-розробники, SQL-команди |
| Типовий use case | Ingestion, трансформація, feature engineering, ML datasets | Semantic layer, BI-звітність, DWH |
Коли обирати Lakehouse, а коли Warehouse у Microsoft Fabric?
Сценарії, де Lakehouse — очевидний вибір
Lakehouse підходить там, де дані різнорідні, обсяги великі, або процес обробки складний.
Обирай Lakehouse, якщо:
- Будуєш data engineering пайплайни з Bronze/Silver/Gold шарами
- Команда працює на Python або PySpark і звикла до notebook-середовища
- Потрібно обробляти сирі файли — CSV, JSON, XML, Parquet — без попередньої схеми
- Плануєш ML-проєкти, feature engineering або інтеграцію з ML-фреймворками
- Важлива гнучкість schema-on-read: структура даних може змінюватися між завантаженнями
У реальних проєктах Lakehouse найчастіше займає Bronze і Silver шари медальйонної архітектури: сюди потрапляють сирі дані з джерел, тут відбувається очищення, нормалізація і трансформація через Spark.
А якщо хочеш системно вивчити data engineering підходи, включно з pipeline-архітектурою і хмарними сховищами — спеціалізація Analytics & Data Engineer покриває саме цей стек.
Сценарії, де Fabric Warehouse виграє
Warehouse оптимальний там, де важлива строга схема, транзакційна цілісність і зручність для SQL-команд.
Обирай Warehouse, якщо:
- Основний споживач даних — Power BI, і команда будує semantic layer
- BI-аналітики або SQL-розробники без Spark-досвіду будуть основними користувачами
- Потрібні stored procedures, views і повноцінний DML без обхідних шляхів
- Критична строга схема і контроль над типами даних на рівні DDL
- Будуєш enterprise-звітність з row-level security і контролем доступу на рівні об’єктів
Warehouse — природне середовище для Gold шару в медальйонній архітектурі: сюди потрапляють вже очищені й трансформовані дані, готові для споживання бізнесом.
Коли вони працюють разом: медальйонна архітектура у Fabric
У більшості enterprise-проєктів Lakehouse і Warehouse — це не альтернативи, а ролі в одній архітектурі.
Типова схема виглядає так:
- Bronze (Lakehouse) — сирі дані з джерел: файли, API, бази даних. Spark завантажує і зберігає без трансформацій.
- Silver (Lakehouse) — очищення, дедублікація, нормалізація. PySpark або Spark SQL трансформують дані в Delta-таблиці.
- Gold (Warehouse або Lakehouse + SQL analytics endpoint для read-only сценаріїв) — агреговані, готові до споживання дані.
Важливий нюанс: SQL Endpoint Lakehouse дає read-only доступ до Delta-таблиць через SQL. Він зручний для швидких запитів, але підтримує тільки SELECT — без INSERT, UPDATE, DELETE і без stored procedures. Якщо Gold шар потребує активної трансформації через SQL або складних views із write-логікою — Warehouse тут доречніший.
Практично корисна можливість: Fabric підтримує cross-database запити між Lakehouse і Warehouse в одному workspace. Це означає, що Gold-шар у Warehouse може напряму JOIN-ити дані з Silver Lakehouse через SQL — без копіювання даних між артефактами. Один запит, два артефакти, одна екосистема.
Типові помилки при виборі між Lakehouse і Warehouse у Fabric
Помилка 1: «Lakehouse замінює Warehouse — навіщо два артефакти?»
Це найпоширеніша помилка серед команд, які тільки починають працювати з Fabric. Логіка зрозуміла: обидва зберігають дані в OneLake, обидва мають SQL-доступ — навіщо дублювати?
SQL analytics endpoint Lakehouse — read-only щодо Lakehouse Delta-таблиць: через нього не виконують INSERT, UPDATE, DELETE або ALTER TABLE для цих таблиць і не використовують stored procedures як у Warehouse. Якщо потрібен повноцінний SQL-шар із керованими views, procedures і write-логікою, краще використовувати Warehouse.
Помилка 2: Використовувати SQL Endpoint Lakehouse як повноцінний Warehouse
SQL Endpoint і Warehouse — різні речі, хоча обидва дають SQL-доступ до даних.
SQL Endpoint автоматично генерується для кожного Lakehouse і відображає Delta-таблиці як SQL-об’єкти. Але це read-only інтерфейс поверх Spark-метаданих — без транзакцій у класичному SQL-розумінні, без DDL через SQL і без write-операцій.
Warehouse — окремий артефакт із власним T-SQL движком, де ви повністю контролюєте схему і маєте повноцінний DML. Плутати їх — значить або недовикористовувати Warehouse, або очікувати від SQL Endpoint можливостей, яких у нього немає.
Помилка 3: Обирати архітектуру під інструмент, а не під команду і use case
Типова ситуація в командах: data engineer обирає Lakehouse, бо знає Spark і Python — і будує всю архітектуру навколо нього. BI-команда потім страждає, бо не може нормально працювати з даними через SQL Endpoint без write-доступу.
Або навпаки: аналітик обирає Warehouse, бо знає T-SQL — і потім виявляється, що ML-пайплайни складно інтегрувати, а трансформація великих обсягів через T-SQL обходиться дорожче і повільніше, ніж через Spark.
Вибір архітектури має починатися з питання: хто і як буде споживати ці дані?
Помилка 4: Ігнорувати Data Governance при масштабуванні
При масштабуванні до enterprise-рівня питання управління даними стає критичним. Warehouse нативно підтримує row-level security, column-level security і object-level permissions через T-SQL — це знайомий і передбачуваний механізм.
Lakehouse має свої механізми контролю доступу, але вони працюють інакше — і при переході від пілоту до продакшену це часто стає несподіванкою.
Якщо тема Data Governance важлива для вашого проєкту — закладайте її в архітектурне рішення з самого початку, а не після того, як дані вже розподілені між артефактами.
Моя позиція: як я дивлюся на вибір між Lakehouse і Warehouse у Fabric
Питання «що обрати» часто неправильно поставлене. В більшості реальних проєктів потрібні обидва артефакти — і завдання архітектора полягає в тому, щоб правильно розподілити між ними ролі.
Мені подобається така метафора: Lakehouse — це фундамент і кухня, де відбувається вся важка робота з даними. Warehouse — це вітальня для гостей, тобто для бізнес-аналітиків і Power BI. Гості не ходять на кухню, але саме те, що там готується, потрапляє до них на стіл.
Fabric змінює підхід не тим, що замінює DWH на Lakehouse. Він дозволяє їм жити в одній екосистемі без дублювання даних — і це справжня цінність OneLake. Раніше lake і warehouse були окремими системами з окремими копіями даних. Тепер — єдине сховище, різні движки.
Практична порада: починай з визначення primary consumer. Хто буде читати ці дані — Spark-пайплайн чи Power BI звіт? Від відповіді на це питання і відштовхуйся при виборі артефакту для кожного шару архітектури.
Є компроміси, є контекст — і немає єдино правильної відповіді без розуміння конкретної ситуації.
FAQ: питання про Lakehouse і Warehouse у Microsoft Fabric
Питання: Що таке Lakehouse у Microsoft Fabric?
Відповідь: Lakehouse у Microsoft Fabric — це архітектура, що поєднує гнучкість data lake із можливостями аналітики data warehouse в єдиному середовищі на базі OneLake. Дані зберігаються у форматі Delta Lake і доступні через Apache Spark, SQL Endpoint або Jupyter notebooks. Lakehouse підтримує як структуровані Delta-таблиці, так і сирі файли в секції Files — CSV, JSON, Parquet. Це рішення підходить для сценаріїв із різнорідними даними, data engineering пайплайнами і ML-проєктами.
Питання: Як почати роботу з Lakehouse або Warehouse у Microsoft Fabric?
Відповідь: Для початку потрібен workspace у Microsoft Fabric із активною Fabric capacity або безкоштовним пробним періодом. Lakehouse створюється через розділ Data Engineering — туди можна завантажувати файли, підключати Data Pipelines і запускати Spark notebooks для трансформацій. Warehouse створюється через розділ Data Warehousing і одразу підтримує повноцінний T-SQL для створення таблиць, views і запитів. Обидва артефакти можуть існувати в одному workspace і читати дані з OneLake.
Питання: Lakehouse vs Warehouse у Fabric — чим вони відрізняються?
Відповідь: Warehouse у Fabric — це класичне реляційне сховище з повним T-SQL, транзакціями та строгою схемою, оптимізоване для структурованих даних і BI-звітності. Lakehouse орієнтований на гнучку обробку великих і різнорідних даних через Spark і SQL Endpoint без жорсткої схеми на вході. Головна відмінність — рівень контролю над схемою і спосіб обробки: Warehouse дає більше контролю через SQL, Lakehouse — більше гнучкості через Spark.
Питання: Які помилки роблять при виборі між Lakehouse і Warehouse у Fabric?
Відповідь: Найпоширеніша помилка — обирати Warehouse лише тому, що він «звичніший», навіть коли дані неструктуровані або надходять із багатьох джерел у сирому вигляді. Інша помилка — використовувати Lakehouse для суто BI-сценаріїв, де потрібні транзакції та строгий контроль схеми. Також часто плутають SQL Endpoint у Lakehouse із повноцінним Warehouse: SQL Endpoint підтримує тільки SELECT і не має stored procedures чи write-операцій через SQL.
Підсумок: data warehouse vs data lakehouse у Fabric — не конкуренти, а партнери
Lakehouse і Warehouse у Microsoft Fabric вирішують різні задачі. Lakehouse — гнучкий фундамент для data engineering, ML і обробки великих обсягів через Spark. Warehouse — контрольоване середовище для структурованої аналітики, BI-звітності і SQL-команд.
Вибір між ними — це вибір движка і моделі доступу, а не вибір де зберігати дані. Обидва використовують OneLake як основу, і саме це дає можливість поєднувати їх в одній архітектурі без дублювання.
У реальних проєктах питання «що обрати» найчастіше трансформується в питання «як правильно розподілити ролі між ними». Починайте з primary consumer — і архітектура стає очевиднішою.
Формат:онлайн 
Тривалість:2 місяці 
