• On-Demand：每掃描 1 TB 收費約 $7.19 美元，不查詢不收費
• Editions：2023 年新架構，分 Standard、Enterprise、Enterprise Plus，支援自動擴縮
• Flat-rate 已經沒有再提供，請以 Editions 為主。

官方說明參考這份文件，以下逐一拆解。

1. BigQuery 計費的核心單位：Slot 是什麼？

Slot 是 BigQuery 的虛擬 CPU 單位，代表查詢執行時可用的運算能力。BigQuery 執行查詢時，會自動把工作分散到多個 Slot 並行處理，Slot 越多查詢越快。

Slot 中文叫運算單元，在大陸叫”槽”。

根據 Google 以前的公開文件 1 槽 (Slot) = 0.5個 vCPU和 0.5GB 的記憶體。

但後來可能由於硬體效能提升，後來隱藏了這個數據。

Slot 不夠用時會發生什麼事？

On-Demand 模式下，BigQuery 提供每個專案共享的 Slot 資源池。當同一專案內有多個大型查詢同時執行時，會出現排隊（Queuing）的情況，導致執行時間延長。

Flat Rate 或 Editions 模式下，你買多少 Slot 就用多少，不會自動借用額外資源。

2. 隨需計費（On-Demand Pricing）深度解析

查詢費用的計算方式

• 計費單位：每掃描 1 TB 收費約 $7.19 美元（台灣區域 asia-east1）
• 最小計費單位：10 MB，就算你的查詢只掃描 1 MB的資料，系統仍以 10 MB 計算
• 計費基礎：查詢實際讀取的欄位資料量，不是整張表的大小
• 要注意，如果你的表格有 100,000 資料，即使你查詢使用 Whare 或 Limit 語法，只撈出 10 筆資料，它還是讀取 100,000 筆資料，除非你有做分區表（後面詳述） 。
• 每個月前面 1 TB 屬於免費額度，超過 1 TB 的資料量才開始計費。
• 可參考 GCP 價格計算機的數據：

使用 Dry Run 預估費用

執行查詢前，可用 Dry Run 模式預估掃描量，完全不收費。

操作方式：

在 BigQuery 主控台，點選「More → Query settings → Dry Run」；或在 CLI 使用 --dry_run 參數，系統會直接告訴你這次查詢預計掃描多少 Bytes。

另外，BigQuery 主控台的 SQL 編輯器右上角，每次寫完查詢都會顯示「This query will process X GB」。執行前先看這個數字，是控制費用的第一道關卡。

3. BigQuery Editions：新版計費方案全解析

以前 BigQuery 提供 Flat Rate，有別於 On-Demand 像計程車跳錶，每掃描一點資料收一點錢；

Flat Rate 像月租車，費用固定，查詢不另外計費。

2023 年，Google 推出 Editions 架構，重新定義 BigQuery 的計費方式。

Standard、Enterprise 與 Enterprise Plus 比較

Editions 和舊版 Flat Rate 最大的差異

舊版 Flat Rate：Slot 數量固定，資源無法自動調整。

如果你買了 100 個 Slots (運算單元)，那這 100 個單位就是專屬於你的，即便你的工程師下班了、資料庫閒置在那裡，你還是要付這 100 個單位的完整費用。

Editions：引入 Autoscaler，查詢量高峰時自動增加 Slot，閒置時自動縮減，不再需要猜測最高需求來決定購買數量。

正因為計費邏輯從「買斷固定數量」變成了「按實際彈性用量付費」，所以你在設定 Reservations (預留項目) 時，會發現 Google 不再給你一個「固定 100 Slots 的總價」。

系統現在只會讓你設定一個 Max Reservoir Size (預留項目大小上限)，這就像是幫你的信用卡設一個「單筆消費限額」，防止自動擴充得太過火導致帳單爆炸。

既然實際支出是根據每分每秒的波動累積起來的，那份試算表列出的 25%、50%、75% Utilization (使用率)，其實是在幫你估計：如果你的業務平均負載在這些水位，你月底大概會收到多少錢的帳單。

之所以沒有列出 100% 的費用，是因為在 Autoscaling (自動擴充) 的機制下，除非你的查詢量大到 24 小時都把這 100 個 Slots 佔滿，否則你幾乎不會付到 100% 的錢。

這也是為什麼你看到 Baseline (基準運算單元) 的選項會被設為 0 或較低的數值；Baseline 代表「無論如何我都要保有的最低戰力」，如果你的 Baseline 設得越低，系統在沒事做的時候就能縮得越小，省下更多費用。

你可能會問， On-Demand 的都直接去使用 Enterprise (企業版) 的 自動擴充 (Autoscaling) 功能就好了，反正沒有用就沒費用，有用還比較便宜，對嗎？

BigQuery 隱藏的「計費邏輯」

BigQuery Edition 並不一定比原本的 On-demand (按需求計費) 便宜，因為計費單位的根本不同：

在 On-demand (按需求計費) 的模式下，Google 是看你的 SQL 指令「掃描了多少資料量」來收錢。

BigQuery Edition ，計費的標竿就完全改變了，系統改為計算你「使用了多少運算力（Slots）以及用了多久（時間）」。就像搬家「按出動的人力和時間算錢」一樣。

哪一種比較划算，完全取決於你的行李（資料）長什麼樣子

首先要考慮你原本 On-Deman 的每月費用是否超過 2,000 美元，這種用量在台灣通常是大企業才要考慮。

如果你的查詢語法寫得不夠有效率，導致系統需要動用大量 Slots 埋頭苦幹很久，那麼在 Enterprise (企業版) 下產生的費用，反而有可能會超過原本的 On-demand (按需求計費)。

如果你的工作負載（Workload）是屬於那種「掃描資料量極大，但運算過程很簡單」的類型，Enterprise (企業版) 可能會顯得非常划算；反之，如果你的資料量很小，但 SQL 邏輯複雜到讓系統算到滿頭大汗，那 On-demand (按需求計費) 反而可能是你的省錢好朋友。

Commitment 承諾方案的折扣

既然叫做「承諾」，就是不管你有沒有用 Slots，你每個月都要支付固定的費用。

這是和上述 BigQuery Editions 最大的不同。

資源型承諾 (Resourced-Based CUD)：折扣最深但相對固定

從上方表格最右側兩欄看到，你會發現 Resource CUDs 的價格較低，因為你給 Google 的承諾非常死，讓他們能非常精確地預估硬體採購和機房調度，所以他們給出的折扣也最慷慨，3 年期的價格甚至能讓你省下將近 40% 的費用。

然而，高折扣的代價就是「專款專用」。當你簽下 Resource CUDs 時，通常需要鎖定特定的 Slots (運算單元) 數量以及特定的 Region (區域)。

這對於已經進入穩定營運期、且每天運算量都像心電圖一樣平穩的老牌公司來說是首選，因為他們很清楚自己每小時就是要燒掉這麼多 Slots，直接選這個方案最省錢。

支出型承諾 (Spent Based)：靈活但折扣較淺

表格左側數過來第二、三欄就是支出型承諾，2026 年才正式上線，例如「我保證接下來一年，每小時一定會在這裡消費 100 元」。

不論你的 Slots (運算單元) 是在台灣還是在日本執行，或者你今天用的是 Enterprise (企業版) 還是 Enterprise Plus (企業加強版)，這份承諾都能幫你折抵支出。因為它給了你極大的轉身空間，所以 Google 給你的折扣就相對比較小，大約是在 10% 到 20% 之間。

這種適合那些業務還在變動、或者數據分散在多個 Regions (區域) 的團隊。

如果你今天還在測試哪一種 BigQuery Edition (版本) 最適合你，或者你擔心未來半年公司會把機房從台灣搬到其他國家，那麼鎖定這種以「美金金額」為單位的 BigQuery CUD，就能確保你的折扣不會因為換了環境就失效。

它就像一張通用的禮券，雖然面額折扣沒那麼多，但走到哪都能用，這就是它存在的最大價值。

4. 儲存費用（Storage Costs）完整說明

Active Storage vs. Long-term Storage

Long-term Storage 的降級是自動發生的，不需要手動操作。

降低儲存成本的策略

• 超過一年的歷史資料匯出到 Google Cloud Storage（GCS），費率比 BigQuery 低
• 使用 Table Expiration 功能，設定資料過期自動刪除
• 對大型表格採用分區設計，只保留必要分區在 BigQuery，其餘歸檔

5. 免費額度（Free Tier）

每個月的免費額度：

• 查詢：前 1 TB 掃描量免費
• 儲存：前 10 GB 免費
• 資料匯入：Batch Load 完全免費（這點常被忽略）

PS. 這個免費額度是完全不用註冊 300 美金試用的情況下，也可以直接使用的，可參考 BigQuery 免費沙箱。

6. 其他潛在費用

資料串流（Streaming Insert）費用

使用 Streaming Insert 把即時資料寫入 BigQuery，按寫入資料量額外計費。

原本只有 Steaming Inserts 這個方法，後來又提供 BigQuery Storage Write API，更為划算。

如果不需要即時性，改用 Batch Load 可完全省掉這筆費用。

BigQuery ML 計費

你會看到 BigQuery ML 兩類 Model 價差極大，為什麼？

• 線性回歸、邏輯回歸、K-means、PCA、時間序列等內建疊代模型：$312.50/TiB（台灣約 $359，依匯率與區域調整）。
• AutoML Tables、DNN、boosted tree、隨機森林等外部模型：僅 $6.25/TiB（台灣約 $7），因前處理用標準查詢費率，訓練轉 Vertex AI 但折算低。

差異原因

內建疊代模型需多次掃描資料（預設 50 次迭代），計算密集，故單 TiB 處理位元組計費高（有效乘以迭代次數）。

外部模型多依賴 Vertex AI，因為這類模型被稱為 External Models（外部模型）或 Vertex AI 整合模型。

這報價其實只是一個「過路費」或是「代工準備費」。

BigQuery 只負責把數據整理好（這個過程稱為 Preprocessing 預處理），一旦數據準備好了，它就會把這些資料打包，送到隔壁棟專門做 AI 的工廠——Vertex AI 去進行真正的訓練。

而 Vertex AI 的計費方式通常不是看資料量（TB），而是看它動用了多少台強大的機器、工作了幾個小時（這個單位叫做 Node-hour 節點小時），這才是真正昂貴的地方。

BigQuery BI Engine 費用

按 GB 小時計費，約 $0.0478 美元/GB/小時。BI 儀表板查詢頻繁時，這筆費用會快速累積。

7. 5 個實用的省錢技巧

7.1 避免 SELECT * 全表掃描

BigQuery 按掃描的欄位資料量計費。SELECT * 會讀取所有欄位，即使你只用其中幾個，費用照算。

一張有 100 個欄位的表格，只選取需要的 5 個欄位，查詢費用可降到原本的 5% 左右。

7.2 善用分區 (分割)（Partitioning）與叢集（Clustering）

分區：把大型表格按時間或其他欄位切分。查詢加上分區欄位的篩選條件，BigQuery 只掃描對應分區。

叢集：在分區之內，進一步按特定欄位排序資料。

搭配使用分區和叢集，查詢費用可降低 50% 以上。

7.3 設定查詢上限與預算警示

在 BigQuery 設定每個用戶或每個專案的每日查詢費用上限（Cost Controls），超過門檻查詢會被自動拒絕。

搭配 Google Cloud Billing 的 Budget Alerts，費用達到設定百分比時自動發送通知。

7.4 善用 Materialized Views

有複雜查詢需要反覆執行（例如每天計算一次彙總報表），改用 Materialized Views（實體化視圖）。BigQuery 預先計算並儲存結果，後續查詢直接讀取，省去重複掃描的費用。底層資料更新時，Materialized Views 也會自動更新。

7.5 定期評估是否切換 Editions

月費持續增長，超過 2,000 美元時，用 BigQuery Slot Recommender 分析歷史查詢記錄，評估購買固定 Slot 是否更划算。

8. 如何監控與管理費用

用 Google Cloud Console 查看帳單

Billing 頁面可按專案、服務、時間段篩選費用，找出費用來源。

設定預算與費用警示

在 Cloud Billing 的「Budgets & alerts」設定預算上限，達到 50%、90%、100% 時自動發送通知。這是避免帳單超出預期的基本防線，每個 BigQuery 使用者都應該設定。

常見問題（FAQ）

Q1. Slot 買了沒用完，會退費嗎？

BigQuery Editions 的承諾費用固定收費，不論實際使用多少 Slot，費用照算。

Q2. SELECT * 真的會讓費用變很高嗎？

是的。BigQuery 依照掃描的欄位資料量計費，SELECT * 讀取所有欄位，就算只用少數欄位費用不變。改成只選必要欄位，有機會省下 80% 以上的查詢費用。

Q3. 如何查看每個查詢花了多少錢？

透過 INFORMATION_SCHEMA.JOBS_BY_PROJECT 查詢歷史記錄，欄位 total_bytes_billed 乘以當前費率即可估算費用。也可搭配 Cloud Billing Export，把費用明細匯出到 BigQuery 做深入分析。

Q4. BigQuery 資料匯入需要付費嗎？

Batch Load（批次匯入）免費。Streaming Insert（串流寫入）按寫入資料量額外收費。

Q5. 如何預防帳單突然暴增？

三管齊下：設定每個用戶的查詢費用上限（Cost Controls）、在 Cloud Billing 設定 Budget Alerts、定期審視使用量報告。

The post BigQuery 計費方式完整介紹：費用結構、自動擴充與省錢技巧全攻略 first appeared on 東東 GCP 教學 - GCP 實戰講師 - 雲上星辰有限公司.

BigQuery 是 GCP 的企業級資料倉儲服務，它可以快速處理結構化和非結構化資料，並提供即時查詢和分析功能。

它主要針對需要分析大量資料的企業所設計，例如電子商務平台、遊戲公司、媒體公司和金融服務公司等等。簡述 BigQuery 的優勢如下：

(一) 再大的資料都能即時高速處理與查詢

BigQuery 能在幾秒鐘內處理數百億行數據，這對於需要快速決策的企業來說至關重要。它的分散式架構允許你同時查詢和寫入資料，完全不需要等待。

而且無論是幾百 GB 的數據，還是幾 PB 的數據，BigQuery 都能輕鬆處理。它的擴充能力確保即使你的業務需求增長，你的資料分析能力也能跟上。

(二) 串接各種資料來源

BigQuery 自問世以來，便極力整合巿面上各種服務，尤其是針對第三方的資料來源，開發了各種連接器 (Connector) 來串接，直接省去你手動傳輸的工作，非常方便。

建議你可以先查看官方文件，也許你的資料來源已經內建整合 BigQuery 的功能喔！

(三) 無伺服器容易上手

使用 BigQuery 根本不用開機器，直接倒入資料就可以開始分析，光是這一點就足以輾壓巿面上各種分析工具。而且你只要使用 SQL 語法就能分析出結果 (如第一張圖片)，不用重新學習新的語法，對使用者非常友善。

基於以上特色，BigQuery 在世界各地早已經有各大知名企業使用，最知名的就是 Twitter (現在叫 X)，而在台灣像是知名的社群數據分析公司 QSearch，在 8 小時內可以分析 432 億筆資料。痞客邦 幾10秒就查完 60 億筆資料。

其他成功案例還有 KKBOX、東森新聞雲、大數據(網路溫度計)、旋轉拍賣 Carousell、智生活、UDN 聯合新聞網、 QBurger、Freshworks、Blibli 等等，族繁不及備載。

二、資料上傳到 BigQuery 的方法介紹

BigQuery 支援多種上傳資料的方法和工具，方便企業處於各種不同情境，都能夠找到方法把資料匯入 BigQuery，分述如下：

(一) 手動匯入檔案

1. 從本機上傳 CSV 檔

假如你剛開始使用 GCP，你可以先在 Console 上面手動匯入一筆小量的資料，我這裡先準備一個 CSV 檔案，內容是 GCP 的帳單明細。如果你想用我的資料測試看看，也可以從這裡下載。

這裡要注意如果第一列是你的欄位名稱，務必要確保它是小寫英文字母開頭，後面是可接英文和數字，如果有空格請使用底線，萬一沒有按照要求來匯入資料，就會失敗喔！

我們先到 BigQuery 的主畫面，然後點擊「建立資料集」，也就是 Dataset：

點擊之後，馬上跳出側邊視窗，先設定 Dataset ID，注意不能用 “-” 而是要用 “_”。另外 Dataset ID 並不像 Cloud Storage，使用全球獨一無二的 Bucket ID，你可以設定任何的 Dataset ID。

在位置部分，和 Snapshot 或 Image 一樣，你可以設定單一地區或是多個地區的儲存位置。

下方有一個預設資料表到期時間，通常我們不會去設定，因為萬一時間到了，整個 Dataset 的資料都會刪除乾淨。除非你很確定只是短期使用，再做這個設定。

確認沒問題的話，就可以點擊「建立資料集」。

接下來你會看到左邊已經產生剛剛建立的 Dataset，並在右邊視窗看到相關資訊，我們再點擊「建立資料表」：

接著跳出側邊的視窗，我們在來源部分點擊下拉選單，選擇來源為「上傳」。

同時你也會看到它可以從各種不同來源來建立資料表，例如 Cloud Storage、雲端硬碟、Bigtable 甚至 AWS 的 S3 和 Azure Blob Storage 都可以是匯入資料的來源。

接著跳出上傳檔案的視窗，選擇我的 CSV 檔案之後，BigQuery 自動偵測要匯入的檔案格式，自動秀出 CSV。

我們再輸入要建立的表格名稱，接著不要急著按下「建立資料表」喔！我們再來看一些重要參數。

結構定義就是 Schema，指的就是這張表格的結構，包含欄位名稱和資料格式，例如文字叫 STRING、日期叫 DATE 等等，還有欄位是否可以為空 (NULLABLE) 還是必填 (REQUIRED)。

你可以點擊「以文字形式編輯」，手動一個一個欄位設定。如果你是初學者，不知道如何設定的話，可以直接勾選「自動偵測」，BigQuery 會自動幫你偵測內容，選擇一個適合的格式。

如果你是專業的資料數據工程師，請務必手動設定欄位，確保它的格式符合你後續的分析工作。 

接下來的「分區」下拉式選單，是因為 BigQuery 有所謂的分區表 (Partitioned Table)。

因為 BigQuery 一般的表格，每次都是查詢整個表格，即使你只撈出一點點資料，但它仍然會以整張表格的資料量計費，這樣很容易就花費不少錢。

而分區表的設計，可以讓你設定撈取資料的日期範圍，當你使用相同語法來查詢時，它只會依照日期範圍的資料量來計費，而不是整張表格計費，節省不少成本。

我們目前的資料量不大，可以保持「無分區」就好。我們再往下展開進階選項。

進階選項展開後，第一個是「寫入偏好設定」，如果你的表格本來有資料，你可以決定要繼續新增 (附加到資料表中)，或是把原本資料蓋掉 (覆寫資料表)，而我們是建立新的表格，所以選哪一種都可以。

而「允許的錯誤數量」很重要，指的是你對於這個匯入動作，是否要求必須每一筆都格式正確。

如果是，你就設成 0，但你要注意，在匯入過程中，只要偵測到一筆資料有問題，你就必須「全部重新匯入」，即使你已經匯入 100 萬筆資料。

這就會導致你浪費前面所有的時間，你可以視情況「把允許的錯誤數量」調高一點，例如資料筆數的 1%，否則你就必須保證資料格式完全正確。 

至於「要略過的標題列數」，就像我前面準備好的 CSV 檔，第一列是欄位名稱，所以我就在這裡輸入 1，確保它不會把欄位名稱也當成一筆資料，如果你的原始資料並沒有欄位名稱，就保持 0 就好。 

其他選項就保持預設，然後按下建立資料表。

幾秒鐘後，會看到系統提示資料表建立完成的訊息，我們可以直接點擊「前往資料表」： 

13 系統提示表格建立完成，點擊前往資料表

資料來源：擷圖自 GCP 主控台

畫面跳轉到我們建立完成的表格，你可以看到 BigQuery 自動偵測的欄位名稱和資料類型。 

我們點擊「詳細資訊」，可以看到表格的一些基本資訊，例如表格的完整 ID、建立時間、位置、表格的大小和資料比數等等。 

我們在點「預覽」，可以看到表格前面幾列的內容。

要注意 BigQuery 是按照查詢的資料量來計費的，如果你想探索資料，不要動不動就 「Select * from 某個 Table」，這樣是會被計費收錢的喔！

這個方法要注意，只能上傳最大 100 MB 的檔案，再大就無法上傳了。

2. 從 Google Drive 匯入 BigQuery

這個方法可以上傳最大 10GB 的檔案，所以先上傳到這裡比較方便。 但它只限 Google 試算表，不能匯入 CSV 檔案喔！

你可以直接在檔案上按右鍵=>共用=>複製連結：

然後貼到「選取雲端硬碟 URI」欄位中：

比較特別的地方是，你可以指定匯入的資料範圍，不一定要全部匯入。我們選定資料範圍後可以複製左上角的座標： 

然後貼到工作表範圍：

其他的設定跟前面一樣，沒問題就按下建立資料表： 

完成後去查看表格，你會發現，你看不到資料量大小和筆數，是因為 BigQuery 並沒有把 Google 試算表的資料複製進來，而是當成外部的表 (External Table) 來用。

接著我們使用查詢來確認，看它是不是剛好 10 筆資料。我們開啟新的分頁：

它把前面欄位的部分空著，我們直接輸入「 * 」代表所有欄位，並且把「 LIMIT 1000」刪除，確保它能夠秀出所有資料，接著按下「執行」：

你會到剛好 10 筆資料的查詢結果，代表即使試算表有 100 多筆資料，但我們己在匯入時限制 10 筆的範圍，所以這裡就只能看到 10 筆。

關於資料不在 BigQuery 裡面的問題，不用擔心，接下來我們使用「撈出資料寫入表格」的語法來處理，我們開啟一個新的查詢分頁，然後準備以下語法：

沒問題就按下執行，因為這個語法是讓它直接執行寫入資料表的動作，是在背景作業，不會秀出資料給你看。所以我們再按「前往資料表」：

你會看到它沒有再秀出「外部資料設定」和「來源 URI」，而是直接秀出資料筆數和佔用空間大小。 

代表它已經是 BigQuery 本身的內部表格喔！

3. 從 Google Cloud Storage 匯入檔案

假如你的資料超過 10 GB，那建議先上傳到 Cloud Storage 再匯入 BigQuery，這樣最大單次能匯入 5TB 的檔案。

我用同個檔案來示範，首先我直接拖曳到 Cloud Storage 的 Bucket。

然後回到 BigQuery 建立資料表，按下「瀏覽」：

然後找到要匯入的檔案，再按「選取」。

順便提一下，它支援萬用字元 (例如: gs://bucket/data/*.csv)，代表你可以一次匯入多個檔案，但資料總量還是不能超過 5 TB 喔！

接下來看到「結構定義」，我們這次自己來挑選匯入之後的欄位格式。如果你使用我的範例檔案，可以參考下圖設定，其它類型可以查看官方文件。

然後按下「以文字形式編輯」，它會把設定轉換成語法，強烈建議你複製語法。

為什麼要多此一舉？

你剛剛手動設定欄位，一定花費很多時間。如果待會匯入發生錯誤，相同的動作你就要再做一次。

現在只有 6 個欄位就算了，如果正式的表格有 40 個欄位，你可能已經花了半個小時設定，結果匯入失敗要重來的話，你可能會懷疑人生。

如果你已經事先複製語法，你只要稍做調整就可以直接貼上，可以省去你大量的時間。 

接下來是分割設定，是因為 BigQuery 有所謂的分區表 (Partitioned Table)。

因為 BigQuery 一般的表格，每次都是查詢整個表格，即使你只撈出一點點資料，但它仍然會以整張表格的資料量計費，這樣很容易就花費不少錢。

而分區表的設計，可以讓你設定撈取資料的日期範圍，當你使用相同語法來查詢時，它只會依照日期範圍的資料量來計費，而不是整張表格計費，節省不少成本。

我們這次選擇「依欄位分割」，然後選取「use_date」欄位，並且勾選必須使用「WHERE 子句」來查詢資料。

目的就是要強迫使用者在查詢的時候指定時間範圍，如果使用者不使用這個語法，系統不會讓他執行，藉此降低查詢成本 。

接下來進階選項的部分跟前面一樣，你可以事情況設定「允許的錯誤數量」，以及「要列過的標題列數」，如果沒問題就按下「建立資料表」。 

建立完成之後你會看到系統提示「這是分區資料表」，你也會在下方看到「已分區」以及分區的欄位。 

關於更多從 Cloud Storage 匯入 BigQuery 的細節，可以參考這份文件。

我們將三種方法整理如下表，你可以視情況選用適合的匯入方法。

(二) 使用 Data Transfer Service 立即或排程匯入

如果你要正式傳輸大量資料到 BigQuery，推薦使用 Data Transfer Service（ 簡稱 DTS)。

它除了可以從地端的資料庫上傳之外、也支援從 Google 相關的行銷平台如 Google Ads、Ad Manager 和 Google Play，甚至其他雲端如 AWS S3 Storage、AWS Redshift、Azure Blog Storage、Salesforce 等，更多資料來源可以參考這份文件。

針對不同來源，操作方法都差不多，我們就以 AWS S3 Storage 來源為例子，說明步驟如下。

我們先從 BigQuery 主選單進去，找到「資料移轉」再建立「移轉作業」： 

接下來從「來源類型」點擊下拉式選單，你會看到它有非常多的來源可以選擇，我們就直接選 「Amazon S3」： 

我們就來設定轉移的作業名稱，以及排程的執行頻率，例如每天執行一次就設定為 24 小時。 

在目的地設定，我們輸入轉入  BigQuery 的表格名稱。而在 Amazon S3 的資料來源設定當中，有兩個重要的欄位叫做 Access Key ID 和 Secret Access Key： 

我們就去 AWS 的主控台然後點擊右上角自己的 ID，進入安全憑證頁面：

接著點擊「建立存取金鑰」：

接著就進入到存取金鑰的頁面，它有提供 Access Key ID 和 Secret Access Key，如果你只是短暫測試，就直接將兩個值複製起來，不要下載 CSV 檔案，以免金鑰被駭客拿到。 

 Access Key ID 和 Secret Access Key 複製後貼入 DTS 的內容欄位。

另外 Write Disposition 指的是，你匯入資料後，要不要清除原始資料 (WRITE_TRUNCATE)，或是一直附加到表格的最後面 (WRITE_APPEND)。

而在傳輸選項的部分：

Number of Error Allowed

跟之前建立 BigQuery 一樣，如果資料量夠大，建議設定一些允許的錯誤，以免整個傳輸作業有任何一點錯誤，導致全部重來。

Decimal Target Types 

這是非常重要的欄位，指的是關於如何處理從 S3 中的 decimal (十進位數) 格式資料轉換到 BigQuery 時的資料型態轉換規則。

你可以先指定比較偏好的型態，再指定退而求其次的型態，最多三個。

在傳輸過程中，先用第一個型態來接收資料，如果接收到不符合這個型態的，整個欄位自動調整成第二個型態來接收看看，不行再改成第三個型態。

例如你有一個 decimal(38,9) 的欄位 (總共38位數，小數點後9位)，你先設定「NUMERIC, BIGNUMERIC, STRING」：

• 系統會先檢查 NUMERIC 是否能處理這個精確度 (這麼多位的數字)。
• 結果後來發現有一個數字太大，NUMERIC 不足以處理 (因為 NUMERIC 最多 38 位)，就會嘗試把欄位整個改成 BIGNUMERIC 繼續接收資料。
• 結果數字又更大，或是非數字的資料出現，BIGNUMERIC 也不行，最後會轉成 STRING，幾乎什麼格式的內容都可以接受。

這樣做的好處是：

• 避免資料傳輸中斷 – 不會因為突然出現意外的資料格式就失敗，不要全部重來太辛苦了。
• 自動調適 – 不需要事先精確知道所有資料的格式和範圍，如果你懶得事先指定格式，就給一個順序讓 DTS 自動判斷就好。
• 資料完整性 – 確保所有資料都能被正確保存，即使需要轉換成比較寬鬆的格式，寧可先收進來，格式後續再慢慢處理就好了。

Ignore Unknown Values

很容易理解，無法判斷的內容就直接略過，也可以避免因錯誤而中斷。

Header Rows to Skip

跟之前匯入 CSV 檔的操作一樣，如果第一列是標題就讓它略過。

最後服務帳戶的部分，要指定一個讓它能有權限代替你執行整個傳輸工作，你不需要事先研究要設定給這個 Service Account 哪些權限。

你直接指定一個帳戶給它，它會自動授予必要的權限角色給這個帳戶，當然你可以先產生一個不具備任何權限的服務帳戶，後面碰到權限問題再調整就好。

然後勾選「電子郵件通知」，這樣就不用時時進來確認進度。沒問題就按下「儲存」，它就會自動開始傳輸了。

整個設定如上，除了你可以在 Console 設定，如果你有安裝指令套件，也可以下 bq 指令；或是寫程式呼叫 API，或操作 Java 的 Library 都可以執行傳輸工作。

更多設定的細節可以參考這份文件。如果是從 Azure Blob Storage 來傳輸，也可以參考這份文件。

(三) 匯入串流資料

前兩種都是批次，代表一次性把資料匯入完成。

而串流資料是持續不斷產生的 (例如社群留言、股票報價、使用者點擊遊戲或工廠 IoT 設備回傳)，可能要即時處理和反應 (例如即時推薦商品或掉出寶物)，就必須使用串流資料的傳輸方法，依照複雜程度分述如下：

1. BigQuery Storage Write API

這個方法針對小規模、簡單的串流需求，直接從應用程式寫入資料，並且不需要複雜的資料轉換，最適合這種方法。

BigQuery 早期主要使用 tabledata.insertAll API。這個 API 的設計相對簡單，主要特性包括：

(1) 使用 REST over HTTP 通訊協定。

(2) 資料格式採用 JSON。

(3) 提供基本的串流寫入功能。

(4) 操作直觀容易上手。

但它同時也存在一些明顯的問題：

(1) 效能限制

．使用 REST over HTTP 通訊協定，傳輸效率較低。

．JSON 格式佔用較大的網路頻寬。

．屬於短期 Request，每個連接都有建立和關閉的動作，耗費系統資源且傳輸量受限。

(2) 資料一致性問題

．沒有完整的交易支援，例如有一部分失敗，不能全部倒回處理。

．無法保證資料的精確一次處理，可能出現資料重複的情況。

(3) 成本考量：

．資料傳輸成本較高。

．沒有免費用量額度。

而 Storage Write API 相對的優勢如下：

(1) 採用 gRPC 串流取代 REST over HTTP

雖然每個資料表最多 100 個連線，但這 100 個連線是持久的，可以持續使用，效能提昇不少。

(2) 資料一致性強化

它使用一個編號系統「串流偏移」(Stream Offset) 來追蹤每筆資料，當發現資料重複就不會傳送，提供「完全一次性」處理保證的選項。

(3) 成本效益

Storage Write API 提供每月 2 TiB 的免費擷取額度，而且 gRPC 串流能夠使用更少的資源來處理資料，提升資源的使用效率。

兩者比較總結如下表：

因此，如果需要高頻率的短期連線，可以使用 tabledata.insertAll API，如果需要穩定的長期資料串流以及資料一致性保證或交易支援，就選擇 Storage Write API。

2. Datastream

如果不寫程式，最好的方法就是使用 Datastream，它可以支援資料庫的即時同步，包含 MySQL、PostgreSQL、Oracle 等，如果來來源資料庫有變更，它也能同步到 BigQuery，也就是所謂的 CDC (Change Data Capture)。

設定步驟很簡單，首先進入Datastream 來建立連線設定檔：

我們真是 PostgreSQL 資料來為範例的資料來源，點擊 PostgreSQL：

我這裡沒有現成的資料庫，以下使用國外網友的示範圖片，輸入連線設定檔名稱和 ID，並且指定 Region：

接著輸入資料庫的 IP、Port、連線帳號、密碼和資料庫名稱： 

它有提供三種連線方式，我們選擇最簡單的 IP 白名單，這裡指的是允許地端的資料庫可以從Datastream 的 IP 連線過去存取資料。 

看到它跳出 IP 位址，直接複製起來貼到地端的防火牆去設白名單。

接著要測試連線，這裡一定要測試成功，才可以建立設定檔，所以上方的欄位不能隨便亂打喔！

若測試通過，就可以建立設定檔了。

接著畫面會秀出，我們剛剛建好的連線設定檔內容，我們回到上一層： 

我們要針對傳輸的目的地 BigQuery 也建立連線設定檔，點擊「Create Profile」： 

選擇 BigQuery：

設定名稱和 Region 並按下建立：

接下來就看到它設定完成了：

我們現在可以正式建立串流工作，點擊「Create Stream」： 

輸入串流的名稱、ID、Region、來源跟目的地： 

然後按「Continue」進行下一步：

在這裡我們選擇剛剛建立的 PostgreSQL 連線設定檔： 

在這裡我們一樣要測試一下資料庫的連線，成功後再按「Continue」：

在 Configure Source 中，我們要設定 Publication Slot Name 和 Publication Name。

這個 Slot 不是 BigQuery 本身的 Slot 喔！在 PostgreSQL 的資料複寫 (Replication) 機制中，Replication Slot 是一個重要的概念。

它能夠追蹤資料變更，即使複寫目標 (Datastream) 暫時離線或延遲，Slot 也會確保需要的 WAL (Write-Ahead Logging) 檔案，直到 Datastream 收到這些變更，也能避免資料遺失。

你需要在 PostgreSQL 資料庫中預先建立這個 Replication Slot，然後在設定 Datastream 時提供這個 Slot 名稱，這樣 Datastream 就能透過這個 Slot 來追蹤和接收資料庫的變更。

而 Publication 是 PostgreSQL 10 版之後推出的邏輯複寫 (Logical Replication) 機制中的一個重要元素。你可以指定特定的表格要被複寫，以及要複寫哪些類型的操作。

再往下選擇要轉移資料的表格跟欄位，選好再下一步： 

在目的地的部分，我們就選擇剛剛建立的 BigQuery 連線設定檔： 

這裡是問你要把轉移出來的資料要放在單一 Region 還是多個 Region 的 Dataset。

如果你後續的的應用主要在特定區域運作，選擇 Region 即可，如果你需要更高的配額限制和更高的可用性，選擇 Multi-region。

Stream Write Mode 指的是寫入模式，包含 Merge (合併模式，會更新舊資料)、Append (追加模式，不會更新或刪除現有資料) 和Replace (替換模式，會刪除所有現有資料)。

而 Staleness Limit (資料陳舊限制)，指的是資料是否需要立即處理，設定為 0 秒表示資料會立即被處理，用來保持最即時的狀態。但可能會導致較高的查詢成本，因為每次變更都需要立即處理。

如果您想降低成本，並且可以接受一點資料延遲的話，可以增加一點 Staleness Limit。

最後再按一下「RUN VALIDATION」來確認所有的設定正確無誤，如果都沒問題就可直接按下「CREATE & START」直接開始傳輸：

它跳出一個確認視窗，再次按下「CREATE & START」：

接著我們就看到 Datastream 開始同步資料了： 

3. Pub/Sub 搭配 Cloud Functions

Pub/Sub 是一個完全代管的訊息佇列 (Message Queue) 服務，基於發布/訂閱 (Publish/Subscribe) 模式，主要用於事件驅動架構和串流資料處理。主要有三個特性：

(1) 解耦 (Decoupling)

透過發布/訂閱模式，發送方和接收方之間不需要直接互動，讓系統的各個部分能夠獨立發展和擴展，大幅提升了系統的靈活性和可維護性。

(2) 可靠性 (Reliability)

系統會將所有訊息永久儲存，即使在過程中發生異常，訊息也不會遺失。

(3) 擴展性 (Scalability)

系統能夠因應流量變化自動擴充，無需手動干預。

而 Cloud Functions 本身是輕量級的應用程式平台，內建訂閱 Pub/Sub Topic 的功能 很適合處理中小規模的串流資料，尤其是針對簡單的資料轉換。

當新訊息到達時，能夠自動觸發 Cloud Function 執行，最適合用於事件驅動的架構，特別是那些資料流時有時無的場景。

優勢：

因為是無伺服器架構，不用管理任何基礎設施。系統能夠根據實際負載自動擴展，只要為實際使用的資源付費。

開發過程也相對簡單，工程師可以專注於業務邏輯的實現，不必擔心底層基礎建設的管理。這種按需付費的模式通常能提供較好的成本效益。

限制：

Cloud Functions 的執行時間有上限，最長只能運行 540 秒，不適合需要長時間處理的任務。例如資料轉換太複雜的時候，並且冷啟動也會帶來延遲。另外對於併發處理能力也有一定的限制。

注意事項：

首先要設定合理的 Time-Out 時間，確保能夠完整處理資料。同時，必須實作穩健可靠的錯誤處理和重試機制，以應對可能的失敗情況。你也要建立完善的監控機制來追踪 Cloud Functions  的執行狀態。

4. Pub/Sub + Cloud Run

Cloud Run 結合 Pub/Sub 提供了一個更加靈活的串流資料處理方案。特別適合那些需要自訂處理邏輯，或需要特定運作環境的場景。

與 Cloud Functions 相比，它支援更長的運作時間，最長可達到 60 分鐘，並且能夠處理中大型的串流資料。

優勢：

由於容器化的部署方式，這提供很大的靈活性。

您可以使用任何程式語言，安裝任何所需的相依性套件。Cloud Run 能夠自動擴充 (Autoscale)，同時能運作較長時間，讓它能夠適用於複雜的應用場景。

限制：

首先是容器映像檔的維護，這需要一個完整的容器管理或 CI/CD 流程。相比 Cloud Functions，Cloud Run 的設定也相對複雜一些，需要更多的維運工作。

從成本角度來看，如果沒設定好 Autoscale 的參數，可能會導致較高的費用。

注意事項：

要注意容器映像檔的維護和更新策略。對資源的配置需要仔細優化，包括記憶體、CPU 等參數的設定。

建立完善的監控和警報機制也很重要，需要及時發現和解決潛在問題。另外，為了控制成本也要小心設定 Autoscale 的策略。

5.  Pub/Sub + Dataflow

Dataflow 結合 Pub/Sub 是一個企業級的串流處理方案，適合處理大規模資料和複雜的轉換。

Dataflow 具有高度的擴展性，特別是那些複雜的業務邏輯，或需要進行大規模數據處理的企業級應用場景。

優勢：

Dataflow 提供了豐富的資料轉換和處理功能，能夠處理複雜的業務邏輯。它也能 Autoscale，能夠自動處理負載量的變化。

還內建完善的容錯機制，能夠確保數據處理的可靠性。此外，它還支援複雜的視窗操作 (Window Operations)，將連續不斷的資料流切分成有限時間區段來處理，以及自訂的轉換邏輯。

限制：

Dataflow 也是最複雜的，它需要較多的專業知識，從設定到後續維護都很複雜。從成本角度來看，它是會自動建立虛擬機器來運作，也有較高的運營成本，通常需要專門的團隊和較長的時間投入。

注意事項：

首先是仔細規劃資料管道 (Data Pipeline) 的設計，確保能夠高效地處理資料流。

成本優化也是一個重要考量，需要合理設置資源使用策略，從 CPU、記憶體、硬碟，到 Autoscale、處理窗格和管道設計等等。建立完善的監控機制是很重要的。

6.  串流方法比較表

以下整理五種串流資料的方法，你可以根據場景來決定處理方式：

三、資料「不用」上傳到 BigQuery 的方法介紹

沒錯，資料不一定要上傳到 BigQuery 才能做分析，你可以讓資料就在原來的地方，讓 BigQuery 自己過去抓資料來分析，以下介紹資料「不用」上傳到 BigQuery 的方法：

(一) 外部表  (External Tables)

外部表就像是在 BigQuery 中設定一個連結，指向存放在別處的資料。連結建立後，你就一樣在 BigQuery 的介面，使用一般的 SQL 語法來查詢，就跟查詢 BigQuery 本身的表格一樣方便。

適用的資料來源包含：

• Cloud Storage 中的 CSV、JSON、Avro、Parquet、ORC 等檔案
• Google 試算表
• Bigtable

像是從雲端硬碟匯入 Google 試算表，我們在最前面已經示範過了，匯入之後，就會呈現表格的詳細資訊，有一個來源 URI 代表真的是外部表，這裡就不再贅述。

使用外部表有一些注意事項如下：

1. 查詢效能會比較慢

因為每次都要讀取外部資料，效能取決於資料來源本身，就不像在 BigQuery 身上那麼快。

2. 資料格式要一致

尤其是 CSV 的欄位順序和型態，例如 Schema 設定 3 個欄位，但某些 CSV 檔只有 2 個欄位，就會報錯「Invalid field count」；或是​​數字欄位出現文字，會造成「Invalid integer value」錯誤。

3. 檔案路徑支援萬用字元 「*」

代表你可以一口氣匯入「多個」檔案成為「一個」外部表，很適合定期新增的資料檔案，例如每天的 Log 檔，每次執行查詢時，BigQuery 都會重新掃描符合萬用字元的檔案，非常方便。

4. 權限要設定正確

你設定適當的權限給 BigQuery Service Account，例如 storage.objectViewer，確保 BigQuery 能存取Cloud Storage 的檔案。

(二) 同步查詢 (Federated Query)

Federated Query 是直接發送 SQL 查詢語法到其他資料來源，即時取得結果。這種方式更有彈性，可以直接查詢原始資料庫，尤其來源資料經常變動的話，適合用這種方式查詢。

適用的資料來源包含：

• Cloud SQL (MySQL/PostgreSQL)
• Cloud Spanner
• Alloy DB

我們以網路上示範的影片為例子呈現如下，我們現在 Spanner 準備好一個 demo_db 資料庫，點擊進入看到 emp 表格，再點進去：

我們再點擊「Data」，看到裡面已經準備好一筆資料。 

我們在回到 BigQuery 去新增外部的資料來源，點擊「ADD DATA」裡面的「External data source」： 

選擇 Spanner 之後，填上資料庫的相關資訊，如果相關內容都輸入正確，可以直接按下「Create Connection」：

接下來它秀出連線資訊，我們可以直接點擊「Query」來試著查詢資料：

它預設的語法是讓你看到整個資料庫的 Metadata，例如資料庫裡有哪些表格和欄位。 

我們來調整一下語法，讓它直接查詢「emp」這個表格，最後就看到原本儲存 Spanner 的裡面的資料內容，代表我們的確是連線到 Spanner 做查詢。 

使用 Federated Query 的注意事項：

1. 需要額外設定連線和授權

因為我們直接連線到來源資料庫，查詢時間可能較長。光是連線成功就需要時間等待。

2. 要注意資料量

避免查詢太大量資料，影響原始資料庫的運作，如果要大量還是把資料轉入 BigQuery 比較好。

3. SQL 語法會因資料來源而異

要配合來源資料，例如 MySQL、PostgreSQL 和 Spanner 的查詢語法可能有所不同。

4. 計費方式與一般查詢不同

它不會佔用 BigQuery 的儲存費用，但仍然會有查詢費用。如果頻繁查詢外部資料庫，也要考慮提高規格，相對也造成較高成本。

(三) 如何判斷要用原生、外部表或同步查詢？

我們已經看了各種匯入資料到 BigQuery 的方法，那要選原生或外部表或同步查詢的決策標準是什麼？這裡整理各種方法優缺點和適用的場景給你參考：

建議策略

1. 從資料更新頻率來看

(1) 如果資料每天更新 1-2 次，建議使用原生表，查詢效能最好。

(2) 如果資料持續變動 (如每分鐘)，考慮外部表或 Federated Query。

(3) 如果是即時分析需求，一定使用 Federated Query。

2. 從查詢效能來看

(1) 需要毫秒級回應，必須使用原生表。

(2) 可接受秒級延遲，使用外部表。

(3) 可接受較高延遲，使用 Federated Query 。

3. 以成本為考量

(1) 資料量大但查詢頻率低，選擇外部表或 Federated Query，不用花費 BigQuery 儲存成本。

(2) 查詢頻率高，原生表有 24 小時快取，重複讀取外部資料成本較高。

(3) 預算有限，可先用 Federated Query，再根據使用情況調整。

4. 實務建議

(1) 可採用混合策略，不同的資料採用不同的查詢方式。

• 熱門資料 (經常查詢) 使用原生表
• 冷資料 (不常查詢) 使用外部表
• 特殊即時需求用 Federated Query

(2) 建議先小規模測試：

• 先用小部分資料評估性能
• 測試實際查詢場景
• 監控成本和效能數據再決定

四、上傳到 BigQuery 之前的注意事項

前面看完各種上傳或不上傳到 BigQuery 的方法，除了針對採取的方法提共建議之外，這裡也建議上傳之前要確認以下注意事項：

(一) 資料品質與準備工作

你必須確保所有資料的格式是一致的，包括日期格式和數值類型都要統一，異常值和空值也要先處理好。

編碼格式最好用 UTF-8，這樣比較不會出現亂碼。另外欄位名稱要注意，不能用特殊字元，不然 BigQuery 會報錯。

針對批次載入，你沒有辦法在 BigQuery 傳到一半給它按暫停，調整後再繼續傳，它錯了就是要全部重來，所以請務必謹慎處理，避免重工。

(二) 成本考量

如果資料需要整理，可以先用臨時表，等到都整理好了再存到永久表。這樣中間處理的表隔天會自動刪除，不會佔用空間也不用付費，最後的結果才存在永久表裡給大家查詢使用。

分區 (Partitioned) 策略也要規劃好，確保查詢只針對部分資料而不是整張表格，這樣可以省下不少查詢費用。要是預算有限，最好設個配額上限，免得花太多錢。

(三) 效能優化

表格結構要設計得合理，別搞得太複雜，例如盡量使用巢狀表格 （Nested Table） 而非 Join 太多表格。

選擇分區欄位的時候，通常用時間欄位或是基數 (Cardinality：一個欄位中不重複值的數量) 比較高的欄位會比較好。如果需要的話，也可以考慮加上叢集索引。

(四) 權限與安全性

如果上傳有使用特定工具，要遵守「最小權限原則」，給予剛好且必要的權限。資料存取的控管策略也要想清楚，特別是有敏感資料的話，可能還需要設定資料遮罩或加密。

(五) 上傳方式選擇

大部分情況都建議先傳到 Cloud Storage 再導入 BigQuery，至少資料已經先進來了，也不受檔案大小限制。

記得要設定合理的 Time-Out 時間，讓傳輸工作多等待一段時間，萬一上傳失敗也要有因應的處理方式。

(六) 監控與維護

上傳過程中要做好監控，隨時掌握進度。要是上傳失敗了，得要有辦法快速恢復。定期維護和檢查資料品質也別忘了。

(七) 文件與溝通

透過文件把所有細節都記錄下來，每個欄位都要寫清楚說明，資料從哪裡來、怎麼處理的都要記錄好。

跟其他團隊也要講清楚什麼時候上傳、會影響到誰。要是碰到問題，大家也才知道該怎麼處理。

五、結論

我們總共看了手動上傳、Data Transfer Service、Datastream 和串流各種方法，以及「不上傳」到 BigQuery 的外部表和 Federated Query。

可以看到 BigQuery 提供的方法真的非常多，讓你可以因應各種情境，來評估和選擇最適合的方法。

至於到底要用哪一種方法，除了參考上面的整理表格之外，最重要還是建議你先以小量資料試過一遍，才會發現到更多沒提到的小細節，來幫助你做出更好的判斷。

只要資料成功進來了，BigQuery 就不只能夠幫你做好分析，還能做為開發 AI 模型的基礎，幫企業產生更多價值。

本文同時刊登於：

【東東老師 X 思想科技】BigQuery 的優勢與使用方法

【東東老師 X 思想科技】資料匯入到 BigQuery 的方法

【東東老師 X 思想科技】資料「不用」上傳到 BigQuery 的方法介紹

The post [BigQuery 教學] 把資料上傳到 BigQuery 的各種方法和步驟 first appeared on 東東 GCP 教學 - GCP 實戰講師 - 雲上星辰有限公司.

如果用一句話講完 BigQuery，就是你只要下一個 SQL 分析語法，就可以叫雲端上一大堆機器出來幫你分析資料。就像陳浩南一聲令下，小弟瞬間集結完成，幫你「橋事情」。

Google BigQuery 是一種由 Google Cloud 提供的無伺服器資料倉儲解決方案，專為大規模資料處理設計。

你可以將它視為資料分析的高速引擎，幫助你快速從海量資料中找出洞察。

重點是你只要使用通用的 SQL 語法，就可以馬上使用，完全不用學習新的技術，超級方便。

接下來，我們將深入介紹它的功能、組成元件、特色以及使用它的好處。

一、BigQuery 的基本介紹

BigQuery 是一種基於雲端的企業級資料倉儲服務，它可以快速處理結構化和非結構化數據，並提供即時查詢功能。它主要針對需要分析大量數據的組織設計，例如電子商務平台、金融服務公司等。

二、BigQuery 的核心功能

(一) 即時查詢與高效能處理

BigQuery 的設計使它能在幾秒鐘內處理數百億行數據，這對於需要快速決策的企業來說至關重要。它的分散式架構允許你同時查詢和寫入資料，完全不需要等待。

(二) 支援大規模資料分析

無論是幾百 GB 的數據，還是幾 PB 的數據，BigQuery 都能輕鬆處理。它的擴展性確保了隨著你的業務需求增長，你的資料分析能力也能跟上。

(三) 與其他 GCP 工具的整合

BigQuery 可與 Google Cloud 其他工具無縫整合，例如 Dataflow、Pub/Sub 和 Looker (或 Looker Studio)，讓你能建立完整的數據管道和視覺化報告。

三、BigQuery 的組成元件

(一) Dataset：資料的邏輯分組

Dataset 是 BigQuery 的核心概念之一。你可以將 Dataset 理解為數據的邏輯容器，用於組織和管理 Tables 與 Views。

每個 Dataset 都屬於一個特定的專案，並可以設定資料位置、存取權限與加密選項。

Dataset 的特點：

1. 幫助你有效組織資料（例如將不同部門的數據分開存放）。

2. 支援跨 Dataset 查詢，方便資料整合。

3. 具有細緻的權限管理，確保數據安全。

(二) Table：儲存結構化資料的基本單位

Table 是 BigQuery 中存放數據的主要單位。每張 Table 包含行與列，類似於傳統的關聯式資料表，但支持更大規模的資料。

BigQuery 支持的 Table 類型

1. 永久表（Permanent Table）

一般的資料表，存放數據直到你手動刪除。

2. 臨時表（Temporary Table）

這些表僅在查詢執行期間存在，適合處理臨時性的中間結果，你每次查詢永久表的結果，它都會暫存 24 小時。

3. 分區表（Partitioned Table）

這種表根據時間（例如日期）、數字範圍或數據欄位進行分區，能有效提升查詢效能並降低成本。

4. 分片表（Sharded Table）

通過表名結構（如 `table_202311`）分片，雖然靈活，但不如分區表高效。

(三) View：基於查詢語句的虛擬表

View 是基於 SQL 查詢創建的虛擬表，讓你能透過查詢結果像操作實際表一樣進行使用。

BigQuery 支持的 View 類型：

1. 標準 View（Standard View）

基於靜態查詢語句，直接返回當前的查詢結果。

2. 授權 View（Authorized View）

允許你控制使用者對基礎表的存取權限。授權 View 是在敏感數據共享中非常實用的工具。

3. 物化 View（Materialized View）

將查詢結果存儲起來，從而加速重複查詢的性能，同時降低計算資源的使用。

View 的優勢：

1. 簡化複雜查詢，減少重複 SQL 撰寫的麻煩。

2. 可作為權限管理的工具，限制對底層數據的存取，因為它能透過很靈活的語法，從各個表格抓取和過濾資料，給有適當權限的人看。

3. 提高效能，特別是使用物化 View 時。

四、BigQuery 的特色

(一) 無伺服器架構的便利性

BigQuery 不需要你配置伺服器或管理基礎設施，讓你能將精力集中在數據分析上，而非繁瑣的運維工作。

光是這一點，就完全屌打巿面上所有資料倉儲和分析工具，像是 AWS 和 Azure 還要開機器，主機效能受限於你開的規格，BigQuery 完全不問規格，自動依照你的資料量瞬間呼叫機器幫你運算。

(二) Pay-as-you-go 計費模式

BigQuery 採用按 Query 量 (處理的資料量) 計費，確保你只需為實際使用的資源付費，這對於中小型企業尤其有吸引力。

不過也要注意，因為BigQuery 太方便了，你很容易就不小心 Query 太多資料，未來會再介紹節省 BigQuery 費用的方法。

(三) 跨地區資料分析的優勢

BigQuery 支持跨地區資料分析，讓你能從全球各地的數據中快速獲得洞察，而不必擔心資料傳輸的延遲。

五、使用 BigQuery 的主要優勢

(一) 企業如何受益於 BigQuery

BigQuery 幫助企業節省成本、提升效率，並提供即時的數據洞察，這些都是在數據驅動時代中脫穎而出的關鍵。

值得提的一點是企業不用在初期一口氣花好幾百萬，購買一套資料倉儲，而是每月依使用量計費，減少一口氣支出太多的負擔。

(二) 開發者與資料科學家的支援

BigQuery 提供 SQL 語法支援，且與各種開發工具兼容，讓開發者能快速上手並整合到現有的工作流程中。

六、如何開始使用 BigQuery？

(一) 建立專案與資料集

首先，你需要在 Google Cloud Console 中建立一個專案，並設定資料集，這是你管理資料的基礎。

(二) 撰寫查詢語法與分析資料

利用 BigQuery 提供的標準 SQL，你可以輕鬆撰寫查詢語法，並快速分析資料，甚至建立視覺化的報表。

七、結論

BigQuery 是一個功能強大且靈活的資料分析工具，無論是對於初創企業還是大型組織，都能帶來明顯的價值。如果你正在尋找一種高效處理數據的解決方案，不妨考慮使用 BigQuery。

八、常見問題解答

1. BigQuery 是免費的嗎？

BigQuery 提供免費沙箱，你連信用卡都不用就可以玩，每月包含 1 TB 的查詢和 10 GB 的存儲，超出部分需按使用量付費。

2. BigQuery 支持哪些資料格式？

它支持 CSV、JSON、Parquet、Avro 等多種格式，適合不同的資料需求。

3. 如何與第三方工具整合？

BigQuery 可以通過 API 或第三方工具如 Tableau、Power BI 進行整合，方便創建報告。

4. BigQuery 的資料安全性如何保障？

BigQuery 提供強大的資料加密與訪問控制，不管是 Dataset、Table、View 都可以單獨分享存取權限，並符合多項全球合規標準。

5. BigQuery 可以取代傳統數據庫嗎？

它適合用於分析數據，但不適合作為交易型資料庫（OLTP）。

意思就是不能當一般的資料庫，每天不間斷 Insert、Update、Delete 的意思。

影片版的介紹如下：

The post [BigQuery 教學] 雲端界陳浩南 – BigQuery 是什麼？功能、組成元件、特色和優勢完整介紹 first appeared on 東東 GCP 教學 - GCP 實戰講師 - 雲上星辰有限公司.

Data Engineer 證照是什麼？

Google Cloud Professional Data Engineer 是 GCP 推出的證照之一，

Data Engineer 就是針對 GCP 資料處理各項服務，

對它們的使用方法、資料處理流程、資料管道 (Data Pipeline)、

最佳實務和解決方案的相關知識所推出的證照。

而證照的有效期限只有兩年，所以快到期了，必須要趕快去考，

我是 9/18 到期，它有給予一個月的寬限期，所以趕在 9/23 去考，

目前第三次考過 Date Engineer，這是證照的公開連結。

為什麼要考這 Data Engineer 證照?

我之前一直都在 GCP 代理商擔任雲端架構師，

幫客戶執行各種上雲專案、教育訓練、技術支援和解決方案的建議，

其中也有不少關於資料方面的需求，所以對代理商而言，是一張很重要的證照。

現在我自己出來教 GCP，為了維持知識的更新，就繼續考來延長有效期。

近年來大數據、雲端和 AI 的蓬勃發展，資料的重要性不言而喻，

如果你的公司也在用 GCP，你的工作又和資料相關，

則這張證照一定是必備的。

Data Engineer 考試資格

沒有資格限制。

官網希望你至少有 3 年產業經驗，包含 1 年使用 GCP 設計解決方案的經驗，

有經驗去考會比較有感覺，至少你知道題目都在問什麼，

如果對 GCP 的資料各項服務都不懂，直接去考，

就像是在背題目跟答案，考完學到的不多。

PS.其實你根本背不完，還不如乖乖回去研讀相關知識。

Data Engineer 到底在考什麼？

常見的考試情境如下：

1. 資料建模

資料應該放在哪裡？怎麼放比較便宜？

效能比較好？看到的資料比較新？

2. 批次和即時資料處理

用什麼工具抓資料？多久抓一次？

資料有問題怎麼處理？如何確保資料不會掉？

3. 機器學習

機器學習的基本概念，資料放哪裡適合做機器學習？

資料要整理成什麼樣子？什麼情境之下，該用什麼模型？

4. 資料管道建立

地端資料如何上 GCP？其他雲端資料如何抓過來？

怎麼傳速效能比較快？比較便宜？比較安全？

GCP 的資料如何放到 BigQuery？

Data Engineer 各服務出題比例

先看這張圖就對了：

你可以看得出幾個重點：

1.核心服務

(1) BigQuery 

資料倉儲和分析工具，它一直保持資料一哥的地位，你也可以說它是雲端界陳浩南。

(2) Dataflow 

資料處理最重要的自動化工具，是原生的 Apache Beam，

寫 Java 或 Python 程式讓它可以自動處理資料，還能夠依照資料量大小 Autoscale。

(3) Pubsub 

接住串流資料最重要的工具，如果你的串流資料來源，流量大小不固定，

有時1秒1筆，有時1秒10萬筆，就可以用 PusSub 幫你把資料接住，不會漏掉。

這三個弄熟就可以當選總統掌握 40% 的考試了，未來應該還是持續佔據很大的比例。

2.機器學習知識

因為資料是 AI 跟機器學習的原料，所以機器學習的基礎知識都納入考試，

也包含機器學習相關服務 BigQueryML、AutoML、Dialogflow。

奇怪怎麼沒有 Vertex AI？最近生成式 AI 的興起，Google 大推 Vertex AI 開發平台，

各種 AI 應用工具例如 Agent Builder、Model Builder 和 Model Garden 推陳出新。

不過，這些服務 Google 自己也一直改來改去的，功能和命名都一直改，還沒穩定下來，

我猜是這樣的原因，所以都還沒納入考題，也好，不然考了之後，服務又改名或下架，就太尷尬了。

3.基本資料服務

Cloud SQL – 雲端版的 MySQL、Postgre SQL、SQL Server

Dataproc – 雲端版的 Hadoop、Spark、Pig、Hive 等資料處理工具

Bigtable – 雲端版低延遲的 NoSQL 資料庫

Cloud Storage – 無限大的雲端檔案儲存空間和 API 服務

Spanner – 全球即時同步的關聯式資料庫

Cloud Composer – 資料管道管理與編排，可以控制整個資料的旅程，

從資料的產生、處理到分析都可以納入管理，近年來考題越來越多。

4.資料搬遷

各種情境題，像是：

地端資料如何搬上雲端？

怎麼傳比較快？或比較便宜？

其他雲端的資料怎麼傳到 GCP？

GCP 的其他服務，怎麼倒入 BigQuery？

資料放哪裡比較便宜？

這種題目蠻需要你對各種工具和服務都很了解，才有辦法回答正確。

5.資安跟資料治理

在這部分當中，Cloud KMS (加密金鑰管理) 和 Cloud DLP (資料外洩防護) 一直都會考，

最近又出了像是 Dataplex、Analytics Hub、Data Catalog 和 Dataform 比較新的服務。

就是因為公司的資料太多，然後到處放，沒有管好怕會造成外洩，

所以這些服務就是要幫助公司管好資料，未來這塊考題應該會越來越多，

我也是因為考試才碰到這些東西，有機會一定要實際操作看看。

官方宣布的考試範圍可以參考這個連結，以前有考 Case 題組，

就是一個 Case 考個 3~5 題，大概考 1~3 個 Case，

你可以從官網先了解公司的背景，考試的時候就不用從頭開始看。

但 2024 年又沒考了，所以不用再讀 Case。

準備方式

官方資源

如果要真的懂 GCP 的各項資料服務，還是先以官網文件為準。

但是文件非常多，是「非常非常非常多」，所以你只要大概知道每個服務大概在做什麼就好，

你可以讀像是：

Overview 和 Introduction： 大概了解用途。

Best Practice：應該怎麼用比較快、效能比較好、比較便宜、比較安全等等。

Troubleshooting：有問題時應該怎麼處理，要檢查什麼地方。

不要求看完全部的文件，因為根本看不完。

你可以上這個 Skillbost ，裡面有一個 Data Engineer Learning Path：

它除了免費提供線上課程之外，

課程中還有免費的 Lab，至少都做一下，

這樣你學東西才會有感覺，不會都在死記硬背，學不到東西。

官網還有提供範例考題，一定要做，不要送分題都拿不到。

網路資源

說真的，有些服務在台灣的企業，真的很少用到，

除非你是在專門做資料分析的公司，或是技術領先的公司。

要不然，很多考試的內容，在工作上很難用到。

所以官方文件大概看過之後，

你就直接搜尋 “google cloud data engineer questions” 找到相關資源，例如 Exam Topic。

要注意的是，內容「非常多」，而且 Google 一直都在更新考試內容，

像我今年第三次考，發現跟上次 2022 年比起來，根本就是大改，

這段時間我 K 書 K 到懷疑人生，難度指數從 4 顆星升到 5 顆星。

考試規則和題型

單選題和多選題，50 題，2 個小時考完。

進考場前所有東西都要給考場人員保管，手機要關機，手錶要拿下來。

中途可以上廁所，但時間會繼續算。

冷氣有點冷，可以帶件外套。

考完會馬上告訴你 Pass 或 Fail，官方是說需要人工確認後再發正式 Email 給你，

另外這個考試結果，不會講分數，不會跟你說哪一題做錯，

我猜他們要看考試的監控影片，看你有沒有作弊。

報名考試

註冊帳號與報名考試

直接從這個網站報名，先註冊帳號，記得姓名要用護照名稱喔！

我以前用一般的英文名字，跟護照羅馬拼音的名字不同，

結果到考場被拒絕，盧了半天才能進去考試，讓我有夠緊張。

我當天考完馬上聯絡客服，請他們幫我改成護照名稱 (因為自己無法改)。

然後點擊 “Register For An Exam”：

找到你要考的科目，選擇你要遠端 (Remote) 還是去考場 (Onsite) 考，

我一律建議去考場，因為遠端你要安裝軟體，然後在家找一個安靜的地方，

對方還會在線上看你考試，確認你有沒有異常的舉止。

萬一考試那天網路不通，或是你家的貓咪突然攻擊你，你就無法專心完成考試了。

選好就可以選擇考場，像我都去恆毅資訊考試，

因為恆毅資訊有喝到飽的快樂肥宅水，

考前喝一杯，考完開心再喝一杯，不香嗎？

對了不要喝太多，不然考試中會很想上廁所。

考試費用

像上面選擇科目的時候，它跟你說要 200 美金，但你真的要付款的時候，

它又自動打 6 折，所以才 120 美金。

而且它還有 Coupon/Voucher Code，後面會跟你說如何取得。

但要注意沒考過的話，

第一次沒考過，要 14 天後才能重考，

第二次沒考過，要 60 天後才能重考，

第三次沒考過，要 365 天後才能重考，

重考都要重新付費喔！詳情看這份官方的重考政策。

列印考試確認單

報名刷卡完成之後，你會收到一封 Email，

上面有考試相關資訊，

更重要的是 Test Taker Authorization Code，考場要比對這個 Code，

強烈建議你印出來，不然考場人員無法讓你進去考試喔！

考完試之後會收到什麼福利？

收正式通知信

我這次是 9/23 去考試的，然後在 9/25 收到下面這封信，

這才是正式確認你有成功考過。

註冊 Credly 帳號並下載證照 PDF 檔

如果你是第一次考到 GCP 證照，請先去 Credly 註冊一個帳號，

先點擊第一個連結：

然後你可以參考這篇，我當初花半小時才找到下載的地方，

所以特別寫了這篇分享，方便你投履歷表或跟公司報帳。

取得考過禮物和考試折扣券

往下看有一條很重要，

這一條是給你拿考試禮物和考試折扣券的地方。

PS.如果你是第一次考證照，強烈建議每一個連結都點進去，

有很多重要權益可能是你想要的喔！

點擊 “Account” 之後，會進到 https://cp.certmetrics.com/google/en/benefits/program 

這時點擊 Claim benefit：

你會拿到一個折扣碼，再點擊 Access Benefit：

(前後兩張圖不一樣，因為原本的圖沒截到)

補充一下，像左邊的 Exam Discount，就可以讓你下次報名考試的時候，

輸入折扣碼，取得半價優惠，也就是已經 120 美金的費用，再變成 60 美金，所以根本沒有到 6000 台幣那麼貴。

我們再回來，點擊 Access Benefit，會跳出新的視窗，

你會進入 Google 的商店，你可以免費選一個禮物：

把折扣碼貼上之後，就進入選禮物的頁面。

像我就選了一件外套：

最後再填寫一下地址，記得都要用英文喔，

你可以去郵局網站來翻譯成英文地址：

完成囉！接下來就靜候 Google 從國外發貨到你家！

證照持有者目錄

還有一個我覺得很有趣，有點類似證照名人榜的東西，

你可以在這裡查到你自己的名字。

你可以用下面的 Search Directory，用證照篩檢考過的人有哪些：

像我把我 6 張證照都加入篩選，看看有多少人跟我一樣，結果竟然有 531個人。

我再加一個過濾條件 Location 選台灣看看，結果台灣還有 16 個人至少 6 張證照以上，

可見人外有人，天外有天啊！！

可見台灣這麼小的地方，還是臥虎藏龍，高手在民間！

我要持續努力，不可以此自滿！

以上分享到這裡，謝謝大家！

The post GCP 證照 Data Engineer 介紹、考試心得、準備方式和考過福利分享 first appeared on 東東 GCP 教學 - GCP 實戰講師 - 雲上星辰有限公司.

他的檔案好幾 GB，剛好我查到這篇文章提到，

不能匯出超過1GB的檔案，必須要分開儲存。

那我就來試試看，首先去 BigQuery 找一個超過 1GB 的 Table。

注意到它的 Dataset 是在 US，所以為了把它的資料存到我的 Dataset，我必須也在 US 建立一個 Dataset。

接下來開始查詢整張表格，然後點擊「儲存結果」=> 「BigQuery」資料表。

選擇我剛建立的 Dataset

幾秒鐘後，完成了。

預覽一下資料

看一下詳細資訊，沒錯有1.76GB

那我接著把它儲到 Cloud Storage Bucket。

設好 Dataset

報錯了，因為超過 1GB

不該用 UI，要用語法

可以了，但是…

50個檔案，不是1GB一個檔案，另一個0.76GB嗎？

這裡有教你先分割表格，再依照分割區逐一匯出

https://cloud.google.com/bigquery/docs/exporting-data#limit_the_exported_file_size

以下我對原始表分做兩個分割

CREATE TABLE rsync_test_us.processed_table
PARTITION BY RANGE_BUCKET(export_id, GENERATE_ARRAY(0, 2, 1))
CLUSTER BY export_id
AS (
  SELECT *, CAST(FLOOR(2*RAND()) AS INT64) AS export_id
  FROM rsync_test_us.games_wide
);

分割後的表格資訊

你可以看到，表格多一欄，一半的 record 的 export_id 為 0，另一半 record 的 export_id 為 1.

然後我把第二分割匯出到 Cloud Storage，目前看到 906 MB，這樣匯出，應該只會有一個檔案？

EXPORT DATA
  OPTIONS (
    uri = 'gs://dong-dong-gcp-rsync/games_wide-*.csv',
    format = 'CSV',
    overwrite = true,
    header = true,
    field_delimiter = ';')
AS (
  SELECT *
  FROM rsync_test_us.processed_table WHERE export_id = 1
);

結果竟然又被它分成3個檔案，太奇怪了？

應該是說，我不應該用上面的語法，我應該直接 Select 出來，直接儲存到 Cloud Storage 嗎？

其實上面語法，把 “*” 拿掉即可，這裡有說明，這裡改用 Web UI 來示範。

要注意，要存到美國的 Dataset。

成功了。

然後再匯到 Cloud Storage

設定檔案名稱

開始匯出

看到了，最下面那個檔，沒有被切成3個。

接下來用 gcloud rsync 指令，-r 表示它可以一直監控，有新檔案上來，會同步 ，接下來是來源 bucket 最後面是我本機電腦的資料來

gsutil rsync -r gs://dong-dong-gcp-rsync rsync_local

因為我本來就有3個檔案在地端，所以指令下去，現在只會同步最新的那個檔案。

最新檔案在同步中，副檔名是 .gstmp

再等一下，我家網路還算快，每秒 5 MiB，相當於 0.6 MB。

完成了，整個 846MB檔案已在本機。

順便實驗一下，如果把3個小檔刪除，那我本機檔案會跟著刪嗎？

不會，應該用這個指令

gsutil rsync -d -r gs://dong-dong-gcp-rsync rsync_local/

刪除了

那我再隨便上傳一個檔案上去 GCS，可以再同步下來嗎？

目前測試，不會同步，以後再測試看看囉！

順便置入一下，關於更多 GCP 相關的概念和實作教學，都在東東的 GCP 線上課程《雲端架構師養成班》，有需要可以進來看喔！

The post [GCP 教學] 如何把 BigQuery 的大量分析結果同步到地端本機 first appeared on 東東 GCP 教學 - GCP 實戰講師 - 雲上星辰有限公司.