从Blob存储到Azure Table Storage的增量数据加载方案咨询

优先推荐：增量加载方案（兼容你熟悉的SQL水印逻辑） #

• 预先创建一张独立的同步控制表（同目标表存在一个Azure Table Storage账号下即可），固定分区键为sync_config，行键设为last_sync_watermark，值存储你业务中可用于判断增量的标识：优先选记录自带的递增唯一字段，比如创建时间、自增ID，无相关字段的话可以存储上一次同步时的Blob文件最后修改时间、文件内容哈希值。
• 同步任务触发后，第一步先读取控制表中的水印值，再拉取当前Blob存储中的最新全量文件，筛选出符合增量条件的记录：如果用记录创建时间当水印，仅筛选创建时间大于水印值的记录即可；如果用文件哈希当水印，需要拉取上一次同步备份的历史文件和当前文件做行级比对，提取差集作为增量数据。
• 增量数据写入目标Azure Table时，建议使用TableTransactionAction批量提交请求，单批次最多支持100条同分区键的操作，总大小不超过4MB，相比单条写入性能提升10倍以上。
• 增量数据全部写入成功后，更新控制表中的水印值为本次同步的最新标识，供下一次同步使用。

备选方案：全量Upsert同步（适合小数据量场景） #

如果你的单文件记录数长期低于10万条，且不想做增量逻辑开发，可以直接用这个极简方案：

• 同步时直接拉取当前Blob中的全量记录，按你设计的分区键、行键生成Azure Table实体。
• 调用Azure Table原生的UpsertEntity接口批量写入：该接口会自动判断分区键+行键的唯一组合是否存在，存在则更新整条记录，不存在则新增，无需提前做增量比对。
• 该方案开发成本仅为增量方案的30%，但数据量超过10万条后同步耗时会明显上升。

同步触发方式选择 #

• 低延迟场景：用Azure Event Grid订阅Blob容器的Blob Created事件，新文件上传覆盖旧文件时自动触发同步任务。
• 非实时场景：用定时触发器（Azure Functions、Azure Data Factory定时触发器均可）按固定周期（比如每日凌晨）执行同步。

关键注意事项 #

• 目标Azure Table的分区键要尽量选择离散度高的字段（比如客户所属区域、业务类型），避免出现热点分区导致读写性能下降，行键选择记录唯一标识即可。
• 批量操作要求单批次内所有实体的分区键完全一致，否则请求会被Azure Table直接拒绝。

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