データフロー(Power Query Online)⑥_Premium時の運用D

拡張コンピューティングエンジンデータフローシリーズの最後として、実際にデータフローの運用シナリオについて見ていきたいと思います。複数の選択肢があると思いますが、どのように選択するかはライセンスの種類や企業内部のポリシーに従うものとなります。なお、本記事で紹介する例はあくまで参考程度にしていただき、実際の運用はこれまでのシリーズを参考にベストな手法を取って頂くのが良いかと思います。

実際の運用シナリオ
運用シナリオの例
最後に

実際の運用シナリオ

実際の運用シナリオについて、実はMicrosoftの公式Docsに記載されています。順番的にこちらを良く読んでもらったほうが分かりやすいかもしれませんが、具体的な事例がないので、本ブログがその役割を果たせればと思います。

learn.microsoft.com

上記公式を少し要約しますと以下の通りになります。

データフローはエンタープライズに重点を置いたソリューションであり、組織内でデータの共有、再利用、利用者が新たに開発を行うコストを下げるもの
Pro環境での利用は小規模、基本的にはPPUやPremium環境での利用が望ましい
容量とライセンス（Free, Pro, PPU）の違いがあるため、よく考慮してから運用を行うこと
5,000人超のユーザーはPremium容量、それ以下の場合はPPU + Proで対応
バックエンド（開発用）ワークスペースとユーザーワークスペース（実運用）の2つを構築するパターンにおいて、データフローを活用するエンドユーザーは後者にアクセスする
ワークスペース別にデータフローの消費パターンを決めことるで適切なデータガバナンスを行うことが可能。例えば、全世界のデータ（Global Sales Workspace）にアクセスし、地域別（US Sales Workspace, UK Sales Workspace, Japan Sales Workspace等）にフィルターされたデータフローの活用、消費用のワークスペースにて「リンクされたエンティティ」と「計算されたエンティティ」に接続する等
シナリオ図にあるのは、データフローを使ってPower BIに関する"Happy Path"*1に関する説明
ステージング、変換、最終データフローという概念をベースにベストプラクティスに従うこと（下図ハイライト部分）
1つのワークスペースにデータフローを全て格納するのではなく、複数のワークスペースを利用すること
- ワークスペース1: 別名「バックエンドワークスペース」であり、開発用のワークスペース。通常、上図のstagingとtransformationデータフローの両方を含む。データフローの作成者はデータガバナンスを行うチーム（IT, CoE等）であり、ワークスペースの権限は「管理者」「メンバー」「共同作成者」のいずれかをアサイン
- ワークスペース2: 別名「ユーザーワークスペース」であり、ワークスペース1のデータの出力先。セルフサービスアナリスト、Power BIヘビーユーザー、モデリング担当者等のペルソナが対象であり、ワークスペース権限は「ビューアー」をアサイン
その他
- 拡張コンピューティングエンジンに対する理解
- データフローとデータセットの更新（増分更新）
- Azure Data Lake Storage Gen2（Bring Your Own Storage）の活用*2
- On-premise Data Gatewayの設定
- アクティビティの監視

以上がMicrosoftが推奨するデータフローの活用に際して留意すべき点、ベストプラクティス等となります。

運用シナリオの例

ここまでコンパクトにまとめていますが、実はこれらをベースに、自社に最も適したシナリオを作っていくのがセオリーです。デスクトップ版の Power Query は、その先にあるデータモデルを構築するために存在しますが、データフロー（Power Query Online）は、誰でもデータを共有できる環境を構築することができるため、自由度が高くなります。

以下挙げるユースケースは上述したベストプラクティスを含む、いくつかのやり方となります。

ユースケース①: データが変化しない

Power BIに関するトレーニングやサンプルデータを使ってデモを行う場合にメインで使用するケース。自作サンプルデータやMicrosoft等が提供しているサンプルデータ*3等、デモに使用しやすいように加工したものがこれに当たります（以下いくつか紹介しておきます）。

DP-900T00A-Azure-Data-Fundamentals（CSV）
Monthly Inventory Sales（Excel and CSV: ヘッダーは日本語）
OData Sample（ODataフィードコネクタを使用）
Adventure Works Sample Database（SQLサーバー、SSMS必要）
Contoso Retail DWH（同上）

※その他pbixを含むサンプルデータは下記石川さんの記事が分かりやすい
Power BIの各種サンプルデータ - Qiita

これらのデータはExcelやCSV、ODataフィードなどの形式であれば、データフローに入れておくと、データを取得して変換するプロセスが簡単になると思います。しかし、最後の2つはSQLデータソースとなるため、クラウド上にデータを移行する場合に限り、検討する価値があるでしょう。SQLサーバーにあるデータは高度に最適化されているため、デモを行う場合には、データをローカルサーバーに格納する方が、パフォーマンスが高くなる可能性があります。

用途別にデータソースをデータフローに格納しておくことで、様々なデモに対応することが可能となります。この方法の特徴としては、データが変更されないため、自動更新の設定をする必要がないことが挙げられます。また、Power BIやExcelなどのクライアントから各データフローにアクセスする際には、すでに変換されたデータが使用されるため、モデリングの前準備が完了していることがメリットとして挙げられます。

ユースケース②: モデリング専用データフロー

ユースケース①は個人を対象とした使い方でしたが、ユースケース②はそれをさらに拡張した使い方として考えることができます。すなわち、異なるソースからデータフローに単純にデータを持ってくるだけでなく、そのデータフロー自体が1つのデータモデルとして構築できるようにしておくことです。具体的には、Power BI Desktopでモデリングを行う際に必要なデータ（テーブル）が、そのデータフローから全て揃っている状態となります。これにより、例えば財務分析、在庫・売上分析、市場調査などのレポート構築を目的とする場合には、そのサブジェクトに関するモデリングに必要なデータを容易に見つけることができます。

この方法は個人使用に限定される可能性が高いため、組織で活用するためには拡張することが困難になるかもしれません。しかし、このような考え方から始めることで、徐々に必要なニーズに応えるためのアーキテクチャを構築していくことができると思います。

ユースケース③: 再利用可能データフロー

このシナリオは、本来のデータフローの活用シナリオであり、組織でスケールさせていくためには、アーキテクチャを考えていく必要があります。このシナリオでは、ソースデータが定期的に変化し、組織内で共通化できそうなデータをデータフローに格納していくことになります。

例えば、在庫データが必要なチームや仕入データが必要なチームに共通するデータ（例: 日付マスタや商品マスタ等）をデータフローで構築しておくことで、単一のデータソースを参照することができ、データ品質の維持に貢献できます。

通常であれば、チーム内の誰かが複雑なETL作業を行わなければなりませんが、データフローを使用することで、組織活用（エンタープライズ型）セルフサービスとしても機能します。データオーナーシップが必要になりますが、データエンジニアリングを行うチームやBI開発者がデータフローのメンテナンスを行うと良いでしょう。

複数のユーザーがアクセスできるデータ基盤となりますので、アーキテクチャが複雑になってきます。特にエンタープライズ規模のデータフローの構築については下記の項目を良く理解する必要があります。

データの鮮度に対するリクエスト
ソースの種類（オンプレミス or クラウド）
1回あたりの更新時間と1日の更新頻度
高度な更新手法（増分更新等）
Power BI ProとPower BI Premiumのデータフローで利用できる機能の違い（過去記事参照）
トラブルシューティングのやり方（更新失敗時の更新履歴のチェック、サポートチケットの発行等）
CPUパフォーマンスの確認（Power BI Premium Capacity利用限定）
Metrics Appの利用
データフローの昇格と認定を行うことで、Discoverability（発見性）を高める

この記事では、詳しい説明は省略しますが、「CPUパフォーマンスの確認」についてはPower BI Premiumにおいて各アイテム（アーティファクト）別にリソース使用率をモニタリングし、CPU使用率が高いアイテムが特定のデータフローであるかどうかを確認することが重要となります。

ユースケース④: クリエティブな使い方

データフローのクリエティブな使い方の1つとして、1データフローに1つのテーブルだけを格納するやり方があります。Christopher WagnerさんのYouTubeですが、非常にユニークな構築法が紹介されていました。

イメージは下図の通りとなります。

左側がこのユースケースの例ですが、私自身はこのようなクエリを作成したことがないため、懐疑的な部分もありますが、メリットを見ると、確かにうまく機能する可能性があると思います。データフローの昇格と認定を行うことで、ユーザーからすると必要なデータに効率よくアクセスできる可能性が高いかもしれません。

当然ですが、これらのクエリを作成するためには、ステージングクエリが必要になる場合もあります。しかし、更新スケジュールを適切に設定することで、最終的なクエリが各データフロー自体になるため、ユーザービリティが非常に高いと言えます。

デバッグの容易さ
データの発見しやすさ
クエリパフォーマンス

上記3つを全てカバーしていることがポイントでしょうか。

デメリットとしては、

データオーナーがこれらのデータフローを1つずつ作成する必要がある
モデリングに必要なデータを探す必要がある

ことが挙げられます。同じクエリを1つのデータフローに格納する方法に比べて手間がかかるため、上記メリットとのトレードオフとなります。

最後に

データフローは、クラウド上で行うセルフサービスETL*4と呼ばれるものです。デスクトップ版のPower Queryと同じ使い勝手ですが、個人と組織、スケールなどの点で大きく異なります。Microsoftはデータ基盤に関して、データフローをデータインテグレーションという分野で最も重要な1つとして投資しており、今後発表される新しい機能にも搭載されることが決まっています。

少しネタバレになりますが、セルフサービスBIを起点とするユーザーで、エンタープライズグレードのBI構築に携わる方は、今のうちにデータフローの使い方に慣れておくことをお勧めします。

*1:データフローに関するEnd-to-endシナリオで、データの取得・変換からPower BIのデータモデルへの読み込みに際して行う設定等に対する説明

*2:注意点

*3:pbixファイルではなく、生データのほう

*4:ユーザーがアプリケーションのUIを頼りに、ローコードベースで自分たちで好きなデータを取得・変換するプロセス