要在 dbt 的開發流程中進行除錯，老實說，比 BigQuery 麻煩許多。畢竟除了 BigQuery 之外，其他的工具都是 call BigQuery 的 API，再將它回傳的訊息做 parsing，來讓使用者知道他們錯在哪裡。

還是 BigQuery 最乾淨俐落。

過去使用第三方工具串接時就有遇到障礙，像是在 Metabase 中，我們沒辦法知道實際的運算成本，而當錯誤發生時，也需要多花一些心神來理解錯誤。

像是以下這個錯誤就是指在 query 的第三行中，預期要結尾的地方卻出現了一個未知的 a，導致執行出錯，看起來蠻單純的，但已經比 BigQuery 的錯誤訊息複雜很多。

而更麻煩的是錯誤可能並非 query 本身，可能是 Metabase 與 BigQuery 的連線問題，或是運算的額度超過上限，等等其他問題都會干擾對於錯誤的判斷，而致使我們在開發時花費許多不必要的時間來處理錯誤。

而剛開始使用 dbt 時，我們發現它的錯誤訊息比這個更難理解。

印象很深刻，我們一開始花了大半個下午，在釐清我們到底遇到了什麼錯誤，最後發現是在使用 dbt 內建的 date_trunc 函式時，不同的資料倉儲中，參數的位置是相反的（如文件）

現在想起來蠻好笑的，我們會遇到這樣的問題，不是因為我們當時太遜（也可能是啦），而是：錯誤訊息標示的位置與 dbt model 的位置不相同。

什麼意思呢？

dbt 的 code 會出現在幾個地方：

1. sql file in models folder：你編寫的 sql 檔案，但由於 dbt 可以使用一些自定義的函數、jinja 語法、引用 macro 等情境，因此這份檔案並非純粹的 sql code，無法直接複製貼上到 BigQuery 上執行。
2. compiled code：dbt cloud 跟 dbt core 都有個按鈕，可以將上述的檔案轉譯成實際可執行的 sql code，方便我們去檢查，或是抓去 BigQuery 上執行。
3. sql file in target folder：在執行完 dbt compile 指令後，它會在 repo 中的另一個名為 target 的資料夾中生成一份 sql code，這個 code 跟上述第二點的差異在哪裡呢？這一份 code 中，包含了 DDL (Data Definition Language)，也就是會包含 create or replace table … 這一段文字。

而剛才說到的錯誤訊息，就是針對第三個 sql file in target folder來顯示的，因此行數上就會與上面兩個平常開發會看到的檔案行數不相同。我們當時就是因為沒有理解這個差異，在破解錯誤的過程中走上了歪路，越走越遠的。

這個在除錯時發生的問題，是我這幾天突然回想起來的，想起當時的鬱悶感，覺得可以跟大家分享一下，當時的標示不像現在十分清楚，錯誤訊息中還有 target 路徑下對應檔案的超連結，十分方便！