次の方法で共有

テーブル モデルでのパーティション

  • [アーティクル]

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

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

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

粒度

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

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

Partition データ ソース
Sales2020 現会計年度
Sales2019-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) を使用してプログラムでパーティションを作成、編集、マージ、および削除します。

Tabular Model Scripting Language (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 スクリプトは、Invoke-ASCmd コマンドを実行するか、SQLServer Integration Services (SSIS) スクリプト タスクを実行して、SQL Server Management Studio、PowerShell で実行できます。

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

MaxConnections

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

MaxParallelism

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

Monitor

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

注意

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

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

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

こちらもご覧ください

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