Premium キャパシティにない Power BI データフローでもそこそこいい感じにつかえるけれども、Premium な機能も使ってみる。Power BI Premium では、SharePoint Online サイトとか組織内のWebアプリにレポートを埋め込んで共有したり、Power BI アプリを介しすべての Power BI アカウントに向けて共有したり、ライセンス周りに大きなアドバンテージがあったのだけど、Power BI データフローでそのコスト差が埋まってきた感じがしないでもない。
- リンクされたエンティティによるデータフローの更新
- エンティティの増分更新
- 専用に割り当てられたリソースによる並列実行
ひとまず、これら3点について使い方や気になった点のまとめ。
他に注目な Power BI データフローに組み込まれた Machine learning ってのもあるのだけど、まだ先の話(CY '19 - Spring)なのでそっ閉じ。Azure integration はもう少ししたらかな。
リンクされたエンティティによるデータフローの更新
Power BI のデータフロー間でエンティティをリンクする (プレビュー)
プレビューですし、リンクつけておくなど。
同じワークスペースの中でエンティティを参照するデータフローを何段か作った。これがリンクされたエンティティなのだけど、ここでは、計算されたエンティティと他データソースなどを利用するエンティティを追加していない。簡単に試すだけなので。
Gen1からふたつに分岐してそれぞれリンクされたエンティティを持つデータフローを用意した状態。で、それぞれ個別に用意したので "最終更新"が異なっているのです。
Gen1を更新、ここではオンデマンド更新をすると Gen1を参照 もしくは データリネージュ的な子孫となるデータフローも更新されるのです。すべてがリンクされたエンティティなので更新に時間を要することもなく"最終更新" 時間が一致してる。途中のデータフローに計算されたエンティティなど他エンティティが存在したときもう少し時間が経過することになる。
更新履歴を参照すると "リンクされたソース" によるデータフローの更新であったことが記録される。
データフローの更新でさらにデータフローを更新することができるので、データリネージュの維持が比較的簡単にできるようになっているっていうこと。で、途中のデータフローに含まれるエンティティがさらにリンクされたエンティティで参照されているときも別途の動作をすると。
- データリネージュが循環参照
- ホップ数が5を超える
ときにはこの更新機能は失敗に終わる。で、更新を伝搬させないためには、リンクされたエンティティの読み込みを無効にすればよい。
Power BI のデータフロー間でエンティティをリンクする (プレビュー) - データフローからレポートを表示する場合のアクセス許可
ここわかりにくかったのだけど、こういうこと。
他ワークスペースからリンクしたエンティティ用意されているとき
リンク元のワークスペースに参加していない、つまり、データフローを参照することができないとき、リンクされたエンティティを参照することはできない。ただし、計算されたエンティティを利用することは可能。
リンク元のワークスペースに参加している、つまり、ソースのデータフローを参照できる場合、リンクされたエンティティも利用することができる。
エンティティの増分更新
データセットでも利用できる増分更新と変わらないので難しいことはない。いわゆる UPSERT ではない。で、エンティティごとの設定なのです。
フィルタに利用される列
増分であることのフィルター条件に利用されるのは、日付/時刻 型 なので、 Power Query でいうところの DateTime.Type に変換しておく必要がある。
保存される行
数値 : 1 ~ 120
単位 : 年 / 四半期 / 月 / 日
更新される行
数値 : 1 ~ 120
単位 : 年 / 四半期 / 月 / 日 ※保存される行で指定した期間単位より短い期間単位であること
en-us 以外の環境だと表示がよろしくないけれどもこんな感じに。
これらの設定を保存すると、このデータフローが次に更新されるときに、過去 3 年間 のデータがデータフロー ストレージに読み込まれます。以降の更新では、過去 5 日間 に変更されたデータのみが更新されます。
When you save these settings, data from the past 3 years will be loaded to your dataflow storage the next time this dataflow is refreshed. Subsequent refreshes will update only data that's changed in the past 5 days.
データ変更の検出
フィルタに使用する列をもうひとつ追加。更新対象のうち更新対象範囲内でさらに更新されたと考えられる行のみを追加するっていうこと。使いどころはよーく考えておけばよいか。
完了期間のみ更新
更新される行の期間が "月" であるとき、当月1日から当日までを含めるか否か。
増分は差し変わる感じ
"更新"というよりは差し替えられる感じ。
データフローのストレージである Azure Data Lake Storage Gen2 にどのように保存されているかは、model.json をみるととてもよくわかる。
- できるだけファイル数が少なくなるように構成(パーティション)される
- 増分は "日" 単位 もしくは 更新される行で指定した単位
- データフロー更新時、保存される行で指定した単位まで適宜おまとめ
- 保存する行で指定した範囲を超えるとき、ファイル単位(パーティション)でさよなら
Fiscal Year っぽい対応には 四半期とか使う感じかな。とはいえデータフローだけで対応する必要はないのだけど。
専用に割り当てられたリソースによる並列実行
Power BI でのセルフサービスのデータ準備 (プレビュー) - Power BI Premium でデータフロー機能
可能であればエンティティはパラレルで処理されていくって話。Premium じゃないキャパシティは共有リソースなので、騒々しいご近所さんに影響を受ける可能性もあってどうしても時間を要すると。
例えば、Azure SQL Database に いくつかのエンティティが抽出を試みるとき、ここでは4つすべてがパラレルで抽出⇒変換まで実行され素早く更新が完了した。
なんでこんなに差がつくのさって感じではあるんだけど、共有リソースなので仕方がない。占有で利用できるリソースが割り当てられるのが Premium なキャパシティであるから。
