Upsert dữ liệu vào BigQuery bằng n8n: để BigQuery làm việc nặng

TL;DR: Muốn đồng bộ dữ liệu vào BigQuery mà chạy lại không sinh bản ghi trùng: đẩy dữ liệu mới vào bảng tạm, rồi chạy một câu MERGE để BigQuery tự quyết định update hay insert. n8n chỉ đóng vai điều phối — toàn bộ logic nằm trong SQL.

Sai lầm thường gặp: bắt công cụ automation so sánh dữ liệu

Cách làm theo bản năng là: kéo toàn bộ dữ liệu cũ từ BigQuery về, so với dữ liệu mới, tách ra nhóm update và nhóm insert, rồi gọi API tương ứng.

Cách này chạy được với vài trăm dòng. Lên vài chục nghìn dòng thì:

• Kéo dữ liệu cũ về tốn thời gian và bộ nhớ của n8n
• Logic so khớp nằm rải rác trong nhiều node, sửa nghiệp vụ là phải vẽ lại nhánh
• Mỗi lần chạy đều đọc lại toàn bộ bảng, dù chỉ có 20 dòng thay đổi

BigQuery là công cụ xử lý dữ liệu. Việc so khớp hàng triệu dòng đúng là việc của nó, không phải của lớp automation.

Kiến trúc: bảng tạm + MERGE

Luồng gồm ba bước:

Bước 1: Đẩy vào bảng tạm

Dữ liệu mới insert nguyên cụm vào một bảng staging theo schema định sẵn. Không kiểm tra gì cả, không so sánh gì cả — chỉ đổ vào.

Bước 2: Chạy MERGE

Gọi một câu query đã viết sẵn. Câu này merge từ bảng tạm vào bảng chính: trùng khoá thì update, chưa có thì insert.

Bước 3: Dọn bảng tạm

Xoá dữ liệu trong staging để lần chạy sau sạch sẽ.

Mấu chốt: toàn bộ logic upsert nằm trong câu SQL chạy trên BigQuery, không nằm trong workflow. n8n chỉ còn vai trò canh giờ và điều phối.

Câu MERGE

BigQuery hỗ trợ MERGE chuẩn — đây chính là upsert:

MERGE `project.dataset.bang_chinh` AS t
USING `project.dataset.bang_tam` AS s
ON t.id = s.id
WHEN MATCHED THEN
  UPDATE SET
    t.ten        = s.ten,
    t.doanh_thu  = s.doanh_thu,
    t.updated_at = s.updated_at
WHEN NOT MATCHED THEN
  INSERT (id, ten, doanh_thu, updated_at)
  VALUES (s.id, s.ten, s.doanh_thu, s.updated_at);

Đặt câu này vào node Google BigQuery với operation execute query. Mỗi lần workflow chạy, nó chỉ gọi đúng câu query đó.

⚠️ Warning: Nếu bảng tạm có thể chứa nhiều dòng cùng một id (nguồn gửi trùng trong một lô), MERGE sẽ báo lỗi vì không biết chọn dòng nào. Khử trùng trước trong mệnh đề USING bằng cách chọn bản ghi mới nhất theo updated_at cho mỗi id.

Vì sao cách này tốt hơn

Điểm cuối quan trọng hơn người ta tưởng. Một câu MERGE là thứ kế toán hay analyst đọc được; một workflow 15 node thì chỉ người dựng ra nó hiểu.

Khi nào nên và không nên dùng

Nên dùng khi đồng bộ định kỳ một lượng dữ liệu vừa phải vào BigQuery và cần idempotent — sync đơn hàng theo giờ, số liệu vận hành theo ngày, dữ liệu từ LarkBase sang kho phân tích.

Không nên khi cần cập nhật gần thời gian thực từng bản ghi một. BigQuery không sinh ra cho kiểu ghi lắt nhắt liên tục; mỗi lần chạy query đều tính chi phí quét dữ liệu. Trường hợp đó dùng cơ sở dữ liệu giao dịch thì hợp hơn.

Đừng quên phần vận hành

Một pipeline chạy hàng ngày cần ba thứ mà lúc dựng hay bỏ qua:

• Retry: node gọi BigQuery bật retry on fail. Rớt mạng một lần không nên làm mất cả lượt sync.
• Cảnh báo: gắn error workflow bắn tin về nhóm chat. Pipeline hỏng im lặng ba ngày là chuyện có thật.
• Kiểm tra sau khi chạy: đếm số dòng trong bảng chính trước và sau, so với số dòng trong bảng tạm. Lệch bất thường thì báo ngay thay vì chờ báo cáo sai.

Nếu nguồn dữ liệu là LarkBase, nhớ xử lý phân trang khi đọc — đọc thiếu dòng thì MERGE chạy đúng nhưng dữ liệu vẫn thiếu, và kiểu sai này rất khó phát hiện.

ℹ️ Info: Trước đây tôi dựng luồng này bằng AnyCross. Từ 2026 chuyển sang n8n vì tự host được, có log từng node để lần lỗi, và không tính tiền theo lượt chạy — pipeline chạy theo giờ thì số lượt cộng lại rất nhanh.

Tự làm mất bao lâu

Dòng cuối hay bị bỏ qua. BigQuery tính tiền theo lượng dữ liệu quét — một câu MERGE viết cẩu thả chạy mỗi 15 phút trên bảng lớn có thể tạo ra hoá đơn bất ngờ. Trước khi bật lịch chạy dày, kiểm chi phí ước tính của câu query.