私のチームでは数千行におよぶ分析用SQLをリファクタリングして、保守性と生産性を両立する分析パイプラインに生まれ変わらせることができました。
この記事ではリファクタリングを通して確立した、分析用SQLを構造化するための4原則を紹介します。4原則を意識しながらSQLを書くことで、高凝集・疎結合な分析パイプラインを作ることができます。
- SQLを関数とみなす
- テーブルの意味を明確にする
- カラムからフラグを排除する
- レコードの単位を意識する
リファクタリング以前のアドホック集計は数千行にもおよぶ分析用SQLのコードをコピペして、一部を書き換えてからSQLを再実行するという流れでした。
このやり方だと、変更範囲の特定や変更の正しさの確認などにとてつもない時間と労力が取られていました。
そのため、1カ月に1人のアナリストがこなすことのできるアドホック集計は多くて2〜4件程度でした。
そして、アドホック集計の依頼に対して少なくとも5営業日以上の納期をもらっていました。
しかしリファクタリングの実施後は一人で5件〜7件程度のアドホック依頼をこなすこともできるようになりました。
基本的に部品化されたSQLの差し替えで対応可能なため、コード追加による機能変更で、変更による影響の範囲も限られているためレビューの工数も大幅に削減することができました。
その結果、今までレビューも含めると5営業日以上必要だったアドホックの分析依頼が、最短数時間で完了できるようになりました。
今回紹介した4原則はあくまで分析用SQLという最終的なユースケースがはっきりした集計分析用の分析パイプラインを構築する際のものです。
DWHやデータマートの構築など汎用的なデータソースを作成するためのデータパイプラインの構築には当てはまらない部分もあることはご注意ください。