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

В этой статье описывается этап 3, который связан с проведением подтверждения концепции (POC) для снижения риска и устранения неизвестных случаев при миграции в Power BI.

Diagram shows the stages of a Power BI migration. Stage 3 is emphasized for this article.

Примечание.

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

Основной целью этапа 3 является решение неизвестных и устранение рисков как можно раньше. Техническая POC полезна для проверки допущений. Это можно сделать итеративно вместе с планированием развертывания решения (описано на этапе 2).

Выходные данные этого этапа — это решение Power BI, которое сужается в область, устраняет начальные открытые вопросы и готов к дополнительной работе на этапе 4, чтобы сделать ее готовой к рабочей среде.

Важно!

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

Совет

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

Установка целей POC и область

При проведении POC сосредоточьтесь на следующих целях:

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

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

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

Важно!

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

Обработка различий в Power BI

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

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

Рассмотрите возможность перепроектирования архитектуры данных

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

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

Внимание

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

Определите, как обрабатывать преобразования панелей мониторинга

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

  1. Устаревшая панель мониторинга можно создать в виде отчета Power BI. Большинство отчетов создаются с помощью Power BI Desktop. Отчеты с разбивкой на страницы и отчеты Excel также являются альтернативными вариантами.
  2. Устаревшая панель мониторинга может быть воссоздана как панель мониторинга Power BI. Панели мониторинга — это функция визуализации служба Power BI. Визуальные элементы панели мониторинга часто создаются путем закрепления визуальных элементов из одного или нескольких отчетов, Q&A или Краткая аналитика.

Совет

Так как панели мониторинга являются типом контента Power BI, не используйте слово панели мониторинга в имени отчета или панели мониторинга.

Сосредоточьтесь на большом рисунке при повторном создании визуальных элементов

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

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

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

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

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