本編

2023年7月31日（現地日付）にリリースされたdbt-coreのv1.6のアップデート情報をまとめる。（参考：Upgrading to v1.6 (latest)）
公式ドキュメントによると、今回のアップデートの中で特に重要な点は以下の3つとしている。

Next milestone of multi-project deployments: improvements to contracts, groups/access, versions; and building blocks for cross-project ref

Semantic layer re-launch: dbt Core and MetricFlow integration

Mechanisms to support mature deployment at scale (dbt clone and dbt retry)

上から順に簡単に紹介する。
なお、すべてのアップデート情報については以下を確認すべし

1. `ref`を用いて他のプロジェクトのモデルを参照できる機能を実装

そもそも、multi-project deploymentsとは、dbtのプロジェクトが大きくなり、スピードを持った開発や管理が難しくなるケースを想定したdbtメッシュ実現のための計画を指すようである。dbtメッシュはモノリシックでない（モデルを1つのプロジェクトですべて完結させず、複数プロジェクトにまたがる）かつ、サイロ化を防ぐ（異なるプロジェクト間の可視性を高める）世界を実現させることを目的としている。

前回バージョンのv1.5では計画のフェーズ1として以下の3つの機能が実装された。

Model contracts
- データプラットフォームに応じて、カラムにnot nullなどの制約をつける機能。これを満たさない場合はモデルは作成されない
Model groups & access
- グループに含まれるモデルをpublicとprivateに分類することで他のプロジェクトからの参照制約をつける機能
Model versions
- モデルを下流ユーザにAPI風に提供するときに役立つためのモデルのバージョニング機能

今回のv1.6では計画のフェーズ2として上記の機能の改修およびrefを用いて他のプロジェクトを参照できる機能が実装された。
これまでは、パッケージとして別のプロジェクトのソースをインストールして利用する方法があったが以下のような問題があった。

入力を解析して解決するのに時間がかかる
上流モデルの管理者の意図しない使われ方をしてしまう可能性がある
環境変数やモデル名、スキーマ名、バージョンの変更に都度対応しなければならない
誤ってモデルを構築し、予期しないコストや権限の問題が発生する可能性がある

今回のv1.6のアップデートによって、パッケージとしてインストールするのではなく、refを用いて上流のプロジェクトのモデルをソースとして参照することができるようになった（他プロジェクトからの参照を許すpublicなモデルに対して、dependencies.ymlにプロジェクト名を記述すれば、モデル内で{{ref('project_name', 'model_name')}}のように参照ができる。参考：Project dependencies）。内部的には、メタデータを利用して、publicとして定義された別プロジェクトのモデルを参照できるようになった。そのため、上流プロジェクトで定義していた環境変数の再設定なども不要になった。
しかし、注意点として現時点では、dbt CloudのEnterpriseのクローズドベータ版のみ利用できる機能となっている。利用する際には、dbt Labsのアカウントチームに問い合わせが必要である。
理由としては、技術、メンテナンス、ビジネスの観点から比較的規模が大きいエンタープライズ向けに提供される機能として提供するためとしている（参考：開発者コメント）。
今後、dbt CloudのEnterprise製品を選択する理由の1つになる可能性があるためチェックしておくと良いかもしれない。

2. dbt Core と MetricFlow の統合

これまでは、dbtでセマンティックレイヤーを実現するためのパッケージとしてdbt_metricsが用意されていたが、それを廃止しMetricFlowと統合することになった。
dbt_metricsを廃止する理由については、以下の開発者ブログが参考になる。

なお、dbtセマンティックレイヤーの完全な機能は現在、dbt CloudのTeamまたはEnterpriseのパブリックベータ版のみ利用可能である。
dbt Cloud Developerプランと dbt Coreユーザーは、MetricFlowを使用してローカルでメトリクスを定義およびテストできるが、統合ツールを使用してメトリクスを動的にクエリすることはできない。

MetricFlowを利用したチュートリアルが用意されているので参考にすると良い。

3. `dbt clone`と`dbt retry`のコマンド追加

今回、新しくdbt cloneとdbt retryコマンドが追加された。
dbt cloneは、各データプラットフォームの機能を利用して、ある環境から別の環境にdbtモデルの軽量コピーを作成する（例：Snowflakeならゼロコピークローニングが利用できる）。新しい開発環境を迅速に起動する場合、または特定のモデルをステージング環境から運用環境にプロモートする場合に役立つ（例：テスト環境をコストをかけずにサクッと作りたいときなどに役立つ）。
利用方法としては、クローン元のマニフェスト（通常ならtarget/manifest.jsonに存在する）をコピーし、適当なフォルダに複製（例えばartifacts/manifrst.jsonとして配置）する。
その後、プロファイル（~/.dbt/profile.yml）をクローン先の別のスキーマ（例えばPUBLICからDEV）に書き換えるなどした後、dbt clone --state artifactsを実行すると、すべてのモデルがクローンされる（他のコマンドと同様に、モデル単位でselectも可能）

実行されたクエリの例（Snowflakeで実行した例）

create or replace
      transient
      table DAI_TRAINING_DB.DEV.my_first_dbt_model
      clone DAI_TRAINING_DB.PUBLIC.my_first_dbt_model

なお、ビューの場合は、クローンが機能として存在しないため、元のクエリと同じクエリが実行される。
詳細はドキュメントで確認すべし。

dbt retryは、以前に実行したコマンドを失敗した時点から実行する。最初からやり直すのではなく、前回の実行/ビルド/テストでエラーまたはスキップされたノードのみを再構築する（dbtの主要なコマンドであるrun,test,seed,snapshotなどに対応している）
現在は、dbt Cloudのみでサポートされた機能であり、今後ネイティブにサポートされる予定とのこと。

余談

アップデートの予定はどこで確認できるかというと、dbt-coreのリポジトリのdbt-core/blob/main/docs/roadmap/2023-02-back-to-basics.mdで確認できる。
今回リリースされたv1.6は7月にリリースすることが決まっており、次のv1.7は10月にリリースされる予定である(3ヶ月周期でリリースが予定されている)。

また、dbt-coreのマイナーバージョンのリリース時には、バージョンと共に有名なPhiladelphianの名前がつけられ、リリースノートには、その偉人に関連する伝記が紹介される

今回のv1.6では、西フィラデルフィア出身の劇作家である「Quiara Alegría Hudes」の名前がつけられた

なぜPhiladelphianの名前をつけるのか詳細は説明されていない（もしかすると、dbt Labsの創設者兼CEOのTristan HandyがPhiladelphianであり、地元の偉人を紹介してPhiladelphiaに興味を持ってもらうために設けた習慣かもしれない）

さらに余談として拙者のPRがマージされて今回のv1.6でリリースされたのも嬉しいので報告する。（v1.6のリリースノートから確認できる）

残念ながら上に述べた重要なアップデートには関係しないPRでござる（無念）

終わりに

ちゅらデータでは、クレイジーな仲間を募集しているでござる
データエンジニア、もしくはSE系からデータエンジニアになりたい方がいればぜひ、御仁の力量に応じたグレード（ジュニア/ミドル/シニア）にて、応募するでござる