為什麼我們需要 dbt？我們真的需要它嗎？

今天又在 Medium 看到這篇 No, Data Engineers Don’t NEED dbt.，在談論到底需不需要 dbt。

近年在資料領域會一直看到各種討論，很多人吹捧 dbt 的強勢之後，又會有人緊跟上來說過譽，基本上什麼領域、什麼話題，應該都會遇到很類似的情況。很多時候在決策階段，吸收了過多的資訊，反而會迷失其中。

很唐突地，跟大家推薦最近看的一本書—『選擇的弔詭：選錯，沒你想的糟！』裡面就提到雖然總是會說選擇越多，越自由，但過多的選擇其實會帶來反效果，讓人無論在選擇前後都提心吊膽擔心自己做錯或錯過。

在 dbt 這一題，我覺得重點是要回歸本質，看看團隊的資料架構，以及團隊的資料服務的群眾、需求、目的等。

如果想要高大上一點，可以往高層次、更抽象的議題來思考：

• 資料的本質與價值：在當今的數據驅動時代，團隊如何看待資料的本質？資料是否只是過去的記錄，還是未來決策的基石？
• 團隊的資料哲學：團隊對資料的管理和利用是否反映其核心價值觀？如何確保資料驅動的決策與團隊使命和願景相一致？團隊是否擁抱資料民主化的理念？是否希望資料足夠透明，每個成員都能輕鬆訪問和理解資料，以促進更好的決策？
• 創新與變革的驅動力：資料處理的工具與流程如何成為團隊創新與變革的驅動力？在此過程中，dbt 是否能夠促進或阻礙這一目標？
• 技術的角色：在資料分析與處理的整體生態系統中，技術（如 dbt）扮演著什麼角色？這是否是團隊面對不斷變化的數據需求的長期解決方案？

找出團隊真正關注的議題，評估原先的資料處理模式與導入 dbt 的差異、優劣勢，以及導入的人力成本等。

不過其實我更喜歡思考一些白話版本的問題，我覺得白話版本的問題更能幫助我推進思考，當然可以在想完之後再包裝一下，讓問題看起來更精緻：

• 資料真的重要嗎？：我們的資料對於做決策有多大幫助？現行的機制提供的資料有遇到什麼痛點嗎？我們的資料品質有被挑戰過嗎？還是大家其實不太在意，只是當作例行公事？
• 我們有多少資料？：我們的資料來源有多複雜？現行的機制是否需要花很多人力與費用來整理和分析？轉換的流程常出錯、需要人力維護嗎？
• 資料使用方便嗎？：現在團隊中的每個人都能輕鬆找到和理解資料嗎？討論的時候會常受到對資料長相理解不清楚而有困擾嗎？
• 我們需要協作嗎？：團隊之間的合作有多重要？我們是否需要一個更好的工具來協助共同處理資料？我們使用的工具（像 dbt）能否提高我們的工作效率，還是只是增加了更多麻煩？

在思考的過程中，可以更專注於發掘 dbt 的特典，套用回團隊現在的狀況，像是：

• dbt 在使用 SQL 轉換資料特別有優勢，團隊目前都是用 SQL 做資料轉換嗎？
• dbt 提升資料一致性，增進品質，同時也需要不少心力來維護測試，團隊在意嗎？願意或有這個心力來維護嗎？
• dbt 在資料架構上有清楚明確的指示，協助我們將資料庫變得更為規格化，以清楚的規範來管理整個團隊的資料、而非只有特定夥伴有清楚的掌握，任何人接手後都較能輕易上手，但也未必說這個模式與規範是最好的。目前團隊在資料架構上進展到哪個階段？轉換至 dbt 的模式來處理是否耗費大量心力，會不會其實原本的模式團隊都很習慣、也足夠好用了？

提了幾個思考點作為範例，dbt 的優點並不是決定要使用就會出現的，就像遊戲中也沒有全能的裝備，不同的角色會有最適合自己的裝備，要去評估戰況、評估裝備的特點，才能去選擇最適合自己的裝備。

在導入 dbt 的過程中，不敢說跟當初的想像一模一樣（畢竟這個系列文章就是在講跟當初想像不一樣的部分ＸＤ），但至少在方向上，有往我們期待的理想前進一大步。