見出し画像

【Tableau】サービスの運用改善から見えた空間データ作成のコツ

NAVITIME_Tech

この記事は、NAVITIME JAPAN Advent Calendar 2024の13日目の記事です🎄

こんにちは、にんにくです。
ナビタイムジャパンの移動データ事業部で移動ビッグデータの分析・可視化を担当しています。
今回はTableauで提供しているWeb分析システムのデータ運用改善で得られた知見を説明します。

本記事では「Tableau」「Tableau Prep」でのデータ作成に焦点を当てております。
Tableauを使用したことのある方を想定読者としていますので、「Tableau」「Tableau Prep」の使い方に関する説明については割愛しています。
Tableau用語に関する詳細は公式サイトの用語集をご確認ください。


本記事のポイント

  • 「Tableau Prep」から「PostgreSQL」に保存されたジオメトリデータを空間データとして抽出すると非常に時間がかかる
    ※同サイズの文字列データと比較して約60倍の読み込み時間が必要

  • 「Tableau」で空間データを使用する場合は、マスターテーブルとなる.hyperファイルを作成しておく。データの集計後に結合することでデータソースの作成時間を大幅に短縮できます。

背景

今回、データ運用を改善したWebサービスは『インバウンドプロファイラー』※です。昨今の訪日外国人観光客の増加により、取得可能なデータが大きく増えました。これに伴い、毎月のデータ追加・更新にかかる時間もだんだん増えていました。

更新作業には、ローカルのPCリソースをほぼ使い切る工程が含まれております。そのため、実行時間が半日を超えてしまうと、翌日の業務に支障が出てしまいます。また、データの取得からデータ反映までのリードタイムを短縮できれば、データの速報性が上がりサービスの品質向上にもつながります。

改善対象としたヒートマップのデータが使用されている画面

※『インバウンドプロファイラー』は、訪日外国人向け経路検索・多言語観光案内アプリ『Japan Travel by NAVITIME』から利用者の同意を得て取得した
インバウンドGPSデータと属性アンケートを元に、訪日外国人旅行客が集まっている場所や時間帯、季節別の傾向などを簡単に比較、分析が行えるよう可視化に特化したWeb分析システムです。「Tableau」を用いて提供しており、毎月最新のデータ追加運用を行っています。


データ作成手順（改善前）

  1. 「Amazon Athena」でデータを集計
    メッシュ形状データはWell-known text形式で保存されており、レコード単位でメッシュ番号と合わせて出力。

  2. 集計結果を「PostgresSQL」のテーブルへインポート
    Well-known textからgeometry型へ変換

  3. 「Tableau Prep」で.hyperファイルを作成
    2.のテーブルを参照、空間データとして抽出を行い.hyperファイルを作成

  4. 「Tableau Desktop」で.hyperファイルを読み込みパブリッシュ

データ作成手順（改善前）

訪日外国人観光客の増加に伴い、3. のデータ抽出工程に14時間ほどかかるようになりました。データの肥大化により、作業中のPCのメモリとストレージは使い切られ、さらに処理速度が低下する状況に陥っていました。

メッシュ形状データはWell-known text形式で用意していたためTableauで利用するには空間データへの変換処理が必要です。そのためPostgreSQLを利用してTableauから空間データとして認識可能なgeometry型への変換を行っていました。
※かつて「Tableau Desktop」で型変換する手法も行っていましたが、データ肥大化のため「PostgreSQL」の利用に切り替えています。

データ作成手順（改善後）

  1. 空間データのマスターとして正規化データを作成し.hyperファイルとして保存。
    ※今回は日本の125m, 250m, 500m, 1km, 10kmのメッシュデータを作成

  2. 「Amazon Athena」でデータを集計。
    メッシュ形状データは出力せず、メッシュ番号を出力

  3. 「Tableau Prep」で.hyperファイルを作成
    2. の集計結果と1. で作成したマスターを結合し、集計結果に空間データを付与

  4. 「Tableau Desktop」に.hyperファイルを読み込みパブリッシュ

データ作成手順（改善後）

改善の結果、Tableau Prepでデータを作成していた 3.の工程が大幅に短縮され、ジオメトリオブジェクト付き.hyperファイルの作成が14分で終わりました。

あらかじめ空間データのマスターを作成しておくことで、集計結果のレコードごとに発生していた「PostgreSQLのジオメトリオブジェクトを空間データとして抽出する」工程を「データの結合」に置き換えることができました。この「PostgreSQLのジオメトリオブジェクトを空間データとして抽出する」工程は同量の文字列データを読み込む場合と比較して約60倍の時間がかかります（1800万行のテストデータで計測）。そのため、形状データをレコードごとに保持し都度空間データに変換するのではなく、事前にマスターを用意して集計データと結合するアプローチを採用しました。

おわりに

「Tableau」で空間データを扱う際には、パフォーマンスやデータサイズとのバランスを考えると、最終的に.hyper形式で管理するのが便利に感じられることが多いかと思います。データの管理・集計方法として、「正規化したデータベースを用意して集計時に結合する」という手法は一般的なものとして知られています。今回は、「Tableau」でこの考え方を活用する場合についてご紹介しました。

運用改善のために作成したマスターデータでしたが、チーム内で重宝しており様々な業務で利用されています。以前よりも気軽に可視化ができるようになり、分析の試行回数を増やすことができる副次効果も感じられています。みなさまもぜひ作ってみてはいかがでしょうか。