这个处理器负责引导新表。它查找CDC配置以确定快照模式，并在需要时对启用CDC的表执行快照。为了对表进行快照，代理执行全表扫描，并将结果集中的每一行转换为单独的创建事件，然后依次将它们排队到内存中BlockingQueue．

这个处理器负责监视CDC目录中的新提交日志，并通过Cassandra的文件解析提交日志文件CommitLogReader，将反序列化的突变转换为标准化的更改事件，最后将它们编入与快照处理器相同的队列。

在这一点上，一些读者可能会考虑并发而不是串行地运行快照处理器和提交日志处理器。原因是卡桑德拉用了客户端时间戳以确定事件顺序，并解决与最后一次写入获胜的冲突。这个客户端时间戳故意存储在每个更改事件中。这就是快照不需要进行提交日志处理的原因——顺序稍后在数据仓库中查询数据时确定。

这个处理器负责将更改事件从队列中解出，并将它们转换为Avro并通过卡夫卡的制作人将它们发送给卡夫卡。它还跟踪最近发送的事件的位置，以便在重新启动时能够从它停止的地方开始。

在CDC代理中实现内存队列乍一看似乎有些过分。假设只有一个线程执行入队列操作，另一个线程执行出队列操作，性能提升可以忽略不计。这里的动机是将解析提交日志的工作(应该以正确的顺序连续完成)与序列化和发布Kafka事件的工作(可以由多个线程并行处理不同的表)分离开来。尽管目前还没有实现这种并行化，但我们希望在不久的将来能够灵活地添加该特性。

有些人可能也想知道为什么卡夫卡连接在这里不使用，因为它看起来很适合流。如果我们想要具有容错能力的分布式并行处理，这是一个很好的选择。然而，它的部署、监控和调试要比Kafka生成器复杂得多。为了构建最小可行的基础设施，我们当时选择了Kafka生成器。

为了支持自动模式演变，这个处理器周期性地轮询数据库以获得最新的表模式，如果检测到变化，就更新内存中的模式缓存。开云体育电动老虎机快照处理器和提交日志处理器都从这个缓存中查找表模式，并在进入队列之前将其作为更改事件的一部分附加。然后在出队列时，队列处理器将附加的表模式转换为Avro模式以进行记录序列化。

这个处理器负责在提交日志被处理后清理它们。默认的提交日志后处理器实现将简单地执行删除。可以为用例配置自定义提交日志后处理器，例如将提交日志文件归档到S3或GCS．

BigQuery视图是虚拟的这一事实意味着，每当查询该视图时，实际上都会触发原始数据的完整压缩。这意味着成本将随着查询数量的增加而增加，更不用说重复事件将需要处理的数据量放大了N倍，其中N是复制因子。为了节省成本和提高性能，通过物化视图来定期压缩是必要的。

在Cassandra 4.0中，改进的CDC特性允许连接器在写入事件时实时解析事件，而不是在每次提交日志刷新时以微批量解析事件。这大大降低了延迟。

正如前面提到的，有一个线程负责出队列、序列化和发布Kafka记录。但是，随着写吞吐量的增加，如果代理的性能没有跟上，则会导致未处理的提交日志积压，这可能会影响生产数据库的健康状况。开云体育电动老虎机下一步是利用事件的并行处理来优化性能。

我们最初将Cassandra CDC代理构建为一个独立的项目。既然它是开源的开云体育官方注册网址连接器，我们可以用Debezium中现有的类替换一些自定义类。开云体育官方注册网址另一个改进是支持所有Debezium连接器都具有的公共特性，比如支持多种序列化格式。开云体育官方注册网址最后，CDC代理没有容错能力;作为部署的一部分，需要强大的警报和监控。未来需要探索的一个领域是在Kafka Connect之上构建CDC代理作为源连接器，这进一步简化了Cassandra连接器与其他Debezium连接器的关系，并免费提供可伸缩性和容错性。开云体育官方注册网址

通过剥离除基本功能之外的所有功能，我们能够在合理的时间内用有限的资源构建、测试和部署一个工作解决方案。如果我们的目标是设计一个包含所有功能的管道，这将需要更长的时间和更多的资源。

Cassandra是一个开源项目。我们不是独自解决问题，而是从一开始就与Cassandra社区合作(即通过提交者和用户分享经验)聚会，在邮件列表中讨论提案，在会议上展示概念验证开云体育最新版等);所有这些都为我们在整个设计和实现阶段提供了有价值的反馈。