共用方式為

Power BI 實作規劃：工作區層級工作區規劃

  • 發行項

注意

本文是 Power BI 實作規劃系列文章的其中一篇。 此系列主要著重於 Microsoft Fabric 中的 Power BI 體驗。 如需有關此系列的簡介，請參閱 Power BI 實作規劃。

本文涵蓋 Fabric 工作區層級規劃，強調 Power BI 體驗。 本文的主要目標讀者為：

  • Fabric 管理員：負責監督組織中 Fabric 的管理員。
  • 卓越中心、IT 和 BI 小組：負責監督資料和 BI 並在整個組織中支援自助使用者的小組。
  • 內容建立者和擁有者：需要在工作區中建立、發佈和管理內容的自助建立者。

若要有效地使用工作區，需要做出許多策略性決策。 可能的話，個別工作區層級決策應該與您的租用戶層級決策一致。

注意

工作區的概念源自 Power BI。 使用 Fabric 時，工作區的用途已變得更加廣泛。 結果是工作區現在可以包含來自一或多個不同 Fabric 體驗的項目 (也稱為工作負載)。 雖然內容範圍已比 Power BI 更廣，但這些文章中所述的大部分工作區規劃活動都可以套用至 Fabric 工作區規劃。

工作區用途

規劃工作區時，請務必考慮其儲存的內容類型，以及工作區要支援的活動。

請考慮下列兩個財務相關工作區範例。 雖然它們都專用於同一個小組，但每個工作區都有不同的用途：

  • 財務月底工作區：財務月底工作區包含對帳和月底報表。 此工作區被視為支援共同作業工作的非正式工作區。 內容檢視人員不需要 Power BI 應用程式，因為此工作區的主要用途是由一小組密切合作的人員共同作業。 大部分的小組成員都有權編輯此工作區中的內容。
  • 財務報表工作區：財務報表工作區包含已完成的簡報層級報告。 此工作區包含使用 Power BI 應用程式在組織中廣泛散發給許多檢視人員 (包括主管) 的內容。 工作區會受到密切控管。

考慮到這兩個範例，請考慮工作區用途的兩個特定層面：共同作業意圖，以及檢視意圖。

共同作業意圖

Fabric 入口網站中工作區的主要目標是促進多人之間的共同作業。 有許多方式可以在工作區中執行共同作業：

  • 以小組為基礎的開發：多人可以共同建置、測試及發佈內容。 一位使用者可能會處理資料湖存放庫的設計。 另一位使用者可能會處理語意模型的設計，而其他使用者則可能會專注於建置報表。
  • 測試和驗證：使用者可能需要針對新內容執行資料驗證。 營業單位中的主題專家可能需要執行使用者驗收測試 (UAT)，或者資料品質小組可能需要驗證語意模型的精確度。
  • 增強功能：內容專案關係人和取用者可能會在情況變更時建議內容的增強功能。
  • 擁有權轉移：其他人或小組可能會接管並負責其他人所建立的內容。

Fabric 採用藍圖的主要領域之一是內容擁有權和管理。 工作區中將發生的共同作業類型會根據內容擁有權和管理所使用的方法而有所不同：

  • 企業主導的自助 BI：內容是由營業單位或部門內的內容建立者所擁有和管理。 在此案例中，工作區中的大部分共同作業發生在該營業單位內的使用者之間。
  • 受控自助 BI：資料是由集中式小組所擁有和管理，而來自營業單位的各種內容建立者則負責報表和儀表板。 在此案例中，可能需要多個工作區，讓多個人員的小組安全地協助共同作業。
  • 企業 BI：內容是由集中式小組所擁有和管理，例如 IT、企業 BI 或卓越中心 (COE)。 在此案例中，工作區中的共同作業工作發生在集中式小組的使用者之間。

檢查清單 - 考慮您打算在工作區中共同作業時，關鍵決策和動作包括：

  • 考慮共同作業的期望：決定工作區共同作業需要如何發生，以及誰參與單一小組或跨組織界限。
  • 考慮內容擁有權和管理的期望：思考不同的內容擁有權和管理方法 (企業主導的自助 BI、受控自助 BI 和企業 BI) 將如何影響您設計和使用工作區的方式。

提示

當單一方法無法滿足您的需求時，請準備好具有彈性，並針對不同的工作區使用不同的內容擁有權和管理策略。 策略可以根據案例以及所涉及的小組成員。

內容檢視意圖

工作區的次要目標是將內容散發給需要檢視內容的取用者。 對於內容檢視人員，主要 Fabric 工作負載為 Power BI。

在 Power BI 服務中，有數種不同的方法可達成內容散發：

  • 您可以使用 Power BI 應用程式來檢視報表：儲存在非個人工作區中的內容可以發佈至 Power BI 應用程式。 Power BI 應用程式比直接在工作區中檢視報表更方便使用。 因此，使用 Power BI 應用程式通常是將內容散發給取用者的最佳選擇。 Power BI 應用程式的對象非常具有彈性。 不過，有時候您想要如何使用應用程式散發內容的目標，是決定如何在工作區中或跨工作區組織內容的因素。 如需保護 Power BI 應用程式的詳細資訊，請參閱報表取用者安全性規劃。
  • 報表可以直接在工作區中檢視：這種方法通常適用於非正式的共同作業工作區。 工作區角色會定義誰可以檢視或編輯工作區中包含的內容。 如需工作區角色的詳細資訊，請參閱內容建立者安全性規劃。
  • 可以共用報表：當需要提供工作區內單一項目的唯讀存取權時，使用個別項目權限 (連結或直接存取) 會很有用。 我們建議您比共用更頻繁地使用應用程式權限和工作區角色，因為它們更容易維護。 如需詳細資訊，請參閱報表取用者安全性規劃 (部分機器翻譯)。
  • 報表可以內嵌在另一個應用程式中，並在那裡檢視：有時取用者的目的是檢視內嵌在另一個應用程式中的 Power BI 內容。 內嵌內容適合讓使用者停留在應用程式中，以提高效率並保持在其工作流程中。

Fabric 採用藍圖的另一個重要領域是內容傳遞範圍。 工作區支援內容散發的方式會根據內容傳遞範圍而有所不同：

  • 個人 BI：內容供建立者使用。 由於與其他人共用內容並非目標，因此個人 BI 會在個人工作區內完成 (在下一個主題中描述)。
  • Team BI：內容會與相對密切合作的較少同事共用。 在此案例中，大部分工作區都是非正式的共同作業工作區。
  • 部門 BI：內容會散發給屬於大型部門或營業單位的許多取用者。 在此案例中，工作區主要是用於共同作業工作。 在部門 BI 案例中，內容通常會在 Power BI 應用程式中檢視 (而不是直接在工作區中檢視)。
  • 企業 BI：內容會廣泛跨組織界限傳遞至最大目標取用者數目。 在此案例中，工作區主要是用於共同作業工作。 針對企業 BI 案例，內容通常會在 Power BI 應用程式中檢視 (而不是直接在工作區中檢視)。

提示

當您規劃工作區時，請在判斷工作區授權模式時考慮對象的需求。 指派給工作區的授權類型會影響可用的功能，包括可檢視或管理工作區內容的人員。

檢查清單 - 當您考慮如何檢視工作區內容的預期時，關鍵決策和動作包括：

  • 請考慮檢視內容的預期：決定您希望取用者如何檢視已發佈至工作區的內容。 請考慮檢視是否會直接在工作區中發生，還是使用不同的方法。
  • 判斷將傳遞內容的對象：考慮目標對象是誰。 此外也請考慮工作區授權模式，特別是當您預期大量內容檢視人員時。
  • 評估 Power BI 應用程式的需求：考慮工作區用途，因為它與內容散發需求相關。 需要 Power BI 應用程式時，這可能會影響建立工作區的決策。
  • 考慮內容傳遞範圍的預期：考慮不同的內容傳遞範圍 (個人 BI、Team BI、部門 BI 和企業 BI) 將如何影響您設計和使用工作區的方式。

提示

準備好具有彈性。 您可以根據案例以及所涉及的小組成員，針對工作區使用不同的內容檢視策略。 此外，當整理工作區時，不要害怕針對工作區使用不同的內容傳遞範圍方法。

適當地使用個人工作區

有兩種類型的工作區：

  • 個人工作區：每個使用者都有個人工作區。 個人工作區可用來將特定類型的內容發佈至 Fabric 入口網站。 其主要目的是支援個人 BI 使用案例。
  • 工作區：工作區的主要目的是支援多個使用者之間的共同作業。 其次，工作區也可用來檢視內容。

針對學習個人 BI、暫存內容或測試目的以外的任何內容使用個人工作區可能會有風險，因為個人工作區中的內容是由一個人管理和維護。 此外，個人工作區不支援與其他人共同作業。

若要允許建立任何類型的 Fabric 項目 (例如資料湖存放庫或倉儲)，則必須將工作區新增至 Fabric 容量。 這適用於標準工作區和個人工作區。 因此，您可以透過其容量指派，控管能夠在個人工作區內建立特定類型項目的人員。

個人工作區在其選項中受到限制，無法與其他人共用內容。 您無法從個人工作區發佈 Power BI 應用程式 (而 Power BI 應用程式是將內容發佈至組織的重要機制)。 個別項目權限 (連結或直接存取) 是與其他人共用個人工作區內容的唯一方式。 因此，大量使用個別項目權限牽涉到更多工作，並增加錯誤的風險。 如需詳細資訊，請參閱報表取用者安全性規劃 (部分機器翻譯)。

檢查清單 - 考慮應使用個人工作區的預期時，關鍵決策和動作包括：

  • 了解個人工作區的目前用法：與使用者進行交談，並檢閱活動資料，以確保您了解使用者正在使用其個人工作區執行的動作。
  • 決定應該如何使用個人工作區：決定您組織中應 (及不應) 如何使用個人工作區。 專注於平衡內容共同作業和檢視需求的風險和易用性。
  • 適當時重新放置個人工作區內容：針對重要內容，請視需要將內容從個人工作區移至標準工作區。
  • 建立及發佈個人工作區的相關文件：為您的使用者建立實用的文件或常見問題集，以了解如何有效地使用個人工作區。 在您的集中式入口網站和訓練教材中提供資訊。

注意

如需詳細資訊，請參閱這些 Fabric 採用藍圖主題：集中式入口網站、訓練和文件。

工作區擁有權

規劃工作區時要考慮的最重要事項之一是決定擁有權和管理角色和責任。 目標是確定誰負責建立、維護、發佈、保護及支援每個工作區中的內容。

當建立和管理資料的責任分散或散布在部門與營業單位之間時，擁有權的明確性特別相關。 此概念有時也稱為資料網格架構。 如需資料網格的詳細資訊，請參閱什麼是資料網格？。

在 Fabric 中，透過工作區啟用散布或分散式擁有權。 組織的不同區域可以獨立運作，同時仍會參與 OneLake 中相同的基礎資料結構。 每個工作區都可以有自己的系統管理員、存取控制和容量指派 (用於計費、地理位置和效能監視)。

提示

在 Fabric 中支援工作區擁有權的另一種方式是網域，本文稍後會說明。

當共同作業的意圖涉及單一營業單位以外的多個小組時，它可能會增加管理工作區的複雜性。 建立個別工作區通常很有幫助，以清楚描述哪個小組負責哪些內容。 使用多個工作區可讓您確定擁有權和管理責任，並協助您根據最低權限原則來設定安全性。 如需更多安全性考量，請參閱內容建立者安全性規劃。

提示

與課責和責任相關的決策應該直接與定義工作區存取相關的動作相互關聯，本文稍後會說明。

檢查清單 - 考慮工作區擁有權責任時，關鍵決策和動作包括：

  • 深入了解內容擁有權的運作方式：確定您深入了解整個組織的內容擁有權和管理方式。 認識到可能不會是一律套用到整個組織的一體適用方法。 了解散布或分散式擁有權需求。
  • 定義和記錄角色和責任：確定您為工作區中共同作業的人員定義並記錄清楚的角色和責任。 在上線活動、訓練教材和集中式入口網站中提供這項資訊。
  • 建立責任矩陣圖：劃分預期會在建立、維護、發佈、保護及支援內容時處理每個職能的人員。 當您開始規劃工作區存取角色時，請準備好這項資訊。
  • 考慮共同擁有權或多小組擁有權案例：識別當案例存在時，在哪個位置才有助於將工作區分開，使責任明確。
  • 建立工作區管理文件：教導工作區系統管理員和成員如何管理工作區設定和存取。 包含工作區系統管理員、成員和參與者的責任。 在您的集中式入口網站和訓練教材中提供資訊。

工作區組織

如何組織工作區是工作區規劃最重要的層面之一。

根據共同作業需求，不同的營業單位和部門可能會稍微使用不同的工作區。 當您需要新的工作區時，建議您考慮本節所述的因素。

工作區主體和範圍

下列選項提供一些建議，說明如何依主體和範圍來組織工作區。

在某些情況下，您可能已經在Microsoft Entra 標識符中建立一些有用的群組。 然後，您可以使用它們來管理所定義主體區域和範圍的資源存取權。 不過，您可能需要建立一些新的群組，以符合此目的。 如需考量事項，請參閱下方的工作區存取一節。

選項 1：個別主體區域或專案的工作區

為每個主題區域或專案建立工作區可讓您專注於其用途。 它可讓您採取平衡的方法。

範例：每季財務或產品上市分析

選項 1 的優點包括：

  • 管理允許編輯或檢視內容的使用者存取權更為直接，因為它的範圍是個別主題區域。
  • 當使用者跨組織界限存取內容時，依主題區域建構工作區會更有彈性且更易於管理 (相較於接下來討論的選項 2)。
  • 在包含太多項目和包含太少項目的工作區之間，使用個別主體區域的範圍是很好的妥協。

選項 1 的缺點是，根據定義工作區寬窄的方式，將建立許多工作區仍有一些風險。 當內容分散到許多工作區時，尋找內容對使用者來說可能很困難。

提示

依主體區域或專案規劃完善且受控的工作區通常會產生可管理的工作區數目。

選項 2：個別部門或小組的工作區

建立每個部門或小組 (或營業單位) 的工作區是常見的方法。 事實上，遵循組織圖是人員開始使用工作區規劃的最常見方式。 不過，這並不適用於所有案例。

範例：財務部門或銷售小組分析

選項 2 的優點包括：

  • 開始使用規劃很簡單。 在該部門工作的人員需要的所有內容都會位於一個工作區中。
  • 使用者可以輕鬆知道要使用哪一個工作區，因為其所有內容都會發佈至與其部門或小組相關聯的工作區。
  • 管理安全性角色可以很簡單，特別是當 Microsoft Entra 群組指派給工作區角色時 (這是最佳做法)。

選項 2 的缺點包括：

  • 結果通常是包含許多項目的廣泛範圍工作區。 廣泛定義的工作區範圍可能會讓使用者難以找出特定項目。
  • 因為工作區與 Power BI 應用程式之間具有一對一關聯性，所以廣泛定義的工作區可能會導致使用者的應用程式包含大量內容。 從應用程式排除某些工作區項目，以及應用程式瀏覽體驗的良好設計可以減輕此問題。
  • 當其他部門的使用者需要檢視特定工作區項目時，管理權限可能會變得更複雜。 風險是人員會假設部門工作區中的所有內容只有他們才能看到。 風險也在於個別項目的共用將會過度使用，以達成細微的檢視權限。
  • 如果某些內容建立者需要編輯某些項目的權限 (但並非所有項目)，則無法在單一工作區中設定這些權限。 這是因為決定編輯或檢視權限的工作區角色是在工作區層級定義。
  • 當您有大量的工作區項目時，這通常表示您必須對項目使用嚴格的命名慣例，讓使用者能夠找到所需的項目。
  • 具有許多項目的廣泛工作區可能會對可儲存在工作區中的項目數目造成技術上的限制。

提示

建立符合組織圖的工作區時，您通常會有較少的工作區。 不過，它可能會導致包含大量內容的工作區。 當您預期有大量項目和/或許多使用者時，不建議根據每個部門或小組調整工作區。

選項 3：特定報表或應用程式的工作區

除了特定情況之外，不建議為每個報表或分析類型建立工作區。

範例：每日銷售摘要或主管獎金

選項 3 的優點包括：

  • 定義狹窄工作區的用途是明確的。
  • 超敏感性內容可能且通常隔離到自己的工作區中，以便明確地加以管理和控管。
  • 微調工作區權限適用於一些項目。 例如，當允許使用者編輯一個報表，但不能編輯另一個報表時，此設定就很有用。

選項 3 的缺點包括：

  • 如果過度使用，建立定義狹載的工作區會導致大量的工作區。
  • 搭配使用大量工作區會牽涉到更多工作。 雖然使用者可以依賴搜尋，但在正確的工作區中尋找正確的內容可能會令人沮喪。
  • 當有更多的工作區存在時，從稽核和監視的觀點來看會產生更多工作。

提示

建立範圍較窄的工作區，例如個別報表，應該只基於特定原因來執行。 它應該是例外狀況，而不是規則。 有時候，區分計分卡為個別工作區是一種實用的技術。 例如，當計分卡呈現跨越多個主題區域的目標時，使用個別工作區會很有幫助。 設定管理及檢視計分卡的特定權限也很有幫助。

檢查清單 - 考慮工作區內容的主題區域和範圍時，關鍵決策和動作包括：

  • 評估工作區目前設定的方式：檢閱人員目前使用工作區的方式。 識別哪些運作情況良好，而哪些效果不佳。 規劃潛在的變更和使用者教育機會。
  • 考慮最佳的工作區範圍：識別您希望人員如何根據用途、主題區域、範圍以及負責管理內容的人員來使用工作區。
  • 識別高度敏感性內容所在的位置：判斷何時可以合理建立高度敏感性內容的特定工作區。
  • 建立及發佈有關使用工作區的文件：為您的使用者建立實用的文件或常見問題集，以了解如何組織和使用工作區。 在訓練教材和集中式入口網站中提供這項資訊。

工作區項目類型

將資料工作區與報告工作區分開是將資料資產與分析資產分離的常見做法。

  • 資料工作區專門用來儲存和保護資料項目，例如資料湖存放庫、倉儲、資料管線、資料流程或語意模型。
  • 報告工作區更著重於下游分析活動。 它專門用來儲存和保護項目，例如報表、儀表板和計量。 主要報告工作區 (但不一定是獨佔) 包含 Power BI 內容。

提示

每個 Fabric 體驗都可讓您建立各種類型的項目。 這些項目不一定能完美符合何者會視為資料與報告 (或分析) 內容的概念。 其中一個範例是 Fabric 筆記本，可用於許多不同的方式，例如：在資料湖存放庫中載入和轉換資料、提交 Spark SQL 查詢，或使用 PySpark 分析及視覺化資料。 當工作區包含混合工作負載時，建議您主要著重於工作區的用途和內容的擁有權，如本文其他地方所述。

區分資料工作區與報告工作區的優點包括：

  • 重要的組織資料，例如已認可的資料湖存放庫或語意模型，可以位於專為以企業規模提供可重複使用資料而設計的特定工作區中。 常見範例包括：
  • 存取管理可以集中處理重要的組織資料。 當不同人員負責資料和報告時，相較於報告工作區，分別管理資料工作區的存取很有用。 使用受控自助 BI 時，通常會有許多報表建立者和較少的資料建立者。
  • 限制誰可以編輯和管理語意模型，將意外變更的風險降到最低，特別是針對許多用途或許多使用者重複使用的重要資料項目。 實體分離可減少意外或未經核准變更的機會。 這一層額外的保護對於經過認證的語意模型很有幫助，這些模型仰賴其品質和可信度。
  • 已釐清共同擁有權案例。 當共用語意模型從集中式 BI 或 IT 小組傳遞，而自助內容建立者 (在營業單位中) 發佈報表時，最好將語意模型隔離成個別工作區。 這種方法可避免共同擁有權案例的模棱兩可，因為每個工作區的擁有權和責任更清楚定義。
  • 已強制執行資料列層級安全性 (RLS)。 當您鼓勵建立者在不同的工作區中工作時，他們對於原始語意模型不會有非必要的編輯權限。 其優點在於 RLS 和/或物件層級安全性 (OLS) 將會針對內容建立者 (以及內容檢視人員) 強制執行。

區分資料工作區與報告工作區的缺點包括：

  • 需要工作區命名慣例，才能區分資料工作區與報告工作區。
  • 需要額外的使用者教育，以確保內容作者和取用者知道發佈和尋找內容的位置。
  • 有時候，明確描述應該包含在工作區中的項目類型是一項挑戰。 一段時間後，工作區最後可能會包含比原先預期更多的內容類型。
  • 使用個別工作區會導致您需要管理和稽核更多的工作區。 當您規劃目的、範圍和其他考量 (例如開發、測試和生產內容分離) 時，工作區設計的方法可能會變得更加複雜。
  • 可能需要額外的變更管理程序，才能追蹤和排定集中式資料項目的要求變更優先順序，特別是當報表建立者的需求超出複合模型和報表層級量值所能處理的範圍時。

檢查清單 - 考慮要儲存在工作區中的項目類型時，關鍵決策和動作包括：

  • 決定資料重複使用的目標：決定如何在受控自助 BI 策略中實現資料重複使用。
  • 更新可跨工作區使用語意模型的人員租用戶設定：判斷是否可將這項功能授與所有使用者。 如果您決定限制誰可以在工作區之間使用語意模型，請考慮使用 Fabric 核准的報表建立者等群組。

工作區存取

由於工作區的主要用途是共同作業，因此工作區存取大部分適用於建立和管理其內容的使用者。 當工作區用於檢視內容時，它也可能也會相關 (工作區的次要用途，如本文稍早所述)。

開始規劃工作區角色時，詢問自己下列問題會很有幫助。

  • 工作區中共同作業進行方式的預期為何？
  • 工作區是否會直接用於檢視取用者的內容？
  • 誰將負責管理工作區中的內容？
  • 誰將檢視儲存在工作區中的內容？
  • 是否打算將個別使用者或群組指派給工作區角色？

最佳做法是每當可行時，使用群組來指派工作區角色。 您可以指派不同類型的群組。 工作區角色都支援安全性群組、啟用郵件功能的安全性群組、通訊群組和 Microsoft 365 群組。 如需使用群組的詳細資訊，請參閱租用戶層級安全性規劃。

規劃使用群組時，您可能會考慮為每個工作區的每個角色建立一個群組。 例如，若要支援每季財務工作區，您可以建立下列群組：

  • Fabric 工作區管理員 – 每季財務
  • Fabric 工作區成員 – 每季財務
  • Fabric 工作區參與者 – 每季財務
  • Fabric 工作區檢視人員 – 每季財務
  • Power BI 應用程式檢視人員 – 每季財務

提示

建立上方列出的群組可提供彈性。 不過，它牽涉到建立和管理許多群組。 此外，只會由 IT 建立和維護群組時，管理大量群組可能會很困難。 藉由對特定附屬成員啟用自助群組管理，即可減輕這項挑戰。 這些成員可能包括卓越中心 (COE)、風雲人物，或已接受過訓練知道如何管理其營業單位角色成員資格的受信任使用者。 如需詳細資訊，請參閱租用戶層級安全性規劃。

當資料工作區與報告工作區分開時，如本文稍早所述，會產生更大的群組數目。 當您區分資料和報告工作區時，請考慮群組數目如何從 5 加倍增至 10：

  • Fabric 資料工作區管理員 – 每季財務
  • Fabric 報告工作區管理員 – 每季財務
  • Fabric 資料工作區成員 – 每季財務
  • Fabric 報告工作區成員 – 每季財務
  • Fabric 資料工作區參與者 – 每季財務
  • Fabric 報告工作區參與者 – 每季財務
  • Fabric 資料工作區檢視人員 – 每季財務
  • Fabric 報告工作區檢視人員 – 每季財務
  • Power BI 應用程式檢視人員 – 每季財務

當有多個工作區可供開發、測試和生產環境使用時，會產生更大的群組數目。 群組數目有可能是三倍。 例如，只有資料工作區管理員時，會有下列三個群組：

  • Fabric 資料工作區管理員 – 每季財務 [開發]
  • Fabric 資料工作區管理員 – 每季財務 [測試]
  • Fabric 資料工作區管理員 – 每季財務

先前的範例旨在傳達對應至工作區角色的群組使用可能會很快地變得無法管理。

提示

有時候需要較少的群組，特別是在開發階段。 例如，您可能不需要在開發階段指定工作區檢視人員群組；只有測試和生產環境才需要該群組。 或者，您可能可以使用相同的工作區管理員群組進行開發、測試和生產。 如需開發、測試和生產環境的詳細資訊，請參閱本文稍後的工作區生命週期管理。

有效使用工作區角色的群組可能需要相當多的規劃。 為遇到現有群組 (可能符合組織圖) 不符合管理 Fabric 內容的所有需求時的案例做好準備。 在此情況下，建議您特別為此目的建立群組。 這就是單字 Fabric 或 Power BI 包含在上述群組名稱範例中的原因。 如果您有多個商業智慧工具，您可以選擇改為只使用 BI 作為前置詞。 如此一來，您就可以跨多個工具使用相同的群組。

最後，這些範例會顯示一個工作區 - 每季財務 - 但通常可以使用一組群組來管理工作區集合。 例如，財務小組所擁有和管理的多個工作區可能會使用相同的群組。

注意

您通常會更廣泛地規劃安全性，並考慮語意模型讀取和建置權限需求，以及資料列層級安全性 (RLS) 需求。 如需支援報表取用者和內容建立者之考量事項的詳細資訊，請參閱安全性規劃文章。 基於本文的目的，焦點只會放在工作區規劃程序期間的工作區角色。

檢查清單 - 考慮工作區存取時，關鍵決策和動作包括：

  • 請參閱角色和責任：使用稍早準備的角色和責任資訊來規劃工作區角色。
  • 識別誰將擁有和管理內容：確認您預期儲存在單一工作區中的所有項目都符合負責擁有和管理內容的人員。 如果發生不相符的情況，請重新考慮如何更妥善地組織工作區。
  • 識別將在工作區中檢視內容的人員：判斷人員是否會直接從工作區檢視內容。
  • 規劃工作區角色：針對每個工作區決定哪些人員適合管理員、成員、參與者和檢視人員角色。
  • 決定群組或個別角色指派：決定您想要將個別使用者還是群組指派給工作區角色。 檢查是否有可用於工作區角色指派的現有群組。
  • 判斷是否需要建立新的群組：仔細考慮是否需要為每個工作區角色建立新的群組。 請記住，這可能會導致建立和維護許多群組。 判斷建立新工作區時的程序，以及建立相關群組的方式。
  • 設定及測試工作區角色指派：確認使用者具有建立、編輯和檢視內容時維持生產力所需的適當安全性設定。

工作區網域

如本文稍早所述，請務必清楚了解工作區擁有權。 在 Fabric 中進一步支援工作區擁有權的其中一種方式是使用網域。 網域是以邏輯方式將具有類似特性的多個工作區分組。

如需規劃租用戶中網域的詳細資訊，請參閱工作區網域。

工作區設定

您可以為每個個別工作區設定數個設定。 這些設定可能會大幅影響共同作業的發生方式、允許誰存取工作區，以及跨 Fabric 工作負載的資料重複使用層級。

工作區授權模式

每個工作區都有授權模式設定。 它可以設定為 Pro、Premium Per User、Premium 容量、內嵌、Fabric 容量或試用版。

重要

此文章有時會提及 Power BI Premium 或其容量訂用帳戶 (P SKU)。 請注意，Microsoft 目前正在整合購買選項，並按容量 SKU 淘汰 Power BI Premium。 新客戶和現有客戶應考慮改為購買 Fabric 容量訂用帳戶 (F SKU)。

如需詳細資訊，請參閱 Power BI Premium 授權的重要更新 (英文) 和 Power BI Premium 常見問題集 (部分機器翻譯)。

授權類型對於工作區規劃而言很重要，因為它會決定：

  • 功能：支援不同的功能。 PPU 包含更多無法在 Pro 中使用的功能 (例如部署管線)。 更多 Fabric 功能 (例如資料湖存放庫) 可供指派給 Fabric 容量的工作區使用。
  • 內容存取：授權類型決定誰可以存取工作區中的內容：
    • 只有擁有 PPU 授權的使用者 (除了獲指派工作區角色之外) 才能存取 PPU 工作區。
    • 如果您預期將內容傳遞給具有免費授權的內容檢視人員，您將需要 F64 或更高版本的授權。
  • 資料儲存位置：當您需要將資料儲存在特定地理區域 (位於您主區域外部) 時，該區域可能會有指派給容量的工作區 (因此，容量會在該區域中建立)。 如需資料儲存位置的詳細資訊，請參閱租用戶設定。

檢查清單 - 考慮工作區授權模式時，關鍵決策和動作包括：

  • 考慮每個工作區需要哪些功能：判斷每個工作區的功能需求。 請考慮工作負載中的差異，以及您想要存取工作區的使用者。
  • 設定工作區授權模式：根據每個工作區所需的功能，檢閱和更新每個工作區授權模式。

工作區生命週期管理

當內容建立者共同作業以提供對組織而言很重要的分析解決方案時，會有各種生命週期管理考量。 這些程序也稱為持續整合/持續傳遞 (CI/CD)，這是 DevOps 的一個層面。

數個生命週期管理考量包括：

  • 如何確保內容及時、可靠且一致地傳遞。
  • 如何在處理相同專案之多個內容建立者之間進行溝通和協調活動。
  • 當多個內容建立者編輯相同專案中的相同項目時，如何解決衝突。
  • 如何建構簡單且可靠的部署程序。
  • 如何將已部署的內容復原至先前穩定且可運作的版本。
  • 如何在保護生產內容的同時，平衡新功能和 BUG 修正的快速發行。

在 Fabric 中，生命週期管理有兩個主要元件。

  • 內容的版本控制：Git 整合可讓內容擁有者和建立者建立其工作的版本。 它可以與工作區中的 Web 型開發搭配使用，或在用戶端工具中開發時搭配使用，例如 Power BI Desktop。 版本控制 (也稱為原始檔控制) 是藉由使用與 Azure DevOps 中本機和遠端存放庫相關聯的分支追蹤專案的所有修訂來達成。 遠端存放庫中的分支會定期認可變更。 當內容建立者完成經測試和核准的修訂時，其分支會與主要遠端存放庫中最新版的解決方案合併 (解決任何合併衝突之後)。 您可以在 Fabric 入口網站中為每個工作區指定 Git 整合，前提是已在租用戶設定中啟用此功能。
  • 升級內容：部署管線主要著重於發行管理，以維護使用者的穩定環境。 您可以將工作區指派給部署管線中的階段 (開發、測試或生產環境)。 然後，您可以輕鬆地且有系統地將內容升階或部署至下一個階段。

結合生命週期管理功能時，規劃程序期間需要考慮最佳做法。 例如，您可以選擇將 Git 整合用於開發工作區和部署管線，以發佈至您的測試和生產工作區。 這些類型的決策需要一致地使用同意的做法。 建議您執行概念證明，以完整測試您的設定、程序和權限模型。

檢查清單 - 規劃工作區生命週期管理時，關鍵決策和動作包括：

  • 決定使用者應如何使用版本控制：分析自助和進階內容建立者的工作方式，以判斷使用商務用 OneDrive 或 SharePoint 的檔案版本設定是否適當。 為需要更多功能的進階使用者導入 Git 整合。 準備好支援這兩種類型的使用者。
  • 決定使用者如何升階內容：分析自助和進階內容建立者的工作方式，以判斷部署管線是否適合升階內容。
  • 決定是否應啟用 Git 整合：考慮 Git 與工作區的整合是否適合內容建立者的工作方式。 設定 [使用者可以將工作區項目與其 Git 存放庫同步] 租用戶設定，以配合此決策。 檢閱每個 Git 整合租用戶設定，並根據治理指導方針加以設定。
  • 執行概念證明：實施技術概念證明，以釐清您打算如何讓 Git 工作區和部署管線共同運作。
  • 決定哪些工作區應該有 Git 整合：考慮內容建立者的工作方式，以及哪些工作區應指派給開發、測試或生產 (發行) 分支。
  • 確認授權：確認您有容量授權可供使用 Git 整合。 確定每個工作區都指派給 Fabric 容量或 Power BI Premium 容量。
  • 設定 Azure DevOps：與您的系統管理員合作，設定您針對每個工作區所需的 Azure DevOps 專案、存放庫和分支。 為每個存放庫指派適當的存取權。
  • 連線工作區：將每個工作區連線到適當的 Azure DevOps 存放庫。
  • 考慮應該部署至生產環境的人員：決定應該能夠更新生產內容的人員及其方式。 請確定這些決策與組織中處理工作區擁有權的方式一致。
  • 教育內容建立者：確定您的所有內容建立者都了解何時使用生命週期管理功能和做法。 讓他們了解工作流程，以及不同工作區如何影響生命週期管理程序。

工作區與 ADLS Gen2 整合

您可以將工作區連線到 Azure Data Lake Storage Gen2 (ADLS Gen2) 帳戶。 這麼做可能會有兩個原因：

  • Power BI 資料流程資料的儲存體：如果您選擇攜帶您自己的資料湖，則可以直接在 Azure 中存取 Power BI 資料流程 (Gen1) 的資料。 當您想要讓其他使用者或程序檢視或存取資料時，直接存取 ADLS Gen2 中的資料流程儲存體會很有幫助。 當您的目標是重複使用 Power BI 以外的資料流程資料時，這特別有用。 指派儲存體有兩個選項：
    • 租用戶層級儲存體，這在想要將 Power BI 資料流程的所有資料集中到一個 ADLS Gen2 帳戶時很有用。
    • 工作區層級儲存體，當營業單位管理自己的資料湖或具有特定資料落地需求時，這會很有幫助。
  • Power BI 語意模型的備份和還原：針對指派給容量或 PPU 的工作區，支援 Power BI 語意模型備份和還原功能。 這項功能會使用用來儲存 Power BI 資料流程資料的相同 ADLS Gen2 帳戶 (如上一個項目符號點所述)。 語意模型備份有助於：
    • 符合資料保留需求
    • 將例行備份儲存為災害復原策略的一部分
    • 將備份儲存在另一個區域中
    • 移轉資料模型

重要

在 Fabric 管理入口網站中設定 Azure 連線並不表示整個租用戶的所有資料流程預設都會儲存至 ADLS Gen2 帳戶。 若要使用明確的儲存體帳戶 (而不是內部儲存體)，每個工作區都必須明確連線。 在工作區中建立任何 Power BI 資料流程之前，請務必先設定工作區 Azure 連線。

檢查清單 - 考慮工作區與 ADLS Gen2 整合時，關鍵決策和動作包括：

  • 決定工作區是否會以需要 Azure 儲存體的方式使用：考慮攜帶自己的資料湖案例是否適合用於資料流程的儲存體和/或您是否需要使用語意模型備份和還原功能。
  • 判斷將使用哪一個 Azure 儲存體帳戶：針對資料流程資料或語意模型備份的租用戶層級 (集中式) 儲存體，選取已啟用階層命名空間的 Azure 儲存器帳戶 (ADLS Gen2)。 請確定您隨時可以提供 Azure 儲存體帳戶資訊。
  • 設定租用戶層級儲存體帳戶：在 Fabric 管理入口網站中，設定租用戶層級 ADLS Gen2 儲存體帳戶。
  • 決定工作區系統管理員是否可以連線儲存體帳戶：討論以了解分散式小組的需求，以及個別小組目前是否維護自己的 Azure 儲存體帳戶。 決定是否應啟用這項功能。
  • 設定工作區層級儲存體的管理員設定：在 Fabric 管理入口網站中，啟用可讓工作區系統管理員連線自己的儲存體帳戶的選項。
  • 設定工作區層級的 Azure 儲存體連線：為每個個別工作區指定 Azure 儲存體帳戶。 您必須先設定儲存體帳戶，才能在工作區中建立任何 Power BI 資料流程。 如果您想要使用語意模型備份，請確定工作區授權模式已設定為容量或 PPU。
  • 更新工作區管理文件：確定您的工作區管理文件包含如何正確指派 ADLS Gen2 儲存體帳戶的相關資訊。 在您的集中式入口網站和訓練教材中提供資訊。

工作區與 Azure Log Analytics 整合

Azure Log Analytics 是 Azure 監視器內的服務。 您可以使用 Azure Log Analytics 來檢閱裝載 Power BI 語意模型之 Analysis Services 引擎所產生的診斷資料。 工作區層級記錄可用於分析效能和趨勢、執行資料重新整理分析、分析 XMLA 端點作業等等。 Azure Log Analytics 僅適用於指派給容量或 PPU 的工作區。

注意

雖然名稱類似，但傳送至 Azure Log Analytics 的資料與 Power BI 活動記錄所擷取的資料不同。 傳送至 Azure Log Analytics 的資料與 Analysis Services 引擎所產生的事件有關 (例如查詢開始和查詢結束事件)。 相反地，活動記錄與追蹤使用者活動有關 (例如，檢視報表或編輯報表事件)。

如需語意模型事件記錄的詳細資訊，請參閱資料層級稽核。

如需如何設定 Azure Log Analytics 以搭配 Power BI 使用的詳細資訊，請參閱設定適用於 Power BI 的 Azure Log Analytics。 請務必了解您必須具備才能讓整合運作的必要條件。

檢查清單 - 考慮與 Azure Log Analytics 的工作區整合時，關鍵決策和動作包括：

  • 決定工作區系統管理員是否可以連線到 Log Analytics：決定是否允許所有或部分工作區系統管理員使用 Azure Log Analytics 來分析工作區層級記錄。 如果存取權僅限於特定人員，請決定要使用的群組。
  • 設定 Log Analytics 連線的租用戶設定：在 Fabric 管理入口網站中，根據工作區系統管理員設定連線的決定來設定租用戶設定。
  • 設定每個工作區的 Log Analytics工作區：在工作區設定中，為每個工作區指定 Azure Log Analytics 資訊。 若要擷取工作區層級記錄，請確定工作區授權模式設定為容量或 PPU。
  • 更新工作區管理文件：確定工作區管理文件包含如何將工作區指派給 Azure Log Analytics 的相關資訊。

其他工作區屬性

有數個其他工作區屬性可以提供有用的資訊。 針對受控工作區，建議您設定這些屬性。

以下是如何設定這些關鍵設定以改善使用者體驗的一些建議。

  • 工作區描述：良好的工作區描述包含工作區中可找到內容類型的簡短但具體說明。 您最多可以使用 4,000 個字元來描述：
    • 工作區的用途
    • 目標對象
    • 發佈至工作區的內容類型
    • 工作區是否被視為受控管
    • 工作區是否包含開發、測試或生產資料
    • 有任何問題時應該連絡的對象 (除了接下來描述的連絡人清單之外，盡可能突顯此資訊偶爾非常重要)
  • 工作區連絡人：工作區連絡人清單預設包含工作區系統管理員。 如果您有與主題專家不同的技術內容擁有者，則可能會發現指定其他連絡人會很有幫助。 其他連絡人可以是可以回答工作區內容相關問題的群組或個人。
  • 工作區影像：掃描工作區清單時，工作區影像的一致使用對使用者很有幫助。 請考慮使用影像來協助使用者進行判斷：
    • 網域或主體區域
    • 哪個營業單位或小組擁有和管理內容
    • 無論是資料工作區 (專門用來儲存可重複使用的項目，例如資料湖存放庫、倉儲、資料管線、資料流程或語意模型)
    • 還是報告工作區 (專門用來儲存分析項目，例如報表、儀表板或計量)
  • 資料模型設定：允許具有語意模型「建置」權限的工作區成員、系統管理員和使用者，使用 Web 介面來編輯 Power BI 資料模型。 此設定會與 [使用者可以在 Power BI 服務中編輯資料模型] 租用戶設定一起使用。 此設定應該與您如何建立、管理及部署內容的決策和程序一致。 此外，請考慮您的版本控制方法，如本文稍早所述。

檢查清單 - 考慮其他工作區屬性時，關鍵決策和動作包括：

  • 指定工作區描述：確定工作區描述中包含實用且完整的描述。
  • 使用工作區的實用影像：為工作區設定一致的影像，以視覺化方式協助使用者了解其主題區域、擁有和管理工作區中內容的人員和/或儲存在工作區中的內容類型。
  • 識別工作區的連絡人：確認工作區系統管理員是否應為工作區連絡人，或是否應指定特定使用者或群組。
  • 指定資料模型設定：考慮哪些工作區可以允許 Web 型資料模型編輯。 根據誰可以編輯和管理內容的喜好設定，設定 [使用者可以在 Power BI 服務中編輯資料模型] 租用戶設定。

其他技術因素

還有其他技術因素可能會影響工作區設定。

  • 如果您整合內容與其他工具和服務，則可能會有授權含意。 例如，如果您在 Power BI 報表中內嵌 Power Apps 視覺效果，則將需要適當的 Power Apps 授權。
  • 每個工作區的儲存體限制適用於您可以在 Pro 工作區中儲存的資料量。 如果使用容量或 PPU 不是選項，請考慮如何在工作區規劃程序期間在儲存體限制內工作。
  • 當您從 AppSource 安裝範本應用程式時，它會建立新的工作區，而其主體和範圍將會很窄。

檢查清單 - 考慮其他技術因素時，關鍵決策和動作包括：

  • 注意技術因素：當您完成規劃程序時，請判斷是否有技術原因 (例如每個工作區的儲存體限制) 可能會影響決策程序。
  • 重新組織工作區內容：如果儲存體限制可能會成為問題，請立即建立個別工作區，並將內容重新發佈至這些新工作區。

相關內容

如需更多考量、動作、決策準則和建議，以協助您進行 Power BI 實作決策，請參閱 Power BI 實作規劃。