Планирование реализации Power BI: планирование и проектирование содержимого

Примечание.

Эта статья является частью серии статей по планированию реализации Power BI . Серия посвящена планированию реализации интерфейса Power BI в Microsoft Fabric. Посмотрите введение к серии.

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

• Центр передового опыта (COE) и команды бизнес-аналитики: Команды, ответственные за надзор за Power BI в организации. К этим командам относятся лица, принимающие решения, которые решают, как управлять жизненным циклом содержимого Power BI.
• создатели содержимого и владельцы контента: пользователи, которые создают контент, который они хотят опубликовать на портале Fabric, чтобы поделиться с другими пользователями. Эти лица отвечают за управление жизненным циклом создаваемого содержимого Power BI.

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

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

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

на схеме

Примечание.

Общие сведения об управлении жизненным циклом контента см. в первой статье этой серии.

Подсказка

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

• Для получения дополнительной информации о том, как эффективно планировать и разрабатывать решение Fabric или Power BI, ознакомьтесь со статьей о планировании решения.
• Для получения дополнительной информации о том, как эффективно спланировать миграцию Power BI, рекомендуем прочитать серию о миграции Power BI.

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

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

Определение и описание содержимого

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

Примечание.

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

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

Какой формат содержимого?

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

Отвечайте на вопросы, приведенные ниже, чтобы определить тип контента, который вы создадите.

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

Подсказка

Рассмотрите возможность создания архитектурной схемы для описания формата содержимого. Можно включить различные источники данных, типы элементов и потребителей контента, а также связи между этими дискретными компонентами. Архитектурная схема может помочь в кратком изображении содержимого и его сложности, и она помогает планировать управление жизненным циклом. Значки Fabric и значки Azure можно использовать для создания этих схем во внешнем программном обеспечении. Кроме того, можно использовать схемы Azure, которые поставляются сo значками и инструментами рисования для создания этих диаграмм.

Пример таких схем см. в схеме планирования реализации Power BI схемах сценариев использования.

Кто будет создавать и поддерживать содержимое?

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

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

• Сколько разных людей вы ожидаете для создания этого контента? Будет ли несколько создателей контента совместно работать или один человек отвечает за создание содержимого?
• Знакомы ли создатели содержимого с управлением жизненным циклом и связанными понятиями, такими как управление версиями? Понимают ли создатели содержимого преимущества управления жизненным циклом?
• Будут ли создатели контента, которые разрабатывают решение, будут теми же лицами, которые поддерживают его после развертывания?
• Существуют ли у создателей контента или их команд уже внедренные методики управления жизненным циклом для поддержки существующих решений?
• В настоящее время создатели содержимого используют такие средства управления жизненным циклом, как Azure DevOps?

Это важно

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

Какова важность содержимого?

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

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

• Насколько важно это содержимое для бизнеса? Насколько срочным является запрос на его разработку?
• Будут ли критически важные для бизнеса решения или действия приниматься из информации, предоставленной этим содержимым?
• Насколько широко вы планируете распространять это содержимое (от организации до ограниченной локальной команды)?
• Будут ли руководители или другие стратегические лица, принимающие решения, полагаться на это содержимое для их работы?
• Что такое влияние этого содержимого? Например, если содержимое внезапно недоступно, какие бизнес-последствия будут возникать, например потеря дохода или прерывание бизнес-процессов?

Когда вы достаточно определили и описали создаваемое содержимое, следует решить, как создатели контента должны сотрудничать.

Определение того, как пользователи будут использовать содержимое

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

Использование и повторное использование семантических моделей

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

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

• Power BI

  • Отчеты
  • Отчеты с разбивкой на страницы
  • Оценочные карты
  • Excel (анализ в сводных таблицах Excel)
  • семантические модели (составные модели)

• Microsoft Fabric

  • активатор (прежнее название — рефлектор)
  • навыки ИИ
  • Второй пилот
  • исследования
  • наборы метрик
  • ноутбуки (с помощью библиотек Semantic Link и semantic-link-labs)

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

Примечание.

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

Отчеты

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

• Просмотр отчетов. Стандартный сценарий, в котором пользователь просматривает данные в отчете, который вы распространяете или предоставляете им общий доступ.
• Подключение к семантической модели и создание нового отчета. С помощью разрешений на сборкупользователи могут создавать новый отчет в Power BI Desktop или в службе Power BI. Этот отчет имеет динамическое подключение к общей семантической модели. Пользователи также могут преобразовать прямо подключенный отчет в новую составную семантическую модель, которая осуществляет запрос к оригиналу с помощью DirectQuery.
• Создание аналитики из существующей визуализации отчета. С разрешениями на сборку пользователи также могут выбрать поддерживаемое визуальное представление для исследования его данных. При этом создается новый элемент исследования, позволяющий пользователю добавлять поля или изменять форматирование. Пользователи могут сохранять и делиться результатами исследования, если они соответствуют требуемым критериям лицензирования, членства в рабочей области и разрешений элементов.
• Персонализация визуальных элементов отчета, в которой пользователи могут изменять поле и форматирование.Персонализация визуальных элементов работает аналогично разведке, но требует только разрешения на чтение и не создает новый элемент. Персонализация визуальных элементов также использует любые перспективы, которые пользователь применяет к странице отчета, которая ограничивает доступные поля, которые пользователь может видеть и использовать.

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

• Какие разрешения будут предоставлены пользователям и как управлять этими разрешениями. Перед получением разрешений на сборку пользователям рекомендуется выполнить обучение.
• Будет ли добавлена перспектива в модель или нет. Вы можете добавлять перспективы только с помощью представления TMDL в Power BI Desktopили с помощью других сторонних средств. Рекомендуется добавлять перспективы, когда пользователи используют персональные визуализации или составные модели.
• Какие поля следует скрыть в модели, и следует ли включить свойство IsPrivate в TOM таблиц, чтобы они или их дочерние объекты не отображались как подсказки. Обратите внимание, что свойство Private TOM можно задать только с помощью внешних средств в файле метаданных модели (например, BIM или TMDL) или удаленной модели, опубликованной в службе Power BI.
• Как вы будете задокументировать модель и что должно быть включено в эту документацию. Рекомендуется сделать документацию с учетом конкретных вариантов использования и включать релевантную и полезную информацию, а не экспортировать метаданные модели, такие как выражения мер DAX, которые обычно не полезны для конечных пользователей.
• Как вы будете советуть пользователям выбирать один подход по сравнению с другим.

Осторожность

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

Excel (анализ в сводных таблицах Excel)

Если у пользователей есть разрешения на сборку для модели, они также могут подключаться к семантической модели из Excel и запрашивать её с помощью MDX из сводной таблицы Excel. Это может быть полезно, если пользователи предпочитают работать в Excel для изучения или анализа данных.

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

• Некоторые функции, такие как параметры поля или динамические строки формата измерения , работают только в Power BI, а не в Excel. Для достижения аналогичного результата необходимо использовать другие подходы.
• Анализ в Excel требует включения свойства столбца IsAvailableinMDX. Если пользователи не будут использовать Excel, отключение этого свойства может привести к созданию более компактных и производительных моделей.
• Пользователи не могут просматривать скрытые столбцы или меры в семантической модели так, как это возможно в Power BI Desktop (щелкнув правой кнопкой мыши по области данных и выбрав "отобразить скрытое").
• Пользователи не могут создавать собственные метрики или визуальные вычисления в Excel, как при использовании живого соединения из Power BI Desktop. Однако они могут ссылаться на поля сводной таблицы в других ячейках и листах Excel для пользовательских вычислений.
• Пользователям анализа в Excel часто требуется дополнительное обучение по его использованию. Это особенно верно, если они ожидают опыта, подобного экспорту, или выражают намерение сохранить данные в виде автономных копий. Рассмотрите возможность обучения пользователей в таких вещах, как:
  • Как обновить данные.
  • Отфильтруйте данные перед добавлением полей в сводную таблицу.
  • Избегайте больших и подробных запросов без фильтров.
  • Power BI Desktop будет более производительной, чем анализ в Excel, так как анализ в Excel запрашивает модель с помощью многомерных выражений, но Power BI Desktop запрашивает модель с помощью DAX.
  • Как избежать создания рисков управления или безопасности, при этом используя Excel так, как им удобно.

Навыки Copilot и Искусственный интеллект (ИИ)

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

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

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

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

• Какие задачи Copilot или ИИ способны и не способны выполнять.
• Когда следует использовать возможности Copilot или ИИ для анализа данных вместо традиционных (не ИИ) методов.
• Как писать эффективные подсказки.
• Как проверить выходные данные.
• Как устранить проблемы с непредвиденными результатами.

Подсказка

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

• Оптимизация процесса для авторов отчетов и пользователей моделей
• Обновите свою модель данных, чтобы оптимально работать с Copilot для Power BI
• написание запросов DAX с помощью Copilot

Copilot и другие технологии искусственного интеллекта имеют важные ограничения и рекомендации, которые также следует понимать на этапе планирования и проектирования содержимого:

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

Осторожность

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

Отчеты, разбитые на страницы

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

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

• Как создавать и поддерживать запросы DAX, например с помощью представления запросов DAX Power BI Desktop или других сторонних средств.
• Необходимо ли принимать решения по проектированию, чтобы гарантировать, что семантическая модель эффективно выполняет запросы, например, материализуя определенные данные в столбце или таблице модели.
• Будете ли вы внедрять визуализацию отчета с разбивкой на страницы в интерактивные отчеты Power BI с помощьюили нет.
• Как убедиться, что между отчетами с разбивкой на страницы и другими отчетами нет избыточности.
• В каком формате следует распространять отчеты с разбивкой на страницы, а также требоваться ли метки конфиденциальности или защита от потери данных для защиты этих выходных данных от создания рисков управления или безопасности.

Другие

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

• Активатор (прежнее название — Рефлектор): Вы можете использовать семантическую модель для автоматизации оповещений о данных и запуска потоков данных, например, созданных с помощью Power Automate.
• наборы метрик: можно создать набор метрик, включающий меры и рекомендуемые измерения из нескольких семантических моделей в одном месте. Наборы метрик могут улучшить обнаружение данных для пользователей.
• Исследования: Помимо создания исследований из отчетов и выходных данных Copilot, пользователи также могут создавать исследования из семантической модели.

Распространение отчетов и общий доступ к ним

В зависимости от того, как вы будете распространять и делиться вашими отчетами Power BI, вы будете принимать различные решения по дизайну. Например, детализация между отчетами — это функция, которая позволяет пользователям перемещаться между отчетами в одной рабочей области или приложении. Однако вы не можете использовать переход между отчетами, если внедряете отчет или публикуете его публично через функцию Publish-to-Web.

Другие элементы

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

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

Определите, как создатели контента должны сотрудничать

Поскольку решение увеличивается по масштабу и сложности, может потребоваться, чтобы несколько создателей контента и владельцев работали совместно. При создании сложных решений рекомендуется использовать эффективные средства, которые помогают структурировать, управлять и поддерживать совместную работу. Существует множество способов совместной работы при создании содержимого Power BI, например с помощью Microsoft Teams, Azure DevOps или GitHub.

Подсказка

Даже если создатели контента работают независимо, они по-прежнему могут воспользоваться планированием и структурированием своей работы с помощью таких средств, как Microsoft Teams, Azure DevOps или GitHub. Это особенно важно при планировании развертывания контента, например, используя обновление OneDrive из библиотеки документов Microsoft Teams или интеграцию Git из репозитория Azure DevOps или GitHub.

Microsoft Teams

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

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

Подсказка

Мы рекомендуем использовать Microsoft Teams для упрощения эффективного управления жизненным циклом контента в сценариях самообслуживания с децентрализованной доставкой содержимого.

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

• Планировщик: владельцы содержимого могут использовать Планировщик для создания планов, чтобы отслеживать задачи и работу с содержимым. Задачи могут описывать проблемы, ошибки или функции в решении и соответствующие заинтересованные лица.
• SharePoint: создатели содержимого могут хранить файлы и управлять ими в библиотеке документов Microsoft Teams или подключенном сайте для каждого канала. Файлы содержимого, хранящиеся в SharePoint, могут использовать управление версиями для отслеживания изменений содержимого и управления ими. Дополнительные сведения об отслеживании изменений и управлении ими с помощью SharePoint см. на этапе 2. Разработка содержимого и управление изменениями.
• утверждения: создатели контента и владельцы могут настраивать и использовать рабочие процессы для утверждения изменений контента или выпусков после проверки.
• Fabric и Power BI: создатели содержимого и владельцы могут получить доступ к порталу Fabric из Microsoft Teams. Оттуда они могут управлять и обсуждать содержимое и добавлять полезные отчеты на вкладки в каналах Teams.
• Другие интеграции: создатели содержимого могут использовать другие службы Майкрософт или сторонние службы, которые интегрируются с Microsoft Teams в соответствии с их предпочитаемым рабочим процессом и потребностями.

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

• Управление доступом к командам и каналам.
• Кто отвечает за управление командами и каналами.
• Как определяется и организуется работа в отдельных командах, каналах и планах.
• Как создатели содержимого должны использовать библиотеку документов для упорядочивания файлов и отслеживания изменений и управления ими. Например, как упорядочить библиотеку документов и следует ли создателям содержимого выполнять регистрацию и извлечение файлов.
• Следует ли создателям контента использовать OneDrive Refresh для автоматической публикации файлов Power BI Desktop (.pbix).
• Как разрешаются конфликты синхронизации файлов.
• Когда архивировать и удалять файлы из библиотеки документов, которые больше не актуальны.

Azure DevOps или GitHub Enterprise

Создатели содержимого и владельцы также могут взаимодействовать и сотрудничать в центральном, упорядоченном центре с помощью Azure DevOps или GitHub Enterprise.

Примечание.

Azure DevOps — это набор служб, которые интегрируются с Power BI и Fabric для планирования и оркестрации управления жизненным циклом контента. При использовании Azure DevOps таким образом обычно используются следующие службы:

• Azure Repos. Позволяет создавать и использовать удаленный репозиторий Git, который является расположением удаленного хранилища, которое используется для отслеживания изменений содержимого и управления ими.
• Azure Pipelines. Позволяет создавать и использовать набор автоматизированных задач для обработки, тестирования и развертывания содержимого из удаленного репозитория в рабочей области.
• Azure Test Plans: Позволяет разрабатывать тесты для валидации решения и автоматизировать контроль качества вместе с Azure Pipelines.
• Azure Boards. Позволяет использовать доски для отслеживания задач и планов в качестве рабочих элементов, а также ссылки на рабочие элементы из других служб Azure DevOps.
• Wiki Azure: позволяет делиться информацией со своей командой, чтобы они могли понять и внести свой вклад в контент.

С помощью Azure DevOps или GitHub Enterprise создатели контента используют проекты для структуры взаимодействия, планирования и работы. Кроме того, контент-мейкеры могут управлять жизненным циклом содержимого из Azure DevOps, выполняя управление исходным кодом, проверки и развертывания. Контроль версий — это процесс управления более детализированными изменениями кода и метаданных содержимого.

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

Подсказка

Мы рекомендуем использовать Azure DevOps для эффективного управления жизненным циклом контента в корпоративных сценариях с централизованной доставкой содержимого. Совместная работа с помощью Azure DevOps или аналогичных средств предпочтительнее в более сложных сценариях для совместной работы с помощью Microsoft Teams или SharePoint. Это связано с тем, что существуют дополнительные средства и варианты, позволяющие упростить более надежную совместную работу и автоматизацию.

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

• Как определяется область работы и как создаются, именуются и используются ветви содержимого.
• Как авторы группируют и фиксируют изменения и описывают их с помощью сообщений коммитов.
• Кто отвечает за проверку и утверждение изменений с использованием пулл-реквестов.
• Как разрешаются конфликты слияния pull request, и кто их разрешает.
• Как изменения, внесенные в разные ветви, должны быть объединены в одну ветвь.
• Как тестируется содержимое и кто выполняет тестирование перед развертыванием содержимого.
• Как и когда изменения развертываются в рабочие пространства разработки, тестирования и эксплуатации.
• Как и когда можно откатить развернутые изменения или версии решения.

GitHub

Создатели контента и владельцы также могут взаимодействовать и совместно работать с помощью GitHub (только облачные версии) и GitHub Enterprise. Как и в Azure DevOps, GitHub предоставляет платформу со службами, которые можно использовать для оркестрации и управления аспектами среды Power BI или Fabric.

Основное различие между Azure DevOps и GitHub заключается в том, что в то время как Azure DevOps предоставляет набор средств для управления жизненным циклом разработки программного обеспечения, GitHub основное внимание уделяется размещению репозиториев Git, управления версиями и совместной работы по коду. В основном используется GitHub при планировании развертывания содержимого с помощью интеграции Git. Кроме того, можно использовать GitHub для синхронизации содержимого из общедоступного репозитория с открытым кодом с рабочей областью.

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

Примечание.

Вы также можете использовать Microsoft Teams вместе с Azure DevOps или GitHub, так как существуют различные способы интеграции этих служб. Например, вы можете просматривать и управлять Досками Azure и отслеживать события в Azure Pipelines из Microsoft Teams.

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

Когда вы решили, если и как создатели содержимого должны работать совместно, вы должны решить, где будут храниться файлы. Многие из этих файлов будут храниться в местах совместной работы.

Выбор места хранения файлов

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

Подсказка

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

Типы файлов, которые необходимо хранить часто, включают:

• файлы содержимого: файлы, содержащие данные содержимого или метаданные. Файлы содержимого, например .pbix и файлы проекта Power BI (.pbip), содержат конфиденциальную информацию. Храните файлы содержимого в безопасном расположении, доступном только тем, кто нуждается в доступе к ним. Кроме того, следует хранить файлы содержимого в расположении, поддерживающем управление версиями, например библиотеку документов в Microsoft Teams или репозиторий Git в Azure DevOps. Примеры файлов содержимого:
  • Файлы Power BI Desktop (.pbix)
  • Файлы проекта Power BI (.pbip)
  • Файлы отчета с разбивкой на страницы Power BI (RDL)
  • Файлы метаданных модели (BIM или TMDL)
  • Файлы метаданных потока данных (.json)
• Файлы источника данных: файлы, которые используются элементами данных, такими как семантические модели или потоки данных. Содержимое напрямую зависит от файлов источника данных, поэтому важно тщательно учесть, где они хранятся, так как удаление их приведет к сбою обновления данных. Кроме того, эти файлы могут содержать конфиденциальную информацию. Таким образом, храните файлы источника данных в безопасной, надежной и надежной среде, которая имеет ограниченный доступ другим лицам. Примеры файлов источника данных могут включать:
  • Структурированные источники данных, такие как книги Excel, Parquet или CSV-файлы.
  • Частично структурированные источники данных, такие как JSON или XML-файлы.
  • Неструктурированные источники данных, такие как изображения, импортированные в отчеты.
• вспомогательные файлы: файлы, поддерживающие создание содержимого или управление ими, но не требуются для его работы. Вспомогательные файлы должны храниться в расположении, поддерживающем управление версиями, и где к ним могут получить доступ другие средства и создатели содержимого. Ниже приведены примеры вспомогательных файлов:
  • Файлы темы Power BI (.json)
  • Файлы изображений (.png, .jpgили .gif) в отчетах Power BI.
  • Файлы правил анализатора лучших практик (.json).
  • Файлы исходного кода для содержимого и запросов.
  • Настраиваемые файлы визуализации (.pbiviz).
• шаблоны и документация: файлы, которые помогают в создании самостоятельного контента или описании существующего контента. Шаблоны и документация должны быть легко доступны пользователям, которым требуется их использовать. Примеры шаблонов и документации могут включать:
  • Файлы шаблона Power BI (.pbit).
  • Шаблоны визуализации и примеры отчетов.
  • Проекты решений и документация.
  • Планирование решений и стратегии.
  • Запросы пользователей и проблемы с решениями.

Осторожность

Некоторые файлы содержимого, такие как PBIX и PBIP-файлы, могут содержать конфиденциальные данные, импортированные из источников данных. Кроме того, файлы метаданных могут содержать конфиденциальную информацию, а в некоторых случаях — и отдельные точки данных. Примером этого является метаданные отчета и шаблоны PBIT, которые могут содержать значения столбцов в определенных обстоятельствах. Убедитесь, что вы принимаете необходимые меры предосторожности для хранения этих файлов в безопасных расположениях и что вы практикуете эффективную защиты от потери данных.

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

SharePoint Online или OneDrive

Обычным решением для хранения файлов является использование сайтов SharePoint. SharePoint широко доступен для большинства пользователей и высоко интегрирован с Power BI и другими приложениями Microsoft 365, такими как Microsoft Teams. Кроме того, он имеет встроенное управление версиями, что упрощает хранение большинства типов файлов. Управление версиями позволяет просматривать и управлять различными сохраненными версиями файла.

При хранении файлов в SharePoint рассмотрите следующие моменты.

• Организация: Убедитесь, что вы поддерживаете согласованную и логическую структуру, чтобы было легко найти конкретные файлы. Используйте хорошие соглашения об именовании, упорядочивайте файлы в папках и архивные файлы, которые больше не относятся к текущим проектам.
• Обновление OneDrive: вы можете связать опубликованную семантическую модель или отчет с файлом .pbix, хранящимся в SharePoint или OneDrive для рабочих или учебных сайтов. С помощью этого подхода вам больше не нужно публиковать семантическую модель, чтобы вносить изменения в действие. Вместо этого изменения отображаются после автоматического обновления OneDrive, который происходит почасово. Хотя это удобно, помните, что этот подход сопровождается некоторыми предостережениями и проблемами. Когда что-то происходит, это невозможно легко обратить вспять.
• Предварительный просмотр отчетов. В SharePoint можно просматривать отчеты Power BI, не устанавливая Power BI Desktop или скачивая файл .pbix локально. При открытии отчетов таким образом они отображаются в браузере . Эта возможность может быть удобной альтернативой просмотру отчетов на портале Fabric. Он включен по умолчанию в параметрах клиента Fabric.

Подсказка

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

Рассмотрите возможность хранения следующих типов файлов в SharePoint.

• Шаблоны и документация: Сохраняйте шаблоны и документацию в SharePoint, если у вас нет готового решения для хранения. SharePoint идеально подходит для этих файлов, так как вы можете предоставить доступ другим пользователям и управлять файлами без сложных настроек или процессов.
• Вспомогательные файлы: храните вспомогательные файлы в SharePoint, если у вас нет существующего решения для хранения. Однако некоторые вспомогательные файлы (например, темы Power BI .json файлы отчетов) могут лучше храниться в системе управления версиями, которая позволяет просматривать сохраненные изменения и управлять ими.
• файлы содержимого: хранить содержимое в SharePoint, если это не важно для бизнеса, или если у вас нет доступа к удаленному репозиторию, например Azure Repos.
• Источники данных: Храните источники данных в SharePoint только если они невелики по размеру и сложности. Дисциплина при использовании SharePoint для хранения файлов источника данных. Рассмотрим другие возможные альтернативные варианты, такие как OneLake.

Осторожность

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

Предупреждение

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

OneLake

Если у вас есть емкостьFabric, OneLake может быть хорошим выбором для хранения файлов источников данных. Вы можете отправлять или синхронизировать файлы в OneLake с помощью Проводника файлов OneLake, где они могут быть преобразованы в таблицы для использования в последующих рабочих нагрузках, таких как Power BI. Для больших или регулярно обновляемых источников данных вы можете автоматически загружать файлы в OneLake с помощью Fabric Data Factory или других приложений, использующих API Azure Data Lake Storage (ADLS) 2-го поколения или Python SDK для хранилища Azure.

Осторожность

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

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

Предупреждение

Обозреватель файлов OneLake имеет несколько важных ограничений и рекомендаций. Например, OneLake не поддерживает управление версиями файлов, таких как SharePoint или OneDrive. Учитывайте эти рекомендации и ограничения при выборе места хранения файлов.

Подсказка

При хранении данных в OneLake подумайте о включении непрерывности бизнес-процессов и восстановления после аварий (BCDR) для снижения риска потери данных. С включенной функцией BCDR данные дублируются и хранятся в двух разных географических регионах в соответствии со стандартными парами регионов Azure.

Удаленный репозиторий

Создатели контента могут выполнять коммиты и сохранять работу с локального компьютера в удаленный репозиторий— например, Azure Repos или GitHub Git-репозиторий — с регулярными интервалами во время разработки. Удаленный репозиторий содержит последнюю версию содержимого или вспомогательных файлов, и она доступна всей командой разработки. Как правило, удаленный репозиторий упрощает более сложные подходы к управлению жизненным циклом, чем с помощью Teams, SharePoint или OneDrive. Это связано с тем, что с помощью удаленного репозитория создатели контента могут воспользоваться более сложными способами совместной работы над файлами или отслеживать изменения файлов и управлять ими. Например, создатели содержимого могут работать с собственной ветвью удаленного репозитория, чтобы внести изменения и запросить слияние этих изменений в основную ветвь при готовности.

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

• Шаблоны и документация: храните шаблоны и документацию в удаленном репозитории при управлении проектом с помощью связанных служб, таких как Azure DevOps.
• вспомогательные файлы: храните вспомогательные файлы в удаленном репозитории, когда он доступен для легкого отслеживания изменений и управления ими.
• файлы содержимого: храните содержимое в удаленном репозитории, когда это критически важно для бизнеса; или, если вы планируете сотрудничать с другими разработчиками над тем же содержимым. Удаленный репозиторий идеально подходит для отслеживания изменений содержимого и упрощения совместной работы.

Подсказка

При использовании удаленного репозитория настоятельно рекомендуется хранить отчеты и семантические модели Power BI в виде файлов проектов Power BI Desktop (PBIP) вместо PBIX-файлов. Это связано с тем, что сохраненные изменения не могут быть идентифицированы в PBIX-файле.

Кроме того, рекомендуется использовать расширенный формат отчета Power BI (PBIR) для отчетов. Формат PBIR обеспечивает более легкость чтения метаданных отчета, что упрощает отслеживание и управление изменениями в системе контроля версий. Кроме того, отчеты, использующие этот формат, легче управляемы программными средствами, такими как semantic-link-labs, библиотека Python от компании Microsoft, которую можно использовать в тетрадях Fabric.

Нет файлов: содержимое, созданное на портале Fabric

Создатели содержимого могут создавать содержимое непосредственно на портале Fabric. В этом сценарии они обычно не работают непосредственно с файлами содержимого. Как правило, вы должны создавать содержимое на портале Fabric только в том случае, если типы элементов не могут быть созданы в другом месте (например, потоки данных, панели мониторинга или системы показателей). Вы также можете создавать отчеты и семантические модели на портале Fabric, если у вас нет доступа к компьютеру с Windows и поэтому не может использовать Power BI Desktop. Дополнительные сведения см. в разделе "Пользовательские средства и устройства".

Осторожность

Вы не можете скачать в виде файла некоторое содержимое, созданное на портале Fabric. Например, отчеты, созданные на портале Fabric, нельзя скачать как PBIX-файлы.

При создании содержимого на портале Fabric вместо этого следует использовать API Fabric или интеграцию Git для резервного копирования определений содержимого . При резервном копировании определений контента вы снижаете нарушения, если это содержимое случайно удаляется или непреднамеренно изменяется. Если содержимое случайно удалено или изменено, его можно заменить с помощью резервной копии.

Контрольный список - При планировании и проектировании контента ключевые решения и действия включают:

• Планирование решений: Сбор бизнес-требований и технических требований для достаточного понимания проблемы, которую будет решать ваше содержание, и для разработки того, как это содержание будет решать проблему.
• Определите, кто будет создавать содержимое. В зависимости от рабочего процесса, навыков и потребностей отдельного создателя контента могут потребоваться различные подходы к управлению жизненным циклом.
• определить, требуется ли совместное взаимодействие нескольких создателей контента. Убедитесь, что создатели содержимого совместно используют типы файлов, поддерживающие управление версиями, такие как PBIP-файлы.
• Решите, как создатели контента будут сотрудничать: определите, насколько сложным будет сотрудничество. Кроме того, определите, как упростить эту совместную работу, например с помощью Microsoft Teams, Azure DevOps или GitHub.
• Определите формат содержимого. Определите, будут ли семантические модели и отчеты Power BI состоять из PBIX-файлов или PBIP-файлов (или других форматов, таких как BIM или TMDL для моделей), а также будет ли отчеты использовать формат PBIR или нет.
• определите, как будет использоваться содержимое: оцените, как пользователи будут взаимодействовать с данными. Определите, какие типы элементов необходимо создать для поддержки потребления, и требуется ли пользователям только разрешение на чтение, а также разрешения на сборку базовых семантических моделей или других элементов данных. Если пользователям действительно требуются разрешения на сборку, заранее определите, как они будут использовать семантические модели, и как вы будете их этому обучать эффективно.
• настройка средств совместной работы. Убедитесь, что вы выполняете необходимую первую настройку для решения или проекта. Принимать ключевые решения о том, как управлять совместной работой с помощью этих средств.
• хранить файлы источника данных в SharePoint или OneLake: хранить небольшие, простые файлы источника данных в SharePoint. В противном случае используйте OneLake или ADLSGen2 (если они доступны).
• Храните содержимое и вспомогательные файлы в SharePoint, Microsoft Teams или репозитории Git. Для более простых, небольших проектов используйте SharePoint для большинства файлов, если это организовано, и вы соблюдаете правила управления доступом. Для больших сред или при необходимости параллельной совместной работы рекомендуется использовать репозиторий Git в GitHub или Azure DevOps, который обеспечивает подробный обзор изменений содержимого.
• Хранение шаблонов и документации в Microsoft Teams или SharePoint: Эти шаблоны и документация предназначены для пользователей сообщества. Убедитесь, что шаблоны и документация легко находятся, используются и понимаются другими пользователями.
• План разработки и развертывания. Чтобы завершить этот первый этап, выполните конкретное планирование ключевых областей и провести начальную настройку. Например, установите средства и проверьте подключения к источнику данных.

Связанный контент

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