Сценарии использования Power BI: расширенная подготовка данных

Примечание.

Эта статья входит в серию статей по планированию реализации Power BI. В этой серии основное внимание уделяется рабочей нагрузке Power BI в Microsoft Fabric. Общие сведения о серии см. в статье о планировании реализации Power BI.

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

Инвестиции во время и усилия в централизованной подготовке данных помогают:

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

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

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

Примечание.

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

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

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

Схема сценария

Совет

Рекомендуется ознакомиться с сценарием самостоятельной подготовки данных, если вы не знакомы с ним. Расширенный сценарий самостоятельной подготовки данных основан на этом сценарии.

Основное внимание уделяется этому расширенному сценарию подготовки данных:

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

Примечание.

Иногда термины семантической модели и модели данных используются взаимозаменяемо. Как правило, с точки зрения служба Power BI она называется семантической моделью. С точки зрения разработки она называется моделью данных (или моделью для краткой). В этой статье оба термина имеют одно и то же значение. Аналогичным образом создатель семантической модели и модельизатор данных имеют то же значение.

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

Diagram shows advanced data preparation, which is about improving the reach and reusability of dataflows. Items in the diagram are described in the table below.

Совет

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

На схеме сценария показаны следующие действия пользователя, инструменты и функции:

Позиция Description
Item 1. Создатель потока данных разрабатывает коллекцию таблиц в потоке данных. Для потока данных, предназначенного для повторного использования, обычно (но не требуется), что создатель принадлежит централизованной команде, которая поддерживает пользователей через границы организации (например, ИТ, корпоративная бизнес-аналитика или Центр превосходства).
Item 2. Поток данных подключается к данным из одного или нескольких источников данных.
Item 3. Некоторым источникам данных может потребоваться локальный шлюз данных или шлюз виртуальной сети для обновления данных, например те, которые находятся в частной сети организации. Эти шлюзы используются как для разработки потока данных в Power Query Online, так и для обновления потока данных.
Item 4. Все задействованные рабочие области имеют режим лицензии, равный емкости Fabric, емкости Premium, Premium на пользователя или Embedded. Эти режимы лицензий позволяют использовать связанные таблицы и вычисляемые таблицы в рабочих областях, которые необходимы в этом сценарии.
Item 5. Создатели потоков данных разрабатывают потоки данных с помощью Power Query Online, которая является веб-версией Power Query.
Item 6. Промежуточный поток данных создается в рабочей области, выделенной для централизованного управления потоками данных. Промежуточный поток данных копирует необработанные данные из источника. Некоторые, если таковые имеются, применяются преобразования.
Item 7. Поток данных преобразования (также известный как очищенный поток данных) создается в той же рабочей области. Он источник данных с помощью связанных таблиц для промежуточного потока данных. Вычисляемые таблицы включают шаги преобразования, которые подготавливают, очищают и переобужают данные.
Item 8. Создатели потоков данных имеют доступ к управлению содержимым в рабочей области, выделенной для централизованного управления потоками данных.
Item 9. Одна или несколько других рабочих областей предназначены для предоставления доступа к окончательному потоку данных, который предоставляет готовые к рабочей среде данные моделям данных.
Item 10. Окончательный поток данных создается в рабочей области, доступной для моделей данных. Он источник данных с помощью связанных таблиц для потока данных преобразования. Вычисляемые таблицы представляют подготовленные выходные данные, видимые для моделей данных, которым предоставлена роль просмотра рабочей области.
Item 11. Создатели семантической модели (которые используют выходные данные потока данных) имеют доступ к рабочей области, содержащей окончательные выходные данные потока данных. Создатели потоков данных также имеют доступ к управлению и публикации содержимого в рабочей области (не изображено на схеме сценария).
Item 12. Создатели семантической модели используют окончательный поток данных в качестве источника данных при разработке модели данных в Power BI Desktop. После готовности создатель семантической модели публикует файл Power BI Desktop (PBIX), содержащий модель данных в служба Power BI (не показан на схеме сценария).
Item 13. Администраторы Структуры управляют параметрами на портале Администратор.
Item 14. На портале Администратор администраторы Power BI могут настроить подключения Azure для хранения данных потока данных в учетной записи Azure Data Lake Storage 2-го поколения (ADLS 2-го поколения). Параметры включают назначение учетной записи хранения на уровне клиента и включение разрешений хранилища на уровне рабочей области.
Item 15. По умолчанию потоки данных хранят данные с помощью внутреннего хранилища, управляемого служба Power BI. При необходимости выходные данные потока данных можно хранить в учетной записи ADLS 2-го поколения организации.
Item 16. Администраторы Структуры контролируют и отслеживают действия на портале Fabric.

Ключевые моменты

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

Потоки данных

Поток данных состоит из коллекции таблиц (также известных как сущности). Каждая таблица определяется запросом, который содержит шаги подготовки данных, необходимые для загрузки таблицы с данными. Все работы по созданию потока данных выполняются в Power Query Online. Поток данных можно создать в нескольких продуктах, включая Power Apps, Dynamics 365 Customer Аналитика и Power BI.

Примечание.

Потоки данных нельзя создавать в личной рабочей области в служба Power BI.

Типы потоков данных

Использование составных стандартных блоков — это принцип проектирования, позволяющий управлять, развертывать и защищать системные компоненты, а затем использовать их в различных сочетаниях. Создание модульных автономных потоков данных, относящихся к цели, является лучшей практикой. Они помогают добиться повторного использования данных и масштабирования предприятия. Модульные потоки данных также проще управлять и тестировать.

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

Промежуточный поток данных

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

  • Доступ к источнику данных ограничен узкими временными окнами и (или) несколькими пользователями.
  • Темпоральная согласованность требуется, чтобы все потоки данных вниз (и связанные семантические модели) предоставляли данные, извлеченные из источника данных одновременно.
  • Сокращение количества запросов, отправленных в источник данных, необходимо из-за ограничений исходной системы или его возможности поддерживать аналитические запросы.
  • Копия исходных данных полезна для процессов выверки и проверки качества данных.

Поток данных преобразования

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

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

Окончательный поток данных

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

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

Примечание.

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

Рабочие области для потоков данных

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

Ниже приведены два типа рабочих областей, показанных на схеме сценариев:

  • Рабочая область 1. Она хранит централизованно управляемые потоки данных (иногда называются серверной рабочей областью). Он содержит потоки данных промежуточного и преобразования, так как они управляются теми же людьми. Создатели потоков данных часто из централизованной команды, например ИТ, бизнес-аналитики или Центра превосходства. Они должны быть назначены администратору рабочей области, члену или участник роли.
  • Рабочая область 2. Она сохраняет и предоставляет конечные выходные данные потока данных потребителям данных (иногда называется рабочей областью пользователя). Создатели семантической модели часто являются аналитиками самообслуживания, пользователями и инженерами данных гражданина. Они должны быть назначены роли просмотра рабочей области, так как они должны использовать только выходные данные окончательного потока данных. Для поддержки создателей семантической модели из различных областей организации можно создать множество рабочих областей, таких как этот, на основе вариантов использования и потребностей безопасности.

Совет

Рекомендуется ознакомиться с способами поддержки создателей семантической модели, как описано в сценарии самостоятельной подготовки данных. Важно понимать, что создатели семантической модели по-прежнему могут использовать все возможности Power Query в Power BI Desktop. Они могут добавить шаги запроса для дальнейшего преобразования данных потока данных или слияния выходных данных с другими источниками.

Типы таблиц потока данных

На схеме сценария показаны три типа таблиц потока данных (также известных как сущности).

  • Стандартная таблица: запрашивает внешний источник данных, например базу данных. На схеме сценария стандартные таблицы отображаются в промежуточном потоке данных.
  • Связанная таблица: ссылается на таблицу из другого потока данных. Связанная таблица не дублирует данные. Скорее, он позволяет повторно использовать стандартную таблицу несколько раз для нескольких целей. Связанные таблицы не отображаются для просмотра рабочих областей, так как они наследуют разрешения от исходного потока данных. На схеме сценария связанные таблицы показаны дважды:
    • В потоке данных преобразования для доступа к данным в промежуточном потоке данных.
    • В последнем потоке данных для доступа к данным в потоке данных преобразования.
  • Вычисляемая таблица: выполняет дополнительные вычисления с помощью другого потока данных в качестве источника. Вычисляемая таблица позволяет настраивать выходные данные по мере необходимости для отдельных вариантов использования. На схеме сценария вычисляемые таблицы показаны дважды:
    • В потоке данных преобразования для выполнения общих преобразований.
    • В последнем потоке данных для доставки выходных данных создателям семантической модели. Так как вычисляемые таблицы снова сохраняют данные (после обновления потока данных), моделиаторы данных могут получить доступ к вычисляемых таблицам в окончательном потоке данных. В этом случае моделиторы данных должны предоставляться доступ к роли средства просмотра рабочей области.

Примечание.

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

Расширенный вычислительный модуль

Расширенный вычислительный модуль — это расширенная функция, доступная в Power BI Premium. Расширенный вычислительный модуль повышает производительность связанных таблиц (в той же рабочей области), которые ссылают (ссылаться на) поток данных. Чтобы получить максимальную выгоду от расширенного вычислительного модуля, выполните следующие действия.

  • Разделение промежуточных и преобразований потоков данных.
  • Используйте ту же рабочую область для хранения промежуточных и преобразований потоков данных.
  • Примените сложные операции, которые могут сворачивать запросы на ранних этапах запроса. Приоритеты свертываемых операций могут помочь достичь оптимальной производительности обновления.
  • Используйте добавочное обновление для уменьшения длительности обновления и потребления ресурсов.
  • Выполняйте тестирование на ранней и частой стадии разработки.

Обновление потоков данных и семантической модели

Поток данных — это источник данных для семантических моделей. В большинстве случаев используются несколько расписаний обновления данных: по одному для каждого потока данных и по одному для каждой семантической модели. Кроме того, можно использовать DirectQuery из семантической модели в поток данных, для которого требуется Power BI Premium и расширенный вычислительный модуль (не показан на схеме сценария).

Azure Data Lake Storage 2-го поколения

Учетная запись ADLS 2-го поколения — это конкретный тип учетной записи хранения Azure, которая включает иерархическое пространство имен. ADLS 2-го поколения имеет преимущества производительности, управления и безопасности для операционных аналитических рабочих нагрузок. По умолчанию потоки данных Power BI используют внутреннее хранилище, которое является встроенной учетной записью озера данных, управляемой служба Power BI. При необходимости организации могут принести собственное озеро данных, подключився к учетной записи ADLS 2-го поколения в своей организации.

Ниже приведены некоторые преимущества использования собственного озера данных:

  • Пользователи (или процессы) могут напрямую получить доступ к данным потока данных, хранящимся в озере данных. Это полезно при повторном использовании потока данных за пределами Power BI. Например, Фабрика данных Azure может получить доступ к данным потока данных.
  • Другие средства или системы могут управлять данными в озере данных. В этом случае Power BI может использовать данные, а не управлять ими (не изображены на схеме сценария).

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

Примечание.

Данные потока данных в ADLS 2-го поколения хранятся в контейнере, относяющемся к Power BI. Этот контейнер показан на схеме сценариев самостоятельной подготовки данных.

Параметры портала администрирования

На портале Администратор есть два важных параметра:

  • Подключения Azure. Раздел подключений Azure на портале Администратор включает параметр настройки подключения к учетной записи ADLS 2-го поколения. Этот параметр позволяет администратору Power BI перенести собственное озеро данных в потоки данных. После настройки рабочие области могут использовать учетную запись озера данных для хранения.
  • Хранилище уровня рабочей области. Администратор Power BI может задать разрешения на хранение на уровне рабочей области. Если этот параметр включен, администраторы рабочей области могут использовать другую учетную запись хранения для одного набора на уровне клиента. Включение этого параметра полезно для децентрализованных бизнес-подразделений, которые управляют собственным озером данных в Azure.

Установка шлюза

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

Шлюз данных требуется, если:

  • Создание потока данных в Power Query Online, которое подключается к частным данным организации.
  • Обновление потока данных, который подключается к частным данным организации.

Совет

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

Системный надзор

Журнал действий записывает действия пользователя, происходящие в служба Power BI. Администраторы Power BI могут использовать данные журнала действий, собранные для аудита, чтобы помочь им понять шаблоны использования и внедрение. Журнал действий также ценен для поддержки усилий по управлению, аудита безопасности и требований соответствия требованиям. В расширенном сценарии подготовки данных данные журнала действий полезны для отслеживания управления и использования потоков данных.

Другие полезные сценарии, которые помогут вам в принятии решений по реализации Power BI, см. в статье о сценариях использования Power BI.