dbtで整えたデータを、その先の仕事へ。

モデルと、その依存関係とテストの置き場所はdbtです。ActQLは、そのモデルが作ったデータを、DWHの手が届かないシステムへ届けます。CRM、サポートデスク、スプレッドシート。そして、そちらのデータをモデル側へ持ち帰ります。両者の組み合わせには、2つの向きがあります。

dbtが作ったモデルを使う

たとえば、dbtがSnowflakeに usage_30d を作っているとします。取引先ごとに1行、アクティブユーザー数と利用の傾向が入ったモデルです。ActQLから見れば、このモデルも普通のテーブルなので、1つのプログラムでSalesforceの取引先とJOINし、結果に対して処理できます。

SELECT a.id, a.name, u.active_users, u.trend
FROM salesforce.accounts AS a
JOIN snowflake.usage_30d AS u ON a.id = u.account_id
WHERE u.active_users < 5 AND u.trend = 'down';

CLIから実行すれば、結果は表で返ります。|> EFFECT UPDATE salesforce.Account … を足せば、同じプログラムがフィールドを書き戻します。書き込みの前には、変わるレコードと値を表示してCheckpointで止まります。判断が必要なら |> INFER も加えられます。このJOINをエンジンがどう計画するかは、トップページのAny scaleに載せています。

この向きにはアダプターは要りません。ActQLは、モデルが置かれているDWHをConnectorで読み、JOINはできる限りSnowflake側にPushdownします。

dbtのモデルをActQLで実行する

モデル、ref()、source()、テスト、マテリアライゼーション、インクリメンタルといった、いつものdbtの使い方はそのままに、実行の裏側をActQLにできます。するとモデルがシステムをまたいで読めるようになります。Salesforceの上に置くステージングモデルや、DWHとSaaSのAPIをJOINするマートです。dbt-actql自体は、SalesforceやPostgresのことを知りません。それはActQLのConnectorとプランナーの役目なので、Connectorが増えてもアダプターは複雑になりません。なお、アダプターがあることと、dbt Platformで公式にサポートされることは別の話です。

いま動く範囲：dbtのquotingをオフにしたプロジェクトで、モデルが SELECT か、マテリアライズ済みの ref() に対するPipeクエリであれば、コンパイル済みのdbt SQLはそのままActQLに受理されます。ephemeralモデルに対するPipeクエリ、ダブルクォートの識別子、モデル内の INFER はまだ受理されません。

ビルドと操作は分ける

モデルは dbt build を実行するたびに作り直されます。外部への操作は、そうであってはいけません。CRMの更新やメール送信のような外部への書き込みは、モデルの中ではなく、完成したモデルを読むActQLのプログラムに置き、そのプログラム自身のトリガーと承認で動かします。こうすれば、ビルドをやり直しても何も再送されません。

dbtと何が違うのか

置き換えではありません。dbtは1つのDWHの中でデータを変換し、モデルの正しさを保ちます。ActQLはシステムをまたいで読み書きし、外部への書き込みをすべて検査と承認のできるEffectとして扱い、途中で止まったRunを復旧します。仕事がDWHの中で終わるなら、dbtだけで十分です。

dbt
 ↓
dbt-actql
 ↓
ADBC
 ↓
Flight SQL
 ↓
SQL
 ↓
ActQL
 ↓
cross-system physical execution

近日公開予定です。