Коротко: OneLake — це централізоване хмарне сховище даних, вбудоване в Microsoft Fabric, яке автоматично об’єднує всі аналітичні артефакти організації в одному просторі. Побудоване на Azure Data Lake Storage Gen2, воно зберігає дані у відкритому форматі Delta Lake / Parquet і підтримує підключення зовнішніх джерел через Shortcuts. Стаття для дата-інженерів і аналітиків, які хочуть зрозуміти, як OneLake влаштований зсередини і де його реальні межі.
Вступ
Більшість data-команд рано чи пізно стикаються з однією і тією ж проблемою: дані розкидані між десятками сховищ. S3 для одного продукту, ADLS для іншого, окремий DWH, окремий data lake, ще й кілька баз у різних хмарах. Управляти цим — окрема повноцінна робота.
Microsoft Fabric OneLake намагається вирішити цю проблему структурно: один тенант — одне логічне сховище для всієї організації. Усі Fabric-сервіси пишуть туди автоматично, зовнішні джерела підключаються через Shortcuts, а формат зберігання — відкритий Delta Lake / Parquet.
У цій статті розберемо, як OneLake влаштований фізично і логічно, як працюють Shortcuts, як організувати medallion-архітектуру і яких помилок варто уникати з самого початку.
Що таке OneLake і чому це інший підхід до зберігання даних?
Від роздробленості до єдиного сховища: контекст проблеми
Класичний сценарій у середній компанії: аналітична команда має доступ до п’яти різних сховищ, кожне з власними правилами доступу, форматами і пайплайнами синхронізації. Щоб зрозуміти, де “правильна” версія даних, потрібно спочатку розібратися, яке сховище є джерелом правди.
OneLake вирішує це концептуально. Аналогія проста: як OneDrive — єдине місце для файлів користувача, OneLake — єдине місце для даних організації. Один тенант Microsoft Fabric отримує один OneLake. Усі workspace-и і всі артефакти всередині них автоматично пишуть у це сховище.
OneLake є storage-фундаментом для lakehouse-підходу у Fabric. Сам підхід lakehouse реалізується через Lakehouse items: вони поєднують структуровані таблиці з ACID-транзакціями та зберігання файлів різних форматів в одному просторі.
OneLake як фундамент Microsoft Fabric
Усуваючи data silos, OneLake спрощує governance і знижує операційні витрати на переміщення даних між системами. Але важливо розуміти: OneLake — це фундамент платформи, а не окремий продукт. Він існує тільки в контексті Microsoft Fabric.
Як влаштована OneLake архітектура зсередини?
Фізичний рівень: ADLS Gen2 як основа
OneLake фізично базується на Azure Data Lake Storage Gen2. Це означає, що під капотом ви отримуєте перевірену інфраструктуру: ієрархічний простір імен, підтримку великих обсягів даних і нативну інтеграцію з Azure-екосистемою.
Але OneLake — це не просто ADLS Gen2 з іншою назвою. Поверх фізичного рівня Microsoft додав логічний шар: уніфіковане управління, автоматичну інтеграцію з усіма Fabric-сервісами і єдину модель безпеки.
Логічна організація: тенант → workspace → item
Ієрархія OneLake виглядає так:
- Тенант — весь OneLake організації. Один тенант Fabric = один OneLake.
- Workspace — логічний контейнер для проєктів або команд. Аналог папки верхнього рівня.
- Item — конкретний артефакт: Lakehouse, Warehouse, Eventhouse тощо. Кожен item автоматично отримує власний розділ у OneLake без ручного налаштування.
Ця ієрархія важлива для розуміння того, як налаштовувати доступ і як організовувати дані між командами.
Delta Lake і Parquet: чому відкритий формат — це стратегічне рішення
У Fabric Lakehouse структуровані таблиці зазвичай зберігаються як Delta/Parquet, а Files/ можуть містити довільні формати. OneLake загалом розвивається як логічний data lake для відкритих форматів, зокрема Delta Lake і Iceberg, тому важливо розрізняти OneLake як storage layer і Lakehouse/Warehouse як аналітичні items поверх нього.
Parquet — колонковий формат. У аналітичних запитах, де потрібно прочитати 3-5 колонок із таблиці з сотнями мільйонів рядків, це може суттєво зменшити обсяг даних, які реально читаються з диска.
Delta Lake додає до Parquet transaction log — директорію _delta_log, де зберігається вся історія змін. Це дає ACID-транзакції, schema evolution і можливість time travel: запит даних станом на будь-який момент у минулому.
Стратегічна перевага: формат Delta / Parquet читається зовнішніми інструментами напряму. Якщо завтра ви захочете підключити Databricks або Apache Spark поза Fabric — дані залишаться доступними без конвертації.
Як різні Fabric-артефакти пишуть у OneLake
| Артефакт | Тип даних | Формат у OneLake | Основний use case |
|---|---|---|---|
| Lakehouse | Структуровані + неструктуровані | Delta (Tables/) + будь-який (Files/) | Data engineering, ML-підготовка |
| Warehouse | Структуровані | Delta Parquet | SQL-аналітика, звітність |
| Eventhouse / KQL Database | Часові ряди, логи | Власний формат (Kusto) + Delta export | Real-time аналітика |
| Power BI semantic model (Direct Lake) | Структуровані | Читає з Delta напряму | BI та дашборди |
Структура папок у Lakehouse виглядає так:
MyLakehouse.Lakehouse/
├── Tables/
│ ├── sales/
│ │ ├── _delta_log/
│ │ │ └── 00000000000000000000.json
│ │ ├── part-00000-abc123.snappy.parquet
│ │ └── part-00001-def456.snappy.parquet
│ └── customers/
│ ├── _delta_log/
│ └── part-00000-xyz789.snappy.parquet
└── Files/
├── raw/
│ └── orders_2024_01.csv
└── exports/
└── report.json
Tables/ — зона для таблиць, насамперед Delta-таблиць у типових lakehouse-сценаріях. Саме Delta-таблиці дають transaction log, time travel і ACID-переваги. Files/ — зона для довільних файлів.
Що таке OneLake Shortcuts і як вони працюють?
Shortcuts як ‘портали’ до зовнішніх даних
Shortcuts — одна з найпотужніших і водночас найменш зрозумілих фіч OneLake архітектури. Суть проста: ви бачите дані у OneLake, але фізично вони залишаються у зовнішньому сховищі.
Жодного переміщення або копіювання. Shortcut — це логічне посилання з делегованою авторизацією. Fabric виступає проксі: отримує запит від користувача, авторизується у зовнішньому сховищі через service principal або managed identity і повертає дані.
Підтримувані джерела: AWS S3, GCS, ADLS Gen2, Dataverse та інші
OneLake підтримує shortcuts до наступних джерел:
- Azure Data Lake Storage Gen2 — GA
- AWS S3 — GA
- S3-compatible storage, зокрема Cloudflare R2 або MinIO — GA
- Google Cloud Storage — GA
- Microsoft Dataverse — доступний через Dataverse integration; Dataverse shortcuts є read-only
- OneDrive та SharePoint Folder — preview як джерела shortcuts у lakehouse, з актуальними покращеннями автентифікації
- On-premises і network-restricted джерела — через Fabric on-premises data gateway, GA для підтримуваних типів shortcut
- OneLake-to-OneLake — для cross-workspace sharing без копіювання
Типова ситуація в командах: компанія роками накопичувала дані в AWS S3 і хоче почати використовувати Microsoft Fabric для аналітики. Shortcuts дозволяють підключити S3-бакети до OneLake і одразу почати роботу — без міграції даних і без подвійних витрат на зберігання.
Shortcuts vs копіювання: коли що обирати
Shortcuts — розумний компроміс між гнучкістю та продуктивністю. Але є нюанси.
Коли shortcuts — правильний вибір:
– Поступова міграція: читаєте з S3, поступово переносите дані в OneLake
– Федеративний доступ: дані мають залишатися у першоджерелі за вимогами compliance
– Cross-workspace sharing: одні й ті самі дані потрібні кільком командам без дублювання
– Мультиклаудна аналітика: дані в різних хмарах, аналітика в одному місці
Коли краще скопіювати дані:
– Критичні аналітичні навантаження, де latency shortcuts недопустима
– Дані часто трансформуються — нативні Delta-таблиці дають більше можливостей оптимізації
– Потрібен повний контроль над форматом і партиціонуванням
Деякі Spark-операції на shortcuts працюють повільніше, ніж на нативних даних у OneLake. Це не критично для більшості сценаріїв, але варто враховувати при проєктуванні продуктивних пайплайнів.
Medallion-архітектура у OneLake: Bronze, Silver, Gold на практиці
Чому medallion — це не просто модний термін
Medallion-архітектура — рекомендований Microsoft патерн для організації даних у OneLake. Три шари з чіткими обов’язками:
- Bronze — сирі дані як є. Мінімальна обробка, максимальне збереження. Append-only: нічого не видаляємо, нічого не змінюємо.
- Silver — очищені, нормалізовані дані. Тут відбуваються joins, дедуплікація, базові трансформації. Дані вже придатні для аналізу.
- Gold — агрегати і бізнес-метрики, готові для споживання Power BI, ML-моделями або кінцевими API.
Ця структура вирішує конкретну проблему: коли дані з різних джерел змішані в одному місці без чіткого розмежування, якість даних деградує, а налагодження пайплайнів перетворюється на детективну роботу.
Як організувати шари у OneLake: workspace vs Lakehouse
Два підходи, кожен зі своїми компромісами.
Варіант 1: окремий Lakehouse для кожного шару
Workspace: DataPlatform
├── Bronze_Lakehouse
│ └── Tables/
│ ├── raw_orders/
│ └── raw_customers/
├── Silver_Lakehouse
│ └── Tables/
│ ├── orders_cleaned/
│ └── customers_deduplicated/
└── Gold_Lakehouse
└── Tables/
├── sales_summary/
└── customer_ltv/
Переваги: ізоляція доступу між шарами, чіткі межі відповідальності, незалежне масштабування. Недолік: більше артефактів для управління.
Варіант 2: один Lakehouse з папками-шарами
Простіше для початку, але ускладнює ізоляцію доступу. Підходить для невеликих команд або пілотних проєктів.
Практична порада: починайте з одного Lakehouse. Розділяйте на окремі тільки тоді, коли є реальна потреба в ізоляції доступу або незалежному масштабуванні.
Пайплайни для просування даних між шарами
Основні інструменти для переміщення даних між шарами:
# Приклад: просування даних з Bronze до Silver через PySpark у Fabric Notebook
from pyspark.sql import functions as F
from delta.tables import DeltaTable
# Шляхи до Bronze та Silver Lakehouse у OneLake
# Замініть workspace_name, Bronze_Lakehouse і Silver_Lakehouse на ваші реальні назви
bronze_path = (
"abfss://workspace_name@onelake.dfs.fabric.microsoft.com/"
"Bronze_Lakehouse.Lakehouse/Tables/raw_orders"
)
silver_path = (
"abfss://workspace_name@onelake.dfs.fabric.microsoft.com/"
"Silver_Lakehouse.Lakehouse/Tables/orders_cleaned"
)
# 1. Читаємо сирі дані з Bronze-шару
bronze_df = spark.read.format("delta").load(bronze_path)
# 2. Виконуємо базові трансформації для Silver-шару
silver_df = (
bronze_df
.dropDuplicates(["order_id"])
.filter(F.col("order_status").isNotNull())
.withColumn("order_date", F.to_date(F.col("order_date_str"), "yyyy-MM-dd"))
.drop("order_date_str", "_ingestion_timestamp")
)
# 3. Якщо Silver Delta-таблиця вже існує — виконуємо upsert через MERGE.
# Якщо таблиці ще немає — створюємо її першим записом.
if DeltaTable.isDeltaTable(spark, silver_path):
silver_table = DeltaTable.forPath(spark, silver_path)
(
silver_table.alias("target")
.merge(
silver_df.alias("source"),
"target.order_id = source.order_id"
)
.whenMatchedUpdateAll()
.whenNotMatchedInsertAll()
.execute()
)
else:
(
silver_df.write
.format("delta")
.mode("overwrite")
.save(silver_path)
)
print("Дані успішно просунуті з Bronze до Silver.")Fabric Data Factory і Spark Notebooks — два основні інструменти для побудови таких пайплайнів. А якщо ви хочете навчитись будувати повноцінну інфраструктуру даних з нуля, спеціалізація Analytics & Data Engineer охоплює саме цей стек: від проєктування архітектури до написання продуктивних пайплайнів.
Як OneLake керує безпекою та доступом до даних?
OneLake security: один периметр безпеки для всіх даних
Аутентифікація у Microsoft Fabric OneLake відбувається через Microsoft Entra ID (колишній Azure AD). Один identity provider для всього: користувачі, сервісні акаунти, managed identities.
Це спрощує управління, але водночас підвищує ставки: компрометація облікового запису Entra ID дає доступ до всього, що цей акаунт може бачити у Fabric.
Рівні доступу: workspace, item, row-level і column-level security
Система доступу в OneLake багаторівнева:
- Workspace roles — Admin, Member, Contributor, Viewer. Базовий рівень: визначає, що користувач може робити з усіма артефактами у workspace.
- Item-level permissions — доступ до конкретного Lakehouse або Warehouse без доступу до всього workspace. Корисно, коли різні команди мають різні потреби.
- Row-level security (RLS) і column-level security (CLS) — можуть реалізовуватись через Power BI semantic models, Warehouse/SQL security або через OneLake Security preview залежно від item і сценарію доступу. Важливо тестувати enforcement окремо для Spark, SQL Endpoint, Power BI Direct Lake та зовнішніх engines, бо модель доступу залежить від ролей workspace, item permissions і підтримки конкретного engine.
- OneLake Data Access Control — OneLake Security, раніше відома в матеріалах як OneSecurity, — це напрям розвитку granular access control у OneLake. Станом на 2026 частина можливостей, зокрема OneLake security roles для tables/folders, RLS і CLS, перебуває у preview, тому перед продакшен-впровадженням потрібно перевіряти актуальний статус у документації Microsoft.
Типова помилка: давати широкі workspace-права замість гранульованих item-permissions. Результат — або надлишковий доступ до чутливих даних, або заблоковані колеги, яким потрібен доступ лише до одного Lakehouse.
Чому централізоване сховище потребує зрілого Data Governance
Централізація даних — це не тільки технічна, а й організаційна задача. Коли всі дані організації опиняються в одному місці, ціна неправильного налаштування доступу зростає пропорційно.
Без чітких правил governance централізоване сховище може перетворитися на “data swamp” — місце, де дані є, але ніхто не розуміє, що де лежить і кому належить.
Практичні рекомендації для старту:
– Принцип least privilege: давайте мінімально необхідний доступ
– Регулярний аудит прав доступу — хто і до чого має доступ
– Data classification: позначайте чутливі дані через Microsoft Purview
Типові помилки та реальні обмеження OneLake, про які мовчать у маркетингових матеріалах
Обмеження, які важливо знати до початку проєкту
OneLake — аналітичне сховище, а не транзакційне. Якщо потрібна OLTP-база з мілісекундними відповідями на точкові запити — OneLake для цього не підходить. Для real-time сценаріїв із sub-second latency у Fabric є Eventhouse / KQL Database.
Delta Lake small files problem. Потоковий запис із частими мікробатчами може генерувати тисячі дрібних Parquet-файлів. Це уповільнює читання і збільшує навантаження на transaction log. Вирішення — регулярні операції OPTIMIZE і VACUUM.
Shortcuts мають обмеження продуктивності. Деякі Spark-операції на shortcuts можуть бути повільнішими, ніж на нативних даних у OneLake. Для критичних аналітичних навантажень варто оцінювати продуктивність окремо.
Vendor tie-in на рівні платформи. Формат Delta / Parquet відкритий, але екосистема Fabric прив’язує до Microsoft-інструментів. Перехід на іншу платформу — це не просто перенесення файлів, а переналаштування всіх пайплайнів, ролей і інтеграцій.
Помилки у проєктуванні, які коштують дорого
Помилка #1: зберігати все у Files/ замість Tables/. Ви втрачаєте версіонування, time travel і оптимізацію запитів Delta Lake. Якщо дані структуровані — використовуйте Tables/.
Помилка #2: ігнорувати партиціонування. Великі таблиці без партиціонування за датою або іншим ключем фільтрації — це повне сканування таблиці на кожен запит.
Помилка #3: не запускати VACUUM і OPTIMIZE. Transaction log і дрібні файли накопичуються. Через кілька місяців активної роботи це помітно впливає на продуктивність.
-- Виконувати у Fabric Notebook / Spark SQL, а не в SQL Analytics Endpoint
OPTIMIZE sales_summary
WHERE order_date >= '2025-01-01'
VORDER;
-- Очищення старих версій Delta-файлів
VACUUM sales_summary RETAIN 168 HOURS;Помилка #4: плутати workspace roles з item permissions. Workspace roles — широкий доступ до всього workspace. Item permissions — точковий доступ до конкретного артефакту. Для більшості сценаріїв правильна комбінація — мінімальні workspace roles плюс точні item permissions.
FAQ: питання про OneLake та Microsoft Fabric
Питання: Що таке OneLake у Microsoft Fabric?
Відповідь: OneLake — це єдине централізоване хмарне сховище даних, вбудоване в платформу Microsoft Fabric, яке автоматично доступне для всіх сервісів екосистеми. Воно побудоване на базі Azure Data Lake Storage Gen2 і зберігає структуровані дані у відкритому форматі Delta Parquet. Завдяки цьому організація має одне джерело правди замість розрізнених сховищ. Усі Fabric-артефакти — Lakehouse, Warehouse, Eventhouse — автоматично пишуть у OneLake без додаткового налаштування.
Питання: Як почати роботу з OneLake у Microsoft Fabric?
Відповідь: Щоб почати роботу з OneLake, достатньо створити Workspace у Microsoft Fabric — OneLake активується автоматично. Далі підключайте Lakehouse, Warehouse або Dataflow, і всі дані зберігатимуться в єдиному просторі. Для доступу до файлів можна використовувати OneLake Explorer, Azure Storage Explorer або ABFS API. Перший практичний крок — створити Lakehouse, завантажити тестові дані у Files/ і перетворити їх на Delta-таблицю через Spark Notebook.
Питання: OneLake vs Azure Data Lake Storage — у чому різниця?
Відповідь: ADLS Gen2 — інфраструктурний сервіс зберігання, який потребує ручного налаштування доступу, безпеки та інтеграцій з кожним інструментом окремо. OneLake побудований поверх ADLS Gen2, але додає рівень абстракції: автоматичну інтеграцію з усіма сервісами Fabric, Shortcuts для посилань на зовнішні дані та єдину модель управління доступом. Простіше кажучи, OneLake — це ADLS Gen2 з керованою надбудовою для аналітичних команд, де більшість інфраструктурних завдань вирішені за замовчуванням.
Питання: Скільки коштує використання OneLake у Microsoft Fabric?
Відповідь: OneLake не є окремим продуктом із власною підпискою, але зберігання даних у OneLake тарифікується окремо від Fabric compute capacity. Орієнтовна ціна для OneLake storage — близько $0.023 за GB/month у US West 2, але фінальну суму потрібно перевіряти в Azure Pricing Calculator з урахуванням регіону, BCDR, cache, retention і можливого data transfer.
Питання: Які помилки роблять при роботі з OneLake?
Відповідь: Найпоширеніша помилка — дублювання даних замість використання Shortcuts, що призводить до зайвих витрат на зберігання і проблем із консистентністю. Команди також часто ігнорують medallion-архітектуру і зберігають усе в одному шарі, ускладнюючи управління якістю даних. Ще одна типова проблема — зберігати структуровані дані у Files/ замість Tables/, втрачаючи переваги Delta Lake. І майже завжди недооцінюють важливість регулярного OPTIMIZE та VACUUM для підтримки продуктивності.
Висновок: OneLake як ключовий інструмент сучасного дата-інженера
OneLake — це не черговий маркетинговий ребрендинг хмарного сховища. Це архітектурне рішення, яке об’єднує розрізнені аналітичні інструменти навколо єдиного джерела даних із відкритим форматом і централізованим управлінням доступом.
Для дата-інженера це означає менше часу на синхронізацію між сховищами і більше — на побудову якісних пайплайнів. Для аналітика — одне місце, де лежать усі дані організації. Для команди загалом — спрощений governance і менше операційного боргу.
Формат:онлайн 
Тривалість:2 місяці 
