Разбираемся в архитектуре Microsoft Fabric: Lakehouse и Warehouse

By Mirko Peters · 2026-08-27

Добро пожаловать обратно в блог! Если вы следите за нашими недавними выпусками подкаста, вы знаете, что мы подробно разбираем быстро меняющийся мир платформ данных, современной аналитики и корпоративной архитектуры. Проектирование аналитического ландшафта никогда не было универсальным решением, но с появлением Microsoft Fabric организации получают единую среду, которая объединяет инжиниринг данных

Automatically translated with AI from the original post. Read the English original

Добро пожаловать обратно в блог! Если вы следите за нашими недавними выпусками подкаста, вы знаете, что мы подробно разбираем быстро меняющийся мир платформ данных, современной аналитики и корпоративной архитектуры. Проектирование аналитического ландшафта никогда не было универсальным решением, но с появлением Microsoft Fabric организации получают единую среду, которая объединяет инжиниринг данных, хранилища данных, бизнес-аналитику и ИИ в рамках одной эксплуатационной платформы. Однако наличие единой платформы не означает, что архитектурного выбора не нужно делать. Одно из первых решений, с которым сталкиваются архитекторы данных и инженерные команды, когда начинают работу с Microsoft Fabric, — выбор между Lakehouse и хранилищем данных (Data Warehouse).

Это архитектурное решение лежит в основе того, как ваша организация хранит, обрабатывает и предоставляет данные. Стоит ли использовать гибкость и открытость Lakehouse или остаться при структурированной реляционной мощи традиционного хранилища данных? Чтобы по-настоящему разобраться в этом выборе, нужно снять слои с хранилища Microsoft Fabric, проанализировать, как навыки команды влияют на решение, и посмотреть, как современные форматы данных, такие как Delta Lake, соединяют эти два подхода. Давайте разберёмся в архитектуре Microsoft Fabric и выясним, как выбрать правильный путь для вашей организации.

Введение в варианты хранения в Microsoft Fabric

До появления Microsoft Fabric построение полноценной платформы данных часто означало сборку из отдельных сервисов Azure: настройка Azure Data Lake Storage, выделение выделенных пулов SQL, управление кластерами Azure Databricks и подключение рабочих областей Power BI. Такой подход был мощным, но часто приводил к изолированным хранилищам данных, избыточным копиям информации и административным издержкам при управлении безопасностью и вычислительными ресурсами в разрозненных сервисах.

Microsoft Fabric решает эту проблему фрагментации, вводя OneLake — единое SaaS-озеро данных с мультиарендной архитектурой, которое выступает в роли OneDrive для данных вашей организации. Всё в Fabric — будь то Lakehouse, хранилище данных, база данных KQL или семантическая модель Power BI — расположено поверх OneLake. В рамках этого единого слоя хранения организации могут выбирать, как структурировать свои аналитические данные и работать с ними. Два основных движка для хранения и запросов аналитических данных в Fabric — это Lakehouse и хранилище данных (Data Warehouse). Хотя они опираются на общие базовые технологии, они спроектированы под разные рабочие нагрузки, пользовательские роли и эксплуатационные модели.

Знакомство с Microsoft Fabric Lakehouse

Microsoft Fabric Lakehouse — это архитектурный шаблон для работы с данными, который объединяет лучшие элементы озёр данных и хранилищ данных в единой среде. Он оптимизирован как для файловых задач инжиниринга данных, так и для структурированных аналитических запросов, поэтому он пользуется популярностью у инженеров данных и специалистов по данным.

По своей сути Lakehouse в Fabric управляет файлами и папками так же, как традиционное озеро данных, но добавляет важный транзакционный слой на основе открытого формата Delta Parquet. Это означает, что неструктурированные данные (например, изображения, PDF-файлы, аудиофайлы и исходные JSON-логи) можно хранить рядом со структурированными и полуструктурированными табличными данными. Кроме того, Lakehouse нативно интегрируется с Apache Spark. Если ваша команда работает с блокнотами PySpark, распределёнными трансформациями данных и масштабным инжинирингом данных, Lakehouse становится идеальной площадкой. Он позволяет специалистам по данным выполнять сложные трансформации, обучать модели машинного обучения и строить надёжные конвейеры данных с помощью методологий, ориентированных на код.

Знакомство с Microsoft Fabric Data Warehouse

С другой стороны спектра находится Microsoft Fabric Data Warehouse. Если ваша организация многие годы работала с традиционными корпоративными хранилищами данных, SQL Server или выделенными аналитическими базами данных, Fabric Data Warehouse будет сразу казаться знакомым и привычным.

В отличие от Lakehouse, который объединяет разные форматы хранения и принимает неструктурированные файлы, Fabric Data Warehouse ориентирован строго на реляционные данные и структурированные таблицы. Он создан для высокопроизводительных запросов на T-SQL. Когда вы создаёте Warehouse в Fabric, вы получаете модель с раздельными хранилищем и вычислительными ресурсами, оптимизированную для реляционных операций, сложных соединений и отчётности в области бизнес-аналитики. Администраторы баз данных, SQL-разработчики и аналитики данных могут писать стандартные скрипты T-SQL, управлять схемами баз данных, создавать представления и применять хранимые процедуры, не изучая Spark и не настраивая конфигурации кластеров. Он обеспечивает предсказуемое управление, безопасность и транзакционную согласованность, которых традиционные команды корпоративных данных ожидают от корпоративного хранилища данных.

Ключевые архитектурные различия: Lakehouse и Warehouse

При сравнении Microsoft Fabric Lakehouse и Data Warehouse бок о бок различия выходят за рамки выбора между Spark и T-SQL. Понимание этих архитектурных отличий помогает командам не переусложнять решение и не выбирать модель хранения, которая идёт вразрез с их привычными рабочими процессами.

Во-первых, посмотрите на типы данных, которым отдаёт приоритет каждый вариант. Lakehouse работает со всем, от исходных неструктурированных документов до структурированных таблиц Delta. Data Warehouse строго оптимизирован для структурированных и полуструктурированных реляционных данных. Во-вторых, посмотрите на вычислительные движки. Lakehouse в значительной степени опирается на Apache Spark для обработки данных, тогда как Data Warehouse использует SQL-движок с массově-параллельной обработкой (MPP). В-третьих, обратите внимание на управление данными. Lakehouse обеспечивает открытый доступ к базовым файлам, позволяя специалистам по данным читать файлы Parquet напрямую с помощью внешних инструментов или библиотек Python. Warehouse более жёстко абстрагирует базовое хранилище, предоставляя понятный реляционный интерфейс SQL-базы данных, оптимизированный для аналитической отчётности и параллельной обработки запросов.

Согласование навыков команды с выбором хранилища

Архитектурное решение никогда не должно приниматься в отрыве от реальности: нужно учитывать практические навыки вашей команды. Технология настолько эффективна, насколько эффективны люди, которые с ней работают.

Если в вашей организации много разработчиков Power BI, традиционных администраторов баз данных и SQL-аналитиков, которые работают с T-SQL каждый день, принуждение их к архитектуре Lakehouse с упором на Spark может создать ненужную кривую обучения и замедлить поставку результатов. В этом сценарии Fabric Data Warehouse обеспечивает комфортный старт: ваши существующие SQL-специалисты сразу могут использовать текущий опыт. И наоборот, если в организации работают инженеры данных и специалисты по данным, которые свободно владеют Python, Scala и фреймворками распределённых вычислений, Lakehouse даёт им программную гибкость и вычислительный масштаб, необходимые для построения сложных конвейеров преобразования и решений в области ИИ. Выбор подходящего варианта хранения в Fabric означает честную оценку возможностей вашей команды и проектирование архитектуры, которая дает им силы, а не отталкивает их.

Работа с разными типами данных и нагрузками

Требования к нагрузкам и разнообразие данных часто становятся решающими факторами при выборе между Lakehouse и Data Warehouse в Microsoft Fabric. Не все данные поступают аккуратно организованными в реляционные таблицы, и не вся аналитика выглядит одинаково.

Если ваши конвейеры загрузки получают большие объёмы сырой телеметрии, потоков данных с IoT-датчиков, неструктурированных текстовых файлов и системных журналов, Lakehouse становится естественной зоной первичной загрузки. Он позволяет быстро записывать исходные данные на уровень Bronze архитектуры Medallion, обрабатывать их в блокнотах Spark и преобразовывать в чистые аналитические таблицы. С другой стороны, если основная нагрузка связана с обслуживанием панелей бизнес-аналитики с высокой параллельностью на основе чистых, хорошо структурированных измерений, Data Warehouse показывает себя лучше всего. Его движок T-SQL тонко настроен на выполнение сложных аналитических запросов с низкой задержкой, что гарантирует бизнес-пользователям быстрые и надёжные ответы из семантических моделей Power BI.

Использование формата Delta для единого хранилища

Один из самых удачных архитектурных решений Microsoft при создании Fabric — использование открытого формата Delta Parquet для всех структурированных таблиц. Этот выбор позволяет во многих отношениях стереть границы между Lakehouse и Warehouse.

Независимо от того, загружаются ли данные и обрабатываются ли они внутри Fabric Lakehouse с помощью PySpark или загружаются в Fabric Data Warehouse с помощью T-SQL, физические файлы, которые хранятся в OneLake, имеют формат таблиц Delta. Этот открытый стандарт хранения обеспечивает транзакции ACID, «путешествие во времени» и высокую производительность в обеих средах. Поскольку и Lakehouse, и Warehouse могут читать и записывать таблицы Delta, организациям больше не нужно беспокоиться о привязке к проприетарному хранилищу. Это означает, что инженер данных может подготовить данные с помощью Spark в Lakehouse, а SQL-разработчик может выполнять запросы к тем же самым таблицам с помощью T-SQL в Warehouse, без создания дублирующих физических копий данных.

Лучшие практики выбора подходящего решения в вашей организации

Планируя развертывание Microsoft Fabric, как вы решаете, внедрять ли Lakehouse, Warehouse или их комбинацию? Успешные организации, как правило, следуют нескольким основным лучшим практикам при проектировании сред Fabric.

Во-первых, при необходимости используйте гибридный подход. Microsoft Fabric спроектирован так, чтобы вы могли использовать Lakehouse и Warehouse бок о бок в рамках одной структуры клиента и рабочих областей. Lakehouse можно использовать для приема сырых данных, сложных трансформаций инженерии данных и задач data science, а витрины отчетности и общие согласованные измерения размещать в Data Warehouse. Во-вторых, используйте ярлыки OneLake, чтобы избежать ненужного перемещения и дублирования данных между доменами. В-третьих, всегда проектируйте решение с учетом потребителей: оценивайте типы собираемых данных, навыки специалистов, которые преобразуют данные, и требования к производительности для бизнес-пользователей, которые работают с итоговыми аналитическими выводами.

Чтобы услышать практический разбор того, как эти архитектурные компоненты связаны между собой — от приема сырых данных до принятия управленческих решений, — обязательно послушайте наш связанный выпуск подкаста Microsoft Fabric End-to-End: From Raw Data to Business Decisions with Amit Chandak [MVP]. В этом выпуске Амит рассказывает, как организации могут использовать OneLake, разбираться в выборе между Lakehouse и Warehouse, оптимизировать трансформации и создавать масштабируемые аналитические решения, которые помогают как людям, принимающим решения, так и AI-сценариям.