接著來討論這整段 pipeline 的費用監控。如果看了這整個系列的文章，應該會看到蠻多地方在討論費用的部分，為了省錢，雖然沒有到無所不用其極，但也是在開發上付出了不少心力來維護呀。

正因為花了不少心力，「結果省了多少錢？」這個問題就變得格外重要，必須要好好跟老闆交代才行。

這篇先介紹我們監控了哪些服務的費用。

先前有提過我們的資料架構，主要由 Airflow, Cloud Storage, BigQuery, Metabase 組成，而目前還導入了 dbt。

而在這些服務中，需要監控費用的，主要是 Cloud Storage 的儲存費用、BigQuery 的儲存與運算費用。Airflow 的部分也有例行的報表在監控，但他基本上就是服務的費用，不太受到資料轉換量體等等而有劇烈的費用差異，我們針對 Airflow 的監控主要是針對它運行的工作是否有遇到錯誤情況。

為什麼沒有提到 dbt 跟 Metabase 呢？撇除機器的維運費用之外，這兩個服務的運行都是呼叫 BigQuery 的運算服務來進行，因此統一算入 BigQuery 之中，後續會討論我們怎麼來區辨不同服務的費用。

Cloud Storage 費用

我們在 GCS 中有很多 bucket，每個 bucket 有自己的儲存設定，像是針對我們資料庫的備份，若無特殊需求，則會在一定時限之後，轉為冷儲存，後續再一段時間後，進行刪除。

可以看到官方文件中的 Storage classes 介紹，將儲存分成 Standard, Nearline, Coldline, Archive 等不同的儲存類別，而他們的 SLA 及可用性就略有差異，而最主要是費用也有所差異，每個等級都是翻倍的差異，具體差了多少可以參考這份文件。

而單純顯示出我們的花費其實沒有多大的幫助，畢竟資料儲存是絕對必須要進行的，該花的錢就是要花啊，數據指標要是無法推進現狀的改善，只是呈現目前情況，就沒什麼意義。

因此，我們在這個監控資訊中，加入了長久以來沒有資料更新的 bucket list，因為通常資料應該會持續進行備份，若一直沒有人輸入新的資料，通常那個 bucket 應該是沒有人在使用了，我們就可以定期檢視是否有棄置的 bucket 可以來進行大掃除，除了節省成本之外，也能保持資料庫的乾淨，確保不會有舊時代的遺物被拿來使用。

下一篇我們再延續討論重頭戲 —— BigQuery 的部分吧！