1. はじめに

Findyでデータエンジニアとして働いているひらき（hiracky16）です。この記事ではFindyで取り組んでいるデータ基盤について紹介します。

Findyでは2023年からデータエンジニアを採用し本格的にデータ基盤構築に着手しています。これまではBigQuery（Google Cloud）を中心としたデータ蓄積・利活用をしていました。今後もっとデータ分析、機械学習などのデータ利用を加速するためにデータマネジメントが不可欠だと考えており、データエンジニアを採用しています。まだ1人目のデータエンジニアがジョインしてから半年間くらいの取り組みですが、現時点のアーキテクチャや技術スタック、伸びしろや展望などを記します。

1. はじめに
2. これまでのデータ基盤の伸びしろ
3. 現状のデータ基盤アーキテクチャ
4. 今後やりたいこと
5. 終わりに

2. これまでのデータ基盤の伸びしろ

僕が入社する前のアーキテクチャがこんな感じです。

プロダクトのRDSからEmbulkを使って1日1回必要なデータをBigQueryへ転送していました。プロダクトのデータだけでなくGAイベントデータを蓄積していました。昨年からTransformのツールにdbtを導入しており定期的に実行されるクエリを徐々にdbtへ移行している状態でした。

データ利用で言うと定期的に見るべき数値はLooker Studioで可視化したり、GASからBigQueryへクエリ発行してスプレッドシートで表示しています。また別Google Cloudプロジェクトにある機械学習用のデータセットにコピーもされていました。

上記を踏まえて現場の課題感やアーキテクチャ図を見ての客観的な伸びしろをまとめてみました。

Embulkなどデータロード系のジョブが失敗した場合のリカバリに負荷がかかっている
dbtを使ったクエリが増えない
スプレッドシートとGASで実行しているクエリの正確性が担保できていない
データソースの変更に対する影響範囲が見積もれない（データリネージが追えない）
データ基盤と機械学習用の検証環境がないため新規開発やアップデートにハードルがある
機械学習のプロジェクトとデータ基盤のプロジェクトが別になっておりデータ鮮度が異なる

3. 現状のデータ基盤アーキテクチャ

3.1. 本番環境のIaC化と開発環境の準備

まず取り掛かったのが本番環境のIaC化でした。上記に示したアーキテクチャ図を書く前に本番環境の主要なリソースをTerraformにインポートしてコード管理できるようにしました。その過程で不要なリソースを整理でき、本当に必要なものだけを見極めることができます。おまけにコスト削減にも繋がります。一通りTerraformへの書き起こしが完了したら、あとは開発環境のGoogle Cloudプロジェクトを作りTerraformを適用するだけです。

データに関しては1日1回、Data Transferでデータセットごとコピーしています。

開発環境に本番環境相当のデータとGoogle Cloudリソースが揃ったので、後に紹介するDataformを使った定期実行クエリの開発を増やしています。これによって本番環境にて検証用テーブルができたり、間違えてテーブルを消してしまうなどの問題を減らせたと思います。

3.2. データロード系のツール刷新

データを取り込むツールとしてtroccoとDatastreamを採用しました。

troccoはもともと別チームで管理しているものに相乗りさせてもらう形で使っています。 MAツールや他のクラウドサービスといった様々なデータソースに対応可能なため重宝しています。またロードだけでなくReverse ETLにも役立っており、作ったデータマートを別サービスに読み込んで活用しています。

DatastreamはCDCのサービスでサーバレスなので運用に手間がかからない点でEmbulkの代わりに採用しました。一方でリアルタイムにソースが変わるため集計のたびに数値が変化するため、問題発生時の原因調査が困難になりました。現状運用上でカバーできていますが、再現性と説明の容易さを向上させるべく集計に使ったデータを別で持つべきか悩んでいるところです。

またスプレッドシート上で管理しているマスタデータにも対応すべくBigQueryの外部テーブルとして扱っています。

3.3dbtからDataformへの変更

データ変換のためのツールをdbtからDataformへ変更しました。

dbtはDataformに比べて開発が活発で、ライブラリが充実しているため採用しました。この前提でdbtにクエリや知識を集約させるべくBigQueryのユーザーを巻き込み利用を促していましたが、なかなかモデル（テーブル）の数が増えませんでした。

理由として2つのハードルがありました。 1つ目がBigQueryでクエリを記述後エディタを開き、dbt 用に書き足す一手間かかってしまうことが大きなハードルになっていること。 2つ目はdbt側の制約（主にモデル名の一意制約）やデータ基盤側の設計から定めたルールが気軽にコミットしづらい状況を作ってしまいました。

これらのハードルをクリアすべくDataformの利用を検討しました。 Dataformはブラウザで完結しBigQueryのメニューにあるため多少ツール間の移動コスト軽減されます。かつDataformにはモデル名の一意制約がなくBigQueryと同様にデータセット間で被らなければ同名のモデルがプロジェクトに複数存在しても問題ありません。導入した結果、モデル数はdbtプロジェクトに比べて3倍ほどできており、実際に使いやすいという声もあるので一定成功だったのかなと思っています。

Dataformからdbtへ乗り換えた話は見聞きしたことがありますが、dbtからDataformへのケースは見たことないので一定期間経ったらまた振り返りの記事を書こうと思います。

3.4. データを4層で管理

参考にしたのはdbtのベスプラの1つである「How we structure our dbt projects」です。 dbtをツールとしては不採用にしましたが、考え方は利用させてもらっています。 🙏

docs.getdbt.com

当初3層（lake/warehouse/mart）で作ろうとしていましたが、データソースに対して直接クエリしようとするとBigQuery上で不都合なことがありました。例えばDatastreamで転送してきた日時のデータがすべてDATETIME型になってしまい、TimeZone を考慮した計算ができませんでした。毎回TIMESTAMP型に変換する処理をwarehouse層に書かせるのも厳しいのでstaging層を設けて型変換などの簡単な変換をすることにしました。

4. 今後やりたいこと

4.1. 全体を統括するオーケストレーションツールの導入

現在、データ抽出と読み込みはtroccoやDatastreamで行われますが、Dataformによる変換はその読み込みが終わった頃を見計らって実行しています。もしtroccoによるデータロードが失敗した際にDataformによる変換が実行されてしまうので、データを閲覧する方が古いデータを見てしまう可能性があります。

また現状troccoやDataformそれぞれでエラー検知の仕組みを備えており、日常業務の監視に一定コストがかかっています。データの抽出から提供までの流れを効率的に管理・監視し、運用コストをかけずに行うためにもオーケストレーションツールの導入が今後必要です。

4.2. データ基盤の利用者拡大に向けたルールと権限

せっかく作ったのでもっと新しいデータ基盤を使ってもらいたいのですが、ルールがないとせっかくの設計が腐敗してしまいます。例えばGASから直接クエリを発行することはSQLの内容がGASに閉じてしまいメンテができなくなってしまうので新環境では禁止していきたいと考えています。 4層のアーキテクチャも開発上意識しなくてはならないルールなので、なぜ必要なのか理由とともに作るつもりです。

また、適切な権限や公開範囲の設定も必要です。どのチームがどの範囲のデータセットを扱うことができるか整理しないと予期せぬ変更をしてしまうなどの事故につながってしまいます。皆が安心して使えるデータ基盤にするためにも適切な権限設定やルール作りが急務だと考えています。