データフローに関して、前回から少し間が空いてしまいましたが、データフローを通常（Premium）に運用する際のことについて、留意点も含め記載しておきたいと思います。これまでの話では、データフローは
- ステージングクエリ（ストレージ）であり、ソースシステムへの負担を減らす働きがあるミニデータマートのような存在
- Power BI Premium (PPC = Premium Per Capacity) or PPU (Premium Per Uer)を使用して初めて威力が発揮される
- 個ではなく組織での共有を目的とする
- コードベースで開発され、UIはモダンPower Queryであり、ExcelやPower BI Desktop版のPower Queryも今後追随予定
- Power BIだけでなく、その他多くのMicrosoftのサービスで利用可能
等が大きなメリットであったと述べてきました。基本的な特徴はChatGPTに聞いたほうがきれいにまとめてくれますが、今回はPremiumで運用する際に知っておくべきことについて実例でまとめました。
リンクされたエンティティと計算されたエンティティ
リンクされたエンティティ
データフローを使用するにあたって、最も重要な概念であるのが①リンクされたエンティティと②計算されたエンティティでしょう。エンティティ*1とは、データの世界では”情報のまとまり”であり、Power Queryのクエリ（=テーブル）であると考えて良いでしょう。
それゆえ、①と②は時に「リンクされたテーブル」、「計算されたテーブル」と表現することも可能ですが、後者の「計算されたテーブル」は計算テーブル（Calculated Table）と混同しやすくなるので、この記事では全て従来の「リンクされたエンティティ」と「計算されたエンティティ」という表現で統一します。
上記リンク先を読めば①及び②の概念が分かりますが、「リンクされたエンティティ」とは①は下図のように、異なるデータフローでエンティティ（テーブル）をリンクした場合に使用できるものです。この例ではDataflow 2のTable Aが「リンクされたエンティティ」となります。
リンクされたエンティティは特徴は主として以下の通りです。
- Premium機能であるため、Power BI Proでは実現できない
- ストレージとしてデータが読み込まれた状態であり、Power BI Desktop等のクライアントからデータをそのまま読み込める状態
- それ自体に変更を加えることはできず、変更を行いたい場合、
- 元のデータフローを更新する必要がある
この場合、Dataflow 1のTable Aを更新して初めて、Dataflow 2のTable Aが更新される - Dataflow 2のTable Aに別のテーブルからマージや結合を行う
これを実施した場合、「リンクされたエンティティ」ではなく、「計算されたエンティティ」となり、その変更を加えた状態がキャッシュされる
- 元のデータフローを更新する必要がある
- ワークスペースが同じデータフローでは、ソースとなるデータフローが更新されるが、異なるワークスペースの場合、データは自動更新されない
これらの特徴は非常に重要であり、データフローをリンク参照を行うことが多い場合には特に留意が必要となります。なお、他のワークスペースにあるデータフローの利用を可能にするためには、以下のようにアクセスの許可に関する設定を行う必要があります。こちらを忘れると他のワークスペースにあるデータフローにアクセスできないため、注意が必要です。
計算されたエンティティ
計算されたエンティティは以下のようなイメージです。⚡マークがあるクエリは「計算されたエンティティ」で、Table Dを参照したり、⚡Table DとTable Aをマージさせた場合も該当します。
計算されたエンティティは特徴は主として以下の通りです。
- Premium機能であるため、Power BI Proでは実現できない
- デスクトップ版Power Queryのように、マージや結合を自由に行うことが可能
- これにより、共通で処理可能な部分はソース側で行うが、共通で変換した出力から残りの変換はPower BIサービス側の拡張コンピューティングエンジンが行うため、処理が高速化される
最後の例は例えば下図の例で考えると分かりやすいでしょう。この図では、Dataflow 2の⚡Table G（⚡Table Eと⚡Table Fのマージされた結果）が更新されるためには、最初のソースであるTable Dという共通で処理が可能な部分、すなわち一度データソース側で処理（キャッシュ）された後、⚡Table D、⚡Table E、⚡Table Fというアウトプットを作り出していきます。⚡のクエリ（テーブル）は全てキャッシュされた結果となりますので、⚡Table GはTable Dをもう一度更新する必要がなく、既にキャッシュされた⚡Table Eと⚡Table Fをベースにマージされますので、マージする際のパフォーマンスが最適化されます。
マージのパフォーマンスが良くなるということはデータフローの更新が早く終わることを意味しますので、データフローを多く活用する、かつ、複雑で複数のクエリ（テーブル）を作るニーズがある場合には、上図のようにTable Dのように、
オリジナルのソースから直接変換をせず、計算されたエンティティを作るため、読み込みだけを行うステージングクエリ
を作っておくのがベストプラクティスの1つとなります（詳細は下記より）。
なお、Premiumで使用するデータフローは他にもパワフルな機能が含まれており、例えば以下のようなものがあります。
- データフローに対するDirectQuery接続
- 拡張コンピューティングエンジンによる処理能力の向上
- 増分更新の使用
特に拡張コンピューティングエンジンは上述したアーキテクチャを遵守するとパフォーマンスを発揮しますので、
- ソース
- 読込オンリーのステージングクエリ（ここで一旦全てキャッシュさせる）
- 実際に各クエリへのETL作業（リンクされたエンティティ / 計算されたエンティティの使用）
というステップを踏まえると効果的となります。なお、拡張コンピューティングエンジンを使用すると、Power Queryのパフォーマンスにおいて最も重要な概念であるクエリフォールディングが実現できることになりますので、積極的に使っていきたいものです。
まとめ
今回はPremium環境で使用した際の基本的な概念について解説をしました。全て覚えるのは大変ですが、リンク先を辿って少しずつ理解していくと良いでしょう。なお、かなり前のBlogになりますが、拡張コンピューティングエンジン（Enhanced Compute Engine）に関するテクニカルな解説は下記をご参照。
- その仕組みについて（日本語訳）
この強化されたコンピュートエンジンは、データフローエンティティデータをSQLベースのキャッシュにロードすることにより、複数のシナリオのパフォーマンスを向上させます。SQLのクラスタ化されたカラムストアインデックスとその他の最適化を使用し、クエリ処理で最大20倍の改善を目指します。Premiumのデータフローに対して計算されたエンティティやDirectQuery接続は、Power Bl Proのデータフローのようにストレージやフラットファイルから読み込むのではなく、キャッシュから読み込むことで実現することができます。
Premiumで使用するデータフローは拡張コンピューティングエンジンによって、Pro環境のデータフローよりもパフォーマンスが高速化されていることが分かります。次回はデータフローの更新で気をつけるべきポイントについて見ていくことにします。
*1:実際に良く使われるケースとして、会社（エンティティ）等があり、「実在」、「本質」、「実体」といったことを意味する
