次の方法で共有


表形式モデルのパーティション

適用対象: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

パーティションは、頻繁に処理 (更新) する必要があるデータの一部を、あまり頻繁に処理できないデータから分割します。 たとえば、ファクト テーブルには、ほとんど変更されないデータを含む特定の行セットが含まれている場合がありますが、他の行セットには頻繁に変更されるデータが含まれます。 データの一部のみを処理する必要がある場合は、 すべての データを処理する必要はありません。

パーティションは、テーブルを論理パーティション オブジェクトに分割することによって機能します。 データの一意のセグメントを含む個々のパーティションは、他のパーティションとは独立して順次または並列に増分処理することも、処理操作から完全に除外することもできます。

粒度

既定では、モデル内の各テーブルには 1 つのパーティションがあります。 ファクト テーブルなど、多くの場合、テーブルの 1 つのパーティションを複数のパーティションに分割すると、使用可能なリソースを処理に利用しやすくなります。

効果的なモデル設計と処理戦略では、パーティションを使用して不要なプロセッサの負荷とメモリ消費を排除すると同時に、データがデータ ソースからの最新のデータを反映するのに十分な頻度で更新されることを確認します。 たとえば、表形式モデルには、現在の会計年度と前の会計年度の売上データを含む Sales テーブルを含めることができます。 モデルの Sales テーブルには、次のパーティションがあります。

Partition データ元から
Sales2020 現在の会計年度
売上高2019年-2010年 会計年度 2010、2011、2012、2013、2014、2015。 2016, 2017, 2018, 2019
SalesOld 過去 10 年より前のすべての会計年度。

現在の 2020 会計年度の新しい売上データが追加されると、そのデータは、現在の会計年度の売上データ分析に正確に反映されるように毎日処理する必要があるため、Sales2020 パーティションは毎晩処理されます。

Sales2019-2010 パーティションのデータを夜間に処理する必要はありません。 ただし、過去 10 会計年度の売上データは、製品返品やその他の調整によって変更される可能性があるため、定期的に処理する必要があるため、Sales2019-2010 パーティションのデータは毎月処理されます。 SalesOld パーティション内のデータはほとんど変更されないため、毎年処理されるだけです。

2021 会計年度を入力すると、新しい Sales2021 パーティションがモデルの Sales テーブルに追加されます。 その後、Sales2020 パーティションを Sales2019-2010 パーティションとマージし、名前を Sales2020-2011 に変更できます。 2010 会計年度のデータは Sales2020-2011 パーティションから削除され、SalesOld パーティションに移動されます。 その後、すべてのパーティションが処理され、変更が反映されます。 これは一般に ローリング ウィンドウ パターンと呼ばれます。各パーティション内のデータは定義済みの日付範囲内にあり、必要に応じてインクリメントされ、メモリと処理リソースの使用は時間の経過と同時に予測可能な範囲内に維持されます。

粒度は、許容できる時間内に増分処理する必要があるデータの量など、さまざまな要因の影響を受けます。 たとえば、最後の 1 日のみを毎日処理する必要がある場合は、日単位の細分性を使用すると便利な場合があります。 混合粒度は、低グレインでのほぼリアルタイムの更新や、履歴の静的パーティションとの組み合わせた、より高い粒度でのシナリオに対して構成できます。 これにより、パーティションが少なくなりますが、パーティション範囲が正しく定義されるように管理オーバーヘッドも増加します。

パーティション分割は、複数のデータ ソースのデータを含むテーブルにも有効です。 データ ソースによってデータが更新される時間が異なる場合があり、モデルのテーブル データの細分性と処理の要件が異なる場合があります。 たとえば、モデル内の Orders テーブルには、factInternetOrders と factRetailOrders という 2 つの異なるファクト テーブルからの注文トランザクションが含まれています。 データ ソースでは、factInternetOrders は 1 時間ごとに更新されます。 一方、factRetailOrders は、すべての小売店が閉じられた後、1 日に 1 回だけ更新されます。 factInternetOrders と factRetailOrders の両方からインポートされたデータに対して、モデル Orders テーブルに異なる粒度で個別のパーティションを作成することで、Orders テーブルに対する処理操作をよりインラインで分離し、データ ソースの注文データと共に実行できます。

各シナリオは一意です。 データモデルの粒度を定義し、頻繁に処理する必要があるデータと、そうでないデータを効果的に分割するパーティションを設計します。

パーティションの制限

プラットフォームに関係なく、モデル内のパーティション オブジェクトの数にハード制限はありません。 ただし、各パーティションには、メモリ フットプリントを持つデータのセグメントが少なくとも 1 つ含まれます。 小さいパーティションが多すぎると、小さなセグメントが多くなりすぎる可能性があります。 ストレージ エンジンが過剰な数のセグメントをスキャンする必要がある場合、クエリのパフォーマンスに悪影響を及ぼす可能性があります。 多すぎるパーティションに対するメタデータ操作の速度も、処理リソースに悪影響を及ぼす可能性があります。

パーティション分割の目標を効果的に達成しながら、パーティションの最小数を作成します。 粒度に基づいて効果的なパーティション分割戦略に重点を置き、使用可能な処理リソースとメモリ リソース内で最も関連性の高い変更データを持つパーティションのみを、ユーザー クエリが少ない場合に処理することがより重要です。

また、パーティション内のデータ量に制限はありません。 モデルには 1 つの既定のパーティションを持つ 1 つのテーブルがあり、そのテーブルにはモデル内のすべてのデータが含まれる可能性があります。 パーティション内のデータ量は、サービス プランまたはハードウェアで使用可能なメモリ リソースによってのみ制限されます。

パーティションの作成と管理

Visual Studio でテーブル モデル デザイナーを使用してモデルを作成する場合は、パーティション マネージャーを使用して、モデル ワークスペース データベースで新しいパーティションの作成、パーティションの編集、マージ、または削除を行います。 作成するモデルの互換性レベルに応じて、パーティション マネージャーには、パーティションに含めるデータを選択するための 2 つのモードが用意されています。構造化データ ソースを持つ表形式の 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 句は、より大きい (>)、より小さい (<)、等しい (=) 演算子を使用して、正確に 1 暦年を定義していることに注意してください。 パーティションを定義するときは、各パーティションのクエリで、他のパーティションとのデータ重複を引き起こすことができない一意の範囲のデータを定義することが重要です。

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 互換性レベルのモデルでは、Analysis Services スクリプト言語 (ASSL) が TMSL の代わりに使用されます。

テーブル オブジェクト モデル (TOM)

テーブル オブジェクト モデルでは、パーティションは Microsoft.AnalysisServices.Tabular 名前空間の Partition クラスによって定義されます。 TOM を API として使用するプログラムによるソリューションの詳細については、この記事で後述する 「テーブル、パーティション、列の作成 (TOM)」および 「高度なパーティション分割戦略 」を参照してください。

1100 および 1103 互換性レベルのモデルの場合は、 分析管理オブジェクト (AMO) を使用します。

パーティションの処理

テーブル データをパーティション分割すると、それらのパーティションをソリューションに適した時間と間隔で処理できます。 プロセス (更新) 操作が実行されると、データ ソース接続を使用してデータ ソースへの接続が確立されます。 Analysis Services では、各パーティションに対して指定されたクエリを使用して、データ ソースに対してクエリを実行します。 新しいデータと更新されたデータがモデル テーブルに読み込まれ、リレーションシップと階層が再構築され、計算列が再計算されます。

Visual Studio でモデルを作成する場合は、メニューまたはツール バーからワークスペース データベース パーティションに対してプロセス操作を手動で実行できます。 デプロイされたモデルの場合、処理操作は SSMS の [プロセス テーブル] ダイアログを使用して手動で呼び出されます。そのためには、 Refresh コマンド (TMSL) を含むスクリプトを実行するか、テーブル オブジェクト モデル (TOM) を使用してプログラムで呼び出します。

並列処理

Analysis Services は、2 つ以上のパーティションに並列処理を利用し、処理パフォーマンスを向上させます。 並列処理の構成設定はありません。 並列処理は、テーブルを処理するとき、または同じテーブルとプロセスに対して複数のパーティションを選択すると、既定で発生します。 ただし、並列処理操作を制限する設定があります。

MaxConnections

既定では、各処理操作は各パーティションに接続し、データ ソースに対してクエリを実行します。 1 つのデータ ソースに 対する MaxConnections プロパティとして指定される既定の最大接続数は 10 です。 Analysis Services は、コア数と使用可能なスレッド数に基づいて、実行する同時処理操作の数を決定します。 これらのスレッドは、サーバー インスタンス間で共有されます。 プロセスなどの 1 つのコマンドで、使用可能なすべてのスレッドを受信できない場合があります。 並列処理操作ごとに 1 つずつ、処理のために起動するスレッドは、MaxConnections の制限内に収まるように遅延する可能性があります。

MaxParallelism

既定では、処理操作は可能な限り並列で実行されます。 ただし、シーケンス コマンド (TMSL)maxParallism プロパティ オプションを指定することで、パーティションを順番にまたは並列に処理できます。 値を 1 に設定すると、並列ではなく、1 つのスレッドが処理に使用されます。 値を 2 以上に設定すると、並列処理操作に使用できるスレッドの数が固定されます。

Monitor

プロセス操作中に使用可能なスレッドの効果的な使用を判断するには、Azure メトリックス エクスプローラーを使用して CommandPoolIdleThreads と CommandPoolBusyThreads を監視します。 詳細については、「 サーバー メトリックの監視」を参照してください。 SQL Server Analysis Services の場合は、パフォーマンス モニターを使用して、処理プールのアイドル状態の非 I/O スレッドと、I/O 以外のスレッドでビジー状態の処理プールを監視します。 詳細については、 パフォーマンス カウンター (SSAS) に関するページを参照してください。

再エンコードが検出されると、並列処理によってリソースの使用が増加する可能性があります。 これは、複数のパーティション操作を中断し、新しいエンコードを並列で再開する必要があるためです。

高度なパーティション分割戦略

Analysis Services テーブル モデルの自動パーティション管理 .pdf 記事と、GitHub の付属の AsPartitionProcessing コード サンプルでは、テーブル オブジェクト モデル (TOM) を使用してパーティションを作成および管理することで、架空の会社である Advenure Works の詳細な情報とソリューションの例の両方を提供します。 この記事とプロジェクトで説明する概念は、すべての Analysis Services プラットフォームに適用されます。

こちらも参照ください

テーブル モデル パーティションの作成と管理
パーティション オブジェクト (TMSL)
テーブル オブジェクト モデル (TOM) を使用してテーブル、パーティション、および列を作成する
パーティションの作成 (チュートリアル のレッスン)