iT邦幫忙

2024 iThome 鐵人賽

DAY 12
1
AI/ ML & Data

這跟文件說的不一樣!從 0 到 1 導入 dbt 的實戰甘苦談系列 第 12

DAY 12 Incremental 跟文件說的不一樣!談何時該用增量模型

  • 分享至 

  • xImage
  •  

incremental models!(文件

簡單來說就是從原本的 create or replace table 變成 insert into table,在這樣轉變的過程中,優勢是,我們可以只更新新進來的資料,不需要去重新運算已經處理過的資料。

這個操作我們過去使用 BigQuery procedures 時也有使用。

然而這個做法其實也有蠻多麻煩之處的,首先它的寫法與原先的整張表重新建立不同,需要重新編寫。
或是譬如在增減欄位或調整運算邏輯後,需要重新處理整張表格。
還有要如何確保只抓到未更新過的資料。

dbt 的 incremental models 提供我們一個方法,透過 config 與 macro 的設定,我們可以用同樣的 sql code,僅加上一些參數的設定,就讓這些資料表,若是不存在時,自動以建立資料表的方式處理,當有資料時,可以根據資料更新狀態,將未更新的資料新增進資料表中。

講到這邊,可能會覺得為什麼要做這麼複雜,直接砍掉重練多輕鬆呢。

錢啊!還得是錢!處理越多資料就越貴、也越花時間,一切都是為了省時省力省錢(好像沒有省到力?)

dbt 算是有幫忙到以事半功倍的方法做到這件事。

一張資料表,主要是 fact table(因為只有它適合以時間來做切片),必須在運算時省到錢,有兩個情況:

  1. 在建立這張表,改成使用 insert 的方式加入資料,上游只讀取更新部分的資料,而必須做到這件事情,就必須使用 partition功能(BigQuery 文件),將資料以 ingestion time 或是 created time 來去做每小時、每日或每月的切分。
    我們的日更資料表原先要讀取數年的資料,現在變成只要讀取這兩天新進來的資料,省下大把的運算成本!
  2. 這張表被下游使用時,只讀取部分區間的資料,譬如說規定下游在進行視覺化時,盡可能只使用特定區間的資料,可能是這個月、或這個學期等。

這兩個情況,通常第一點會節省的幅度較大,因為原始資料的量體應該遠大於轉換後的資料表,而要省到這筆成本,必須將上游的原始資料 (source) 做 partition。這塊可能就要看資料 ingestion 的方式了,我們正好有跟軟體協作,針對比較大的事實表格,改以每日新增資料的方式處理,將資料以新增的日期來做切分;另外也正在進行將實時串流資料以 ingestion time 的日期做切分,可以滿足這一個條件。

第二點有時候也很實用,尤其當資料表會被高頻率讀取時,像我之前處理的服務中,有每幾分鐘就要讀取資料的情況,有 partition 就幫了大忙;或是在多數不特定人常常使用的公開資料的情境中,也很有幫助。

總結來說,如果上游資料表沒有 partition,下游也沒有很頻繁的取用資料的話,或是這張資料表轉換完畢後,量級已經比原始資料小很多的話,做成 incremental model 就沒有這麼大的意義了。


上一篇
DAY 11 Evaluator 跟文件說的不一樣!談如何評估專案完成度
下一篇
DAY 13 Incremental 跟文件說的不一樣!談增量模型怎麼省不了錢?真不是 BUG?
系列文
這跟文件說的不一樣!從 0 到 1 導入 dbt 的實戰甘苦談30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言