周一早上，群里转来十几条产品更新。
有人说 BigQuery 能把表同步进 AlloyDB 了，有人说 Looker 的 AI 问数终于能看到 token 用量。再往下翻，还有数据库故障抓取、Kafka 权限日志和时序库备份。
每一条都像该收藏。收藏夹也很配合，安静地躺着两千多条“以后有空再看”。
不过，这周的 5 条更新放在一起，倒有一条很清楚的线：数据平台不只是在增加功能，也在补“发生过什么”的证据。数据同步要能解释新旧边界，AI 问数要能看到消耗，故障要留下现场，拒绝访问要能追到客户端，备份则要真的恢复得出来。
下周不必把 5 个开关都打开。挑离生产最近的一项，做一次小范围验证，比在群里发五张产品截图有用。
BigQuery 数据回到 AlloyDB：先问清楚“同步”是哪一种
8 月 7 日，Google Cloud 在发布说明中加入 BigQuery 到 AlloyDB 的数据同步预览。
团队可以把 BigQuery 表一次性复制进 AlloyDB，也可以设置周期同步。一次性同步得到的是可写的独立副本；周期同步得到的是只读本地表，可按小时、6 小时或更长间隔刷新。与直接通过 foreign data wrapper 远程查询不同，这条路径会把数据搬进 AlloyDB 存储，换取更低延迟的事务访问。
这对“仓库里已经算好，业务系统又需要低延迟读取”的场景很有吸引力。例如，运营系统要按客户分群给出优惠，画像和分群每天在 BigQuery 更新，而应用希望像查 PostgreSQL 本地表一样读取结果。
可是，“同步”这个词有一种职业病：听起来总比实际更实时。
官方文档把边界写得很具体。当前功能仍是预览，只支持 PostgreSQL 18。周期表是只读的；同步会消耗 AlloyDB 的 CPU 和内存；如果使用 replace，旧目标表会先被删除再重建，查询者可能短暂看到空表，随后才看到分批写入的数据。BigQuery Storage Read API 和 AlloyDB 存储也会分别计费。
所以，下周如果团队准备试，不妨先做四件事：
- 写清业务真正需要的是一次性导入、每小时镜像，还是实时查询，不要让“同步”替大家做决定。
- 选一张可以重算的小表，在低峰期执行一次 replace，记录空窗、完成时间和资源变化。
- 对比源表与目标表的行数、主键、更新时间和关键金额，不只看任务状态显示成功。
- 主动取消一次任务，再按官方方式删除同步表，确认后台调度不会留下孤儿任务。
复制一张表不难。难的是让使用它的人知道，这张表此刻代表哪个时间点。
Looker 开始记 token：AI 问数终于多了一本账
8 月 3—5 日，Google Cloud 为 Looker 26.12 逐步启用一批更新。其中一项预览能力，是给 Conversational Analytics 增加使用与 token 可观测信息。
管理员启用后，可以在系统活动看板里看到预估输入 token、输出 token、每日用量，以及哪些数据 Agent 消耗最多。输入不只包括用户的问题，还包括对话历史、元数据和 Agent 指令；输出则包括自然语言答案、生成的 API 调用或 SQL，以及可视化内容。
这个变化很小，却补上了 AI 问数上线后经常缺的一本账。
以前团队讨论 AI 成本，容易停在“每次问答大概几分钱”。可同一句“昨天华东销售多少”，如果 Agent 带上了一长段模型说明、几十张表的元数据和完整聊天历史，成本与延迟都可能悄悄长大。问题本身只有 8 个字，送进模型的行李倒像搬家。
不过，官方也提醒了两个边界：这项能力仍是预览，token 看板每 24 小时刷新一次；它记录的是估算用量，不是逐次问答的实时计费器。它适合找趋势、找大户，不适合拿来做一笔账的最终结算。
下周可以先做一个很朴素的基线：
- 选 20 个高频业务问题，记录回答质量、查询耗时和预估 token。
- 把最贵的 3 个问题拆开看：是聊天历史过长，还是元数据、指令或生成结果太大。
- 精简一项上下文后重跑，只改一个变量，比较质量有没有下降。
- 同时保留 SQL、数据源和答案，避免把“token 少了”误当成“系统更好了”。
AI 问数的成本，不该只在云账单月底出现。它应该和正确率、延迟一起进入日常验收。
Cloud SQL 会抓故障现场：告警之后不再只剩一条曲线
8 月 5 日，Google Cloud 宣布 Cloud SQL for MySQL 的 Performance Capture 正式可用。
它会监控数据库指标。当 CPU、内存、临时文件、历史链表长度、信号量等待、事务锁等待或长事务等条件持续越过阈值时，自动执行诊断命令，把当时的数据库和操作系统快照写进 Cloud Logging。
默认探测间隔是 30 秒，连续 3 次满足条件才触发完整抓取，用来避开短暂尖峰。成功抓取后还有 30 分钟冷却期；如果同一问题反复触发，冷却时间会逐步拉长，避免诊断日志自己变成新的麻烦。
这件事解决的是值班同事很熟悉的尴尬：凌晨 2 点收到 CPU 95% 告警，等人连上数据库时已经恢复。监控曲线能证明“刚才很忙”，却不告诉你当时有哪些锁等待、长事务和查询。
下周不要一上来把所有阈值都设满。先挑一类过去真的发生过的故障，例如长事务或副本延迟，用历史数据定阈值；然后在测试实例制造一次可控问题，确认日志里有没有足够信息回答“谁在等、等什么、持续多久”。
还要留意成本边界。Performance Capture 本身不另收费，但日志进入 Cloud Logging，存储仍可能产生费用。故障证据应该比告警更完整，也不能完整到把日志桶撑成第二个事故。
MSK 记录拒绝访问：Kafka 权限问题终于能找到客户端
8 月 6 日，AWS 为 Amazon MSK Provisioned 集群增加 Kafka Authorizer Log Delivery，Standard 和 Express brokers 都支持，功能本身不额外收费。
每一次被拒绝的授权请求会记录客户端 IP 和尝试调用的 API。日志可以送到 CloudWatch Logs、S3 或 Data Firehose，新旧 Provisioned 集群都能启用。
过去处理 Kafka 权限问题，开发同事常只带来一句：“消费者突然读不到了。”数据平台再去猜是 topic 名写错、ACL 少了一条、账号换了，还是客户端连到了不该去的集群。现在至少能从拒绝日志里看到谁从哪里来，想做什么。
下周可以做一次拒绝测试：
- 用测试身份请求一个明确无权访问的 topic。
- 确认日志能落到预期目的地，并能按客户端 IP、API 和时间搜索。
- 核对日志保存期限、访问权限和敏感字段，别让安全日志反过来成为无人管理的数据。
- 把一条真实拒绝记录接进值班手册，写清谁负责判断、谁能改 ACL、改完如何复测。
有日志不等于权限治理完成。它只是让“读不到”从一句抱怨变成一条能继续追查的证据。
Timestream for InfluxDB 补上备份恢复：别只验证“备份成功”
8 月 7 日，Amazon Timestream for InfluxDB 增加客户可控的备份与恢复，InfluxDB 2 和 InfluxDB 3 引擎都支持。
团队可以做一次性备份，也可以给每个资源设置最多 4 组自动备份计划，分别选择小时、天、周、月或自定义周期与保留时间。第一次是完整备份，之后使用增量备份。恢复时既可以创建一个继承源配置的新资源，也可以替换现有资源。
这是一个很实用的补丁。时序库常放着监控指标、设备数据和业务事件，一到迁移、参数调整或版本变化，大家都会说“先备份一下”。至于恢复需要多久、恢复后少不少数据，往往留给真正出事那天再研究。这种安排很公平：事故已经够忙了，再临时加一场学习。
下周如果团队在用这项服务，先别把“备份任务成功”当作结束。挑一段非关键数据做一次恢复演练，记录恢复点、耗时、目标资源配置和最新数据时间；再跑几条固定查询，比较时间范围、序列数量与抽样结果。
备份是一份承诺。恢复演练才是验收。
拾穗解读：这周真正值得做的，是补一张证据清单
把这 5 条消息放在一起，会发现平台正在替团队保留越来越多的中间事实。
BigQuery 到 AlloyDB 不只给出一个目标表，还给出同步任务和刷新状态；Looker 不只返回答案，也开始记录上下文与输出的 token 用量；Cloud SQL 保存故障发生时的状态；MSK 留下被拒绝的客户端和 API；Timestream 则把备份变成可按计划管理的对象。
这些能力不会自动让系统可靠。它们只是让可靠性少依赖一点记忆，多依赖一点能复查的东西。
如果下周只能做一个动作，我建议选离你最近的一条链路，补一张四栏清单：
- 触发：什么时候同步、抓取、记录或备份。
- 证据：任务状态、日志、快照、用量或校验结果存在哪里。
- 验收：怎样证明结果完整、权限正确、成本可接受、恢复可用。
- 责任：失败以后谁判断，谁处理，什么时候复测。
纸不必漂亮。能在周一早上的群里少问一句“应该没问题吧”，它就已经值回工钱。
我叫石头，在数据行业里摸爬滚打了十几年，越来越相信好系统会替人留下证据。这里写的，就是这些教训——我觉得值得说出来的那部分。
一手来源：
- Google Cloud release notes：AlloyDB sync、Looker Conversational Analytics 与 Cloud SQL Performance Capture · 2026-08-05—2026-08-07
- Google Cloud：Sync BigQuery data to AlloyDB · 2026-08-07
- Google Cloud：Cloud SQL performance capture overview · 2026-08-04 更新，2026-08-05 宣布 GA
- Google Cloud：Looker System Activity dashboards — Conversational Analytics · 2026-08-05 发布说明
- AWS：Amazon MSK now delivers Kafka Authorizer Logs to customers · 2026-08-06
- AWS：Amazon Timestream for InfluxDB now supports backup and restore · 2026-08-07
