前へ

次へ

Power BI のデータ モデリングのベスト プラクティスを実装する

完了

パフォーマンスが高くスケーラブルなデータ モデルにとって、データ モデリングのベスト プラクティスを実装することが重要です。

適切な Power BI モデル フレームワークを選択する

適切な Power BI モデル フレームワークを選択することは、スケーラブルなソリューション構築の核です。

Power BI データ モデルでの作業の開始点は "インポート モード" です。 インポート モードには、ほとんどのオプションが備わています。柔軟に設計でき、高速なパフォーマンスを実現します。

データ ソースに大量のデータが格納されているときや、レポートでほぼリアルタイムのデータを配信する必要があるときは、"DirectQuery" モデル フレームワークを使用します。

最後に、以下を行う必要があるときは "複合モデル" を使用します。

• DirectQuery モデルのクエリ パフォーマンスを向上させる。
• インポート モデルから凖リアルタイムのクエリ結果を配信する。
• Power BI データセット (または Azure Analysis Services モデル) を他のデータを使用して拡張する。

複合モデルは、複数の DirectQuery ソースのデータを結合するか、DirectQuery とインポート データを結合します。

重要

インポート、DirectQuery、または複合モデルの使用の詳細については、「Power BI モデル フレームワークを選ぶ」モジュールを参照してください。

データ モデリングのベスト プラクティスを実装する

データ モデルを構築する際に遵守すべき基本原則がいくつかあります。 これらの原則は、データの増加が始まるにつれてさらに重要になります。

最も重要なのは、データが Power BI に到達する前にできるだけ上流で、できるだけ多くのデータ準備作業を行うことです。 たとえば、データ ウェアハウス内でデータを変換する機会があるなら、そこで行うべきです。 ソース時点で変換することで、そのデータに基づいて構築される他のすべてのソリューションの一貫性が保たれ、Power BI モデルで追加の処理を行う必要がなくなります。 これには、データ エンジニアや他のデータ チーム メンバーとの連携が必要になる場合があり、非常に重要です。

インポート モードのベスト プラクティス:

• 可能であれば、常にインポート モードで開始します。
• 必要なデータのみを取り込みます。
  • 不要な行と列を削除します。
  • ビジネス要件に応じて、絶対に必要なもの (テーブル/パーティション) のみを処理します。
• 幅の広いテーブルは使用しないようにします。
  • Power BI でスター スキーマを使用します。
    • ソースが、美しくモデル化されたデータ ウェアハウスである場合は、一歩先を行くことができます。
    • ビッグ データは、多くの場合、幅の広いフラット テーブルに格納されています。 パフォーマンス上の利点を得るには、ディメンション モデルを活用します。
    • Power BI は、ディメンションが異なる、粒度が異なる複数のファクト テーブルをサポートしているので、すべてを 1 つの大きなテーブルに入れる必要がありません。
• 可能な場合は、データをモデルに読み込む前に事前集計します。
• 計算列の使用量を減らします。
  • 追加の列を必要とするデータ変換は、可能な限りソースの近くで行う必要があります。
• カーディナリティの高い列使用しないようにします。
  • datetime 列は、1 つは日付、1 つは時刻の 2 つの列に分割することを検討してください。
• 適切なデータ型を使用します。
  • ID 列には、文字列ではなく、整数を使用します。
  • 必要に応じて、ID 列に代理キーを使用します。
• リレーションシップでの双方向フィルターの使用を制限します。
• 自動の日付/時刻を無効にします。
  • ソースの日付テーブルに接続するか、独自の日付テーブルを作成します。
• 属性以外の列の属性階層を無効にします。
• リレーショナル データベースにクエリを実行する場合は、テーブルではなくデータベース ビューにクエリを実行します。
  • ビューでは、列を管理する抽象化レイヤーが提供され、最初の考慮事項に関連して、変換を可能な限りソースに近づけます。
  • ビューにロジックを含めないようにします。 含めるのはテーブルの SELECT ステートメントのみにする必要があります。
• 必要のないデータの読み込みを回避するために、パーティション分割と増分更新を検討します。
• クエリ フォールディングが確実に行われることを確認します。
  • クエリ フォールディングが不可能な場合は、データ エンジニアと協力して、変換を上流に移動する別の機会があります。

ヒント

インポート モデルに読み込まれるデータを減らすのに役立つ手法をご確認ください。

DirectQuery モードに固有のベスト プラクティス:

• リレーションシップで [参照整合性を想定] プロパティを使用して整合性を適用するようにリレーションシップを設定します。
  • リレーションシップで [参照整合性を想定] を設定すると、OUTER JOIN ではなく INNER JOIN ステートメントをクエリで使えるようになります。
• リレーションシップでの双方向フィルターの使用を制限します。
  • 必要な場合にのみ使用します。
• DAX 計算の複雑さを制限します。
  • DirectQuery ではクエリ フォールディングが既定で行われるため、DAX メジャーが複雑になると、ソースでの複雑さが増し、クエリが遅くなります。
  • また、複雑な DAX の必要性は、できるだけ上流で変換を適用するという主要原則にもつながります。 場合によっては、データ エンジニアと協力して、ソースで変換を適用する必要があります。
• 計算列の使用は避けてください。
  • 追加の列を必要とする変換は、特に DirectQuery を使用するときには、できるだけ上流で行う必要があります。
• 計算列でリレーションシップを使用しないようにします
• 一意識別子列でリレーションシップを使用しないようにします
• DirectQuery 内のファクト テーブルに関連するディメンションには、デュアル ストレージ モードを使用します。

注意

DirectQuery モデルの開発に関する考慮事項の完全な一覧については、「DirectQuery モデルのガイダンス」を参照してください。

表形式モデルを開発するときにモデリングの誤りや変更を警告するツールも使用でき、モデルの設計とパフォーマンスが向上します。 表形式エディター内のベスト プラクティス アナライザーは、モデリングのベスト プラクティスに準拠するモデルを設計するのに役立つように設計されています。

次のユニットでは、Power BI Premium を使用して大規模なデータセット ストレージ形式を構成する方法について説明します。

続行