知っている人は知っていますが、Power BIのカスタムコネクタにDr.Sumが対応しました。Dr.SumはWingArc1st社のデータ分析基盤（DWH）ですが、日系ベンダーにおいては相応に人気があるようです。
Dr.SumにPower BIを繋げる機会をもらいましたので、このブログではDr.Sumの使用感も含め、まとめてみました。
Dr.SumとPower BIの連携
Dr.Sumはデータ分析エンジンであり、SQLサーバーのようなものとなります。機能的な部分や使い勝手は異なるものので、SQLを発行してデータベースを操作するという点においてはほぼ同じと考えています。
Power BIとの連携について、WingArc1st社いわく、
Dr.Sumから直接Power BIに繋げたい顧客ニーズが高かった
ことが背景にあるようです。今まではODBC接続、あるいはCSV/ExcelへエクスポートしてPower BIで接続していましたが、ユーザーの利便性並びに満足度の向上を満たすため、当社はカスタムコネクタを開発し、2022年5月から提供が始まりました。
Power BIに接続する手順は冒頭のブログ及び公式サイトを参照して頂きたいのですが、顧客のニーズに真摯に応える姿勢は非常に素晴らしいと感じています。
Power BIへの読込速度
Power BIへの読込速度を試してみましたので、結果を共有しておきたいと思います。データソース及び前提条件は以下の通り。
- データソース
SQLサーバー vs Dr.Sum vs CSV - テストデータ
ContosoRetailDWのFactOnlineSales
① SQLサーバー: ContosoRetailDW
② Dr.Sum: 下記③（CSV）から読み込んだデータ
③ CSV: ContosoRertailDWからエクスポートしたFactOnlineSales - データ量
約1,300万行 × 13列
SQLサーバーやCSVは割愛しますが、Dr.Sumにデータを読み込んだ場合、以下のようなテーブルとして格納されます（読み込みについては後述）。
Power BIで初めてDr.Sumに接続する場合は冒頭のブログ・公式サイトを参考して頂きたいのですが、成功すると以下のように、データを取得できます。
ここからはデータをPower BIデータモデルへ読み込みを行いますが、ロード時間のパフォーマンスを測定するため、同じチームのPhil氏が作ったツールを使います。
解説は上記ページ（英語）にありますので、詳細は割愛しますが、前提として
- SQL Server Profiler（単体はこちら）
SSMS（クリックするとダウンロードが始まる）がインストールされていればOK - DAX Studio
localhostナンバーの取得
の2つがインストールされている必要があります。Phil氏が作ったTemplateはテーブル名に余計なコードが入っていますので、テーブル名だけで試したい方は下記よりファイルをダウンロードしておいてください。
サンプルデータも下記置いておきます。
上記2つをダウンロードし、Sample Dataを適宜フォルダに解凍し、Analyze my Refresh.pbixを開きます。なお、Sample DataをCドライブの直下にTempというフォルダに解凍しておくと、下記パラメータ（ファイルパス）を変更せずに済みます。
※ サインインしていない状態でAnalyze my Refresh.pbixを開くと、「このファイルには、秘密度ラベルが適用されています」という表示が出現しますが、無視して頂いてOKです
- パラメータを変更する（C:\TempにSample Dataを解凍しなかった場合）
Power Queryエディタを立ち上げ、以下の順番で解凍したxmlファイルのパスを記入していきます
- 閉じて適用をクリックし、データが更新されていることを確認
これでテスト結果を見ることができるようになりましたが、SpeedTest.xmlを選択すると、SQLサーバー vs Dr.Sum vs CSVのそれぞれの結果を可視化できます。
以下、各項目についての解説です。なお、このxmlファイルはPower BI Desktopで3つ異なるデータソース（SQLサーバー、Dr.Sum、CSV）から同じデータ量をPower BIデータモデルに読み込んだ時のパフォーマンスとなります。xml内には実際のデータは入っておらず、SQL Server Profilerで取得された更新プロセスに関する情報のみが入っています（実際のやり方はPhil氏のブログを参照）。
- ExecuteSQL
データソースの速さを示すもので、クエリを送信してから最初の行を受信するまでの時間を表す。図では分かりにくいですが、ソースとして3つとも早く、全て2秒となっています（※下記追記あり） - Process
データソースからPower BIのAnalysis Services（AS）インスタンスに流れ込み、ASがデータを受信・処理・エンコーディング・圧縮する速度 - Object Name
クエリ（テーブル）名 - Rows Read
読み込んだ行数 - Duration Measure (Seconds)
① + ②の合計時間（秒） - Rows per second
1秒当たりの読込行数（数値が大きいほど、読込パフォーマンスが良い） - Performance Comparison
一番遅いデータソース（今回の場合、CSV）に対して、他のデータソースが何倍の速さであったかを示す相対指標（結果： SQLは3.2倍、Dr.Sumは1.3倍速かった）
この結果から分かる通り、同じデータ量のデータを同時にロードした場合、SQLサーバーのパフォーマンスが最も高く、CSVの約3倍以上のパフォーマンスとなりました。一方で、Dr.SumもCSVで読み込んだ場合の1.3倍速かったことが分かりました。念の為、テストデバイスのスペックも記載しておきます。
SQLのパフォーマンスが最も高い理由として、どうやらSQLはカートリッジ方式による接続手法で接続しているため、他のMコネクタよりもパフォーマンスが高いという（by Phil氏）。そして、試したことはないですが、Oracle, Teradata, Redshift等もこれに相当するといいます。なお、Mベースのコネクタは常に一定のオーバーヘッドが発生するようですが、少なくとも今回の検証では3つのソースは非常に速いということが分かっています。
ここで質問が3つほど出てきます。
- ExecuteSQLの結果は全てにおいて同じ？（全て2秒）
- 3つのクエリを別々に実行したら、どうなるのか？
- Dr.Sumはデータベースなので、Query Foldingが効いている？
まず2を見ていくと、1と2の両方について解決できそうです。別々にクエリを実行したところ、以下の結果となりました。
読みにくいのでテーブルでまとめますと以下になります。
同時読込Durationは3つのクエリを同時に実行した際の結果、それ以外は1つずつ実行した結果をまとめたものとなります。ここで分かることは、
同時実行した場合よりも、1つずつ実行したほうが約30%の時間削減
に繋がるということです。通常、スタースキーマを構築する時、FactOnlineSalesは他のクエリ（Dimテーブル）と一緒に実行されますので、他のクエリのデータ量が少ない場合、SQL（36秒）、Dr.Sum（86秒）、CSV（122秒）がもしかすると実際の数値に近いかもしれません。
一方で、上表には記載していませんが、Performance Comparisonの数値はほぼ同時実行時と同じ数値となりました。いずれにしても、パフォーマンスで言えば、同時実行も単独実行も同じ、SQL > Dr.Sum > CSVという結果になりました。
質問1に戻りますが、同時実行では全て2秒であったExecuteSQLは、SQLとCSVではオーバーヘッドなし（0秒）、Dr.Sumだけ1秒だけ掛かっています。殆ど差がないので誤差の世界かもしれませんが、同時実行するとこの1秒が2秒なるようです（※詳細な仕組みは不明）。
質問3はクエリエディタを見る必要がありますが、しっかりQuery Foldingが効いてるようです。この辺りはSQLということで、共通しているようですね。
Query FoldingはPower Queryの特徴の1つで、ソースシステム（SQLサーバー、Dr.Sum等）で処理できる作業はソース側で処理させる（ソース側にプッシュバックする）、これによってクエリ処理、データモデルへのロード等が最適化される、というテクノロジーになりますが、Power QueryによるETLプロセスにおいて最も重要な概念の1つとなります。
なお、CSVはデータソースとしてExcelの5～7倍程度早く、ソースとしては速いほうですが、Dr.Sumは更にそれを上回ったようです。私の検証環境（Dr.Sumが自分のPCにインストールされている）ではこのようになりましたが、全てがこの通りとは限りませんので、CSVの抽出パフォーマンスと逆転してしまった、という場合でも驚く必要はないでしょう。
Power BI with Dr.Sum ②に続きます
