1年間のDataPlatformプロジェクトから見えてきた「DataWarehouseの作りかた」〜前編〜
この記事は eureka Advent Calendar 2019 21日目の記事です。軽井沢で書いています。
昨日は弊チームの先輩、山本による Gatringを使って負荷テストをしよう！ でした。
どうも、みなさんおはこんばんちは。元BI、現SREチームのsotaroです。
普段はデータ領域のエンジニアリング全般を主にやりつつ、PairsやPairsエンゲージのインフラも触ったりしています。
また、この1年は特に、今年1月より発足した「Data Platformプロジェクト(以降、DPプロジェクトと略す)」で開発の中心的なメンバーとして活動してきました。
今回は、その「DPプロジェクト」について、簡単に振り返ってみながら、
- 「データ基盤構築における学び」 (前編)
- 「1年のプロジェクトを通して見えてきたDWH構築の方法」 (後編)
について、ご紹介していきたいと思います。
DPプロジェクトのスタート地点は？
DPプロジェクトのスタート地点では、eureka/PairsのDataLake以降のデータ基盤はざっくり以下のような構成でした。
※ ここでDataLake以降に限定しているのは、今回はロギングや収集の話はスコープに含めないためです🙇♂️その辺りはまた別の機会でお話するかもしれません🙇♂️
簡単に説明をすると、分析に利用するデータをBigQueryに集約するところまではできているが、ローデータ以降の加工済みテーブル等は特になく、redashに登録するクエリやSageMakerのノートブック内で毎回ゼロから処理のロジックを記述している、という状況でした。(一部スニペットやUDFの利用はしていましたが…。)
DPプロジェクトは何がしたかったのか？
上図のような構成からスタートしたDPプロジェクトでしたが、
そもそもなぜ始めたのか？というと、大きな課題感として以下のようなものを感じていました。
- データアナリストがクエリ職人になってしまうことで、属人化したデータ加工のナレッジで仕事が振られ、本当に解くべき課題に向かう時間を失う
- 仕様変更への追従漏れやSQL記述ミスによって、意思決定の判断材料たるデータの質にバラツキが出る
上記のような問題について、BIチーム内だけでなく、SREやAI、PM、さらには経営陣までをも巻き込んだ議論が何度かあり、結果として
データ加工のナレッジを人ではなくシステムに落とし込み、再利用可能性を高めることや、チームのリソースを再配置し、分析組織全体の価値を向上させること
を目的に、DPプロジェクトがスタートしました。
…
また、より詳細なDPプロジェクトのWhyや発足期の動きについては、私のBI時代のボス Tamaki Tetsumoto がとてもわかりやすいスライドを世に公開しているので、ぜひこちらもご覧ください。
DPプロジェクト発足のモチベーションについては、私も1年前のアドベントカレンダーに書いていたりもします。
また、この記事に書いてあるように、弊社では現在もDataLake/DWH/DM間のデータ処理を管理するワークフローエンジンとしてCloud Composerを採用しています。
ですが、最近「俺たちは本当にCloud Composerを必要としているのか？俺たちに本当に必要なのは…(続く)」みたいな気持ちになってきているので、「Cloud Composer全然分からない」記事を近日公開予定です。。😌
さて、気を取り直して、ここからはDPプロジェクトで実際にやってきたことと、そこからの学びを振り返りたいと思います。
1年間に渡るプロジェクトの全てを説明しても大変なので、印象的な「やってよかった」「やらなくてよかった」を紹介する形式でいきたいと思います。
DPプロジェクトのやってよかった / やらなくてよかった
【やってよかった】はじめはとにかく「必要そうなものを作って見せる」のサイクルを回す
DPプロジェクトは、まずはじめの3ヶ月をスクラム形式で進めていきました。
チームの構成員は、PO(BIチームのHead)、SRE/BIの私、そしてアナリスト2名とPM1名の計5名でした。
この最初の3ヶ月をスクラムで進めたことは成功だったと思っています。
「プラットフォーム」と名のつくものは、油断しているとすぐにプロダクト側のニーズを履き違えたものを作ってしまいかねないものだと私は考えています。
そこで、DPプロジェクトチームでは、スクラムのスタイルで、
- 各スプリントの始めにステークホルダーやビジネスエキスパートとディスカッション
- 今求められているアウトプットを拾い上げる
- チーム内で優先度や「どう作るか？」を吟味する
- データセットを作成する
- Tableau等のビジュアライザで可視化し、フィードバックをもらう
という動きを繰り返していきました。
このサイクルを回すことでData Platformをプロダクトのニーズから遠ざけずに、スピード感を持って作っていくことができたと思っています。
また、この段階では、DataLake->DWH->DataMartという加工ロジック上の依存関係の流れやデータセット自体の汎用性を考えすぎないことが重要です。これは反省でもあります。
作る側としては、そういうものをどうしても作りたくなるものですが、
小さく、そして確かに価値のあるものを素早く作り、私たちが作ろうとしているData Platformの存在価値を見極めながら進めていくことを重要視しました。
ただ、ステークホルダーやビジネスエキスパートと会話することで、必ずしも作るべきものが見えてくるわけではありません。往々にして、顧客は本当に求めているものを言語化していないことがあるので、後述する実際の利用データと合わせて、優先度付け等をおこなっていくのが良いでしょう。
【やらなくてよかった】はじめから無理してDWHを作ろうとしなくていい
DPプロジェクトでは、スタート当初、DataMart構築をしつつDWHを作るための議論を何度も重ねていました。
その過程で、モデリング手法について学んだり、実際に設計をしパイプラインを作るところまでやったりもしました。
しかし、当初の私たちの想定からすると奇妙なことが起きました。
DWHは基本的にDataMartと比べて、汎用性が高くなるものだと信じ、構築していたのですが、作ったDWHはあまり使われておらず、むしろ特定のDataMart層のテーブルがいろいろなところでジョインされたり、使い回されたりしていました。
なぜこんなことが起きたのか。それはDWH構築を「頭でっかち」に進めてしまったことが問題だったと私は考えています。
「頭でっかち」とは、ディメンショナルモデリング、スタースキーマ、ファクト/ディメンションという言葉に踊らされ、これらを作ることにフォーカスしてしまっていたということです。
モデリングは方法論であり、上手く取り入れることで大きな効果を得られますが、その意味や効果もよくわからないまま、定義だけを受け入れて、ディメンションとファクトを分離したり、スタースキーマを作ろうとしていたことで、本来のニーズを取りこぼしたものができあがっていたのです。
このエピソードから、私たちは基本的に「ゼロの状態からDWHを作ろうとする」ことを避け、DataMartや未だ使い回されているredashクエリからDWHを抽出しようとする動き方をはじめました。
この方法についての詳細は、時間の都合上、後日、追記していきたいと思います。
【やってよかった】BigQueryやBIツールの利用データをヒントにする
DPでは、BigQueryを利用しているとデフォルトでStackdriverに送られているAuditLog(監査ログだが、単純に利用ログとしても使える)を、BigQueryの専用データセットにsinkすることで、以下のようなデータを集計し、次に作るDWHやDataMartを決める上でのヒントとしています。
- よくジョインされているテーブルの組み合わせ
- よくクエリされているテーブルのランキング
また、Audit Log以外にも、弊社エウレカでは、分析向けのビジュアライザとしてTableauを利用しているので、Tableauのデータソースの利用ランキングやデータソース同士のジョイン情報なども、ヒントとして利用しています。
【やってよかった】定例の会議体で設計を議論したりレビューする
DPプロジェクトは最初の3ヶ月を終えると、スクラムチームは解散となり、BIチームのHeadとコア開発メンバーの私だけで開発を進める日々がその後半年ほど続きました。
ただ、2人で会社のデータ基盤を作り、メンテし続けることに限界を感じたので、私たちは、社内でデータ基盤に興味がありそうな人を誘い入れ、DWH/DataMartの設計を議論したり、DWH構築のナレッジをシェアする定例の会議体を設けることにしました。
これもまた、成功だったと思っています。
ディメンショナルモデリングなどのDWH構築の方法論のシェアをしたり、上述の分析向けデータセットの利用データを見ながら議論をすることで、参加メンバーのData Platformに関するナレッジを向上させつつ、設計をブラッシュアップしていくことができます。
【やってよかった】価値が浸透してきたら足回りを整える
そういえば、こちらはData Platformという文脈に限らない話ですが、
- CI/CDによるデリバリー速度の担保
- 可用性、信頼性を高めるためのログモニタリング
- GKEのリソース配置の調整
など、SREとしての足回りを整える取り組みもやっておいてよかったなと思っています。
プロジェクト後半にもなると、元々2人しか開発メンバーがいなかったDPプロジェクトにも有志で参加してくれるメンバーが増えてきたので、僕自身がSQLを書いたりするよりも、SREとしての動きにシフトしていくことにしました。
そうすることで、チームのアウトプット最大化とその価値を台無しにしないための安定性に貢献できたかなと思います。
プロジェクトやPlatform自体の成熟度に合わせて、足回りを整える動きも担っていけるメンバーが関わっていけると良さげかなーという学びって感じです。
関連するAirflowやBigQueryについてのTipsについては、同僚の Kurimura Takahisaがまとめたこちらの記事もぜひ読んでみてください。
さて、DPプロジェクトを通して私たちが得た学びを振り返ってきました。やっと、本題「Data Warehouseの作りかた」についてのお話ができるところまで来ることができましたが、時間の都合上、続きは後編となります…🙇♂️
アドベントカレンダーとしては、一旦こちらで私の記事は終わりとなります。
いかがだったでしょうか？この記事では、eurekaでの今年1年のData Platformプロジェクトを振り返りながら、データ基盤構築に関する学びを共有させていただきました。
明日は、今年夏にローンチした新サービス Pairsエンゲージのバックエンド開発を担当するイギリス紳士Jimによる 「Pairsエンゲージの新規開発に採用したサーバーサイドアーキテクチャ🤵👰」です！お楽しみに！
良いお年を:)
