前回は、Premium環境におけるデータフローの機能について説明しました。今回は、1つのデータフローから別のデータフローを構築する場合の留意点について見ていきたいと思います。シナリオをいくつか準備したので、1つずつ見ていきます。
Pro → Premiumにあるデータフローへの接続
いきなり結論になってしまいますが、Pro環境からPremium環境のデータフローへのアクセスはできません。データフロー同士を「リンクされたエンティティ」として紐づけることは許可されていません。前回のおさらいですが、社内環境でデータフローを使用するためには、アクセス権限を付与する必要があるということでした。
この操作を行うと、下図のように、異なるライセンスを持っている場合でも、ワークスペースが共有されるようになります。
しかしながら、PPU*1ライセンスに含まれるアーティファクト*2は、同じPPUライセンスを持っていない場合にはアクセスできまん。例えば、Pro環境からPPU_Demoをクリックした場合、以下のようなメッセージが表示され、PPUにアップグレードするように促されます。
データフローの観点から見ると、前回の内容も含めて、下図がまとめになります。
※ 矢印が「→」の場合、左側のテーブルを作るために、右側のテーブルにリンクしようとしていることを意味します
Power BI Pro環境では、AはPremium環境のDテーブルを「リンクされたエンティティ」として接続することができず、CはBテーブルを「リンクされたエンティティ」として参照することができません。一方、Premium環境にあるPPU Dataflowでは、すべての参照元にあるテーブルを「リンクされたエンティティ」または「計算されたエンティティ」として再利用することができます。そのため、Dataflow Proでは、AテーブルとCテーブルを作成することはできず、Premium環境での運用が必要となります。
Premium → Pro/Premiumにあるデータフローへの接続
Premium環境からProやPremium同士のワークスペースにあるデーターフローへの接続は下図の通りとなります。
※ 矢印が「←」の場合、右側のテーブルを作るために、左側のテーブルにリンクしようとしていることを意味します
全て「リンクされたエンティティ」として問題なく接続できるようになっています。
①はWorkspace C（PPU）からWorkspace A（Pro）への🔗接続
②はWorkspace C（PPU）からWorkspace B（PPU）への🔗接続
③はWorkspace C（PPU）と同じワークスペースにあるSalesテーブルへの🔗接続
となりますが、ソースとなるデーターフローが更新された場合、Workspace Cから🔗接続されたデータフローが自動更新されるかどうかについて、把握しておく必要があります。
結論から言いますと、
①と②は自動更新されず、③だけが自動更新される
ことになります。ソースとなるデータフロー（Workspace AやBに構築済）はマテリアライズされた状態ですが、通常同じワークスペースに存在する限り、「リンクされたエンティティ」は自動更新されます。この制限事項はかなり重要ですので、公式Docsからも再度確認しておいてください。
下記ダウンロードURLから入手できるDataflow_RefreshHistory_dynamic_header_pq.pbixを少しカスタマイズして、データフローの更新履歴の確認も含めて見てみます。
上記解説したデータフローを各ワークスペースにて作り、ここで解説したやり方で更新履歴を見てみます。まずはWorkspace AとWorkspace Bのデータフローをそれぞれ更新します。
更新の結果を見ると、「01.データフロー名」において、Premium環境にあるDataflow_PPUのSalesテーブルでは更新に関する詳細が提供されるのに対して、Pro環境にあるDataflow_Proは詳細がいくつか欠けている状態となっています。データフローを使う場合には通常、Premium環境で使用してくださいというメッセージだと思いますが、エンジンによって取得できる情報の種類や数が違うため、この差異が生じているかもしれません。
ここから、ワークスペースAの①Dataflow_Pro、ワークスペースBの②Dataflow_PPU、ワークスペースCの③Sales_PPUの3つのデータフロー内にあるSalesテーブルに行を追加し、この3つのデータフローをそれぞれ「リンクされたエンティティ」として作られたワークスペースCにあるDataflow_PPUについて確認してみます。
行の追加は単純にTable.Repeat関数を使い、行数を倍増させた状態にします。
元々の行数は約20万行でしたが、40万行に増加しているのが分かります。
ここでワークスペースCのDataflow_PPUを開くと、以下のような構成になっています。
なお、「Sales_PPU_SameWS」というクエリは、同じワークスペースCにある「Sales_PPU」という「リンクされたエンティティ」を参照したものです。ワークスペースBから参照した「Sales_PPU」と区別するため、「SameWS」という名前を追加しています。ようやく準備が出来ましたので、行数が追加された全てのデータフロー（Salesテーブル）について、もう一度更新履歴をpbixに取り込んだ結果を確認してみます。
WorkspaceAとBのSalesテーブルは上述の通り、PPUのほうが多くの情報を入手できます。同時に、08. 期間（更新時間）もPremium環境のほうが大幅に速いことが分かります（15秒 vs 60秒）。
WorkspaceCのSales_PPUの更新履歴は以下の通りです。
面白いことにSales_PPUはWorkspaceCにあるDataflow_PPU（①～③の集合）でもないのに、Dataflow_PPUにおける①と②の処理結果も表示してくれています。「スキップ」となっていますが、これは更新が行われていないことを意味しており、行が追加されたにも関わらず、Dataflow_PPUではリンクされたエンティティの①と②の数字が20万行のままになっていることを示唆しています。その証拠に、Power BI DesktopからWorkspaceCにあるDataflow_PPUのこれら3つのテーブルの行数をカウントしてみると、以下のように、①と②は20万行のまま、③（同じワークスペースCから参照した）データフロー（Sales_PPU_SameWS）だけが行数が2倍となっています。
このことから、冒頭で話をした通り、
①と②は自動更新されず、③だけが自動更新される
ことが確認できました。
なお、WorkspaceCの「Sales_PPU」が更新された後、同じワークスペースにある「Dataflow_PPU」も自動的に更新されたことを示す証拠として、下図のように「Sales_PPU」の終了時刻が「Dataflow_PPU」の開始時刻と同じになっていることが挙げられます。
おまけとして、ワークスペースCのDataflow_PPUの更新履歴を見てみます。「リンクされたエンティティ」となりますので、「09. 処理された行数の合計」等は空白であり、🔗という状態になっているため、更新も瞬時に終わっています。前述の通り、「Sales_PPU」と「Sales_Pro」は異なるワークスペースにあるため、Dataflow_PPUは「スキップ」処理扱いとなり、一番下の同じワークスペースCにある「リンクされたエンティティ」だけが自動更新されます。
実際の運用において、「Dataflow_Pro」や「Datalow_PPU」（ワークスペースB）などは定期的に更新されるステージングデータフローとなるため、ここでのデータ更新（一次更新）をスケジュールしておき、その後の変換用データフローが以下のいずれかになるかによって、追加で更新スケジュールの設定が必要かどうかが決まってきます。
1の場合、更新スケジュールの設定は必要ありませんが、2の場合はさらに設定が必要となります。したがって、下図のように手動で更新を行って初めて、データが最新の状態で保たれることになります。
ここで最も混乱を招くのが「05. 状態の更新」における「スキップ」です。ここでの「スキップ」とは、前段階でのデータの更新が必要ないため、この段階では何も処理が行われなかったことを意味しています。しかし、異なるワークスペースから行われた処理であるため、「Sales_PPU」と「Sales_Pro」は実際には40万行のデータとして取得できるようになり、更新が正常に終わったことを意味しています（下図）。
まとめ
今回は「リンクされたエンティティ」の更新について、更新履歴を見ながら話を進めました。ポイントは、
「リンクされたエンティティ」がワークスペースをまたぐ場合、自動更新 or 手動/スケジュール更新
を仕掛けることが必要になる、ということです。「リンクされたエンティティ」は更新が瞬時になる特徴があることから、同じワークスペース or 異なるワークスペースに関わらず、（ステージングデータフローの後にある）変換用データフローをスケジュール更新しておくと安心するでしょう。
次回は「計算されたエンティティ」及びクエリの更新結果について、実例を交えながら見ていきたいと思います。
