有用な Tableau ワークブックを
設計するための ベストプラクティス
第2版
Alan Eldridge
Tableau Software
2014 年 4 月 15 日
1
まえがき
はじめに、このドキュメントは、多くの作成者の手による資料の抜粋を組み合わせてまとめた
ものであると申し上げておきます。 筆者の行った作業は、それらを 1 つのドキュメントに集約
して体系化したことです。 各セクションの文章に見覚えのある読者の方もいらっしゃることで
しょう。すべてご存知の方もいらっしゃるかもしれません。 ここで、オリジナル資料を作成さ
れた方の功績をたたえるとともに、このドキュメントの作成にあたり、著作権を主張せず快く
ご協力くださったことに心から感謝します。
このドキュメントでは、Tableau 8.1 の機能を説明すると同時に、Tableau 8.2 に登場すると思わ
れる変更点にも触れています。 Tableau のアップグレードで新機能が登場するのを受け、ガイ
ドラインが一部変更になることがあります。
2
目次
まえがき .................................................................................................................................................... 2
「有効性」の定義....................................................................................................................................... 5
お客様のために ................................................................................................................................... 5
基本原則............................................................................................................................................... 5
パート 1 - ワークブックの設計.................................................................................................................. 7
Tableau の得意分野 ............................................................................................................................. 7
Tableau の不得意分野 ......................................................................................................................... 8
設計 - よいアプローチと悪いアプローチ ............................................................................................. 9
パート 2 - データ接続 ............................................................................................................................. 13
ファイルベース .................................................................................................................................... 13
リレーショナル .................................................................................................................................... 15
Hadoop ................................................................................................................................................ 18
OLAP .................................................................................................................................................... 19
クラウドベース .................................................................................................................................... 19
Data Server .......................................................................................................................................... 21
抽出..................................................................................................................................................... 21
パート 3 - クエリ ...................................................................................................................................... 30
クエリの把握 ....................................................................................................................................... 30
パフォーマンスの記録........................................................................................................................ 30
結合カリング ....................................................................................................................................... 32
ブレンディング..................................................................................................................................... 33
フィルター ............................................................................................................................................ 39
パート 4 - 計算 ........................................................................................................................................ 48
基本的な計算と集計計算 .................................................................................................................. 48
表計算................................................................................................................................................. 48
計算とネイティブ機能 ......................................................................................................................... 49
データ型の影響 .................................................................................................................................. 49
パフォーマンス向上のためのテクニック............................................................................................ 50
パート 5 - デスクトップかサーバーか ..................................................................................................... 54
3
一般的なガイドライン ......................................................................................................................... 54
構成..................................................................................................................................................... 54
Tableau Server の監視........................................................................................................................ 55
キャッシュ ............................................................................................................................................ 55
パート 6 - その他の要因 ........................................................................................................................ 60
環境要因............................................................................................................................................. 60
付録 A - リレーショナルと OLAP の機能..................................................................................................... 61
4
「有効性」の定義
「有効」なワークブックにはいくつかの要件があります。 それらの要件には技術的なものとユ
ーザーに起因するものがありますが、一般に、有用なワークブックとは、次のようなワークブ
ックです。
「ビジュアル分析の原則」を利用して、作成者のメッセージやデータを効率よく伝える
ことができ、場合によってはユーザーによる操作も可能なワークブック。
応答時間の短いワークブック。 主観的な評価基準ではありますが、ファイルを最初に開
くときやユーザーが操作したときに、数秒で情報を表示できるワークブックを目指して
います。
このドキュメントの第 1 部では、上記の 1 つ目の点、主にワークブックの設計について説明し
ます。 第 2 部では、ワークブックのパフォーマンスにかかわる要素について説明します。 後で
詳しくご説明しますが、ワークブックのパフォーマンスにかかわる要素はさまざまで、次のよ
うなものが挙げられます。
データ接続
クエリ
計算
ビジュアライゼーション設計
Tableau Desktop と Tableau Server との違い
お客様のために
長年の経験から、お客様がぶつかる問題の多くはワークブック関連であることが分かっていま
す。 Tableau ではこれらを解決し、さらに望ましくは教育を通じて問題を防ぎ、ワークブック
を最適化して有用なものにすることを目指しています。
基本原則
ワークブックのパフォーマンスに影響する機能について技術的な詳細を論じる前に、有用なダ
ッシュボードやビューを作成するうえで役に立つ大まかな原則を 3 つご紹介します。
過ぎたるはなお及ばざるがごとし
何についても言えることですが、よいものであっても度が過ぎればかえって害になります。 た
った 1 つのモノリシックなワークブックにすべてを詰め込もうとしてはいけません。 1 つの
Tableau ワークブックにはダッシュボードが 50 件入り、各ダッシュボードにはチャートオブジ
ェクトが 20 個入り、各オブジェクトはそれぞれ 50 件の異なるデータソースから情報を取得す
ることができます。しかし、処理速度は確実に遅くなります。
作成したワークブックがどうしてもそのようになってしまうという場合は、ファイルをいくつ
かに分けてみてはいかがでしょうか。 8.1 では、異なるワークブックからダッシュボードをコ
ピーできるため、この作業がとても簡単になりました。 ダッシュボードが必要以上に複雑なと
きは、単純化して、エンドユーザーをビューからビューへと誘導する操作性を加えることも検
討してみてください。 ドキュメントの数で Tableau の価格が変わるわけではありません。デー
タを分散してみましょう。
5
データベースの処理速度が Tableau の処理速度を決める
Tableau ワークブックが、ツールに関係なく実行速度の遅いクエリに頼っているのであれば、ワ
ークブックの速度も当然遅くなります。
次のセクションで、データベースを調整する際のヒントをご紹介します。クエリの実行速度を
改善するためにお役立てください。 また、Tableau の高速データエンジンを使用してクエリの
パフォーマンスを向上する方法についても説明します。
Tableau Desktop で遅ければ、Tableau Server でも遅い
Tableau Desktop で動作の遅いワークブックは、Tableau Server にパブリッシュしてもそれ以上速
くはなりません。 一般に、ワークブックのパフォーマンスは Tableau Server では若干遅くなり
ます。理由は 2 つあります。1 つは、サーバーリソースを共有するユーザーが複数いて、同時
にワークブックを作成しているため。もう 1 つは、ダッシュボードやチャートのレンダリング
を、各クライアントワークステーションで行うかわりにサーバーで行う必要があるためです。
例外は、Tableau Desktop がサーバーにはないリソース制限を受けている場合です。たとえば、
分析中のデータをサポートするのに十分な RAM が PC に備わっていないなどがこれにあたりま
す。 低スペックで RAM が 2GB のワークステーションで作業すると、動作が遅かったり、「メ
モリ不足」というエラーが出ることもあります。そのような場合は、ワークブックをパブリッ
シュすればサーバーのより大きなメモリや処理能力を利用できるため、許容できる速度までパ
フォーマンスが向上します。
6
パート 1 - ワークブックの設計
多くのユーザーにとって、Tableau を使っての作業は新しい経験です。有用なワークブックを作
成するためには、学んでおくべきテクニックやベストプラクティスがいくつかあります。 それ
でも、慣れないユーザーの多くが従来の設計手法を Tableau でも使用してしまい、残念な結果
を招いていることが分かっています。 このドキュメントでは、ビジネスデータ分析の新しいカ
テゴリーやデータ分析ツールの新しいカテゴリーの使用方法についてベストプラクティスを明
らかにし、ご紹介します。
Tableau の得意分野
Tableau Software は、ユーザーがデータを見て操作し、理解する際の、データの見せ方や操作方
法を変えようとしています。 そのため、従来のエンタープライズ版 BI プラットフォームのよ
うな機能や使用感をお届けしようとは思っていません。 Tableau は、次のようなワークブック
を作成する場合に最高の力を発揮します。
視覚的なワークブック - 人間が大量で複雑なデータを理解するうえで最も効果的な方法
は、視覚的表現を用いることです。これを裏付ける証拠はたくさんあります。 Tableau
は、チャート、図、ダッシュボードなどを使ってデータを提示するようデフォルト設定
されています。 表やクロス集計もサポートされており、それぞれの役割があります。こ
れらの最適な使用法は後で詳しくご紹介します。
操作性の高いワークブック – Tableau ドキュメントはそもそも、デスクトップ、Web、モ
バイルのいずれでもユーザーに操作性を提供できるよう設計されています。 印刷中心の
アウトプット(紙ベース、PDF などのデジタル文書)の生成を主とする他の BI ツールとは
異なり、Tableau が目指すのは、ユーザーが自分でデータを分析しビジネス上の問題を解
決できるような、操作性が高く豊かな機能やサービスを提供することです。
繰り返し分析できるワークブック - 発見とは、本質的に反復のプロセスです。 Tableau は、
質問から発見へ、発見から質問へというサイクルをすばやく行えるよう設計されていま
す。そのためユーザーは、仮定を立て、データを使って検証し、仮定を修正してもう一
度検証するという作業をスピーディに行なえます。
動作の速いワークブック - これまでの BI プロセスは時間のかかるものでした。 ソフトウ
ェアをインストールして構成するにも、データを分析できるように準備するにも、また、
ドキュメントやレポート、ダッシュボードなどを設計し実装するにも、すべてに時間が
かかりました。しかし、Tableau ならこれまでよりずっと速くソフトをインストールし、
サーバーに接続し、ドキュメントを作成できます。数週間から数か月かかっていた問題
解決の作業を、数分から数時間程度に短縮できることも少なくありません。
シンプルなワークブック - 従来のエンタープライズ版 BI ツールは、価格か、機能の複雑さ
のどちらかで、一般のビジネスユーザーの手に負えないものが多々ありました。 多くの場
合、ユーザーは、IT の専門家かパワーユーザーの手を借りないと思い通りのクエリやドキ
ュメントを作成できませんでした。 Tableau はハイテクに強くないユーザーでも直感的に
操作できるインターフェイスを備え、データベースやスプレッドシートの専門家でなくて
も、クエリを実行したり複雑なデータを分析したりできるようになっています。
見た目のいいワークブック - 「美の基準は見る人次第」と言いますが、視覚的コミュニ
ケーションには推奨されるベストプラクティスがあります。 Tableau では表示形式など
7
の機能により、一般ユーザーでも、効果的で理解しやすいチャートを、使用するデータ
に基づいて作成できるようになっています。
ユビキタスなワークブック - 1 つのプラットフォームを対象にドキュメントを作成する機
会は、年々減っています。 ユーザーは、デスクトップ、Web、モバイルと、プラットフ
ォームを問わずデータの表示や操作をする必要があり、データの状態も他のアプリケー
ションやドキュメントに埋め込まれているなど多岐にわたっています。 Tableau では、1
種類のドキュメントをパブリッシュし、パブリッシュしたドキュメントをあらゆるプラ
ットフォームで利用できます。その際、移植や再設計などの操作は必要ありません。
Tableau の不得意分野
Tableau は機能が豊富でパワフルなツールですが、ソリューションとして最適ではない場合もあ
ることを最初にご理解ください。 不可能なタスクがあるという意味ではありません。Tableau
は、元の設計仕様に含まれていないタスクでも、工夫次第で実行することができます。 しかし、
Tableau の開発段階では想定されていなかったタスクもあり、そのようなタスクを何とかして
Tableau で実行したとしても、努力が十分に報われない可能性もあります。結果として得られる
ソリューションも成果が上がらなかったり融通のきかないものになることがあります。
次のようなケースでは、要件を再検討するか、別のアプローチを検討することをお勧めします。
画面表示ではなく、紙への印刷を前提にデザインされたドキュメントが必要な場合。 つ
まり、複雑なページレイアウトを管理する必要がある場合、ページ分けや章立て、ヘッ
ダーやフッターのグループ化などの機能が必要な場合、正確な WYSIWYG フォーマットが
必要な場合などです。 Tableau でも複数ページのレポートを生成できますが、フォーマ
ット管理については、印刷向けの専用レポート作成ツールにはかないません。
カスタマイズされたドキュメントを複数の配信モードで送信する際に、プッシュ型配信
(または「バースト配信」)する複雑なメカニズムが必要な場合。 Tableau を使用してプッ
シュ型配信システムを構築することはできますが、Tableau の標準機能ではありません。
TABCMD ユーティリティを軸にカスタムソリューションを開発する必要があります。
Tableau 8 にはレポートのサブスクリプションという概念が採用されていますが、これは
ユーザーごとのプル型モデルであり、レポートのバースト配信とは異なります。
データの受け取り手側の主な利用方法が、データを別のフォーマット(多くの場合 CSV フ
ァイルや Excel ファイル)にエクスポートすることである場合。 これは、詳細データを含
む行がたくさんある表タイプのレポートでよくあるケースです。 改めて申し上げますが、
Tableau でも、ビューやダッシュボードのデータを Excel にエクスポートできます。しか
も、エクスポートのレベルをサマリーと詳細から選べます。 しかし、主な利用方法がエ
クスポートである場合、これは Tableau の本来の用途でない ELT (抽出・加工・書き出し)
プロセスに当たります。 レポート作成ツールよりも、ずっと効率的にこの作業を行える
ソリューションはたくさんあります。
非常に複雑な、クロス集計式のドキュメントが必要な場合。このようなドキュメントは、
複雑な小計機能や相互参照機能を含む既存のスプレッドシートレポートを再現している
場合も少なくありません。よくある例は損益計算書や貸借対照表などの財務諸表です。
また、シナリオモデリング、what-if 分析、さらには仮定データの変更などが必要になる
ことも考えられる場合が、これに当てはまります。 元になる精細度の高いデータがない
8
場合や、レポートのロジックが、レコードを合計値までロールアップするのでなくセル
参照に基づく場合、この形式のレポートには引き続きスプレッドシートを使用するほう
が適していることもあります。
設計 - よいアプローチと悪いアプローチ
Tableau では、エンドユーザーにとって操作性の高いレポートを作成できます。 Tableau Server
で配信される完成品は、データをただ見るだけでなく、ユーザー自身がデータを分析できるイ
ンタラクティブなアプリケーションです。 そこで、効果的な Tableau ダッシュボードを作成す
るためには、静的なレポートを作成するときのような考え方を改める必要があります。
以下は、Tableau を使い始めたばかりの作成者が作りがちなダッシュボードの例です。特に、
Excel や Access などのツールを使っていた人や、従来のレポート作成ツールを使った経験があ
る人は、ここで紹介する間違いをしてしまいます。 それは何もかも詰め込んだ表タイプのレポ
ートで、何種類ものフィルターが用意されているのが特徴です。ユーザーはこのフィルターを
使って、自分が見たい数件のレコードが表示されるよう表を絞り込んでいく必要があります。
Tableau ダッシュボードでは、これは悪い例です(実際、どんなダッシュボードでも好例とは言
えません)。 厳しいことを言えば、これは見せかけのデータ抽出プロセスです。ユーザーに、デ
ータを Excel など別のツールに移植して詳細な分析やチャート作成をしたいと思わせるからで
す。 好意的に解釈すれば、エンドユーザーがどのようにデータを分析したいか実際には分から
ないため、「最初の基準に基づいてすべての情報と絞り込み用のフィルターをご用意しました
ので、ご自由に分析してください」というやり方を採用した、と言えます。
9
以下は設計しなおしたダッシュボードです。まったく同じデータを使っています。 ここでは、
集計のレベルを最も高くしてあります。
1 つ以上の要素を選択すると、次のレベルの詳細が表示されます。
これを繰り返すたびに、より詳しいデータが明らかになっていきます。
最終レベルまで表示すると、最初にご紹介したクロス集計ダッシュボードと同じデータになり
ます。
10
データをどう提示するかを考えないようにしてください(この点は重要ですが、後で取り上げま
す)。 代わりに、このダッシュボードを使用する際の流れを考えるようにします。 自然に、左
から右へ、上から下へと視線が移動します。 この例では元になるデータ量が膨大ですが、ダッ
シュボードの役目は、エンドユーザーが徐々にデータを掘り下げ、自分が探している詳細なレ
コードにたどり着けるよう誘導することです。
ここで紹介した 2 つの例の最も重要な違いは、分析プロセスを通じてエンドユーザーをどのよ
うに誘導しているかです。 最初の例では、ユーザーが求めている可能性のあるレコードをすべ
て表示して広いところから始め、エンドユーザーが自分でフィルターを適用して、表示される
レコード数を少なくするようになっています。 この手法はそれ自体に問題を含んでいます。
1 つ目の問題は、エンドユーザーにデータを表示する前に実行する必要のある第 1 のク
エリが、本質的に最大のクエリ(「すべてのレコードを取得」)になることです。 実際の
データセットでこれを行うとなると、クエリを実行して Tableau エンジンにデータが届
くまでに、かなりの時間がかかってしまいます。 ソリューションに対するエンドユーザ
ーの印象を決めるうえで、第一印象は非常に重要です。起動して数秒以内に何も起こら
ないとなれば、印象が悪くなります。
2 つ目の問題は、数十万から数百万のマーク(クロス集計の各セルを「マーク」と言います)
を含むビューを作成するために、CPU やメモリのスペックが相当高いマシンが必要なこと
です。 そのようなマシンがなければ、また時間がかかり、システムの応答時間についての
印象が悪くなります。 Tableau Server で複数のユーザーがサイズの大きいクロス集計を作成
すると、パフォーマンスが低下し、最悪の場合にはメモリ不足が起こることも考えられま
11
す。 技術的に見るとこのような状況は「非常に悪いこと」であり、サーバーが不安定にな
る、エラーやその他のあらゆる不具合が起こるなど、エンドユーザーにとって好ましくな
い事態になるおそれがあります。 もちろん、サーバーにメモリを追加してこの可能性を低
く抑えることはできますが、それは対処療法であって根本的な解決にはなりません。
3 つ目の問題は、最初に適用するフィルターで絞り込みの程度が広くなりすぎるか狭くな
りすぎるかを判断するための文脈的な指針が、ユーザーに与えられていないことです。 第
1 のクエリで数万件ものレコードが返されてサーバーの RAM を使い尽くしてしまわないよ
う、レポートのユーザーが利用できるカテゴリーをすべて確認できているかどうかを知る
には、どうすればよいのでしょう。 それを知るには、手間のかかる方法以外ありません。
対照的に、設計しなおした例では、第 1 のクエリで最も高位の集計データのみをリクエストし
ます。
実行の必要がある第 1 のクエリが高度に集計されているため、返ってくるデータもほん
の数件のレコードに抑えられます。 設計の優れたデータベースで、これは非常に効率的
なアクティビティと言えます。第一印象を形成する応答時間もとても短くなり、システ
ムに対する印象も良くなります。 データを掘り下げるたびに実行される他のクエリも、
高位での選択内容によって集計され制約されています。 そのため、クエリを実行するの
も Tableau エンジンにデータが返ってくるのも、遅くなりません。
ダッシュボードを十分に完成したときにはより多くのビューが表示されますが、各ビュ
ーに含まれるマークの数は数十個に抑えられています。 それぞれのビューを生成するの
に必要なリソースは、システム上で多数のエンドユーザーがアクティブな場合ですらさ
さいなもので、メモリ不足におちいる可能性ははるかに下がります。
最後に、ナビゲーションの高位のレベルでは、販売量がカテゴリーごとに示されていま
す。 これにより、各選択肢に含まれる情報が多いか少ないかを判断する文脈が、ユーザ
ーに提供されます。 また、色別表示により、各カテゴリーの収益性も分かるようになっ
ています。 やみくもにナビゲートするのではなく、どのエリアに注目する必要があるか
が分かるため、ユーザーにとってデータがとても身近になります。
12
パート 2 - データ接続
Tableau のパワフルな機能の 1 つは、プラットフォームを問わずデータに接続できる機能です。
Tableau が接続できるプラットフォームは、大まかに分けて以下のいずれかに特徴付けられます。
ファイルベースのデータソース
リレーショナルデータソース
OLAP データソース
Web ベースのデータソース
データソースの種類ごとに長所と短所がありますので、個別に説明します。
Tableau 8.2 では、Mac OS X 用の Tableau Desktop がサポートされるようになりました。ただし、
Mac 用にサポートされるデータソースの種類は、当面の間 Windows と異なります。プラットフ
ォーム間の差を埋めるべく鋭意努力中ですが、一部のデータソースについては一方のプラット
フォームでのみサポートされることもあります。
ファイルベース
このカテゴリーには、ファイルベースのデータフォーマットがすべて含まれます。代表的な例
は、CSV などのテキストファイル、Excel スプレッドシート、MS Access などです。 ビジネスユ
ーザーは、よくこのフォーマットのデータを扱っています。それが、「管理された」データセ
ットの外部にデータを移動する際の常識だからです。
通常、Tableau では、この種のデータソースを Tableau の高速データエンジンにインポートする
ようユーザーにお勧めしています。 なぜなら、クエリの実行がかなり速く、またデータ値を保
存する際のファイルサイズを大幅に小さくできるからです。 ただし、ファイルが小さい場合や、
刻々と変化するデータを反映させるためにリアルタイムにファイルに接続する必要がある場合
は、ライブ接続も可能です。
ほとんどの場合、Tableau では Microsoft JET ドライバーを使用して、データソースへの接続、ク
エリの実行、抽出などを行っています。 このインターフェイス階層の制約によってエンドユー
ザーが直面する共通の問題については、次のページでご確認ください。
MS JET ドライバーには、読み込める列の数やサイズの点で制約があります。 読み込んだ
ファイルの列数は最大で 255 列、テキストフィールドも 255 文字で切り捨てられてしま
います。 このような制約については、次の掲示板のスレッドで詳細をご覧いただけます。
http://community.tableausoftware.com/thread/109727
テキストファイルや Excel スプレッドシートはデータ型が明確なデータソースでないため、
MS JET ドライバーはファイルの一番上から N 個の行を読み取り、各列に含まれるデータ
の種類を判断します。 しかしこれだけでは、ソースフィールドに保存されているデータ
の種類を正しく特定するには不十分なこともあります。 たとえば、読み取った値が数字
のみだからといってデータの種類を数値と判断したとしても、もっと下に文字のエント
リがないとは限りません。 次のナレッジベース文書に、この問題の回避策がいくつか紹
介されています。 http://kb.tableausoftware.com/articles/knowledgebase/tableau-does-notcorrectly-recognize-excel-columns
MS JET ドライバーは「COUNT DISTINCT」や「MEDIAN」を集計としてサポートしていません。
ファイルベースのデータソースにライブ接続している場合、これらの機能は Tableau
13
Desktop のインターフェイスでご利用いただけません。 最も簡単な回避策は、これらの機
能をサポートしている Tableau の高速データエンジンに、データを抽出することです。
MS JET ドライバーは 4GB を超えるサイズのファイルを読み込めません。 Excel や Access
も同様のファイルサイズ制限があるため、これらのツールで作成したファイルでは問題
ありませんが、非常にサイズの大きいテキストファイルでは問題の起こるおそれがあり
ます。 この問題を解決するため、Tableau はバージョン 6.1 で専用のテキスト解析ツール
を導入しました。 これにより、サイズ制限なしでテキストファイルを Tableau の高速デ
ータエンジンにインポートできるようになっています。このようなファイルに対して直
接クエリを実行すれば、パフォーマンスが著しく低下するのは必至です。まったくお勧
めできません。 ただし、この解析ツールには用途に関する制限があります。具体的には、
テキストファイルを正攻法で読み込む場合にのみ使用するということです。 計算やフィ
ルターがある場合は、MS JET ドライバーを使ってインポートしてください。
Tableau 8.2 では、ファイルベースのデータソース(具体的にはテキストファイルと Excel ワーク
ブック)用に新しいコネクタレイヤーが登場します。 この新しいコネクタを採用した目的の 1
つは、ファイルベースのデータソースに関する上記の問題の多くを解決するためであり、また、
Mac OS X 用の Tableau Desktop をサポートする目的もあります。
この新しいコネクタでは MS JET を使用しないため、前述の制約はありません。 ただし、違う
点もいくつかあります。
改善され
た項目
非対応と
なる点
テキスト
全般的な解析機能が大幅に向上
フィールドの種類を検出する機能が大
幅に向上(列数の増加、ロジックの改
善)
区切り文字やコードページの自動検出
データ内のヘッダーの有無に関する自
動検出機能の向上
JETになかったデータエンジン関数の
追加(COUNTD、MEDIAN、PERCENTILE、D
ATEPARSEなど)
IN/OUTセット
結合セット
秒の小数部を含む日付
YYYYMMDD式の日付
X%を数字として処理
列数を255列から増加
テキスト修飾子(引用符)の文字
解析の明示ロケール
Mac対応
JET SQL – RAWSQLとカスタムSQL
schema.iniに固定幅のファイルフォー
マット
右結合と完全結合
非平衡結合
14
Excel
全般的な解析機能が大幅に向上
フィールドの種類を検出する機能が大幅
に向上(列数の増加、ロジックの改善)
データ内のヘッダーの有無に関する自動
検出
フィールド名の改善
JETになかったデータエンジン関数の追
加(COUNTD、MEDIAN、PERCENTILE、DATEPA
RSEなど)
IN/OUTセット
結合セット
列数を255列から増加
整数の列を解析する際に、ダブルでなく
整数として解析
時刻を含まない日付の列を解析する際
に、日時でなく日付として解析
一重引用符のあるシートに対応(目立た
ない利点の1つです)
Mac対応
JET SQL – RAWSQLとカスタムSQL
Excel 3、4、5のファイルに対応
XLSB対応
右結合と完全結合
非平衡結合
Windows 用 Tableau をご利用の方には、必要に応じて MS JET ベースのレガシーコネクタに戻す
オプションもご用意しています。Mac 用 Tableau をご利用の場合、このオプションはご利用い
ただけません。
リレーショナル
Tableau ユーザーにはリレーショナルデータソースが最も一般的なタイプのデータソースであり、
Tableau では幅広いプラットフォームに対してネイティブドライバーをご用意しています。 行
ベースや列ベースのもの、パーソナル版やエンタープライズ版などがあり、アクセスにはネイ
ティブドライバーや汎用 ODBC を使用します。 技術的には、Map-Reduce データソースも Hive
や Impala などの SQL アクセスレイヤーを介してアクセスするため、このカテゴリーに含まれま
すが、これについては後で詳しく説明します。
RDBMS でのクエリ速度に影響する内的要因はたくさんあります。 これらの変更や調整には通常
データベース管理者のサポートが必要ですが、大幅なパフォーマンス向上につながります。
インデックス
データベースに正しいインデックスを付けることは、クエリのパフォーマンスを向上するうえ
で不可欠です。
表の結合の一部を構成する列のすべてにインデックスを付けるようにします。
Tableau 内のフィルターで使用されている列にはすべてインデックスを付けるようにします。
データベースによっては、不連続の日付フィルターを使用すると、クエリが日付列や日
付時刻列のインデックスを使用しないことがあります。 この点についてはフィルターに
関するセクションで詳しく述べますが、日付範囲フィルターを使うと日付インデックス
が確実に使用されます。 つまり、「YEAR([DateDim])=2010」とする代わりに、フィルタ
ーを「[DateDim] >= #2010-01-01# and [DateDim] <= #2010-12-31#)」と表します。
クエリ最適化ツールで高品質のクエリプランを作成できるようにするには、データで統
計を有効にしておきます。
DBMS 環境では多くの場合、クエリを確認して有用なインデックスを推奨する管理ツー
ルがあります。
参照整合性
Tableau は、参照整合性情報があると、複数の表にまたがるデータがどのように関連しているか
把握しやすくなります。 これを正しく構成することで、Tableau は効率のよいクエリを構築で
きます。
可能な限り、すべての表で主キーを明示的に定義します。
すべての外部キーの関係を明示的に定義します。 こうすると、データベースで検証が行
われていることが分かるため、Tableau は整合性チェックの大部分を省略できます。
区分の指定
データベースを区分するとは、大きな表を小さな別個の表(「パーティション」「シャード」な
どと言います)に分割することであり、これによりパフォーマンスが向上します。 つまり、スキ
ャン対象のデータ量が少なくなるため、または I/O に利用できるドライブが増えるため、クエ
15
リの実行速度が上がるのです。 区分はデータ量が多いときに推奨される方法で、Tableau に対
して透過的です。
Tableau で区分の威力が発揮されるのは、フィルターが適用されることの多いディメンション
(時間、地域、カテゴリーなど)にわたって区分を行い、クエリが 1 つのパーティション内のレ
コードのみを読み取ればよいように構成されたときです。
データベースによっては、区分インデックスを正しく使用するために日付範囲フィルター(不連
続フィルターではありません)が必要になる場合があります。このような場合に日付範囲フィル
ターを使用しないと、表を完全にスキャンしても結果は非常に悪くなります。
NULL
多くのデータベースでは、ディメンション列に Null 値があると、インデックスの効果が軽減さ
れることがあります。 可能な限り、ディメンション列は Null にならないよう定義します。
計算
Tableau では、計算フィールドは、データベースに送信され処理されるクエリの一部として表さ
れます。 計算が非常に複雑な場合、生成される SQL は最適なものでない可能性があり、改善の
余地があると考えられます。
そのような場合は、式を手動で調整するためのカスタム SQL ステートメントを作成するか(ただ
し、後述する問題点があります)、データベース内のビューまたは関数にある式を実装すること
ができます。
カスタム SQL
カスタム SQL でデータ接続を形成できることは非常に有効な機能ですが、パフォーマンスの点で
は制約があります。 表とは対照的に、カスタム SQL は絶対に分割できず、常に原子性をもって実
行されます。 その結果、データベースは次のような処理をするよう求められることになります。
SELECT SUM([TableauSQL].[Sales])
FROM (
SELECT [OrdersFact].[Order ID] AS [Order ID],
[OrdersFact].[Date ID] AS [Date ID],
[OrdersFact].[Customer ID] AS [Customer ID],
[OrdersFact].[Place ID] AS [Place ID],
[OrdersFact].[Product ID] AS [Product ID],
[OrdersFact].[Delivery ID] AS [Delivery ID],
[OrdersFact].[Discount] AS [Discount],
[OrdersFact].[Cost] AS [Cost],
[OrdersFact].[Sales] AS [Sales],
[OrdersFact].[Qty] AS [Qty],
[OrdersFact].[Profit] AS [Profit]
FROM [dbo].[OrdersFact] [OrdersFact]
) [TableauSQL]
HAVING (COUNT_BIG(1) > 0)
カスタム SQL を使用する際は、Tableau の高速データエンジンと併用することをお勧めします。 こ
うすると、原子性のあるクエリは一度のみ実行され(データをデータ抽出のためにロードする)、そ
れ以降 Tableau で行うすべての分析は、そのデータ抽出に対して動的で最適化されたクエリを使用
16
して行われます。 また、コンテキストフィルターに関する以下のセクションで、カスタム SQL の
結果を一時表の形にする処理をデータベースに実行させるテクニックを紹介します。
Tableau 8 以降では、カスタム SQL でパラメーターを使用できるようになりました。これにより、
基本のクエリがより動的になる(パラメーターを使用するフィルター句が適切に評価されるな
ど)ため、ライブ接続のパフォーマンスが向上することも考えられます。 また、「TOP」や
「SAMPLE」など、データベースから返されるデータ量を制限するパフォーマンスリミッターの
値を渡すのにも使用できます。 ただし、パラメーターはリテラル値を渡す場合にのみ使用でき
るものであり、「SELECT」句や「FROM」句を動的に変更するのには使用できません。
サマリー表
非常に規模が大きく詳細なデータセットがあり、通常クエリを実行する際に集計を行う場合(た
とえば、トランザクションを個別に保存してあるが、ふだんは日付、地域、顧客、製品などで
集計して使用する場合)は、サマリー表を作成し、それに対して Tableau を使用してクエリ速度
を上げることを検討してみてください。
なお、Tableau データ抽出を使用して集計データ抽出を作成することで、同様の結果を得られま
す。 詳しくは、抽出に関するセクションをご覧ください。
ストアドプロシージャ
Tableau 8.1 には、Sybase ASE、SQL Server、Teradata などのストアドプロシージャに対するサポート
が追加されています。 非常に複雑なロジックを実装する必要がある場合(ユーザーからの入力に基
づく場合など)は、カスタム SQL の代わりにこの方法を用いると効率がよくなることがあります。
Tableau 用のデータソースを定義するストアドプロシージャがある場合は、次の点を覚えておい
てください。
ストアドプロシージャにより結果セットが複数返されると、Tableau は最初のセットのみ
読み込み、残りを無視します。
ストアドプロシージャに出力パラメーターがある場合、Tableau はフィルターを適用して
そのストアドプロシージャを除外し、[接続]ダイアログボックスに表示しません。
非スカラー型のパラメーターがあるストアドプロシージャは除外されます。
Tableau に一致する型(varbinary 型、geometry 型、hierarchyid 型など)がない結果セット列
は記録されます。 結果セット列が不明なデータ型にマッピングする場合、Tableau は
「結果セット...に使用可能な列がありません」というメッセージを表示します。
結果セットを返さないストアドプロシージャも[接続]ダイアログボックスに表示されます
が、選択しても失敗します。
ストアドプロシージャに必要なパラメーターに値がないと、エラーになります。 パラメ
ーターが必要かどうかを Tableau が事前に判断することはできません。
Tableau が、ストアドプロシージャに対してトランザクション管理を実施することはあり
ません。 つまり、ストアドプロシージャの作成者は Tableau に依存すべきではなく、ス
トアドプロシージャを呼び出す前にトランザクションを開始してくれる、後でストアド
プロシージャをコミットしてくれるなどと考えてはいけません。
17
初期 SQL
カスタム SQL の代替方法としては、初期 SQL ブロックにカスタム SQL ステートメントを使用す
ることも挙げられます(データソースでサポートされている場合)。 この方法を使用すると、後
でクエリで選択される一時表を作成できます。 カスタム SQL はビジュアライゼーションが変更
されるたびに実行されますが、初期 SQL はワークブックを開くときに一度しか実行されないた
め、これによりパフォーマンスが大幅に向上することもあります。
Hadoop
Tableau 8.1 では、3 種類の Hadoop ディストリビューションと、以下のインターフェイスがサポ
ートされています。
Cloudera Hadoop
HortonWorks Hadoop Hive
HiveServer
Impala
Beeswax Server
Beeswax Server と Kerberos
HiveServer
HiveServer2
HortonWorks Hadoop Hive
MapR Hadoop Hive
HiveServer
HiveServer2
Hive は SQL-Hadoop トランスレーションレイヤーとして動作し、クエリを MapReduce にトラン
スレートして、HDFS データ上で実行できるようにします。 Impala は HDFS データ上で SQL ステ
ートメントを直接実行します(MapReduce は必要なくなります)。 通常 Impala は Hive よりずっ
と速いと言われていますが、この分野は変化が激しく、Apache Shark (Hive 対応)、Hortonworks
Stinger 他多数の新技術によりその差が埋められていく可能性もあります。
ただし、このような追加コンポーネントがあっても、Hadoop の応答性は、Tableau で作成され
るような分析クエリには不十分なこともよくあります。 クエリの応答時間を改善するには、多
くの場合、Tableau データ抽出を使います。抽出の詳細、抽出を「ビッグデータ」でどのように
活用するかなどは後で取り上げます。
Hadoop データソースでのパフォーマンス向上について詳しくは、次のページをご覧ください。
http://kb.tableausoftware.com/articles/knowledgebase/hadoop-hive-performance
18
OLAP
Tableau では次の OLAP データソースをサポートしています。
Microsoft Analysis Services
Microsoft PowerPivot (Excel 用 PowerPivot と SharePoint 用 PowerPivot)
Oracle Essbase
SAP BW
Teradata OLAP
OLAP に接続する場合とリレーショナルに接続する場合では、MDX と SQL の言語差または DAX と
SQL の言語差に基づく機能的な差がいくつかあります。重要なことは、Tableau ではどちらも同じ
ユーザーインターフェイス、ビジュアライゼーション、計算されたメジャーの式の言語などにな
るということです。 主な差はメタデータ(定義の方法と場所)、フィルタリング、合計や集計の方
法、データブレンディングの際にデータソースがどのように使用されるかなどに関するものです。
詳しくは付録 A をご覧ください。
Tableau 8.1 の新機能として、SAP BW キューブから Tableau のデータエンジンにデータを抽出で
きるようになりました。 Tableau は葉ノード(それより下に階層のないデータ)を検索し、それら
でリレーショナルデータソースを作ります。 多次元からリレーショナルに変換するときは、す
べてのキューブ構造が維持されるわけではないため、キューブ抽出では、ビジュアライゼーシ
ョンの状態に影響することなく抽出とライブ接続を自由に行き来することはできません。 ビジ
ュアライゼーションの構築を始める前に決めておかなければいけないことがありますが、すべ
てを事前に決定する必要はありません。 抽出後、複数の別名オプション(キー、長い名前など)
を切り替えることができます。
クラウドベース
Tableau は現在、以下の Web ベースのデータソースをサポートしています。
Salesforce.com
Google アナリティクス
oData
Windows Azure Marketplace DataMarket
この最初のソース群は、Web サービスからデータレコードを読み出し、Tableau データ抽出フ
ァイルにロードします。 「ライブ接続」はこのようなデータソース向けのオプションではあり
ませんが、抽出ファイルを更新して含まれるデータをアップデートすることができます。
Tableau Server を使用すると、この更新プロセスを自動化し、スケジュール設定できます。
Amazon Redshift
Google BigQuery
Microsoft SQL Server Azure (SQL Server ドライバー経由)
これらもクラウドベースのデータソースですが、リレーショナルデータソースのように動作し、
ライブ接続も抽出も可能です。
19
Salesforce
Tableau を使用して Salesforce に接続すると、データは自動で Tableau データ抽出ファイルに抽
出されます。 文字数制限により、一部のフィールドが抽出されない場合もあります。 具体的に
は、4096 文字を超えるテキストフィールドや計算フィールドは抽出に含まれません。 データに
計算フィールドがある場合は、抽出後に Tableau でそのフィールドを再度作成する必要があり
ます。
また、Force.com API ではクエリの合計文字数を 10,000 文字に制限しています。 非常に幅の広
い表(列数が多く、列名も長いなど)を 1 つ以上接続すると、抽出時、制限に達してしまうおそ
れがあります。 そのような場合は、選択する列数を少なくし、クエリの規模を小さくする必要
があります。 企業に対しては、Salesforce.com がこのクエリの上限を引き上げることもあるた
め、 Salesforce の管理者に詳細をお問い合わせください。
Google アナリティクス
Google アナリティクス(GA)は、レポートに多数のディメンションが含まれる場合やデータ量が
多い場合に、データのサンプリングを行います。 (通常の GA アカウントで)所定の日付範囲内
の特定の Web ページに関するデータが表示回数 50,000 回を超える場合、GA は結果を集計して、
そのデータのサンプルセットを返します。 GA が Tableau にデータのサンプルセットを返すと、
Tableau はビューの右下隅に次のメッセージを表示します。
「Google アナリティクスによってサンプルデータが返されました。 接続に多数のディメンショ
ンまたは大量のデータが含まれている場合にサンプリングが発生します。 サンプリングがレポ
ート結果に与える影響の詳細については、Google アナリティクスドキュメントを参照してくだ
さい」
データがサンプリングされたことを知るのは重要です。なぜなら、すでにサンプルセットにな
っているデータをさらに集計することになれば、その推測値は非常に偏って正確でないものに
なる可能性があるからです。 たとえば、データの中でもめずらしいカテゴリーがサンプリング
されたサンプルセットを集計したとします。 すると、集計されたサンプルセットの推測値は、
そのカテゴリーに含まれるサンプル数が不十分なために偏っていることがあります。 データを
正確に推測できる GA ビューを構築するには、推測するカテゴリーに十分な数のサンプルがあ
るようにします。 推奨される最小のサンプル規模は 30 件です。
GA のサンプル規模を調整する方法や、GA のサンプリングについて詳しくは、GA ドキュメント
をご覧ください。
http://support.google.com/analytics/bin/answer.py?hl=en&answer=1042498
サンプリングが起こるのを避ける方法は 2 つあります。
セッションまたはヒットレベルで複数の GA レポートを実行し、データをサンプリング
されない塊に分割します。 その後データを Excel ファイルにダウンロードし、Tableau
の抽出エンジンを使用してファイルからデータを追加し、データを 1 つのデータセット
に再構成します。
20
GA アカウントをプレミアムアカウントにアップグレードします。これで、レポートに
含められるレコード数が増加します。 これで、分析に向けてデータを塊にするのもかな
り簡単になります。 今後について言うと、Google は、GA プレミアムユーザーがセッシ
ョンやヒットレベルデータを Google BigQuery にエクスポートし、さらに分析できるよ
うにすると発表しました。 Tableau は BigQuery に直接接続できるため、データへのアク
セスがさらに簡単になります。
ちなみに、Tableau が GA へのクエリに使用する API では、クエリのディメンションは最大で 7
個、メジャーは 10 個に制限されます。
Data Server
これ自体はデータソースではありませんが、データソースに接続するもう 1 つの方法に、
Tableau Server の Data Server を経由する方法があります。 Data Server はライブ接続とデータ抽
出の両方をサポートし、スタンドアロン型のデータ接続にまさる利点がいくつかあります。
メタデータが Tableau Server に一元的に保存されるため、それを複数のワークブックで、
また、複数の作成者やアナリストで共有できます。 ワークブックには一元化されたメタ
データの定義へのポインターが含まれ、ワークブックが開かれるたびに、変更が行われ
たかがチェックされます。 変更があった場合には、ワークブックに埋め込まれているコ
ピーを更新するよう、ユーザーにメッセージが表示されます。 つまり、ビジネスロジッ
クに対する変更を 1 か所でのみ行うだけで、変更内容はそのロジックを使用するすべて
のワークブックに反映されます。
データソースがデータ抽出の場合、複数のワークブックにわたって使用できます。 Data
Server を使わなければ、ワークブックごとにその抽出のローカルコピーを含めることに
なります。 Data Server を使うと不必要なコピーの数が減り、サーバー上に必要な保存領
域や更新プロセスの重複を削減することにつながります。
データソースがライブ接続の場合、データソース用のドライバーを各アナリストの PC に
インストールする必要はありません。Tableau Server にのみインストールしてください。
Data Server が、Tableau Desktop からのクエリに対するプロキシとして動作します。
抽出
ここまでは、データがオリジナルフォーマットのままのデータ接続に関して、そのパフォーマ
ンスを向上するためのテクニックをご紹介してきました。 これらはライブデータ接続といい、
ライブデータ接続では、パフォーマンスの面でも機能の面でもソースデータのプラットフォー
ムに依存していました。 ライブ接続でパフォーマンスを向上するためには、データソースに変
更を加える必要があることも少なくありませんが、どうしてもこれができないお客様も多数い
らっしゃいます。
誰でも実行可能な代替方法は、Tableau の高速データエンジンを活用し、ソースデータシステム
から Tableau データ抽出にデータを抽出することです。 「抽出」の定義は以下のとおりです。
ディスクに書かれていて再現可能なデータの持続キャッシュ
多桁式データストア(分析クエリに対してデータが最適化されたフォーマット)
21
クエリ中はデータベースから完全に接続解除。 事実上、抽出はライブデータ接続の代わ
りです
抽出を完全に再生成するか、既存の抽出にデータの行を徐々に追加することで、更新可
能
アーキテクチャを意識。ほとんどのインメモリ技術とは異なり、利用可能な物理的 RAM
の量による制約を受けません
移植可能。抽出はファイルとして保存されるため、ローカルハードドライブにコピーし
て、ユーザーが企業ネットワークに接続していないときにも使用できます。 また、
Tableau Reader 用に配信されるパッケージドワークブックにデータを埋め込む際にも使用
できます。
多くの場合、参照元のライブデータ接続よりはるかに速い動作
The Information Lab の Tom Brown 氏が、抽出が有利に働く用途を説明するすばらしい記事を書
いています。他のユーザーが別の例を紹介しているコメントも、あわせてお読みください。
http://www.theinformationlab.co.uk/2011/01/20/tableau-extracts-what-why-how-etc/
なお、抽出はデータウェアハウスの代わりというより、補完的に作用します。 どちらも時間を
かけたデータの収集および集計（たとえば周期的な増分更新など）に使用できますが、抽出は、
長期的ソリューションとしてよりも、限定的なソリューションとして使用することをお勧めし
ます。 増分更新では、処理済みのレコードに対するアクションの更新や削除をサポートしてい
ません。これらを変更するには、抽出を完全にロードしなおす必要があります。
最後に、SQL Server Analysis Services や Oracle Essbase などの OLAP データソースでは抽出を作成
できません。 ただし、Tableau 8.1 では SAP BW から抽出を作成する機能を採用しています(上記
の関連セクションをご覧ください)。
抽出を使うケース、 ライブ接続を使うケース
データ抽出にも、使用に適した時と場所があります。 以下に、抽出が有利に働くシナリオをい
くつかご紹介します。
クエリの実行が遅い場合 - Tableau Desktop で生成されるクエリをソースデータシステム
で処理するのに時間がかかる場合、抽出を作成することで簡単にパフォーマンスを向上
できることがあります。 抽出データフォーマットは、本質的に、分析クエリに短い時間
で応答するよう設計されているため、このような場合には抽出をクエリ高速化キャッシ
ュと考えることができます。 接続の種類によっては(サイズの大きいテキストファイル、
カスタム SQL 接続などの場合)、これが推奨されるベストプラクティスであり、一部のソ
ースはこのモデルでのみ動作します(クラウドデータソースに関するセクションを参照)。
オフラインで分析する場合 - オリジナルのデータソースが利用できない状態でデータを
操作する必要がある場合(出張や在宅勤務でネットワークに接続していない場合など)がこ
れに該当します。 データ抽出はファイルとして持続し、ノートパソコンなどのポータブ
ル機器に簡単にコピーできます。 ネットワークへの接続状況が頻繁に変わる場合でも、
簡単に抽出とライブ接続を切り替えることができます。
22
Tableau Reader 用、Online 用、Public 用などのパッケージドワークブック - ワークブック
を共有して他のユーザーが Tableau Reader で開けるようにする場合、または Tableau
Online や Tableau Public にパブリッシュする場合は、パッケージドワークブックファイル
にデータを埋め込む必要があります。 埋め込み可能なデータソース(ファイルベースのデ
ータソース)をワークブックで使用している場合でも、データ抽出は本質的にデータ圧縮
のレベルが高いため、得られるパッケージドワークブックはずっと小さいサイズになり
ます。
追加機能 - 一部のデータソース(MS JET ドライバー経由のファイルベースのデータソース
など)ではサポートされていない機能が Tableau Desktop にあります(中央値、個別カウン
ト、ランク、百分位集計、 セットの IN/OUT 操作など)。 データを抽出すると、これらの
機能を簡単に有効にできます。
データセキュリティ - ソースデータシステムからデータのサブセットを共有する場合、
抽出を作成して他のユーザーが利用できるようにすることが可能です。 含めるフィール
ドや列の数を制限したり、個別のレコードレベルのデータの代わりにサマリー値を他の
ユーザーに見せたい場合は集計データを共有したりすることができます。
抽出は非常に強力な機能ですが、すべての問題に対する特効薬ではありません。 抽出の使用が
不適切なこともあるシナリオを以下にご紹介します。
リアルタイムデータ - 抽出はある時点におけるデータのスナップショットであるため、
分析にリアルタイムデータが必要な場合は使用に適しません。 Tableau Server を利用して
抽出を自動更新することは可能であり、多くのお客様が日々この方法を実践しています
が、真にリアルタイムのデータにアクセスするにはライブ接続が必要です。
膨大なデータ - 対象となるデータ量が膨大な場合(「膨大」の定義はユーザーによって異
なりますが、一般にレコード数が数百万件から数十億件ある場合を指します)、抽出は実
用的ではありません。 得られる抽出ファイルも、サイズが大きすぎるか、作成プロセス
に何時間もかかることがあります。 ただし、このケースにはいくつか例外があります。
ソースデータセットが膨大であっても、実際に作業するのはこのデータにフィルタリン
グ、サンプリング、集計処理などを行って得られたサブセットである場合、抽出が適し
ていることも大いに考えられます。 一般論を言えば、Tableau 抽出エンジンは数億件の
レコードまでなら十分扱えるよう設計されています。ただし、これはデータの形状や密
度に左右されます。
パススルーRAWSQL 関数 - ワークブックでパススルー関数を使っている場合、データ抽出
には適しません。
ユーザーレベルのセキュリティが強固な場合 - ユーザーレベルのセキュリティを強固に
する必要がある場合は、データソースに実装する必要があります。 ワークブックレベル
で適用されるユーザーレベルのフィルターがある場合、ユーザーはこれらをいつでも削
除でき、抽出に含まれるすべてのデータにアクセスできるようになります。 このケース
での例外は、データソースフィルターがある状態で抽出が Tableau Server にパブリッシュ
されており、他のユーザーは Data Server を経由してこの抽出にアクセスしている場合で
す。 ただし、ユーザーのダウンロード許可を取り消し、実装済みのフィルターを迂回で
きないようにする必要があります。
23
抽出の作成
この部分は簡単です。Tableau Desktop のご利用を前提に説明します。 データに接続したら、
[データ]メニューに移動し[データの抽出]をクリックします。次にダイアログボックスのデフォ
ルトに同意します(詳しくは後述します)。 Tableau に抽出の保存先をたずねられるので、ファ
イルの保存先を選択します。Tableau から「My Tableau Repository | Datasources」を提案します
が、そこでも別の場所でも構いません。
後は抽出が作成されるのを待つだけです。所要時間は、使用するデータベーステクノロジー、
ネットワーク速度、データ量などによります。また、抽出の作成はメモリやプロセッサを大量
に使用するため、お使いのワークステーションの処理速度や容量にも左右されます。
データソースのアイコンが変化して、作成終了を知らせます。アイコンの後ろに別のデータベ
ースのアイコンが表示されます。コピーであることを表すもので、これこそが抽出の定義です。
抽出を最初に作成するときは必ず Tableau Desktop 上またはデータ抽出 API 経由で実行されるた
め、ワークステーションに作成されます。 ワークステーションのスペックが、タスクの実行に
十分であるか確認する必要があります。 抽出の作成には、CPU、RAM、ディスク容量、ネット
ワーク I/O などあらゆる種類のリソースを使用します。また、スペックの低い PC で大量のデー
タを処理する場合、いずれかのリソースが不足するとエラーが起こります。 大規模な抽出には、
それに適したワークステーション(コアプロセッサが複数ある CPU が速い、RAM が大容量、I/O
が速いなど)を使用することをお勧めします。
抽出作成プロセスには、作業ファイルを書き込む一時ディスクスペースが必要です。Tableau
8.1 以前では、最大で得られる抽出ファイルの二乗に相当するスペース(100MB の抽出ファイル
では数 GB の一時スペース)が必要でしたが、Tableau 8.2 ではこれが大幅に縮小され、プロセス
に必要なスペースは最終的な抽出ファイルサイズの 2 倍となっています。 作業スペースは、
TEMP 環境変数で指定されるディレクトリ(通常は C:\WINDOWS\TEMP または
C:\Users\USERNAME\AppData\Local\Temp)に割り当てられます。 このドライブのスペースが不十
分な場合は、環境変数でより容量に余裕がある場所を指定します。
24
ワークステーションで初期抽出プロセスを実行できない場合(または非実用的な場合)、次の回
避策を行うと、後で Tableau Server にパブリッシュするよう空の抽出を作成できます。 まず、
DateTrunc(“minute”, now())を含む計算フィールドを作成します。 次に抽出フィルターを追加
し、表示される単一の値を除外します。1 分後にはフィルターが有効でなくなるため、この操
作は手早く行ってください。 もっと時間が必要な場合は、パブリッシュ間隔を広めにとります
(5 分、10 分、必要に応じて 1 時間など)。 これで、空の抽出がデスクトップに作成されます。
サーバーにパブリッシュして更新スケジュールをトリガーすると、除外したタイムスタンプが
すでに変わっているため、完全な抽出が入力されます。
抽出時の集計
抽出時の集計を使用すると、パフォーマンスは必ず向上します。 Teradata や Vertica で膨大な量
のデータを扱っているとしても、データの集計やフィルタリングを適切に行えば、データ抽出
による効果を得られます。 たとえば、最新のデータのみが問題であれば、そのデータをフィル
タリングできます。
必要なフィールドを選択し、Tableau Desktop の[データの抽出]ダイアログボックスにある[表示
可能なディメンションのデータの集計]チェックボックスを選択すると、事前に抽出範囲を規定
できます。 また、分析を行いダッシュボードを作成した後、パブリッシュする用意が整ったと
きにも、[データの抽出]ダイアログボックスに戻り、[使用していないフィールドをすべて非表
示]のボタンをクリックできます。 そうしておいてデータを抽出すると、データはビューを作成
するのに必要な絶対最小限にとどまります。 これは、サマリービューを作成する際の設定によ
く使われます。 すると、ワークブックの別のページで、詳細レベルはより低く、サイズはより
大きい抽出を使用できます。 データをフィルタリングしてあるため、パフォーマンスはさほど
低下しません。 バックエンドでライブシステムに接続するまで、このプロセスを維持できます。
ライブシステムは少ない数の行を特定するのに向いています。 このように、組み合わせや異な
るレベルでの集計を行うことにより、ほぼすべてのパフォーマンス問題を解決でき、必要な速
25
度で結果を得ることができます。 Tableau はメモリ効率がよいため、通常は比較的簡単にこの
方法でパフォーマンスを向上でき、同時に複数の抽出を実行することもできます。
フィルタリングされたサブセット(1 か月分のデータなど)またはデータのランダムサンプルのい
ずれかの形で、データのサブセットを抽出することもできます。 これにより、分析コンテンツ
の作成が可能となります。また、Tableau の威力のおかげで完全なデータセットに取り組む準備
ができたときには、[抽出の使用]メニュー項目を選択解除します。
26
抽出の最適化
Tableau Server は、データベースにある物理的な列を最適化するだけでなく、Tableau で作成さ
れた追加の列も最適化します。 これらの列には文字列操作や文字列連結などの確定計算の結果
が含まれ、その結果はグループやセットとともに決して変わりません。 実行時に計算されたパ
ラメーターや集計(合計や平均など)に関わる計算を含む非確定計算の結果は、保存できません。
データをほんの 2 行追加して抽出を更新すると、抽出のサイズが 100MB から 120MB へと大幅に
増加したことに気づくことがあります。 この急な増大は、最適化により計算フィールド値を含む
列が追加で作成されることに起因します。列を追加する理由は、ディスクにデータを保存するほ
うが、データが必要になるたびに再計算するよりも時間やリソースを削減できるからです。
1 つだけ気をつけていただきたいのは、データ抽出への接続を重複してコピーする場合に、最
適化または更新オプション用に選択する接続にすべての計算フィールドが存在することを確認
する必要があるということです。計算フィールドが存在しないと、Tableau ではそのフィールド
は使われていないと見なされ、具体化されません。 必ず、プライマリデータソースにある計算
フィールドをすべて定義し、必要に応じて別の接続にコピーして、プライマリデータソースか
らの抽出のみを更新または最適化するようにしてください。
抽出の更新
Tableau Desktop で抽出を更新するにはメニュー選択で行います([データ]メニュー > [{目的のデー
タソース}] > [抽出] > [更新])。更新するとデータが最新のものになり、新しい行があれば追加さ
れます。 ただし、Tableau Server では、パブリッシュプロセスの最中またはその後で、抽出を自
27
動更新するよう管理者が定義したスケジュールを付けることができます。 スケジュールは 15
分間隔で設定でき、毎日、毎週などの設定で同時刻に更新するようにもできます。 「移動窓」
を設定して、データが最新のものに絶えず更新されるようにすることもできます。
注: 15 分ごとの更新間隔では不十分という方は、ライブデータに接続するか、同期型レポート
データベースを設定することをお勧めします。
1 つの抽出に対して 2 種類の更新スケジュールを選択できます。
増分更新では行が追加されるのみで、既存の行に対する変更は含まれません。
完全更新では現在の抽出が破棄され、データソースから新しい更新をゼロから再生成し
ます。
更新間隔よりも更新に時間がかかった場合
たとえば、1 時間ごとにデータを更新するようスケジュール設定されているのに、データ量が
多すぎて更新に 1 時間半かかったとします。 このような状況は、実際には望ましいとも言えま
す。
第 1 の更新が 1:00 に始まり 2:30 に終わります。
第 2 の更新は 2:00 に始まり 3:30 に終わります。
第 2 の更新は 3:00 に始まり 4:30 に終わります。
1:00 の時点で、ユーザーは 1 時間半前のデータを使用しています。 1:00 の更新が終わる 2:30
まで待って次の更新を始めたら、第 2 の更新は 4:00 までかかります。 しかし、更新がオーバー
ラップすると、1 時間ごと(2:30、3:30、4:30)に新しいデータが利用できるようになります。オ
ーバーラップがない場合、この間隔は 1 時間半ごと(2:30、4:00、5:30)になります。 1 回の更新
が完了すると、新規のリクエストはすべてそのバージョンの抽出にルーティングされます。
[メンテナンス]画面に、現在実行中のバックグラウンドタスクが、過去 12 時間に実行されたタス
クとともに表示されています。 色分けはタスクのステータスを表しています。 [メンテナンス]画
面を利用できるのは、管理者と、適切な許可を持つ一部のユーザーです。該当する人には、抽出
のアドホック更新を開始する許可が与えられます。 また、たとえばデータベースがロードする場
合に、データベースのロード完了後に抽出を開始するトリガーを設定することができます。
28
Tableau Server を使用している場合は Tabcmd コマンドラインを、Tableau Desktop を使用してい
る場合は Tableau.exe コマンドラインを使用して、ワークブックを増分のみまたは完全に更新す
ることもできます。 複雑なスケジュール設定が必要な場合は、Windows タスクスケジューラな
どの外部スケジュール管理ツールからこれを呼び出せます。 Tableau Server インターフェイスで
最小の 15 分間隔より短い更新サイクルをお望みの方は、この方法が必要になります。
スケジュールどおりに更新が行われるよう設定したり、 スケジュールを無効にして必要に応じ
て手動で更新を開始したりできます。
29
パート 3 - クエリ
ここまでデータ接続について見てきて、ベストプラクティスに従っていることを確認したにも
かかわらず、 まだパフォーマンスのレベルが低いとします。 その場合、次に確認すべき項目は、
特定のクエリ(多くの場合は複数のクエリ)を把握し、その状態を最適にすることです。
クエリの把握
Tableau では、ログファイルで完全なクエリテキストが見られます。 規定の場所は
C:\Users\<username>\Documents\My Tableau Repository\Logs\log.txt です。 このファイルはかなり
冗長ですが、クエリは<QUERY>タグと</QUERY>タグとの間にあります。
2014-02-19 12:32:21.574 (-,-,-,-) 16a8: <QUERY protocol='0ec80680'>
2014-02-19 12:32:21.574 (-,-,-,-) 16a8: SELECT [ProductDim].[Product Category]
AS [none:Product Category:nk],
2014-02-19 12:32:21.574 (-,-,-,-) 16a8:
[ProductDim].[Product Subcategory] AS
[none:Product Subcategory:nk],
2014-02-19 12:32:21.574 (-,-,-,-) 16a8:
SUM([OrdersFact].[Sales]) AS
[sum:Sales:ok]
2014-02-19 12:32:21.574 (-,-,-,-) 16a8: FROM ( ( ( ( [OrdersFact]
2014-02-19 12:32:21.574 (-,-,-,-) 16a8:
INNER JOIN [CustomerDim] ON
[OrdersFact].[Customer ID] = [CustomerDim].[Customer ID] )
2014-02-19 12:32:21.574 (-,-,-,-) 16a8:
INNER JOIN [DeliveryDim] ON
[OrdersFact].[Delivery ID] = [DeliveryDim].[Delivery ID] )
2014-02-19 12:32:21.574 (-,-,-,-) 16a8:
INNER JOIN [LocationDim] ON
[OrdersFact].[Place ID] = [LocationDim].[Place ID] )
2014-02-19 12:32:21.574 (-,-,-,-) 16a8:
INNER JOIN [ProductDim] ON
[OrdersFact].[Product ID] = [ProductDim].[Product ID] )
2014-02-19 12:32:21.574 (-,-,-,-) 16a8:
INNER JOIN [TimeDim] ON
[OrdersFact].[Date ID] = [TimeDim].[Date ID]
2014-02-19 12:32:21.574 (-,-,-,-) 16a8: WHERE ((Fix(Fix([TimeDim].[Date])) >=
IIF(ISNULL((-2999)),NULL,DATEADD('d',(-2999),IIF(ISNULL(#02/19/2014
12:32:21#),NULL,DATEADD('d', DATEDIFF('d', #01/01/1970#, #02/19/2014 12:32:21#),
#01/01/1970#))))) AND (Fix(Fix([TimeDim].[Date])) <
IIF(ISNULL(1),NULL,DATEADD('d',1,IIF(ISNULL(#02/19/2014
12:32:21#),NULL,DATEADD('d', DATEDIFF('d', #01/01/1970#, #02/19/2014 12:32:21#),
#01/01/1970#))))))
2014-02-19 12:32:21.574 (-,-,-,-) 16a8: GROUP BY [ProductDim].[Product
Category],
2014-02-19 12:32:21.574 (-,-,-,-) 16a8:
[ProductDim].[Product Subcategory]
2014-02-19 12:32:21.574 (-,-,-,-) 16a8: </QUERY>
Tableau Server の場合、ログは C:\ProgramData\Tableau\Tableau Server\data\tabsvc\vizqlserver\Logs
にあります。
パフォーマンスの記録
ワークブックのパフォーマンスを把握するうえで見ておきたいもう 1 つの場所は、Tableau
Desktop と Tableau Server のパフォーマンスレコーダー機能です。 この機能は[ヘルプ]メニュー
にあります。
30
パフォーマンスの記録を開始し、ワークブックを開きます。 エンドユーザーになったつもりで
ワークブックを操作し、十分なデータが得られたと感じたところで[ヘルプ]メニューに戻り、
記録を停止します。 Tableau Desktop で、データが記録された別のウィンドウが開きます。
これで、ワークブックで最も時間のかかるアクションを特定できるようになりました。たとえ
ば、「悪い例」のダッシュボードの「Sheet 1」から実行されているクエリの 1 つは、完了する
までに 27 秒もかかっています。 棒グラフをクリックすると、実行されているクエリのテキス
トが表示されます。
この情報を使用して、ワークブック内で最優先で検証すべき箇所、つまり改善に費やす時間に
31
対して最も成果が上がるセクションを特定できます。 これらの記録を分析するための詳細情報
については、以下のリンクをご覧ください。
http://onlinehelp.tableausoftware.com/v8.1/server/ja-jp/perf_record_interpret_server.htm
結合カリング
1 つのデータソースに含まれる複数の表を結合する場合、Tableau には「結合カリング」と呼ば
れるすばらしい(そして通常ユーザーには見えない)機能があります。 データベースサーバーで
結合を処理するには時間もリソースも必要なため、常にデータソースで宣言した結合をすべて
列挙するようなことは避けたほうが無難です。 結合カリングによって、結合で定義されるすべ
ての表ではなく、関連性のある表のみにクエリを実行することができます。
以下のシナリオで、小さいスタースキーマに含まれる複数の表を結合した場合を検討してみま
しょう。
結合カリングを使用した場合、Tableau は以下のクエリを生成します。
SELECT [ProductDim].[Product Category], SUM([OrdersFact].[Sales])
FROM [dbo].[OrdersFact] [OrdersFact]
INNER JOIN [dbo].[ProductDim] [ProductDim]
ON ([OrdersFact].[Product ID] = [ProductDim].[Product ID])
GROUP BY [ProductDim].[Product Category]
結合カリングを使用しない場合、Tableau は大幅に効率の悪いクエリを生成します。
SELECT [ProductDim].[Product Category], SUM([OrdersFact].[Sales])
FROM [dbo].[OrdersFact] [OrdersFact]
INNER JOIN [dbo].[CustomerDim] [CustomerDim]
ON ([OrdersFact].[Customer ID] = [CustomerDim].[Customer ID])
INNER JOIN [dbo].[DeliveryDim] [DeliveryDim]
ON ([OrdersFact].[Delivery ID] = [DeliveryDim].[Delivery ID])
32
INNER JOIN [dbo].[LocationDim] [LocationDim]
ON ([OrdersFact].[Place ID] = [LocationDim].[Place ID])
INNER JOIN [dbo].[TimeDim] [TimeDim]
ON ([OrdersFact].[Date ID] = [TimeDim].[Date ID])
INNER JOIN [dbo].[ProductDim] [ProductDim]
ON ([OrdersFact].[Product ID] = [ProductDim].[Product ID])
GROUP BY [ProductDim].[Product Category]
最初から正しいメジャーの合計が計算されるようにするには、すべてのディメンション表を結
合する必要があります。 たとえば、ファクト表に 2008～2012 年のデータが含まれているのに、
ディメンション表には 2010～2012 年のデータしか含まれていない場合、得られる SUM([Sales])
はタイムテーブルが含まれる場合と含まれない場合とで異なる可能性があります。
Tableau 8.1 より前のバージョンでは、参照整合性ルールがソース DBMS で適用されている場合
にのみ行われました。このようなケースを「ハード」な参照整合性ということもあります。 し
かし、多くのお客様はアプリケーション層でまたは ETL 処理により参照整合性を適用していま
す。このようなケースは「ソフト」な参照整合性といいます。 Tableau 8.1 では新機能が登場し、
ユーザーがソフトな参照整合性を適用していることを Tableau に申告すれば、安全に結合カリ
ングを使用できます。
詳しくは、Russell Christopher 氏のブログ『Tableau Love』に連載されている以下の記事をご覧く
ださい。
http://tableaulove.tumblr.com/post/11692301750/what-i-learned-about-tableau-join-cullingover-summer
http://tableaulove.tumblr.com/post/62447366098/what-i-learned-about-tableau-join-cullingover-fall
ブレンディング
Tableau でデータ表を結合するかブレンドするかのどちらかに決める際には、データがどこから
来ているか、データ接続の数、データ内のレコード数などを考慮します。
33
ワークブックで複数のデータソースから取得したデータを使用している場合は、データをブレ
ンドするか、連合データベースシステムを確立する必要があります。 ワークブックで同じデー
タソースから取得した 2 つのデータ接続を使用している場合は、一般的にデータ表を結合する
ことが推奨されます。パフォーマンスやフィルター管理が向上するためです。 ただし、データ
表を結合するよりもデータをブレンドするほうがうまくいく場合もあります。 以下に、データ
ブレンディングでパフォーマンスが向上する可能性のある、よくある状況を 2 つご紹介します。
大規模でクエリの実行に時間がかかるデータ接続が複数ある場合、結合するとクエリ時
間が飛躍的に長くなります。 このような場合は、表を集計し、集計されたものについて
データをブレンドすることをお勧めします。 たとえば、1 日単位ではなく 1 年単位に、
製品名ではなく製品タイプで集計するなどが可能です。 『Data Blending with Summarized
Data (要約データを使用したデータブレンディング)』の記事にある例をご覧ください。
計算のサマリーと内訳の両方を同じビューで表示する場合は、[データ] > [データ接続] >
[複製]の順に選択し、データをブレンドして 2 つのデータ接続間を通信可能にします。
詳しくは、『Showing Summary and Detail Together (サマリーと詳細を同時に表示する)』
の記事をご覧ください。
次の記事には、結合を使うべきケースとデータブレンディングを使うべきケースの例がそれぞ
れ複数紹介されています。 http://kb.tableausoftware.com/articles/knowledgebase/join-vsrelationship-60
ブレンディングを使用する場合、ブレンディングのパフォーマンスに影響する主な要素の 1 つは、
各データソースのレコード数でなく、むしろ 2 つのデータセットをリンクしているブレンド対象
のフィールドの密度です。 ブレンディングでは、リンクしているフィールドのレベルで両方のデ
ータソースからデータをクエリ検索し、両方のクエリの検索結果をメモリで統合します。
34
そのため、一意の値が多いと大容量のメモリが必要になります。 64 ビット版 Tableau 8.1 では
メモリ不足に陥らずにより複雑な(一意の値が多い)データをブレンドできますが、ここで取り
上げているような状況では、計算に時間がかかることに変わりはありません。
ブレンドの際に推奨されるベストプラクティスは、一意の値(注文 ID、顧客 ID、正確な日時な
ど)が多いディメンションでのブレンディングを避けることです。
プライマリグループとプライマリ別名
2 つのデータソース(一方は「ファクト」のレコードを含み、他方はディメンション属性を含む)
をブレンドする必要が生じた場合は、プライマリグループとプライマリ別名を作成すると、パ
フォーマンスを向上できることがあります。 以下の例では、次の 3 つの表について検討します。
プライマリグループが有効に作用するのは、プライマリデータソースのディメンションメンバ
ーに対して 1 対複数でマッピングされる属性が、セカンダリデータソースに含まれている場合
です。 上記のデータから導き出したい情報が次の情報だとします。
ブレンディングによってもこの表を作成できますが、これまで説明してきたとおり、ID の数が
多ければパフォーマンスは非常に低下します。
35
Tableau では、[グループ]フィールドを右クリックして[プライマリグループの作成]を選択する
と、リンクしているフィールド(この場合は ID)を選択したセカンダリデータソースのディメン
ション(この場合はグループ)にマッピングするグループオブジェクトが、プライマリデータソ
ースに作成されます。
これで、ブレンディングの必要なくこの表を再生成できるようになりました。
36
プライマリ別名が有効に作用するのは、プライマリデータソースのディメンションメンバーに
対して 1 対 1 でマッピングされる属性が、セカンダリデータソースに含まれている場合です。
上記のデータから導き出したい情報が次の情報だとします。
2 つのデータソースをブレンドしてもこの表を作成できますが、これまで説明してきたとおり、
ID の数が多ければパフォーマンスは非常に低下します。
37
[名前]フィールドを右クリックし[プライマリ別名の編集]を選択すると、[名前]フィールドを別
名値として[ID]フィールドにワンタイムマッピングできます。
これで、ブレンディングの必要がないためずっと速く、必要なビジュアライゼーションを作成
できるようになりました。
38
プライマリグループもプライマリ別名も動的ではなく、データが変更されたら更新する必要が
あります。 そのため、頻繁に更新されるデータでは優れたソリューションとは言えませんが、
すばやくマッピングをする必要がある場合は、時間やリソースがかかるブレンディングが必要
なくなる可能性もあります。
フィルター
Tableau のフィルターは非常に強力で、表現力の高いものです。 しかし、非効率的なフィルタ
ーが原因で、ワークブックやダッシュボードのパフォーマンスが低下することもよくあります。
以下のセクションに、フィルターを使用する際のベストプラクティスを数多くご用意しました。
なお、フィルターの効率性は、データソース内のインデックスの有無とインデックスの管理状
態に大きく影響されます。 詳しくは、上記のインデックスに関するセクションをご覧ください。
カテゴリー別ディメンションのフィルタリング
次のビジュアライゼーションを例に考えてみましょう。オーストラリアの地図に郵便番号を示
すマークが記されています。
39
この地図にフィルターを適用して、オーストラリア西部の郵便番号(紫の点)のみを表示する方
法はいくつかあります。
オーストラリア西部のマークをすべて選択し、選択したデータのみを保持する
オーストラリア西部以外のマークをすべて選択し、選択したデータを除外する
州ディメンションなど別の属性で選択したデータのみを保持する
郵便番号の値と経度緯度の値のどちらかを範囲指定してフィルターを適用する
不連続
最初の 2 つのオプションを試してみると、選択したデータのみを保持および除外するオプショ
ンはパフォーマンスが低くなることが分かります。実際、フィルタリングしていないデータセ
ットよりも処理速度が遅くなることも少なくありません。 なぜなら、これらのオプションでは、
DBMS によるフィルタリングで選別される郵便番号の値が不連続の集まりとして表わされるか
らです。複雑な WHERE 句を使用する場合も、選択したデータを追加した一時表と結合する場合
も同様です。 マークの数がさらに多ければ、このようなクエリには膨大な時間とリソースが必
要になります。
この例で 3 つ目のオプションを実行すると、得られるフィルター(WHERE STATE=”Western
Australia”)が非常に単純で、データベースで効率よく処理できるため、クエリの実行速度が速
くなります。 ただしこの方法では、フィルターを表すのに必要なディメンションの数が増える
にしたがって効率が悪くなり、最終的には範囲を囲んで選択したデータのみを保持するオプシ
ョンと同レベルのパフォーマンスになります。
範囲指定
範囲指定フィルターを適用するやり方でも、データベースは単純なフィルター句(WHERE
POSTCODE >= 6000 AND POSTCODE <= 7000 または WHERE LONGITUDE < 129)を求めることになるた
め、実行速度が速くなります。 ただしこの方法は、フィルターや関連ディメンションの場合と
異なり、ディメンションの濃度を上げてもこれ以上複雑にはなりません。
結論として、範囲指定フィルターは多くの場合、不連続の値が項目別に分けられた大規模なリ
ストよりも速くクエリを実行でき、マークの数が多い場合はできるだけ選択したデータのみを
保持または除外するオプションに優先して使用することが望ましいと言えます。
日付のフィルタリング: 不連続、範囲指定、相対
日付フィールドは特殊なディメンションであるため、Tableau では標準のカテゴリーデータとは
異なる方法で処理されることがよくあります。 これは、日付フィルターを作成する場合に特に
当てはまります。 日付フィルターは非常に一般的であり、次の 3 つのカテゴリーがあります。
特定の日付を基準とした日付範囲を示す相対日付フィルター、定義済みの不連続な日付の範囲
を示す範囲指定日付フィルター、およびリストから選択した個別の日付を示す不連続日付フィ
ルターです。 上記のセクションで説明したとおり、使用する方法はクエリの効率性に重大な影
響を与えます。
40
不連続
特定の日付または日付レベル全体を含めるフィルターが必要な場合があります。 このタイプのフ
ィルターは不連続日付フィルターと呼ばれます。これは、範囲ではなく不連続の値を定義するた
めです。 このタイプのフィルターでは、日付式が動的計算としてデータベースに送信されます。
SELECT [FactSales].[Order Date], SUM([FactSales].[SalesAmount])
FROM [dbo].[FactSales] [FactSales]
WHERE (DATEPART(year,[FactSales].[Order Date]) = 2010)
GROUP BY [FactSales].[Order Date]
ほとんどの場合、クエリ最適化ツールは DATEPART 計算を合理的に求めますが、不連続日付フ
ィルターを使用するとクエリの実行パフォーマンスが低下するケースもいくつかあります。 た
とえば、日付のパーティションキーで不連続日付フィルターを使用して分割された表に対して
クエリを実行するとします。 この表は DATEPART 値で分割されていないため、データベースに
よっては、必要がなくても、すべてのパーティションにわたって計算を求め基準に一致するレ
コードを探すことがあります。 そのような場合は、日付範囲フィルターを使用したほうが、パ
フォーマンスが大幅に向上する可能性があります。
このタイプのフィルターでパフォーマンスを最適化する方法は、データ抽出を使用して計算を
具体化することです。 まず、DATEPART 関数を明示的に実行する計算フィールドを作成します。
その後 Tableau データ抽出を作成すると、この計算フィールドは保存された値として抽出に具
体化されます(式のアウトプットが確定的なため)。 動的な式でクエリ時に値を計算するのでは
なく、計算フィールドに対するフィルタリングを行い値を簡単に検索するため、処理速度が速
くなります。
41
範囲指定
このタイプのフィルターは、連続する日付範囲を指定するときに使用します。 次のような構造
のクエリがデータベースに送信されることになります。
SELECT [FactSales].[Order Date], SUM([FactSales].[SalesAmount])
FROM [dbo].[FactSales] [FactSales]
WHERE (([FactSales].[Order Date] >= {ts '2009-01-01 00:00:00'})
AND ([FactSales].[Order Date] <= {ts '2012-12-31 00:00:00'}))
GROUP BY [FactSales].[Order Date]
このような WHERE 句はクエリ最適化ツールにとって非常に効率がよく、インデックスやパーテ
ィションを最大限に活用する実行プランができます。 不連続日付フィルターを追加するとクエ
リに時間がかかる場合は、日付範囲フィルターに変えてパフォーマンスが向上するか確認して
みてください。
42
相対
相対日付フィルターを使用すると、ビューを開いた日付と時刻に基づいて、更新する日付の範
囲を定義できます。 たとえば、今年度の累計売上高、過去 30 日間のすべてのレコード、先週
処理したバグの情報などを表示するとします。 相対日付フィルターは、当日ではなく特定のア
ンカー日付を基準とすることもできます。
SELECT [FactSales].[Order Date], SUM([FactSales].[SalesAmount])
FROM [dbo].[FactSales] [FactSales]
WHERE (([FactSales].[Order Date] >= DATEADD(year,(-2),DATEADD(year,
DATEDIFF(year, 0, {ts '2012-12-16 22:37:51.490'}), 0))) AND
([FactSales].[Order Date] < DATEADD(year,1,DATEADD(year, DATEDIFF(year, 0,
{ts '2012-12-16 22:37:51.490'}), 0))))
GROUP BY [FactSales].[Order Date]
上記のように、得られる WHERE 句には日付範囲フィルターが使用されるため、これも効率のよ
い日付フィルターと言えます。
コンテキストフィルター
既定では、Tableau で設定したすべてのフィルターは個別に計算されます。 つまり、各フィル
ターは他のフィルターにかかわらず、データソース内のすべての行にアクセスします。 ただし、
ビューのコンテキストフィルターとして 1 つまたは複数のフィルターを設定することができま
す。 これは独立型フィルターです。 設定するその他のフィルターは、コンテキストフィルター
を通過するデータのみを処理するので、依存型フィルターとして定義されます。
コンテキストフィルターは、フィルターの結果セットを一時表に書くことで実装されるため、
リレーショナルデータソースで特に有効です。 そうなると、この表がそれ以降のフィルターや
クエリに対して別の(より小さい)データソースとして作用し、データビューを構築する際のパ
フォーマンスが向上します。
43
コンテキストフィルターは、パフォーマンスを向上するためによく使われます。 注目すべきは、
データベースがコンテキストフィルターの結果を一時表に書くという点がパフォーマンス向上
の理由だということです。 この一時表の作成は、データベースにとって時間やリソースを大量
に必要とするアクティビティであるため、この方法が推奨されるのは以下のような場合です。
コンテキストフィルターにより、データセットのサイズが格段に縮小される。目安は 1
桁の差が出るかどうかです。
● ユーザーがコンテキストフィルターを頻繁に変更しない。フィルターが変更されると、デ
ータベースは一時表を再計算、再生成する必要があるため、パフォーマンスが低下します
コンテキストフィルターの動作を利用して、複雑な表結合を含むデータセットを単一の非正規
化された表に具体化するというテクニックがあります。 たとえば、Tableau が生成する以下の
クエリを例にとってみましょう。
●
SELECT SUM([OrdersFact].[Sales])
FROM [dbo].[OrdersFact] [OrdersFact]
INNER JOIN [dbo].[CustomerDim] [CustomerDim]
ON ([OrdersFact].[Customer ID] = [CustomerDim].[Customer ID])
INNER JOIN [dbo].[DeliveryDim] [DeliveryDim]
ON ([OrdersFact].[Delivery ID] = [DeliveryDim].[Delivery ID])
INNER JOIN [dbo].[LocationDim] [LocationDim]
ON ([OrdersFact].[Place ID] = [LocationDim].[Place ID])
INNER JOIN [dbo].[ProductDim] [ProductDim]
ON ([OrdersFact].[Product ID] = [ProductDim].[Product ID])
INNER JOIN [dbo].[TimeDim] [TimeDim]
ON ([OrdersFact].[Date ID] = [TimeDim].[Date ID])
WHERE (([LocationDim].[Region] >= 'Africa')
AND ([LocationDim].[Region] <= 'Oceania'))
HAVING (COUNT_BIG(1) > 0)
すべてのディメンションメンバーを返すコンテキストメニューをディメンションに設定するこ
とで、Tableau が上記のクエリを具体化し、結果を一時表に書くようにします。 これにより、
同じクエリが以下のように再生成されます。
SELECT SUM([#Tableau_3_Context].[Sales])
FROM [#Tableau_3_Context]
HAVING (COUNT_BIG(1) > 0)
ご覧のように、データベースで実行しやすい、はるかに簡単なクエリができ、パフォーマンス
も向上します。 このテクニックは、カスタム SQL ステートメントに基づくデータ接続を使用す
るワークブックを最適化する際にも利用できます。
クイックフィルター
「クイック」と言いながら、実際には処理時間が長くなるクイックフィルターもたくさんあり
ます。特に「関連値のみ」を使用するよう設定すると、多数の不連続リストを処理することに
なります。 代わりに誘導形式の分析アプローチを採用し、ダッシュボード内でアクションフィ
ルターを使用してみてください。 数えきれないほどのフィルターを含めて超高度なカスタマイ
ズが可能なビューを構築している場合は、レベルやテーマが異なる複数のダッシュボードを作
ったらどうなるか自問してみましょう(答えはおそらく「イエス」です)。
44
列挙と非列挙
列挙型のクイックフィルターの場合、Tableau では、クイックフィルターオブジェクトをレンダ
リングするために、潜在的なフィールド値すべてについてデータソースでクエリを実行する必
要があります。 このようなクイックフィルターには次のものが含まれます。
複数値リスト
単一値リスト
コンパクトリスト
スライダー
メジャーフィルター
日付範囲フィルター
反対に、非列挙型のクイックフィルターの場合、潜在的なフィールド値を知る必要はありませ
ん。 このようなクイックフィルターには次のものが含まれます。
カスタム値リスト
ワイルドカード照合
相対日付フィルター
期間参照日付フィルター
その結果、非列挙型のクイックフィルターでは、クイックフィルターに関連してデータソース
により実行される必要のあるクエリの数が減ります。 また、非列挙型のクイックフィルターで
は、表示するディメンションメンバーが多い場合に、レンダリング処理を速くすることができ
ます。
非列挙型のクイックフィルターを使うことでパフォーマンスは向上できますが、エンドユーザ
ーから見たときの視覚コンテキストは劣化します。
関連値
列挙型のクイックフィルターは、次の 3 種類の方法で潜在的なフィールド値を表示するよう設
定できます。
[データベース内のすべての値] - このオプションを選択すると、ビューのその他のフィル
ターにかかわらず、データベース内のすべての値が表示されます。 他のフィルターが変
更されても、クイックフィルターはクエリを再度実行する必要がありません。
[コンテキスト内のすべての値] - このオプションは、アクティブなコンテキストフィルタ
ーがある場合にのみ利用できます。 このクイックフィルターでは、ビューのその他のフ
ィルターにかかわらず、コンテキスト内のすべての値(つまり、コンテキストフィルター
により生成された一時表)が表示されます。 他のフィルターが変更されても、クイックフ
ィルターはクエリを再度実行する必要がありません。
[関連値のみ] - このオプションを選択すると、他のフィルターが考慮され、それらのフィ
ルターを通過した値のみが表示されます。 たとえば、[州]のクイックフィルターで[地域]
のフィルターを使用すると、東部の州のみが表示されます。 その結果、このクイックフ
ィルターは、他のフィルターが変更されたときにクエリを再度実行する必要があります。
45
上述のとおり、[関連値のみ]設定はユーザーが関連する選択を行ううえで非常に有用ですが、
ダッシュボードとの通信中に実行される必要のあるクエリの数が大幅に増加することもありま
す。 適度な使用をお勧めします。
クイックフィルターの代替案
クイックフィルターを使用する代わりに、同様の分析結果を得られてなおかつ追加クエリのオ
ーバーヘッドなしでそれが可能な方法はいくつかあります。
ユーザーにクイックフィルターを提供する代わりに、ユーザーの選択に基づいてパラメーター
やフィルターを作成することができます。
メリット:
パラメーターの場合、レンダリングの前にデータソースでクエリを実行する必要がな
い
パラメーターと計算フィールドを併用することで、単なるフィールドフィルターでで
きるよりも複雑な論理を実装できる
パラメーターを使用して、複数のデータソースに対して横断的にフィルターを適用で
きる(クイックフィルターは 1 つのデータソース内でしか動作しない)
デメリット:
パラメーターは単一値のみ対応。ユーザーに複数の値を選択させたい場合には使用で
きない
パラメーターは動的でない。値のリストは作成時に定義され、DBMS にある値に基づ
いて更新しない
別の方法は、ビュー間でフィルターアクションを使用することです。
メリット:
アクションは、視覚的に範囲を囲むか、または CTRL クリックや SHIFT クリックで、複
数の値の選択をサポート。
アクションでは、実行時に求められた値の動的リストが表示される
アクションを使用して、複数のデータソースに対して横断的にフィルターを適用でき
る(クイックフィルターは 1 つのデータソース内でしか動作しない)
デメリット:
フィルターアクションは、クイックフィルターよりも設定が難しい
アクションでは、パラメーターやクイックフィルターのようなユーザーインターフェ
イスが提供されず、通常、表示に要する画面の面積が大きくなる
アクションソースシートでは、データソースに対して引き続きクエリを実行する必要
があるが、Tableau 処理パイプライン内のキャッシュを活用できる
クイックフィルターに過度に依存しない代替の設計テクニックについて詳しくは、上述のセク
ションをご覧ください。
46
ユーザーフィルター
ユーザーフィルターを活用するワークブックでは、[ユーザーフィルターの作成]ダイアログ経
由でもビルトインのユーザー関数のいずれかを使用した計算フィールド経由でも、作成された
フィルターはユーザー独自のものであるため、Tableau Server に展開した際に共有結果キャッシ
ュを使用できません。 これにより、パフォーマンスには次のような影響があります。
すべてのワークブックで、参照元データソースに対してクエリを実行する必要が生じま
す。別のユーザーのセッションでまったく同じクエリが実行された直後でも同様です。
そのため、データソース I/O がより頻繁に必要になります。
各ユーザーセッションが独自のクエリ結果とモデルキャッシュを作成するため、より大
きなキャッシュスペースが必要になります。 そのため、負荷の大きいマシンでは使用中
のキャッシュですらクリアされることになりかねず、この場合にもより多くの I/O が必
要になります。
詳しくは、Tableau Server のキャッシュに関する次のセクションをご覧ください。
47
パート 4 - 計算
多くの場合、ソースデータには、すべての質問に答えるのに必要なフィールドが揃っていませ
ん。 計算フィールドは、分析に必要なすべてのディメンションやメジャーを作成するうえで役
立ちます。
計算フィールド内では、ハードコードされた定数(たとえば税率など)を定義する、引き算や掛
け算など非常に単純な数学操作(「収益－経費」など)を行う、より複雑な数式を使用する、論
理テスト(IF/THEN、CASE など)を実行する、型変換を行う、その他さまざまな操作が可能です。
一度定義すると、計算フィールドはワークブック全体で利用できます。ただし、これはワーク
シートが同じデータソースを使用している場合に限ります。 計算フィールドは、ソースデータ
からのディメンションやメジャーを使う場合と同様に、ワークブックで使用できます。
Tableau には 3 つの異なる計算タイプがあります。
基本的な計算
集計計算
表計算
Tableau 計算レファランスライブラリに、複雑な計算を行う方法についての優れた参考資料や、
ユーザー同士がよくある問題に対するソリューションを共有するフォーラムがあります。
http://community.tableausoftware.com/community/viz-talk/tableau-communitylibrary/calculation-reference-library
基本的な計算と集計計算
基本的な計算と集計計算は、データソースに送信されるクエリの一部として表され、そのため
データベースが計算を実行します。 例:
SELECT DATEPART(year,[TimeDim].[Date]), SUM([OrdersFact].[Sales])
FROM [dbo].[OrdersFact] [OrdersFact]
INNER JOIN [dbo].[TimeDim] [TimeDim]
ON ([OrdersFact].[Date ID] = [TimeDim].[Date ID])
GROUP BY DATEPART(year,[TimeDim].[Date])
YEAR 計算が基本的な計算の例で、SUM(SALES)が集計計算の例です。
一般に、基本的な計算と集計計算はスケーラビリティが良好で、計算のパフォーマンスを向上
するために採用できるデータベース調整テクニックもたくさんあります。
表計算
一方、表計算はデータベースが実行するのではなく、返されたクエリ結果をもとに Tableau が
計算します。 このため Tableau での処理量が増えますが、通常、元のデータソースで計算する
よりもはるかに小さいレコード数について計算が行われます。
表計算のパフォーマンスに問題がある場合(Tableau に返された結果セットが巨大であることが
原因と考えられます)は、データソースレイヤーに計算の一部を差し戻すことを検討してみてく
48
ださい。 これを行う方法の 1 つに、集計データ抽出を活用する方法があります。 例として、複
数の店舗にまたがる 1 日の売上合計の週平均を求めるとします。 表計算でこれを求めるには、
次の式を使います。
WINDOW_AVG(SUM([Sales])
ただし、日数や店舗数が巨大になると、この計算には時間がかかります。 SUM([Sales])をデータ
レイヤーに差し戻すには、日付ディメンションを日レベルまでロールアップする抽出時の集計
を作成します。 これで、抽出の時点ですでに 1 日の合計が具体化されるため、計算は
AVG([Sales])で簡単にできるようになります。
表計算によっては、Tableau エンジンで実行すると膨大な時間やリソースを必要とすることがあ
ります。 以下に示す Richard Leeke 氏のブログ記事によると、よく使われる WINDOW_XXX や
TOTAL などの表計算を実行するのに必要な時間は、分析対象のパーティションにある行数の二
乗に比例して増加するとのことです。 つまり、レコード数が多いと、これらの関数の実行は非
常に遅くなります。
http://www.clearlyandsimply.com/clearly_and_simply/2011/01/another-look-at-site-catchmentanalysis-with-tableau-6-part-3.html
この記事で、Leeke 氏は表計算エンジンが処理する行数の制限を回避する策をいくつか紹介し
ています。 たとえば、上記の WINDOW_AVG 計算は次のように書き換えられます。
IF FIRST()==0 THEN WINDOW_AVG(SUM([Sales]),0,IIF(FIRST()==0,LAST(),0)) END
この変更によりパフォーマンスは格段に向上します。Leeke 氏が紹介している例では、当初 3
時間かかっていたビューのレンダリングが 5 秒に短縮されたそうです。
計算とネイティブ機能
ユーザーが計算フィールドを作成して実行しようとする機能のいくつかは、Tableau のネイティ
ブ機能で簡単に達成できる場合があります。 例:
ディメンションメンバーをグループ化する - グループを使用します
メジャー値をグループ化して「ビン」を作成する - ビンを使用します
ディメンションメンバーについて表示される値を変更する - 別名を使用します
基本のビンでは不可能な可変幅のビンが必要な場合など、すべてのケースに当てはまるわけで
はありませんが、ネイティブ機能がある場合はそちらをご利用ください。 そうすることで手動
で計算するよりも効率がよい場合が多く、また、開発者が Tableau のパフォーマンス向上に継
続的に取り組んでいるため、その成果が現れてくることが予想されます。
データ型の影響
計算フィールドを作成するときは、使用するデータ型が計算速度に大きく影響することを理解
しておく必要があります。 一般的な指針は次のとおりです。
ブール値のほうが整数値よりも計算が遅く、また文字列はそれよりもさらにずっと遅い
文字列の計算は非常に時間がかかります。各計算に対して、10～100 件の基本指示の実行が必
要となる場合がよくあります。 一方、数値やブール値の計算は非常に効率的です。
49
この現象は Tableau の計算エンジンだけでなく、ほとんどのデータベースにも当てはまります。
基本的な計算と集計計算はデータベースに差し戻されるため、数値論理と文字列論理で表され
た計算があれば、ずっと速く実行されます。
パフォーマンス向上のためのテクニック
計算をできるだけ効率よくするために、以下のテクニックを検討してみてください。
基本論理計算にブール値を使用
二元的な結果が生じる計算(はい/いいえ、合否、超過/未満など)の場合は、文字列よりもブール値が返って
くるようにします。 例:
IF [Date]= TODAY() then “Today”
ELSE “Not Today”
END
この場合は文字列が使われているため、計算が遅くなります。 この計算をより速く行うには、
ブール値で結果を得るようにします。
[Date]=Today()
次に、別名を使って、TRUE 結果と FALSE 結果の名前を“Today”と“Not Today”に変更します。
文字列検索
製品名に参照文字列が含まれるすべてのレコードを表示したいとします。 これを実行するため
に、ユーザーからの参照文字列を取得するパラメーターを使用し、次の計算フィールドを作成
したとします。
IF FIND([Product Name],[Product Lookup])>0 THEN [Product Name] ELSE NULL END
目的の文字列が含まれているかをテストするには効率の悪い方法であるため、計算に時間がか
かります。 これを効率よく行うには、特定の CONTAINS 関数を使用することをお勧めします。
この関数は、データベースに送信される際に最適化 SQL に変換されます。
CONTAINS([Product Name],[Product Lookup])
ただし、この場合の最適なソリューションは、計算フィールドの代わりにワイルドカード一致
のクイックフィルターを使用することです。
条件付き計算のパラメーター
Tableau でよく使われるテクニックは、エンドユーザーにパラメーターを提供し、計算の実行方
法を決定する値を自分で選べるようにすることです。 一般に、ユーザーには理解しやすいオプ
ションを提供するほうがよいため、パラメーターは文字列型で作成します。 すでに述べたとお
り、数値計算は文字列計算よりずっと速いため、テキストラベルを表示するにはパラメーター
の[表示名]機能を利用しますが、計算論理には参照元の整数値を用意します。
例として、ビューに表示する日付の集計レベルを、エンドユーザーが可能な値のリストから選
択して管理できるようにするとします。 多くの場合、次のような文字列型パラメーターが作成
されます。
50
値
表示名
年
年
四半期
四半期
月
月
週
週
日
日
次に、これらを次のような計算に使用します。
IF [Parameters].[Date Part Picker]="Year"
THEN DATEPART('year',[Order Date])
ELSEIF [Parameters].[Date Part Picker]="Quarter"
THEN DATEPART('quarter',[Date])
…
ELSE NULL END
しかし、よりよいパフォーマンスが得られるのは、次のようなテキストラベルを含む整数型の
パラメーターです。
値 表示名
1
年
2
四半期
3
月
4
週
5
日
計算は以下のようになります。比較が文字列ではなく数値になっています。
IF [Parameters].[Date Part Picker]=1
THEN DATEPART('year',[Order Date])
ELSEIF [Parameters].[Date Part Picker]=2
THEN DATEPART('quarter',[Order Date])
..
ELSE NULL END
ボーナス: この特定の問題については、さらに速く計算を行う方法があります。 元の文字列型
パラメーターを使用し、次のような計算を作成します。
DATEPART([Parameters].[Date Part Picker], [Order Date]))
ここでは条件付き論理素子がすべて排除され、DATEPART の文字列が計算に直接代入されてい
ます。 優れた最適化 SQL を得るには、この方法が一番です。
51
日付変換
日付データがネイティブの日付形式以外で保存されている（文字列や数字のタイムスタンプな
ど)こともよくあります。 Tableau 8.1 では新たに DateParse()という関数が採用され、日付変換が
簡単にできるようになりました。 現在は、書式設定文字列の形で送信するだけです。
DATEPARSE(“yyyyMMdd”, [YYYYMMDD])
ただし、Tableau 8.1 の DateParse()は、次のデータソースのサブセットでのみサポートされてい
ます。
MySQL
Oracle
PostgreSQL
Tableau データ抽出
お使いのデータソースで DateParse()がサポートされていない場合、日付を Tableau で使用する
正式な日付形式に変換する別の方法は、フィールドを日付文字列(「2012-01-01」など。国際標
準に準じた ISO 文字列が推奨されます)に解析し、DATE()関数に渡す方法です。
元データが数値フィールドの場合は、文字列に変換してから日付に変換するととても非効率的
です。 そのような場合はデータを数値のまま維持し、DATEADD()と日付リテラル値を使用して
計算を実行します。
計算速度の遅い例(ISO 形式の数値フィールドの変換)は次のとおりです。
DATE(LEFT(STR([YYYYMMDD]),4)
+ “-“ + MID(STR([YYYYMMDD]),4,2)
+ “-“ + RIGHT(STR([YYYYMMDD]),2))
この計算をもっと効率よく行うには、次のようにします。
DATEADD( 'day', INT([yyyymmdd] )% 100 - 1,
DATEADD( 'month', INT( [yyyymmdd]) % 10000 / 100 - 1,
DATEADD( 'year', INT( [yyyymmdd] ) / 10000 - 1900,
#1900-01-01# ) ) )
データセットが大きい場合、パフォーマンスの向上は際立ったものになります。 レコード数が
10 億を超えるサンプルでは、最初に示した計算が完了するのに 4 時間もかかりましたが、後に
示した計算は約 1 分で完了しました。
日付関数
タイムスタンプレベルの詳細が必要な場合にのみ NOW()を使用します。 日付レベルの計算には
TODAY()を使用します。
ロジックステートメント
複雑なロジックステートメントを操作する際は、次の点に留意します。
ELSEIF > ELSE IF
52
その理由は、ネストされた IF は、最初の IF ステートメントの一部として計算される代わりに、
2 つ目の IF ステートメントを計算するからです。 そのため、次の計算フィールド
IF [Region] = "East" and [Customer Segment] = "consumer"
then "East-Consumer"
Else IF [Region] = "East" and Customer Segment] <>"consumer"
then "East-All Others"
END
END
は、以下のようにしたほうが速く実行できます。
IF [Region] = "East" and [Customer Segment] = "consumer"
then "East-Consumer"
Elseif [Region] = "East" and [Customer Segment] <>"consumer"
then "East-All Others"
end
また、以下のようにするとさらに計算が速くなります。
IF [Region] = "East" THEN
IF [Customer Segment] = "consumer" THEN
"East-Consumer"
Else "East-All Others"
END
END
同様に、冗長な論理チェックを避けるようにします。 次の計算
IF [Sales] < 10 Then "Bad"
Elseif [Sales]>= 10 and [Sales] < 30 Then "OK"
Elseif [Sales] >= 30 then "Great"
END
をより効率よく書くと、以下のようになります。
IF [Sales] < 10 Then "Bad"
Elseif [Sales] >= 30 then "Great"
else "OK"
END
基本的な計算と集計計算の分離
抽出とカスタム集計を使用する際は、計算をいくつかの部分に分割します。 行レベルの計算を
1 つの計算フィールドに配置し、集計計算を次の計算フィールドに配置します。 そうすると、
抽出により行レベルの計算が最適化(事前計算と具体化)されます。
53
パート 5 - デスクトップかサーバーか
単独ユーザーテストでは問題なく機能したワークブックでも、Tableau Server に展開して多数の
ユーザーで使用したらパフォーマンスが低下したという状況はときどき起こります。 次のセク
ションでは、単独ユーザーと複数ユーザーのシナリオで違いが出る分野を説明します。
一般的なガイドライン
64 ビットのオペレーティングシステムの使用
Tableau Server は 32 ビットの Microsoft オペレーティングシステムでも実行できますが、ベスト
な結果を得るには 64 ビット版をご利用ください。 Tableau 8.1 では、Tableau Server のすべての
コンポーネントをネイティブの 64 ビットプロセスとして実行できます。 つまり、すべてのコ
ンポーネントで、ずっと多くの RAM アドレスを使用できるようになりました。初期のベンチマ
ークテストでは、64 ビット版の Tableau は、32 ビット版よりも飛躍的にスケーラビリティが向
上しています。
お客様には、Tableau Server を 8.1 以降のバージョンにアップグレードし、64 ビットの Tableau
Server を導入することを強くお勧めします。
コアとメモリの追加
Tableau Server を実行するマシンが 1 台か複数台かにかかわらず、原則としては CPU コアや
RAM の多いほうがパフォーマンスが向上します。 Tableau Server が推奨するハードウェアとソ
フトウェア要件を満たしていることを確認し、When to Add Workers & Reconfigure (ワーカーの
追加と再構成の時期)で、追加のマシンが必要かどうかを評価します。
2013 年 7 月、Tableau ではお客様が大規模な導入を計画する場合に備えて、Tableau Server のス
ケーラビリティ試験を実施しました。 サーバー1 台の場合、2 台の場合、3 台の場合と、3 種類
のサーバー構成を、専用の負荷試験環境でテストしました。 また、試験に使用するレポートに
は、複雑さの異なる 2 種類を用意しました。 レポートの読み込み、選択の実行、ビューのフィ
ルタリング、タブの変更など、さまざまなタスクを各ユーザーに実行してもらい、実際の利用
状況をシミュレーションしました。 次のペーパーに、試験の詳細を掲載し、Tableau Server のパ
フォーマンスを向上するテクニックをまとめました。
http://www.tableausoftware.com/ja-jp/learn/whitepapers/tableau-server-scalability-explained
構成
オフピーク時間の更新のスケジュール
サーバーのパフォーマンスが低い場合は、バックグラウンドタスク管理ビューを使用して現在
の更新タスクスケジュールを表示します。 オフピーク時間の更新をスケジュールできる場合は、
実施してみてください。 ハードウェア構成により可能な場合は、バックグラウンダープロセス
を専用のワーカーノードに移動することもできます。
VizQL セッションのタイムアウト制限の確認
VizQL セッションのタイムアウト制限はデフォルトで 30 分です。 VizQL セッションがアイドル
状態でも、メモリや CPU サイクルは消費されています。 下限値で済む場合は、tabadmin を使
用して vizqlserver.session.expiry.timeout 設定を変更します。
54
プロセス構成の評価
Tableau Server はサーバープロセスと呼ばれる 6 つのコンポーネントに分けられます。 既定の
構成は幅広いシナリオに対応できるように設計されていますが、異なるパフォーマンス目標を
達成するように再構成することもできます。 特に、プロセスが実行されるマシンと実行台数を
制御できます。 1、2、および 3 マシンの配置については、Improving Server Performance (サーバ
ーのパフォーマンスの向上)ガイドラインを参照してください。
Tableau Server の監視
Tableau Server には、管理者が Tableau Server でのアクティビティを監視するためのビューがい
くつか用意されています。 これらのビューは、サーバーの[メンテナンス]ページの[分析]表にあ
ります。
これらビューについて詳しくは、以下のリンクをご覧ください。
http://onlinehelp.tableausoftware.com/current/server/ja-jp/adminview.htm
また、カスタムの管理ビューは Tableau リポジトリを構成する PostgreSQL データベースに接続
することで作成できます。 手順についてはこちらをご覧ください。
http://onlinehelp.tableausoftware.com/current/server/ja-jp/adminview_postgres.htm
キャッシュ
キャッシュがあることで、Tableau Server はクライアントのリクエストにすばやく応答できます。
稼働中のデータベースに接続するビューの場合は特にこれが言えます。 Tableau Server には何層
ものキャッシュが用意されており、複数のユーザーリクエストにわたってデータや計算を最大
限に再利用できるようになっています。
55
クライアント側レンダリング
ビューのマークやデータは、クライアントの Web ブラウザーに表示される前に検索され、解釈
され、レンダリングされます。 Tableau Server では、このプロセスをクライアントの Web ブラ
ウザーでもサーバーでも実行できます。 クライアント側レンダリングは既定モードです。理由
は、サーバーでレンダリングとすべての操作を処理すると、ネットワークデータ転送量や往復
遅延が増えるからです。 クライアント側レンダリングにすると、ほとんどのビューの操作が速
くなります。解釈やレンダリングがそのクライアントで実行されるためです。
ただし、ビューによっては、演算能力の高いサーバーでレンダリングを行ったほうが効率がよ
くなる場合もあります。 サーバー側レンダリングは、画像ファイルに必要な帯域幅が、その画
像を作成するのに使用されるデータよりも著しく少ないような、複雑なビューに適しています。
また、タブレットの場合は一般に PC よりもパフォーマンスがはるかに低いため、あまり複雑
なビューの取り扱いには適していません。 PC の Web ブラウザーで開いたビューにはクライア
ント側レンダリングが適用され、タブレットの Web ブラウザーで開いたビューにはサーバー側
レンダリングが適用される場合もあります。
Tableau Server は、これらすべての状況に自動で対応するように構成されています。その際、ビ
ューのレンダリングを Web ブラウザーではなくサーバーで行うためのトリガーとして、しきい
値計算を使用します。 管理者の方は、この設定を試験したり、PC 用とタブレット用に微調整し
たりすることができます。 詳細については、次のトピックを参照してください。
これは、ビューの URL に次を追加すればいつでも調べられます。 レンダリングモードを示す小
さな「S」や「B」がビューのツールバーに表示されます。
「?:jsdebug=true」
56
また、以下の URL パラメーターでクライアント側レンダリングのオンとオフを切り替えられます。
オフにする = 「?:render=false」
オンにする = 「?:render=true」
クライアント側レンダリングは、Internet Explorer 9.0 以降、Firefox、Chrome、Safari でサポート
されています。 これらの Web ブラウザーはすべて、クライアント側レンダリングに使用され
る HTML 5 <canvas>要素を含んでいます。 また、ビューが多角形、カスタム形状、ページ履歴
機能などを使用している場合は、クライアント側レンダリングをオンにするようなケースでも、
サーバー側レンダリングが実行されます。
画像タイルキャッシュ
クライアント側レンダリングが使用されない場合、Tableau には、ビューのレンダリング時間を
短縮するために 3 層のサーバー側レンダリングが用意されています。 1 層目は画像タイルキャ
ッシュです。
クライアントにはダッシュボードが一連の画像の「タイル」として配信されます。これらが組
み立てられ、完全なダッシュボードとして表示されます。 このキャッシュからコンテンツを再
利用するのがサーバー応答の形態として最も効率的で、次のような場合に実行されます。
ダッシュボードがすでにレンダリングされており、キャッシュされる時間の有効期限が
切れていない場合
ダッシュボードのセキュリティがユーザーごとに設定されていない場合
リクエストで以前にキャッシュされたダッシュボードと同じ大きさのものが求められて
いる場合。これは、2 つのクライアントブラウザーウィンドウがまったく同じサイズか、
ダッシュボードが固定サイズで設計されている場合に起こり得ます
画像タイルキャッシュはディスクベースで、ゲートウェイサービスにより管理されます。 VizQL
ワーカーマシンごとに 1 つ用意されています。
モデルキャッシュ
画像タイルキャッシュを利用できない場合、VizQL Server はリクエストされた画像を再レンダリ
ングする必要があります。 その操作には、計算フィールド、表計算、リファレンスライン、傾
向線など、以前に実行した計算をすべて再利用できる場合があります。これらの結果は VizQL
モデルキャッシュに保持されており、次のような場合に使用できます。
リクエストされたダッシュボードが以前この VizQL インスタンスでレンダリングされて
おり、キャッシュされる時間の有効期限が切れていない場合
リクエストされたデータに変更がない場合(すべてのフィルター、パラメーター、動的計
算が同じ場合)
計算に変更がない場合(リファレンスラインや傾向線などに変更がない場合)
ダッシュボードのセキュリティがユーザーごとに設定されていない場合
モデルキャッシュは RAM ベースで、VizQL Server インスタンスごとに 1 つ用意されています。
複数の VizQL インスタンスを実行すると、ユーザー数が少ない場合、モデルキャッシュの効率
が低下することがあります。
57
クエリ結果キャッシュ
モデルキャッシュを利用できない場合、すでにデータソースから読み出されクエリ結果キャッ
シュに保持されているデータを使用して、必要な計算をすべて実行できることがあります。 ク
エリ結果キャッシュはクエリによって返されたレコードを保持するもので、次のような場合に
使用できます。
リクエストされたダッシュボードが以前この VizQL インスタンスでレンダリングされて
おり、キャッシュされる時間の有効期限が切れていない場合
データソースから必要なディメンションやメジャーに変更がない場合(動的計算フィール
ドなどを介して変更されたフィールドがない場合)
ダッシュボードのフィルターに変更がない場合
ダッシュボードのセキュリティがユーザーごとに設定されていない場合
モデルキャッシュ同様、クエリ結果キャッシュは RAM ベースで、VizQL Server インスタンスご
とに 1 つ用意されています。 複数の VizQL インスタンスを実行すると、ユーザー数が少ない場
合、クエリ結果キャッシュの効率が低下することがあります。
キャッシュを最大限に利用する
上述したように、画像タイルやモデルキャッシュが必ず再利用されるようにするには、ワーク
ブックを設計する際に、ダッシュボードのサイズに関するルールを「固定サイズ」に設定する
ことが一番効率的です。
キャッシュの調整
マクロレベルで、Tableau Server におけるキャッシュのパフォーマンスは、Tableau Server 構成
ユーティリティから以下の 3 つの設定のいずれかに構成できます。
クエリの最小化
バランス
最新
各 VizQL Server でできるだけ長く、モデルとクエリ結果をキャッシュ
する
明示的に更新されない限り、リクエストはキャッシュデータを得る
キャッシュはメモリに保持され、メモリがいっぱいになると古いアイ
テムから消えていく
各サーバーで長くても指定された時間(分)、モデルとデータをキャッシ
ュする
リクエストが得るキャッシュデータは古くても何分前のものか分かる
サーバーではモデルやデータをまったくキャッシュしない
リクエストは最新のデータをデータソースから得る
このオプションでは、サーバーにかかる負荷が他と比べて非常に多い
58
Tableau にすべてのキャッシュを無視させ、ビューURL に「?:refresh=yes」パラメーターを添付
してデータソースにクエリを実行させることもできます。 例:
http://demoapac.tableausoftware.com/views/NewWaveDashboard/ExecutiveDashboard?:refresh=yes
また、Tableau Server 管理者は、モデルキャッシュとクエリ結果キャッシュの両方についてサイ
ズを調整することができます。 これらの設定は、tabadmin コマンドラインツールから変更でき
ます。
モデルキャッシュ
vizqlserver.modelcachesize:30
ワークブックの Viz インスタンスごとにモデルが 1 つある場合
に、キャッシュするモデルの数
クエリキャッシュ
vizqlserver.querycachesize:64
キャッシュするクエリ結果のサイズ(メガバイト)
詳細については、次のリンクを参照してください。
http://onlinehelp.tableausoftware.com/current/server/ja-jp/reconfig_tabadmin.htm
これらの設定を変更すると、VizQL Server インスタンスで使用される RAM の容量が増加します。
Tableau Server に、これをサポートするのに十分なメモリがあることを確認してください。
59
パート 6 - その他の要因
最後のこのセクションでは、変更が難しいことも多い他の要因を取り上げます。 たとえば、OS
の選択、Tableau を実行しているハードウェアなどはすべて、Tableau のパフォーマンスに影響
します。
環境要因
OS - 32 ビットか 64 ビットか
通常、Tableau の実行には 64 ビット OS が推奨されます。 Tableau 8.1 のリリースでは、アプリ
ケーション全体が 64 ビットになりました。つまり、このアプリケーションでは 3.2GB を超える
RAM を使用できます。これにより、ユーザーはよりサイズの大きいクエリを短時間で実行した
り、より多くのデータマークを効率よくレンダリングしたりすることができるようになりまし
た。 この変更は、高密度のフィールドをブレンドする、(セオリーに従わずに)非常に大規模な
クロス集計をレンダリングするなどのシナリオに、大きく影響します。 実際、カスタムの地理
的多角形などデータマークを数多くレンダリングするユーザーにとって、この変更は大きな収
穫となっています。
RAM 容量、CPU 速度
多くのアプリケーション同様、Tableau にとっても大きい容量の RAM や処理速度の速い CPU は
有利に働きます。 Tableau が実行するアクションの一部(データ抽出の作成や更新など)はマルチ
スレッドであるため、コア数が多いのも有利です。
SSD か回転ディスクか
Tableau のアクションの一部(データ抽出の読み込み、作成、更新など)は頻繁な I/O を必要とす
るため、回転式ディスクよりも SSD を使用するほうが有利です。
ネットワークインターフェイスの速さ
データが Tableau ワークステーションのリモートにある場合、または Tableau Server にデータや
ワークブックをパブリッシュする場合、応答の速いネットワークインターフェイスや待ち時間
の短いネットワーク接続は有利です。
ブラウザーの種類
Tableau は JavaScript を多用するため、ブラウザーの JavaScript 解釈プログラムの速度がレンダ
リング速度に影響します。 急速に進化している分野でどのブラウザーも優れていますが、現時
点でのランキングは次のとおりです。
Firefox、Chrome
新 IE (バージョン 10 以降)
旧 IE (バージョン 9 以前)、Opera、Safari
このアドバイスは次のレポートの内容に基づいています。
http://www.zdnet.com/the-big-browser-benchmark-january-2013-edition_p2-7000009776/
60
付録 A - リレーショナルと OLAP の機能
Tableau は、キューブ(OLAP)データソースとリレーショナルデータソースの両方に、ライブのネイティブ接続を使用して接続します。
キューブの表とリレーショナルの表は構造や目的の面で、また多くの場合パフォーマンスの面でも、大きく異なります。 このよう
な違いのため、Tableau では、各タイプの接続を最大限に活用できるように最適化された接続や機能をご用意しています。
大まかに言うと、キューブは事前集計されており、構造化されています。 リレーショナルソースは一般に非集計で、構造化の程度
も高くありません。 どちらのタイプのデータソースを使用しても、Tableau 機能の大部分は同じです。
機能
キューブ
リレーショナル
ユーザーフィルタ
ー
キューブでは、ユーザーレベルのセキュリティを定義で
きます。 Tableauにはお使いの環境でこの論理を活用す
る機能があります。 Tableau内でセキュリティモデルを
再度モデル化する必要はありません。 キューブでこれ
をまだ定義していない場合は、Tableauで定義できます。
リレーショナルデータソースには、ユーザーレベルのセ
キュリティを定義する機能があります。 Tableau内で
この論理を再定義する必要はありません。 データベー
スにこの論理がない場合は、Tableauで定義できます。
セキュリティ
セキュリティ
データブレンディ
ング
どのような組織でも、キューブ内にあるデータと、キュ
ーブ内にないデータがあります。 Tableauを使用する
と、ユーザーは、リレーショナルデータを移動したりキ
ューブでモデル化したりせずに、キューブデータと簡単
にブレンドできます。
データブレンディングは、リレーショナルデータベース
で、複数のデータベースにまたがって、またキューブと
も機能します。 異種データソースを分析する際、Tabl
eauには独特のアプローチがあります。 Tableauではデ
ータを移動する必要がありません。
データブレンディング
データブレンディング
61
機能
キューブ
リレーショナル
セット分析
キューブユーザーには、セットを好む人が多くいます。
Tableauではこのようなセットを活用します。 なお、セ
ットがキューブ内にない場合は、Tableauで動的で次元を
含むセットを作成できます。
セットはデータの次元交点を保存する1つの方法です。
リレーショナルデータソースを使用すると、キューブに
似たセットをデータ内に作成できます。
セット
ランク付けセット
集計計算関数
キューブの場合、集計が事前に行われ、Tableauはキュー
ブの集計セットを使用して応答します。 これが、パフ
ォーマンスに関するキューブの主な利点の1つです。
リレーショナルデータベースの場合、集計を事前に行う
ことは通常ありません。 TableauはTableau内でユーザ
ーに集計の選択肢を与え、データベースが要求に応じて
集計を実行します。
Tableau
「グループ」
キューブの場合、通常、グループ化は開発者により定義
され、事前に計算されています。 そのため、パフォー
マンス上の利点と標準構造が得られます。 グループ化
は、以下のように簡単なMDXでできます。
リレーショナルデータベースの場合、通常、グループ化
は事前にモデル化されていません。 ただし、Tableau
には、分析中いつでもその場でグループを作成する機能
が用意されています。
グループの作成
[Customer].[CustomerGeography].[France]
+
[Customer].[CustomerGeography].[Germany]
Tableau「ビン」
キューブの場合、通常、ビン(メジャー範囲のグループ
化)はモデル化されており、ディメンションウィンドウ内
の属性になっています。 そのため、ビンの共通定義が
可能です。 ユーザーは、Tableauで次のような簡単なMD
Xを使ってビンを作成または変更できます。
str(INT(([Internet Sales Amount] / [Bin Size])) *
[Bin Size])
62
リレーショナルデータベースの場合、通常、ビンはモデ
ル化されていません。 ただし、Tableauには、メジャ
ーについてビンを作成する機能が用意されています。
均等なビン
不均等なビン
機能
キューブ
リレーショナル
文字列の操作
多くの場合、キューブで文字列の操作を事前に行うこと
はありません。 文字列の操作は、Tableauで次のような
簡単なMDXを使って行うことができます。
リレーショナルソースに接続すると、文字列の操作はTa
bleauの計算フィールドを使用して直接実行できます。
これは、大文字と小文字を切り替える、5桁+4桁の郵便
番号から5桁部分を抽出する、その他多数の操作の際に
便利です。
LEFT([Product].[Product Categories].DataMember.Memb
erValue,LEN([Product].[Product Categories].DataMemb
er.MemberValue)-5)
データ型
キューブの場合、データ型(文字列型、日付型、数値型な
ど)と役割(ディメンションとメジャー)は明示的に定義さ
れています。 これにより、事前集計や属性が必ずTable
auの正しいウィンドウに表示されます。
文字列関数
リレーショナルデータベースの場合、Tableauが自動で
列タイプを検出します。 これにより、Tableauで操作
する必要のあるデータ量が制限されます。 Tableauで
データ型を変更する場合は、右クリックでできます。
データ型の変更
KPI、スコアカード
キューブの場合、特定のメンバーがどのKPIグループに属
するかという情報を含む属性を定義できます。 また、
次のような簡単な計算やパラメーターを使用して、Table
auでしきい値KPIを直接作成できます。
リレーショナルデータベースの場合、簡単な計算フィー
ルドを使用して、すばやくKPI計算を作成できます。
KPI計算
[Internet Sales Amount] >= [Desired Sales]
アクション
キューブの場合、Tableauのアクションをすべてサポート
しています。 また、同じワークブック内のアクション
は、キューブからリレーショナルソースへも作用しま
す。 キューブベースのアクションは、Tableauでサポー
トされていません。
アクション
63
リレーショナルデータソース内、複数のリレーショナル
ソースにわたって、またはキューブとリレーショナルソ
ースとの間で、アクションは作用します。 そのため、
2つのデータ型の間で双方向通信が成立します。
機能
キューブ
リレーショナル
階層
これは、Tableauとキューブを一緒に使用する主な利点の
1つです。 Tableauでは、階層を非対称的にまたはギザ
ギザに掘り下げる操作もサポートしています。
リレーショナルデータベースの場合、構築済みの階層は
内包していませんが、Tableauから簡単にその場で構築
できます。
階層の構築
クイックフィルタ
ー
キューブに接続すると、クイックフィルターが階層の一
部を構成していることが分かり、その構造も表示されて
います。 1つの階層の複数の層でフィルターを適用でき
ます。 属性が1つしかない場合は、構造化ビューを避
け、単一層階層にすることができます。
リレーショナルデータベースの場合、クイックフィルタ
ーには構造がなく、1層として表示されます。 このよ
うなクイックフィルターは、右クリック1回でビジュア
ライゼーションやダッシュボードに配置できます。
抽出
キューブには事前集計を行う性質があるため、本質的に
応答が速く、抽出の必要はありません。
リレーショナルデータベースは応答に時間がかかること
がよくあります。 Tableauでは、リレーショナルデー
タに対して高速パフォーマンスを提供する手段として、
高速データエンジンを用意しています。 また、ライブ
接続やデータ抽出などのオプションも用意しています。
別名
キューブの場合、ビジネス上分かりやすい名前がよく格
納されています。 Essbaseに接続すれば、キューブ内で
定義された別名ファイルをどれでも使用できます。
リレーショナルデータベースの場合、独自の別名値を作
成して、ディメンションメンバーの名前を変更できま
す。 これは、何かをグループ化して新しい名前を付け
る際に便利です。
書式設定
フィールドの書式設定(パーセンテージ、通貨など)はキ
ューブで定義されます。 これにより、ユーザーが何も
しなくても、数値は必ず正しく表示されます。
通常リレーショナルデータソースには、書式設定が備わ
っていません。 パーセンテージや通貨の定義は、Tabl
eau内で直接行います。 メジャーを使用するたびに正
しい書式設定で表示されるよう、デフォルトの書式設定
を設定することもできます。
64
機能
キューブ
リレーショナル
並べ替え順序
キューブの場合、属性やディメンション内のメンバーの
並べ替え順序を、開発者が定義できるようになっていま
す。 そのため、属性を使用するたびに、メンバーが正
しい順序で表示されます。 これは、非標準の書式設定
が含まれる場合に便利です。
リレーショナルデータベースの場合、規定の並べ替えは
データベースの定義の一部ではありません。 ユーザー
はTableauでメジャーから得られる並べ替え(売上高によ
る州の並べ替えなど)や、既定の手動による並べ替えを
定義できます。
会計年度
キューブの場合、開発者はキューブ内でさまざまなカレ
ンダーを定義できます。 会計年度、4-4-5カレンダー、
独自の小売カレンダーなど、いずれの場合もTableauはそ
の構造を継承し、同じように動作します。
リレーショナルデータベースの場合、通常、日付のみが
保存され、さまざまなカレンダーは保存されません。
ユーザーはTableauで、新しい会計年度の開始を定義し
たり、4-4-5カレンダーや小売カレンダーを模倣する日
付計算を書いたりすることができます。
65
© Copyright 2024 Paperzz
