この記事はMicrosoft Power BI Advent Calendar 2019に参加しています。
ラグビーワールドカップ2019日本大会公式サイトを利用したPower BI レポートRWC2019BIを作成した際に起こったトラブルや知見のお話です。
トラブル1 : データソースのデータが急に変わり、レポートが破綻した
レポートが9割方出来上がり、公開に向けた調整をやってた頃のお話です。
データの更新を行うと、突如として今まで公式サイトから取得出来てた日本語データの大半が英語になりました。
例えばこの場合ならアルゼンチンがArgentinaといった具合です。
その被害は甚大です。
日本語データを前提として設計してたスライサーは全滅。
日本語データをフィルター式として利用していたDAX式も全滅。
日本語データで関連付けてたリレーションも全て破綻しました。
例えば試合会場のデータはこのようになりました。
Before
After
Afterは復旧後の画像なので列名などが異なってますが、当時は会場、開催地、所在地の全てが英語になってしまったのです。
何があったか
正確な原因は不明ですが、恐らく公式サイトの設定が変わったのだと思います。
以前はPower Queryでhttps://www.rugbyworldcup.com/matches?lang=jaを指定すれば日本語サイトを読み出せました。
しかし、この時を境にhttps://www.rugbyworldcup.com/matches?lang=jaであってもPower Queryでは英語サイトを読み出すようになってしまったのです。
対策
他所のデータをデータソースとする場合、変更は必ずあるものと覚悟しておく
自分が管理していないデータに何があっても文句は言えません。
データが急に変更されても対応しやすいデータ構造やステップを組もう
Power Queryで処理をなるべくワンラインに収めたり、既存の処理を弄って複雑な事をやらせたりもできます。
しかしPower Query Ninja なら兎も角、生兵法でやっても面倒を見切れなくなるだけなので、自身のレベルに合わせたステップ構築がお勧めです。
Power Queryデフォルトのステップ名はある程度分かりやすい名前ですが、重要なステップに自分で分かりやすい名前を付けておくと修正の際に迅速な作業を行えます。
また「ステップのここからここまでで何を処理する」という風に処理するテーマ毎にステップを連ねてあげると、後付けでステップを差し込みやすいです。
今回の例であれば、[更新トラブル対応]と付いたステップが対応を行った際に追加したものです。
もし一過性のトラブルであれば、[更新トラブル対応]と付いたステップを消すだけで元通りになります。
データソースの母国語(大体は英語)と日本語の対訳テーブルを用意しておこう
国外の組織のデータをソースとする場合、例え日本語サイトが提供されていたとしても正は相手の母国語のデータです。
日本語サイトの日本語は、翻訳されて出て来た処理の結果でしかありません。
もし日本語訳が変わると困ったり、今回のようなトラブル対応を見越すのであれば、相手の母国語のデータと日本語との対訳テーブルを用意するのが便利です。
母国語サイトと日本語サイトのデザインが共通なら作り方は簡単で、Power Queryを使い同じ処理で母国語サイトと日本語サイトのデータを取得し、マージした上でExcelなどの静的データにします。
サイトデザインが共通の場合、データの並び順も一緒の場合が多いはずなので難易度は低いと思います。
トラブル2 : Power BI Desktop と Power BI Service ではビジュアルの挙動が異なる
レポートが無事完成し、Power BI Serviceで公開した後のお話です。
これは現在の物ですが、RWC2019BIのトップページにはマップビジュアルが使われています。
公開した直後、Power BI Serviceのレポートでそこを見た時に違和感を感じました。
「あれ？ロシアが無いぞ？」
何があったか
以下の国名を標準のマップビジュアルで場所フィールドに追加した場合の挙動を見てみましょう。
データカテゴリは場所を選択。
これが同じマップビジュアルをPower BI DesktopとPower BI Serviceで表示した結果です。
Power BI Desktop
Power BI Service
見てわかる通り、異常な点が幾つかあります。
Power BI Desktopではジョージア(旧名グルジア)がアメリカ合衆国ジョージア州にマッピングされています。
Power BI Serviceではそれに加え、ロシアがアメリカニューヨーク州のロシアにマッピングされていたり、イギリス連合王国の大半がアメリカ合衆国国内に存在してます。
なんとPower BI DesktopとPower BI Serviceで、マップビジュアルのマッピングアルゴリズムが異なるのです。
対策
必ず発行したレポートを確認しながら作ろう
先ほど見たように、Power BIはPower BI DesktopとPower BI Serviceでビジュアルの挙動が異なる事が多々あります。
またデザインにおいてもこれは同様で、Power BI Desktopで文字サイズを調整してスクロールバーを粛清しても、Power BI Serviceではサイズ感が異なりスクロールバーが復活する事も多いです。
細かい調整をする時は、最終成果物であるPower BI Serviceに発行したレポートを見ながら調整しましょう。
さもなくば2度手間が待っています。
正確な表現が必要な物は機械による自動判定を極力避け、数値で指定しよう
マップビジュアルの場所フィールドのように、システムがデータを自動で判定してよしなにしてくれる機能は非常に便利です。
しかし、それは裏を返せばシステムの判定に人間が介在出来ないという事です。
今回の例であれば、Power BI Desktopならジョージアをグルジアに変更するだけでマップビジュアルは期待した結果を出してくれます。
しかしPower BI DesktopとPower BI Serviceではそもそもマッピングアルゴリズムが異なるため、このような対策は無意味です。
この手のトラブルを避けるためには判断する余地のないデータを利用するのが一番で、今回の例であれば緯度経度でマップ上を絶対値で指定可能です。
まとめ
-
他所のデータを使う時は急な変更があっても泣かない
- 我々は使わせて頂いてるだけです
-
Power BIはSaaSである事を常に意識しよう
- ローカルとクラウドでは挙動が異なるのは当然と考えましょう
-
自動で判断させても良いデータなのか、正確性を担保する必要があるデータなのか
- マップなど、システムが自動で判断する機能を持ったビジュアルを業務で利用する際は必ず考慮してください
所用で投稿が遅れました…(´・ω・｀)
反省
謝辞
このBIレポートを作りにあたり、某室長から様々なフィードバックと御馳走と激しい指示がありましたが、無事乗り切れました。
最後のデータ検証にも付き合っていただいて、トラブル1の対処でも非常に助かりました。
現地の試合会場までレポートを持ち込んでくれたり、ブログで取り上げてくれたり、感謝の念に堪えません。
因みに私はDefense Coachです(/・ω・)/ｶﾞﾝﾊﾞｯﾀ
ラグビーが好きな会社役員の方も多いですし、こういうところの方々にも見てもらってPower BIが更に広まってくれるとありがたいですねー。
