4 ms·

Can it rebalance partitions? And delete crap from topics? Every time we have to call up our ops guys for this; it’s like “deep breath, first utter some indescr

Can it rebalance partitions? And delete crap from topics? Every time we have to call up our ops guys for this; it’s like “deep breath, first utter some indescribable magic aws iam nonsense and somehow get an ephemeral shell on some rando bitnami Kafka image’s ./kafka-topic shell scripts to work over the next few hours” and ultimately succeed but with deep regrets

rockwotj 2y ago
> delete crap from topics You have to rewrite the whole topic to do this right? (or do some hacks with compaction if you have unique keys)
- bink 2y ago
  Or just advance the offsets for that partition beyond the problematic data, or adjust retention, or both.
  - nick0garvey 2y ago
    There is also the deleteRecords API specifically for this. It's easier than the retention shrink -> increase dance, as it is a single API call and retention does not kick in immediately. The log segment must roll for retention to apply, either due to size or time. https://kafka.apache.org/11/javadoc/org/apache/kafka/clients/admin/AdminClient.html#deleteRecords-java.util.Map- https://kafka.apache.org/11/javadoc/org/apache/kafka/clients...
sauljp 2y ago
Hi! kaskade is more like AKHQ than Cruise control. We use strimzi by default, so we deploy cruise control with kafka, and it takes care of rebalancing the data across the nodes. Also you can deploy it without strimzi. Delete crap is more complicated, usually with kafka-delete-records (this is king of new I think). The problem is the offsets. By general rule you should not delete data from topics
kvakerok 2y ago
If you have to manually delete data from topics, you are doing Kafka wrong. The whole point of it is high speed data throughput, so that something automated does it for you downstream.
- sauljp 2y ago
  Totally agree
- otabdeveloper4 2y ago
  Seems like a ./kafka-topic shell script is their "something automated". [Pro tip: kafka is a piece of shit architecture and actually doesn't provide you with anything better.]
  - cosmic_quanta 2y ago
    > kafka is a piece of shit architecture Hmmm interesting. I have only seen people rave about it, but haven't used it myself. Why is it shit architecture?
    - sauljp 2y ago
      I do not think it is a shit arch. I think that is an arch for some problems, but people insist on using it for uses cases it was not built for.
    - otabdeveloper4 2y ago
      A message queue has one (1) job: to keep track of the already-processed message pointer. Which Kafka doesn't do. So you either store everything forever (lol) or you write some sort of broken half-baked solution for a message queue on top of Kafka. (Broken and half-baked because you're not going to achieve fault tolerance or consistency without re-implementing the storage layer.) Now, you're just gonna say that "Kafka isn't a message queue". Well, I don't need half of a solution that isn't even a message queue. Nobody needs that.
      - 2y ago

rockwotj 2y ago

> delete crap from topics You have to rewrite the whole topic to do this right? (or do some hacks with compaction if you have unique keys)

bink 2y ago
Or just advance the offsets for that partition beyond the problematic data, or adjust retention, or both.
- nick0garvey 2y ago
  There is also the deleteRecords API specifically for this. It's easier than the retention shrink -> increase dance, as it is a single API call and retention does not kick in immediately. The log segment must roll for retention to apply, either due to size or time. https://kafka.apache.org/11/javadoc/org/apache/kafka/clients/admin/AdminClient.html#deleteRecords-java.util.Map- https://kafka.apache.org/11/javadoc/org/apache/kafka/clients...

sauljp 2y ago

Hi! kaskade is more like AKHQ than Cruise control. We use strimzi by default, so we deploy cruise control with kafka, and it takes care of rebalancing the data across the nodes. Also you can deploy it without strimzi. Delete crap is more complicated, usually with kafka-delete-records (this is king of new I think). The problem is the offsets. By general rule you should not delete data from topics

kvakerok 2y ago

If you have to manually delete data from topics, you are doing Kafka wrong. The whole point of it is high speed data throughput, so that something automated does it for you downstream.

sauljp 2y ago
Totally agree
otabdeveloper4 2y ago
Seems like a ./kafka-topic shell script is their "something automated". [Pro tip: kafka is a piece of shit architecture and actually doesn't provide you with anything better.]
- cosmic_quanta 2y ago
  > kafka is a piece of shit architecture Hmmm interesting. I have only seen people rave about it, but haven't used it myself. Why is it shit architecture?
  - sauljp 2y ago
    I do not think it is a shit arch. I think that is an arch for some problems, but people insist on using it for uses cases it was not built for.
  - otabdeveloper4 2y ago
    A message queue has one (1) job: to keep track of the already-processed message pointer. Which Kafka doesn't do. So you either store everything forever (lol) or you write some sort of broken half-baked solution for a message queue on top of Kafka. (Broken and half-baked because you're not going to achieve fault tolerance or consistency without re-implementing the storage layer.) Now, you're just gonna say that "Kafka isn't a message queue". Well, I don't need half of a solution that isn't even a message queue. Nobody needs that.
    - 2y ago