分析基盤について
グロースハックチームでは、膨大な量のデータを効果的に管理し、利用者が必要なデータに簡単にアクセスできるようにする仕組みを構築しています。
概要
and roots の分析基盤では、利用者が「効率的で正確なデータ活用を行うこと」を実現するために、 3 層アーキテクチャ という概念を採用しています。
3 層アーキテクチャとは、ステージング層、インターミディエイト層、そしてマート層という 3 つの層からなる構造です。各々の層は特定の役割を果たし、全体として情報の流れをスムーズにします。
- Staging Layer: データの集約地点で、様々なシステムやデータベース、あるいはファイルから必要な生データを収集し、一定の形式に変換します。
- Intermediate Layer: ステージング層から受け取ったデータをビジネスルールや集約処理に基づき、マート層への準備を整える中間調整を担います。
- Mart Layer: 一元管理され整理されたデータを、利用の目的に応じて再加工して提供します。目的に応じたデータ分析やレポート作成が容易になります。
これら 3 つの層を通じて、and roots ではデータの正確性を保ちつつ、迅速にビジネスに活用できる情報を提供することが可能となっています。
ユーザーごとの DWH に関与する範囲
一般的に開発メンバー、ビジネスユーザーが関与する範囲は以下の通りです。
分析基盤を支える技術
色々あわせて、月額 70 〜 80 万円くらい掛かっています。
| 役割 | サービス名 | 技術 |
|---|---|---|
| クラウドインフラ | Google Cloud | |
| DWH アプリケーション | BigQuery | SQL |
| データインジェスチョン | Airbyte | |
| データインジェスチョン | Cloud Functions | Python |
| データインジェスチョン | trocco | |
| ELT、セマンティックレイヤー | dbt Cloud | SQL + Jinja |
| マスターデータ管理 | Retool | SQL + JavaScript |
| データカタログ | SELECT STAR | |
| BI | Looker Studio | |
| アドホック分析 | JupyterLab | Python |
| ドキュメント管理 | Docusaurus + Netlify | |
| コード管理 | GitHub | |
| CI/CD | GitHub Actions |
Staging Layer
ここでは、データソースから分析基盤に格納したデータの品質を確保するための データの一時保管庫 として利用しています。
Staging Layer は、さらに Raw Staging、Hard Staging という 2 つの要素に分解することができます。
Raw Staging
Raw Staging は、データソースの生データを格納する場所で、以下の規則を遵守してデータの管理を行っています。
- テーブルの命名規則:
Raw_[MultiTenant]_[Bkcc]_[Stream]_[Table] - データ構造:
any
メタ属性
Raw Staging に存在するメタ属性は、以下の通りです。
| カラム名 | データ型 | 説明 | テスト |
|---|---|---|---|
_LOAD_TS | timestamp | ロード日時。ビジネスオブジェクトを DWH にロードした日時。 | not_null |
Hard Staging
Hard Staging は、Raw Staging から取り込まれた生データに対して、統合化や最新化以外のハードビジネスルール（正規化、型変換、コード値補完）を適用し、さまざまなメタデータを追加します。
- 正規化: 非構造化または半構造化データを構造化データに変換
- 型変換: 目的のデータ型に変換（文字列として格納されていた数値データを数値型に変換）
- コード値補完: コード値をアプリケーションシステムで定義されている言葉に変換
この過程により、データの初期処理と整合性チェックが行われ、データ品質が保証されます。
- テーブルの命名規則:
Hrd_[MultiTenant]_[Bkcc]_[Stream]_[Table] - データ構造:
RDB（※第三正規系ではない） +SCD Type 2
メタ属性
Hard Staging に存在するメタ属性は、以下の通りです。
| カラム名 | データ型 | 説明 | テスト |
|---|---|---|---|
_HASHKEY | string | サロゲートキー。 | not_null |
_MULTI_TENANT_ID | string | マルチテナント ID。複数のテナントでビジネスオブジェクトが作成される場合、_TENANT_ID が区切られて格納される。存在しない場合は default を格納。 | not_null |
_BKCC | string | ビジネスキー衝突防止コード。各プラットフォームの文字列が格納される。存在しない場合は default を格納。 | not_null |
_STREAM_ID | string | ストリーム ID。データソースの識別子（アカウント ID やショップ ID など）が格納される。存在しない場合は default を格納。 | not_null |
_RECSRC | string | レコードソース。データの出典元を格納。 存在しない場合は default を格納。 | not_null |
_LOAD_TS | datetime | ロード日時。ビジネスオブジェクトを DWH にロードした日時。 | not_null |
_LOAD_END_TS | datetime | ロード終了日時。ビジネスオブジェクトの有効期限。 | |
_HASHDIFF | string | ハッシュ差分。ビジネスオブジェクトの変更履歴を追跡。 | not_null、unique |
_TRANSACTION_TS | datetime | 観測日時。ビジネスオブジェクトがデータソースで観測された日時。 |
Intermediate Layer
Intermediate Layer は、Hard Staging から受け取ったデータをビジネスルールや集約処理に基づき、マート作成のクエリの複雑さを解消する中間調整役を担います。
- テーブルの命名規則:
Int_[Table]
Mart Layer
ここでは、データ活用の目的（データ分析やレポート作成、リバース ETL など）に応じて、データを再加工して提供します。
Mart Layer のテーブルは、データの活用の目的と 1 対 1 の関係性で運用します。
- テーブルの命名規則:
[TableType]_[Table]- TableType:
Explore,Report,ReverseETL,Source
- TableType:
Explore
Explore テーブルは、データの利用目的が「データ探索」や「アドホック分析」である場合のみ使用するテーブルです。
Report
Report テーブルは、レポートのパフォーマンス向上や従量課金のコストカットを目的にした「BI ツールのデータ参照元」として使用するテーブルです。
現環境では、カスタムクエリによる定点観測ダッシュボードの作成を一切許可しておりません。
カスタムクエリの結果を BI ツールで可視化したい場合は、グロースハックチームに問い合わせいただき、承認後「レポート読み込み用」としてテーブルを作成致します。
ReverseETL
ReverseETL テーブルは、ダウンストリームの MA ツールから分析基盤のデータを利用するときのエンドポイントとして使用するテーブルです。
Source
Source テーブルは、Hard staging で最低限の処理が行われ、最新のビジネスオブジェクトだけが抽出された、データソースでの関係性をそのまま再現したテーブルです。
カラムが全て存在するので、データウェアハウスのような使い方をすることができます。
Explore テーブルや Report テーブルに追加したいカラムがあればグロースハックチームに連絡してください。