GitHub リポジトリに貯めていく分析 SQL 運用

リポジトリにためていく分析SQL運用

Da Vinci Studio 分析チームの濱口です。
分析チームでは各々が書いた SQL をドキュメントにまとめて GitHub リポジトリに貯めて共有しています。この試みを始めてから1年ほどたったので、運用してみて感じたことや気づいたことについて紹介しようと思います。

背景

SQL を GitHub リポジトリに貯め始めたのは、以下のような問題意識からでした。

ちゃんとした枠組みがなく、タスク管理ツール上で雑に行われていたり、そもそもレビューが行われていなかったりという状態でした。このような状態が続いてしまうと、SQL のミスやデータの誤りに繋がってしまい、データの信頼性が損なわれてしまいます。

様々なところでレビューされていたりされていなかったりで、それぞれの書いた SQL がどこにあるのかがわかりづらい状態でした。他の人が書いた SQL を参考にしたり再利用したりするのにも一苦労で、とても非効率です。

貯めるまでの流れですが、特に特別なことはなく

という手順になります。

マークダウン形式のファイルに作成した SQL の概要、実際に書いた SQL などを記載したプルリクエストを作成します。ディスクリプションには、データ抽出の目的と SQL を実行して抽出したデータを記載し、データの数値についても確認できるようにしています。

チームメンバーからレビューをもらい、SQL やデータに誤りがないかチェックします。
ディスクリプションにレビューのチェック項目を設けており、その項目に沿ってレビューを行うことで漏れが出ないように対策しています。最低でも1人から Approve もらって問題なさそうであればマージします。

レビューのチェック項目

といったように、当初抱えていた問題は解消できました。
しかし、運用する上でまたいくつか別の課題が出てきました。

最初のうちは良かったのですが、ファイルがどんどん増えていくうちに参考にしたいファイルを見つけるのが困難になってきました。
解決策として、全てのファイルを同じ 1 つのフォルダに貯めていたのを、外部と内部の案件別で分割した上で、さらにデータマートごとにクエリを分けるようにしました。

データの抽出内容によってはかなり長い SQL になることもあり、とにかくレビューが大変でした。レビューが大変だと後回しにされがちで、レビューが滞るという問題が出てきました。
この問題に関しては

などを行っており、現在も改善を続けています。上記２つの改善についてはいくつか別のブログにもまとめています。

運用していて出てきた新たな課題についても、さらに改善していきたいと思います。

Da Vinci Studio では一緒に働ける仲間を絶賛大募集中です！募集職種と詳細に関しては、以下のリンクからそれぞれ確認できます。