Справочник - DP-600 Microsoft Fabric Analytics Engineer Associate

Запрос к массивной (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 - это функция безопасности на уровне базы данных, которая скрывает данные на лету на основе разрешений пользователя. Она защищает конфиденциальные данные на месте, не требуя отдельных представлений или копий данных.