LuckyTemplates 中的度量：優化技巧和技術

在本教程中，您將學習如何在 LuckyTemplates 中優化度量。優化報告中的度量可以提高代碼在生成有價值的見解和數據方面的性能。您還將了解不同的評估方法以及如何應用它們來優化您的報告。您可以在本博客底部觀看本教程的完整視頻。

目錄

• 1.分析代碼的性能
  • 測量中的變量
  • DAX Studio 的冷緩存
• 2. 在 LuckyTemplates 中分析一個度量
  • LuckyTemplates 中的 RB 激勵百分比度量
    • 來自存儲引擎的數據
  • IF 和 Switch 背後的邏輯
• 3.使用代碼評估方法
  • 第一種方法：嚴格評估
  • 第二種方法：渴望評估
    • 急切評估的缺點
  • 第三種方法：IF.EAGER 評估
  • 評估方法總結
• 4. 優化 LuckyTemplates 中的度量
  • LuckyTemplates 中度量的高級優化
    • 刪除回調數據
• 5.優化LuckyTemplates中的其他措施
• 結論

1.分析代碼的性能

在本例中，您需要優化此報表：

這是您將要使用的數據模型：

作業表包含有關在給定時間段內執行的任何作業的所有信息。

該表是您要優化的所有措施的基礎：

首先，您需要測試報表的性能。

轉到View 選項卡並選擇Performance Analyzer。然後，單擊Start Recording and Refresh Visuals。等待分析器呈現視覺效果。

完成此操作後，下拉激勵細分列表並單擊複製查詢。

接下來，選擇“外部工具”以轉到 DAX Studio 並查看 LuckyTemplates 生成的代碼。

然後，將復制的查詢粘貼到工作區中。

測量中的變量

第一個變量是DateClosed，它是儀表板上的切片器。它使用事實表中的一列來獲取切片器中特定時間段的值。

下一個變量是JobLost，它檢查 Job Lost 數據的 False 或 Blank。

最後一個變量是MatrixVisual。這是代碼的核心。它顯示 LuckyTemplates 生成的用於填充矩陣視覺對象的匯總列。它在此矩陣中對作業丟失類型進行分組，並註入來自切片器的過濾器。然後，它添加擴展列。

匯總列完成執行後，您將在代碼下方的窗格中看到結果。

LuckyTemplates 使用結果來填充矩陣視覺對象。

DAX Studio 的冷緩存

接下來，您需要檢查執行整個代碼所花費的時間。為此，請打開 Server Timings，然後選擇Clear Cache Then Run。

當您嘗試使用DAX Studio優化 LuckyTemplates 中的度量時，最好在冷緩存場景下操作，以便您獲得的時間是正確的。之後，在Server Timings 選項卡中按 F5 等待操作完成。

完成後，您可以看到總執行時間為 3.6 秒。大部分時間花在公式引擎上，花在存儲引擎上57毫秒

您還可以看到它找到了 383 個存儲引擎查詢。在所有這些查詢中，有 327 個被轉換到內存中以便它們可以被重用。

2. 在 LuckyTemplates 中分析一個度量

接下來，您需要優化這 3 個相同的措施。

您必須將這些度量值提取到不同的文件中，並將其連接到您正在使用的數據模型。

之後，啟動 Server Timings 以查看 3 種措施在填充視覺效果時所花費的時間。

運行結果顯示，這些度量耗時 1.85 秒來檢索結果。

結果顯示一個包含 10 行和 3 個擴展列的表格，這些列屬於匯總列。

Loss Type 列包含 10 個唯一值，代碼計算這些值以獲得激勵百分比。

代碼花費的時間呈指數增長。這是您需要優化它們的時間和地點。

LuckyTemplates 中的 RB 激勵百分比度量

這是 LuckyTemplates 中的 RB 激勵百分比度量。這是本示例中使用的 3 個主要度量之一。

您可以看到它正在嘗試計算激勵百分比。

它有一個變量 JobType，它在當前過濾器上下文中檢索丟失的類型值。它還會檢查當前過濾器上下文中是否只有一個值可見。您需要使用一個  函數，以便每次滿足條件時，它都會給出相應的結果。

此度量代碼會生成大量存儲引擎油脂，從而增加代碼總持續時間的時間。

現在，返回 DAX Studio 檢查度量生成的存儲引擎查詢量。

您可以看到執行 600 毫秒和 43 個存儲引擎查詢來簡單地檢索 10 行的數據。

來自存儲引擎的數據

現在，檢查從存儲引擎請求的數據。在第一個查詢中，有 Jobs Loss Type 和 Jobs Loss Type 的DCOUNT 。

下一個查詢具有來自報告中的切片器的 Jobs Date Closed。

在第三個代碼中，您將看到另一個具有回調數據 ID 的 Jobs Loss Type。

在另一行中，您將看到最重要的代碼行。

您首先看到的是已收到的工作付款、開具發票和實際費用的

接下來是 聲明條件及其相應結果的WHERE函數。結果將根據切片器選擇和 RB Incentive% 度量中的 switch 語句而有所不同。

您還會注意到第 12 行和第 14 行的代碼是相同的。

如果向右滾動，您可以看到有相同查詢的行。行上的查詢由 RB Incentive% 度量中的 switch 語句引導。

如果返回 LuckyTemplates 中的 RB Incentive% 度量值，您可以看到重複查詢的次數以及它如何反映在存儲引擎查詢中。

IF 和 Switch 背後的邏輯

 和SWITCH函數的邏輯。

您需要在查詢計劃中單獨執行它們。但在此之前，請確保連接到數據庫並打開查詢計劃。

執行 查詢計劃中的SWITCH語句。然後，突出顯示該 語句，然後按 Enter 鍵。

這將生成具有不同操作的邏輯查詢計劃。

接下來，通過突出顯示語句並按回車鍵來執行IF語句。

您可以看到它生成了相同的邏輯查詢計劃。

這是因為無論何時使用SWITCH 函數，引擎都會在內部將該函數轉換為IF語句。但建議使用SWITCH語句，因為它可以提高代碼的可讀性。

之後，您需要了解代碼在IF或SWITCH函數中是如何執行的。

這是一個示例代碼，其中包含一個SWITCH語句。

它具有毛利、總估算和總發票的度量值，它們都是不同列的總和。它還具有一個 函數，用於處理Jobs Loss Type 的 以及一個SWITCH和TRUE語句。

當您執行這段代碼時，您會看到函數背後的邏輯。

第一個查詢從 Jobs 表中獲取不同的 Jobs Loss Type。

除了 Jobs Loss Type 之外，它還獲得 Jobs Estimate 的總和。

在WHERE條件內，您還可以看到 Jobs Loss Type 列中存在的值。

3.使用代碼評估方法

在 DAX 中，有 3 種評估代碼的方法：

• 嚴格評估
• 急切的評估
• IF.熱切評估

這些方法將幫助您優化 LuckyTemplates 中的代碼或度量。

第一種方法：嚴格評估

下面顯示的示例使用嚴格評估方法。

其背後的邏輯是，如果 Jobs Loss Type 的上下文等於 A，它將提供 Gross Profit。否則，它會給出總估計值。代碼對 Jobs Loss Type 中的每一行執行此操作。

這是 LuckyTemplates 中使用嚴格評估的另一個示例度量。

當你執行這段代碼時，它會生成 5 個存儲引擎查詢。

使用嚴格評估時，如果毛利乘以 1.4 大於平均估計值，代碼將提供總估計值。否則，它將給出毛利。

使用 Strict Evaluation 會產生更多的存儲引擎查詢，因為IF 語句會多次檢查 Gross Profit 的競爭，最終會阻礙整個操作的性能。

第二種方法：渴望評估

這是與前面示例相同的代碼。

但是，它不是在IF語句中計算度量 ，而是在RETURN之前計算 中的所有內容。

這意味著在檢查報表之前，它會獲取所有 Job Loss Type 的 Gross Profit 和 Total Estimate 的所有值。

當您執行這段代碼時，存儲引擎的數量會減少到 3 個。

它提高了整個操作的性能。

在第一個操作查詢中，它獲取 Jobs Loss Type 以及 Jobs Estimate 和 Gross Profit 的總和。

下一個查詢從 Jobs Stable 獲取 Jobs Estimate 的總和。這用於計算平均估計值。

最後一個查詢為寫在ADDCOLUMNS上的值提供了不同的 Jobs Loss Type 。

使用 Eager Evaluation 將所有內容都放在一個數據緩存中。數據也在公式引擎上進行評估和迭代。IF語句將根據 True 或 False 評估返回 Total Estimate 或 Gross Profit 。 

Eager Evaluation 並不總是優化代碼的最佳方法。如果您有復雜的代碼，嚴格評估將帶來更好的性能。這完全取決於您在 DAX 代碼中使用的函數。

Eager Evaluation 的缺點是，如果您在IF 或 SWITCH 語句之前創建有價值的值，並在永遠不應執行的語句中使用這些變量，引擎仍會計算這些變量。

急切評估的缺點

這是缺點的示例：

理想情況下，如果 Jobs Loss Type 等於 A，它應該獲得 Gross Profit。否則，它得到總估計。

由於 Job Loss Type 列中沒有等於 A 的值，因此它應該始終獲得 Total Estimate。但是，它仍然提供數據緩存中的毛利。

如果您查看第一個查詢，它會獲取 Jobs Loss Type 以及 Jobs Gross Profit 和 Estimate 的總和。

在下一個查詢中，它從 Jobs 表中獲取不同的 Jobs Loss Type。

第三種方法：IF.EAGER 評估

下一個方法是 IF.EAGER 函數求值，它複製了 Eager Evaluation 的行為。

它允許您編寫代表嚴格評估的代碼並使用 Eager Evaluation 執行它。

如果您查看此示例代碼，它與嚴格評估代碼一樣。唯一的區別是它使用IF.EAGER 函數而不是IF。

在執行代碼之前，請確保連接到 LuckyTemplates 模型並打開服務器計時。完成後，按 F5。

您可以看到它生成了 3 個存儲引擎查詢。

第一個查詢獲取 Jobs Loss Type 以及 Jobs Estimate 和 Gross Profit 的總和。

第二個查詢獲取工作估計的總和。

最後一個查詢從 Jobs 表中獲取不同的 Jobs Loss Type。

您會注意到它執行了與 Eager Evaluation 相同的行為。

評估方法總結

在嘗試使計算性能更好時，您必須記住以下幾點：

• 嚴格評估用於復雜代碼。當您不想評估表提供的所有值時，它也適用。
• 如果您的代碼很簡單，則更適合使用 Eager Evaluation。
• 如果您想使用 Strict Evaluation 編寫代碼並使用 Eager Evaluation 執行代碼，請使用 IF.EAGER。

但請注意，您必須測試這三種方法才能找出最適合在您的報告中使用的方法。

4. 優化 LuckyTemplates 中的度量

本教程的主要課程是優化您的代碼。

返回並查看使用嚴格評估執行的RB Incentive%度量。接下來，嘗試使用 Eager Evaluation 對其進行評估。

首先創建變量並輸入 RETURN函數。

使用變量更改度量參考。

之後，確認測量並轉到 DAX Studio 看看它是否提高了性能。

它顯示總時間為 642 毫秒，存儲引擎查詢總數已減少到 39。

現在，為所有數據創建變量並將所有度量引用更改為其相應的變量。

接下來，確認度量並在 DAX 工作室中執行代碼。

總執行時間和存儲引擎查詢總量分別從 600 毫秒減少到 170 毫秒，從 43 個查詢減少到 15 個查詢。

您還可以看到沒有重複項。在代碼中使用變量可以提高代碼的可讀性和性能。

LuckyTemplates 中度量的高級優化

接下來，您需要進一步優化您的 DAX 代碼。

不要使用，而是使用 函數。

HASONEVALUE 計算過濾器上下文中可用值的數量，這是一個非常密集的操作。同時，ISINSCOPE檢查提供的列是否用於分組。

更改功能後，確認測量並在 DAX Studio 中執行。

可以看到現在存儲引擎的查詢次數是12次，總的執行時間也變成了105毫秒。

在第二個查詢中，您會注意到一個回調數據 ID。

當您對文本字段使用 SELECTEDVALUE 時，有時會發生這種情況。當你看到Callback數據時，存儲引擎調用公式引擎來幫助解決代碼的複雜性。這會降低測量的性能。

刪除回調數據

您需要刪除回調數據才能在報告中獲得更好的性能。為此，您需要在數據模型中創建一個配置表。

轉到“輸入數據”選項並粘貼數據。將表命名為LossTypeConfigTable。

接下來，單擊編輯以更改您要導入的列的數據類型。

損失類型 ID 的數據類型應該是教師值，以便可以在SELECTEDVALUE函數中使用。

將其加載到模型中後，根據損失類型在 Jobs 表和 LossTypeConfigTable 表之間創建關係。

創建關係後，轉到 Jobs 表並添加一個新列。將其命名為 Loss ID，然後輸入公式。

對配置表使用 函數，然後提取 Loss Type ID。

接下來，返回到 RB Incentive% 度量並引用數字字段而不是文本字段。在SELECTEDVALUE中，將 Loss Type 替換為 Loss ID。

接下來，修改代碼中的所有措施。在檢查作業類型時使用整數值而不是文本值。

更改代碼後，確認度量並在 DAX Studio 中執行它。

查詢中取消了回調數據 ID，代碼的執行時間減少到 93 毫秒。

RB Incentive% 措施現已完全優化。

5.優化LuckyTemplates中的其他措施

您還需要優化 WR Incentive% 和 QB Incentive% 措施。

複製並粘貼 RB Incentive% 度量中使用的確切代碼。然後，一起運行 3 個措施。

總執行時間經過優化，從 1855 毫秒減少到 213 毫秒。也只有 12 個存儲引擎查詢。

前兩個查詢創建篩選器上下文，其餘查詢表示 Jobs Loss Type 列中值的確切數量。

由於所有措施都已優化，運行原始代碼並查看性能如何變化。數據顯示它現在的計算時間為 1.9 秒。

現在優化了整個代碼的性能，使您的報告更快更好。

通過這門新課程優化 DAX 函數
簡單的 LuckyTemplates 轉換以獲得更優化的數據
使用高級 DAX 優化 LuckyTemplates 公式

結論

在 LuckyTemplates 報表中，應優化措施以確保您的 DAX 代碼順利運行。這也提高了報告的整體性能。

您已經了解了在 LuckyTemplates 中優化度量的不同方法，並且您已經了解瞭如何根據報告的上下文評估使用哪一種方法。