resolve streaming data skew

思寇特牌搬砖工 2019-09-07 18:50:11

记录一下今天找到的这方面的资料

https://melmeric.files.wordpress.com/2014/11/the-power-of-both-choices-practical-load-balancing-for-distributed-stream-processing-engines.pdf

特别简单的算法,这方面研究的开山鼻祖,不过似乎效果很不错。大段大段的数学分析就直接跳过了。但是我对这个算法在我们真实环境的效果存疑,因为我们的热点数据基本上是集中出现在很短的时间段里的,还有一个担心,如果不幸算出来两个下游Task都是在同一台机器上,那么很可能没有实际的效果。

对应的storm和flink上的实现

https://github.com/gdfm/partial-key-grouping/blob/master/src/main/java/com/yahoo/labs/slb/PartialKeyGrouping.java

https://github.com/apache/flink/blob/a2429551c2e498383ed61a7e3650224c12ec3933/flink-staging/flink-streaming/flink-streaming-core/src/main/java/org/apache/flink/streaming/runtime/partitioner/PartialPartitioner.java

感觉flink团队太龟毛,完全是无厘头的理由拒了这个patch。

如果流上的热点是随着时间变化的,这种情况PKG不见得可以正确处理,于是有了这一篇论文。

https://arxiv.org/pdf/1806.00760.pdf

这篇文章专门针对时间序列上的热点做了很多优化,首先是一个基于时间衰减的data sketch算法找到局部的热点key,然后会根据key是否是热点,计算下游candidate数目,对于冷key,直接使用2,类似于PKG,而对于热key,会对比最热的key来确定发送下游candidate的数目。

然后这篇文章与众不同的地方来了,它不是单纯基于历史信息来决定最终发到哪个下游,而是估算出每个下游unprocessed item的数目,加上该下游的处理能力,来做这个决定,虽然文章的初衷是考虑下游异构,这在现在容器化一切的情况下很少有,但是这的确是一个更科学的方案。但是需要已知下游的capacity。我觉得这个还好,下游需要自己算,结果可以写zk,也可以创建一个kafka topic来记录。

其实这种思路我以前试过,用局部热点近似全局热点,可以是可以的,但是对于我们这样source被切成几百个partition的情况,单个partition只有全局的0.5%不到数据。,局部热点和全局有点儿差。当时我做了一个纯本地key group,比如storm上,一个worker进程里很多task,单个task的热点没有什么用。但是进程级别的热点还是有用的,就和全局热点差不多,这样子同一进程相同的key汇聚到一起,识别热key就方便多了。

思寇特牌搬砖工
作者思寇特牌搬砖工
12日记 12相册

全部回应 0 条

添加回应

思寇特牌搬砖工的热门日记

豆瓣
免费下载 iOS / Android 版客户端