Slide 1

Slide 1 text

dbt Coreとdbt-athenaによる AWS上のdbt環境構築ナレッジ 2023年11⽉28⽇(⽕)13:00〜 鈴⽊ 那由太 1

Slide 2

Slide 2 text

2 はじめに <⼀⾔で⾔うと> • AWS上でdbt-athenaをアダプターに利⽤して、Glueデータカタログにモデルを作成する場合の 構成例を紹介する。 <キーワード> • dbtとは • データ変換をSQLベースで簡単に⾏えるようにするためのツール • クラウドDWH上でのデータ変換処理をより⾼速かつ⾼品質に⾏えるようにする、さまざまな機能を提供する • dbt Coreとは • コマンド ラインから開発してdbtプロジェクトを実⾏できるオープンソースプロジェクト • dbt-athena-communityとは(以降dbt-athena) • Amazon Athena向けのアダプタープラグイン • コミュニティで開発されているオープンソースプロジェクト

Slide 3

Slide 3 text

3 dbt-athenaによる処理の主要部分 Amazon S3 Amazon Athena AWS Glue Data Catalog コンピュート サービス • ソーステーブル • モデル(テーブル・ビュー) • ステージング • インターメディエート • マート コンピュートサービス上でdbtのコマンドを実⾏する。dbtはAWSのAPIにアクセスし、 モデルで定義された処理をAthenaで実⾏して、指定したマテリアライゼーションで実体化させる。 • dbt runで実行 • --project_dirでdbtプロジェクトを指定可能( dbtプロジェクト構成については後ほど確認) • --profiles_dirで仕様するプロファイルを指定可能(プロファイルについては後ほど確認)

Slide 4

Slide 4 text

4 AWSでのdbt実行環境例 # コンピュート サービス 概要 メリット デメリット 1 EC2 • EC2にdbtをインストールしておき、 ワークフローツールなどで実行する。 • ワークフローツールなどと 同居させて、始めやすい。 • デバッグがしやすい。 • EC2の管理が必要になる。 2 ECS • ECRなどにdbtプロジェクトをイメージにして pushしておきECSタスクで実行する。 • オーケストレーターと 実行環境を分離できる。 • 費用・管理コストが抑えやすい。 • 厳密にはローカル実行はできな いので、開発時にやりにくさを感 じるかも。 • オーケストレーターなどは 別に必要。 実⾏時間制限がないコンピュートサービス上で実⾏させることになる。 メジャーな候補としては以下の2つが挙げられる。

Slide 5

Slide 5 text

5 dbtプロジェクト構成の全体像 ▼ベストプラクティスに沿ったdbtプロジェクト構成※ ※ best practicesより2023/11/20に引⽤ https://docs.getdbt.com/best-practices/how-we-structure/1-guide-overview プロジェクト構成は理由がなければベストプラクティスに倣うと良い。 各層について • ソーステーブル︓既存Glueテーブルからデータを読み出すためのもの • モデル︓SQLおよびJinjaにより定義される。Glueとしてはテーブル・ビュー • ステージング︓ソーステーブルを後続で扱いやすく加⼯した層 • インターメディエート︓マートの共通ロジックを表す層 • マート︓ユースケースに対応するデータを表す層

Slide 6

Slide 6 text

6 Glue・Athenaへの接続設定 ▼ソース定義例 ▼profiles.yml設定例 Athenaへの接続設定はprofiles.ymlとソーステーブルにてGlueデータベースなどを設定する。 特にprofiles.ymlについては、dbt-athena-communityのGitHubレポジトリを確認するとよい。 AWSへの接続にprofileの認証情報を使いたい場合は profiles.ymlで指定する。 EC2のインスタンスロールを使うような場合は指定なしでも良い。 ソースの定義でもデータベースおよびテーブル を指定する。

Slide 7

Slide 7 text

7 ドキュメント生成 dbt-athenaでも問題なく使⽤可能だった。 モデル・テストの管理およびリネージが確認できる。 • dbt docs generate • dbt docs serve --port 8001

Slide 8

Slide 8 text

8 適切そうな規模感 Amazon DataZone Amazon Simple Storage Service (Amazon S3) Domain A Amazon Athena AWS Glue Data Catalog EC2 Domain B Amazon DataZone 個⼈的にはチーム単位でのデータ統合や共有⽤データ作成を⾏うくらいの規模感が適切な印象を持っている。

Slide 9

Slide 9 text

9 テストツールおすすめ # ツール名(パッケージ名) 概要 ポイント 1 標準テスト dbtの標準機能として搭載されて いる。スキーマに関するもの主。 dbt-athenaでも確実に動作する。 2 dbt-unit-testing モデルのデータが期待値と一致 するかテストできる。 期待値はテーブルからSELECTした 結果を突き合わせることができる。 3 dbt_expectations 品質テストを実装する。(Great Expectations準拠) 標準テストより柔軟な品質テストが実 装できる。 使ってみてよかったものについてご紹介する。 • packages.ymlにインストール対象を記載 • dbt depsコマンドでインストール • インストール先はprofiles.ymlでカスタマイズできる

Slide 10

Slide 10 text

10 タグによる実⾏制御 • モデルやテストにタグを付与して実⾏の制御を⾏うことができる。 • --select “tag:タグ名”︓指定したタグのものを実⾏する • 例: dbt run --select “tag:sample_tag” • --exclude “tag:タグ名”︓指定したタグのもの以外を実⾏する • 例: dbt test --exclude “tag:prod_test” • タグ設計のポイント • モデル︓実⾏頻度 • データソースシステムはなにか • ユースケースはなにか • いつデータ連携されるのか • テスト︓テスト種別 • なんのテスト項⽬か(ロジックのテスト、スキーマのテスト) • どの環境向けか(開発・ステージング・本番) 当然ながらモデル・テストの設計をまず⾏う必要があり、 その設計を踏まえてタグを決めて付けていくのがやりや すかった。 ただ、タグ名を決めておけば置換などすれば修正も進め やすいのでまずはラフに付けてみてから細かくしていく のでも良さそう。

Slide 11

Slide 11 text

11 モデル間の関係性による実⾏制御 • +を使ってあるモデルが関係する親や⼦のモデルを実⾏することもできる。 • dbt run --select "+my_model” • https://docs.getdbt.com/reference/node-selection/graph-operators • modelディレクトリ配下のディレクトリを指定して実⾏もできる。 • dbt run --select "path.to.my.models" • https://docs.getdbt.com/reference/node-selection/syntax ソーステーブルが常に最新であることを保証できるのであればよさそう。 ソーステーブルの中⾝をPULLしないといけない場合は、動的に親⼦が選べても データ同期をそれに合わせて調整するか⾃分で決め打ちで実装しておかないといけない。 ディレクトリ構成は開発者側で制御できるので、こちらの⽅が使い勝⼿がよさそう。

Slide 12

Slide 12 text

12 オーケストレーターの必要性 EC2・ECSともにジョブオーケストレーターは必須になる。 dbt runだけで定期的に全てのモデルを作成できるが、データ作成に必要な処理は以下もあるため。 • ソーステーブルが参照するS3パスへの最新データの取得のため、AWSのAPIを利⽤する必要があるとき • 作成したデータをどこかのサービスにこちらから連携したいとき • 実⾏履歴を管理したいとき • テスト実施時など⼀連のdbtのコマンドを順番に実⾏したいとき(dbt seedしてからdbt runしてdbt testしたいとか) 候補 • Step Functions • Apache Airflow(Amazon Managed Workflows for Apache Airflow など) • Digdag • Dagster

Slide 13

Slide 13 text

13 AWSでのdbt Core構成例 Amazon Simple Storage Service (Amazon S3) Amazon Athena EC2 AWS Glue Data Catalog dbt run --select “tag:sample_tag” ワークフローエンジンとdbt⽤のサーバーをEC2で⽴て、ワークフローエンジンからdbtのコマンドを 実⾏してGlueテーブル・ビューとしてモデルを実⾏する。 ▼構成例 ワークフローエンジン

Slide 14

Slide 14 text

14 AWSでのdbt Core構成例 『Implement data warehousing solution using dbt on Amazon Redshift』より2023/11/22に引用した。 https://aws.amazon.com/jp/blogs/big-data/implement-data-warehousing-solution-using-dbt-on-amazon-redshift/ https://dev.classmethod.jp/articles/20230430- amazon-redshidt-dbt-best-practice/ ▼関連︓Redshiftを組み合わせたときの ベストプラクティス解説 ▼構成例(Redshiftの例を引⽤) dbtおよびdbtプロジェクトをコンテナとしてECRに保存する。 ワークフローエンジンからECSタスクを実⾏してモデルを実⾏する。 実⾏時にタスクにタグなどを渡すことで実⾏するモデルを制御するのでも良い。

Slide 15

Slide 15 text

15 MLシステムでの⽤途 Amazon S3 Domain A AWS Glue Data Catalog EC2 Domain B AWS Clean Rooms Amazon S3 Amazon S3 Amazon S3 Amazon S3 System Amazon SageMaker 学習・推論データを作成するためのデータ統合・データマート作成が主な役割になると考えられる。 機械学習モデルの推論結果をGlueテーブルとして公開するときにも使える。 外部

Slide 16

Slide 16 text

16 Icebergテーブルの利⽤ https://dev.classmethod.jp/articles/20230727- amazon-athena-iceberg-x-dbt-cyopiri-dd/ https://github.com/dbt-athena/dbt-athenaより2023/11/27に引用 dbt-athenaではIcebergテーブルもサポートしている。 Icebergの場合テーブルのメンテナンスは必要なため、OPTIMIZE・VACUUMのSQLをスケジュール実⾏する。 OPTIMIZEについてはGlueデータカタログの⾃動的なコンパクションも使えるが、厳密にはOPTIMIZEと異なる。 https://dev.classmethod.jp/articles/try-aws-glue- iceberg-automatic-compaction/ ▼設定例 ▼⾃動的なコンパクション ▼Iceberg x dbt参考

Slide 17

Slide 17 text

17 まとめ <紹介したこと> • AWS上でdbt-athenaを利⽤してGlueデータカタログにモデルを作成する場合の構成例を紹介した。 • dbt-athenaのAWSに関する設定箇所や基本的な使い⽅を紹介した。 • 使ってみて適していそうと思った構成イメージを紹介した。 • テスト⽤パッケージやモデル実⾏コマンドについて紹介した。 <紹介できなかったこと> • そのほかのdbtの重要な基本機能(dbt seedなど) • dbtのベストプラクティス • Jinjaを使ったモデリング