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

この記事では、Power BI セマンティック モデルを開発して発行する Power BI Desktop データ モデリング者を対象にしています。 具体的には、 インポート モデルに読み込まれるデータを減らすのに役立つさまざまな手法について説明します。

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

VertiPaq ストレージ エンジンによって達成される効率にもかかわらず、モデルに読み込まれるデータを最小限に抑えるように努力する必要があります。 これは、大規模なモデルや、時間の経過とともに大きくなると予想されるモデルに特に当てはまります。 説得力のある 4 つの理由があります。

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

不要な列を削除する

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

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

これらの目的のいずれにも対応していない列は削除できます。 テーブルから列を削除することは、 垂直フィルターと呼ばれることもあります。

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

不要な行を削除する

可能な限り少ない行でモデル テーブルを読み込む必要があります。 これを実現するには、フィルター処理された行セットをモデル テーブルに読み込み、時間またはエンティティでフィルター処理するという 2 つの異なる理由があります。 行の削除は、 水平フィルターと呼ばれることもあります。

• 時間でフィルター処理するには、ファクト テーブルに読み込まれるデータ履歴の量を制限する (およびモデルの日付テーブルに読み込まれる日付行を制限する) 必要があります。 既知のレポート要件でない限り、使用可能なすべての履歴を既定で読み込まないことをお勧めします。 時間ベースの Power Query フィルターをパラメーターと共に実装し、相対期間を使用するように設定することもできます (たとえば、過去 5 年間の更新日を基準に)。 また、時間フィルターに対する振り返り変更によってレポートが壊れることはありません。レポートで使用できるデータ履歴が少なくなる (またはそれ以上) だけです。
• エンティティによるフィルター処理では、ソース データのサブセットがモデルに読み込まれます。 たとえば、すべての販売地域の売上ファクトを読み込むのではなく、1 つの地域のファクトのみを読み込みます。 この設計アプローチでは、多数の小さなモデルが生成され、 行レベルのセキュリティ (RLS) を定義する必要がなくなりますが、Power BI サービスで特定のセマンティック モデルのアクセス許可を付与し、各セマンティック モデルに接続する重複するレポートを作成する必要があります。 Power Query パラメーターと Power BI テンプレート ファイルを使用して、管理と発行を簡略化できます。 詳細については、「 Power BI Desktop でのレポート テンプレートの作成と使用」を参照してください。

グループ化と集計

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

ソースの販売ファクト テーブルに注文明細行ごとに 1 行が格納される例を考えてみましょう。 すべての売上メトリックを集計し、日付、顧客、製品別にグループ化することで、データの大幅な削減を実現できます。 日付を 月レベルでグループ化することで、さらに大幅なデータ削減を実現できます。 モデル サイズが 99% 減少する可能性はありますが、日レベルまたは個々の注文ライン レベルでのレポートはできなくなります。 ファクト データの要約を決定するには、常にトレードオフが伴います。 トレードオフは、DirectQuery ストレージ モードの一部のテーブルを含むモデル設計によって軽減できます。これについては、この記事の 後半 で説明します。

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

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

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

この例では、列の既定の集計プロパティを Do Not Summarizeに設定することをお勧めします。 これは、注文番号値の不適切な要約を回避するのに役立ちます。

カスタム列の設定

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

可能な限り、Power Query でのカスタム列の作成を優先します。 ソースがデータベースの場合、2 つの方法で読み込み効率を向上させることができます。計算は SQL ステートメントで定義するか (プロバイダーのネイティブ クエリ言語を使用して)、データ ソースの列として具体化できます。

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

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

他のクエリとのデータ統合をサポートすることを目的とした Power Query クエリは、モデルに読み込むべきではありません。 これらのクエリをモデルに読み込むのを回避するには、これらのインスタンスでクエリの読み込みを無効にしてください。

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

Power BI Desktop には、"自動の日付/時刻" と呼ばれるオプションが含まれています。 有効にすると、モデル内の各日付列に対して非表示の自動日付/時刻テーブルが作成されます。 このオプションは、カレンダー期間のフィルター、グループ化、およびドリルダウン アクションを構成するときのレポート作成者をサポートします。 非表示テーブルは、実際にはモデルのサイズを大きくする計算テーブルです。

詳細については、「Power BI Desktop での自動の日付/時刻のガイダンス」を参照してください。

DirectQuery ストレージ モードを使用する

DirectQuery ストレージ モードは、ストレージ モードのインポートに代わる方法です。 DirectQuery モデル テーブルはデータをインポートしません。 代わりに、テーブル構造を定義するメタデータのみで構成されます。 テーブルのクエリを実行すると、ネイティブ クエリを使用して、基になるデータ ソースからデータが取得されます。 Import と DirectQuery ストレージ モードのテーブルを 1 つのモデルで組み合わせると、 複合モデルと呼ばれます。

モデル サイズを小さくする効果的な手法は、大規模なファクト テーブルのストレージ モードを DirectQuery に設定することです。 この設計アプローチは、多くの場合、前に紹介したグループ化して要約する手法とうまく機能すると考えてください。 たとえば、集計された売上データを使用して、高パフォーマンスの概要レポートを実現できます。 ドリルスルーページでは、特定の狭いフィルターコンテキストに基づいた詳細な売上情報を表示でき、関連するすべての販売注文が確認できます。 この例では、ドリルスルー ページに DirectQuery モデル テーブルに基づくビジュアルを含め、販売注文データを取得できます。

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

関連するコンテンツ

この記事に関連する詳細については、次の記事を参照してください。

• Power BI サービスのセマンティック モデル モード
• Power BI Desktop のストレージ モード
• わからないことがある場合は、 Fabric コミュニティに問い合わせしてみてください
• ご提案はありますか？ Fabric の を向上させるためにアイデアを投稿する