[ https://issues.apache.org/jira/browse/KAFKA-2092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589634#comment-14589634 ]
Gianmarco De Francisci Morales edited comment on KAFKA-2092 at 6/22/15 8:42 AM: -------------------------------------------------------------------------------- Thanks for your comment [~jkreps]. Indeed, this uses the load estimated at the producer to infer the load at the consumer. You might think this does not work but indeed it does in most cases (see [1] for details). I am not sure whether the lifecycle of the producer has any impact here. The goal is simply to send balanced partitions out of the producer. Regarding the key=>partition mapping, yes this breaks the 1 key to 1 partition mapping. That's exactly the point, to offer a new primitive for stream partitioning. If you are doing word count you need a final aggregator as you say, but the aggregation is O(1) rather than O(W) [where W is the number of workers, i.e., parallelism of the operator]. Also, if you imagine building views out of these partitions, you can query 2 views rather than 1 to obtain the final answer (again, compared to shuffle grouping where you need W queries). I disagree with your last point (and the results do too). Given that you have 2 options, the imbalance is reduced much more than just by 2 times, because you create options to offload part of the load on a heavy partition to the second choice, thus creating a network of "backup/offload" options to move to when one key becomes hot. It's as creating interconnected pipes where you pump a fluid into. What is true is that if the single heavy key is larger than (2/W)% of the stream, then this technique cannot help you to achieve perfect load balance. was (Author: azaroth): Thanks for your comment [~jkreps]. Indeed, this uses the load estimated at the producer to infer the load at the consumer. You might think this does not work but indeed it does in most cases (see [1] for details). I am not sure whether the lifecycle of the producer has any impact here. The goal is simply to send balanced partitions out of the producer. Regarding the key=>partition mapping, yes this breaks the 1 key to 1 partition mapping. That's exactly the point, to offer a new primitive for stream partitioning. If you are doing word count you need a final aggregator as you say, but the aggregation is O(1) rather than O(W) [where W is the number of workers, i.e., parallelism of the operator]. Also, if you imagine building views out of these partitions, you can query 2 views rather than 1 to obtain the final answer (again, compared to shuffle grouping where you need p queries). I disagree with your last point (and the results do too). Given that you have 2 options, the imbalance is reduced much more than just by 2 times, because you create options to offload part of the load on a heavy partition to the second choice, thus creating a network of "backup/offload" options to move to when one key becomes hot. It's as creating interconnected pipes where you pump a fluid into. What is true is that if the single heavy key is larger than (2/W)% of the stream, then this technique cannot help you to achieve perfect load balance. > New partitioning for better load balancing > ------------------------------------------ > > Key: KAFKA-2092 > URL: https://issues.apache.org/jira/browse/KAFKA-2092 > Project: Kafka > Issue Type: Improvement > Components: producer > Reporter: Gianmarco De Francisci Morales > Assignee: Jun Rao > Attachments: KAFKA-2092-v1.patch > > > We have recently studied the problem of load balancing in distributed stream > processing systems such as Samza [1]. > In particular, we focused on what happens when the key distribution of the > stream is skewed when using key grouping. > We developed a new stream partitioning scheme (which we call Partial Key > Grouping). It achieves better load balancing than hashing while being more > scalable than round robin in terms of memory. > In the paper we show a number of mining algorithms that are easy to implement > with partial key grouping, and whose performance can benefit from it. We > think that it might also be useful for a larger class of algorithms. > PKG has already been integrated in Storm [2], and I would like to be able to > use it in Samza as well. As far as I understand, Kafka producers are the ones > that decide how to partition the stream (or Kafka topic). > I do not have experience with Kafka, however partial key grouping is very > easy to implement: it requires just a few lines of code in Java when > implemented as a custom grouping in Storm [3]. > I believe it should be very easy to integrate. > For all these reasons, I believe it will be a nice addition to Kafka/Samza. > If the community thinks it's a good idea, I will be happy to offer support in > the porting. > References: > [1] > https://melmeric.files.wordpress.com/2014/11/the-power-of-both-choices-practical-load-balancing-for-distributed-stream-processing-engines.pdf > [2] https://issues.apache.org/jira/browse/STORM-632 > [3] https://github.com/gdfm/partial-key-grouping -- This message was sent by Atlassian JIRA (v6.3.4#6332)