Создание содержимого для миграции в Power BI

В этой статье описывается этап 4, который связан с созданием и проверкой содержимого при миграции в Power BI.

Примечание.

Полное описание приведенного выше рисунка см. в обзоре миграции Power BI.

Фокус этапа 4 выполняет фактическую работу, чтобы преобразовать доказательство концепции (POC) в готовое к работе решение.

Выходные данные этого этапа — это решение Power BI, которое было проверено в рабочей области разработки и готово к развертыванию в рабочей среде.

Совет

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

Создание рабочего решения

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

Внимание

Повторно используйте как можно больше работы из POC.

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

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

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

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

• Получение данных из одного или нескольких источников данных (которые могут быть потоком данных Power BI).
• Фигура, объединение и подготовка данных.
• Создайте семантику модели, включая таблицы дат.
• Создание и проверка связей модели.
• Определите меры.
• При необходимости настройте безопасность на уровне строк.
• Настройте синонимы и оптимизируйте Q&A.
• Планирование масштабируемости, производительности и параллелизма, что может повлиять на решения о режимах хранения данных, таких как использование составной модели или агрегатов.

Совет

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

Разработка новых отчетов и панелей мониторинга

К основным действиям, связанным с разработкой отчета Или панели мониторинга Power BI, относятся:

• Решите использовать динамическую Подключение для существующей модели данных или создать новую модель данных.
• При создании новой модели данных определите режим хранения данных для таблиц моделей (импорт, DirectQuery или Составной).
• Выберите лучшее средство визуализации данных в соответствии с требованиями: Power BI Desktop, с разбивкой на страницы построитель отчетов или Excel.
• Определите лучшие визуальные элементы , чтобы рассказать историю отчета, необходимо рассказать, и решить вопросы, которые необходимо ответить на этот отчет.
• Убедитесь, что все визуальные элементы представляют четкие, краткие и понятные для бизнеса терминологии.
• Устранение требований к интерактивности.
• При использовании live Подключение ion добавьте меры уровня отчета.
• Создайте панель мониторинга в служба Power BI, особенно если потребители хотят легко отслеживать ключевые метрики.

Примечание.

Многие из этих решений будут приняты на более ранних этапах планирования или в технической POC.

Проверка решения

Существует четыре основных аспекта проверки решения Power BI:

1. Точность данных
2. Безопасность
3. Функция
4. Производительность

Проверка точности данных

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

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

Проверка безопасности

При проверке безопасности необходимо учитывать два основных аспекта:

• Разрешения в отношении данных
• Доступ к семантической модели, отчетам и панелям мониторинга

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

Основными способами предоставления доступа к содержимому Power BI являются:

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

Совет

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

Проверка функциональности

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

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

Проверка производительности

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

Многие проблемы с производительностью возникают из нестандартного daX (анализа данных eXpressions), плохой семантической модели или неоптимального проектирования отчетов (например, при попытке отрисовки слишком большого количества визуальных элементов на одной странице). Технические проблемы с средой, такие как сеть, перегруженный шлюз данных или настройка емкости Premium, также могут способствовать проблемам с производительностью. Дополнительные сведения см. в руководстве по оптимизации power BI и устранении неполадок с производительностью отчетов в Power BI.

Внимание

Иногда эта статья относится к Power BI Premium или ее подпискам на емкость (SKU). Обратите внимание, что корпорация Майкрософт в настоящее время объединяет варианты покупки и отставает от номера SKU емкости Power BI Premium. Новые и существующие клиенты должны рассмотреть возможность приобретения подписок на емкость Fabric (SKU) вместо этого.

Дополнительные сведения см. в разделе "Важные обновления", поступающие в лицензирование Power BI Premium и вопросы и ответы по Power BI Premium.

Документируйте решение

Существует два основных типа документации, которые полезны для решения Power BI:

• Документация по семантической модели
• Документация по отчетам

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

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

Совет

Если вы создаете сайт для работы в качестве центра документации, связанной с Power BI, попробуйте настроить меню справки get с его URL-адресом.

Создание документации по семантической модели

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

• Решения по проектированию и причины.
• Кто владеет, поддерживает и сертифицированы семантические модели.
• Требования к обновлению данных.
• Пользовательские бизнес-правила, определенные в семантических моделях.
• Определенные требования к безопасности семантической модели или конфиденциальности данных.
• Будущие потребности в обслуживании.
• Известные открытые проблемы или отложенные элементы невыполненной работы.

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

Создание документации по отчету

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

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

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

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

Другие полезные ресурсы:

• Преобразование бизнес-аналитики Майкрософт
• Планирование реализации Power BI
• Вопросы? Задайте их в сообществе Power BI.
• Есть предложения? Участие в разработке идей по улучшению Power BI

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