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

Примечание.

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

Подготовка данных (иногда называется ETL, которая является акронимом для извлечения, преобразования и загрузки) часто включает значительное количество работ в зависимости от качества и структуры исходных данных. Сценарий самостоятельной подготовки данных фокусируется на повторном использовании действий по подготовке данных бизнес-аналитиками. Она достигает этой цели повторного использования путем перемещения работы по подготовке данных из Power Query (в отдельных файлах Power BI Desktop) в Power Query Online (с помощью потока данных Power BI). Централизация логики помогает достичь одного источника истины и снижает уровень усилий, необходимых другим создателям контента.

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

Примечание.

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

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

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

На следующей схеме представлен общий обзор наиболее распространенных действий пользователей и компонентов Power BI, поддерживающих самостоятельную подготовку данных. Основное внимание уделяется созданию потока данных в Power Query Online, который становится источником данных для нескольких семантических моделей (ранее известных как наборы данных). Цель состоит в том, чтобы многие семантические модели использовали подготовку данных, которая выполняется один раз потоком данных.

Diagram shows self-service data preparation, which is about dataflows for centralizing data cleansing and transformation work. Items in the diagram are described in the table below.

Совет

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

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

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

Совет

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

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

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

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

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

Примечание.

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

Поддержка создателей семантической модели

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

Примечание.

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

Ниже приведены некоторые преимущества использования потоков данных Power BI.

  • Создатели семантической модели используют тот же знакомый интерфейс Power Query, который найден в Power BI Desktop.
  • Логика подготовки и преобразования данных, определяемая потоком данных, можно многократно использовать, так как она централизованно.
  • При внесении изменений логики подготовки данных в поток данных может не потребоваться обновление зависимых моделей данных. Удаление или переименование столбцов или изменение типов данных столбцов потребует обновления зависимых моделей данных.
  • Предварительно подготовленные данные можно легко сделать доступными для создателей семантической модели Power BI. Повторное использование особенно полезно для часто используемых таблиц, особенно таблиц измерений, таких как дата, клиент и продукт.
  • Уровень усилий, необходимых создателям семантической модели, уменьшается, так как работа по подготовке данных была отложена от работы моделирования данных.
  • Меньше создателей семантической модели требует прямого доступа к исходным системам. Исходные системы могут быть сложными для запроса и могут требовать специализированных разрешений доступа.
  • Количество обновлений, выполняемых в исходных системах, уменьшается, так как семантическая модель обновляет подключение к потокам данных, а не к исходным системам, из которых потоки данных извлекают данные.
  • Данные потока данных представляют моментальный снимок во времени и способствуют согласованности при использовании многих семантических моделей.
  • Разъединение логики подготовки данных в потоки данных может помочь улучшить успешное обновление семантической модели. Если обновление потока данных завершается ошибкой, семантические модели будут обновляться с помощью последнего успешного обновления потока данных.

Совет

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

Гибкость создания семантической модели

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

Расширенные функции потока данных

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

Примечание.

Одним из дополнительных функций является добавочное обновление потоков данных. Хотя добавочное обновление для семантических моделей является функцией Power BI Pro, добавочное обновление для потоков данных является функцией Premium.

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

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

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

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

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

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

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

Хранилище на уровне клиента

Раздел подключений Azure на портале Администратор содержит параметр настройки подключения к учетной записи ADLS 2-го поколения. Настройка этого параметра позволяет использовать собственное озеро данных. После настройки можно настроить рабочие области для использования этой учетной записи озера данных.

Важно!

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

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

Хранилище уровня рабочей области

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

Примечание.

Разрешение на хранение на уровне рабочей области на портале Администратор применяется ко всем рабочим областям в клиенте Power BI.

Формат Common Data Model

Данные в учетной записи ADLS 2-го поколения хранятся в структуре Common Data Model (CDM). Структура CDM — это формат метаданных, который определяет способ хранения самоописающей схемы, а также данных. Структура CDM обеспечивает семантику согласованности в формате, стандартизованном для совместного использования данных в различных приложениях (не показанном на схеме сценария).

Публикация в отдельных рабочих областях

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

Примечание.

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

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

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

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

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

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

Совет

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

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

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

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