データアナリティクス事業本部 機械学習チームの鈴木です。
先月末にデータアナリティクス事業本部の部内メンバー向けに、dbt Coreとdbt-athenaによるAWS上のdbt環境構築ナレッジの共有資料を作成・発表しました。
資料はもともと、DevelopersIOでのブログ公開目的も含めて作成しているので、資料へのリンクとポイントについて簡単にご紹介します。
既にdbt CoreをAWS環境で長らく開発・運用されている方からすると物足りないところもあると思いますが、+オペレータによる親子関係のあるノードの実行とかはあまり日本語の資料も見つけられなかったので、ご参考になる箇所がありましたら幸いです。
資料について
以下にスライドを公開しました。
ポイント
1. dbt-athenaのGlueおよびAthenaへの接続先設定
基本的には以下のファイルで行います。
- モデル作成先：
profiles.yml - モデルではない既存テーブルの読み取り: ソースの定義ファイル
使用するIAMについては、プロファイルを指定したい場合はprofiles.ymlのaws_profile_nameで指定できました。インスタンスロールを使う場合は指定なしでも使えます。
2. タグによる実行制御
--select "tag:タグ名"および--exclude "tag:タグ名"を使って制御が可能です。
AND条件・OR条件を使って複数タグを指定するような細かな挙動については以下のブログが参考になります。
タグはモデルやテストに設定することができますが、どのモデル・テストになんのタグを付けるのかは、各種設計をきちんと行なって決める必要があります。
一方で、タグの付け替え自体は設計さえちゃんと決めておけば単純作業で付け替えできるので、最初はとりあえず付けてしまって、運用する中で調整するのでも良いかもしれないなとは思っています。
3. モデル間の関係性による実行制御
ある関係性が互いにあるモデルを実行する方法として、以下の2つを紹介しました。
- DAG内で親子関係があるもの:
+オペレーターを使って実行する - 特定のディレクトリに存在するもの:
--selectでパスを指定して実行する
運用の仕方にもよりますが、個人的には２点目の機能はプロジェクト構成にも影響するので重要な点だなと思っています。
１点目の機能はマートを最新化したい場合にはとても使い勝手が良さそうですが、ソースがマート作成処理からみて常に最新であることが求められます。
ソースが新しくない場合には、freshnessを使えば検知することができます。
4. オーケストレーターの必要性
例えば、dbt runをcronで実行するだけにもできますが、個人的にはより柔軟な機能を実現するため、何かしらのオーケストレーターがdbtとは別に必須になると思います。
AWSでの候補としてはP.12にいくつか挙げました。
フルマネージドサービスが良ければStep FunctionsでECSタスクとしてdbtを実行することができます。実際、この構成にされている方も多いと思います。
一方で、保守はちゃんとするからとりあえずSSHで入って作業できるようなサーバーでやりたいということもあると思うので、その場合はEC2にオーケストレーターとdbtを同居させるような簡単な構成でも良いようには思っています。
5. Icebergテーブルの利用
dbt-athenaではGlueのIcebergテーブルにも対応しています。
Icebergテーブルを使用する際の懸念事項としては、テーブルのメンテナンスコマンドの実行があります。
GlueのIcebergテーブルはMerge-On-Read (MOR)のため、パフォーマンス維持のために、更新により発生した新規データのコンパクションと削除データのマージは定期的な圧縮の実行が必要になります。このほか、不要ファイルの削除も含めて、定期的にVACUUMとOPTIMIZEのメンテナンスコマンドを実行する必要があるため、これをどのように実装するかは念頭に入れたシステム設計が必要です。
直近リリースされたGlueの自動コンパクション機能は『AWS GlueのIcebergテーブルに対して自動的にコンパクションを実行する機能を使ってみた』で紹介しましたが、この機能は記事執筆時点では削除データのマージはしないため厳密にはOPTIMIZEの代替ではありません。
6. 各種パス指定オプションについて
スライドに分散してパス指定のためのオプションを記載していますが、まとめておきます。
- dbtプロジェクトのパスを指定したい:
dbt runなどで--project_dirオプションを使う。 - プロファイルを指定したい:
dbt runなどで--profiles_dirオプションを使う。 - パッケージのインストール場所を指定したい:
dbt_project.ymlにpackages-install-pathを指定する。
このほかにも重要なものはあるかもしれませんが、今の所、必要になって調べたものを記載しました。
なお、packages-install-pathは、記事執筆時点ではdbtプロジェクトの外を指定すると、dbt cleanで消せない仕様になっているようで、注意が必要そうでした。こういう点でも、細かなケアをするためにオーケストレーターを別に用意すると良いケースがあります。
参考資料
スライド中で掲載した資料を中心にリンクを記載します。
- How we structure our dbt projects | dbt Developer Hub
- Graph operators | dbt Developer Hub
- Syntax overview | dbt Developer Hub
- Implement data warehousing solution using dbt on Amazon Redshift | AWS Big Data Blog
- Amazon Redshift + dbt ユーザー必読の書「Best Practices for Leveraging Amazon Redshift and dbt」を読んでみた | DevelopersIO
- AWS GlueのIcebergテーブルに対して自動的にコンパクションを実行する機能を使ってみた | DevelopersIO
- [動画公開] Amazon Athena (Iceberg) x dbt ではじめるデータ分析！ #ちょっぴりDD | DevelopersIO
- Great Expectationsを用いたデータ品質テストがdbt上で行えるpackage「dbt_expectations」を試してみた #dbt | DevelopersIO
- EqualExperts/dbt-unit-testing: This dbt package contains macros to support unit testing that can be (re)used across dbt projects.
- packages-install-path | dbt Developer Hub
最後に
dbt Coreとdbt-athenaによるAWS上のdbt環境構築ナレッジの共有資料を作成・発表したので資料のご紹介でした。
2
