Справочник

Разработка начального уровня приема данных в архитектуре Medallion для захвата необработанных исходных данных.

→Прием данных в слой Bronze с минимальными преобразованиями и разрешительной схемой.

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

Внедрение изолированных сред и процесса продвижения для артефактов Fabric.

→Используйте конвейеры развертывания Fabric с отдельными этапами рабочих областей для разработки, тестирования и продакшена.

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

Внедрение контроля версий и рабочих процессов утверждения для изменений в производственных элементах Fabric.

→Интегрируйте рабочую область Fabric с Azure DevOps Git. Используйте политики ветвления для принудительного выполнения проверок pull request.

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

Автоматизация изменений строк подключения, специфичных для среды, во время развертываний конвейера.

→Настройте правила развертывания в конвейере развертывания для параметризации подключений к источникам данных для каждого этапа.

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

Организация рабочих областей для нескольких бизнес-подразделений, требующих как изоляции, так и общего управления.

→Создавайте отдельные рабочие области для каждого бизнес-подразделения и группируйте их в Fabric Domains.

Почему: Рабочие области обеспечивают изоляцию контента и безопасности, в то время как Domains позволяют централизованное управление и обнаружение между связанными рабочими областями.

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

→Применяйте описания и теги к таблицам Lakehouse и используйте метки одобрения (Promoted, Certified).

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

Обеспечение последовательной классификации и защиты данных для всех элементов Fabric.

→Интегрируйте с Microsoft Purview Information Protection и включите наследование для меток конфиденциальности для нижестоящих элементов.

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

Определение основного фактора для определения размера мощности Fabric.

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

Почему: Мощность Fabric потребляется вычислительными операциями (единицами мощности), а не объемом хранения данных. Одновременность и сложность задач являются ключевыми факторами.

Предоставление безопасного доступа промышленного уровня из ярлыка Fabric к внешней учетной записи ADLS Gen2.

→Используйте Service Principal с аутентификацией Azure AD, предоставляя ему роли RBAC с наименьшими привилегиями для учетной записи хранения.

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

Создание почти реального времени, только для чтения реплики базы данных Azure SQL Database в Fabric без влияния на источник.

→Используйте Fabric Mirroring для Azure SQL Database.

Почему: Mirroring обеспечивает репликацию данных с низкой задержкой и непрерывным потоком в OneLake в виде таблиц Delta, идеально подходит для аналитики в реальном времени без разработки ETL.

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

→Создайте Shortcut, указывающий на исходную таблицу Lakehouse или внешнее расположение данных.

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

Объединение высокоскоростных потоковых данных с историческими пакетными данными для унифицированной аналитики.

→Используйте Eventstream для приема данных в реальном времени и Lakehouse с таблицами Delta Lake для унифицированного хранения.

Почему: Eventstream обрабатывает потоковый путь, а свойства ACID Delta Lake позволяют ему служить целью как для потоковых добавлений, так и для пакетных обновлений.

Обеспечение анализа на основе T-SQL и Data Science на основе Python для одних и тех же данных Lakehouse.

→Используйте автоматически генерируемую конечную точку SQL analytics для Lakehouse.

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

Прием данных из локального источника данных (например, Oracle, SQL Server) в Fabric.

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

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

Автоматическая обработка новых файлов сразу после их поступления в Azure Blob Storage.

→Используйте триггер Storage Event для конвейера данных, настроенный на срабатывание по событиям создания BLOB-объектов.

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

Извлечение всех записей из REST API, который возвращает данные постранично.

→В действии Copy настройте встроенные правила пагинации коннектора REST. В качестве альтернативы используйте цикл Until или ForEach с переменными для управления токенами страниц.

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

Реализация логики Slowly Changing Dimension Type 2 или обработка потоков Change Data Capture (CDC).

→Используйте операцию Delta Lake MERGE с выражениями `WHEN MATCHED` и `WHEN NOT MATCHED`.

Почему: MERGE предоставляет возможности атомарного upsert (обновление/вставка/удаление), что является основной операцией для поддержания исторических записей в шаблонах SCD2.

Преобразование столбца DataFrame, содержащего вложенные массивы объектов, в отдельные строки.

→Примените функцию `explode()` к столбцу массива в PySpark notebook.

Почему: `explode()` — это стандартная функция Spark для разворачивания массивов, создающая новую строку для каждого элемента в массиве.

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

→Настройте watermark на столбце времени события в запросе Spark Structured Streaming.

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

Выполнение инкрементальной загрузки данных из исходной системы, имеющей столбец временной метки, но без CDC.

→Реализуйте шаблон high-watermark. Сохраните максимальную временную метку из последнего запуска и используйте ее для фильтрации источника в следующем запуске.

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

Действие конвейера периодически завершается сбоем из-за временных проблем с сетью или нагрузки на исходную систему.

→Настройте политику повторных попыток для действия с указанным количеством и интервалом экспоненциальной задержки.

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

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

→Примите данные в Eventhouse и запросите их с использованием Kusto Query Language (KQL).

Почему: Eventhouse (построенный на Azure Data Explorer) и KQL специально разработаны для высокопроизводительного анализа временных рядов и журналов.

Создание единого, многократно используемого конвейера для загрузки десятков таблиц, использующих одинаковую логику преобразования.

→Используйте подход, управляемый метаданными. Храните информацию об источнике/назначении в контрольной таблице и используйте действие ForEach для итерации и передачи параметров в общий дочерний конвейер.

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

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

→Разработайте преобразования, которые могут быть свёрнуты (folded). Проверьте статус свёртывания запросов в редакторе Power Query.

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

Запрос таблицы в том состоянии, в котором она существовала в определенный момент в прошлом, для аудита или восстановления после случайного обновления.

→Используйте функцию Delta Lake time travel с `VERSION AS OF` или `TIMESTAMP AS OF` в запросе.

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

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

→Реализуйте правила RLS с использованием выражений DAX в семантической модели.

Почему: Семантическая модель является централизованным и рекомендуемым слоем для обеспечения бизнес-правил, таких как RLS. Логика применяется динамически на основе идентификации пользователя.

Предотвращение просмотра группой пользователей конфиденциальных столбцов (например, зарплата, PII) в таблице.

→Реализуйте безопасность на уровне столбцов (CLS) в семантической модели или хранилище.

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

Создание отчета Power BI на очень большом наборе данных Lakehouse с высокими требованиями к производительности.

→Создайте семантическую модель, используя режим DirectLake.

Почему: DirectLake предлагает производительность режима Import, загружая данные в память, но без дублирования данных, путем чтения непосредственно из файлов Delta в OneLake.

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

→Создайте и настройте таблицы агрегации в семантической модели.

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

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

→Настройте политику инкрементального обновления для больших таблиц фактов в семантической модели.

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

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

→Выполните команду `OPTIMIZE` для таблицы Delta.

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

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

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

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

Оптимизация производительности чтения для отчетов Power BI, запрашивающих таблицы Delta в Lakehouse Fabric.

→Убедитесь, что оптимизация V-Order включена для таблиц Delta.

Почему: V-Order — это оптимизация времени записи, специфичная для Fabric, которая улучшает производительность чтения для движка Power BI за счет улучшения сжатия и упорядочивания данных.

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

→Выполните команду `VACUUM` для таблицы.

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

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

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

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

Операция соединения Spark медленно выполняется или завершается сбоем из-за того, что одно значение ключа имеет непропорционально большой объем данных (перекос данных - data skew).

→Реализуйте технику "salting": добавьте случайный ключ к перекошенным значениям, чтобы распределить их по большему количеству разделов, затем выполните соединение и агрегацию.

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

Задание Spark notebook выполняется медленнее, чем ожидалось, и причина неясна.

→Используйте Spark UI, доступный из центра мониторинга, для анализа Directed Acyclic Graph (DAG), продолжительности этапов и деталей задач.

Почему: Spark UI предоставляет подробное физическое представление выполнения запросов, позволяя точно определить узкие места, такие как перекос данных, выгрузки на диск или неэффективные shuffle-операции.

Задание Spark завершается с ошибкой OutOfMemoryError на узле драйвера, даже при большом объеме памяти исполнителя.

→Проверьте код на наличие действий, таких как `.collect()` или `.toPandas()`, которые вытягивают большие объемы распределенных данных в память узла драйвера.

Почему: Драйвер имеет собственное ограничение памяти. Сбор большого DataFrame в драйвер — распространенный антипаттерн, вызывающий ошибки OOM; вместо этого используйте распределенные операции.

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

→Установите и проанализируйте приложение Fabric Capacity Metrics.

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

Внедрение централизованного, долгосрочного аудита и мониторинга всех действий в рабочей области Fabric.

→В административных настройках Fabric настройте параметры диагностики для рабочей области, чтобы передавать журналы в рабочую область Azure Log Analytics.

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

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

→Внедрите автоматизацию (например, с помощью API и Azure Automation) для приостановки мощности в нерабочее время и ее возобновления до начала рабочего дня.

Почему: Вычислительные ресурсы мощности являются основным фактором затрат. Приостановка мощности останавливает выставление счетов за CU, обеспечивая значительную экономию средств в периоды простоя.

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

→Настройте оповещения в Fabric Monitoring Hub или используйте Data Activator для мониторинга статуса конвейера и запуска уведомлений.

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