如何通过Azure Function等方式捕获Cosmos DB变更数据用于离线ETL

嘿，这个需求我太有发言权了！要实现类似Oracle离线重做日志的Cosmos DB变更捕获，同时完全不影响在线业务的读写性能，咱们可以从这几个经过实践验证的方案入手：

Cosmos DB原生的Change Feed就是为增量变更捕获量身打造的，它后台默默记录所有插入、更新（替换）操作，现在还支持跟踪删除操作，完全不占用主库的读写RU，对在线业务零干扰。

• 如果你需要定时批量处理（而非实时），可以用Azure Functions的定时触发器：每次触发时，读取从上一次处理到当前的所有变更数据。核心是要做好**检查点（Checkpoint）**管理——把最后处理的Continuation Token存在Azure Blob或一个小型Cosmos DB集合里，这样每次任务启动都能从上次停下的位置继续，不会重复或遗漏数据。
• 要是你后期想改成实时处理，只需要把定时触发器换成Change Feed专用触发器就行，无缝切换，非常灵活。

如果你的ETL不需要准实时，只是每天/每周的离线批量分析，那用Cosmos DB的备份机制就最省心了：

• 利用Cosmos DB的连续备份（支持任意时间点恢复）或定期全量备份，通过定时任务（比如Azure Automation或Azure Functions）定期恢复出一个只读副本库。
• 所有ETL和分析操作都在这个副本库上进行，完全和主库隔离，绝对不会影响在线业务的性能。唯一的缺点是延迟较高，适合对实时性要求不高的场景。

如果需要更细粒度的控制（比如自定义日志格式、记录删除操作的完整上下文），可以在你的业务API层做文章：

• 每次完成Cosmos DB的读写操作后，异步写入一条变更日志到Azure Event Hub或Blob Storage里——一定要用异步方式，比如用Event Hub的批量异步发送，绝对不能让日志写入阻塞主业务流程。
• 之后用定时任务从这个存储中批量拉取日志进行ETL处理，主库的性能完全不受影响。

• RU消耗控制：读取Change Feed时，记得设置MaxItemCount参数，避免一次性读取过多数据导致不必要的RU消耗（虽然Change Feed的RU不占用主库配额，但合理配置能降低成本）。
• 删除操作处理：默认Change Feed不跟踪删除，所以要么开启Cosmos DB的软删除（设置TTL，标记为删除状态而非直接删除），要么在创建容器时开启删除跟踪功能。
• 检查点持久化：千万别忽略检查点的存储，不然每次定时任务启动都会从头读取Change Feed，效率极低。如果用Azure Functions的Change Feed触发器，它会自动帮你管理检查点；如果是自定义定时处理，一定要手动把Continuation Token存起来。

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