Analystのスループットを継続的に最大化させるデータ基盤の運用思想
この記事は「Eureka Advent Calendar 2020」の16日目の記事です。
こんにちは、Head of BIの鉄本です。
15日目は Jun Ernesto Okumuraによるエウレカのデータ組織運営の1年間でした。今日はこの話に関連して、もう少し具体的にEureka BIチームのAnalystの分析フローを支える分析環境について書きます。主に運用の思想や仕組みづくりの紹介になります。
想定読者
- Data Lake・Data Ware House・Data Martなどのデータ基盤周辺知識がある
- Analystを活かすデータ基盤の開発運用に興味がある
前置き
BIチームの紹介やAnalystの業務フローに関する前置きが少し長くなりますがお付き合いくださいませ。
お急ぎの方は、本題まで飛ばしてください。
チームのミッションとデータ基盤
BIチームは、「価値のある意思決定」と「意思決定の効率化」を推進することをミッションにおいているチームです。
ミッション実現に向けて、最近は以下の2軸を強化したいと考えています。
- Analystが「価値のある意思決定」を創出するためのプロセスの構築
- データ基盤（Data Platform）への知見の集約による「意思決定の効率化」
これは私自身の経験ですが、データ周辺はいくらでも手が伸ばせてしまうため、分析で感じる不便からデータの整備に飛び回ったり、データの整形に時間を取られたり、レポーティングに集中できない状態に陥ることがしばしばあります。
そこで、2年ほど前からData Platformを構築・運用しています。
この話は今日は割愛しますが、興味がある方は過去の登壇資料もぜひご覧ください。
改めてミッションの実現に向け、分析を強化しつつも、それを下支えする役割も定義していくことが重要だと考え、役割と責務を明示的に分けるようにしました。
- Analyst：「価値のある意思決定」の推進に責務を持ち、レポーティング活動の一部としてDWH/DMの設計構築も行う
- Data Engineer：Analystのオペレーションの仕組み化・DWH/DMの開発効率化を通した「意思決定の効率化」に責務を持つ
メンバーには、どの役割としての活躍を期待しているのかを期待値として提示しています。中には両方の役割をこなすメンバーもいますが、アサインに対して期待される動きはどの役割なのかを明確にするようにしています。
Analystの動きを支えるData Engineerの役割
Analystがどのように「価値のある意思決定」に貢献していくのかの話の前に、弊社のプロダクト開発の流れを簡単にご紹介します。
ダブルダイヤモンドというフレームワークをご存知でしょうか？
ここでは詳しく説明しませんが、簡単にいうと「発散と収束を繰り返し、課題の特定と解決の精度を高めるためのデザインプロセス」です。
前半の発散（探索）と収束（定義）で課題を特定し、後半の発散（展開）と収束（提供）で解決方法を見つけます。
ref. https://uxdaystokyo.com/articles/glossary/doublediamond/
ダブルダイヤモンドはあくまでも精度を高く施策を実施するためのプロセスなので、それが正しかったかどうかは世に出してみないとわかりません。実際の現場では、提供してから評価し、PDCAを回してブラッシュアップしていくことになります。
ここから先はこれから実現しようとしているプロセスになりますが、AnalystはPdMと伴走して仮説検証から指標の設計と効果測定を行うため、このプロダクト開発のプロセスに合わせて、Analystの動き方を当てはめたい考えています。
発散から収束までの流れを、それぞれのフェーズに適したレポーティングで推進することがAnalystの仕事になります。
- 探索：仮説に対し、探索的に分析をするフェーズです。様々な切り口からインサイトを与えるようなレポーティングを行います
- 定義：課題を特定し、その解消を評価するためのKPIを設計します
- 展開：結果を計測できるレポーティングを通してPDCAを回し、KPIを向上させます
- 提供：最終的なビジネスインパクトや、ユーザー体験の評価を報告し、会社の知見として残します
この一連の流れを繰り返すなかで、効率化しつつもその価値の増大させていくために、データ基盤が必要と考えています。
使い込むことで扱えるデータや知見が溜まっていくような、エコシステムとしてのデータ基盤の存在を目指しています。
これらのお話は、YouTubeに登壇動画が上がっているのでもしお時間があればご覧ください。
本題
Eurekaのデータ基盤
前置きが長くなりましたが、こういったAnalystの活動を技術でどうやって実現しているのかが今回の本題です。
ポイントは、いかにシームレスに、業務のフローに組み込めるかです。
そのため、「簡単にできるが、秩序も担保できる」ことを重視して構築・運用をしています。
まず、現在のEurekaの分析環境のアーキテクチャは下記です。
分析用のDBはBigQueryを、ETLはワークフローエンジンにApache Airflowを採用しています。
仮説検証でのインサイトを出す場面では、探索分析が必要になることが多いです。既存の整形済みデータやレポートが使えれば最短ですし、その割合を増やしていくことを理想としています。
しかし、現実には適当なDWH・DMや過去のレポートが存在しないケースは多々あり、DLからアドホックに集計することになります。
そこで培われた知見をデータ基盤に貯めていくために、 Analystにとって使いやすいETLを目指して日々整備しています。
新たにDWH・DMを増やす上で、Analystに必要なStepは大きく3つです。業務フローのTipsを交えてご紹介します。
Step1. SQLとschemaの用意
これらは業務の中で作成済みのはずなので、必要な作業はコード管理されているファイルに落とし込むのみです。
適当なディレクトリにSQLとschema（json）を保存する作業になります。
Tips. schemaファイルの生成手順
唯一、schemaは作成が面倒かもしれません。
弊社ではAnalyst毎に検証用のBigQueryのdatasetを提供しており、Cloud Shellを使ったschema作成手順を推奨しています。
自分の検証用のdatasetに対象のテーブルを一時保存し、bqコマンドでJSON形式のschemaファイルを取得する流れです。
Cloud ShellをBigQeuryのGUIから起動し、下記コマンドを実行することで、簡単に取得できます。
$ bq show --schema --format=prettyjson [dataset_name].[table_name] > [file_name（hoge.jsonなど仮でOK）]
$ cloudshell dl [file_name]私が実行する場合、自分のテスト用datasetでサンプルテーブルを作り、データの検算をしたらSQLとschemaを保存するようにしています。
Step2. dagの用意
新たなワークフローを追加します。弊社はairflowを採用しているため、pythonでdagファイルというものを用意する必要があります。
詳しいdagファイルの書き方は下記、Sotaro Tanakaの記事を参考にしてください。
※2年前の記事なので、弊社のアーキテクチャなどは現在と異なります。あくまでAirflow導入のチュートリアルとしてお楽しみください。
弊社ではdag_idをfilepathから自動で生成されるようにしていたり、テーブルの再作成を行う関数が用意してあるため、基本的には1部のコードブロックをCOPYし、filepathやテーブル名を差し替えるだけで動くようになっています。まだまだ、より簡単にdagの追加を可能にしていく予定です。
下記はdagファイルの一部抜粋です。
# テーブル再作成用の関数の読み込み
...
from dependencies.subdag.recreate_table_flow_subdag import recreate_table_flow_subdag# 実行環境に合わせた定数の取得
PROJECT_ID = Variable.get("gcp_project")
DM_DATASET_ID = Variable.get("dm_dataset")
...with models.DAG(
# dag_idはfilepathから一意に生成
dag_id=generate_dag_id(__file__),
...
) as dag: # dagの追加は下記の1ブロックをCOPYし、table名を差し替えるのみ
recreate_table_flow_subdag(
root_dag=dag,
project_id=PROJECT_ID,
dataset_id=DM_DATASET_ID,
# 対象テーブル名を指定
table_name="[table_name]",
sql_file_path="dm/PATH/TO/[table_name].sql",
schema_file_path="dm/PATH/TO/[table_name].json",
...
)
ここでは具体的な実装については触れませんが、ご興味のある方はこの機構を整備してくれた Kurimura Takahisaの記事やSlideを参照ください。
この場を借りて、彼には感謝を伝えたいと思います。
現在は簡単なフローがほとんどですが、Data Engineerと相談、設計をしながら今後の利用拡大を見据えてさらに改修していきたいと考えています。
依存関係を回避・スムーズにできる仕組みの導入や、より使いやすいようにリファクタリングを継続していく予定です。
Step3. merge条件を満たす
masterへのmergeは下記を必須としています。
- CI（Github Actionsを採用）のTestが全て通ること
- 1人以上からのApprove
新たなdagを追加する際は、最低限の対象として下記3つのテストが通ることを確認しています。
- pythonのコーディングルールの準拠
- SQLのDry Runの成功
- dagのDry Runの成功
schemaとSQLの一致などこれから拡張していきたいものもまだまだあり、発展途上の部分ではありますが、これらのテストのおかげで治安を維持でています。
コーディングルールに関しては、pre-commitでblackというコードフォーマッターを動かすようにしているので、ルールを意識せずに書くことができます。Analystに少しでも分析に集中してもらうための配慮です。
これがうまく動かない場合は、環境構築で詰まっているので他のメンバーがサポートに入ります。
1名以上のApproveを必須としているのは、属人化を防ぐためと、秩序を保つためです。
特にSchema情報は客観的に見てデータの定義がわかり、他人にも使えるデータかどうか、必ず客観的な意見をもらうことが大事だと考えています。
以上の3stepでDWH・DMがデータ基盤に新たに追加できるようになっています。
おまけ
これまでに紹介してきたワークフローの検証を楽にするために、3つ導入している環境があります。さらっと紹介して終わりたいと思います。
1. stage環境
検証用のstageブランチが用意されており、検証したいbranchをmerge & pushすることで、stage環境に自動deployされます。stage用のDWH・DMも作成されるため、期待通り動くかどうかの確認やプロトタイプの検証に使います。
1日1回、masterの内容でリセットされるため、基本的にはどんな実装を投下しても翌日には直ります。安心して何度でも検証を回せますね。
2. local環境
とはいえ、stageにmergeしてdeployして…という流れでも待てないせっかちな方もいると思います。私です。
共同開発になるので、チャレンジングな実装をするときには他の開発者の検証への影響も気になりますよね。
そんな場合のために、Docker環境が用意されています。自分だけの環境なので、なんの気概もなく検証をぶん回せますね。
3. command実行環境
新たなワークフローを追加した際に、過去のデータを一気に作りたいという場面がよくあると思います。
airflowでは、コマンドラインから実行できる仕組みが用意されています。
弊社では実行したいコマンドを記載したfileを作成し、deployすることで実行されるようになっています。
こちらもReviewとApproveが必要なので、秩序を保ちながら運用ができます。
さらっと書いていますが、公式ドキュメントだけではコマンドの仕様や挙動の理解に苦労することが多々あるので、一緒に試行錯誤してくれる方、大大大歓迎です。まさに今、苦戦しているところです。
何度か紹介してきましたが、改めて、これらの環境を整備してくれた Sotaro Tanaka, Kurimura Takahisaには日々頭が上がりません。
最後に
本日は一部を紹介しましたが、我々は価値のある意思決定の推進とその効率化のために日々邁進中です。
このような仕組みづくりや活動を共にできるSenior Analyst、Data Engineerを積極採用中です。興味を持っていただけた方は気軽にお声がけください。
Senior Analystはこちら
Data Engineerはこちら
