dbt Core + dbt-athena で低コストにデータ基盤のパフォーマンス改善
株式会社ネットプロテクションズ / hmatsudaNP
メンバー / データエンジニア / 従業員規模: 301名〜500名 / エンジニア組織: 51名〜100名
| 利用プラン | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|
dbt Core | 11名〜50名 | 2025年4月 | B to B B to C |
| 利用プラン | dbt Core |
|---|---|
| ツールの利用規模 | 11名〜50名 |
| ツールの利用開始時期 | 2025年4月 |
| 事業形態 | B to B B to C |
アーキテクチャ

アーキテクチャの意図・工夫
dbt導入前のデータ基盤からアーキテクチャは大きく変更せず、データ変換のワークフロー部分のみを内製開発したワークフローからdbtに置き換えました。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
前提として、dbt導入前の弊社のデータ基盤では、データの変換部分は内製開発したワークフローを利用していました。しかし、その内製ワークフローは暫定対応として構築されたものであり、以下の課題を抱えていました。
- 挙動が不安定
- データ基盤の障害は、内製ワークフローに起因するものが大部分を占めていた
- 10件/月程度のアラートが飛び、その度に開発者が確認していた
- 予期せぬ挙動が残っている
- テーブルの依存関係解消に、予期せぬ挙動がのこっており、対応が必要ない場合でもアラートが飛んできていた
- 属人化
- 短期的な対応を優先した結果、特定のメンバーに運用・保守の知識が集中し、属人化してしまっていた
- アルゴリズム的な複雑度が高く、ドキュメントも未整備だったため、キャッチアップに時間がかかっていた
どのような状態を目指していたか
内製システムから外部ツールへの移行によって、安定性と効率を高め、より価値の高い領域にリソースを割くことができる状態を目指していました。具体的には以下の3点です。
- 安定稼働している状態
- システム障害の大部分を占める内製ワークフローがdbtにリプレイスされ、データ基盤全体の障害発生率が下がっている状態
- テーブルの依存関係解消時に起こる既存のバグを解消し、ディメンショナルモデリングが推進しやすい状態
- デファクトスタンダードに乗り副次的効果を享受できる状態
- 世の中で最も使われているアプリケーションなので安定性が高い状態
- ドキュメントが整備されており、ユーザーコミュニティもあるため、知見の獲得が容易な状態
- データ分析環境業界でよく使われているアプリケーションであるため、即戦力となる新規メンバーの獲得がしやすい状態
- 自社開発→外部ツール利用により、人的リソースをより良く配分できる状態
- 内製ワークフローの管理・保守に利用していた人的リソースを別のプロジェクトに活用可能な状態
- 具体的には以下のような業務に力を割きたいと考えていた
- ディメンショナルモデリングの推進
- 事業部でのデータ活用推進サポート
- 機械学習環境の構築
比較検討したサービス
- dbt Core
- dbt Cloud
比較した軸
- 費用
- ニーズに合っているか
選定理由
- dbt Coreの方が費用を気にせずに小さく始めやすかったため
- dbt Cloudは弊社のニーズに対してオーバークオリティだったため
導入の成果
改善したかった課題はどれくらい解決されたか
- dbt導入前にあった3つの課題は、全て解決できました
どのような成果が得られたか
- これまでエンジニアが障害対応に使っていた時間を、別のプロジェクトに使えるようになった
- テーブルの依存関係の予期せぬ挙動を解消し、ディメンショナルモデリングの推進に取り掛かることができた
- dbt testとdbt elementaryの活用により、データ品質を向上させることができた
導入に向けた社内への説明
上長・チームへの説明
- 安定稼働によるエンジニアの対応工数削減効果について定量的に示しました
- また、予期せぬ挙動が解消されることでディメンショナルモデリングを推進しやすくなり、結果として分析者に求められるSQLスキルが下がり、分析者を増やすことができると説明しました
活用方法
普段
- 1日1回データソースからAmazon S3に抽出されてきたデータを検知して、テーブルを差分更新
- テーブルの差分更新は"table_type: iceberg"と"materialized: incremental"を使うことで実現
テーブルの新規作成・編集時
- dbt modelを追加・編集した際には、GitHubの本番環境デプロイ用のbranchにmergeされたタイミングで、変更のあったmodelに対してdbtが実行されるようにGitHub Actionsで設定
よく使う機能
macro
modelファイル名とは異なるテーブル名(エイリアス)の生成や、Glueテーブルのカラム一覧取得など、macroを用いて動的にsqlを作成しています
elementary & dbt test
elementaryを活用して、dbt runやdbt testでerrorが出た際にはslackにアラートを飛ばしています
dbt docs
Amazon S3でホスティングして、社員全員が見られる状態にしています
ツールの良い点
低価格で始められる点
- 安く始めたい場合、S3 + Athena/Glue + dbt-athena の組み合わせはオススメです
- 理由
- Athenaはサーバーレス & スキャン課金
- 例えばSnowflakeやRedShiftは時間課金であり、最初は試行錯誤に時間がかかるので、どうしても初期コストが高くなる
- データスキャン量の課金形態の場合、利用時間を気にする必要がない。使った分だけ課金されるので、初期コストが抑えられる
- Athenaはインフラ周りの設定がいらないので運用コストが不要
- Athena用のストレージやユーザー作成の必要がない
- S3に保存されているデータに対してクエリを叩けるので、データのロードや、ストレージコストを考える必要がない
- Athenaはサーバーレス & スキャン課金
データ変換を全てSQLで行うことができる点
- Pythonなどのスクリプトで実施するよりもメンテナンスがしやすいです
- データエンジニアだけでなく、SQLを扱うことができる人なら誰でも扱うことができるようになります
"table_type: iceberg"によりパフォーマンスが改善できる点
- "materialized: incremental"と組み合わせてテーブルの差分更新が実現できました
- 以前は度々生じていたQuery exhausted resourcesのエラーを回避できるようになりました
ECSで実行可能な点
- EC2と比較して、dbt実行の都度ECSを起動できるため、コスト効率がよく、メンテナンスもしやすいです
LF-Tagをdbt-athenaで付与することができる点
- dbtのSQL内で閲覧権限(LF-Tag)を設定できるのが便利です
macroがdbt側で用意されている点
- カスタマイズしたmacroだけでなく、dbt側で用意されているmacroも問題なく使うことができました
ツールの課題点
dbtのインフラをECSなどで作成する必要がある
- 運用開始時は、ECSの同時実行制御のために、ECSのメモリ設定やdbtのスレッド数の調整など、実行リソースに関するチューニングが必要でした
- 具体的には、dbtの実行時にOut of Memoryエラーが発生したため、ECSのContainer InsightをONにしてメモリ使用率の監視を行いました
- ECS Fargateのメモリを十分に確保した上で、dbtのスレッド数を一旦下げて安定動作を確認しました。その後、Out of Memoryエラーが発生せず、かつ許容時間内に処理が完了する最適なスレッド数まで、段階的に引き上げる調整を行いました
Athena/Glueとiceberg間の仕様違いのために、iceberg形式への変換時にデータ型変換が必要になるケースがあった
- 例えば、Glue テーブルではマイクロ秒精度のタイムスタンプ (timestamp(6)) がサポートされておらず、下記のエラーが発生しました
NOT_SUPPORTED: Timestamp precision (3) not supported for Iceberg. Use "timestamp(6)" instead.
- 解決策としては、macroでdbt modelが参照するテーブルのカラム情報を動的に取得する仕組みを実装し、macro内でカラムのデータ型を判定して、自動でミリ秒精度(例: timestamp(3))にCASTする処理をSQLに組み込むようにしました
ツールを検討されている方へ
- データ基盤のトレンドが変化する中で、無料で始めることができ、多様なサービスとのアダプターが充実しているdbt Coreは、検討初期に「まず導入してみる」ができるおすすめのツールです。
- 弊社では、解決したい課題とツール導入費用を考慮した上で、dbt Coreを選択しました。
- 単純なデータ変換のみであれば、dbtを導入せずにAWS Glue等の他のサービスの変換機能で十分かもしれません。しかし、データ基盤の利用の拡大により、複雑な依存関係をもつテーブルの管理・更新や、ドキュメントの整備が必要になってきた段階で、データ変換の「管理」を得意とするdbtを検討すると良いと思います。
- また、データ変換をすべてSQLで扱えるようになるので、これまでデータアナリストがデータエンジニアに依頼していた内容を、データアナリスト自身ができるようになることも魅力だと思います。
今後の展望
- 弊社の「ツール導入前の課題」は、dbt導入によりいずれも解決することができました。
- 今後は、ディメンショナルモデリング推進に取り組み、社内のデータ活用をさらに促進していきます。その過程で、dbt packageも活用しながら、ドキュメントやメタデータの整備も進め、よりデータを扱う人にとって易しい状態を作っていきたいです。
- また、今年度末にSnowflakeを導入し、dbt-athenaからdbt-snowflakeへ移行予定です。既にdbt-athena導入によりdbtのインフラは構築されているため、dbt-athenaとdbt-snowflakeの仕様の違いの部分を調整していきます。
株式会社ネットプロテクションズ / hmatsudaNP
メンバー / データエンジニア / 従業員規模: 301名〜500名 / エンジニア組織: 51名〜100名
よく見られているレビュー
株式会社ネットプロテクションズ / hmatsudaNP
メンバー / データエンジニア / 従業員規模: 301名〜500名 / エンジニア組織: 51名〜100名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法


