Share via

Power BI 實作規劃：規劃和設計內容

  • 發行項

注意

本文構成Power BI實作規劃系列文章的一部分。 此系列主要著重於 Microsoft Fabric 內的 Power BI 工作負載。 如需系列簡介，請參閱 Power BI 實作規劃。

本文可協助您在管理內容生命週期時規劃及設計內容。 主要以下列目標為目標：

  • 卓越中心（COE）和BI小組： 負責監督組織中Power BI的團隊。 這些小組包括決定如何管理 Power BI 內容的生命週期的決策者。
  • 內容建立者和內容擁有者： 建立想要發佈至 Fabric 入口網站內容以與他人共用的使用者。 這些個人負責管理其建立的Power BI內容的生命週期。

生命週期管理包含您用來處理內容從建立到最終淘汰的內容的程式和做法。 如本系列第一篇文章所述，管理 Power BI 內容生命週期對於確保內容傳遞給商務使用者可靠且一致非常重要。

內容生命週期的第一個階段是規劃和設計內容。 您通常會執行 BI 解決方案規劃來啟動內容生命週期。 您可以 收集需求 ，以瞭解並定義解決方案應解決的問題，並到達解決方案設計。 在此規劃和設計階段中，您會做出重要決策，以準備後續階段。

下圖描述Power BI內容的生命週期，並醒目提示您規劃和設計內容的階段一。

圖表顯示Power BI內容生命週期。第 1 階段是關於內容規劃和設計，會反白顯示。

注意

如需內容生命週期管理的概觀，請參閱 本系列中的第一篇文章。

提示

本文著重於內容規劃和設計的重要考慮和決策，因為它們與生命週期管理有關。

  • 如需如何有效規劃和設計 Fabric 或 Power BI 解決方案的詳細資訊，建議您閱讀解決方案規劃文章。
  • 如需如何 有效規劃 Power BI 移轉的詳細資訊，建議您閱讀 Power BI 移轉 系列。

收集需求時，您應該清楚描述影響您生命週期管理方法之內容的各個層面。 您應該將這些層面記錄為解決方案規劃和設計的一部分。

本文中的下列各節說明解決方案的主要層面和考慮，這些層面和考慮會在您規劃和設計內容時激勵您生命週期管理的方法。

識別並描述內容

當您設計解決方案時，您應該描述內容是什麼、將建立內容的人員、誰將支援它，以及此內容對組織有多重要。 您應該在解決方案設計期間或完成之後處理這些因素， 以收集需求 。

注意

如同您的需求，這些問題的解答可能會在您開發解決方案時變更，或稍後在其生命週期中變更。 回答這些問題之後，請準備好在對內容進行變更時定期重新評估，或隨著其服務的用戶數目進行調整。

回答下列有關內容的問題，以協助您做出稍後的生命週期管理決策。

內容的格式為何？

內容的類型、範圍和複雜度會激勵您如何管理內容的重要決策。 例如，相較於整個組織及多個不同下游工作負載將使用的語意模型，有限對象的單一報表需要不同的生命週期管理方法。

回答如下的問題，以協助您判斷您將建立的內容類型。

  • 您預期要建立哪些項目類型，以及每個專案有多少類型？ 例如，您是否會建立數據流或語意模型、報表或儀錶板等報表專案或兩者的組合等數據項？
  • 內容如何傳遞至內容取用者？ 例如，取用者會使用數據項來建置自己的內容、只會檢視集中式報表，還是兩者的組合？
  • 內容有多複雜？ 例如，它是小型原型，還是包含多個商務程式的大型語意模型？
  • 您是否預期內容的規模、範圍和複雜度會隨著時間成長？ 例如，內容未來會包含其他區域或商業區域嗎？
  • 您預期企業需要此內容多久？ 例如，此內容是否會支援具有有限時程表之企業的重要計劃？

提示

請考慮製作架構圖表來描述內容的格式。 您可以包含不同的數據源、專案類型和內容取用者，以及這些離散元件之間的關聯性。 架構圖表可協助您精簡描述內容及其複雜性，並協助您規劃其生命週期管理。 您可以使用網狀架構圖示和 Azure 圖示，在外部軟體中建立這些圖表。 或者，您可以使用 Azure 圖表，其中包含圖示和繪圖工具來製作這些圖表。

如需這類圖表的範例，請參閱 Power BI 實作規劃 使用案例圖表。

神秘 會建立及支持內容嗎？

內容建立者有不同的需求、技能和工作流程。 這些因素會影響不同生命週期管理方法的成功。 具有共同作業的大型中央小組通常需要比較小的自助建立者小組更複雜的內容生命週期管理。

回答如下的問題，以協助您判斷誰將建立或支持內容。

  • 您預期要建立此內容多少個不同的個人？ 多個內容建立者會共同作業，還是單一個人負責建立內容？
  • 內容建立者是否熟悉生命週期管理和相關概念，例如版本控制？ 內容建立者是否瞭解生命週期管理的優點？
  • 開發解決方案的內容建立者會是部署後支援解決方案的人員嗎？
  • 內容建立者或其小組是否已有現有的生命週期管理做法，以支援現有的解決方案？
  • 內容建立者目前是否使用 Azure DevOps 之類的生命週期管理工具？

重要

請確定您清楚記載誰負責建立內容，以及一旦部署至生產環境，誰將支持內容。 在您的內容生命週期管理規劃中涉及所有這些個人。

內容的重要性為何？

視內容對企業的重要性而定，您將針對如何管理內容做出不同的決策。 業務關鍵性內容需要更健全的內容生命週期管理方法，以保護品質並降低可能的中斷。

回答如下的問題，以協助您判斷內容是否重要。

  • 此內容對企業有多重要？ 發展它的要求有多緊迫？
  • 是否要從此內容提供的資訊做出業務關鍵決策或動作？
  • 您期望將此內容散發到整個組織到有限的本地小組，其範圍有多廣泛？
  • 高管或其他戰略決策者會依賴此內容來工作嗎？
  • 此內容有何影響？ 例如，如果內容突然無法使用，會發生什麼業務影響，例如遺失營收或中斷的商務程式？

當您已充分識別並描述您將建立的內容時，接下來應該決定內容建立者應如何共同作業。

決定內容建立者應如何共同作業

隨著解決方案的範圍和複雜度增加，多個內容建立者和擁有者可能需要共同作業。 建立複雜的解決方案時，建議您使用有效的工具來協助建構、管理及支援共同作業。 在產生 Power BI 內容時，有許多方式可以共同作業，例如使用 Microsoft Teams 或 Azure DevOps。

提示

即使內容建立者獨立工作，他們仍然可以使用 Microsoft Teams 和 Azure DevOps 等工具來規劃和建構其工作。

Microsoft Teams

對於較小型或更簡單的項目，內容建立者可以使用 Microsoft Teams 共同作業。

圖表顯示方法 1，也就是使用 Microsoft Teams 共同作業。下圖中顯示的專案如下所述。

藉由使用 Microsoft Teams，內容建立者會建構其在小組和頻道中的通訊、規劃和工作。 Microsoft Teams 通常是較簡單共同作業案例的絕佳選擇。 例如，針對有限對象產生內容的分散式小組可以使用文檔庫來儲存檔案和版本控制。 它們也可以使用其他整合式工具和服務。

提示

建議您使用 Microsoft Teams，透過分散式內容傳遞，在自助案例中促進有效的內容生命週期管理。

若要在 Microsoft Teams 中共同作業和通訊，您可以在 Power BI 內容的整個生命週期中使用支持服務。

  • Planner：內容擁有者可以使用 Planner 來建立計劃，其用來追蹤工作和範圍內容工作。 工作可以描述解決方案中的問題、Bug 或功能，以及對應的項目關係人。
  • SharePoint： 內容建立者可以在 Microsoft Teams 文檔庫或每個頻道連線的網站中儲存和管理檔案。 儲存在 SharePoint 中的內容檔案可以使用版本控制來協助追蹤和管理內容變更。 如需使用 SharePoint 追蹤和管理變更的詳細資訊，請參閱 階段 2：開發內容和管理變更。
  • 核准：內容建立者和擁有者可以在檢閱後設定和使用工作流程來核准內容變更或發行。
  • 網狀架構和 Power BI： 內容建立者和擁有者可以從 Microsoft Teams 記憶體取網狀架構入口網站。 他們可以從該處管理或討論內容，並將有用的報表新增至Teams頻道中的索引標籤。
  • 其他整合： 內容建立者可以使用與 Microsoft Teams 整合的其他 Microsoft 或第三方服務，以最符合他們慣用的工作流程和需求。

建議您定義內容建立者應如何使用 Microsoft Teams 共同作業的結構化程式。 確定您判斷：

  • 如何管理小組和頻道存取權。
  • 神秘 負責管理小組和頻道。
  • 工作的範圍和組織方式分為不同的小組、頻道和方案。
  • 內容建立者應該如何使用文檔庫來組織檔案及追蹤和管理變更。 例如，如何組織文檔庫，以及內容建立者是否應該簽入和簽出檔案。
  • 內容建立者是否應該使用 OneDrive Refresh 自動發佈 Power BI Desktop （.pbix） 檔案。
  • 如何解決檔案同步衝突。
  • 封存和移除不再相關的文檔庫檔案的時機。

Azure DevOps

內容建立者和擁有者也可以使用 Azure DevOps，在集中組織中樞進行通訊和共同作業。

圖表顯示使用 Azure DevOps 共同作業的方法 2。下圖中顯示的專案如下所述。

注意

Azure DevOps 是一套與 Power BI 和 Fabric 整合的服務，可協助您規劃和協調內容生命週期管理。 以這種方式使用 Azure DevOps 時，您通常會利用下列服務：

  • Azure Repos： 可讓您建立及使用遠端 Git 存放庫，這是用來追蹤和管理內容變更的遠端儲存位置。
  • Azure Pipelines： 可讓您建立和使用一組自動化工作，以處理、測試及將內容從遠端存放庫部署到工作區。
  • Azure 測試計劃： 可讓您設計測試來驗證解決方案，並將品質控制與 Azure Pipelines 一起自動化。
  • Azure Boards： 可讓您使用面板來追蹤工作和計劃作為工作專案，以及鏈接或參考來自其他 Azure DevOps 服務的工作專案。
  • Azure Wiki： 可讓您與其小組分享資訊，以了解並參與內容。

藉由使用 Azure DevOps，內容建立者會使用專案來建構其通訊、規劃和工作。 此外，內容建立者可以藉由執行 原始檔控制、驗證和部署，從 Azure DevOps 內協調內容生命週期管理。 原始檔控制是管理內容程式代碼和元數據更細微的變更程式。

Azure DevOps 通常是更進階共同作業案例的絕佳選擇，因為有可協調內容建立和部署的支援服務和選項。

提示

建議您使用 Azure DevOps 來協助企業案例中具有集中式內容傳遞的有效內容生命週期管理。 使用 Azure DevOps 或類似工具共同作業，在較大型或更複雜的案例中，偏好使用 Microsoft Teams 或 SharePoint 共同作業。 這是因為有更多的工具和選項可用來促進更強大的共同作業和自動化。

建議您定義結構化程式，讓內容建立者如何使用 Azure DevOps 共同作業。 確定您判斷：

  • 如何設定工作範圍，以及如何建立、命名及使用內容分支。
  • 作者如何分組和認可變更，並使用認可訊息加以描述。
  • 神秘 負責使用提取要求來檢閱和核准變更。
  • 如何解決提取要求合併衝突，以及解決這些衝突的人員。
  • 如何在不同分支中所做的變更合併成單一分支。
  • 內容在部署之前，如何測試內容及執行測試的人員。
  • 變更部署至開發、測試和生產工作區的方式和時機。
  • 部署的變更或解決方案版本的復原方式和時機。

注意

您也可以搭配 Azure DevOps 使用 Microsoft Teams，因為整合這些服務的方式有不同。 例如，您可以從 Microsoft Teams 檢視和管理 Azure Pipelines 中的 Azure Boards 及監視事件。

最重要的是，您使用的工具和服務可協助您共同作業，且最符合小組的需求和工作方式。

當您決定內容建立者應該如何共同作業時，接下來應該決定要儲存盤案的位置。 其中許多檔案會儲存在您選擇的共同作業位置。

決定儲存盤案的位置

建立內容時，您通常會產生不同類型的檔案。 請務必決定儲存這些檔案的位置，以便您有效地管理這些檔案。

提示

儲存可供多個小組成員存取的檔案，以及可以輕鬆地追蹤變更的檔案（稱為 版本控制）。 此方法可確保小組成員或檔案遺失不會導致中斷。

您需要儲存的檔案類型通常包括：

  • 內容檔案： 包含內容數據或元數據的檔案。 包含 .pbix 和 Power BI 專案 （.pbip） 檔案等數據的內容檔案包含敏感性資訊。 將內容檔案儲存在安全的位置，只有需要存取這些檔案的人才能存取。 此外，您應該將內容檔案儲存在支援版本控制的位置，例如 Microsoft Teams 中的文檔庫或 Azure DevOps 中的 Git 存放庫。 內容檔案的範例包括：
    • Power BI Desktop （.pbix） 檔案
    • Power BI 專案 （.pbip） 檔案
    • Power BI 編頁報表 （.rdl） 檔案
    • 模型元數據 （.bim 或 TMDL） 檔案
    • 數據流元數據 （.json） 檔案
  • 數據源檔案： 語意模型或數據流等數據項所取用的檔案。 內容直接相依於數據源檔案，因此請務必仔細考慮儲存的位置，因為移除它們會導致數據重新整理失敗。 此外，這些檔案可能包含敏感性資訊。 因此，將數據源檔案儲存在安全、可靠且可信任的環境中，而其他人員可限制存取權。 資料來源檔案的範例可能包括：
    • 結構化數據源，例如 Excel 活頁簿、Parquet 或 CSV 檔案。
    • 半結構化數據源，例如 JSON 或 XML 檔案。
    • 非結構化數據源，例如您匯入報表的影像。
  • 支援檔案： 支持內容建立或管理的檔案，但不需要它才能運作。 支援檔案應該儲存在支援版本控制的位置，以及其他工具和內容建立者可以存取它們的位置。 支援檔案的範例可能包括：
    • 最佳做法分析器規則 （.json） 檔案。
    • Power BI 主題 （.json） 檔案。
    • 內容和查詢的原始碼檔案。
    • 自定義視覺效果 （.pbiviz） 檔案。
  • 範本和文件： 協助建立自助內容或描述現有內容的檔案。 範本和文件應該可供需要使用範本的人員輕鬆存取。 樣本和檔的範例可能包括：
    • Power BI 範本 （.pbit） 檔案。
    • 視覺效果範本和範例報表。
    • 解決方案設計和檔。
    • 解決方案規劃和藍圖。
    • 使用者要求和解決方案問題。

警告

某些內容檔案，例如 .pbix 和 .pbip 檔案可以包含從數據源匯入的敏感數據。 此外，TMDL 或 .pbit 檔案等元數據檔案也可以包含敏感性資訊。 請確定您採取必要的預防措施，將這些檔案儲存在安全的位置，並練習有效的 數據外洩防護。

您有不同的儲存檔案選項。 請確定您根據檔類型、其內容，以及其使用方式，選取適當的位置。

SharePoint Online 或 OneDrive

儲存檔案的常見解決方案是使用 SharePoint 網站。 SharePoint 可供大部分用戶廣泛存取，並與 Power BI 和其他 Microsoft 365 應用程式高度整合，例如 Microsoft Teams。 此外，它具有內 建的版本控制，因此方便儲存大部分的文件類型。 版本控制可讓您檢視及管理檔案的不同儲存版本。

當您將檔案儲存在 SharePoint 中時，請考慮下列幾點。

  • 組織： 請確定您維護一致且邏輯的結構，以便直接尋找特定檔案。 使用良好的命名慣例、組織資料夾中的檔案，以及不再與進行中專案相關的封存盤案。
  • OneDrive 重新整理：您可以將已發佈的語意模型或報表連結至儲存在 SharePoint 或 商務用 OneDrive 的 .pbix 檔案（也稱為工作用 OneDrive 或學校版）網站。 使用這種方法，您不再需要發佈語意模型，即可生效。 相反地，您的變更會在自動 OneDrive 重新整理之後顯示， 這會每小時發生。 雖然方便，但請注意，這種方法隨附一些 警告和挑戰。 當事情發生時，它無法輕易地反轉。
  • 預覽報表： 在 SharePoint 中， 不需要在本機安裝 Power BI Desktop 或下載 .pbix 檔案，即可檢視 Power BI 報表 。 當您以這種方式開啟報表時，報表會顯示在 瀏覽器中。 這項功能可以是從網狀架構入口網站檢視報表的便利替代方案。 根據預設，它會在 Fabric 租用戶設定中啟用。

提示

當您使用 Microsoft Teams 共同作業時，請考慮將檔案儲存在頻道文檔庫中。 此方法可協助集中處理檔案，並協助共同作業。

請考慮將下列檔類型儲存在 SharePoint 中。

  • 範本和文件： 當您沒有現有的記憶體解決方案時，將範本和檔案儲存在 SharePoint 中。 SharePoint 非常適合這些檔案，因為您可以授與其他檔案的存取權，並管理檔案，而不需要複雜的設定或程式。
  • 支援檔案： 當您沒有現有的記憶體解決方案時，將支援檔案儲存在 SharePoint 中。 不過，某些支援檔案（例如 Power BI 主題.json報表的檔案）可能會較好地儲存在版本控制系統中，以允許檢視和管理儲存的變更。
  • 內容檔案：當內容對企業不重要，或您沒有 Azure Repos 等遠端存放庫的存取權時，請將內容儲存在 SharePoint 中。
  • 數據源： 只有在數據源大小小且複雜時，才將數據源儲存在SharePoint中。 使用 SharePoint 儲存數據源檔案時，練習專業領域。 請考慮其他可能的替代方案，例如 OneLake。

警告

請勿使用 SharePoint 做為適當數據架構的替代方案。 雖然在 SharePoint 中儲存數據源檔案在一些有限的案例中可能很方便，但當您擁有較大、更複雜的數據源，或需要較低的數據延遲時，此方法不會進行調整。

警告

請勿使用個人文件系統或個人 OneDrive 帳戶來儲存盤案。 如果擁有者離開組織，這些檔案將無法再使用。

OneLake

如果您有 網狀架構容量，OneLake 是儲存數據源檔案的好選擇。 您可以使用 OneLake 檔案總管，將檔案上傳或同步處理至 OneLake，其可以轉換成數據表，以便在 Power BI 等下游工作負載中使用。 針對較大型或定期更新的數據源，您可以使用 Fabric Data Factory 或其他使用 Azure Data Lake 儲存體 （ADLS） Gen2 API 或 Azure 儲存體 Python SDK 的應用程式，自動將檔案載入 OneLake。

警告

從 OneLake 上傳或下載檔案等動作會耗用 Fabric 容量單位。 您應該 監視容量計量 ，並採取步驟，以避免因大量檔案不必要的移動所造成的容量壓力。

此外，具有 OneLake 檔案總管 的使用者所存取的檔案容易受到意外變更或遺失的影響。 建議您避免針對業務關鍵解決方案使用 OneLake 檔案總管。

警告

OneLake 檔案總管 有幾個重要的限制和考慮。 例如，OneLake 不支援檔案的版本控制，例如 SharePoint 或 OneDrive。 當您決定儲存盤案的位置時，請考慮到這些考慮和限制。

提示

將數據儲存在 OneLake 時，請考慮啟用 商務持續性和災害復原 （BCDR）， 以降低數據遺失的風險。 啟用BCDR後，您的資料會根據 Azure 的標準區域配對，複製並儲存在兩個不同的地理區域中。

遠端存放庫

內容建立者可以在開發期間定期將工作從本機計算機認可並儲存到 遠端存放庫，例如 Azure Repos Git 存放庫。 遠端存放庫包含解決方案的最新版本，而且整個開發小組都可以存取它。 遠端存放庫通常比使用Teams、SharePoint或OneDrive更進階的生命週期管理方法。 這是因為使用遠端存放庫，內容建立者可以從更複雜的選項中獲益，以在檔案上共同作業，或追蹤和管理檔案變更。 例如，內容建立者可以在遠端存放庫的自己的分支上工作以進行變更，並在準備好時要求將這些變更合併到主要分支。

請考慮將下列檔類型儲存在遠端存放庫中。

  • 範本和文件：當您使用 Azure DevOps 等相關服務來管理專案時，將範本和文件儲存在遠端存放庫中。
  • 支援檔案： 當一個檔案可供輕鬆追蹤及管理變更時，將支援檔案儲存在遠端存放庫中。
  • 內容檔案： 當內容對企業至關重要時，請將內容儲存在遠端存放庫中，或您想要與其他開發人員就相同內容共同作業。 遠端存放庫很適合用來追蹤內容變更並協助共同作業。

提示

當您使用遠端存放庫時，請考慮將Power BI報表和語意模型儲存為 Power BI Desktop專案 （.pbip） 檔案 ，而不是 .pbix 檔案。 這是因為 .pbix 檔案中無法識別已儲存的變更。

沒有檔案：在網狀架構入口網站中建立的內容

內容建立者可以直接在 Fabric 入口網站中撰寫內容。 在此案例中，它們通常不會直接使用內容檔案。 您通常應該只在無法於其他地方建立項目類型時，才應該在 Fabric 入口網站中撰寫內容（例如數據流、儀錶板或計分卡）。 當無法存取 Windows 計算機時，您也可以在 Fabric 入口網站中撰寫報表和語意模型，因此無法使用 Power BI Desktop。 如需詳細資訊，請參閱 使用者工具和裝置。

警告

您無法將某些內容下載為在 Fabric 入口網站中建立的檔案。 例如，在 Fabric 入口網站中建立的報告無法下載為 .pbix 檔案。

在 Fabric 入口網站中撰寫內容時，您應該改用 Fabric API 或 Git 整合 來備份 內容定義。 當您備份內容定義時，如果不小心刪除或無意變更該內容，則可減輕中斷。 如果內容不小心遭到刪除或變更，您可以使用備份加以取代。

檢查清單 - 規劃及設計內容時，關鍵決策和動作包括：

  • 進行解決方案規劃： 收集 商務需求 和技術 需求 ，以充分瞭解您的內容將解決的問題，以及設計此內容如何處理問題。
  • 識別將建立內容的人員： 視個別內容建立者的工作流程、技能和需求而定，可能需要不同的生命週期管理方法。
  • 識別多個內容建立者是否需要共同作業： 確定共同作業內容建立者使用的是支援版本控制的檔類型，例如 .pbip 檔案。
  • 決定內容建立者將如何共同作業： 決定共同作業的複雜程度。 此外，決定您將如何促進此共同作業，例如使用 Microsoft Teams 或 Azure DevOps。
  • 設定共同作業工具： 請確定您針對方案或專案執行必要的第一次設定。 使用這些工具，決定您將如何管理共同作業的重要決策。
  • 在 SharePoint 或 OneLake 中儲存數據源檔案： 在 SharePoint 中儲存小型、簡單的數據源檔案。 否則，請改用 OneLake 或 ADLSGen2 （如果有的話）。
  • 將內容和支援的檔案儲存在 SharePoint 或遠端存放庫中： 針對更簡單、較小的專案，如果已組織，且您練習良好的存取管理，請使用 SharePoint 作為大部分檔案。 對於較大的環境，或需要平行共同作業時，請考慮使用遠端存放庫，以提供內容變更的詳細可見性。
  • 在 SharePoint 中儲存範本和文件： 確定範本和檔可供其他人輕鬆尋找、使用及瞭解。
  • 開發和部署規劃： 若要結束這一第一個階段，請執行特定規劃以解決 關鍵領域 並 進行初始設定。 例如，建立工具和測試數據源連線。

相關內容

在本系列中的下一篇文章中，瞭解如何在管理內容生命週期時開發內容及管理變更。