はじめに
こんにちは。Analyticsチームの上田です。
当チームは、2024年3月にチームの概要を紹介するnote記事「データ分析の宝庫を前にして〜Analyticsチーム1年目の取り組み～」を公開しました。その記事ではチーム発足後間もないデータ基盤の構成を紹介しました。それが図1です。
当時は連携しているデータソースがZendeskのみで、極めてシンプルな構成でした。 その後、事業や社内のニーズに応える形で様々なデータソースが増えていき、当時とは大きく異なる構成となりました。 カジュアル面談等では最新の構成をご紹介しているのですが、Web上には公開していませんでしたので、この機会に公開したいと思います！
データ基盤の構成 - 2024年12月時点
図2に最新の構成を示しました。矢印の方向にデータが流れているので、左から右に読み進めると理解しやすいかと思います。
構成の背景
まず、そもそもデータ基盤の構築に至った主な背景は以下です。
- Park DirectのDBだけでなく、ZendeskやHubspotといった周辺ツールのデータを組み合わせた分析のニーズが高まったこと
- Park Directに関するヒストリカルな分析のニーズが高まったこと(Aurora上のデータの多くはその瞬間の状態のみ保持しており、ヒストリカルに保持されていない)
ETL: TROCCO
ETLツールには、以下のような背景でTROCCOを利用しています。
- Analyticsチームは人員が少ない(当時2名、現在4名)のに加え、分析からデータインフラ整備まで広く担当するため、ETLに割ける人的リソースが少ない
- ETLに割ける人的リソースが発生したら、むしろデータ分析や分析を加速する環境整備(データマートやViewの整備など)にリソースを割きたい
TROCCOにはカラムの変更検知機能・テーブルの増減検知機能・転送Job成否のSlack通知機能があり、これらによって少人数でも無理なくデータ基盤を運用することができています。また、TROCCO起因の転送Jobの失敗も一度も発生しておらず、信頼性が高いです。 2024年11月には、図2中央下部に示した「データ基盤→Park DirectのDB」のリバースETLを開始したのですが、こちらもTROCCOによって比較的容易に実現することができました。
ただし、一部のETLではTROCCOを利用していません。Google Analytics・Search ConsoleはBigQueryリンクという機能で直接BigQueryにデータを転送できるため、TROCCOを利用していません。また、月次KPI集計に必要な、データベースの正確な時刻の断面(例えば月初1日9時時点など)の転送には、BigQuery Strage Transfer Serviceを利用しています。これは、TROCCOがその用途に適していないためです。
データマート: BigQuery(Scheduled Query)
データマートの作成はBigQueryのScheduled Queryで実施しています。これには、以下のような背景・意図があります。
- 現時点ではデータマートの構成がシンプルなため、Scheduled Queryで事足りている
- この部分にTROCCOを利用しないことで、TROCCOのクレジットを節約する
DWH: BigQuery
DWHにはBigQueryを利用しています。主な背景は以下です。
- BigQueryの利用経験のあるメンバーが多かったこと
- 金額・運用コスト面で当時の比較対象より優れていたこと
連携するデータソースが増えた現在も、BigQueryは非常に低い金額コストで安定的に運用できています。WebコンソールのUI以外に、これといった不満はありません。
BIツール: Redash
BIツールにはRedashを利用しています。主な背景は以下です。
- データ基盤の導入前から導入されていたBIツールであり、利用中のクエリやダッシュボードが多数存在し、安定的に稼働していたため、廃止する動機が特になかった
- BigQueryとの連携が容易かつ、スキャンデータ量を制限できるため、Redashを介せば安全にBigQueryを利用できる
- 一部の業務ではRedashのアラートを業務開始のトリガーとして利用しており、脱Redashする場合は代替ツールを探す必要があるが、当時は手軽なツールが見当たらなかった
また、ビジネスチームはRedashの抽出結果をスプレッドシート上で加工・共有することが多いため、図2右上に示した「Redash取り込みツール」という独自ツール(SREチーム提供)を利用し、スプレッドシートに簡単に書き出せるようにしています。
現在の課題と今後の改善予定
データソースレイヤーの主な課題
データソースレイヤーの課題は、連携するデータソースの拡充です。特にTROCCOがコネクタを提供していないデータソースとの連携のニーズが高まっているため、TROCCOのHTTP(S)コネクタを利用して対応したいと考えています。
データ基盤レイヤーの主な課題
- 脱BigQuery Scheduled Query
- 現行の仕組みが複雑化する前に、TROCCOのワークフロー機能やDataformといった柔軟性の高い仕組みに移行する
- ヒストリカルデータ蓄積の効率化
- TROCCOの転送モード「UPSERT(MERGE)」を活用する
- データマート/Viewの充実化
- KPIが事前計算されたデータマート/Viewを整備し、集計コスト・ミスを減らす
- データ転送の頻度向上
- リアルタイム性が求められるデータ抽出・分析に対応できるようにする
データ活用レイヤーの主な課題
- 脱・Redash一強体制
- BigQueryデータキャンバス・Gemini in BigQuery・Gemini in Looker(Studio)など、プロンプトベースでデータにアクセスできるUIを提供し、SQLを書けなくても基本的なデータ抽出・分析ができるようにする
- 脱・Redash取り込みツール
- データ基盤でできたことにより、スプレッドシートはBigQueryに直接接続できるのでそちら変更する
データ分析面の課題にも触れたいところですが、それはまた別の記事にしたいと思います！
おわりに
本記事では、2024年12月現在のPark Directのデータ基盤の構成・背景・課題をご紹介しました。Analyticsチームは現在も絶賛採用中です。もしご興味をもっていただけた方は、お気軽にカジュアル面談をお申し込みください！
次回のAnalyticsチーム発信の記事では、「データ基盤→Park DirectのDB」のリバースETLの詳細をご紹介したいと考えています。
ここまで読んでくださり、ありがとうございました。 アドベントカレンダーはまだまだ続きますので、よろしくお願いします！🎄
