我正在尝试部署Google Cloud Dataflow管道,该管道从Kafka集群读取数据,处理其记录,然后将结果写入BigQuery。但是,在尝试部署时,我总是遇到以下异常:
org.apache.kafka.common.errors.TimeoutException: Timeout expired while fetching topic metadata for Kafka Cluster
Kafka集群需要使用JAAS配置进行身份验证,并且我使用以下代码来设置KafkaIO.read Apache Beam方法所需的属性:
// Kafka properties
Map<String, Object> kafkaProperties = new HashMap<String, Object>(){{
put("request.timeout.ms", 900000);
put(CommonClientConfigs.SECURITY_PROTOCOL_CONFIG, "SASL_PLAINTEXT");
put(SaslConfigs.SASL_MECHANISM, "SCRAM-SHA-512");
put(SaslConfigs.SASL_JAAS_CONFIG, "org.apache.kafka.common.security.scram.ScramLoginModule required username=\"USERNAME\" password=\"PASSWORD\";");
put(CommonClientConfigs.GROUP_ID_CONFIG, GROUP_ID);
}};
// Build & execute pipeline
pipeline
.apply(
"ReadFromKafka",
KafkaIO.<Long, String>read()
.withBootstrapServers(properties.getProperty("kafka.servers"))
.withKeyDeserializer(LongDeserializer.class)
.withValueDeserializer(StringDeserializer.class)
.withTopic(properties.getProperty("kafka.topic")).withConsumerConfigUpdates(kafkaProperties))
数据流管道将在禁用公共IP的情况下进行部署,但是从我们的Google Cloud VPC网络到Kafka集群已建立了VPN隧道,并且配置了双方专用ip所需的路由并将其IP列入了白名单。我可以使用Compute Engine VM在与要部署的Dataflow作业相同的VPN子网中ping并连接到Kafka服务器的套接字。
我一直认为配置存在问题,但是我无法弄清楚是否缺少其他字段,或者现有配置中的一个配置错误。有没有人知道我可以进一步诊断问题,因为抛出的异常并不能真正查明问题所在?任何帮助将不胜感激。
编辑: 现在,我现在可以成功地部署Dataflow作业,但是看起来好像读取工作不正常。查看日志以检查Dataflow作业中的错误后,我可以看到发现kafka主题的组协调器后,在警告日志语句之前说没有空闲的读取器关闭超时的警告,没有其他日志语句了:
Close timed out with 1 pending requests to coordinator, terminating client connections
之后是未捕获的异常,其根本原因是:
org.apache.kafka.common.errors.TimeoutException: Timeout of 60000ms expired before the position for partition test-partition could be determined
然后会显示错误消息:
Execution of work for P0 for key 0000000000000001 failed. Will retry locally.
由于Kafka主题实际上在消息中没有键,这可能与键定义有关吗?当我在Kafka工具中查看主题时,数据中观察到的唯一列包括“偏移”,“消息”和“时间戳”。
答案 0 :(得分:0)
根据最近的评论,我认为您在网络堆栈方面遇到的更多的问题,然后从执行与Kafka代理的Dataflow作业运行程序连接方面开始寻找Dataflow管道中缺少的任何配置。
基本上,当您为数据流工作人员使用Public IP地址池时,您无需通过额外的配置即可访问外部Kafka集群,而无需额外配置即可使用{{3} }之间进行日常网络工作,以使所有路由正常工作。
但是,VPC network带来了更多的复杂性,双方都实现了VPC网络,并进一步调整了该VPC的VPN网关,转发规则和地址池。相反,从Dataflow运行时的角度来看,您不需要在Dataflow运行者之间分配公共IP地址,而无疑会降低价格。
您提到的主要问题在于Kafka集群方面。由于Cloud VPN是一个分布式系统,因此它具有以下核心原则:生产者/消费者执行时,它将请求有关哪个代理是分区领导者的元数据,并接收具有该分区可用端点的元数据,因此,客户端随后确认这些端点以连接到特定代理。据您了解,与领导者的连接是通过绑定到外部网络接口的 listener 执行的,该接口是在server.properties
代理人Apache Kafka中配置的。
因此,您可能会考虑在绑定到云VPC网络接口的listeners
中创建一个单独的侦听器(如果不存在),并在必要时使用返回到客户端的元数据传播advertised.listeners
,由用于连接到特定代理的数据组成。