Kafka在producer vs topic设置压缩类型
方法1：使用以下命令创建主题：
bin/kafka-topics.sh --create --zookeeper localhost:2181 --config compression.type=gzip --topic test
方法2：在Kafka Producer客户端API中设置属性compresson.type=gzip。
当使用方法1时，我得到了更好的压缩和更高的吞吐量。
如果我使用方法1，这是否意味着压缩发生在broker端，而在方法2中，消息在Producer端压缩，然后发送给broker？
共有1个答案
如果我使用方法1，是否意味着压缩发生在代理端？
看情况.如果生产者没有设置compression.type或设置一个不同的，那么消息将在代理端被压缩。但是，如果producer还将compression.type设置为gzip，则不需要在代理端再次压缩。实际上，为了确保不需要压缩，还必须满足其他严格的条件，尽管这有点超出了范围。
在方法2中，消息在生产者端被压缩，然后发送给代理？
-
使用Kafka Streams，我们无法确定在处理写入接收器主题的消息后压缩这些消息所需的配置。 另一方面，使用经典的Kafka Producer，可以通过在KafkaProducer属性上设置配置“compression.type”轻松实现压缩 然而，似乎没有任何记录在案的Kafka Streams压缩处理过的消息的例子。 至于这次（2019年初），有没有一种方法可以使用Kafka流进行压缩？
-
当我向Kafka主题发送消息时，我可能会收到一条比其他消息大得多的消息。 因此需要在单消息级进行压缩。根据https://cwiki.apache.org/confluence/display/kafka/compression, 一组消息可以被压缩并表示为一个压缩消息。 同样,根据https://github.com/apache/kafka/blob/0.10.1/clients/src/ma
-
我在《掌握Kafka Streams and ksqlDB》一书中遇到了以下两个短语，作者使用了两个术语，它们的真正含义是“压缩主题”和“未压缩主题” 他们对“日志压缩”有什么看法吗？ 表可以被认为是对数据库的更新。在日志的这种视图中，只保留每个键的当前状态（给定键的最新记录或某种聚合）。表通常是从压缩的主题构建的。 用数据库的说法，流可以被视为插入。每个不同的记录都保留在此日志视图中。流通常是从
-
我在producer端启用了snappy压缩，批量大小为64kb，处理每个1KB的消息，并将延迟时间设置为inf，这是否意味着在我处理64条消息之前，producer不会将消息发送给kafka out topic。。。Kafk64将发送一条消息，或每一个消息的制作人将发送另一个消息。。。 因为偏移量一个接一个地增加，而不是64的倍数 编辑-使用flink-kafka连接器
-
本文向大家介绍Linux Apache设置压缩及缓存，包括了Linux Apache设置压缩及缓存的使用技巧和注意事项，需要的朋友参考一下 压缩文件： 编辑apache模块 vim /etc/httpd/conf.modules.d/00-base.conf 确保以下三个模块没有被注释 LoadModule headers_module modules/mod_headers.so LoadMod
-
我收到了一个数据库更改流，这些更改最终形成了一个压缩的主题。流基本上是键/值对，并且键空间很大(~4 GB）。 这个主题由一个kafka流进程使用，该进程将数据存储在RockDB中（每个消费者/碎片单独使用）。处理器做两件不同的事情： 将数据连接到另一个流中。 检查来自主题的邮件是新密钥还是对现有密钥的更新。如果是更新，则将旧的键/值和新的键/值对发送到不同的主题（更新很少）。 null