効率的に作業できるTableauワークブックを設計するためのベストプラクティス
このホワイトペーパーについて
このドキュメントは、多くの作成者による資料の抜粋をまとめて作成したものであることを再度申し上げたいと思います。私の作業のほとんどは、多くの資料を 1 つにまとめ構造的に整理したことだけです。各セクションの文章に見覚えのある読者の方もいらっしゃることでしょう。実際、すべての部分を認識できる方もいるかもしれません。このドキュメントが存在するのは、作者の方々が継続的に素晴らしい資料を生み出し、著作権侵害の申し立てを起こさずにいてくださるおかげであり、そのことに感謝しています。
また、正確さと読みやすさを改善するためにこのドキュメントを校正してくださった多くの方々にも、お礼を申し上げます。細かい点に注意を払い辛抱強く説明していただいたことで、このドキュメントは私が以前自分だけで作成したものに比べずっと読みやすくなりました。このドキュメントは、Tableau 10 の機能を反映して更新されたものです。Tableau のアップグレードで新機能が登場するのを受け、推奨事項が一部変更になることがあります。どうぞよろしくお願いします。
アラン・エルドリッジ
2016 年 7 月
長い文章の要約
このホワイトペーパーを読んだ方や推奨した方から、ドキュメントとして長すぎると言われることがよくあります。それについては、幅広い内容をある程度深くカバーするためには、相当の長さが必要なのだと答えています。
ただし、このドキュメントの重要な点は以下のようにまとめることができます。
効率的に作業できるワークブックを作るための特効薬はありません。まずはパフォーマンスレコーダーを見ることから始め、どこに時間がかかっているのかを理解します。クエリーに時間がかかっているか。クエリーが多すぎるか。計算が遅いか。レンダリングが複雑であるか。こうしたインサイトを使って、正しい方向に力を向けるよう取り組んでください。
このドキュメントにある推奨事項は、単なる推奨事項にすぎません。ベストプラクティスと言えるレベルではありますが、それが自分のケースでパフォーマンスを改善するかどうかはテストする必要があります。多くの場合は、データの構造や使用しているデータソース (たとえばフラットファイルか、RDBMS か、データ抽出か) に依存しているものです。
抽出を使うと、手早く簡単にほとんどのワークブックをより速く実行することができます。
データがクリーンであるほど、質問の構造によくマッチし (すなわち準備や操作が少なくて済む)、ワークブックの実行が早くなります。
動作の遅いダッシュボードは、多くの場合、設計不良が原因となっています。特に、1 枚のダッシュボード上のチャートや一度に表示するデータが多すぎる場合です。シンプルさを心がけましょう。何もかも表示してからフィルターをかけるよりは、ユーザーが徐々に詳細をドリルダウンできるような作りにしましょう。
参照するフィールドにおいても返すレコードの粒度についても、必要なデータだけを扱いましょう。これによって、Tableau が生成するクエリーはより少なく、より適切に、より速くなり、データソースから Tableau のエンジンに移動させるデータ量を減らすことが可能になります。ワークブックのサイズも軽くなるので、共有しやすくなり早く開けます。
データ量を減らすときは、フィルターを効果的に使いましょう。
文字列と日付の処理速度は遅く、数値とブールは速く処理されます。
最後に、扱うデータセットが大きい、あるいは複雑な場合、このドキュメントの推奨事項を実行してもあまり効果のない場合があります。サイズが大きい、あるいは複雑であるとはどういうことか。それは条件によりますが、自分のデータがいつ大きくなるか分からないため、どのワークブックでもこの推奨事項に従っておいて間違いはないでしょう。習うより慣れろです。
Tableau の得意分野
Tableau Software は、ユーザーがデータを見て操作し、理解する際の、データの見せ方や操作方法を変えようとしています。そのため、従来のエンタープライズ版 BI プラットフォームのような機能や使用感をお届けしようとは思っていません。Tableau は、次のようなワークブックを作成する場合に最高の力を発揮します。
視覚的なワークブック - 人間が大量で複雑なデータを理解するために最も効果的な方法は、視覚的表現を用いることです。これを裏付ける証拠は多数あります。Tableau は、チャート、図、ダッシュボードなどを使ってデータを提示するよう既定で設定されています。表やクロス集計もサポートされており、それぞれの役割があります。これらの最適な使用法は後で詳しくご紹介します。
インタラクティブに使えるワークブック – Tableau ドキュメントは、デスクトップ、Web、モバイルのいずれでもインタラクティブに使えるように設計されています。印刷中心のアウトプット(紙ベース、PDF などのデジタル文書) の生成を主とする他の BI ツールとは異なり、Tableauが目指すのは、ユーザーが自分でデータを分析しビジネス上の問題を解決できる、豊富な機能やサービスを利用できるインタラクティブな体験を提供することです。
繰り返し分析できるワークブック - 発見とは、本質的に反復のプロセスです。Tableau は、質問から発見へ、発見から質問へというサイクルをすばやく行えるよう設計されています。そのためユーザーは、仮定を立て、データを使って検証し、仮定を修正してもう一度検証するという作業をスピーディに行うことができます。
動作の速いワークブック - これまでの BI プロセスは時間のかかるものでした。ソフトウェアをインストールして構成するにも、データを分析できるように準備するにも、また、ドキュメントやレポート、ダッシュボードなどを設計し実装するにも、すべてに時間がかかりました。しかし、Tableau ならこれまでよりずっと速くソフトをインストールし、サーバーに接続し、ドキュメントを作成できます。数週間から数か月かかっていた問題解決の作業を、数分から数時間程度に短縮できることも少なくありません。
シンプルなワークブック - 従来のエンタープライズ版 BI ツールは、価格か、機能の複雑さのどちらかで、多くの場合一般のビジネスユーザーの能力を超えていました。多くの場合、ユーザーは、IT の専門家かパワーユーザーの手を借りないと思い通りのクエリやドキュメントを作成できませんでした。Tableau はハイテクに強くないユーザーでも直感的に操作できるインターフェイスを備え、データベースやスプレッドシートの専門家でなくても、クエリを実行したり複雑なデータを分析したりできるようになっています。
見た目のいいワークブック - 「美の基準は見る人次第」と言いますが、視覚的コミュニケーションには推奨されるベストプラクティスがあります。Tableau では表示形式などの機能により、一般ユーザーでも、効果的で理解しやすいチャートを、使用するデータに基づいて作成できるようになっています。
どこでも使用できるワークブック - 1 つのプラットフォームを対象としたドキュメントはもう作成されなくなっています。ユーザーは、デスクトップ、Web、モバイルと、プラットフォームを問わずデータの表示や操作をする必要があり、データの状態も他のアプリケーションやドキュメントに埋め込まれているなど多岐にわたっています。Tableau では、1 種類のドキュメントをパブリッシュし、パブリッシュしたドキュメントをあらゆるプラットフォームで利用できます。その際、移植や再設計などの操作は必要ありません。
Tableau の不得意分野
Tableau は機能豊富でパワフルなツールですが、最適なソリューションを提供できない問題もあることを最初に理解していただくことが重要です。不可能なタスクがあるという意味ではありません。
Tableau は、元の設計仕様に含まれていないタスクでも、工夫次第で実行することができます。しかし、Tableau の開発段階では想定されていなかったタスクもあり、そのようなタスクを何とかしてTableau で実行したとしても、努力が十分に報われない可能性もあります。結果として得られるソリューションも成果が上がらなかったり融通のきかないものになることがあります。
次のようなケースでは、要件を再検討するか、別のアプローチを検討することをお勧めします。
画面表示ではなく、紙への印刷を前提にデザインされたドキュメントが必要な場合。つまり、複雑なページレイアウトを管理する必要がある場合、ページ分けや章立て、ヘッダーやフッターのグループ化などの機能が必要な場合、正確な WYSIWYG フォーマットが必要な場合などです。Tableau でも複数ページのレポートを生成できますが、フォーマット管理については、印刷向けの専用レポート作成ツールにはかないません。
カスタマイズされたドキュメントを複数の配信モードで送信する際に、プッシュ型配信 (または「バースト配信」) する複雑なメカニズムが必要な場合。Tableau Server にはレポートのサブスクリプションというコンセプトがあり、ユーザーが自分で (Tableau 10 では他のユーザーも)サブスクライブすることができます。レポートをメールで受信できますが、より柔軟なソリューションを必要とされるお客様もいます。Tableau を使用してプッシュ型配信システムを構築することはできますが、Tableau の標準機能ではありません。そのためには、TABCMD ユーティリティに基づいて構築されるカスタムソリューションの開発、あるいは VizAlerts(http://tabsoft.co/1stldFh )、または Metric Insights の Push Intelligence for Tableau http://bit.ly/1HACxul のようなサードパーティー製ソリューションが必要です。
読み手の主な利用方法が、データを別のフォーマット (多くの場合 CSV ファイルや Excelファイル) にエクスポートすることである場合。これは、詳細データを含む行が多数ある表タイプのレポートでよくあるケースです。誤解のないように言うと、Tableau でも、ビューやダッシュボードのデータを Excel にエクスポートできます。しかも、エクスポートのレベルをサマリーと詳細から選べます。しかし、主な利用方法がエクスポートである場合、これはTableau の本来の用途でない ELT (抽出・加工・書き出し) プロセスに当たります。レポート作成ツールよりも、ずっと効率的にこの作業を行えるソリューションは多数あります。
多くの場合、複雑な小計機能や相互参照機能を含む既存のスプレッドシートレポートを反映している、非常に複雑な、クロス集計式のドキュメントが必要です。よくある例は損益計算書や貸借対照表などの財務諸表です。また、シナリオモデリング、what-if 分析、さらには仮定データの変更などが必要になることもあります。元になる粒度の高いデータがない場合や、レポートの論理が、レコードを合計値までロールアップするのでなく「セル参照」に基づく場合、この形式のレポートには引き続きスプレッドシートを使用するほうが適していることもあります。
「効率的に作業できる」なワークブックとは
「効率的に作業できる」ワークブックにはいくつかの要素があります。それには、技術的な要素とユーザーに焦点を合わせた要素がありますが、一般的に見て、効率的に作業できるワークブックとは次のようなワークブックです。
シンプルである - 容易に作成でき、その後も容易に維持することができるか。ビジュアル分析の本質を活かし、作成者とデータのメッセージが明確に伝わるようになっているか。
柔軟性がある - ユーザーが聞きたい複数の質問に答えられるか、あるいは 1 つの質問にしか答えられないか。ユーザーがインタラクティブに操作することができるか、静的なレポートだけを提供するのか。
速い - ユーザーが満足できる速度で応答するか。これは、ファイルを開く、または更新にかかる時間、操作に対する応答時間を意味することがあります。主観的な評価基準ではありますが、Tableau は、ファイルを最初に開くときやユーザーが操作したときに数秒で情報を表示できるワークブックを目指しています。
ダッシュボードのパフォーマンスは、次のようなものに影響を受けます。
ダッシュボードとワークシートの両レベルでのビジュアルデザイン。たとえば表示する要素やデータポイントの数、フィルターやアクションの使用です。
計算。たとえば計算の種類、計算を行う場所などです。
クエリー。たとえば返すデータの量、カスタム SQL かどうか、などです。
データ接続と参照元データソース。
Tableau Desktop と Tableau Server との違い。
その他、ハードウェア構成や容量などの環境的要素。
効率性が重要な理由
それには、いくつかの理由があります。
アナリストあるいはワークブック作成者が効率的に仕事をすると、答えを早く得られるようになります。
効率的に仕事ができれば、分析の「流れ」から逸脱することがありません。つまり、結果を得るするためにツールをどう扱うかよりも、質問とデータのことを考えていられるということです。
デザインの柔軟なワークブックを作ると、似たような要件のために複数のワークブックを作って維持する必要性を減らせます。
シンプルなデザインのワークブックを作ると、他のユーザーがそのワークブックを手にとり、それを元にして別バージョンを作ることが容易になります。
反応速度を認識しておくことは、エンドユーザーがレポートとダッシュボードを適切に表示できるようにするための重要な要素です。できる限り速く動作するワークブックを作るとユーザーの満足度が高まります。
これまでのさまざまな経験では、お客様が直面するパフォーマンスの問題は、そのほとんどがワークブックの設計ミスによるものです。このミスを教育によって直すか、教育によって最初の段階でミスを避けることができれば、問題は解決できます。
ボリュームの小さなデータを扱う場合、ここに記載している推奨事項の多くは重要ではありません。そのままのやり方で作業を進めてかまいません。しかし、億単位のレコードを扱うとなると、多数のワークブックや作成者に与えるワークブック設計不良の影響が増大するため、このホワイトペーパーにあるアドバイスを検討する必要があります。
もちろん、習うより慣れろですから、すべてのワークブックについてこのアドバイスに従うことを推奨します。予想される本番データボリュームでワークブックをテストするまでは、設計完了にはならないと覚えておいてください。
1 つ、大事なことを書いておきます。このドキュメント全体を通して Tableau Server に言及しますが、あなたがオンプレミスよりもホスティング型ソリューションの方を好む場合、このアドバイスはほとんどTableau Online にも当てはまります。明らかな例外は、サーバーの構成パラメーターの微調整/調整や、サーバーティアでのインストール/アップデートに関する点です。SaaS では、これらの問題に対応しています。
物理の法則
ワークブックのパフォーマンスに影響する機能について技術的な詳細を論じる前に、効率的に作業できるダッシュボードやレポートを作成するうえで役立つ基本的な原理を説明します。
遅いデータソースは Tableau も遅くする
Tableau ワークブックが実行速度の遅いクエリを利用していれば、Tableau ワークブックも遅くなります。次のセクションで、データベースを調整する際のヒントをご紹介します。クエリの実行速度を改善するためにお役立てください。また、Tableau の高速データエンジンを使用してクエリのパフォーマンスを向上する方法についても説明します。
Tableau Desktop での動作が遅い場合は、(ほとんどの場合) Tableau Server でも遅くなる
Tableau Desktop で動作の遅いワークブックは、Tableau Server にパブリッシュしてもそれ以上速くはなりません。多くの場合ユーザーは、ワークブックの実行速度はローカル PC より CPU/RAM などの容量が大きなサーバー上で動く Tableau Server の方が速いと思っています。一般的に、ワークブックの実行速度は Tableau Server の方がやや遅めです。その理由は、
同時に複数のユーザーがワークブックを作成するときは、その全員がサーバーリソースを共有しているため (ただし、直感とは反対に、ワークブックを共有すると反応が速くなることに気付くかもしれません。これは Tableau Server 内でのキャッシュの仕組みによるものです)、そして
クライアントワークステーションでなくサーバーが、ダッシュボードとチャートのレンダリングという追加処理を実行しなければならないためです。
まずは Tableau Desktop でワークブックの調整に取り組んでから、Tableau Server でのパフォーマンス調整を始めるようにしましょう。
このルールの例外は、Tableau Desktop がサーバーにはないリソースの制限を受けるときです。たとえば PC が分析したいデータボリュームに対応する十分な RAM を搭載していない場合や、サーバーがデータソースに接続する待ち時間が短い場合があります。低スペックで RAM が 2GBのワークステーションでデータセットを操作すると、動作が遅かったり、「メモリ不足」というエラーが発生することもあります。そのような場合は、ワークブックをパブリッシュすればサーバーのより大きなメモリや処理能力を利用できるため、許容できる速度までパフォーマンスが向上します。
新しいバージョンほど高機能
Tableau の開発チームは、ソフトウェアのパフォーマンスとユーザビリティの向上に絶えず取り組んでいます。Tableau Desktop と Tableau Server を最新バージョンにアップグレードすると、ワークブックを変更しなくてもかなりのパフォーマンス改善を生み出すことがあります。たとえば、多くのお客様が、V8 から V9 にアップグレードしただけでワークブックのパフォーマンスが 3 倍 (以上) 改善したと報告しています。パフォーマンスの向上は、Tableau 10 およびそれ以降でも継続的に重視されています。もちろん、Tableau Online は最新バージョンのリリースに合わせて常時アップグレードされるため、問題ありません。
メンテナンスリリースやメジャー/マイナーリリースでも同様です。Tableau のリリースサイクルの詳細な情報と各リリースの個別内容については、リリースノートページでご紹介しています。
http://www.tableau.com/ja-jp/support/releases
さらに、データベースベンダーも製品の向上に取り組んでいます。次の Web ページのリストで、 適切なデータソースドライバーの最新バージョンを使用していることを確認してください。
http://www.tableau.com/ja-jp/support/drivers
少ないほど効果的
何についても言えることですが、良いものでも度が過ぎればかえって害になります。たった 1 つのモノリシックなワークブックにすべてを詰め込もうとしてはいけません。1 つの Tableau ワークブックにはダッシュボードが 50 件入り、各ダッシュボードにはチャートオブジェクトが 20 個入り、各オブジェクトはそれぞれ 50 件の異なるデータソースから情報を取得することができます。しかし、処理速度は確実に遅くなります。
作成したワークブックがどうしてもそのようになってしまうという場合は、ファイルをいくつかに分けることを検討してください。難しいことではありません。ワークブック間でダッシュボードをコピーするだけで、関連するワークシートとデータソースは全部 Tableau が持ってきてくれます。ダッシュボードが必要以上に複雑なときは、単純化して、エンドユーザーをレポートからレポートへと誘導する操作を加えることも考えてみてください。ドキュメントによって Tableau の価格が決定されるわけではありません。データを自由に分散させてください
スケーラビリティはパフォーマンスと同じではない
スケーラビリティとは、複数のユーザーによる共有ワークブックの表示をサポートできることです。パフォーマンスとは、個々のワークブックが可能な限り早く実行できるようにすることです。このドキュメントにある推奨事項の多くは、Tableau Server にパブリッシュされたワークブックにスケーラビリティの向上をもたらしますが、このドキュメントで主に焦点を当てているのはパフォーマンスの向上です。
推奨ツール
自分のワークブックのパフォーマンスを理解するためには、a) 何が起こっているかと、b) それにかかる時間を理解する必要があります。この情報は、ワークブックの実行場所 (すなわち Tableau Desktopまたは Tableau Server) に応じて、複数の場所、および複数の詳細レベルで取得できます。このセクションでは、利用可能な様々なオプションについて説明します。
パフォーマンスレコーダー
パフォーマンス情報として最初に確認するものは、Tableau Desktop と Tableau Server のパフォーマンスレコーダー機能です。Tableau Desktop では、ヘルプ メニュー内にこの機能があります。
Tableau を起動してパフォーマンスの記録を開始してから、ワークブックを開きます (この間、別のワークブックは開かないことをお勧めします。気付かないうちにリソースを競合させないためです)。エンドユーザーになったつもりでワークブックを操作し、十分なデータを収集したと感じたところで`ヘルプ` メニューに戻り、記録を停止します。Tableau Desktop で、データが記録された別のウィンドウが開きます。
これで、ワークブックで最も時間のかかるアクションを特定できるようになりました。たとえば上図の例では、Timeline ワークシートから選択されたクエリは完了するまでに 30.66 秒もかかっています。棒グラフをクリックすると、実行されているクエリのテキストが表示されます。パフォーマンスレコーダーは Tableau ワークブックに結果を出力するので、追加のビューを作成してこの情報を別の方法で調べることができます。
メモ： 既定では、0.1 秒未満のイベントは表示されません。ダッシュボードの上部にあるフィルターを調節すれば表示することもできますが、処理時間の長いタスクに注意を払う必要があります。1 秒に設定することをお勧めします。
パフォーマンスの記録を Tableau Server 上に作成し、ワークブックがパブリッシュされるときに起こる問題を特定させることも可能です。既定では、パフォーマンスの記録は Tableau Server 上では有効化されていません。これはサイト単位で管理される機能です。
サーバー管理者は、パフォーマンスの記録をサイトごとに有効化することができます。
1. パフォーマンスの記録を有効化したいサイトに移動します。
2. `設定` をクリックします。
3. `ワークブックパフォーマンスメトリックス` 内の `ワークブックパフォーマンスメトリックスを記録` を選択します。
4. `保存` をクリックします。
パフォーマンスの記録を作成する:
1. パフォーマンスを記録したいビューを開きます。ビューを開くとき、Tableau Server が URLの後に `:iid=` を追加します。これがセッション ID です。たとえば次のようなものです。
`http:///#/views/Coffee_Sales2013/USSalesMarginsByAreaCode?:i id=1`
2. ビューの URL の最後の部分の、セッション ID の直前に :record_performance=yes& と入力します。たとえば次のようになります。
`http:///#/views/Coffee_Sales2013/USSalesMarginsByAreaCode?:r ecord_performance=yes&:iid=1`
3. ビューを読み込みます。
パフォーマンスの記録が開始されたことが、ビューのツールバー内に `パフォーマンス` オプション として画面表示されます。
完了し、パフォーマンスの記録を表示する:
1. `パフォーマンス` をクリックしてパフォーマンスワークブックを開きます。これはパフォーマンスデータの最新のスナップショットです。ビューの分析を続行しながら追加でスナップショットを取ることも可能で、パフォーマンスデータは累積されます。
2. 別のページに移動するか、`:record_performance=yes` を URL から削除して記録を停止します。
この情報を使用して、ワークブック内で最優先で検証するべき箇所、つまり改善に費やす時間に対して最も成果が上がるセクションを特定します。これらの記録を分析するための詳細情報については、以下のリンクをご覧ください。
https://onlinehelp.tableau.com/current/pro/desktop/jajp/help.htm#perf_record_create_desktop.htm
ログ
Tableau は、ログファイルで完全なクエリテキストを見ることができます。既定の場所は`C:\Users\\Documents\My Tableau Repository\Logs\log.txt` です。ファイルはかなり冗長なもので、JSON エンコードのテキストで書かれています。そのため、分析には Notepad++ やSublime などのテキストエディターを推奨します。「begin-query」または「end-query」で検索すると、データソースにパスされたクエリの文字列が見つかります。「end-query」ログでも、クエリの実行にかかった時間と Tableau に返されたレコードの数を見ることができます。
code:tableau
{"ts":"2015-05-
24T12:25:41.226","pid":6460,"tid":"1674","sev":"info","req":"-","sess":"-
14
","site":"-","user":"-","k":"end—query",
"v":{"protocol":"4308fb0","cols":4,"query":"SELECT
none:ProductSubcategoryName:nk,\n SUM(CAST((FactSales.ReturnQuantity)
as BIGINT)) AS sum:ReturnQuantity:ok,\n SUM(FactSales.SalesAmount) AS
sum:SalesAmount:ok\nFROM dbo.FactSales FactSales\n INNER JOIN
DimProduct.ProductKey)\n INNER JOIN dbo.DimProductSubcategory
DimProductSubcategory.ProductSubcategoryKey)\n INNER JOIN
DimProductCategory.ProductCategoryKey)\nGROUP BY
DimProductSubcategory.ProductSubcategoryName","rows":32,"elapsed":0.951}
}
Tableau Server の場合は、ログの場所は `C:\ProgramData\Tableau\Tableau Server\data\ tabsvc\vizqlserver\Logs` になります。
Tableau Server パフォーマンスビュー
Tableau Server には、管理者が Tableau Server でのアクティビティを監視するためのビューがいくつか用意されています。これらのビューは、サーバーの `メンテナンス` ページの `分析` 表にあります。
これらのビューについて詳しくは、以下のリンクをご覧ください。
http://onlinehelp.tableau.com/current/server/ja-jp/adminview.htm
また、カスタムの管理ビューは Tableau リポジトリの一部を構成する PostgreSQL データベースに 接続することで作成できます。手順についてはこちらをご覧ください。
http://onlinehelp.tableau.com/current/server/ja-jp/adminview_postgres.htm
TabMon
TabMon は、一定期間にわたりパフォーマンスの統計を収集できる Tableau Server 用オープンソースクラスタモニターです。TabMon はコミュニティのサポートを受け、完全なソースコードを MIT オープンソースライセンスに基づいて公開しています。
TabMon は、追加の設定なしにシステムの健全性とアプリケーションのメトリックスを記録することができます。ネットワーク全体の Tableau Server マシンで、Windows Perfmon、Java Health、Java Mbean (JMX) カウンターなど、ビルトインのメトリックスを収集します。TabMon では、物理 (CPU、RAM)、ネットワーク、ハードディスクの使用状況を監視できます。キャッシュ-ヒット率、リクエストの待ち時間、アクティブセッションなどがトラッキングできます。データは読みやすく統一された構造で表示され、Tableau Desktop でデータを簡単に可視化することができます。
TabMon を使えば、どのメトリックスをどのマシンから収集して監視するかを完全に管理できます。スクリプトやコーディングは不要で、マシン名とメトリックス名が分かっているだけで十分です。
TabMon はリモートでもクラスタから独立させても実行でき、クラスタの健全性をネットワーク上のどのコンピューターからでも監視、集計、分析することができます。本番マシンに負荷が加わることはありません。
TabMon について、詳しくはこちらをご覧ください。
https://github.com/tableau/TabMon/releases
TabJolt
TabJolt は「ポイントアンドラン」で読み込みとパフォーマンスをテストするツールで、特にTableau Server で容易に使えるように設計されています。従来の読み込みテストツールと異なり、TabJolt は Tableau Server に対し自動的に読み込みを実行させます。スクリプトの開発やメンテナンスは不要です。TabJolt は Tableau のプレゼンテーションモデルとして認識されているため、ビジュアライゼーションを自動で読み込み、テストの実行中に可能な操作を解釈することができます。
これによって、TabJolt をサーバー上の 1 つまたは複数のワークブックにポイントし、自動的に読み込み Tableau のビュー上で操作を実行することが可能です。TabJolt はまた、主なメトリックスとして平均応答時間、スループット、95 百分位の応答時間などを収集し、Windows のパフォーマンスメトリックスを相関関係確認用として採取します。
もちろん TabJolt があっても、ユーザーには Tableau Server のアーキテクチャに関する十分な知識が必要です。読み込みテストにおいて、Tableau Server をブラックボックス的に扱うことは推奨できません。期待に沿った成果を生み出す可能性が低くなります。TabJolt は自動化されたツールで、人間による様々な操作を簡単に再生できないため、TabJolt の出す結果が実環境での効果を反映しているか慎重に検討してください。
TabJolt について、詳しくはこちらをご覧ください。
https://github.com/tableau/tabjolt/releases
その他のツール
その他にも利用可能なサードパーティー製ツールがいくつかあり、ワークブックのパフォーマンスの特徴を見出すことができます。その 1 つが Interworks の「Power Tools for Tableau」です。これにはパフォーマンスアナライザー (ビルトインのパフォーマンスレコーダーに類似) が含まれており、どのシートとクエリに一番長く時間がかかっているかを掘り下げて理解することができます。
Palette Software には Palette Insight という製品も含まれています。これは Tableau Server からパフォーマンス情報を取得することで、キャパシティプランニング、リソースを多く使うユーザーやワークブックの特定、ユーザーアクセスの監査、チャージバックモデルの構築を可能にします。
また、現在の DBMS プラットフォームはほとんど、クエリ実行の追跡と分析ができる管理ツールを 備えています。パフォーマンスの記録でクエリの実行時間が大きな問題点だと分かった場合は、お使いの DBA も大いに役立つ可能性があります。
クライアントのブラウザとサーバー間の通信に問題があると思う場合、Telerik Fiddler などのツールやブラウザのディベロッパーツールでクライアントとサーバー間のトラフィックをよく調べてみてもいいでしょう。
多くのユーザーにとって、Tableau を使っての作業は新しい経験です。効率的に作業できるワークブックを作成するために、学んでおくべき設計の手法やベストプラクティスがあります。それでも、慣れないユーザーの多くが従来の設計手法を Tableau でも使用してしまい、残念な結果を招いていることが分かっています。このセクションでは、ベストプラクティスを反映した設計の原則について説明することを目的とします。
優れたダッシュボード設計
Tableau を使って、エンドユーザーのためにインタラクティブな体験を生み出します。Tableau Serverにより提供される完成品は、データをただ見るだけでなく、ユーザー自身がデータを分析できるインタラクティブなアプリケーションです。そこで、効果的な Tableau ダッシュボードを作成するためには、静的なレポートを作成するときのような考え方を改める必要があります。
以下は、Tableau を使い始めたばかりのユーザーの多くが作成しがちなダッシュボードの例です。特に、Excel や Access などのツールを使っていた人や、「従来の」レポート作成ツールを使った経験がある人は、ここで紹介する間違いをしてしまいます。それは「何もかも」詰め込んだ表タイプのレポートで、何種類ものフィルターが用意されているのが特徴です。ユーザーはこのフィルターを使って、自分が見たい数件のレコードが表示されるよう表を絞り込むことができます。
Tableau ダッシュボードでは、これは悪い例です (実際、まったく「良い」例ではありません)。厳しいことを言えば、これは見せかけのデータ抽出プロセスです。データを Excel など別のツールに移して詳細な分析やチャート作成をしたい、とユーザーに思わせるからです。好意的に解釈すれば、エンドユーザーがどのようにデータを分析したいか実際には分からないため、「最初の基準に基づいてすべての情報を用意しました。さらに必要なデータを見つけるために結果セットを絞り込むことができるようにフィルターオブジェクトもあります」というアプローチを取っています。
以下は設計し直したダッシュボードです。まったく同じデータを使っています。ここでは、集計のレベルを最も高くしてあります。
1 つ以上の要素を選択すると、次のレベルの詳細が表示されます。
これを繰り返すたびに、より詳しいデータが明らかになっていきます。
最終レベルまで表示すると、最初にご紹介したクロス集計ダッシュボードと同じデータになります。
データをどう提示するかを考えないようにしてください (この点は重要ですが、後で取り上げます)。代わりに、このダッシュボードを使用した場合の操作性について考えます。レイアウトが左から右へ、上から下へと自然に移動していることに注目してください。この例では元になるデータ量が膨大ですが、ダッシュボードの役目は、エンドユーザーが徐々にデータを掘り下げ、自分が探している詳細なレコードにたどり着けるよう誘導することです。
ここで紹介した 2 つの例の最も重要な違いは、分析プロセスを通じてエンドユーザーをどのように誘導しているかです。最初の例では、ユーザーが求めている可能性のあるレコードをすべて広範囲に表示することから始め、エンドユーザーが自分でフィルターを適用して、表示されるレコード数を減らすようにします。この手法はそれ自体に問題を含んでいます。
1 つ目の問題は、エンドユーザーにデータを表示する前に実行する必要のある最初のクエリが、本質的に最大のクエリ (「すべてのレコードを取得」) になることです。実際のデータセットでこれを行うと、クエリを実行して Tableau エンジンにデータが届くまでに、かなりの時間がかかってしまいます。ソリューションに対するエンドユーザーの印象を決めるうえで、第一印象は非常に重要です。起動して数秒以内に何も起こらないとなれば、印象が悪くなります。
2 つ目の問題は、数十万から数百万のマーク (クロス集計の各セルを「マーク」と言います)を含むビューを作成するために、かなり高性能の CPU とメモリが必要になることです。それにも時間がかかるため、システムの応答時間についての印象がさらに悪くなります。Tableau Server で複数のユーザーがサイズの大きいクロス集計を作成すると、パフォーマンスが低下し、最悪の場合にはメモリ不足が起こることも考えられます。その結果サーバーの不安定やエラーを引き起こし、あらゆる面でエンドユーザーの使い心地が悪くなる可能性があります。もちろん、サーバーにメモリを追加してこの可能性を低く抑えることはできますが、それは対処療法であって根本的な解決にはなりません。
3 つ目の問題は、最初に適用するフィルターの絞り込み範囲が広いか狭いかについて、コンテキストに基づく指針がユーザーに与えられていないことです。最初のクエリで数万件ものレコードが返されてサーバーの RAM を使い尽くしてしまわないよう、レポートのユーザーが利用できるカテゴリーをすべて確認できているかどうかを知るには、どうすればよいのでしょう。それを知るには、手間のかかる方法以外ありません。
対照的に、設計し直した例では、最初のクエリで最も高位の集計データのみをリクエストします。
実行する必要がある最初のクエリが非常に集計されているため、返されるデータもほんの数件のレコードに抑えられます。優れた設計のデータベースを使用する場合、これは非常に効率的です。第一印象を形成する応答時間も非常に短縮され、システムに対する印象も良くなります。データを掘り下げるたびに実行される他のクエリも、高レベルでの選択内容によって集計され制約されています。そのため、クエリを実行して Tableau エンジンにデータが返されるまでの時間は速いままです。
ダッシュボードを完成したときにはより多くのビューが表示されますが、各ビューに含まれるマークの数は数十個に抑えられています。それぞれのビューを生成するのに必要なリソースは、システム上で多数のエンドユーザーがアクティブな場合でも非常に少なく、メモリ不足が発生する可能性は低くなります。
最後に、ナビゲーションの高位のレベルでは、販売量がカテゴリーごとに示されています。これにより、選択する範囲に含まれるレコードが多いか少ないかを判断するコンテキストが、ユーザーに提供されます。また、色別表示により、各カテゴリーの収益性も分かるようになっています。やみくもにナビゲートするのではなく、どのエリアに注目する必要があるかが分かるため、ユーザーにとってデータがとても身近になります。
あくまでシンプルに
初心者のユーザーが犯しがちな間違いは、必要以上に「複雑な」ダッシュボードを作ることです。以前使っていたドキュメントを別のツールから再作成しようとしているのかもしれないし、レポートを印刷するために特別に設計したものを作ろうとしているのかもしれません。その結果、パフォーマンスが遅く効率の悪いワークブックができてしまいます。
複雑なダッシュボードの原因には、次のようなものがあります。
1枚のダッシュボードにワークシートを多く作り過ぎる
初心者が陥りやすい間違いに、チャートやワークシートを 1 枚のダッシュボードに多く詰め込みすぎることがあります。
各ワークシートはデータソースに対し 1 つ (おそらく複数) のクエリーとして実行されることに注意してください。つまり、ワークシートが多いほどダッシュボードをレンダリングする時間がかかるということです。Tableau は、エンドユーザーにインタラクティブなダッシュボードを提供するよう設計されているため、複数のダッシュボードやページにわたってデータを分散してください。
フィルターカードが多過ぎる
フィルターカードは Tableau の非常にパワフルな機能で、エンドユーザー向けに情報が豊富でインタラクティブなダッシュボードを作成することができます。しかし、各フィルターはオプションを列挙するためにクエリを必要とすることがあるため、ダッシュボードに追加し過ぎるとダッシュボードのレンダリングに予想以上に時間がかかってしまいます。また、フィルターで `関連する値を表示` を使うと、他のフィルターが変更されるたびに、表示されている値を更新するためのクエリを必要とします。この機能は控えめに使いましょう。
また、複数のワークシートに適用しているフィルターがある場合は、表示されているすべての対象ワークシートが表示を更新するので、1 つ変更するたびに複数のクエリがトリガーされることに注意してください (画面にないワークシートは更新されません)。これが終わるまで何秒もかかると、操作性が低下します。ユーザーが複数選択タイプのフィルターを何度も変更することが予想される場合は、ユーザーが選択項目の変更が終わってから更新をトリガーできるように、`適用` ボタンを表示することを考慮してください。
パフォーマンス向上のためにダッシュボードを調整する
ダッシュボードをできるだけシンプルにしたら、キャッシュ機能を利用して設計を調整し、さらにパフォーマンスを向上できます。
固定サイズのダッシュボード
パフォーマンスを向上するための一番簡単な方法は、ダッシュボードが固定サイズであるかを確認することです。
Tableau では、レンダリングプロセスの一部をレイアウト作成が占めています。たとえば、スモールマルチプルとクロス集計に表示する行と列の数、描画する軸目盛りやグリッド線の数と間隔、表示するマークラベルの数と位置などです。これはダッシュボードを表示するウィンドウのサイズによって決まります。
同じダッシュボードにサイズの異なるウィンドウから複数のリクエストを行う場合は、リクエストごとにレイアウトを生成する必要があります。・ダッシュボードレイアウトを固定サイズに設定することにより、 どのリクエストにも再利用できるレイアウトを 1 つ作成するだけで済みます。サーバー側レンダリングを行う場合は、これがさらに重要になってきます。ダッシュボードを固定サイズにすると、サーバーでレンダリングされるビットマップをキャッシュして共有できるようになるため、パフォーマンスとスケーラビリティの両方が向上します。
デバイス固有のダッシュボード
Tableau 10 では、デバイス固有のダッシュボードという新しい機能を取り入れています。この機能により、使用しているデバイスに基づいて自動的に選択されるカスタムダッシュボードレイアウトを作成することができます。
スクリーンサイズに基づいて、使用するレイアウトが選択されます。
最小の軸が 500px 以下 – スマートフォン
最小の軸が 800px 以下 – タブレット
800px 超 - デスクトップ
デバイスが変わるとスクリーンサイズもその範囲で変化します。デバイスは縦横に向きを変えることがあることから、スマートフォン/タブレットのレイアウトは基本的に自動サイズ調整に設定することをお勧めします。こうすることで、デバイスに関係なく最も見やすく表示できますが、これによってキャッシュの再利用 (サーバー側レンダリングの場合は、プレゼンテーションモデルのキャッシュとイメージタイルのキャッシュ両方)–に影響が及びます。一般的にはデバイスに合わせたサイズ調整のメリットの方が、キャッシュに及ぶ影響を上回りますが、これについては検討する必要があります。
ユーザーがワークブックを使用し始めたら、最終的に最も一般的なスクリーンサイズ用にモデルとビットマップを設定するとパフォーマンスが向上することに注意してください。
Viz LOD を使用してクエリを減らす
基本的には各ワークシートに必要なフィールドだけ使用することを推奨しますが、1 枚のワークシートに取り込む情報を増やして他のワークシートへのクエリを避けることにより、パフォーマンスを向上させることも可能です。下のダッシュボードを見てください。
予想されるとおりにこれを作成すると、実行する計画によって各ワークシートに 1 つずつ、合わせて2 つのクエリが実行されることになります。
ダッシュボードの設計を変更して、(`詳細`シェルフで) `Cities` ワークシートに `Country` を追加すると、Tableau はたった 1 つのクエリでダッシュボードを完成できます。Tableau は、`Cities` ワークシートのクエリをまず実行してから、そのクエリの結果をキャッシュして `Country` ワークシートに提供するスマートな機能を備えています。この機能を「クエリバッチ処理」といいます。
もちろん、すべてのケースでこれを行うことはできません。ディメンションを–viz に追加すると詳細レベルが変更されて、結果的に表示されるマークが増えるからです。ただしこれは、上の例のようにデータ内に階層リレーションシップがある場合は、表示される詳細レベルに影響がないため便利な手法です。
Viz LOD を使用してアクションを最適化する
アクションでも同様の手法を用いて、必要なクエリの数を減らすことができます。上の例の最適化する前のダッシュボードを使います。今度は `Country`] ワークシートから `Cities` ワークシートにフィルターアクションを追加します。
マップ上のマークをクリックすることでこのアクションをトリガーすると、Tableau はクエリを実行し `Cities` ワークシートの値を決定する必要があることがわかります。これは、`Cities` と `Country` のリレーションシップにあるクエリ結果のキャッシュにデータがないことが理由です。
`Country` を `Cities` ワークシートに追加すると、クエリ結果のキャッシュに十分な情報が入り、データソースに戻らなくてもこれらのフィルターを使うことができます。ソースワークシートがターゲットより詳細である状況でも、同様に最適化することができます。「すべてのフィールド」を使用してフィルターする、既定のアクション定義を使用する場合は、以下のようになります。
これにより、`Country` ワークシートのクエリ結果キャッシュから取得できない`Country` と `Cities`をフィルター句が参照するため、ワークブックはアクションごとにクエリを実行することになります。
code:sql
SELECT Superstore APAC.Country AS Country,
SUM(Superstore APAC.Sales) AS sum:Sales:ok
WHERE ((Superstore APAC.Cities = 'Sydney') AND ([Superstore
APAC].Country = 'Australia'))
GROUP BY Superstore APAC.Country
アクションを `Country` のみでフィルターするように変更した場合、次のようになります。
今度はクエリ結果のキャッシュからフィルターをかけることができるため、データソースにクエリを戻す必要がありません。このように、詳細レベルの変更がワークシートの設計に影響する場合は考慮が必要です。影響しない場合でも、便利な手法となる可能性があります。
優れたワークシート設計
ダッシュボードから 1 レベル掘り下げて、ワークシートを見てみましょう。Tableau では本来、ワークートの設計は実行されるクエリに関連しています。各ワークシートでは、1 つ または複数のクエリが生成されます。そこで、このレベルでは最適なクエリの生成を試みます。
必要なフィールドのみを含める
`詳細` シェルフを確認して、viz で直接使用するフィールド、ツールヒントに必要なフィールド、要求されたマークの詳細レベルを出すためのフィールド以外はすべて削除します。これでデータソース内のクエリ実行が速くなり、クエリ結果に返すデータの量が少なくて済みます。すでに見てきたように、このルールには例外があります。クエリバッチ処理により、同様のクエリが他のワークシートで実行されないようにする場合などです。ただし、これらはあまり一般的ではなく、ワークシートのビジュアルの詳細レベルを変えない場合に限ります。
マークの数を最小限表示して質問に答える
Tableau では、同じ数値を計算する方法が複数あることがよくあります。下のダッシュボードを見てください。両方とも「国ごとの平均オーダーサイズは?」という質問に答えています。
シート 1 では単一のマークのみ表示しており、各国の平均オーダーサイズを示しています。したがって、データソースから返すレコードは 23 件だけです。しかし、シート 2 では各国の各オーダーを表示しており、平均はリファレンスラインとして計算しています。ここでは、データソースから 5436 件のデータを取得する必要があります。
元の質問、つまり国ごとの平均オーダーサイズにだけ興味がある場合は、シート 1 の方が良いソリューションです。しかしシート 2 はその質問に答えながら、オーダーサイズの範囲についてより深いインサイトを提供し、外れ値も特定できます。
Viz が複雑になり過ぎないようにする
重要な指標として、各 viz でレンダリングされるデータポイントの数があります。これは、Tableau Desktop ウィンドウのステータスバーを見れば確認できます。
「マークが多過ぎる」状況を明確に定義するルールはありませんが、マークが多いほど強力な CPU と RAM がレンダリングに必要であることを認識してください。大きなクロス集計、散布図、および/または複雑なカスタムの多角形が表示されたマップには注意しましょう。
マップ
カスタムジオコーディング
カスタムジオコーディングロールをインポートすると、ジオコーディングデータベースに書き込まれます。 これは–Firebird DB ファイルで、既定では `C: \Program Files\Tableau\Tableau 10.0\Local\data\geocoding.fdb` に格納されています。ワークブックのロールを使用し、パッケージドワークブックとして保存する場合は、データベースファイル全体が TWBX ファイルに圧縮され、合計で約 350 MB にもなります。
これにより、作成された TWBX ファイルは a) 非常にサイズが大きく、ジオコーディングのサイズが圧縮されても約 110 MB になり、b) 最初の展開時にはずっと大きいデータセットを扱う必要があるため、開くのにかなり時間がかかります。さらに効率的なアプローチは、データをカスタムジオコーディングロールとしてインポートせずに、分析データと地理空間データを組み合わせるためにワークブック内でブレンディングを使用することです。このアプローチを用いると、geocoding.fdb ファイルは埋め込まれずに TWBX に分析とカスタムジオコーディングデータのみが含まれることになります。
地域区分のカスタマイズ
Tableau 10 の新機能に、地域区分のカスタマイズがあります。これを使ってユーザーは、内部のジオコーディングデータベースのエリアを結合して集計された地域を作成できます。
多数の低レベルの地域に基づいて実行される地域区分のカスタマイズの初期レンダリングには非常に時間がかかるため、この機能は慎重に使ってください。ただし、これを一度実行した後には、カスタマイズされた地域区分がキャッシュされるため高いパフォーマンスが期待できます。
色塗りマップとポイントマップ
色塗りマップのマークは (マップ上で使用される場合、または別のタイプのグラフでマークとして使用される場合に関わらず)、クライアント側でレンダリングすると、高くつくことがあります。これは、形状のための多角形データを送る必要があり、これが非常に複雑な作業になるとがあるためです。レンダリングのパフォーマンスが遅いことに気づいたら、代わりにシンボルマップの使用を検討してください。
多角形マーク
多角形のマークを使用するビジュアライゼーションでは、Tableau Server でサーバー側レンダリングが実行されるようにします。これは、エンドユーザーの操作性に影響する可能性があります。これは控えめに使用してください。
その他の要素
大きなクロス集計
このドキュメントの初期のバージョンでは、大きなクロス集計はレンダリングが非常に遅いこため、使用しないことを推奨しました。このタイプのビジュアライゼーションの根本的な仕組みは最近のリリースで改善されており、クロス集計は他の小さい複数のチャートタイプと同様に速くレンダリングできるようになりました。ただし引き続き、大きなクロス集計の使用には慎重になるようアドバイスします。大量のデータを参照元データソースから読み取る必要があり、分析に役立たないためです。
ツールヒント
既定では、ディメンションをツールヒントシェルフに配置すると、ATTR() 属性関数を使用して集計されます。このとき参照元データソース内で MIN() と MAX() という 2 つの集計を実行する必要があり、両方の結果を結果セットに戻します。詳しくは、このドキュメントで後述する ATTR() の使用のセクションをお読みください。
複数のディメンション値があっても差し支えなければ、既定の ATTR() でなく 1 つの集計だけ使用する方がさらに効果的です。MIN() か MAX() のどちらかを選択します。どちらを使用しても構いませんが、1 つ選択したらそれだけを使用してキャッシュのヒット率が最大になるようにします。
別の方法は、viz の詳細レベルが影響を受けないことが分かっている場合は、ディメンションをツールヒントシェルフでなく詳細レベルシェルフに配置することです。こうすることで、ディメンションフィールドをクエリの SELECT と GROUP BY 句で直接使用できるようになります。データプラットフォームのパフォーマンスに依存することがあるので、集計が 1 つの場合よりもパフォーマンスが優れているかどうかテストすることを推奨します。
凡例
一般的に凡例は、クエリ結果キャッシュからその項目に書き込まれるためパフォーマンス問題の原因とはなりません。ただし、データをクライアントブラウザに転送する必要があるために、列挙された項目が大きくなっている場合は、レンダリングのオーバーヘッドが増大する可能性があります。この場合、凡例は基本的に役に立たないので削除してください。
ページシェルフ
一部のユーザーは、ページシェルフがフィルターシェルフと同様の機能を果たし、データソースから返されるレコード数を減らすと考えています。それは正しくありません。ワークシートに対するクエリは、すべてのページにわたりすべてのマークのレコードを返します。高密度のページディメンションを含むページがある場合 (一意の値が多数ある場合)、ワークシートクエリのサイズが著しく増加し、パフォーマンスに影響を及ぼします。この機能の使用は控えめにしてください。
クライアント側レンダリングとサーバー側レンダリング
ビューのマークやデータは、クライアントの Web ブラウザに表示される前に取得、解釈、およびレンダリングされます。Tableau Server では、このプロセスをクライアントの Web ブラウザでもサーバーでも実行できます。クライアント側レンダリングは既定モードです。これは、サーバーでレンダリングとすべての操作を処理すると、ネットワークデータ転送とラウンドトリップ遅延が増大するためです。クライアント側レンダリングにすると、解釈やレンダリングがブラウザで実行されるため、ほとんどのビューの操作が速くなります。
ただし、ビューによっては、計算能力の高いサーバーでレンダリングを行ったほうが効率が良くなる場合もあります。サーバー側レンダリングは、画像ファイルに必要な帯域幅が、その画像を作成するのに使用されるデータよりも大幅に少ない、複雑なビューに適しています。また、タブレットの場合は一般にPC よりもパフォーマンスがずっと遅いため、複雑なビューの取り扱いには適していません。ただしその代わりに、ツールヒントやハイライトのような単純な操作は、サーバー側レンダリングはサーバーとのラウンドトリップが必要なことから遅くなることがあります。
Tableau Server は、これらすべての状況に自動で対応するように設定されています。その際、Web ブラウザではなく、サーバー上でビューのレンダリングを行うトリガーとして、複雑性しきい値を使用します。このしきい値は PC と 携帯デバイスで異なるため、PC の Web ブラウザで開いたビューがクライアント側レンダリングでも、タブレットで同じビューを開くとサーバー側レンダリングになる場合があります。フィルターによっても、レンダリングの動作が変わることがあります。ワークブックが最初にサーバー側レンダリングを使用して開いても、フィルターが適用されるとクライアント側レンダリングに変わる可能性があります。また、viz で多角形マークやページシェルフを使用する場合は、別の方法でクライアント側レンダリングの条件を満たしている場合でも、サーバー側レンダリングのみを使用するため、これらの機能を使用する際は注意が必要です。
管理者は、この設定を–PC 用とタブレット用にテストしたり、微調整したりすることができます。詳細については、次のリンクを参照してください。
https://onlinehelp.tableau.com/current/server/ja-jp/browser_rendering.htm
効率的なフィルター
Tableau のフィルターは非常に強力で、表現力に優れています。しかし、非効率的なフィルターが原因で、ワークブックやダッシュボードのパフォーマンスが低下することもよくあります。以下のセクションに、フィルターを使用する際のベストプラクティスを多数提供しています。なお、フィルターの効率性は、データソース内のインデックスの有無とインデックスの維持によって大きく左右されます。詳しくは、インデックスに関するセクションをご覧ください。
フィルターの種類
フィルターの優先度
Tableau では、フィルターは次の順番で適用されます。
抽出フィルター
このフィルターはデータ抽出を使用するときにのみ適用できますが、その場合は他のすべてのフィルターの前に論理的に適用されます。参照元データソースから取得するデータを制限し、ディメンションフィルターまたはメジャーフィルターのいずれかにできます。さらに、ソースデータのプラットフォームに応じて、TOP または SAMPLE を実行し、返されるレコード数を減らすことができます。
データソースフィルター
データソースフィルターはライブ接続で使用できる最優先レベルのフィルターです。データソースフィルターとコンテキストフィルターの主な相違は、データソースフィルターがデータソース全体を対象としているのに対し、コンテキストフィルターは各ワークシートに設定されるという点です。つまり、パブリッシュ済みのデータソースで使用される場合、データソースフィルターを適用できますが、コンテキストフィルターはワークシートレベルで適用されるということです。データソースに制限を設けて、エンドユーザーが誤って大量のクエリを実行できないようにするための有効な方法として、データソースフィルターを利用できます。たとえば、データソースフィルターで制限したクエリをトランザクション表に配置し、過去 6 か月間のみを対象にすることが可能です。
コンテキストフィルター
既定では、Tableau で設定したすべてのフィルターは個別に計算されます。つまり、各フィルターは他のフィルターに関係なく、データソース内のすべての行にアクセスします。ただし、コンテキストフィルターを指定することにより、コンテキストフィルターを通過するデータのみが処理されるため、ユーザーが定義するその他すべてのフィルターを依存型にできます。コンテキストフィルターは、正しい答えを取得する必要があるときに使用してください (例: 上位 N 件のフィルタリング)。 たとえば、SUM(Sales) が上位の製品 10 点を地域別にフィルタリングして表示するビューを考えてください。 コンテキストフィルターを使わない場合、以下のクエリが実行されます。
code:sql
SELECT Superstore APAC.Product Name AS Product Name,
SUM(Superstore APAC.Sales) AS sum:Sales:ok
INNER JOIN (
SELECT TOP 10 Superstore APAC.Product Name AS Product Name,
SUM(Superstore APAC.Sales) AS $__alias__0
GROUP BY Superstore APAC.Product Name
ORDER BY 2 DESC
) t0 ON (Superstore APAC.Product Name = t0.Product Name)
WHERE (Superstore APAC.Region = 'Oceania')
GROUP BY Superstore APAC.Product Name
これは、世界の上位 10 製品についてオセアニアにおける貢献度を返します。 実際に必要なデータがオセアニア地域の上位 10 製品である場合、地域フィルターをコンテキストに追加すると以下のクエリが実行されます。
code:sql
SELECT TOP 10 Superstore APAC.Product Name AS Product Name,
SUM(Superstore APAC.Sales) AS sum:Sales:ok,
SUM(Superstore APAC.Sales) AS $__alias__0
WHERE (Superstore APAC.Region = 'Oceania')
GROUP BY Superstore APAC.Product Name
ORDER BY 3 DESC
従来、コンテキストフィルターはデータソース内の一時表として導入されたものでした。 今はそのようなことはありません。 ほとんどの場合、コンテキストフィルターは (上述のように) データソースクエリの一部として導入されているか、データエンジン内でローカルに処理されています。クエリのパフォーマンスを向上させる仕組みとしてコンテキストフィルターを使用する必要はなくなりました。
カテゴリー別ディメンションのフィルタリング
次のビジュアライゼーションを例に考えてみましょう。 オーストラリアの地図に郵便番号を示すマークが記されています。
この地図にフィルターを適用して、西オーストラリア州の郵便番号 (オレンジ色の点) のみを表示する方法はいくつかあります。
西オーストラリア州のマークをすべて選択し、選択したデータのみを保持する
西オーストラリア州以外のマークをすべて選択し、選択したデータを除外する
州ディメンションなどの別の属性で選択したデータのみを保持する
郵便番号の値または経度/緯度の値のいずれかで、範囲のフィルターを適用する
不連続
最初の 2 つのオプションを使用すると、選択したデータのみを保持するオプションと除外するオプションではパフォーマンスが低くなることが分かります。 実際、多くの場合フィルタリングしていないデータセットよりも処理速度が遅くなります。 これは、複雑な WHERE IN 句を使用することにより、あるいは多くの値がある場合には、選択された値を設定した一時的な表を作成し、INNER JOIN–を使ってこの表と主要な表を内部結合することにより、DBMS によるフィルタリングで選別される郵便番号の値が不連続のリストとして表されるためです。 マークの数がさらに多ければ、このようなクエリには膨大な時間とリソースが必要になります。この例で 3 つ目のオプションは、結果として得られるフィルター (WHERE STATE=”Western Australia”)が非常に単純で、データベースで効率良く処理できるため、速く実行できます。 ただしこの方法では、フィルターを表すのに必要なディメンションの数が増えるにつれて効率が悪くなり、最終的には投げ縄選択したデータのみを保持するオプションと同レベルのパフォーマンスになります
値の範囲
値の範囲指定フィルターを適用するやり方でも、データベースは単純なフィルター句(`WHERE POSTCODE >= 6000 AND POSTCODE <= 7000 または WHERE LONGITUDE < 129`) を求めることになるため、実行速度が速くなります。ただしこの方法は、フィルターや関連ディメンションの場合と異なり、ディメンションの濃度を上げてもこれ以上複雑にはなりません。結論として、値の範囲指定フィルターは多くの場合、不連続の値が項目別に分けられた大規模なリストよりも速く評価されます。 マークの数が多い場合は、できるだけ選択したデータのみを保持するオプションまたは除外するオプションよりも優先して使用する必要があります。
スライシングフィルター
スライシングフィルターはディメンション上のフィルターで、viz では使用されません (viz の詳細レベルの一部にはなりません)。 たとえば、国別の合計売上を表示する viz があり、これが地域ごとにフィルタリングされているとします。この場合、実行されるクエリは以下のようになります。
code:sql
SELECT Superstore APAC.Country AS Country,
SUM(Superstore APAC.Sales) AS sum:Sales:ok
WHERE (Superstore APAC.Region = 'Oceania')
GROUP BY Superstore APAC.Country
これらのフィルターは、集計の結果をスライスするとさらに複雑になります。 たとえば、上記の viz を、地域でフィルタリングするのではなく、利益率の高い製品上位 10 品目の売上を表示するようにフィルタリングする場合、Tableau では 2 つのクエリを実行する必要があります。 1 つは利益率の高い製品上位 10 品目を特定するために製品レベルで実行し、もう 1 つは最初のクエリ結果によって制限される国レベルで実行します。
code:sql
SELECT Superstore APAC.Country AS Country,
SUM(Superstore APAC.Sales) AS sum:Sales:ok
INNER JOIN (
SELECT TOP 10 Superstore APAC.Product Name AS Product Name,
SUM(Superstore APAC.Profit) AS $__alias__0
GROUP BY Superstore APAC.Product Name
ORDER BY 2 DESC
) t0 ON (Superstore APAC.Product Name = t0.Product Name)
GROUP BY Superstore APAC.Country
スライシングフィルターは、評価に高くつく場合があるので、使用するときは注意してください。また、ディメンションはクエリ結果のキャッシュの一部ではないため、スライシングフィルターでブラウザ内フィルタリングを高速に行うことはできません (クライアント側レンダリングとサーバー側レンダリングに関する前のセクションを参照)。
クロスデータソースフィルター
クロスデータソースフィルターは、Tableau 10 の新機能です。これにより、1 つまたは複数のフィールドを共有する複数のデータリソースに対してフィルターを適用できます。 リレーションシップはブレンディングと同様の方法で定義します。 つまり、名前/タイプの一致に基づいて自動で定義されるか、データメニュー内のカスタムリレーションシップ経由で手動で定義されます。クロスデータベースフィルターは、ダッシュボード上のクイックフィルターと同様、パフォーマンスと密接な関係があります。 このフィルターを変更すると、複数ゾーンで更新が発生して複数のクエリの実行が必要になる可能性があります。 この機能は慎重に使用してください。 ｈユーザーが複数の変更を行うことが予想される場合は、選択が完了した後にのみクエリを開始できるように、`適用`ボタンを表示することを検討してください。
また、フィルターの領域は「一次」データソースから取り込んでいることにも留意してください。「一次」データソースとは、フィルターが作成されたシートの最初に使用されるデータソースです。関連フィールドが異なるデータソース内に異なる領域を持っている場合、下図のように同一のフィルターが異なる値を表示する結果となる可能性があるため、どれを使用するか注意しなければなりません。
日付のフィルタリング: 不連続、範囲指定、相対
日付フィールドは特殊な種類のディメンションであるため、Tableau では標準のカテゴリーデータとは異なる方法で処理されることがよくあります。 これは、日付フィルターを作成する場合に特に当てはまります。 日付フィルターは非常に一般的で、次の 3 つのカテゴリーがあります。 特定の日付を基準とした日付範囲を示す相対日付フィルター、定義済みの不連続な日付の範囲を示す範囲指定日付フィルター、およびリストから選択した個別の日付を示す不連続日付フィルターです。 上記のセクションで説明したとおり、使用する方法はクエリの効率に重大な影響を与える可能性があります。
不連続
特定の日付または日付レベル全体を含めるフィルターが必要な場合があります。 このタイプのフィルターは不連続日付フィルターと呼ばれます。 これは、範囲ではなく不連続の値を定義するためです。
このタイプのフィルターでは、日付式が動的計算としてデータベースに送信されます。
code:sql
SELECT FactSales.Order Date, SUM(FactSales.SalesAmount)
WHERE (DATEPART(year,FactSales.Order Date) = 2010)
GROUP BY FactSales.Order Date
ほとんどの場合、クエリ最適化ツールは DATEPART 計算を合理的に求めますが、不連続日付フィルターを使用するとクエリの実行パフォーマンスが低下するケースもいくつかあります。 たとえば、日付のパーティションキーで不連続日付フィルターを使用して分割された表に対してクエリを実行するとします。 この表は DATEPART 値で分割されていないため、データベースによっては、必要がなくても、すべてのパーティションにわたって計算を求め基準に一致するレコードを探すことがあります。 この場合、「日付の範囲」フィルターまたは特定の日付を基準とした相対日付フィルターを使用することで、パフォーマンスの大幅な向上が見られる場合があります。
この種のフィルターのパフォーマンスを最適化する方法の 1 つに、計算フィールドのデータを計算済みのデータとしてデータ抽出に持つ方法があります。 まず、DATEPART 関数を明示的に実装する計算フィールドを作成します。 その後 Tableau データ抽出を作成すると、この計算フィールドは保存された値として抽出に持ち続けることができます (式の出力が決定性であるため)。 動的な式ではなく、計算フィールドに対してフィルタリングを行うほうが処理が速くなります。 クエリの実行時に計算する代わりに値を検索できるためです。