Справочник

Запрос к массивной (500М+ строк) таблице Delta в Fabric lakehouse с оптимальной производительностью и доступом к данным почти в реальном времени.

→Используйте семантическую модель в режиме Direct Lake.

Почему: Direct Lake считывает Parquet-файлы напрямую из OneLake, минуя импорт данных или трансляцию запросов. Он обеспечивает производительность, аналогичную режиму Import, без дублирования данных или задержки обновления. DirectQuery работает медленнее; режим Import вносит задержку.

Применение общих расчетов временной аналитики (YTD, QTD, MTD) к десяткам базовых мер (Sales, Profit, Quantity) без создания сотен мер DAX.

→Реализуйте группу вычислений с элементами вычислений для YTD, QTD и MTD.

Почему: Группы вычислений устраняют разрастание мер. Они определяют набор общих вычислений, которые могут динамически применяться к любой выбранной мере, значительно упрощая поддержку модели.

Несколько семантических моделей в рабочей области должны совместно использовать общие таблицы измерений (например, Date, Customer) для обеспечения согласованности и сокращения дублирования данных.

→Создайте "основную" семантическую модель, содержащую общие измерения. Создайте другие "составные" модели, которые подключаются к основной модели через DirectQuery и к таблицам фактов через Direct Lake/Import.

Почему: Эта архитектура "звезда" способствует созданию единого источника истины для измерений. Составные модели позволяют комбинировать данные из разных источников и режимов хранения в унифицированную модель.

Таблица фактов имеет несколько столбцов дат (например, OrderDate, ShipDate), которые должны быть связаны с одной таблицей измерения Date.

→Создайте одно активное и несколько неактивных отношений между таблицами фактов и дат. Используйте функцию DAX `USERELATIONSHIP()` в мерах для активации соответствующего неактивного отношения.

Почему: Power BI позволяет только одно активное отношение между двумя таблицами. Этот шаблон позволяет анализировать данные по разным ролям дат без дублирования таблицы измерений.

Семантическая модель с большой таблицей фактов (миллиарды строк) слишком долго обновляется. Только данные за последние 30 дней часто меняются.

→Настройте инкрементное обновление для таблицы фактов. Установите параметры `RangeStart` и `RangeEnd`. Определите политику для архивации старых данных (например, хранение данных за последние 5 лет) и обновления недавних данных (например, обновление данных за последние 30 дней).

Почему: Это значительно сокращает время обновления и потребление ресурсов, поскольку обрабатываются только разделы, содержащие новые или измененные данные, вместо перезагрузки всей таблицы.

Сложная мера DAX работает медленно, потому что она многократно вычисляет одно и то же промежуточное значение в своей формуле.

→Используйте переменные (`VAR`) для однократного сохранения результата промежуточного вычисления, а затем ссылайтесь на эту переменную несколько раз в операторе `RETURN`.

Почему: Переменные предотвращают повторную оценку одного и того же логического блока движком несколько раз в рамках одного выполнения меры, что значительно улучшает производительность, особенно в итеративных контекстах.

Создание меры для расчета процентного вклада значения (например, продаж продукта) в более крупную общую сумму (например, все продажи продукта) с учетом других фильтров (например, даты).

→Используйте `DIVIDE([Sales], CALCULATE([Sales], ALLEXCEPT(Product, Product[Category])))` для процента от категории или `CALCULATE([Sales], ALL(Product))` для процента от общей суммы.

Почему: `CALCULATE` в сочетании с `ALL`, `ALLEXCEPT` или `REMOVEFILTERS` позволяет изменять контекст фильтра для получения правильного знаменателя для расчета процента.

Отчету нужен срез, который позволяет пользователям выбирать, какую метрику (например, "Выручка", "Стоимость", "Прибыль") должен отображать визуальный элемент.

→Создайте несвязанную таблицу с названиями метрик. Создайте единую меру DAX, используя `SWITCH(SELECTEDVALUE(MetricTable[Metric]), "Revenue", [Total Revenue], "Cost", [Total Cost], ...)` .

Почему: Этот шаблон, часто использующий Field Parameter, предоставляет динамичный и удобный способ переключения вычислений без необходимости использования закладок или нескольких визуальных элементов, делая отчеты более интерактивными и лаконичными.

Команде корпоративной BI необходимо использовать профессиональные инструменты (например, Visual Studio, Tabular Editor, SQL Profiler) для управления, развертывания и устранения неполадок семантической модели Fabric.

→Включите конечную точку XMLA Read/Write для рабочей области.

Почему: Конечная точка XMLA представляет семантическую модель как стандартный экземпляр Analysis Services, обеспечивая подключение из широкой экосистемы передовых инструментов BI и ALM для программного доступа и сложных задач моделирования.

Модель Direct Lake работает медленно. Исследование показывает, что она переключается в режим DirectQuery.

→Используйте DAX Studio или Performance Analyzer для выявления запроса, вызывающего откат. Общие причины включают неподдерживаемые функции DAX, сложный RLS или неоптимизированный/устаревший lakehouse.

Почему: Direct Lake имеет ограничения. Когда запрос использует неподдерживаемую функцию, он незаметно переключается на более медленный движок DirectQuery. Выявление и устранение основной причины (например, оптимизация DAX, выполнение OPTIMIZE для таблицы Delta) является ключом к восстановлению производительности.

Модель имеет отношение "многие ко многим" (например, Sales и Promotions через промежуточную таблицу). Меры возвращают неверные итоговые значения при фильтрации по стороне "многие".

→Убедитесь, что направление кросс-фильтрации в отношениях (Dimension -> Bridge -> Fact) настроено правильно (обычно однонаправленное). При необходимости используйте функции DAX, такие как `TREATAS` или `INTERSECT`, для более сложных вычислений M2M.

Почему: Неправильное направление кросс-фильтрации является частой причиной неверных результатов в моделях M2M. Хотя двунаправленная фильтрация может показаться работающей, она часто приводит к неоднозначности и двойному подсчету. Хорошо определенная модель с явными шаблонами DAX более надежна.

Композитная модель, использующая DirectQuery к массивной таблице фактов, работает медленно. Большинство пользовательских запросов находятся на агрегированном уровне (например, ежемесячные продажи по категориям).

→Создайте агрегированную таблицу, определенную пользователем, в режиме Import. Агрегированная таблица должна содержать предварительно суммированные данные на уровне детализации общих запросов (Month, Category).

Почему: Движок запросов будет автоматически перенаправлять запросы на меньшую, находящуюся в памяти агрегированную таблицу, когда это возможно, обеспечивая значительное повышение производительности. Он будет обращаться к источнику DirectQuery только для запросов, требующих более низкого уровня детализации.

Вычисление сложных нарастающих итогов или скользящих средних в DAX, которые плохо работают с традиционными подходами на основе фильтров.

→Используйте оконные функции DAX, такие как `WINDOW` или `OFFSET`.

Почему: Эти функции специально оптимизированы для позиционных вычислений над отсортированным набором строк. Они часто более производительны и синтаксически проще, чем старые шаблоны, которые полагаются на интенсивную фильтрацию и переходы контекста.

Расчет итоговых значений с начала года (YTD) для компании с финансовым годом, начинающимся 1 июля.

→Используйте функции `TOTALYTD` или `DATESYTD` с необязательным параметром `YearEndDate`. Пример: `TOTALYTD([Sales], 'Date'[Date], "6/30")` .

Почему: Указание параметра даты окончания года является правильным и самым простым способом сделать функции временной аналитики DAX осведомленными о пользовательском финансовом календаре.

Продвижение семантической модели через стадии Dev, Test и Prod, где каждая стадия имеет разную строку подключения к базе данных.

→Используйте конвейеры развертывания Fabric с правилами развертывания.

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

Источник↗

Реализация децентрализованной архитектуры data mesh, где бизнес-домены владеют и управляют собственными продуктами данных.

→Создайте рабочие области, специфичные для доменов. Используйте ярлыки OneLake для обеспечения обмена данными между доменами и их потребления без централизации владения данными.

Почему: Этот шаблон соответствует принципам data mesh, таким как владение доменом и данные как продукт. Рабочие области обеспечивают границы владения, а ярлыки — уровень взаимодействия.

Команде разработчиков необходимо совместно работать над элементами Fabric (семантические модели, отчеты, ноутбуки) с контролем версий и историей изменений.

→Настройте интеграцию Git для рабочей области Fabric, подключив ее к репозиторию Azure DevOps или GitHub.

Почему: Интеграция Git хранит определения элементов Fabric в виде текстовых файлов (JSON, TMDL), что позволяет использовать стандартные практики DevOps, такие как ветвление, запросы на слияние и отслеживание версий. Это необходимо для управления жизненным циклом приложений (ALM) корпоративного уровня.

Перед изменением таблицы lakehouse инженер должен определить все последующие отчеты и семантические модели, которые будут затронуты.

→Используйте представление Lineage View и выберите "Impact analysis" для элемента lakehouse.

Почему: Эта функция предоставляет полное, автоматизированное представление всех зависимостей. Это критически важный инструмент управления для изменения в сложной аналитической среде, предотвращающий неожиданные поломки.

Команде необходимо осуществлять контроль версий семантической модели в текстовом, удобочитаемом формате, который легко сравнивать и объединять.

→Сохраните файл Power BI как Power BI Project (.pbip). Это сохраняет определение модели в формате Tabular Model Definition Language (TMDL).

Почему: TMDL — это удобный для разработчиков формат, который представляет модель в виде структуры папок с отдельными текстовыми файлами для таблиц, мер и т. д. Это значительно превосходит бинарный файл .bim для совместной работы на основе Git и CI/CD.

Реализация архитектуры Medallion (Bronze, Silver, Gold) и необходимость доступа к данным между слоями без физического дублирования данных.

→Используйте ярлыки OneLake для ссылки на данные в других lakehouse или слоях.

Почему: Ярлыки — это символические ссылки в OneLake. Они обеспечивают унифицированное пространство имен и позволяют получать доступ к данным без копирования, что идеально подходит для логической сетки данных или архитектуры Medallion.

Источник↗

Миграция существующей аналитической рабочей нагрузки, интенсивно использующей T-SQL, из Azure Synapse в Fabric.

→Используйте Fabric Data Warehouse.

Почему: Fabric Warehouse предлагает полную совместимость с T-SQL, что делает его идеальной целью для миграции существующих SQL-скриптов, хранимых процедур и аналитических запросов с минимальными изменениями. Конечная точка Lakehouse SQL имеет доступ T-SQL только для чтения и использует Spark SQL для операций записи.

Прием и запрос больших объемов высокоскоростных потоковых данных (например, телеметрии IoT) с задержкой менее секунды.

→Используйте Fabric Eventstream для приема и KQL Database для хранения и анализа.

Почему: Это специализированный стек потоковой аналитики в Fabric. KQL (Kusto Query Language) оптимизирован для анализа временных рядов в потоковых данных, предлагая значительно меньшую задержку, чем пакетные lakehouse или warehouse.

Реализация Slowly Changing Dimension (SCD) Type 2 для поддержания полной истории изменений измерений в lakehouse.

→Используйте оператор `MERGE INTO` в Spark-ноутбуке или конвейере. Сопоставьте по бизнес-ключу; `WHEN MATCHED` обновляет старую запись (устанавливает `IsCurrent` в false, `EndDate` на текущее время); `WHEN NOT MATCHED` вставляет новую запись.

Почему: Операция `MERGE` в Delta Lake обеспечивает атомарные возможности upsert, что делает ее стандартным и наиболее эффективным способом реализации логики SCD в Fabric lakehouse.

Репликация данных почти в реальном времени из операционной базы данных (например, Azure SQL DB) в Fabric lakehouse для аналитики.

→Используйте Fabric Mirroring.

Почему: Mirroring — это решение для захвата измененных данных (CDC) с низкой задержкой и низким влиянием, встроенное в Fabric. Оно автоматически реплицирует изменения данных и схемы в OneLake в виде таблиц Delta, устраняя необходимость в сложных конвейерах ETL.

Прием и преобразование сложных, вложенных данных JSON из API в плоскую, структурированную таблицу Delta.

→Используйте PySpark-ноутбук. Применяйте функции, такие как `from_json`, для разбора схемы и `explode` для преобразования массивов в строки.

Почему: PySpark предоставляет самые мощные и гибкие инструменты для программной обработки сложных и изменяющихся структур JSON, намного превосходящие возможности стандартной операции копирования.

Прием данных в Fabric из локальной базы данных SQL Server, расположенной за корпоративным брандмауэром.

→Установите и настройте локальный шлюз данных на сервере в локальной сети. Добавьте шлюз в качестве источника данных в Fabric.

Почему: Шлюз действует как безопасный мост, передавая запросы и данные между облачными службами Fabric и локальными источниками данных без необходимости открывать входящие порты брандмауэра.

Производительность запросов к большой, часто обновляемой таблице Delta ухудшилась из-за накопления множества мелких файлов данных.

→Выполните команду `OPTIMIZE` для уплотнения мелких файлов в более крупные. Опционально используйте `ZORDER BY` на часто фильтруемых столбцах для совместного размещения связанных данных.

Почему: Меньшее количество более крупных файлов значительно эффективнее для чтения Spark. Z-упорядочивание улучшает пропуск данных, позволяя запросам считывать еще меньше данных. Это критически важная задача обслуживания для таблиц Delta.

Агрегирование потоковых данных временных рядов в фиксированные, непересекающиеся временные интервалы (например, средняя температура с датчика каждые 5 минут).

→Используйте KQL-запрос с оператором `summarize` и функцией `bin()`. Пример: `SensorData | summarize avg(temperature) by sensor_id, bin(timestamp, 5m)` .

Почему: Функция `bin()` является стандартным, высокооптимизированным способом в KQL для группировки событий в фиксированные временные интервалы (tumbling windows) для агрегирования.

Обновление Dataflow Gen2 происходит медленно. Источником данных является реляционная база данных, такая как Azure SQL.

→Просмотрите шаги преобразования в редакторе Power Query, чтобы убедиться, что свертывание запросов активно. Переупорядочите или измените шаги, чтобы максимально использовать свертывание.

Почему: Свертывание запросов переносит логику преобразования обратно в исходную базу данных для выполнения в виде единого нативного запроса. Это значительно эффективнее, чем вытягивание всех необработанных данных в движок Dataflow и их преобразование в памяти.

Spark-ноутбук выполняет медленное соединение между очень большой таблицей фактов (миллиарды строк) и небольшой таблицей измерений (тысячи строк).

→Используйте broadcast join, предоставив подсказку (`spark.sql.functions.broadcast`) или позволив оптимизатору выбрать на основе статистики.

Почему: Broadcasting отправляет всю небольшую таблицу на каждый узел-исполнитель. Это позволяет избежать дорогостоящей операции "shuffle", при которой данные большой таблицы должны быть перераспределены и отправлены по сети, что значительно улучшает производительность.

Конвейер данных оркеструет несколько действий. Одно действие может завершиться сбоем, но последующие, независимые действия должны все равно выполняться, а общий сбой должен быть зарегистрирован.

→Настройте зависимости действий. Действия, которые должны выполняться независимо от результата, должны зависеть от предыдущего действия с условием "Completion".

Почему: Это позволяет создавать надежные, параллельные пути выполнения. Вы можете создавать отдельные ветви для условий "Succeeded" (успех) и "Failed" (сбой) для реализации пользовательской логики ведения журнала или уведомлений.

Конвейер для инкрементной загрузки данных из источника с отметкой времени `last_modified`.

→Реализуйте шаблон водяного знака. Сохраните `max(last_modified)` из последнего успешного запуска. В следующем запуске запросите у источника записи, где `last_modified` больше сохраненного водяного знака.

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

Анализ потока данных IoT в реальном времени для обнаружения необычных всплесков или падений показаний датчиков.

→Используйте функцию `series_decompose_anomalies()` в KQL-запросе в Eventhouse/KQL Database.

Почему: Эта встроенная функция KQL специально разработана для обнаружения аномалий во временных рядах. Она автоматически разбивает ряд на сезонные, трендовые и остаточные компоненты для выявления статистически значимых выбросов, требуя минимальной ручной настройки.

Необходимо объединить данные из Warehouse, Lakehouse и зеркальной Azure SQL Database в одном T-SQL запросе без перемещения данных.

→Используйте трехкомпонентные соглашения об именовании (`database.schema.table`) в запросе, выполняемом из конечной точки SQL Warehouse или Lakehouse. Используйте ярлыки для ссылки на зеркальную базу данных.

Почему: Fabric предоставляет унифицированный движок запросов, который может получать доступ к данным различных элементов Fabric в одной рабочей области с помощью одного SQL-оператора, обеспечивая виртуализацию данных.

Потоку данных необходимо обработать файл, где некоторые строки могут быть недействительными. Весь поток не должен завершаться сбоем; действительные строки должны быть загружены, а недействительные — записаны в журнал.

→В Power Query добавьте шаг для проверки строк и создайте столбец "IsValid". Затем создайте две ссылочные запросы с этого момента: один, который фильтрует по `IsValid = true` для загрузки в место назначения, и другой, который фильтрует по `IsValid = false` для загрузки в журнал ошибок.

Почему: Этот шаблон обеспечивает надежную обработку ошибок путем разделения потока данных. Он предотвращает остановку всего процесса из-за нескольких неверных строк и предоставляет четкий механизм для аудита проблем с качеством данных.

Реализация безопасности на уровне строк (RLS), при которой пользователи должны видеть только те данные, которые соответствуют их идентификации (например, менеджер по продажам видит только свои магазины).

→Создайте таблицу безопасности, сопоставляющую пользователей с сущностями данных. В роли RLS используйте выражение фильтра DAX, например `[ManagerEmail] = USERPRINCIPALNAME()` .

Почему: Динамическая RLS масштабируема. Она использует подход, основанный на данных, вместо создания статической роли для каждого человека или сущности. `USERPRINCIPALNAME()` корректно разрешает идентификатор Azure AD.

Скрытие конфиденциальных столбцов или целых таблиц (например, Salary) от определенной группы пользователей, позволяя им при этом доступ к остальной части семантической модели.

→Определите роли безопасности и настройте Object-Level Security (OLS) с использованием внешнего инструмента, такого как Tabular Editor, для установки разрешений таблицы/столбца на "None".

Почему: OLS обеспечивает детальный контроль над видимостью метаданных модели. В отличие от RLS, которая фильтрует строки, OLS скрывает весь объект. Она должна быть настроена через конечную точку XMLA.

Пользователи сообщают о медленной работе и дросселировании в Fabric. Администратору необходимо выявить основную причину.

→Используйте приложение Fabric Capacity Metrics.

Почему: Это приложение предоставляет подробные сведения о потреблении единиц мощности (CU), событиях дросселирования и использовании ресурсов по типу рабочей нагрузки (например, запрос семантической модели, обновление потока данных). Это основной инструмент для мониторинга производительности и планирования мощности.

Применение политики классификации данных, при которой отчеты и дашборды автоматически наследуют метку конфиденциальности семантической модели, к которой они подключены.

→Включите настройку клиента для нисходящего наследования меток конфиденциальности.

Почему: Это автоматизирует управление данными, гарантируя, что защита, применяемая к источнику данных (например, "Строго конфиденциально"), последовательно применяется ко всему нисходящему контенту, снижая риск утечки данных.

В Fabric Warehouse обычные пользователи должны видеть маскированные данные PII (например, `XXX-XX-1234`), а привилегированные пользователи — полные, не маскированные данные.

→Примените Dynamic Data Masking (DDM) к конфиденциальным столбцам в Warehouse. Предоставьте разрешения `UNMASK` ролям привилегированных пользователей.

Почему: DDM — это функция безопасности на уровне базы данных, которая скрывает данные на лету на основе разрешений пользователя. Она защищает конфиденциальные данные на месте, не требуя отдельных представлений или копий данных.