限制项 | 说明 |
任务并行度 | 数据接入、处理、转储底层都是多个子任务(worker)并发运行的。默认情况下,worker 并行度为1。系统会自动检查上有数据是否有堆积,当有堆积时会自动扩容运行 worker 数,以提高任务处理能力。当前阶段,worker 数的上限 = kafka Topic 的分区数。worker 数用户不可配置,系统会自动扩缩容 worker。 |
任务吞吐性能 | CKafka 连接器是以任务形态进行,其任务性能依赖上下游组件的服务能力。如上游是 Kafka > DIP > Elasticsearch 链路。当上下游无性能瓶颈时,DIP 会通过调整任务并行度来提高数据处理能力,当上下游有性能瓶颈时,则数据的流转耗时会相应增加。客户可以通过查看监控指标和配置堆积告警等手段来发现瓶颈。 |
任务数量 | |
连接数量 | |
主题数量 | |
Schema 数量 | |
HTTP 接入 QPS 限制 | |
数据上报每批次数据总大小 | HTTP 数据上报的每批次上报的数据大小最大为5MB,超过该数据大小就会报错。 |
数据上报每批次数据条数 | HTTP 数据上报的每批次上报的数据条数最大为500条,超过该数据大小就会报错。 |
极端情况任务数据丢失 | 数据处理和数据流出任务本质上是创建 CKafka 生产者或消费者,对选定的任务数据源 topic 进行生产消费。 当消费成功,即数据成功投递到数据目标资源后,任务对应的消费者组(datahub-<任务ID>)才会提交数据对应的消息 offset。但如果任务在成功投递数据后,在提交 offset 前出现异常情况而导致重启,此时数据将会被重复投递到目标资源中。因此建议使用者在业务逻辑代码中对于极端情况做好幂等性等处理。 当消息还未被成功消费,但消息已经到了设置的消息最大保留时间(包括动态消息保留策略,以及手动设置的 topic 的消息保留策略)而被提前删除时,任务将无法消费这部分过期消息,导致数据目标缺少这部分消息对应的数据。 |
本页内容是否解决了您的问题?