いつも分析基盤のご利用いだだき、誠にありがとうございます。
グロースハックチームは、データの利用者に「最高のデータ体験」を提供することを目指しております。
その一環として、データ利用の簡略化と効率化、保守性の向上を図るべく、運用体制のアップデートを行うことになりました。
変更点
今回の変更内容は、以下のようになっています。
- DWH Layer の廃止、Intermediate Layer の導入
- Mart Layer の強化
- Associate 認定試験の内容変更と開催延期
4 月末までに完全切り替えできるように、準備しています。
なるべくビジネスユーザーの工数がかからないように設計しているので、安心して下さい。
1. DWH Layer の廃止、Intermediate Layer の導入
現環境では、データ利用時に基本は Mart Layer、探索用に DWH Layer をご利用頂いているかと思います。
今回の変更に伴い、新しい環境では次のようなスコープになります。
構造が複雑な DWH Layer のアクセス権がなくなることで、未経験者の参入障壁が低くなったり初学者の学習コストが下がったりと、ビジネスユーザーは今まで以上にデータを活用することにフォーカスできるようになります。
従来の探索目的での DWH Layer の利用に関しては、次セクションの内容でカバーできるので、アクセスできるデータが減る訳では無い点はご安心ください。
Intermediate Layer に関しては、開発メンバーにのみ関与する内容となっているので、内容は割愛します。
2. Mart Layer の強化
テーブルの命名規則が変わり、テーブル 1 つ 1 つの役割が今まで以上に明確になります。
- テーブルの命名規則:
[TableType]_[Tenant]_[BKCC]_[Table]- TableType:
Explore,Report,ReverseETL,Source
- TableType:
2-1. Explore
Explore テーブルは、データの利用目的が「データ探索」や「アドホック分析」である場合のみ使用するテーブルです。
2-2. Report
Report テーブルは、レポートのパフォーマンス向上や従量課金のコストカットを目的にした「BI ツールのデータ参照元」として使用するテーブルです。
現環境では、カスタムクエリによる定点観測ダッシュボードの作成を一切許可しておりません。
カスタムクエリの結果を BI ツールで可視化したい場合は、グロースハックチームに問い合わせいただき、承認後「レポート読み込み用」としてテーブルを作成致します。
2-3. ReverseETL
ReverseETL テーブルは、ダウンストリームの MA ツールから分析基盤のデータを利用するときのエンドポイントとして使用するテーブルです。
2-4. Source
Source テーブルは、Hard staging で最低限の処理が行われ、最新のビジネスオブジェクトだけが抽出された、データソースでの関係性をそのまま再現したテーブルです。
カラムが全て存在するので、データウェアハウスのような使い方をすることができます。
従来の Raw DWH + Reference Table みたいなイメージです。
2-5. まとめ
- BI ツール（Looker Studio）と接続:
Report_* - SQL や Python などで、データ探索:
- デフォルト:
Explore_* - DWH:
Source_*
- デフォルト:
ReverseETL に関しては、ビジネスユーザーが触る機会は無いと思います。
3. Associate 認定試験の内容変更と開催延期
従来は and roots 独自の DWH 全体の理解を求めていましたが、DWH Layer の廃止に伴い、Mart Layer だけの運用に切り替わるので、今後は DWH 全体の理解は求めなくなりました。
したがって、Associate 認定試験の範囲が狭まり、試験自体の難易度が少し下がります。
全社切り替わったタイミングで試験を再開しますので、次回の予定は 2024 年の 4 月または 5 月ごろとさせていただきます。
切り替えにあたって
簡単にヒアリングしたところ、 DWH Layer、Mart Layer の利用状況は以下のようになっています。
| 対象 | DWH | Mart |
|---|---|---|
| hugkumi | 90 % | 10 % |
| from, esella | 20 % | 80 % |
| bris | 0 % | 100 % |
| minawa | 100 % | 0 % |
| hide_amazon | 0 % | 100 % |
| hide_rakuten | 100 % | 0 % |
スケジュール（予定）
2024 年の 4 月末までに、すべてのデータ利用者が DWH を参照しなくなるようにしたいと考えています。
以下は、移行プロセスの目安です。次節の現状把握で前後する可能性があるので、変更があり次第個別に連絡します。
| 対象 | 対象者 | 開始日 | 終了日 |
|---|---|---|---|
| minawa | 平井 | 2 月 22 日 | 3 月 8 日 |
| hide_ec | 粟宮、谷水 | 3 月 11 日 | 3 月 22 日 |
| bris | 満塩 | 3 月 25 日 | 4 月 5 日 |
| from, esella | 仁摩、西島 | 4 月 8 日 | 4 月 26 日 |
| hugkumi | 中島、井上 | 3 月 4 日 | 4 月 26 日 |
準備していただきたいもの
現状把握とレポート管理を最適化したいので、現在利用しているダッシュボード、コネクテッドシートの詳細を 1 つずつ教えてください。
- URL
- テクニカルオーナー（作成者）、ビジネスオーナー（閲覧者）
- 利用者、または利用グループ、
- 作成した目的
- 確認している指標
- 利用頻度
- 作成するにあたって、カスタムクエリを利用しているかどうか
- Slack 通知しているいる場合、「チャンネル名」と「通知頻度」、「通知方法」
Q&A（随時更新）
利用者から寄せられた質問に関しては、随時このセクションで回答します。
1. 切り替えに当たって、ビジネスユーザーが手を動かす必要はありますか？
直接手を動かすことは無いです。
カスタムクエリでレポートを作成している場合、それ用のマートテーブル（Report_[table]）を作成し、グロースハックチーム側で Looker Studio と再接続します。
2. 移行期間中に追加したものは都度連絡しないといけないですか？
都度連絡して欲しいです。
3. 切り替えは健太さんが行うのはわかるが、別に Mart を作る際には連絡が必要ですか？
都度連絡して欲しいです。
確定事項ではないですが、将来的には Mart の作成権限をビジネスユーザーに与えることも考えています。
4. 修正が必要になった場合は、連絡したら対応してくれますか？
修正後のビジネスロジック（SQL）はビジネスユーザー側で考えて、連絡して欲しいです。