PowerBI 大型報表架構設計 – 30頁100個度量值1000個對象

  • 2019 年 10 月 6 日
  • 筆記

PowerBI 雖然從某種意義上說只是一個製作報表的工具，但在製作報表的過程中，從簡單的報表，到極為複雜的報表都有可能。

企業級報表是要完全滿足用戶需求的，這和簡單的可視化完全不同，在有些情況，甚至大部分情況，一切科學的可視化理論是失效的，客戶就是上帝。

如果客戶只能理解線圖，你憑什麼告訴客戶自定義圖表更好。這才是真實的企業環境。

這裡簡單探討一下企業級報表項目解決方案的架構設計。

導航系統

很可惜，目前 PowerBI 對支援複雜企業結構報表並不理想，針對如下問題：

  • 可視化對象需要囊括大量資訊
  • 眾多報表主題及子主題
  • 眾多靈活的需求
  • 一致的可維護的報表

PowerBI 目前很難應付，但就導航系統，就會因為無法復用而存在大量手工勞動，經過實踐總結，要完成上述任務並設計出多級導航系統的一個可行方案如下：

這裡面蘊含大量細節上的學問，這是目前幾乎已知相對工作量最小的做法。

  • 橫嚮導航系統滿足了長標題的報表名稱
  • 統一導航系統
  • 二級導航系統應對大型複雜報表結構
  • 純 PowerBI 原生元素打造
  • 精確到像素級別控制

這裡可以延展一些問題讓大家思考，為了設計高度精細的布局，你知道這些問題的答案嗎：

  • 在PBI布局網格中，每兩個小點之間的距離是多大？（如：x像素）
  • 在PBI布局網格中，任意元素的最小高度（寬度）是多大？（如：x像素）
  • 在PBI布局網格中，如果要製作一個背景標題，應該選擇什麼元素？（如：圖形，文本框）
  • 在PBI布局網格中，如果要製作一個圓角矩形，應該選擇什麼元素？圓角弧度大小應該為多大？
  • 在PBI布局網格中，如果要製作一個水平導航條，其高度應該如何設計最佳？
  • 在PBI布局網格中，如果要製作一個導航按鈕，如何設計使得性價比最佳？

如果您思考過以上問題，歡迎留言，以上問題均有標準答案。關於導航系統的製作，PBI在2018年更新過多次特性全部綜合起來，終於可以製作成一個合理的導航系統，但由於無法重用，導致製作效率是低下的，關於這個話題，可以詳盡地說明很多，將開專門主題再做探討。

大家可以參考此圖，自行實踐。

數據準備

由於 PowerQuery 提供了分組功能，在數據準備上相對可以劃分成更合理的結構。至於為何有這些分組及用意，相信很多夥伴也有自己的劃分方式。

在 PowerBI 中，可以使用Ctrl+C, Ctrl+V的方式將PQ邏輯複製粘貼進新的PBI文件，這個功能使得數據準備的邏輯可以復用，是非常重要的。

業務模型數據

由於我們的重點是分析業務，所以業務模型數據是重點，為了構建業務模型，採用經典的ETL劃分方式：

  • 數據源配置，並獲取數據
  • 對獲取到的數據進行處理
  • 要載入的數據應滿足事先定義好的結構

報表模型數據

幾乎沒有PowerBI的報表是僅僅依賴業務數據構建的，為了構建報表，還需要一些輔助的數據，稱為：報表模型數據，如：年齡分組，參數表等。

業務指標

業務指標的宿主表定義。在PBI中可以通過計算表或輸入表兩種方法實現，推薦使用輸入表法。

MVC

MVC，一詞來自軟體工程中前端設計模式。該方法論也適用於PowerBI報表設計：

  • View，即可視化對象圖表。
  • Model，準確講是 ViewModel ，是為了繪製某可視化圖表而依賴的數據結果。
  • Controler，由用戶操作而產生的上下文環境與度量值共同擔任。

Excel120 首次提出將軟體工程設計模式的經典MVC模式引進PowerBI系統設計，這是一套成熟的方法論，用於解除圖表，數據，業務邏輯之間的耦合，進而設計出可以高度復用，靈活擴展的結構。

此話題也將開設專題進行深入探討。

許可權控制

PowerBI 中全動態許可權控制可通過RLS或更加靈活的機制實現，已經單開話題討論。參考：PowerBI 企業級許可權控制全動態終極解決方案。

模型維護

模型維護，是PowerBI報表設計的重點。

模型維護中，常見的問題包括：

  • 哪個自定義圖表沒用過，可以刪除，不知道。
  • 哪個列沒用過，可以刪除，不知道。
  • 哪個度量值沒用過，可以刪除，不知道。
  • 哪個度量值被哪個圖表用著，不知道。
  • 想改一個度量值，由於不知道被誰用，不敢改。

於是，能做的事只有一件，就是：只增加不敢刪除。

這將有可能導致一個項目變得非常非常複雜。很可惜，目前 PowerBI 都沒有給出官方的維護方法，這點使得 PowerBI 製作大型複雜報表非常力不從心。

這裡推薦一個網站：app.datavizioner.com 目前該第三方網站可以大致幫助我們解決一部分問題。

可以通過上傳PowreBI導出的模板文件 .PBIT（必須小於2M），在該網站得到對PowerBI文件結構的解析。

報告分析

可以看出對於本報告：

  • 使用了 35 個頁面
  • 使用了 942 個可視化對象
  • 使用了 17 種可視化對象
  • 包括 26 張表
  • 有 117 個度量值
  • 實際使用了 19 列

這個報表所使用元素的規模（35頁，942個可視化對象）很難純人工維護。 在目前 PowerBI 沒用給出官方高效維護方法的現狀下，必須靠非常有效的人工管理，這就需要我們預先思考清楚如何管理以下元素：

  • 業務基表
  • 輔助基表
  • 計算列
  • 度量值
  • 業務計算表
  • 輔助計算表
  • 關係
  • 按列排序
  • 可視化元素，用於圖表，如：條形圖等。
  • 可視化元素，用於裝飾，如：導航，LOGO，按鈕等。
  • 命名規則
  • 注釋規則

可以考慮以下原則以簡化設計：

  • 遵循非侵入式設計原則（Excel120提出），保持度量值優先。
  • 盡量保持單向一對多關係。
  • 區分業務基表與輔助表。
  • 區分業務度量值與功能度量值。
  • 建立可復用的度量值依賴體系結構。
  • 區分度量值宿主表（Measure Host Table，非官方名稱）。
  • 建立指標命名規則。

大家可以進一步研究補充必要的管理規則。

M 腳本維護

該工具還提供了導出全部 M 腳本

當然，PowerBI 本身也提供了 M 導出的功能。這倒不是大問題。

模型分析

該工具提供了對模型分析的方法：

於是可以大致知道模型的規模以及可以增刪的冗餘成分：

可以看出，在上圖呈現的結構中，藍色表示使用的表；橙色表示未在可視化中直接使用的表，則可知：

  • PBI模型真實的結構既不是星型模型也不是雪花模型，而是：星系模型（Excel120提出）。
  • 星系模型：
  • 包含多個星型，一般取決於事實表的個數，形成多事實表結構。
  • 包含多個孤立星，也就是孤立表，它們通常起到容器，分組，參數，輔助可視化等作用。

因此，我們需要實際維護的是一個複雜的 星系模型。

維護中可以做的事情包括：

  • 明確模型中各種表的作用，有的表中含有業務數據；而有的表則不然，用於其他方面。
  • 隱藏未在可視化中直接使用的表或列。
  • 清理未在可視化中使用過的度量值。
  • 隱藏未在可視化中直接使用的度量值。

大家可以嘗試使用該工具來維護分析自己的模型。

總結

本文將大型複雜PowerBI報表設計結構做了概要式的分析，分為三大方面：

  • 數據準備結構設計：業務數據，輔助數據，指標宿主表，MVC，許可權控制。
  • 數據模型結構設計：基表，度量值，計算列，計算表，輔助表，關係，命名規則。
  • 報表可視化結構設計：導航，布局，MVC。（這裡並非研究如何作圖，而是研究作圖的可復用結構規律）

很顯然，純ETL理論，星型模式，可視化方法都並不真正適合PowerBI，您在大量工作中是否也感覺到了這個問題。在這方面，PowerBI是否給了我們一次可以基於PowerBI去重新思考如何設計結構的機會。PowerBI目前並沒有給出官方的最佳實踐，而且也不直接支援這些複雜問題的處理，耐心等待更新吧。另外，未來我們將更詳盡的探討在PBI現狀下，上述所有內容的細化方法。

VirMach 便宜 VPS

QNews

QNews