表格式模型中的資料分割
適用于:SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium
分割區可將需要經常處理 (重新整理) 的資料與不常處理的資料區分開來。 例如,事實資料表可能包含包含很少變更資料的特定資料列集,但其他資料列集通常會有變更的資料。 只需要處理部分的資料時,就不需要處理 所有資料 。
分割區的運作方式是將資料表分割成邏輯分割區物件。 個別的分割區各自擁有不相重複的資料區段,然後能以循序或平行的增量處理其他分割區,或完全排除在處理作業之外。
細微度
根據預設,模型中的每個資料表都有單一資料分割。 在許多情況下,例如事實資料表,將資料表的單一分割區分割成多個分割區,可以更有效地利用可用的資源進行處理。
有效的模型設計和處理策略會利用分割區來消除不必要的處理器負載和記憶體耗用量,同時確保重新整理資料的頻率足以反映資料來源的最新資料。 例如,表格式模型可以有 Sales 資料表,其中包含目前會計年度和前一個會計年度的銷售資料。 模型的 Sales 資料表具有下列資料分割:
分割區 | 來源資料 |
---|---|
Sales2020 | 目前會計年度 |
Sales2019-2010 | 會計年度 2010、2011、2012、2013、2014、2015。 2016, 2017, 2018, 2019 |
SalesOld | 在過去十年之前的所有會計年度。 |
當目前 2020 會計年度新增新的銷售資料時,必須每天處理該資料,才能在目前的會計年度銷售資料分析中正確反映,因此會每天處理 Sales2020 資料分割。
不需要在 Sales2019-2010 分割區中處理資料。 不過,由於前十個會計年度的銷售資料仍可能會因為產品傳回和其他調整而變更,因此仍必須定期處理,因此會每月處理 Sales2019-2010 資料分割中的資料。 SalesOld 資料分割中的資料很少變更,因此只會每年處理一次。
輸入 2021 會計年度時,新的 Sales2021 資料分割會新增至模型的 Sales 資料表。 然後,Sales2020 分割區可以與 Sales2019-2010 分割區合併,並重新命名為 Sales2020-2011。 從 Sales2020-2011 分割區中排除 2010 會計年度的資料,並移至 SalesOld 分割區。 如此一來,所有資料分割都已經過處理以反映變更。 這通常稱為 滾動視窗 模式 - 每個分割區中的資料都位於預先定義的日期範圍內,並視需要遞增,讓記憶體和處理資源在一段時間內的可預測範圍內使用。
細微性會受到各種因素影響,包括在可接受的時間內以累加方式處理的資料量。 例如,如果每天只需要每天處理最後一天,使用每日資料細微性可能會很有説明。 混合細微度可以針對類似低細微性的近乎即時重新整理,以及較高細微性的靜態分割區等案例進行設定。 這會導致較少的分割區,但也會增加管理額外負荷,以確保正確定義分割區範圍。
資料分割也適用于包含來自多個資料來源之資料的資料表。 不同的資料來源可能會在不同的時間更新資料,這可以判斷模型資料表資料的不同細微性和處理需求。 例如,模型中的 Orders 資料表包含來自兩個不同事實資料表的訂單交易:factInternetOrders 和 factRetailOrders。 在資料來源中,factInternetOrders 會每小時更新一次。 factRetailOrders 另一方面只會在關閉所有零售商店之後一天更新一次。 藉由在模型 Orders 資料表中針對從 factInternetOrders 和 factRetailOrders 匯入的資料建立不同的資料分割,即可分隔 Orders 資料表上的處理作業,並針對資料來源上的訂單資料更內嵌地執行。
每個案例都是唯一的。 請務必為您的資料模型定義資料細微性,最有效地將資料分割成必須經常處理的分割區,與沒有的分割區相較之下。
分割區限制
不論平臺為何,模型中的資料分割物件數目都沒有固定限制。 不過,每個分割區至少有一個資料區段具有記憶體使用量。 太多小型分割區可能會導致小型區段過多。 當儲存引擎必須掃描大量區段時,查詢效能可能會受到負面影響。 過多資料分割區上的中繼資料作業速度,也會對處理資源產生負面影響。
建立分割區數目下限,同時仍能有效地達成資料分割目標。 請務必根據資料細微性來專注有效的資料分割策略,並在使用者查詢不足時,只處理具有可用處理和記憶體資源內最相關變更資料的分割區。
資料分割中的資料量也沒有任何限制。 雖然不太可能,模型可能會有具有單一預設資料分割的單一資料表,而且該資料表可能包含模型中的所有資料。 分割區中的資料量只會受限於服務方案或硬體的可用記憶體資源。
建立和管理分割區
在 Visual Studio 中使用表格式模型設計工具撰寫模型時,您可以使用資料分割管理員,在模型工作區資料庫中建立新的資料分割、編輯、合併或刪除資料分割。 根據您要撰寫之模型的相容性層級,資料分割管理員會提供兩種模式來選取要包含在資料分割中的資料:對於具有結構化資料來源的表格式 1400 和更高層級模型,資料分割是使用 Power Query M 運算式來定義。 例如,下列查詢會定義 2019 日曆年度的資料分割:
let
Source = #"SQL/sqlserver database windows net;Contoso",
dbo_Sales = Source{[Schema="dbo",Item="Sales"]}[Data],
#"Filtered Rows" = Table.SelectRows(dbo_Sales, each [OrderDateKey] >= 20190101 and [OrderDateKey] <= 20191231)
in
#"Filtered Rows"
針對提供者資料來源,資料分割是使用 SQL 查詢來定義。 例如
SELECT [dbo].[Sales].* FROM [dbo].[Sales]
WHERE (([OrderDateKey] >= '20190101') AND ([OrderDateKey] <= '20191231'))
請注意,POWER QUERY M 運算式中的 Filtered Rows 引數和 SQL 語句中的 WHERE 子句會使用大於 () 、小於 < (>) ,以及等於 (=) 運算子來定義一個日曆年度。 定義資料分割時,請務必讓每個分割區的查詢定義一個唯一的資料範圍,而無法讓其他分割區重復資料。
SQL Server Management Studio (SSMS)
部署模型之後,分割區會顯示為SQL Server Management Studio (SSMS) 中的物件。 使用 SSMS 中的 [資料分割] 對話方塊、執行表格式模型指令碼語言 (TMSL) 腳本,或使用表格式物件模型 (TOM) ,建立、編輯、合併及刪除已部署模型的分割區。
表格式模型指令碼語言 (TMSL)
模型的分割區定義于 Partitions 物件中。 在下列範例中,Sales2019 分割區定義為:
"partition": {
"name": "Sales2019",
"mode": "import",
"source": {
"type": "m",
"expression": [
"let",
" Source = #\"SQL/sqlserver database windows net;Contoso\",",
" dbo_Sales = Source{[Schema=\"dbo\",Item=\"Sales\"]}[Data],",
" #\"Filtered Rows\" = Table.SelectRows(dbo_Sales, each [OrderDateKey] >= 20190101 and [OrderDateKey] <= 20191231)",
"in",
" #\"Filtered Rows\""
]
},
Partitions 物件的動作可以在下列 TMSL 命令中指定:
TMSL 腳本可以在 SQL Server Management Studio中執行、使用 PowerShell 執行Invoke-ASCmd命令,或透過 SQLServer Integration Services (SSIS) 腳本工作來執行。
對於 1100 和 1103 相容性層級的模型,如果 TMSL,則會改用 Analysis Services 指令碼語言 (ASSL) 。
表格式物件模型 (TOM)
在表格式物件模型中,資料分割是由 Microsoft.AnalysisServices.Tabular 命名空間中的 Partition 類別所定義。 若要深入瞭解使用 TOM 作為 API 的程式設計解決方案,請參閱本文稍後的建立 資料表、分割區和資料行 (TOM) 和 進階資料分割策略 。
對於 1100 和 1103 相容性層級的模型,請使用 Analysis Management Objects (AMO) 。
處理分割區
當分割資料表資料時,就可以一次處理這些分割區,並針對您的解決方案採取適當的步調。 當 (重新整理) 作業執行時,會使用資料來源連接來建立資料來源的連接。 Analysis Services 會使用針對每個資料分割指定的查詢來查詢資料來源。 新的和更新的資料會載入模型資料表、重建關聯性和階層,並重新計算匯出資料行。
在 Visual Studio 中撰寫模型時,您可以從功能表或工具列,在工作區資料庫分割區上手動執行進程作業。 對於已部署的模型,處理作業是使用 SSMS 中的 [處理資料表] 對話方塊手動叫用,方法是執行腳本,其中包含 Refresh 命令 (TMSL) ,或使用表格式物件模型 (TOM) 。
平行處理
Analysis Services 會針對兩個或多個分割區利用平行處理,以提高處理效能。 平行處理沒有任何組態設定。 當您處理資料表或針對相同資料表和進程選取多個分割區時,預設會發生平行處理。 不過,有限制平行處理作業的設定。
MaxConnections
根據預設,每個處理作業都會連接到並查詢每個分割區的資料來源。 指定為單一資料來源 之 MaxConnections 屬性的預設連線數目上限為 10。 Analysis Services 會根據核心數目和可用的執行緒,決定要執行的並行處理作業數目。 這些執行緒會跨伺服器實例共用。 進程之類的單一命令可能不會收到所有可用的執行緒。 針對每個平行處理作業啟動的執行緒可以延遲處理,以停留在 MaxConnections 限制內。
MaxParallelism
根據預設,處理作業會盡可能平行執行。 不過,您可以使用 Sequence 命令指定 maxParallism 屬性選項, (TMSL) ,選擇循序或平行處理分割區。 將值設定為 1 表示不平行 - 一個執行緒用於處理。 將值設定為 2 或更多指定固定數目的執行緒可用於平行處理作業。
監視器
若要判斷在進程作業期間有效使用可用的執行緒,若要Azure Analysis Services,請使用 Azure 計量總管來監視 CommandPoolIdleThreads 和 CommandPoolBusyThreads。 若要深入了解,請參閱監視伺服器計量。 針對SQL Server Analysis Services,請使用效能監視器監視處理集區閒置非 I/O 執行緒和處理集區忙碌非 I/O 執行緒。 若要深入瞭解,請參閱 SSAS) (效能計數器 。
注意
如果偵測到重新編碼,平行處理可能會導致資源使用量增加。 這是因為多個分割區作業必須以新的平行編碼方式中斷並重新啟動。
進階資料分割策略
Analysis Services 表格式模型的自動化資料分割管理.pdf 一文,以及 GitHub 中隨附的AsPartitionProcessing程式碼範例,提供深入資訊和虛構公司 Advenure Works 的解決方案範例,方法是使用表格式物件模型 (TOM) 來建立和管理分割區。 本文和專案中所述的概念適用于所有 Analysis Services 平臺。
另請參閱
建立及管理表格式模型資料分割
Partitions 物件 (TMSL)
使用表格式物件模型建立資料表、資料分割和資料行 (TOM)
建立分割區 (教學課程)
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應