複雑なデータフローを設計および開発するためのベスト プラクティス

開発中のデータフローがより大きく、そして複雑になっている場合、元々の設計を改善するためにお客様にできるいくつかのことを以下に示します。

複数のデータフローに分割する

1 つのデータフローですべてのことを行わないようにします。 単一の複雑なデータフローの場合は、データ変換プロセスが長くなるだけでなく、データフローの理解と再利用も困難になります。 ご利用のデータフローを複数のデータフローに分割するには、複数のエンティティをそれぞれ別々のデータフローに分離するか、またはエンティティが 1 つであっても複数のデータフローに分離します。 計算対象エンティティまたはリンクされたエンティティの概念を使用すれば、1 つのデータフローで変換の一部を構築し、それを他のデータフローで再利用することができます。

ステージングまたは抽出データフローからデータ変換データフローを分離する

データ抽出専用のデータフロー (つまり、ステージング データフロー) と、さらにそれとは別にデータ変換専用のデータフローを用意すると、多層アーキテクチャを作成する場合だけでなく、データフローの複雑さを軽減するのにも役立ちます。 一部の手順 (データの取得、ナビゲーション、データ型の変更など) で行われるのは、データ ソースからのデータの抽出だけです。 ステージング データフローと変換データフローを分離することで、データフローをより簡単に開発できます。

多層データフロー アーキテクチャ。

データ ソースからステージング データフローへのデータの抽出を示す画像。ここで、エンティティは Dataverse または Azure Data Lake Storage のいずれかに格納され、次に変換データフローに移動されます。そこでは、データは変換されデータ ウェアハウス構造へと変えられ、そしてデータセットに移動されます。

カスタム関数を使用する

カスタム関数は、さまざまなソースからの多数のクエリに対して特定の数の手順を行う必要があるシナリオで役立ちます。 カスタム関数を開発するには、Power Query エディターのグラフィカル インターフェイスを使用するか、M スクリプトを使用します。 関数は、データフローにおいて必要なだけの数のエンティティで再利用できます。

カスタム関数を使用すると、ソース コードのバージョンを 1 つだけとすることができるので、コードを複製する必要がありません。 その結果、Power Query 変換ロジックおよびデータフロー全体の保守がはるかに簡単になります。 詳細については、ブログ記事「Power BI Desktop でカスタム関数が簡単に」を参照してください。

カスタム関数。

フォルダー内にクエリを配置する

クエリにフォルダーを使用すると、関連するクエリを容易にグループ化できます。 データフローを開発する場合は、もう少し時間をかけて、意味のあるフォルダーにクエリを配置します。 この方法を使用すると、今後クエリを見つけるのが簡単になり、コードの管理がずっと簡単になります。

計算対象エンティティを使用する

計算対象エンティティを使用すると、データフローがより理解しやすくなるだけでなく、パフォーマンスも向上します。 計算対象エンティティを使用すると、これによって参照される他のエンティティはデータを "already-processed-and-stored" エンティティから取得するようになります。 変換がはるかにシンプルかつ高速になります。

強化されたコンピューティング エンジンを利用する

Power BI 管理ポータルでデータフローを開発する場合は、拡張コンピューティング エンジンを確実に使用するために、まず計算対象エンティティ内で結合変換とフィルター変換を実行してから他の種類の変換を実行してください。

数が多い手順は複数のクエリに分割する

1 つのエンティティで多数の手順を追跡することは困難です。 そうするのではなく、数が多い手順は、複数のエンティティに分割すべきです。 他のクエリに対しては [読み込みを有効にする] を使用し、それらが中間クエリの場合は無効とし、最終的なエンティティの読み込みはデータフローを通じてのみ行うようにすることができます。 それぞれに含まれる手順数がより少ないクエリが複数ある場合、さらに詳しい調査を行うには、1 つのクエリで数百の手順を掘り下げるよりも、依存関係図を使用して各クエリを追跡する方が簡単です。

クエリと手順に対してプロパティを追加する

ドキュメントは、保守しやすいコードを作成するための鍵となります。 Power Query では、エンティティの他に、手順にもプロパティを追加できます。 プロパティに追加したテキストは、該当するクエリまたは手順にマウス ポインターを合わせると、ヒントとして表示されます。 このドキュメントは、ご利用のモデルを今後維持するのに役立ちます。 テーブルまたは手順を一目見れば、その手順で何を行ったかを考え直して思い出すのではなく、そこで何が行われているかを理解できます。

容量が確実に同じリージョンに含まれるようにする

現在、データフローでは複数の国またはリージョンはサポートされていません。 Premium 容量は、Power BI テナントと同じリージョンに存在する必要があります。

クラウド ソースからオンプレミス ソースを分離する

オンプレミス、クラウド、SQL Server、Spark、Dynamics 365 など、ソースの種類ごとに個別のデータフローを作成することをお勧めします。 ソースの種類ごとにデータフローを別々にすると、トラブルシューティングが容易になり、データフローを更新する際の内部制限が回避されます。

エンティティに必要なスケジュールされた更新に基づいてデータフローを分離する

ソース システムで 1 時間ごとに更新される販売トランザクション テーブルと、毎週更新される製品マッピング テーブルがある場合は、この 2 つを、データ更新スケジュールが異なる 2 つのデータフローに分割します。

同じワークスペース内でリンクされたエンティティの更新がスケジュールされないようにする

リンクされたエンティティが含まれるデータフローから定期的にロックアウトされる場合、それは、同じワークスペース内の対応する依存データフローがデータフローの更新中にロックされることで発生する可能性があります。 このようなロックにより、トランザクションの正確性が提供され、両方のデータフローが正常に更新されることが保証されますが、編集がブロックされる可能性もあります。

リンクされたデータフローに対して個別のスケジュールを設定した場合、データフローが不必要に更新され、データフローの編集がブロックされる可能性があります。 この問題を回避するための推奨事項として、次の 2 つがあります。

  • ソース データフローと同じワークスペース内のリンクされたデータフローに対しては、更新スケジュールを設定しないでください。
  • 更新スケジュールを個別に構成し、ロック動作を回避したい場合は、データフローを別のワークスペースに移動します。