建议的方法确实是将查找数据也摄取到kafka中——例如通过kafka connect——正如您在上面建议的那样。
但在这种情况下，如何安排connect作业每天运行，而不是从源表连续获取数据（在我的情况下不需要这样做）？
也许你可以更新你的问题你不想有一个连续的Kafka连接作业运行？您是否关心资源消耗（数据库上的负载），如果不是“每日udpates”，您是否关心处理的语义，或者。。。？
更新：正如Kafka建议的那样，连接将是一种方式。因为查找数据每天都会在rdbms中更新，所以我考虑将kafka connect作为一个预定的一次性作业来运行，而不是始终保持连接处于打开状态。是的，因为语义和保持连接始终打开并确保它不会被中断的开销…等等。对我来说，在这种情况下，有一个预定的提取看起来更安全。
kafka connect是安全的，而jdbc连接器的构建正是为了以健壮、容错和高性能的方式将db表提供给kafka（已经有许多产品部署）。因此，我建议不要因为“看起来更安全”而退回到“批量更新”模式；就我个人而言，我认为触发每日摄入比保持连续（实时）运行更不方便对于您的实际用例，它也会导致一些不利因素（见下一段）。
但当然，你的里程数可能会有所不同——所以如果你打算每天只更新一次，那就去吧。但是您失去了a）在扩展发生的时间点用最新的db数据丰富传入记录的能力，并且相反地，b）您可能实际上用过时/旧数据丰富传入记录，直到下一次每日更新完成为止，这很可能会导致错误的数据，您正在向下游发送/提供给其他应用程序以供使用。例如，如果客户更新其配送地址（在数据库中），但您每天仅向流处理应用程序（可能还有许多其他应用程序）提供一次此信息，则订单处理应用程序会将包裹运送到错误的地址，直到下一天的摄取完成。
查找数据不大，可能会删除/添加/修改记录。我也不知道我怎么能总是有一个完整的转储到Kafka主题和截断以前的记录。启用日志压缩并为已删除的键发送空值可能不起作用，因为我不知道源系统中删除了什么。
kafka connect的jdbc连接器已经为您自动处理了这个问题：1。它确保db insert/updates/deletes正确地反映在kafka主题中。Kafka的日志压缩确保目标主题不会超出范围。也许您需要阅读文档中的jdbc连接器，以了解您可以免费获得哪些功能：http://docs.confluent.io/current/connect/connect-jdbc/docs/ ?