#tc18 Expedia社での活用事例 – Tableau Conference 2018 at New Orleans

目次

本エントリーでは、2018年10月23日に実施されたTableau Conference@ニューオーリンズにて実施された「Expedia社」のセッション内容についてご紹介します。 目次は下記の通りです。

• 1.セッション概要
• 2.Guiding Principles(基本原則)
• 3.Platform
• 4.なぜファクトテーブルが必要なのか
• 5.Familiar Concepts
• 6.ベストプラクティス
• 7.学んだ事
• 8.Tableauの最適化
• 9.結論
• 10.まとめ

1.セッション概要

本セッションの概要は、下記の通りです。

2.Guiding Principles(基本原則)

開発作業等を進める前に、まずは基本原則となる事柄を整理しています。 以下から、セッションでの報告内容です。

トランザクションデータはセルフ分析に使える状態で格納されているとは限らず、

そのため、セルフ分析を推進するためには下記三点の対応が必要、とのことでした。

• ファクトテーブルとVIEWを用意する
• メトリックスを作成する（例えば、複雑で利用頻度が高そうなIF文のフィールドを、あらかじめ作成しておくようなイメージ）
• データソースを管理する

また、レポーティングを推進するためには下記の3点が必要、とのことでした。 いずれも、レポーティングする際に毎回０から開発する必要がない状態にすることが重要です。

• パラメータに基づいたレポート
• ピボット/チャートのビルダー
• 修正できるテンプレート

3.Platform

Expedia社では、どのような環境でTableauを利用しているのでしょうか。 今回のセッションでは、「環境構成図」と「戦略」について語ってくれました。

3-1.環境構成図

ズバリ、下記のような構成図のようです。

画質が悪くてすいません。 左の部分はオンプレや既存サーバからJsonファイルをS3に保管、真ん中の上部はRDS、DynamoからEMRで処理した結果をS3に保管、という流れです。 そしてそれらのファイルを「AWS Data Pipeline」で処理し、その処理結果をRedshiftにCOPYして、TableauからRedshiftを参照する、という構成でした。 S3を中心として諸々のデータを集約し、集計の早いRedshiftを参照する、という綺麗な構成だと思います。

3-2.戦略

環境を要素ごとに分解し、重要度を明確にしています。 Expedia社では「どのような情報を提供するか」を最優先事項、「データをどのように加工・保管するか」をその次に重要な事項としていました。

また、環境全体を通して「シンプルであることを保つ」ことが必要だとも語っていました。

4.なぜファクトテーブルが必要なのか

Tableauを活用するためには、ファクトテーブルを作成する必要があります。 これはトランザクションテーブルはそのままでは「セルフ分析に使える状態ではない」ためです。 セッションでは、マスターテーブルとトランザクションテーブルを結合して、ファクトテーブルを作成する例で紹介していました。

5.Familiar Concepts

データを管理するための基本的なコンセプトについても報告していました。

• 矛盾がなく、わかりやすい名前をつける
• ソートするために、ナンバリングしておく
• フォルダー等を作成し、階層構造にしておく
• メジャーを作成しておく

どれも基本的なことですが、これらを徹底すればデータ管理がかなりシンプルになりそうですね。 メジャーの作成については、「同じような意味合いのメジャー」を「異なるユーザーが各々作成」してしまうと、「各人の作業時間が増えたり」、「人によって定義が異なること」に繋がるので、大変そうですが出来るだけ徹底したいところですね。

6.ベストプラクティス

本セッションでは、ベストプラクティスとして下記の2点をあげていました。

• VIEWを使うこと
• 一般的、記述的、かつ可読性の高い名前をつけること

VIEWを使うことで、修正時の手間を削減できます。 名前づけについてはBIユーザー＆エンジニアどちらにとっても使いやすい名前をつける事が重要です。

7.学んだ事

Tableauの利活用を推進する上で学んだことについても報告されました。 こういった、「実際にやってみて学んだこと」といった知見は貴重ですね。

下記の3点が挙げられています。

• 500M以上のデータを抽出しないこと
• パフォーマンスについて、常に考えておくこと
• 構成を変更するためにXMLを修正すること

8.Tableauの最適化

Tableauの最適化のためにどのようなことが必要か、についても報告されました。

今まで報告された事柄と一部重複がありますが、「データソースを階層的にする」、「利用していないカラムは隠す」といった対応は重要なものの、見落としがちなので注意が必要です。

9.結論

本セッションの結論として、下記のようにまとめています。

• Think about Guiding Princpals(基本原則を考えよう)

詳細については2.Guiding Principles(基本原則)に記載の通りですが、「現状はどうなっていて」、「何が必要か」と言ったことを最初に「基本原則」として整理しておかないと、何かあった際の判断基準に困ることになってしまいます。

• Engineered Tables - What tables can you engineer

詳細については4.なぜファクトテーブルが必要なのかに記載の通りです。 「何のために」、「どのような構成で」、「どういった管理体制（わかりやすい名前を付ける等）で」テーブルを作成するのかを考慮する必要があります。

• Simple, intuitive and familiar self-service

セルフ分析を進めるためには、シンプルかつ直感的である必要があります。 例えば、5.Familiar Conceptsで述べている事柄が特にマッチしそうです。

• send yourself and email

ダッシュボード自体をEメール等で送ることで、ユーザーに「最新時点のダッシュボード」を簡単に周知することができます。 これも、ユーザの手間を削減することに繋がるので有用な手法です。 サブスクリプションのサーバー設定

10.まとめ

以上でセッション内容の報告については終了です。 Tableauを利用している、もしくはこれからの利用を検討している方に、もし上記の方策が参考になったら幸いです。

また、本エントリー執筆時点でYoutubeにセッションの動画がアップロードされていましたので、もしよろしかったらこちらもご覧ください。 (動画が再生されるので、音に気をつけてください)

また、このほかのセッションについても、下記のチャンネルで検索すると閲覧できるかもしれません。 YoutubeのTableauのチャンネル