原因
stg_users.sql の SQL コメント(--)内に Jinja テンプレートの記述が含まれていたことが原因です。
-- 例: {{ convert_mongo_timestamp('RAW_DATA', 'created') }} AS created
SQL の -- コメントは Jinja にとってはコメントではありません。{{ ... }} は通常どおりマクロとして展開されます。
その結果、コンパイル後の SQL ではマクロの出力がコメントの外に展開され、構文エラーを引き起こしていました。
コンパイル結果(壊れた状態)
-- 例:
CONVERT_TIMEZONE( -- ← コメントの外に出てしまった
'UTC',
'Asia/Tokyo',
RAW_DATA:"created":"$date"::TIMESTAMP_NTZ
)::TIMESTAMP_LTZ
AS created
-- まずは生SQLで書いて...
マクロの出力が複数行にわたるため、1 行目の -- 例: だけがコメントとして扱われ、2 行目以降がそのまま SQL として解釈されました。
解決方法
{{ ... }} を Jinja のコメント記法 {# ... #} に変更しました。
-- Before(Jinja が展開してしまう)
- -- 例: {{ convert_mongo_timestamp('RAW_DATA', 'created') }} AS created
+ -- 例: {# convert_mongo_timestamp('RAW_DATA', 'created') #} AS created
{# ... #} で囲まれた部分は Jinja のコメントとして完全に無視されるため、コンパイル後の SQL に余計な出力が混入しなくなります。
まとめ
| コメント記法 |
Jinja の {{ }} {% %} を… |
SQL コメント --
|
展開する (Jinja はそのまま処理する) |
Jinja コメント {# #}
|
無視する (コンパイル結果に出力されない) |
dbt の SQL ファイル内で Jinja 構文をメモやサンプルとして残したい場合は、必ず {# ... #} を使いましょう。SQL コメント -- の中であっても {{ }} や {% %} は Jinja エンジンによって処理されます。
参考