AWSのQuickSightの導入を始めようとしている人に伝えたい気を付けるポイント4選

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

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

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

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

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

![chrome-capture-2023-4-22 (1).gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952834/a6a59ce2-443c-7735-7988-66c8c30636ec.gif)

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

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


## 4選
- [データセット設計](#データセット設計)
- [SPICEへの同期](#SPICEへの同期)
- [ディレクトリ構成](#ディレクトリ構成)
- [アカウント名](#アカウント名)

### データセット設計
気を付けるポイント：
- 分析に適したデータセット設計を理解する

メモ：
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選」を紹介させていただきました。

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

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