持続可能なデータ分析基盤について考えた話
本記事は、 Showcase Gig Advent Calendar 2022 の6日目の記事です。
こんにちは。ShowcaseGigのわたひきです。
主職種はプロジェクトマネージャーですが、データエンジニア・データアナリストとしての活動も行っています。
今回は、ShowcaseGigのデータ分析基盤について書いてみようと思います。
1年前にkamyu氏が書いた記事の続編にあたる話題です。
これまでのデータ分析基盤
kamyu氏の記事にあるように、わたしがジョインした時点（ちょうど1年前ぐらい）で、ShowcaseGig社内ではLookerを活用できていました。
Lookerの接続データソースはBigQuery
Lookerで作成したダッシュボードが定期的にSlackに流れる状態
これはもう、データ分析基盤がしっかり出来上がっていそうな感がありますね！
何が課題？
ただ、よくよく見てみると、BigQueryはあくまで各種データソースを収集しておくデータレイク的な位置づけで、DWHとしての整備は不十分な状態でした。
Lookerは、データや値の定義を組織全体で統一化するデータガバナンスという、他のBIツール製品にはない強みを持ちます。
ただ、あくまでもBIツールなので、直接、生データを加工して、ダッシュボードを作成できるようにするためにはなかなかの力業を必要としている状況でした。
派生テーブルを多用する必要がある
dimension定義で、同じような置換処理をいろんなviewごとに書く必要がある
結果的に、プロダクトのデータスキーマの変更やビジネス上の指標定義の変更などに対する対応に時間がかかってしまう状況が生まれつつありました。対応できる人も限られてきます。
一方で、事業の拡大に伴って、データ分析基盤に求められる品質・スピード感は高まっていきます。
このままでは、どこかで崩壊してしまうのではないか？という危険を感じました。
ただのデータ分析基盤ではなく、持続可能なデータ分析基盤が必要です。
持続可能なデータ分析基盤を目指す
持続可能なデータ分析基盤について、『正しい意思決定につなげられるデータ分析が社内のすべてのメンバーによって迅速に実践できる基盤』、『管理が属人化せず、仕組化されて行われている基盤』というように定義します。
基盤管理の方法について、ドキュメントなどで引き継いでいくことも可能かもしれませんが、得てして、そういったドキュメントは更新がされにくく、陳腐化してしまうものです。このドキュメントの更新に追われて工数を奪われ、余計に基盤管理自体のスピード感が落ちる、なんていうことにもなりかねません。
基盤自体を眺めれば分かるような、シンプルなものを目指すと、保守性を上げることができそうです。
アーキテクチャはこんな感じ
まず、基本に立ち返って、DataLake/DWH/DataMartの3層構造を意識して、データ分析基盤アーキテクチャを考え、可視化してみることにしました。
このあたりの基本の構造については、『実践的データ基盤への処方箋』がとても参考になります。
結果として、活用しているツール自体はほぼそのままで、BigQueryをいくつかの層に切り分けて利用することにしました。
データレイク層：各データソースからのコピー。生データの保持。
DWH層：データクレンジング・ディメンショナルモデリング・指標集計など。
DataMart層：特定の利用者・用途向けの整理。
つまり、BigQuery内でELT (Extract, Load, Transform)のTをやったうえで、Lookerのデータソースにしてあげよう、というわけです。
データクレンジングなどをBigQueryの段階で終わらせておくことで、Lookerでは、データガバナンスや、分析・可視化に必要な細々した実装に集中できるようにすることが狙いです。
Dataformを使うことにした
BigQuery内でのデータの加工はスケジュールクエリなどでやる方法もありますが、dbtとかDataformのようなツールを使うと運用がラクです。
dbt Cloudでやろうかな～と思って試していたタイミングで、GCPでDataform（Google が2020年に買収したサービス）がちょうどプレビューになったので、以下のような理由から、Dataformを使うことにしました。
元々の機能としてはほぼ変わらない印象
先々のことを考えるとぜんぶGCP上にあったほうが管理上ラク
Dataform自体は無料（SQL実行時にBQ費用はかかる）
dbt Cloudだとアカウント単位で料金が発生する
2022年12月時点だと色々と機能の制約がある（依存関係グラフとかDataform単体でのスケジュール実行とか）のはデメリットではありますが、後から追加するという発表も既にされていますし、そこまで気にしないことにしました。
具体的なDataformの使い方
保守性・可読性を上げるため、ひとつひとつのSQLがシンプルで役割が明確なものになるようにします。
DWH層における処理を、処理内容ごとに明示的にレイヤ分けしました。
source層：汎用的な前処理層。クレンジング。
staging層：分析のベースになる層。source層テーブルのjoin。
reporting層：特定の分析・可視化のための層。
このあたりのモデリングは、絶対的な正解があるものではなく、組織の状況や求められているものによって、最適解が変わってしまいます。
今回は、dbtなどを活用されている先人の皆様の知見を大いに参考にさせて頂きながら、現時点の弊社の課題を解決できるモデリングとしてこの形を採用してみることにしました。
まとめ・今後やりたいこと
持続可能なデータ分析基盤の構想を組み立てることはできたのですが、実はまだまだ作業中の状態です。とはいえ、データの下処理でたくさんクエリを書かなくてもいい状態が見えてきて、データアナリスト寄りのわたしとしてはとってもハッピーです！
この調子で組み換えを進めつつ、さらにデータ活用の幅を広げられるよう、今後は以下のことにも力を入れていきたいです。
テスト周りの整備（品質向上のため）
LookerStudio（旧Googleデータポータル／GoogleDataStudio）でレポート作成できるようにする。よりビジュアライゼーションが豊富だし。
データカタログの構築（指標定義などの可視化・検索性の向上のため）
この記事が気に入ったらサポートをしてみませんか？