一、前言 – BigQuery 的簡介與優勢

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 裡面的問題，不用擔心，接下來我們使用「撈出資料寫入表格」的語法來處理，我們開啟一個新的查詢分頁，然後準備以下語法：

CREATE TABLE `專案.資料集.新表格名稱` ASSELECT * FROM `專案.資料集.原外部表格名稱`

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

你會看到它沒有再秀出「外部資料設定」和「來源 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 的方法介紹