はじめに

課題の早期発見、改善を実施するためにAWSのQuickSightを導入しデータの可視化を実現しました。その際に、仕様の調査に時間がかかったことや認識に誤りがあり手戻りになってしまったこと4選をまとめました。

サンプル

QuickSightを利用したことがない人向けにイメージとしてサンプルのダッシュボードを作成しました。

ユーザー	売上目標/日
営業A	6000
営業B	5000
営業C	4000

商材	売上	原価
商品A	2000	1000
商品B	1800	900
商品C	1500	700

ユーザーは毎日0から6個、いずれかの商材を売っているものとしています。

上記のようにプルダウンから営業の絞り込みやビジュアル上での商材の絞り込みなどボタンをポチポチしているだけで実現出来ます。

サンプルのものは30分くらいで作りました。

データセット設計

気を付けるポイント：

分析に適したデータセット設計を理解する

メモ：
QuickSightはデータセットに登録したデータを分析で利用しデータの可視化を行います。
そのため、データセットにデータがどのように登録するのが適切か理解しないと、分析で期待するような値が表示されません。

今回のサンプルは以下のように作成しました。

ユーザー	日付	種別	商材	売上	原価	目標	粗利	販売数
ユーザーA	2023-04-01	item	商品A	2000	1000	0	売上 - 原価	count({種別}="item")
ユーザーA	2023-04-01	item	商品B	1800	900	0	売上 - 原価	count({種別}="item")
ユーザーB	2023-04-01	item	商品B	1800	900	0	売上 - 原価	count({種別}="item")
ユーザーC	2023-04-01	item	商品C	1500	700	0	売上 - 原価	count({種別}="item")
ユーザーA	2023-04-01	goal		0	0	6000	売上 - 原価	count({種別}="item")
ユーザーB	2023-04-01	goal		0	0	5000	売上 - 原価	count({種別}="item")
ユーザーC	2023-04-01	goal		0	0	4000	売上 - 原価	count({種別}="item")

ポイントは3つです。
1. 軸が異なるが同じ分析で利用したい値(今回の商品系と目標)は、種別のように値を分けて管理しそれぞれの値を格納するカラムを用意する
　⇒特定の軸でのcount()やsum()などの集計が容易になります。

2. 軸が異なり関係のない数字の値には、nullではなく0を入れる
　⇒ビジュアル化の際にnullのカラムが除外されることがあり、期待している計算結果にならないことがあるためです。

3. 計算フィールドの関数数を利用し、集計を実施する
　⇒可能な限りデータセットで作りこんだ方がビジュアル化の時楽です。

SPICEへの同期

気を付けるポイント：

増分更新の仕組みを理解する

メモ：
QuickSightにはSPICEというインメモリエンジンがあります。

SPICEの更新方法としてフル更新/増分更新があるのですが増分更新はかなり癖があります。

確認した範囲では以下の挙動をしてそうです。

挙動

1. 更新元に増分対象のデータが存在しなければ終了
2. 更新先の増分対象のデータを削除
3. 増分対象のデータを登録

一件delete,insertに見えますが。。

上手くいかない例

■ 前提
1日1回前日分を更新する
更新の基準日はレコードの更新日

■ サンプル

更新元

ユーザー	売上目標/日	更新日
営業A	6000	2023-04-01
営業B	5000	2023-04-01
営業C	4000	2023-04-01

更新先

ユーザー	売上目標/日	更新日
営業A	6000	2023-04-01
営業B	5000	2023-04-01
営業C	4000	2023-04-01

■ 上手くいかない例
サンプルの状態で2023-04-02に「営業B」を「営業B+」に変更したとする
更新元は下記の表になる

更新元

ユーザー	売上目標/日	更新日
営業A	6000	2023-04-01
営業B+	5000	2023-04-02
営業C	4000	2023-04-01

この状態で2023-04-02で増分更新すると更新先は下記表になる

ユーザー	売上目標/日	更新日
営業A	6000	2023-04-01
営業B	5000	2023-04-01
営業C	4000	2023-04-01
営業B+	5000	2023-04-02

営業Bがなぜか残る。。
これは更新先には2023-04-02のレコードがないため削除されないが、更新元には2023-04-02のレコードがあるため追加されこのような結果になってしまいます。

この結果を踏まえて、増分更新はログなどの追加しか発生しないもので利用した方が良さそうです。

ディレクトリ構成

気を付けるポイント：

外部から見えることを意識する

メモ：
QuickSightで作成したダッシュボードは、共有フォルダに格納し権限のあるユーザーだけ閲覧が可能になるように設定出来ます。

QuickSightはアプリなどでスマホなどから閲覧出来るのですが、共有フォルダがそのまま出ます。
例えば、開発環境、本番環境などで別れている場合。。

サービス名
    ├ 開発環境
    |    ├ ダッシュボード1
    |    └ ダッシュボード2
    └ 本番環境
         ├ ダッシュボード1
         └ ダッシュボード2

みたいな構成にしていたのですが、ユーザーがダッシュボード1を見たいときに「本番環境」というディレクトが見えてしまう結果になりました。。

アカウント名

気を付けるポイント：

適当な名前を付けない

メモ：
アカウント名は、アプリのログイン時など外部から見えます。
しかし、後から変更出来ないため「まずはお試しで・・・」という気持ちで適当な名前を作ると取り返しのつかないことになります。

分析などを作りこんだ後に、気づいて大変なことになりました。

まとめ

「AWSのQuickSightの導入を始めようとしている人に伝えたい気を付けるポイント4選」を紹介させていただきました。

データの可視化は企業にとって必要不可欠な一方で、ツールなどに頼らないとエンジニアには大きな負担になります。慣れるまでに少し時間はかかりましたが、今後の保守まで考えるとエンジニアの負担を大幅に軽減出来るツールだと思います。

導入を実施する前の資料として参考になればうれしいです。