はじめに
こんにちは〜。 クラシルでデータエンジニアをしておりますharry(@gappy50)です。
これまで、クラシルではデータ基盤からのデータをアプリケーションや推薦システムへ活用するためにDWHにSnowflakeを導入し、様々な活用をしてきました。
その一方で、データ「分析」基盤としての利用を推し進めていくために現在はdbtでのデータモデリングを中心として、一貫性のあるデータ分析が行えるような土台作りに注力しています。
今回は、Snowflakeのコスト監視やdbtのモデリングのコストの監視・可視化ができるdbt-snowflake-monitoringについて簡単にご紹介したいと思います。
現在のクラシルの分析における課題
クラシルでは高速で開発・検証をするためにSQLをみんなで書ける文化が根付いている反面、BIツールであるRedashに様々なKPIや指標が散在するためデータカオスが生まれておりました。 そのため2021年からdbtを導入し、必要なデータマートやマスタ関連のデータ整備をしていました。
それから2年後、高速で開発・検証を進めた結果、dbtでもデータカオスが生まれはじめそうな気配が漂ってきました！（なんてこった
分析で使われているのかわからないテーブル、定期実行しているクエリの実行コストがかさんできた、dbtのbuildに時間がかかりはじめているけど消していいのか、など…
データエンジニアでよくある課題だと思うのですが、テーブルやパイプラインの棚卸はコスト死を防ぐためには死活問題です。 日々の運用クエリはここ1〜2年間でどうにか最低限のお掃除はできるものはあるものの、不要になったリソースを特定し利用者と合意を取るためにはそれなりの時間と根性と思い切りが必要です。
また、そのような監視は分析ワークロードだけでなくdbtから実行されるELTワークロードに対しての監視までを行う必要があるため、 監視対象はdbtのモデルが増えれば増えるほどELTと分析の両側面からの棚卸が必要になります。
dbt-snowflake-monitoringの導入
そのような複雑なワークロードの監視を簡単にしてくれる最高のツール、あります。 Snowflakeのコスト監視SaaSを提供しているSELECT社のOSSであるdbt-snowflake-monitoringです。
SaaS版のSELECTはWeb上からLooker統合やSlackへの通知機能等もあるのでかなり魅力的ですね。
OSS版のdbt-snowflake-monitoringはdbtとSnowflakeに特化しているものの、我々のワークロードのほぼほぼを監視できるので導入をするだけで即時メリットがあります。
導入は以下のQuick Startの手順に従うだけなのでそれほど難しくないです。
導入が完了したら dbt build --select dbt_snowflake_monitoring を実行するとdbt-snowflake-monitoringのモデルがデプロイされます。dbt Cloudの場合はdbt jobに定義をしておいて定期的に更新できるようにしておくのもよいでしょう。
デプロイされたモデルは以下のような使用方法ができます！
毎月の請求額をサービスごとに算出したり
毎月のウェアハウスごとのコストを可視化できるのはもちろんのこと
直近クエリが実行されていないテーブルをテーブルサイズ順に確認できるので不要になってるテーブルの棚卸もコストパフォーマンスがよいものから棚卸できますし
直近コストがかかっているクエリの特定もすぐにできます。
さらには、これが強いのですがdbtのモデルごとのコストの監視もできます。
query_base_table_access のクエリ実行回数とあわせて監視すると不要なデータモデリングのお掃除も楽になりそうですね！
さいごに
いかがでしたか？ dbtとSnowflakeを利用しているのであればまず入れてみるのはいかがでしょうか？
我々クラシルのデータチームは、今年度からは分析の利便性を向上させるためにパワーが出せる状態になっているので、これまでの負債を解消しながら現在はこのようなコスト監視や、立ち向かえていなかったデータモデリングやデータカタログの充足化、Lookerの利活用など新たな分析基盤のための土台作りに注力をしてます。 全員がSSOTのデータやロジックで意思決定をしはじめて、正しい意味で高速で開発・検証ができる状態を目指して日々奮闘していきたいと思います。yatteiki 🦵 :takeshi_arigato:
