共用方式為

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 階段，這是內容規劃和設計階段。

注意

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

提示

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

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

建議您針對內容建立者使用 Microsoft Teams 共同作業方式定義結構化的程序。 請務必要確定：

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

Azure DevOps

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

圖表顯示方法 2，即使用 Azure DevOps 共同作業。接下來會顯示描述圖表中的項目。

注意

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

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

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

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

提示

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

建議您針對內容建立者使用 Azure DevOps 共同作業方式定義結構化的程序。 請務必要確定：

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

注意

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

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

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

決定儲存檔案的位置

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

提示

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

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

  • 內容檔案：包含內容資料或中繼資料的檔案。 包含 .pbix 和 Power BI Project (.pbip) 檔案等資料的內容檔案包含敏感性資訊。 將內容檔案儲存在安全的位置，只有需要存取這些檔案的人才能存取。 此外，您應該將內容檔案儲存在支援版本控制的位置，例如 Microsoft Teams 中的文件庫或 Azure DevOps 中的 Git 存放庫。 內容檔案的範例包括：
    • Power BI Desktop (.pbix) 檔案
    • Power BI Project (.pbip) f檔案
    • 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 報表。 以這種方式開啟報表時，這些報表會顯示在瀏覽器中。 這項功能可以是從網狀架構入口網站檢視報表的便利替代方案。 預設會在網狀架構租用戶設定中啟用。

提示

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

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

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

警告

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

警告

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

OneLake

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

警告

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

此外，使用 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 檔案中無法識別已儲存的變更。

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

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

警告

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

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

檢查清單 - 規劃及設計內容時的重要決策和動作包括：

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

相關內容

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