データ基盤の品質維持にdbt Coreをスモールスタートで導入
レビュー投稿日の情報になります
株式会社JMDC / ytakano
メンバー / データエンジニア / 従業員規模: 301名〜500名 / エンジニア組織: 51名〜100名
最終更新日投稿日
ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|
10名以下 | 2025年1月 | B to B |
ツールの利用規模 | 10名以下 |
---|---|
ツールの利用開始時期 | 2025年1月 |
事業形態 | B to B |
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
オンプレミスの電子カルテデータ基盤のAmazon Redshift Servelessへの移行のプロジェクトも終盤となり、データ基盤を運用するフェーズも考えるタイミングになっていました。 運用する上で重要な事の1つとしてデータ品質の維持があります。製薬企業様、医療機器メーカー様を中心に幅広くご活用いただいているデータであるため、最重要と言っても良いものです。 そのデータ品質の維持をコストをかけず、短期間で実現できる方法はないかと考え、完成済データ基盤に対してもデータ品質チェックを行えそうなdbtを活用できないかを検討していました。 具体的に実現したいことは以下でした。
- テーブル名のprefixが異なるだけの同一定義のテーブルに、同じデータ品質チェックをかけられること
どの月のデータかを区別するためにテーブル名にprefixを付加して分けているためです。 - 抽出したデータをcsv出力できること
データ品質を他部門向けに可視化したり、確認を依頼することがあります。そのような際にある程度集計したデータを抽出し、そのまま提供、もしくはスプレッドシート等で可視化したりしますが、それに使えるデータをcsv出力したいためです。
どのような状態を目指していたか
- 毎月の運用で、同じ手順で再現性のあるデータ品質チェックが行えること
- 容易にデータ品質チェック内容の追加、変更ができること
比較検討したサービス
- dbt Core →採用
- dbt Cloud
比較した軸
- アクセスの制限された環境でも利用出来ること
- お試し的な側面もあったので、利用料がなるべくかからないこと
導入の成果
改善したかった課題はどれくらい解決されたか
「ツール導入前の課題」に記載の実現したいことは全て実現できました。
- テーブル名のprefixが異なるだけの同一定義のテーブルに、同じデータ品質チェックをかけられること
モデルのaliasに、valiablesとテーブル名を連結したものを指定することにより、動的にテーブル名を変更できるようにして同一モデルとして扱うことにより実現できました。 - 抽出したデータをcsv出力できること
dbtのPackageのdbt-labs/redshiftでUNLOADコマンドを実行するunload_tableマクロがあり、そちらを活用しました。
詳しくはテックブログを参照ください。
どのような成果が得られたか
- 短期間で約470項目のテストを準備
genericテストを3個自作、汎用性の高いGenericテストを中心に活用したので、比較的短期間でデータ品質維持の基礎も構築可能でした。 - データ基盤の結合テストやユーザ受け入れ試験のデータ抽出にも活用
運用開始前から再現性のあるテストとしても活用できました。- 運用部門が評価するための集計データの抽出
- ユニークとなるべき値の重複などデータの妥当性不備を早期発見、対処
- テーブルの比較のテストで修正後の意図しないデータ差異がないかも容易に確認が可能
- 過去同様の対応事例(railsのwebアプリケーションで作りこみ)との比較
- 工数
今回:約3人月 / 過去事例:約9人月 = 1/3(同規模1システムあたり 6人月減) - データ品質チェック数
今回:470 / 過去事例:117 = 約4倍
- 工数
導入に向けた社内への説明
上長・チームへの説明
- 過去同様の対応事例に倣うと、railsのwebアプリケーションで作りこみとなるが、そこまでの工数はかからず、必要な時期までに実現できる見込みであること
- コマンドラインベースにはなるが、実現したいことはすべて可能な見込みであること
- 他のRedshift Serveless移行をしているデータ基盤でも活用できる可能性が十分に見込まれること
- アダプタとしてAthenaやBigQuery、Snowflakeなどがあり、Redshift以外でも利用可能
活用方法
- まずはデータ基盤にアクセスできるローカルPC上からの実行等のスモールスタートでも運用上十分と判断
- 複数人が運用する想定からdbt実行環境をコンテナ化、コードはgit管理することによる実行環境の共通化
- ローカルPCからRedshift Serverlessにアクセスするにはsshで踏み台サーバ経由での接続となり、将来的にECSタスクでの自動実行等も視野に入れたかったので、dbtのコンテナとssh接続するコンテナを分離した構成に
- データ基盤運用上は、月に1回のデータマート作成前後のいくつかのタイミングで該当テストを実行するコマンド、テスト結果レポートやエラー内容をslack通知するelementaryのコマンドをまとめたシェルスクリプトを担当者が実行
よく使う機能
- dbt run/dbt testといった基本コマンド
- edr monitor/edr reportといったelementaryのコマンド
- dbt Package
- dbt-labs/redshift
- dbt-labs/dbt-utils
- elementary-data/elementary
ツールの良い点
- 再現性のあるデータテストをSQLの知識があれば、比較的容易に作成できる
- Genericテストを自作できたり、環境変数や変数を活用するのが容易で非常に汎用性が高い
ツールの課題点
- データパイプラインからdbtを活用できれば、dbt unit testやメタデータ管理など、より恩恵が受けられるが、そこから置き換えていくには組織内での活用を推進し、dbtの良さをもっと知ってもらう必要がある
- 汎用性が高く、まだまだ使える機能やパッケージがありそう
株式会社JMDC / ytakano
メンバー / データエンジニア / 従業員規模: 301名〜500名 / エンジニア組織: 51名〜100名
よく見られているレビュー
株式会社JMDC / ytakano
メンバー / データエンジニア / 従業員規模: 301名〜500名 / エンジニア組織: 51名〜100名
レビューしているツール
目次
- 導入の背景・解決したかった問題
- 活用方法