テクテク日記

テクテク=テクノロジー&一歩ずつ(テクテク)

Jeffrey WangによるDAXエンジンの解説①

Power BI CATチームのKasperさんのYoutubeチャネルにPower BI DAXエンジンの開発者であるJeffrey Wangさんが登場しました。こちら、デモ等はないですが、DAXの開発者による解説ということで非常に興味深い内容でした。対談は90分と長く、字幕も英語しかないのでコアなものについては記事にまとめてみました。DAXが好きな人、DAXpert*1な人、どちらも楽しめるのではと思います。ちょっと長くなるので複数回に分けて記載します。

KasperさんとJeffreyさん

KasperさんはPower BI CATのスペシャリストチーム*2を率いており、DAXpertのPhil SeamarkさんやPower BI Dev CampのTedさん、Dataverse + Power BIのスペシャリストのScottさん、可視化のプロであるMiguel Myersさんと同じチームになります。

一方でJeffreyさんは2004年からMicrosoftのBIテクノロジーであるMDXDAX等の言語を開発するエンジニアであり、今回のゲスト。

DAXに関する質疑応答

1. MDX vs DAX、そしてDAXをデザインした理由とは?

当時(2000年後半)、TableauがセルフサービスBI*3(以降、SSBI)の世界で非常に成功していたことが、MDXからDAXへの移行のきっかけの1つとなった。

DAXとMDXの違いは以下の2つである。

  1. SSBIの市場にフォーカスしていくことが決まっていたことが最初の理由
    TableauはSSBIマーケットで非常に成功していたことから、DAXシンプルをテーマとしている。一方で、MDXを学ぼうとした場合、言語そのものについて学ぶ前に、MDXのコンセプト - 多次元モデル(Cube、ディメンション、メンバー等)を知る必要があり、DAXExcelのような感覚ですぐに使用できる(リレーションシップに慣れている人にとっては非常に入りやすい言語である)。総じて、DAXはMDXよりもシンプルである。
  2. MDXに関するパフォーマンスの問題
    MDXについて、少しの変更を加えただけで全く異なるパフォーマンスになるため、多くの人が理解できずにいた。MDX時代ではセル・バイ・セル(CBC)モードとブロックモードがあり、最初はCBCモードからスタートしたが、後からブロックモードが加わった。
    MDXにあって、DAXにない機能もあるが、こちらは意図的にそうしている。例えば、Stop and GoというモードがMDXにあるが、こちらはある評価式をある程度展開した後、展開された結果が次へ展開するかどうかを決めるモード(Expression Treeにおいてサブツリーを展開していくかどうかというモード)。一方、DAXはブロックモードのみだけでなく、Stop & Goを全く採用しておらず、数式を全体としてとらえて評価していくことになるため、MDXでは無理だったパフォーマンスの最適化に向けて様々な施策を打つことができた。

なお、MDXの開発投資は殆ど行われていないが、現在もExcel Power PivotがMDXテクノロジーを採用していることから、MDXがなくなったわけではない。ただ、DAXに多くの新しい機能が追加されるようになり、Power BIのネイティブ言語がDAXであるため、投資の殆どがそちらに向けられるようになっている。

2. DAXはVariable(変数)やIterator(反復子)がなかった時代と比べるとかなり複雑になってきたが、それについてどう思うか?

個人的にはVariableというネーミングは非常によろしくないのは認めるが、そのネーミングを変更する時期にはなっていない(本当は「コンスタント」という名前が正しいのは知っているが・・)。しかし、Variableによって人々のDAXの書き方が大きく変わり、パフォーマンスの改善はもとより、ステップ別の実行を見ることができるようになったのは大きい。

3. DAXはより複雑になってきており、DAXがシンプルである側面を見落としている人が多いのも事実である。これについてどう思うか?

SSBIの世界では、一夜にして全員がエキスパートになることを期待するのは無理でしょう。パターンがあるとすれば、データ量が多く、複雑なビジネス上の問題を解決するために専門的にコンサルを行う人が書くDAXと、そうではなく、多くの場合において簡単なDAXで事足りるSSBIソリューションで仕事が完結する人たちがいる。後者の場合、データ量も少ないでしょうし、DAXの最適化について考慮する必要もないでしょう。重要なのは自分の仕事内容に合わせて自分のペースで勉強することである。

4. DAXを関数言語(Excelのよう)にした理由は?デザインに関する考え方は?

DAXを開発した当時(2010年頃)はPower BIが存在していなかったこともあり、Excelのようにするのが要求であった。Excel Power Pivotがクライアントであったので、最終的にはExcelに融合していくことも考慮していたため、互換性を重要視していた。その証拠に、SUMやSUMX等がその余韻である。

5. Power PivotはExcelユーザー向けだったが、Power Viewが登場し、そこからパフォーマンスを改善するためにVariableが登場した。DAXの構文自体が変わってきたわけですよね?

DAX関数言語として使われるだけでなく、クエリ言語としても使用する目的があった。最初の試みは、DAXを使って可能な限り、リレーショナルな形でクエリ言語として活用したかった。後になって、DirectQueryが深刻なパフォーマンス問題の1つとして顕在化した。

そこで原点のMDXに戻ってSQLアプローチとパフォーマンスを比較した結果、ミックスアプローチとしてスーパーDAXプロジェクト*4が開始されるようになった。そこからVariableが登場し、根本的なパフォーマンス問題を解決するようになったが、当時は依然としてPower Pivotが使われており、加えてパフォーマンス以外にリリースサイクルやマス顧客へ届けるためのアプローチといった別の問題が存在していた。

そこからPower BIが登場をしたわけだが、Microsoftは非常にラッキーだった。なぜならば、Power BIに関する根本的なテクノロジーは、既に存在しており、Power BI Desktopというソフトウェア自体を開発する必要があったにせよ、テクノロジーをゼロから作る必要はなかった。

6. DAXエンジンをデザインする上で最もハードな事は何だったか?

これまで他のクライアントツールで人々は分析作業を行ってきた。新しいものを作り出すときに、人々が昔どのような関数を使っていたか、人気があるものをピックアップして最初は構築していけばよかったので、この部分についてはそれほど難しいものもなかった。

難しいのはどうやってそれを実現し、パフォーマンスを最適なものにしていくかであったDAXは極端にシンプルだったので、人々はそれを信じさえしなかった。開発チームが多大な投資を行った結果、殆どのDAX関数は、他の関数と一緒に使えることが特徴であり、その関数自体で完結するような事は稀である。

7. 最近、DAX関数にOFFSET関数が登場し、いろんな可能性が出てきた。DAX 3.0といった考え方に変える時か?

SQLが登場して、その17年後にWindow関数が登場した。Window関数についてはSQLを使うことを想定していないアナリストなどが当時から多く使っていたことに驚いた。行を跨ぐ計算を行うことが出来るため、普通のSQLステートメントで手間がかかる計算でも、Window関数を使えば簡単に実現できる。

同様にDAXは同じ行同士を計算させるのは得意だが、行を跨ぐ計算は苦手である。そこでOFFSET関数が第一弾として、DAXのWindow関数ファミリーの一員として登場した。なお、OFFSET関数はパフォーマンス的にも悪くないことが特徴である。

8. DAXに関するBlogに期待している人も多いと思うが、Blogをもっと書いてくれないか?

昔はProgramマネジャーだったけど、今はもうそうではないので時間ができたから書くかもしれない。現在は、多くのエンドユーザーと近い人がDAX関数について書いてるので、そうではない自分があれこれ書くつもりはないが、いくつかのDAX関数について誤解を持っているようなケースが見受けられるので、それらについては今後触れていくかもしれない。

*1:DAX + Expertの造語

*2:Power BI CATではジェネラリストチームとスペシャリストチームに分かれており、スペシャリストはいわゆるPBIに関する開発者のスキルを持っている人たちの集まり。ちなみに私はジェネラリストチームに所属しています

*3:Self-Service BI: SSBI。ビジネスユーザーがIT部門の負担を最小化し、自分たちでデータを抽出・変換し、BIソリューションを実現する現在主流のBI

*4:詳細は述べられなかったが、社内でDAXのパフォーマンス問題を改善していくプロジェクトと思われる