Power BIのインポートとDirect Queryの違いを知っていますか？データの取りこみ方の違いを解説します！
#Power BI #違い #Direct Query #インポート
Power BIのデータソースの設定方法は基本的にはインポートとDirect Queryの2種類があります。
ライブ接続は、また別の機会にしておきましょう。
今回はその2つについて、それぞれの特徴と実際に使っていて困ったことなどをご紹介します。
ぶっちゃけインポートとDirect Queryはどう使い分ければいいの？
インポートとDirect Queryの使い分けはとても単純で、以下の観点で見分けることが可能です。
- その場で新しい指標やテーブルの追加を行っていくなど、より自由に様々な観点から分析を進めていきたい
- 自由度は多少犠牲にしてもいいのでリアルタイム性が欲しい
前者の自由度が欲しいならインポート、後者のリアルタイム性を重視するのであればDirect Queryとなります。
それでは、両者にどのような違いがあるのかを見ていきましょう。
インポートはデータを抱え込む Direct Queryはデータを呼び出す
Power BIのデータソース設計の考え方としては、基本的には自分のところデータを抱え込むインポートが基本になっています。
基本的な流れとしては、Power Queryでデータの加工法を設定してファイル内に取り込み、それを可視化するのです。
そうなると問題となるのはデータの鮮度。
最後にPower BI内にデータを取り込んだのが昨日だとすると、今時点での最新売上データが見たくても無理というのが弱点です。
別のページ（Power BIのライセンス 無料版とPro、Premiumの違いは？ライセンスを選ぶときのポイントを解説！）で紹介していますが、Power BI Proだと1日8回、Power BI Premiumだと1日48回までの更新が可能ですが、それでもリアルタイムとは言えません。
そこで登場するのがDirect Queryという方法です。
これは各データベースに対して、ビジュアルを表示するために必要な情報を問い合わせて受け取る方式で、計算処理をデータベースに任せているのが特徴です。
そのため、Power BI自体でデータを抱えることなく、データベースがその時点でもっている情報を計算して出力することができます。その処理が行われるのがレポートが開かれたタイミングということで、ほぼほぼリアルタイムと呼べるものが実現できるわけです。
そうなると、Direct Queryの方が便利そうですよね。
ところが、Direct Queryの場合だと気をつけておかないといけないことがあるのです。
Direct Queryは複雑な処理が弱い
Direct Queryの弱み①：とにかく重い
インポートであれば1秒もかからず表示されるものに対して5秒以上待たされるなんてことが普通に発生します。
Direct Queryを使うときのコツとしては、とにかく通常のPower BIで勧めている明細レベル全てを取り込むのではなく、可能な限りで集計した状態でデータを持っておくこと。
データベース側である程度の計算処理を済ませてしまって、Power BI側においてはそれを表示させる程度に止めることが重要です。
Direct Queryの弱み②：列を追加して、それを使ってリレーションをつなぐとエラーが出る
これは特定の環境でしか試していないので、他だと大丈夫なのかもしれません。
Power BIって複合キーが使えないのです。詳しい方はこれで何が問題かお察し頂けた方もいるかもしれません。
システムによっては複合キーが当たり前で、1列ではレコードが特定できないということが多々あるかと思います。
Power BIはそれができないので、複合キーを全て結合した列を追加して、それをリレーションで結びます。
ところが、です。
Direct Queryでそれをやろうとするとエラーが発生。
原因は後述しますが、Power BI側で何とかしようとすると無理が出てしまうようです。
Direct Queryの弱み③：DATEADD関数など使えない関数がある
Direct Queryで取り込んだテーブルについては、メジャーの使用に制限がかかっています。実はこれ、オプションから無制限のメジャーを許可することによって解除できるのですが、結局エラーが発生してしまうということがあります。
Direct Queryを使うときには、使える数式の中で何とか表現を試みるのが一つ。もう一つは数式を駆使して代用をするのが一つです。
DATEADD関数でいうならば、フィルターに日付使って無理やり表現することも不可能ではありません（かなりぐちゃぐちゃな関数になりますが）。
原因はDAXからSQLへの翻訳にあり
上に出したのはあくまでも例になるのですが、全ての原因が一つに集約されます。
それは、計算処理を接続先のデータベースに投げるにあたって、DAXで計算しようとしているのを無理やりSQLに翻訳しているということです。
DAXとはData Analysis Expressionsの略で、BIのような多様な分析に対応させるために高速な処理を可能な構造をとっています。
そのために、SQLに直すとかなり複雑になってしまうものがあり、それがエラーとなって帰ってきてしまうのです。
どうしても単純な数式にせざるを得ないということがわかります。
Direct Queryを使うために必要な準備
Direct Queryを使うために必要な準備①：Direct Queryとして接続可能なデータソースを調べる
まず、そもそもDirect Queryを使うことのできるデータソースであるかの確認が必要です。
接続可能なデータソースについてはMicrosoftのサイトから確認ができます（https://docs.microsoft.com/ja-jp/power-bi/desktop-directquery-data-sources）。
Direct Queryを使うために必要な準備②：接続先のデータソースの先でテーブル・ビューをつくることのできる人材を確保する
Direct Queryで呼び出したいテーブル群が複雑な構造をしていたり、レコード数が非常に多かったりすると時間がかかってしまう原因になることから、テーブル・ビューを追加することによってより単純化する必要が出てきます。
そうなると必要になるのが、そのテーブル・ビューをつくることのできる人材です。
Power BIはビジネス部門から導入することができるツールであるため、実はここがネックとなることが多いと感じています。
システム部門主導に導入するということだったらあまり問題にならないのですが、気を付けておきたい点です。
Direct Queryを使うために必要な準備③：分析に使うテーブルについてのビューをつくる
一つには、複合キーしかない場合については単一のキーをつくるために使用しますが、それ以外でも、極力Power BI側での演算を除外することによって、DAXからSQLへの翻訳が単純になるようにしておく必要があります。
項目を引っ張ってくるだけで可視化ができるまでのおぜん立てができるのであれば速度はあげられますが、Power BIの自由に分析するという長所を潰してしまう事にもなります。
使用する人の希望に合わせてどの程度まで作りこみをすべきかを検討していく必要があります。
ここまでインポートとDirect Queryの違いについてみてきました。
とはいえ、自分の会社ではどちらを適用したらいいのかわからない方もいらっしゃるかと思います。
弊社ではそういったご相談に対しても対応が可能ですので、是非お気軽にお問い合わせください。
＜Power BIハンズオンセミナー＞
弊社ではPower BIをはじめとするさまざまな無料オンラインセミナーを実施しています！
＞＞セミナー一覧はこちら
＜PowerBIの入門書を発売中！＞
弊社ではPower BIの導入から基本的な使い方・活用方法の基礎などをわかりやすく解説した書籍も販売しています。
＞＞目次も公開中！書籍の詳細はこちら
