DAX Studio 中數據緩存的物化想法

本教程將討論 DAX Studio 中數據緩存的物化。這篇文章將展示它如何影響您的計算，同時使用您的查詢生成結果。您將了解哪種具體化更好，以最大限度地提高 DAX 的性能。

物化有兩種思路：Early Materialization和Late Materialization。

目錄

• 早期物化
• 延遲實現
• 在每個具體化查詢中
• 結論

早期物化

早期物化是指物化行數大於輸出所需的行數。

如果您的輸出是一個日曆年的表，並且您有五年的數據，那麼就沒有必要帶很多具體化的行。最佳實踐是使物化行數等於所需行數。但是，情況並非總是如此，因為它取決於DAX和數據設置的複雜性。

永遠記住數據由列組成。因此，當公式引擎需要在表上工作時，列以表格式重新組合在一起，這就是物化。在 Early Materialization 的想法中，存儲引擎將數據緩存發送到公式引擎。然後公式引擎在該緩存上工作並執行複雜的過程。

早期具體化可能是由於數據模型中的複雜連接或多對多關係引起的。它也可能是由複雜的過濾器或迭代器引起的。

採取複雜措施並沒有錯；您只需正確設置它們以盡可能多地利用存儲引擎。

延遲實現

延遲具體化是指具體化的行數等於或接近輸出所需的行數。

存儲引擎幾乎完成了所有的工作，沒有給公式引擎留下任何東西。這使得整個計算更快。

這些是早期和晚期實現的示例查詢：

在運行這些查詢之前，請確保清除緩存。這將使您的查詢針對冷緩存運行。如果您在不清除緩存的情況下運行 DAX，您將得到以下結果：

總執行時間只有 1861 毫秒，因為它已經使用了緩存。因此，在運行查詢之前，請始終清除緩存。

如果您運行 Early Materialization 查詢，您可以看到它花費的總時間是 9485 毫秒。它生成了一個數據緩存和一行輸出，但返回了 2500 萬行。

您不需要具體化 2500 萬行來獲得單行結果，因為這需要時間並會降低 DAX 的性能。

如果運行 Late Materialization 查詢，您可以看到整個計算只用了 1340 毫秒。它還生成了 2 個數據緩存，每個緩存返回 5003 行。

如果您查看物理查詢計劃，您可以看到 5000 行。它們的行數不相等。Server Timings 的結果有時會與 Query Plan 中準確的行數有一點出入。

因此，從處理一個具有 2500 萬行的數據緩存，您現在有兩個具有 5003 行的數據緩存。這就是使用 Later Materialization 比 Early Materialization 獲得更快結果的原因。

在每個具體化查詢中

通過查看查詢，您已經可以看到 Later Materialization 更快。Early Materialization 查詢計算匯總表的行數。

匯總和具體化的表比僅在表上執行的更大，這是延遲具體化查詢正在做的事情。

如果您的查詢速度很慢，請首先查看查詢中提取了多少行以及輸出需要多少行。您還可以轉到邏輯查詢計劃並遵循計算中發生的工作流程。

LuckyTemplates Desktop DAX 教程中的 DAX Studio 是什麼： LuckyTemplates 中的
上下文和計算引擎度量：優化技巧和技術

結論

當您的查詢從數據模型中提取列或行時，就會發生具體化。當您的引擎從您的數據模型獲取數據以便為您的查詢提供結果時，此過程自然發生。

但是，如果您的 DAX 提取的行數超過結果所需的行數，則可能會出現問題。這個問題可以通過簡化 DAX 來執行特定流程來解決。