この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
こんにちは。DI部/奈良県民のtamaでございます。
2月15日（木）に、3回目となる関西Tableauユーザー会が開催されました。本エントリでは、その模様をレポートしたいと思います。
エントリ構成について
今回のユーザー回は、3つのプログラムで構成されていますが、プログラム2の「Desighning Dashboard for Performance」が特に重厚な内容だったため、「プログラム1と3」と「プログラム2」で、エントリを分けたいと思います。
本エントリは「プログラム2」を取り扱います。
※「プログラム1と3」に関するレポートは以下からどうぞ
概要
- 2月15日（木） 16:00〜
- 大阪府大阪市淀川区西中島5-12-12 エムオーテックス新大阪ビル
関西地域のTableauユーザーのみなさま お待たせしました、第３回のユーザー会を開催することになりました！
第２回のグループディスカッションで出た意見の中から、分析を始める前のデータ準備や パフォーマンスに関わる内容が多かったことから、「データ」にフォーカスをあてることにしました。 そしてなんと、今回はTableau Japan株式会社からJediの田中香織さんが講師です！ 限られた時間ですが、きっと多くの気づきを得られると思いますので、奮ってご参加ください。
プログラム2:Desighning Dashboard for Performance（分析前のデータ準備、パフォーマンスのコツ）
概要
第２回のグループディスカッションでこんな意見がありました。 ・複数データをくっつける時、どうすればいいの？ ・非エンジニアだからJOINと言われてもよくわかんない！ ・データ増えたら重くなった… Tableauの田中さんが、これらの疑問にスパッと回答！可視化にスムーズには入れるコツを伝授します。
Tableauを使い続ければ、必ず直面する問題「パフォーマンス」について、Jediによる有益なアドバイスが詰まった発表です。
パフォーマンスの考え方
- そもそも、パフォーマンスが悪いと何が問題なのか。
- 例えば、何らかの知りたいことがあって、Tableauでデータを取り込んで、操作するとき…
- その時、データの表示が遅いと、「表示が遅い」という方に気が取られてしまう。これはデータ分析において非常に問題である。
- パフォーマンスが良いと、以下のメリットが生まれる。
- 迅速に「答え」を見つけることができる。
- 「Flow」に乗れる
- データ分析における、答えを導くまでの考え方の流れのことを、Tableau社ではFlowと呼ぶ
- いちいちTableauワークブックを 作り直す必要がない
- パフォーマンスが遅いと、「早い版のワークブックを作り直そう」という流れになって、似たようなビューを量産するおそれがある。
パフォーマンスを決める要素
- やりたいこと
- そのデータから知りたいこと、解決したいことなど。
- 「パフォーマンス（スピード）をあげる」こと自体がやりたいことではない事に注意する必要がある。
- 知識
- パフォーマンスが遅くならない方法を知っているかどうか
- データ量
- 処理能力
- ハードウェア性能など
- 一番手っ取り早いのは、「処理能力」に大量に投資する方法。（ハードウェアの性能を良い物にするなど）
- しかし、それは本当に効率的な方法なのか？
- そこにかけるお金を、「やりたいこと」「知識」に向ければ、会社やチームにとって、もっと有益な事ができるようになるはず。
- 本当に重要なのは「やりたいこと」のはず
- そして、そのためには「知識」が必要
考え方の1例
- 例えば、「1月〜12月までの売上データ」をTabelauで見るとする。そして、そのデータには「商品カテゴリ」という項目も存在し、行数としては10億件ほどある。
- そのデータを表示するのに、毎回10分程度かかるとする。（10億件が10分だったら良い方？）
- そのデータはやがて誰も見なくなる。
- 月次の売上が見たいだけなら、日単位、時間単位のデータは不要
- 「やりたいこと」に対して、本当に必要なデータは何かを考える必要がある。
誰が何をするかが重要
- SQLとはコンピュータのための言語である。
- Tableauは、設定されたビューを、DBがわかる言語に変換する（VizQL）
- そして、DBから返された結果を、ビューにする。
- SQLクエリの変換は「文章を書くだけ」と例えることができる。
- その文章に書かれていることを処理するのは、DB側。（結合、集計、計算など）
- 処理結果を画面にレンダリングしたり、表示した数値を表計算したりするのはTableau側。
- パフォーマンスが遅い時の考え方の1つとして、Tableau側（レンダリング等）かDB側（集計）のどちらがボトルネックになっているか判断する。
-
他にも以下のようなチェックポイントがある
- データがどこに置いてあるか
- ネットワークは遅くないか
- ビューを見るのはどこか（何の端末で見るのか）
- ボトルネックを判断する手段の1つして「パフォーマンス記録」という機能がある。
- Best Practice
- データ側が遅ければ、Tableauで早くなることはない。
- Tableau Desktopで遅ければ、Tabelau Serverで早くなることはない。
- データ可視化について最適化されているのはDesktop。
- ServerはDesktopの機能をブラウザで代用しているだけ。
- Serverはバックでデータ更新タスクなどが走っていたりするので、ビュー表示に100%リソースを割けない。
- データ可視化について最適化されているのはDesktop。
- 入れすぎ厳禁
- できるだけシンプルなビューにすることを心がける
データソース
- 昨今、増えるデータ量とハードウェアの進化はイタチごっこ状態（総務省の資料より）
- データが多いほどたくさんのことを知れる
- データが多いほど遅くなる（Flowに乗れない）
- データソースに対するフィルタリング
- 普通のフィルタ（クイックフィルタ）は、データソースを全て読み込んでからフィルタリングする
- 要するに早くならない
- 「抽出フィルタ」「データソースフィルタ」を使用するべき
- 普通のフィルタ（クイックフィルタ）は、データソースを全て読み込んでからフィルタリングする
- データ側（DB側）でやれることはやっておく。
- チューニング
- インデックス、パーティショニング
- JOIN
- 集計テーブル（サマリーテーブル、データマート）の作成
- Tableau上で結合すると遅くなるが…
- 逆に遅いことは承知の上で、試しにTableau上で結合してビューを作ってみる。
- そのビューが有用と分かった場合、その結合処理をDB側で実施することで、そのビューのパフォーマンスを上げることができる。 *「後からテーブルを用意して解決できる」というのはTableauの特徴。（他のBIツールでは難しい場合が多い）
- 「抽出」か「ライブ接続」か
- DB側のパフォーマンスが悪い場合、抽出は有効
- ただ、これは結構ケースバイケースの場合が多い
- 併用することもできる。（初期表示は抽出から、ドリルダウン後のデータはライブ接続…といった方法）
- DB側のパフォーマンスが悪い場合、抽出は有効
- 集計テーブル（サマリーテーブル、データマート）をDBに作れない場合
- 予め集計の条件を指定して「抽出」することができる
計算フィールド
- 行レベル計算
- 1行単位で計算する
- DBチューニングの効果が高く反映される
- 集計計算
- SUMとかAVGなど（列単位で計算するもの）
- 行レベルと混在して使用することはできない。
- 表計算
- データ側から持ってきたデータをTableau側で上書き計算する
- 割合とかランクなど
- 「表計算」が多いと遅くなる
- DBのチューニングは関係ない（Tableau側の話なので）
- データ側から持ってきたデータをTableau側で上書き計算する
- ネイティブ機能（Tableau標準の機能、メニューから選べるもの）は計算フィールドより早いことが多い。
- グルーピング
- IF文を書くのではなく、グループ機能を使う
- ディメンションの名称変更
- 「別名」をつける
- メジャー値のグルーピング（ヒストグラムなど）
- ビン機能を使う
- グルーピング
- データ形式の処理速度について
- 整数 > ブール値 > 文字列 の順で早い
- 大前提としてコンピュータはゼロイチの世界で生きているので、数値の処理が早いのは自明。
- ブール値は盲点になりがち
- ☓
if [date] = today() then 今日 else "xxxx" end - ○
[date]=today
- ☓
- パラメータを利用して数値にする
- 整数 > ブール値 > 文字列 の順で早い
- IF文は基本的に重い
- 入れ子になっているような計算フィールドがあった場合、改めて整理するべき
- Tableauというより、プログラミングの基本的な考え方
- ELSEIFを使用する
- 入れ子になっているような計算フィールドがあった場合、改めて整理するべき
フィルター
- ディメンジョンフィルター
- 「不連続」は遅い
- クエリを発行して、全てのディメンジョンを取得しにいくため。
- 「連続」は早い
- 「1〜10」を取得する場合、「連続」だと初めの値と最後の値だけ確認できれば取得できる。（連続しているので1〜10の間に他の数値が入るわけがない）
- 「1〜10」を不連続として扱う場合、1〜10を全て独立した値とみなし、全ての値をチェックするため遅い。
- 「不連続」は遅い
- クイックフィルター
- 一番よく使われるフィルター（選択項目として用意できるやつ）
- これが多いほど遅くなる
- フィルターを操作するたびにクエリが発行されるため
- 項目がデータに依存しないクイックフィルターは早い
- 相対日付フィルター
- 単純に日付だけを参照するため
- 相対日付フィルター
- 「フィルターは何もインサイトを与えてくれない」（田中氏の持論）
- フィルターは相手（見る側）を強制させる
- 取って代わる方法（考え方）として「Guited Analytics」というものがある。
- パラメーターを活用してパフォーマンスを向上させる
- パラメーターはクエリを発行しない
- データソースをまたいでフィルタリングができる
- ただし、単一選択しかできない、動的（ダイナミック）にできない、そもそも複雑な機能である…といったデメリットはある
- フィルターアクションを活用してパフォーマンスを向上させる
- 「 ダッシュボードの、あるビューの項目を選択すると、別のビューがその項目で絞り込まれる」といった機能のこと
- フィルタを乱立するより良い方法。
- ただし、ビューのUIが変わる点に注意が必要。
- クエリの発行は避けられない
- フィルターがかかる順番を意識することは大事
ダッシュボードデザイン
- 意外とパフォーマンスに影響する。
-
不要な「詳細」は外す
- 不要な「地理的役割」は設定しない
- 緯度や経度のデータがあったら、何かと設定したくなるが、使わないのならしない方が早くなる
- テキストテーブル（Excelのようなクロス集計表）を描画するには大量のメモリが必要
- 最低でも1画面に収まるようにレイアウトする
- スクロールが必要なクロス集計表は絶対避けるべき（そもそも本当にそのビューが必要なのか考えるべき）
- 「Guided Analytics」
- 別のビュー項目を選択したとき、その項目でフィルタリングされたクロス集計表だけ表示されるようにする等
- 初期表示（ビュー項目を選択していないとき）をしないようにすることも可能。（選択したときだけクロス集計表が表示される）
- 最低でも1画面に収まるようにレイアウトする
- 1ワークシート1クエリで収まるようにする
- サイズを「固定」する
- 「自動」にすると、Tableau Serverでの表示の際、キャッシュに当たる率が低くなる
- 「固定」の方がキャッシュヒット率が高い
- 「そのビューを閲覧する人」に併せて「固定」する方がよい（個別に「自動」でレンダリングされると、遅くなる）
- 「自動」にすると、Tableau Serverでの表示の際、キャッシュに当たる率が低くなる
そもそもTableauに向いていること
- ビジュアル
- インタラクティブ
- 繰り返し・定期的に使用
- 迅速
- シンプル
- ユビキタス
そもそもTableauに向いていないこと
- 紙資料
- データエクスポート
- 複雑なクロス集計
- Excelレポートの完全置換
Stephen Few氏のメッセージ
- データビジュアライゼーションの第一人者、Stephen Few氏によるダッシュボードの定義です。
- 「ダッシュボードは、1つまたは複数の目標を達成するために必要な、最も重要な情報を視覚的に表示し、1つの画面に統合して配置することで、情報を一目で観察できるようにします。」
所感
Tableauで作成したViz（ビュー）のパフォーマンス問題は、多くのユーザーが抱えている問題です。
実際、「DB側をパワーアップすれば大体解決するのではないか」的な考えをどこかで持っていた私にとって、Tableauから考えられる事がこんなにもあるのかと、非常に響いた発表でした。
その中で、首がちぎれるくらい頷けた部分が、「やりたいことを明確にする（ことがパフォーマンス向上につながる）」という点です。
文字にすれば非常に簡単なことではあるのですが、Tableauを触る上で意外と盲点になりがちなのがここではないでしょうか。そのVizで知りたいこと、伝えたいことがはっきりしていれば、最低限必要なデータや、どういう見せ方がいいのか…といった部分は自ずと見えてきます。それだけでも、かなりパフォーマンスの向上につながるのではないでしょうか。
また、「フィルターからはインサイトは生まれない」という衝撃的発言（？）と同時に紹介された「Guided Analytics」という考え方も気になるところです。こちら、深く調査して新たにブログに起こしたいですね。
以上です。
14
