GBQ Exceeded rate limits问题及表对比插入方案咨询

使用GBQ完成两张3万行人员表的唯一值筛选、差集比对、新增数据插入时触发Exceeded rate limits报错，针对三个疑问的解答如下：

1. 是否可仅通过GBQ原生语法完成唯一值、差集计算 #

完全可以，这也是这类数仓操作的标准实现方式，不需要把数据拉到Python侧做内存比对，3万行规模的计算在GBQ侧毫秒级即可完成，性能远高于Python列表比对，还能大幅减少接口请求次数。
核心实现逻辑：

• 单表人员去重直接使用DISTINCT或GROUP BY人员唯一标识（如人员ID、身份证号）即可
• 差集（即源表存在、目标表不存在的新增人员）可通过LEFT JOIN IS NULL、NOT EXISTS或EXCEPT DISTINCT语法实现，单条SQL即可完成「筛选新增+插入目标表」全流程，不需要把数据迁出GBQ。

示例实现SQL：

-- 直接筛选新增人员并写入目标表，全程无额外接口调用
INSERT INTO `你的项目ID.你的数据集名.目标人员表`
SELECT DISTINCT a.* 
FROM `你的项目ID.你的数据集名.待比对源表` a
LEFT JOIN `你的项目ID.你的数据集名.目标人员表` b
ON a.person_id = b.person_id -- 替换为实际的人员唯一标识字段
WHERE b.person_id IS NULL;

如果需要比对两张源表找出双方独有的人员记录，直接用EXCEPT DISTINCT语法即可：SELECT * FROM 表A EXCEPT DISTINCT SELECT * FROM 表B会直接返回表A存在、表B不存在的去重结果。

2. 优化Python操作类能否解决速率限制报错 #

可以，你当前触发限流的核心原因大概率是把GBQ当做普通业务数据库使用，发送了大量细粒度请求（比如把全量数据拉到Python侧循环比对、逐行调用插入接口），3万行逐行插入就会产生3万次写入请求，很容易触发GBQ的短周期请求配额限制。
操作类可按以下方向优化：

• 所有计算逻辑优先下推到GBQ侧用单条SQL完成，禁止拉取全量数据到本地做循环比对、逐行回写
• 增加指数退避重试逻辑：GBQ的速率限制是短时间窗口的配额超限，碰到报错时按1s、2s、4s、8s的间隔退避重试，最多重试5次即可覆盖绝大多数偶发限流场景
• 全局复用BigQuery Client实例，不要每次执行操作都新建客户端，减少额外的鉴权、连接开销
• 确需从Python侧写入数据时，使用批量写入接口（如load_table_from_dataframe、批量insert_rows_json），单批次写入控制在1万行以内，禁止逐行调用写入接口。

优化后的操作类参考：

from google.cloud import bigquery
from tenacity import retry, wait_exponential, stop_after_attempt

class GBQ_Class():
    def __init__(self, project, dataset, table):
        self.project = project
        self.dataset = dataset
        self.table = table
        # 初始化时全局复用客户端实例
        self.client = bigquery.Client(project=self.project)

    # 增加限流自动重试逻辑
    @retry(wait=wait_exponential(multiplier=1, min=1, max=10), stop=stop_after_attempt(5))
    def execute_query(self, query):
        return self.client.query(query).result()

    def select(self, limit):
        query = """
            SELECT * FROM `{0}.{1}.{2}` LIMIT {3}
        """.format(self.project, self.dataset, self.table, limit)
        return self.execute_query(query)

3. 流式写入是否为更优实现方案 #

你的场景完全不适合用流式写入，不存在更优一说：

• 流式写入的适用场景是高并发、连续产生的实时数据（如埋点、日志实时上报），这类场景本身请求频率高，流式写入有独立的配额池，但高频调用同样可能触发限流
• 流式写入的数据会存在最长90分钟的流缓冲区，缓冲区的数据无法执行DELETE/UPDATE操作，做表比对时容易出现数据不一致问题
• 你的场景是一次性批量同步3万行规模的新增人员，用原生INSERT INTO ... SELECTSQL或者批量导入接口，在性能、成本、稳定性上都远优于流式写入。

只有当你需要每秒写入数百条以上数据、要求数据写入后秒级可查的实时场景时，才需要考虑使用流式写入。

内容的提问来源于stack exchange，提问作者Oleg Lysytskyi