dbtでは、dbtを扱う上で必要とされるスキルを証明するものとして認定試験が用意されています。合わせてドキュメントとして展開されている『dbt Analytics Engineering Certification Exam』では、『dbtを使ってモデルを構築、テスト、保守して、他の人がデータにアクセスできるようにする』『dbt を使用してエンジニアリング原則を分析インフラストラクチャに適用する』ことが出来るようになるためにはどういう部分を押さえておけば良いのか、が端的に紹介されています。
そこで当エントリでは、このドキュメントを読み込んでdbtのスキルを習得するには、認定試験「dbt Analytics Engineering Certification Exam」をクリアするには何を学んで理解しておけば良いのかについて見ていきたいと思います。
目次
- dbtモデルの開発
- データモデリングの際に発生するエラーの内容を確認し解決させる
- データパイプラインのモニタリング(監視)
- dbtテストの実装
- dbtジョブのデプロイ
- dbtドキュメントの作成と運用
- バージョン管理システムを通してのコード化の促進
- データウェアハウスにdbt用の環境を構築
- まとめ
dbtモデルの開発
Identifying and verifying any raw object dependencies(生オブジェクトの依存関係を特定・検証する)
文章を読む限りでは割と抽象的なイメージですが、これはdbtで管理する前に、生データ時点でのデータウェアハウス上の要素間の依存関係を把握・理解しておきましょうね...ということでしょうか。
Understanding core dbt materializations(基本的なdbtにおけるマテリアライゼーションを理解する)
dbtモデルを、対象となるウェアハウス環境に永続化させるための手法、戦略を「マテリアライゼーション」と呼んでいます。条件や用途に応じて幾つかのパターンがあります。
Conceptualizing modularity and how to incorporate DRY principles(モジュール性の概念化とDRY原則の組み込み方法)
dbtにおけるモジュール性(システムのコンポーネントを分離して再結合できる程度)という考え方をdbtではどのように扱っているかについての言及。
DRY原則に関しては下記ドキュメントでも言及、解説されています。
Converting business logic into performant SQL queries(ビジネスロジックをパフォーマンス性の高いSQLに変換)
dbtでは実行させたい処理をSQLで記述、指示する形となっていますが、ビジネスロジックをこの(dbtで稼働する)SQLに、パフォーマンス性を踏まえた上で変換する方法やスキルについて求められています。
公式では無いですがそのものズバリなワードで下記の記事がありました。この辺考え方の参考になるかもしれません。
またレガシーなSQLをdbtで動くSQLに変換する方法についてはこちらのドキュメントで言及されています。
Using commands such as run, test, docs and seed(dbtコマンドの利用)
dbtでは環境に対してコマンド操作で処理を実施することが可能です。
Creating a logical flow of models and building clean DAGs(モデルの論理フローを作成し、クリーンなDAGを構築)
DAG(Directed Acyclic Graph/有向非巡回グラフ)は分析エンジニアリングの実践では、データモデル間の関係を視覚的に表現するために DAG がよく使用されますが、そのDAGをdbtではどのように構築し、どのように扱うか...という点について言及しています。
Defining configurations in dbt_project.yml(dbt_project.ymlで設定を定義する)
dbtプロジェクトに於ける設定を行っているdbt_project.ymlに関する定義内容の理解。
Configuring sources in dbt
データストアから取得したテーブルを宣言する方法として提供されているものが「source」です。
Using dbt Packages(dbtパッケージの利用)
分析上の問題に対応するノウハウの共有やコーディング処理・各種作業に掛かる時間の短縮を目的とした、dbtで提供されているライブラリ群をパッケージと呼んでいます。
データモデリングの際に発生するエラーの内容を確認し解決させる
Understanding logged error messages(ログに記録されたエラーメッセージを理解する)
dbtで発生したエラーはログに記録されます。ここではその記録された内容に関する理解が求められています。
Troubleshooting using compiled code(コンパイルされたコードを使ってのトラブルシューティング)
dbtではcompileというコマンドでmodelなどの設定ファイルから実行可能なSQLを生成していますが、その辺りのトピックについても言及しています。
Troubleshooting .yml compilation errors(.ymlファイルのコンパイルエラーに関するトラブルシューティング)
上記同様の方向性、こちらはymlファイルに関するもの。
Distinguishing between a pure SQL and a dbt issue that presents itself as a SQL issue(「純粋にSQLの問題」なのか「dbtが生成したSQLの問題」なのかを区別する)
何らかのエラーが発生した時に、その問題が「dbtが関係していない、純粋にそのSQLの問題」なのか「そうでない(dbtが何らか関係している)」のかを区別出来るようにしておく必要があります。
Developing and implementing a fix and testing it prior to merging(修正の開発と実装、およびマージ前のテスト)
dbtにモデルの開発、実装、テストを行います。下記ドキュメントではdbtに於ける各種開発に関するベストプラクティスにも言及されています。
データパイプラインのモニタリング(監視)
- Understanding and testing the warehouse-level implications of a model run failing at different points in the DAG(DAG上の様々な局面でモデル実行が失敗した際の影響度を理解し、テストする)
- Understanding the general landscape of tooling(ツールの一般的な状況を理解する)
このパートに関しては作成したdbtのパイプラインが運用フェーズに入った際、監視しているパイプラインでエラーが発生した際の対応に関するトピックとなっているようです。
dbtテストの実装
Using generic, singular and custom tests on a wide variety of models and sources(さまざまなモデルやソースに対してテストを実施する)
dbtではdbtで定義したモデルやリソースに対してテストを定義し、実行することが可能となっています。テストの種類としては単一テスト(generic test)、汎用テスト(generic test)、カスタムテスト(custom test)の3種類があります。
Understanding assumptions specific to the datasets being generated in models and to the raw data in the warehouse(モデルで生成されるデータセットとウェアハウス内の生データに固有の前提条件を理解する)
dbtでモデルを定義した場合、実際の生データとの関係性や何かしらの差異が発生している、もしくは関係性に関して理解しておく必要がある...という事なのでしょうか。今後の学習でこの辺り詳細明らかに出来ればと思います。
Implementing various testing steps in the workflow(ワークフロー内で様々なテスト手順を実装する)
dbtではテストの種類が様々あることは前述しましたが、ここではその多種多様なテストをどのようにワークフローで実装、展開していくかということに焦点が当たっていると思われます。この辺が参考になりそう？
Ensuring data is being piped into the warehouse and validating accuracy against baselines(データがウェアハウスにパイプされていることを確認し、ベースラインに対する精度を検証する)
文脈からすると、ワークフローが実行されたことによるデータパイプラインの「在り方」について、作成されたデータそのものに対する検証も必要ですね...という辺りに言及しているのではというところでしょうか。
dbtジョブのデプロイ
Understanding the differences between deployment and development environments(デプロイ環境と開発環境の違いを理解する)
dbtに関わらず、サービス稼働しているプロダクトはデプロイ環境(ここでは"本番環境"の意？)と開発環境(本番環境にデプロイするための各種検証、動作確認を兼ねた環境)が設けられる事がありますが、dbtにおいてのそれについても理解しておきましょう、環境の使い分けをちゃんと把握しておきましょう、というトピック。
Configuring development and deployment environments(デプロイ環境と本番環境の設定)
それぞれの環境に関する設定方法、設定の違いなどに関して。(と思われる)
Configuring the appropriate tasks, settings and triggers for the job(業務に適したタスク、設定、トリガーの設定)
利用者環境に於ける業務の面から、どのようにタスクや設定、トリガーを構成するのが良いのか、というトピック。dbt自体での設定もそうですが、dbtだけでは賄いきれない設定や条件の場合は他サービスからdbtのジョブを連携させる...といった部分にも言及している内容になってそう？(というのが下記ドキュメントから推察出来ますね)
Understanding how a dbt job utilizes an environment in order to build database objects and artifacts(データベースオブジェクトと成果物を構築するために、dbtジョブがどのように環境を利用するかを理解する)
このトピックについては構造や仕組み、どういった流れで実現されているのかを理解する事が出来ていれば良さそうです。
Using dbt commands to execute specific models(dbtコマンドを使って特定のモデルを実行する)
"特定のモデルを実行する"というのは、「作成済みの特定のモデルに対して任意の操作を実行する」という理解で合ってるのかな？状況に応じた処理を行いたい時にどのコマンドをどういう風に使えば良いのか？というのを押さえておけば良さそう。
dbtドキュメントの作成と運用
Updating dbt docs(dbtに関するドキュメントの更新)
dbtでは、作成したデータモデルに対するドキュメントを生成する仕組みが提供されています。この情報を更新する際のポイントについて言及されています。
Implementing source, table, and column descriptions in .yml files(ymlファイルでのソース、テーブル、カラムの記述の実装)
dbtでは様々な設定をymlファイルで行っています。対象となるソースやテーブル、カラムといった要素をどの様に設定・記述していけば良いのかというトピックです。
Using dbt commands to generate a documentation site(ドキュメントサイト生成にdbt commandsを利用する)
上述のdbtドキュメントはコマンド実行によっても行うことが出来ます。このトピックはその辺に言及しているものと思われます。
Using macros to show model and data lineage on the DAG(マクロを使用してDAG上のモデルとデータの系統を表示する)
マクロ(macro)って一体何？と思いましたが、Jinjaの中に含まれる要素(コード)をそういう風にdbtでは呼んでいるんですね。
Jinja のマクロは、何度でも再利用できるコードの一部です。他のプログラミング言語の「関数」に似ており、複数のモデル間でコードを繰り返す場合に非常に役立ちます。
マクロは.sqlファイル内、通常はmacrosディレクトリ ( docs ) 内に定義されます。
ちなみにJinjaとは、高速で表現力豊かな、拡張可能なテンプレート エンジンです。テンプレート内の特別なプレースホルダーを使用すると、Python 構文に似たコードを作成でき、ドキュメントをレンダリングするためのデータがテンプレートに渡されます。dbtでは内部にこのJinjaを活用しています。
Jinja及びMacroに関するdbtドキュメントはこちら。
バージョン管理システムを通してのコード化の促進
Understanding concepts and working with Git branches and functionalities(Gitのブランチと機能の概念を理解し、作業する)
dbtではリソースのバージョン管理にGitを用いています。Gitのブランチについてその仕組、概念を理解しておき、実際に使えるようになる必要がdbt利用の際には求められます。
Creating clean commits and pull requests(クリーンなコミットとプルリクエストの作成)
ブランチ同様、CommitとPull Resuestに関しても内容を理解し、扱えるようにしておく必要があります。ここでは「クリーンな」という但し書きが付いてますので、よりベストな、望ましい設定やルールに基づいた運用が出来ることが求められているようです。
Merging code to the main branch(コードをメインブランチにマージする)
上記2トピックに続いて、マージについても(以下略
データウェアハウスにdbt用の環境を構築
Understanding environment’s connections(環境の繋がりを理解する)
ここでの"繋がり(Connection)"は「dbtの実行環境」と「dbtが処理を行うデータウェアハウスの環境」における理解で良いのでしょうか？dbtにおけるデータウェアハウスの設定周りを見ておけば良さそうな気はします。
Understanding the differences between production data, development data, and raw data(本番データ、開発データ、生データの違いを理解する)
ここでの「データ」の定義が前者2つと後者でどう違うんだろう？という率直な疑問は浮かびますが、dbtにおいては何か固有の定義があるのだと思われます(多分この辺に情報ありそう)。その辺りの違いをしっかりと識別、認識しておく必要があります。
まとめ
という訳で、dbtの認定試験「dbt Analytics Engineering Certification Exam」に関するドキュメントに記載されているトピックをそれぞれ読み解いて全容を把握してみた内容の紹介でした。
私自身、まだdbtに関するスキルはまだまだなレベルではありますが、一度全容を見渡して見ることでざっくり"登るべき山"の状況が把握できた気がします。あとはひたすら個々のトピックについて学び、実践し、自らの血肉としていくだけですね！
ということで、dbtに関するインプットは適宜アウトプットしていこうと思います。
2
