【寄稿】TableauからAmazon QuickSightへの切替に対する技術検証

この投稿はアクセンチュア株式会社 テクノロジーコンサルティング本部所属のエンジニア 杉本 優里 氏、金 敬源 氏、 マネージャー 竹内 誠一 氏に、TableauからAmazon QuickSightへの切替に対する技術検証の結果について寄稿いただいたものです。

本ブログは、2022年5月ごろにあるお客様でTableauからAmazon QuickSightへの切り替えを提案した経験から得られた、Amazon QuickSightへのダッシュボード移⾏のHints&Tipsをご紹介します。

このお客様では、Tableauダッシュボードをプロジェクトの開発⽣産性向上に活⽤しています。具体的にはプロジェクト管理ツールやコードレビューツールのデータを収集・蓄積し、様々な切り⼝で集計して表やグラフで表⽰したり、切り⼝や集計範囲を変えながら分析したりしています。

お客様はダッシュボードの利⽤範囲の拡⼤を計画する⼀⽅で、ダッシュボードのコストは極⼒抑制したいと考えており、安価な従量課⾦で、運⽤負荷の⼩さいマネージドサービスのAmazon QuickSightへの移⾏を望んでいました。しかし現在利⽤中のTableauは表やグラフの表現⼒に定評のある製品で、ダッシュボードではその製品固有の複雑な関数も使⽤しているため、現⾏と同等の表現⼒・分析⼒を提供できるダッシュボードをAmazon QuickSight上で再現するのは難しいかもしれないと考えておられました。

このような懸念は机上の仕様⽐較だけで解決するのは難しいものです。そこで現⾏のTableauダッシュボードとデータソースのサンプルを⽤意し、Amazon QuickSight上で同等のダッシュボードを作ってみて、操作体験に基づいて移⾏の是⾮を判断することにしました。

本ブログではTableauダッシュボード表現のAmazon QuickSightへの移行と、移行後の運用方法検討の大きく２軸でご紹介を進めてまいります。

1. Amazon QuickSightの分析への移行検討

• ピボットテーブル関数
• 大量データ処理

2. 運用方法検討

• 求められた環境構造
• 環境ごとの共有フォルダを使った運⽤の流れ
• 共有フォルダの権限設定
• 分析（Analysis）の複製

3. 実現できなかった機能

4. 総括

1. Amazon QuickSightの分析への移行検討

ピボットテーブルの関数

Tableauではビューの表⽰に使われるディメンションの粒度とは異なる粒度で集計テーブルを作成できる機能があります。この機能はLOD 表現と呼ばれ、従来の BI ツールでは中間テーブルを作成しないと表現ができない計算を実現できます。その中で既存のTableauピボットテーブルではInclude、Fixed、Excludeを使い、テーブルを定義しています。

Amazon QuickSightではレベル対応の集計を使い、テーブル表⽰に使われるディメンション単位の集計が可能です。今回のLOD表現はピボットテーブルに限られ、ピボットテーブルの拡張、折りたたみにより集計が変わってしまい、Amazon QuickSightのレベル対応の集計だけでは具現できませんでした。レベル対応の集計を加えて下記の⽅法を使⽤し、Amazon QuickSightのピボットテーブルでLOD表現の具現化を検証しました。

レベル対応の集計

Amazon QuickSightではLAAと呼ばれ、計算フィールドとクエリ内の表⽰レベルの集計に関連して、集計をいつ計算するかを選択できるレベル対応の集計があります。

ピボットテーブルのテーブル計算

Amazon QuickSightではテーブル計算を使⽤して、測定 (数値) を含むピボットテーブルのセルに統計関数を適⽤できます。

計算フィールド

計算フィールドは、データセットもしくは分析の編集において、1つまたは複数の関数と既存のフィールド値を⽤いて計算を実⾏、結果を出⼒するフィールドです。

AVG({INCLUDE [sprint_name]: SUM([story_point])})

テストピボットテーブルは以下となります。

⾏はproject_name、team_name、sprint_nameで分けられ、列は各sprint_nameのstory_pointをピボットテーブルで表しています。

1. TableauのFixed表現

Fixed表現はビュー内のディメンションに関係なく、指定されたディメンションを使⽤して値を計算します。テストピボットテーブルでビューの集計単位に関係なく、sprint_name毎にstory_pointを合計し、それらの平均を取るLOD表現を作成します。

TableauのLOD表現を使い計算式を作成します。

AVG{FIXED {sprint_name}: SUM({story_point})}

FIXED {sprint_name}でディメンジョンをsprint_nameに指定し、SUM({story_point})でsprint_name毎の story_pointの合計を計算します。

この計算式をAmazon QuickSightで具現してみました。クライアントの希望により、計算式をteam_name列があり/なしに分けて作成しました。

まず、team_name列がありのケースです。

Amazon QuickSightのsumOver()関数はパーティションを使⽤し、計算が含まれるピボットテーブルの範囲を指定して合計を取る事ができます。このsumOver()関数を使ってsprint_name毎にstory_pointを集計してみました。計算レベルはビジュアルに適⽤する前に計算するため、PRE_AGGに指定しています。

Amazon QuickSightでは以下の計算式を作成します。

sumOver({story_point}, [{sprint_name}], PRE_AGG)

結果

team_name列がありのFixed表現はAmazon QuickSightのレベル対応集計とテーブル集計（フィールドウェルでAggregate:Averageをマッピング）を使い、LOD表現と同じように平均を出す事ができました。

team_name列がなしのケースは以下の計算式を作成します。

sumOver(sum({story_point}), [{sprint_name}])/countOver({sprint_name}, [{project_name},{sprint_name}])

countOver 関数は、ディメンションのリストでパーティション分割されたディメンションまたはメジャーの数を計算します。countOver関数を使い、project_nameの中のsprint_nameの数を計算してproject_nameの中のsprint_name の平均を取ります。

結果

team_name列なしのケースはレベル対応の集計と計算フィールドの関数を使い、LOD表現と同じように平均を出す事ができました。Fixed表現をAmazon QuickSightで具現する⽅法を検証したところ、指定したい列のディメンジョンにより、計算式の組み合わせの変更が必要ということが分かりました。

2. TableauのInclude表現

Include表現はビューに含まれるディメンションに加えて、指定されたディメンションを使⽤して値を計算します。

テストピボットテーブルでビューの集計単位を基準にsprint_name毎にstory_pointを合計し、それらの平均を取るLOD表現を作成します。

AVG({INCLUDE [sprint_name]: SUM([story_point])})

story_pointの合計÷選択されたディメンジョンの総数なので、Amazon QuickSightではdistinct_count()関数を使って sprint_nameをグループ化して総数を取ります。

Distinct_count()関数はディメンションまたはメジャーの個別の値の個数を計算し、選択した 1 つ以上のディメンションに基づいてグループ化して返します。

Amazon QuickSightでは以下の計算式を作成します。

Sum({story_point})/distinct_count({sprint_name})

結果

team_name単位

project_name単位

3. TableauのExclude表現

Exclude表現はビューに含まれるディメンションから、指定されたディメンションを除外して値を計算します。ビューの集計単位を基準にsprint_nameを除外してstory_pointを合計し、それらの平均を取る計算式を作成します。

AVG({EXCLUDE [sprint_name]: SUM({story_point})})

Exclude表現の場合はAmazon QuickSightではピボットテーブルの拡張、折りたたみだけでLOD表現と同じように実現できました。

結果

sprint_nameを除外：team_name単位の折りたたみ

team_nameとsprint_nameを除外：project_name単位の折りたたみ

今回はAmazon QuickSightでのレベル対応集計、テーブルの計算、計算フィールドの組み合わせでTableauのLOD表現と同じように結果を出す事ができました。ピボットテーブルの構造と元LOD表現により、計算式の組み合わせが変わるので上記の計算式が正解ではありません。関数の組み合わせを⼯夫することで多様な表現ができると考えました。

⼤量データの表⽰

既存システムでは大量データ表⽰時に計算すると10秒程度表⽰にかかり、パフォーマンスに対してネックに感じていました。データの更新頻度は最短設定の15分で問題なく、容量に対する料⾦も許容範囲とのことでしたので、Amazon QuickSightでは高速ストレージのSPICEに全データを保存し検証することとなりました。約30万件のデータを利⽤し、ピボットテーブルで利⽤可能な最⼤項⽬数（20個）を利⽤した表を3つ⽤意しました。その表には関数やフィルターや条件付き書式を指定し可能な限り⼤量の処理を⾏うようにしています。

結果、複数の条件を適⽤した場合でも、既存システムの描画速度より⾼速であることがわかり、よりAmazon QuickSightの利⽤の意思を固めていただけました。

2. 運用方法検討

求められた環境構造

一般的なソフトウェア開発プロセスと同様にダッシュボードを段階的に開発・デプロイするため、今回は本番・検証・開発の3つの環境を立てるべく環境分離を求められました。現行システムで環境分離を実現しているため、Amazon QuickSightでの実現は必須でした。またデプロイプロセスを極力自動化することも要望されました。こちらは現行システムで未実施のため必須要件ではありませんが、Amazon QuickSightへの移行を契機に自動化を推進したいと考えていました。

Amazon QuickSightは1アカウントにつきリージョンを跨いで1つが基本です。namespaceを利⽤することで複数の環境を持つことは可能ですが、認証方法がIDフェデレーションに限定される、Amazon QuickSightのGUIでは管理できない等の制約があるためこの⽅法は見送りました。

マルチアカウントで環境分離を⾏う⽅法は、「【開催報告】AWSで実践！Analytics Modernization 〜事例祭り編〜」にて紹介されており、作成した分析をテンプレート化することで複製時にそのアカウントで作成したデータセットを参照するように変更することができます。

しかしながら、1アカウントで運⽤を⾏いたいという要望が強く、Amazon QuickSightの運用設計にて共有フォルダを活⽤した運⽤⽅法が紹介されていることを発⾒し、この⽅法を深掘りしました。

環境ごとの共有フォルダを使った運⽤の流れ

1アカウントで共有フォルダを使った運⽤をする流れを検討しました。開発・検証・本番の3つの環境ごとにDBが分かれている前提で、それぞれを1つのAmazon QuickSightからアクセスした場合は以下になります。

1. データセットを作成
2. 分析を作成（開発）
3. ダッシュボードを作成
4. 共有フォルダに格納
5. 分析を複製（検証）
6. データセットを変更
7. ダッシュボードを作成
8. 共有フォルダに格納
9. 5〜8を本番⽤に繰り返す

下図を⾒ていただけるとイメージしやすいかと思います。以降この運⽤に関して述べていきます。

共有フォルダと権限設定

環境分離の項⽬でも触れましたが、Amazon QuickSightの運⽤設計　P25に紹介されている共有フォルダの権限を⼯夫することで、1アカウントで運⽤することができるのではないかと考えました。共有フォルダにはデータセット、分析、ダッシュボードを格納することができます。今回はダッシュボードを分離したかったのですが、下図のように環境ごとの共有フォルダを用意して適切に権限を割り振ることで、今回求められた環境分離を実現できます。

分析やダッシュボードを個別共有するとなると、1つずつユーザーグループやユーザを紐づける必要があり共有先のミスに繋がります。共有フォルダを利⽤しても手作業であることは変わりなく、格納先間違いが起きる可能性はゼロではありません。しかし、権限のある場所のみに格納できるため個別に設定するよりも管理が容易になります。可能な限り⼿作業を減らしたいため、「共有フォルダへの格納」も⾃動化できるとより運⽤しやすくなります。

分析（Analysis）の複製⽅法

分析を複製するにはCLIを使いテンプレート化する⽅法と、GUIを使って複製する⽅法の２つあります。

まずは、CLIを使ってテンプレート化する⽅法は「Amazon QuickSight のテンプレートを使⽤して、クロスアカウントアクセスを設定する⽅法」を参考に実⾏します。CLIでのみ対応できる⽅法ではありますが、テンプレート化することにより分析に設定したいデータセットをARNベースで指定して切り替えることができることは良い点です。⼀⽅で、この⼿順により作成したテンプレート⼀覧はテンプレート⼀覧APIでのみ参照ができます。Amazon QuickSightに⼀覧を⾒るための画⾯は存在しません。

GUIの場合は「分析の複製」を実⾏します。分析を開き「別名で保存」することにより複製可能です。

3. 実現できなかった機能

運⽤観点求めていたのは可能な限り⼿作業をなくす⼿段です。その中でできなかったものが4つあります。

1.      分析内で作成したグラフの共有

1つのグラフや表を複数のシート・ダッシュボードで共有したいという要望がありました。1つのグラフ情報を修正すると同じグラフのデータが更新されるイメージです。現⾏システムにて、同じグラフを複数のダッシュボードで利⽤しており、グラフ更新時の反映漏れを無くしたいためです。この機能はAmazon QuickSightにはありませんでした。

代替案として、複数のユーザーやユーザーグループに配布したいグラフや表を抜き出してひとつのダッシュボードに集め、そのダッシュボードのコピーを複数の宛先に配布する方法を提案しました。ダッシュボードをまたがってグラフや表を共有したりコピーしたりできなくても、ダッシュボードのコピーと一緒にグラフや表を配布できます。ただしダッシュボードの数が増えるので、ユーザーにとっても運用担当者にとっても煩雑さの増加がデメリットになります。

2.      分析のエクスポート∕インポート

分析をJSONやXML形式でエクスポート∕インポートができれば、JSONやXMLを編集することで部分的に変更を⾏ったり、ローカルで新たな分析を作成し組み合わせを⾃由に変えられるなど、運⽤の幅が広がると考えました。分析の編集や新規作成やデプロイを自動化することも可能になります。しかし残念ながらAmazon QuickSightからエクスポートできる形式はPDFかCSVです。ダッシュボードを見たままの状態でPDFに出⼒でき、グラフで使われているデータをCSVで出⼒できますが、分析で使⽤しているグラフ等を記述する情報を出⼒することは叶いませんでした。

Amazon QuickSightからエクスポートできるものとしてはテンプレートもあります。テンプレートは分析のARNを含んでいますが、それより細かい粒度のグラフや表の情報は含んでいませんでした。

以上の検討により今回の検証の時点では、分析をエクスポート／インポートする方法はないと判断しています。

3.      計算フィールドの環境間コピー

分析を作成する際に計算フィールドも一緒に作成・更新することはめずらしくありません。実はこの計算フィールドは分析には含まれず、接続先DB等のデータソースの情報とともにデータセットに格納されます。今回想定する環境では、データソースは開発、検証、本番の各環境で異なるため、データセットも環境ごとに作成します。したがって分析を開発した後で検証環境や本番環境にコピーしていく際に、計算フィールドも検証環境や本番環境のデータセットにコピーしたいのですが、計算フィールドだけをコピーする方法は提供されていませんでした。

そこで代替手段として２つの方法を考えました。一つ目は、開発環境のデータセットを検証環境にコピーし、コピー先のデータセットのデータソース情報を検証環境のものに置き換えるという方法です。この方法はGUIでのみサポートされます。もうひとつは、describe-data-set CLIで開発環境のデータセットの情報をJSON形式で取得し、そこから計算フィールド情報を抽出してcreate-data-set CLIの入力に渡し、このCLIで検証環境のデータセットを作り直すという方法です。describe-data-setの出力を読み取ってcreate-data-setの入力を組み立てるプログラムの開発は必要ですが、CLIベースの方法なので運用自動化が可能です。

4.      ダッシュボード作成と同時にフォルダへ格納

ダッシュボード作成と同時にシェアするフォルダを指定することができれば、⼿作業を減らすことができると考えていました。しかしながら、GUIを使った場合はダッシュボードを作成→ダッシュボード⼀覧を表⽰→メニューから格納フォルダを指定の3つの作業をしなければなりません。

CLIのcreate-dashboardにも格納先フォルダを指定する⽅法はありませんが、create-dashboard実行後にcreate-folder-membershipを実行することでフォルダに格納できます。シェルスクリプト等の工夫により、この２つのCLIをまとめて一回で実行する方法は考えられます。

4. 総括

TableauとAmazon QuickSightという互換性のないBIツール間の移⾏が成功する可能性はケースバイケースで、ベストプラクティスのようなものを確⽴することは難しいと思います。ただし元のダッシュボードと⾒た⽬まで同じものを⽬指すのではなく、実際に何を得たいかを明確にすることでTableauからAmazon QuickSightへの移行が可能になると考えます。今回紹介した⽅法は広く応⽤できるとは限りませんが、移⾏上の考慮点と対策の⼀例として参考にはなると思います。

一方で運用観点では、GUIでしかできない操作とCLIでしかできない操作が混在していて、わかりにくさを感じたことは否めません。すべての操作にGUIとCLIの選択肢を用意すべきとは思いませんが、運用自動化を目指すならダッシュボードのデプロイのパイプライン化に必要なCLIが拡充されたら嬉しいですし、テンプレートをベースにしたダッシュボード開発を目指すなら、テンプレート操作からダッシュボード開発まで一貫してGUIでできるほうが使い勝手がいいです。

このブログで取り上げたTableauからAmazon QuickSightへの切り替え提案に取り組んだ2022年5月以降、Amazon QuickSightに関連して重要な新機能が今日までにいくつも発表されています。このブログでは新機能には踏み込みませんでしたが、もし現時点でTableauからAmazon QuickSightへの切り替えを検討したら、より洗練された移行方法を提案できたことでしょう。Amazon QuickSightの改善努力が継続されているという事実はAmazon QuickSight選択への大きな励みになります。上記の運用観点での要望実現も夢ではないと願いつつ、Amazon QuickSightのさらなる機能拡充・使い勝手の向上に期待しています。

著者について

	杉本 優里 アクセンチュア株式会社 テクノロジーコンサルティング本部 インテリジェントクラウドイネーブラーグループ所属
	金 敬源 アクセンチュア株式会社 テクノロジーコンサルティング本部 インテリジェントクラウド アンド インフラストラクチャー グループ所属
	竹内 誠一 アクセンチュア株式会社 マネジャー　テクノロジーコンサルティング本部 インテリジェントクラウド アンド インフラストラクチャー グループ所属