Skip to main content

分析基盤について

グロースハックチームでは、膨大な量のデータを効果的に管理し、利用者が必要なデータに簡単にアクセスできるようにする仕組みを構築しています。

概要​

and roots の分析基盤では、利用者が「効率的で正確なデータ活用を行うこと」を実現するために、 3 層アーキテクチャ という概念を採用しています。

3 層アーキテクチャとは、ステージング層、DWH 層、そしてマート層という 3 つの層からなる構造です。各々の層は特定の役割を果たし、全体として情報の流れをスムーズにします。

  • Staging Layer: データの集約地点で、様々なシステムやデータベース、あるいはファイルから必要な生データを収集し、一定の形式に変換します。
  • DWH Layer: 収集されたデータを整理し一元管理します。また、企業のビジネスルールに従った形にデータを加工、変換し、ビジネス上の意味を持つ情報へと変換します。
  • Mart Layer: 一元管理され整理されたデータを、利用の目的に応じて再加工して提供します。目的に応じたデータ分析やレポート作成が容易になります。

これら 3 つの層を通じて、and roots ではデータの正確性を保ちつつ、迅速にビジネスに活用できる情報を提供することが可能となっています。

ユーザーごとの DWH に関与する範囲​

一般的に基盤メンバー、ビジネスユーザーが関与する範囲は以下の通りです。

グロースハックチームが提供している「分析スキルマップ」において、Advanced レベル以上に到達すると、Mart Layer の作成が許可され、より自由度の高い分析が行えるようになります。

また、Associate レベルでも間接的にはマート層の作成が可能です。これにより、様々な角度からデータを探求し、深い洞察を得ることができます。

分析スキルマップへのチャレンジを積極的に行い、自身の分析スキルを向上させてみてください。

分析基盤を支える技術​

色々あわせて、月 60 万円くらい掛かっています。

役割サービス名技術
クラウドインフラGoogle Cloud
DWH アプリケーションBigQuerySQL
データロードtrocco
データロードCloud FunctionsPython
ELTdbt CloudSQL + Jinja
ELTDataformSQL + JavaScript
マスターデータ管理RetoolSQL
データカタログSELECT STAR
BILooker Studio
BITableau
アドホック分析JupyterLabPython
アドホック分析RStudioR
ドキュメント管理Docusaurus + Netlify
コード管理GitHub
CI/CDGitHub Actions

Staging Layer​

ここでは、データソースから分析基盤に格納したデータの品質を確保するための データの一時保管庫 として利用しています。

Staging Layer は、さらに Raw Staging、Hard Staging という 2 つの要素に分解することができます。

クラスごとの CRUD（2024 年 1 月以降適用予定）createreadupdatedelete
BeginnerFALSEFALSEFALSEFALSE
AssociateFALSEFALSEFALSEFALSE
Advanced / Professional / MasterFALSETRUEFALSEFALSE
グロースハックチームTRUETRUETRUETRUE

Raw Staging​

Raw Staging は、データソースの生データを格納する場所で、以下の規則を遵守してデータの管理を行っています。

  • テーブルの命名規則: Raw_[MultiTenant]_[Bkcc]_[Stream]_[Table]
  • データ構造: any

メタ属性​

Raw Staging に存在するメタ属性は、以下の通りです。

カラム名データ型説明テスト
_LOAD_TStimestampロード日時。ビジネスオブジェクトを DWH にロードした日時。not_null

Raw Staging の具体例​

note

and roots グループの楽天の注文データを格納する場合

記事執筆時（2023 年 7 月）では、グループには 5 つの楽天のショップが存在します。

clienttenantshop
はぐくみプラスhugkumihugkumi ( 354955 )
フロムココロfromfrom & esella ( 334924 )
esella
tellasbrisbris ( 416180 )
bris ( 402128 )
ライフlifelife ( 390167 )

この場合、Data Source との関係性は、以下のようになります。

Hard Staging​

Hard Staging は、Raw Staging から取り込まれた生データに対して、統合化や最新化以外のハードビジネスルール（正規化、型変換、コード値補完）を適用し、さまざまなメタデータを追加します。

  • 正規化: 非構造化または半構造化データを構造化データに変換
  • 型変換: 目的のデータ型に変換（文字列として格納されていた数値データを数値型に変換）
  • コード値補完: コード値をアプリケーションシステムで定義されている言葉に変換

この過程により、データの初期処理と整合性チェックが行われ、データ品質が保証されます。

  • テーブルの命名規則: Hrd_[MultiTenant]_[Bkcc]_[Stream]_[Table]
  • データ構造: RDB （※第三正規系ではない） + SCD Type 2

メタ属性​

Hard Staging に存在するメタ属性は、以下の通りです。

カラム名データ型説明テスト
_HASHKEYstringサロゲートキー。not_null
_HASHKEY_[BUSINESS_KEY]stringビジネスキー衝突防止処理を適用したビジネスキー。マルチテナント環境でのテーブル結合を簡略化。not_null
_MULTI_TENANT_IDstringマルチテナント ID。複数のテナントでビジネスオブジェクトが作成される場合、_TENANT_ID が区切られて格納される。存在しない場合は default を格納。not_null
_BKCCstringビジネスキー衝突防止コード。各プラットフォームの文字列が格納される。存在しない場合は default を格納。not_null
_STREAM_IDstringストリーム ID。データソースの識別子（アカウント ID やショップ ID など）が格納される。存在しない場合は default を格納。not_null
_RECSRCstringレコードソース。データの出典元を格納。 存在しない場合は default を格納。not_null
_LOAD_TSdatetimeロード日時。ビジネスオブジェクトを DWH にロードした日時。not_null
_LOAD_END_TSdatetimeロード終了日時。ビジネスオブジェクトの有効期限。
_HASHDIFFstringハッシュ差分。ビジネスオブジェクトの変更履歴を追跡。not_null、unique
_TRANSACTION_TSdatetime観測日時。ビジネスオブジェクトがデータソースで観測された日時。

Hard Staging の具体例​

note

はぐくみプラスの Amazon の注文データの場合

DWH Layer​

ここでは、企業が持つ様々なデータを一元的かつ整合性を保って蓄積・整理する「データの倉庫」の役割を担っています。

DWH Layer は、さらに Raw DWH、Business DWH、Reference Table という 3 つの要素に分解することができます。

DWH Layer のテーブル構造については、以下のページに ER 図を載せているので参考にしてください。

ユーティリティ > ER 図

クラスごとの CRUD（2024 年 1 月以降適用予定）createreadupdatedelete
BeginnerFALSETRUEFALSEFALSE
AssociateFALSETRUEFALSEFALSE
Advanced / Professional / MasterFALSETRUEFALSEFALSE
グロースハックチームTRUETRUETRUETRUE

Raw DWH​

Raw DWH には、Staging Layer で最低限の品質が担保された、限りなく生データに近いビジネスオブジェクトの最新データが格納されています。

  • テーブルの命名規則: RDW_[Bkcc]_[Table]
  • データ構造: RDB （※第三正規系ではない）

メタ属性​

Raw DWH に存在するメタ属性は、以下の通りです。

カラム名データ型説明テスト
_HASHKEYstringサロゲートキー。not_null、unique
_HASHKEY_[BUSINESS_KEY]stringビジネスキー衝突防止処理を適用したビジネスキー。マルチテナント環境でのテーブル結合を簡略化。not_null
_MULTI_TENANT_IDstringマルチテナント ID。複数のテナントでビジネスオブジェクトが作成される場合、_TENANT_ID が区切られて格納される。存在しない場合は default を格納。not_null
_BKCCstringビジネスキー衝突防止コード。各プラットフォームの文字列が格納される。存在しない場合は default を格納。not_null
_STREAM_IDstringストリーム ID。データソースの識別子（アカウント ID やショップ ID など）が格納される。存在しない場合は default を格納。not_null
_RECSRCstringレコードソース。データの出典元を格納。 存在しない場合は default を格納。not_null
_LOAD_TSdatetimeロード日時。ビジネスオブジェクトを DWH にロードした日時。not_null
_TRANSACTION_TSdatetime観測日時。ビジネスオブジェクトがデータソースで観測された日時。

Raw DWH の具体例​

note

はぐくみプラスとフロムココロ、tellas の Amazon の注文データの場合

Business DWH​

Business DWH は、対になる Raw DWH にソフトビジネスルールを適用し、分析の軸になる様々な集計列を格納しています。Raw DWH とは、 _HASHKEY だけで結合することが出来ます。

  • テーブルの命名規則: BDW_[Bkcc]_[Table]
  • データ構造: RDB （※第三正規系ではない）

メタ属性​

Business DWH に存在するメタ属性は、以下の通りです。

カラム名データ型説明テスト
_HASHKEYstringサロゲートキー。

Business DWH の具体例​

note

Amazon の注文データの場合

Reference Table​

Reference Table （マスタテーブル）は、ビジネス活動の基盤となる組織全体で共有される重要なデータを格納しています。製品や取引先、従業員などの情報を保存しています。Business DWH と同様にクエリを支援します。

トランザクションデータ + ソフトビジネスルールが Business DWH で、マスタデータ + ソフトビジネスルールが Reference Table になります。

  • テーブルの命名規則: Ref_[Table]
  • データ構造: RDB （※第三正規系ではない）

メタ属性​

Reference Table に存在するメタ属性は、以下の通りです。テーブルによってカラムがあったりなかったりします。

カラム名データ型説明テスト
_HASHKEYstringサロゲートキー。not_null、unique
_TENANT_IDstringテナント ID。マルチテナントを解除するときに使用する。商品系のリファレンステーブルのみ存在。not_null
_BKCCstringビジネスキー衝突防止コード。各プラットフォームの文字列が格納される。存在しない場合は default を格納。not_null
_STREAM_IDstringストリーム ID。データソースの識別子（アカウント ID やショップ ID など）が格納される。存在しない場合は default を格納。not_null
_RECSRCstringレコードソース。データの出典元を格納。 存在しない場合は default を格納。not_null

Mart Layer​

ここでは、DWH Layer で一元管理され整理されたデータを、利用の目的（データ分析やレポート作成、リバース ETL など）に応じて、データを再加工して提供します。

Mart Layer は、データの利用目的に応じて、OBT（One Big Table, 大福帳テーブル）やディメンショナルモデル（スタースキーマ）などのテーブルが存在します。

  • テーブルの命名規則: [TableType]_[MultiBKCC]_[MultiTenantID]_[Table]
    • TableType: OBT, StarFct, StarDim, Doc
  • データ構造: OBT 、 Star Schema
クラスごとの CRUD（2024 年 1 月以降適用予定）createreadupdatedelete
BeginnerFALSETRUEFALSEFALSE
AssociateFALSETRUEFALSEFALSE
Advanced / Professional / MasterFALSETRUEFALSEFALSE
グロースハックチームTRUETRUETRUETRUE