複雑なデータフローを設計および開発するためのベスト プラクティス
開発中のデータフローがより大きく、そして複雑になっている場合、元々の設計を改善するためにお客様にできるいくつかのことを以下に示します。
複数のデータフローに分割する
1 つのデータフローですべてのことを行わないようにします。 単一の複雑なデータフローの場合は、データ変換プロセスが長くなるだけでなく、データフローの理解と再利用も困難になります。 複数のテーブルを複数のデータフローに分けるか、1 つのテーブルを複数のデータフローに分けることで、データフローを複数のデータフローに分割することができます。 計算テーブルまたはリンク テーブルの概念を使用すれば、1 つのデータフローに変換を部分的に作成し、それを他のデータフローで再利用することができます。
ステージングまたは抽出データフローからデータ変換データフローを分離する
データ抽出専用のデータフロー (つまり、ステージング データフロー) と、さらにそれとは別にデータ変換専用のデータフローを用意すると、多層アーキテクチャを作成する場合だけでなく、データフローの複雑さを軽減するのにも役立ちます。 一部の手順 (データの取得、ナビゲーション、データ型の変更など) で行われるのは、データ ソースからのデータの抽出だけです。 ステージング データフローと変換データフローを分離することで、データフローをより簡単に開発できます。
データ ソースからステージング データフローへのデータの抽出を示す画像。テーブルは Dataverse または Azure Data Lake Storage に格納され、 その後、データが変換のデータフローに移動されて、データ ウェアハウスの構造に変換されます。 その後、データはセマンティック モデルに移動されます。
カスタム関数を使用する
カスタム関数は、さまざまなソースからの多数のクエリに対して特定の数の手順を行う必要があるシナリオで役立ちます。 カスタム関数を開発するには、Power Query エディターのグラフィカル インターフェイスを使用するか、M スクリプトを使用します。 関数は、必要な数のテーブルで、データフローで再利用できます。
カスタム関数を使用すると、ソース コードのバージョンを 1 つだけとすることができるので、コードを複製する必要がありません。 そのため、Power Query 変換ロジックとデータフロー全体の保守が大幅に簡単になります。 詳細については、ブログ投稿: Power BI Desktop でカスタム関数を簡単に作成するを参照してください。
Note
カスタム関数を使用してデータフローを更新するために Premium 容量が必要であるという通知を受け取ることがありますが、 このメッセージは無視して、データフロー エディターを再度開いてください。 "読み込みが有効な" クエリを参照しない関数であれば、通常は問題ありません。
フォルダー内にクエリを配置する
クエリにフォルダーを使用すると、関連するクエリを容易にグループ化できます。 データフローを開発する場合は、もう少し時間をかけて、意味のあるフォルダーにクエリを配置します。 このアプローチであれば、将来的にクエリが簡単に見つかるようになり、コードの保守も大幅に楽になります。
計算テーブルを使用する
計算テーブルを使用すると、データフローの理解が容易になるだけでなく、パフォーマンスも向上します。 計算テーブルを使用する場合、そこから参照される他のテーブルは、"既に処理および格納隅" のテーブルからデータを取得するため、 変換がはるかに簡単で高速になります。
強化されたコンピューティング エンジンを利用する
Power BI 管理ポータルでデータフローを開発する場合は、他の種類の変換を行う前に、計算テーブルで結合とフィルター処理の変換を行うことで、計算エンジンを拡張して使用する必要があります。
数が多い手順は複数のクエリに分割する
多くのステップを 1 つのテーブルで追跡することは困難です。 多数のステップを複数のテーブルに分割することが必要です。 他のクエリでは読み込みを有効にするを使用し、中間クエリの場合は無効にして、データフローによる最終的なテーブルのみを読み込んでください。 それぞれに含まれる手順数がより少ないクエリが複数ある場合、さらに詳しい調査を行うには、1 つのクエリで数百の手順を掘り下げるよりも、依存関係図を使用して各クエリを追跡する方が簡単です。
クエリと手順に対してプロパティを追加する
ドキュメントは、保守しやすいコードを作成するための鍵となります。 Power Query では、プロパティをテーブルとステップにも追加できます。 プロパティに追加したテキストは、そのクエリまたはステップにカーソルを合わせたときにツールヒントとして表示されます。 これにより、将来的にモデルの保守が容易になります。 テーブルまたは手順を一目見れば、その手順で何を行ったかを考え直して思い出すのではなく、そこで何が行われているかを理解できます。
容量が確実に同じリージョンに含まれるようにする
現在、データフローでは複数の国またはリージョンはサポートされていません。 Premium 容量を、Power BI テナントと同じリージョンに用意する必要があります。
オンプレミスのソースをクラウド ソースから分離する
オンプレミス、クラウド、SQL Server、Spark、Dynamics 365 など、ソースの種類ごとに個別のデータフローを作成することをお勧めします。 ソースの種類ごとにデータフローを別々にすると、トラブルシューティングが容易になり、データフローを更新する際の内部制限が回避されます。
テーブルの更新スケジュールに基づいてデータフローを分離する
1 時間ごとに更新される営業取引テーブルがソース システムに存在し、毎週更新される製品マッピング テーブルがある場合は、これら 2 つのテーブルを、データ更新スケジュールの異なる 2 つのデータフローに分割してください。
リンクされたテーブルを同じワークスペースでスケジュール更新しない
リンクされたテーブルを含むデータフローから定期的にロックアウトされる場合、対応し依存するデータフローが同じワークスペース内で更新中にロックされることが原因である可能性があります。 このようなロックにより、トランザクションの正確性が提供され、両方のデータフローが正常に更新されることが保証されますが、編集がブロックされる可能性もあります。
リンクされたデータフローに対して個別のスケジュールを設定した場合、データフローが不必要に更新され、データフローの編集がブロックされる可能性があります。 この問題の回避のために、次の 2 つの方法をお勧めします:
- ソース データフローと同じワークスペース内のリンクされたデータフローに対しては、更新スケジュールを設定しないでください。
- 更新スケジュールを個別に構成し、ロック動作を回避したい場合は、データフローを別のワークスペースに移動します。