インポート モデリングのデータ削減手法

  • [アーティクル]

この記事では、インポート モデルを開発している Power BI Desktop データ モデラーを対象としています。 インポート モデルに読み込まれるデータを減らすためのさまざまな手法について説明します。

インポート モデルは、VertiPaq ストレージ エンジンによって圧縮および最適化されてからディスクに格納されるデータと共に読み込まれます。 ソース データがメモリに読み込まれると、10 倍の圧縮が見られる可能性があるため、10 GB のソース データが約 1 GB のサイズに圧縮されることを期待できます。 さらに、ディスクに永続化すると、さらに 20% を削減できます。

VertiPaq ストレージ エンジンによって実現される効率性だけでなく、モデルに読み込まれるデータを最小限に抑えるように努力することが重要です。 大規模なモデルや、時間の経過と共に大規模になると予測されるモデルの場合は、特にそうです。 説得力のある 4 つの理由があります。

  • モデル サイズが大きくなるほど、お持ちの容量でサポートできくなる可能性があります。 共有容量では最大 1 GB のモデルをホストできますが、Premium 容量では SKU に応じてより大きいモデルをホストできます。 詳細については、大規模なセマンティック モデルに対する Power BI Premium のサポートに関する記事を参照してください。 (セマンティック モデルは、以前はデータセットと呼ばれていました)。
  • モデル サイズが小さくなるほど、容量リソース (特にメモリ) の競合が減少します。 これにより、より長時間、より多くのモデルを同時に読み込むことができるため、削除率が低くなります。
  • モデルが小さいほどデータ更新が高速になるため、レポート作成の待機時間が短くなり、セマンティック モデルの更新スループットが向上し、ソース システムと容量リソースの負荷が軽減されます。
  • テーブルの行数が少ないほど、評価計算が高速になるため、クエリの全体的なパフォーマンスを向上させることができます。

重要

この記事では、Power BI Premium またはその容量サブスクリプション (P SKU) に言及することがあります。 現在、Microsoft は購入オプションを統合し、容量あたりの Power BI Premium SKU を廃止していることに注意してください。 新規および既存のお客様は、代わりに Fabric 容量サブスクリプション (F SKU) の購入をご検討ください。

詳細については、「Power BI Premium ライセンスに関する重要な更新」と「Power BI Premium のよく寄せられる質問」を参照してください。

この記事では、8 種類のデータ削減手法について説明します。 これらの手法は次のとおりです。

不要な列を削除する

モデル テーブルの列には、主に次の 2 つの目的があります。

  • レポート: モデル データの適切なフィルター処理、グループ化、および集計を行うためのレポート デザインを実現します
  • モデル構造: モデルのリレーションシップ、モデルの計算、セキュリティ ロール、さらにはデータの色の書式設定をサポートします

このような目的で使用されない列は、削除される可能性があります。 列の削除は、"列フィルター選択" と呼ばれます。

既知のレポート要件に基づいて、正確な数の列を含むモデルを設計することをお勧めします。 要件は時間の経過と共に変わる可能性がありますが、後で列を削除するよりも後で列を追加する方が簡単なことを覚えておいてください。 列を削除すると、レポートまたはモデル構造が壊れる可能性があります。

不要な行を削除する

モデル テーブルは、できるだけ少ない行数で読み込む必要があります。 これは、2 つの異なる理由 (エンティティごとにフィルター処理するか、時間によってフィルター処理するか) のために、フィルター処理済みの行セットをモデル テーブルに読み込むことで実現できます。 行の削除は、"水平方向のフィルター処理" と呼ばれます。

エンティティによるフィルター処理では、ソース データのサブセットがモデルに読み込まれます。 たとえば、すべての販売地域の売上ファクトを読み込むのではなく、1 つの地域のファクトのみを読み込みます。 この設計方法では、多数の小さなモデルが生成されるため、行レベルのセキュリティを定義する必要がなくなります (ただし、Power BI サービスで特定のセマンティック モデルのアクセス許可を付与し、各セマンティック モデルに接続する "重複" レポートを作成する必要があります)。 Power Query パラメーターと Power BI テンプレート ファイルを利用して、管理と発行を簡素化することができます。 詳細については、「クエリ パラメーターと Power BI テンプレートについて詳しく調べる」のブログ記事をご覧ください

時間によるフィルター処理では、ファクト型のテーブルに読み込まれる "データ履歴" の量が制限されます (また、モデルの日付テーブルに読み込まれる日付の行も制限されます)。 使用可能なすべての履歴を自動的に読み込むことは、これが既知のレポート要件である場合を除き、お勧めできません。 時間ベースの Power Query フィルターは、パラメーター化でき、さらには相対的な時間間隔 (たとえば、更新日に対して過去 5 年間など) を使用するように設定できることを理解すると役立ちます。 また、時間フィルターへの遡及的な変更によりレポートが壊れることはありません。これにより、レポートで使用できるデータ履歴が減る (増える) だけです。

グループ化と集計

モデルのサイズを小さくする最も効果的な方法は、事前に集計されたデータを読み込むことです。 この手法を使用すると、ファクト型テーブルの粒度を上げることができます。 ただし、詳細が失われるという明確なトレードオフがあります。

たとえば、ソースの売上ファクト テーブルには、注文明細行ごとに 1 つの行が格納されています。 すべての売上指標を集計し、日付、顧客、製品別にグループ化することで、データの大幅な削減を実現できます。 次に、"月レベルで" 日付をグループ化することで、さらに大幅なデータ削減を実現できることを検討します。 これにより、モデル サイズの 99% 削減を達成できる可能性がありますが、日単位や個別の注文レベルでレポートを作成することはできなくなります。 ファクト型データの集計の決定には、常にトレードオフが伴います。 このトレードオフは、混合モデル設計によって軽減できる可能性があります。このオプションについては、「混合モードに切り替える」の手法で説明します。

列のデータ型を最適化する

VertiPaq ストレージ エンジンでは、列ごとに個別のデータ構造が使用されます。 仕様により、これらのデータ構造は、値のエンコードを使用する数値列データに対して最も高い最適化を実現します。 ただし、テキストやその他の数値以外のデータでは、ハッシュ エンコードが使用されます。 これには、列に格納されている一意の各テキスト値に数値識別子を割り当てるためにストレージ エンジンが必要です。 これは数値識別子で、その後、データ構造に格納され、ストレージとクエリの実行中にハッシュ検索が必要になります。

一部の特定のインスタンスでは、ソース テキスト データを数値に変換できます。 たとえば、販売注文番号にプレフィックスとして常にテキスト値 (例 "SO123456") が付くことがあります。 プレフィックスを削除して、注文番号の値を整数に変換することができます。 大きなテーブルの場合、データを大幅に削減できる場合があります。列に一意の値または高いカーディナリティの値が含まれている場合は特にその可能性が高くなります。

この例では、列の [既定の概要] プロパティを [集計しない] に設定することをお勧めします。 これは、注文番号値の不適切な集計を最小限に抑えるのに役立ちます。

カスタム列の設定

VertiPaq ストレージ エンジンでは、通常の Power Query ソース列と同様に、モデル計算列 (DAX で定義) が格納されます。 ただし、データ構造は若干異なる方法で格納され、通常、圧縮率は低くなります。 また、これらはすべての Power Query テーブルが読み込まれると構築されるため、データ更新時間が長くなる可能性があります。 そのため、テーブル列を計算列として追加するのは、Power Query 計算列 (M で定義) よりも効率性が落ちます。

設定により Power Query のカスタム列が作成されている必要があります。 ソースがデータベースの場合は、2 通りの方法で読み込み効率を高めることができます。 計算は、(プロバイダーのネイティブ クエリ言語を使用して) SQL ステートメントで定義することも、データ ソース内の列として具体化することもできます。

ただし、場合によっては、モデルの計算列の方が適していることもあります。 これには、数式でメジャーを評価する場合や、DAX 関数でのみサポートされる特定のモデリング機能が必要な場合などが考えられます。 このような例の詳細については、「DAX における親子階層の関数について」を参照してください。

Power Query クエリの読み込みを無効にする

他のクエリとのデータ統合のサポートを意図した Power Query クエリは、モデルに読み込むことはできません。 クエリがモデルに読み込まれないようにするには、これらのインスタンスでクエリの読み込みを確実に無効にするようにしてください。

[読み込みを有効にする] オプションを表示している Power Query のスクリーンショット。

自動の日付/時刻を無効にする

Power BI Desktop には、"自動の日付/時刻" と呼ばれるオプションが含まれています。 有効にすると、カレンダー期間のフィルター、グループ化、ドリルダウン アクションの構成時にレポート作成者をサポートするために、日付列に対して非表示の自動の日付/時刻テーブルが作成されます。 非表示のテーブルは、実際には計算テーブルであり、これによってモデルのサイズが大きくなります。 このオプションの使用に関するガイダンスについては、Power BI Desktop の自動の日付/時刻のガイダンスの記事を参照してください。

混合モードに切り替える

Power BI Desktop では、混合モードの設計によって複合モデルが生成されます。 基本的には、テーブルごとにストレージ モードを決定することができます。 そのため、各テーブルでは、[ストレージ モード] プロパティを [インポート] または [DirectQuery] として設定できます ([デュアル] はもう 1 つのオプションです)。

モデル サイズを小さくする効果的な方法は、大規模なファクト型テーブルの [ストレージ モード] プロパティを [DirectQuery] に設定することです。 この設計アプローチは、前述の「グループ化と集計」の手法と組み合わせて使用することを考慮してください。 たとえば、集計された売上データを使用して、ハイ パフォーマンスの "概要" レポートを作成することができます。 ドリルスルー ページでは、すべてのコンテキスト内の販売注文を表示する、特定の (および絞り込んだ) フィルター コンテキストの詳細な売上を表示できます。 この例では、ドリルスルー ページには、販売注文データを取得するための DirectQuery テーブルに基づくビジュアルが含まれています。

ただし、複合モデルに関連する多くのセキュリティとパフォーマンスへの影響があります。 詳細については、「Power BI Desktop で複合モデルを使用する」の記事を参照してください。

関連するコンテンツ

Power BI インポート モデル設計の詳細については、次の記事を参照してください。