随记12.07

美团做的storm：
https://tech.meituan.com/test_of_storms_reliability.html

WC的总字数：

image.png

大小：16GB
速率10000 tuple/s，耗时：
开始时间：1543325515912
结束时间：1543336799774
总耗时：3小时8分3秒862毫秒

kafka单线程无限制速率：

image.png

关闭ACK：
input 10000/s

[图片上传中...(image.png-8070f9-1543398774746-0)]

image.png

image.png

kafka的输入稳定在9.3k，即使设置为10k，所以吞出实际为9.3K左右

image.png

关闭ACK，速率10000，花费时间：
开始时间：1543395338096
结束时间：1543432644598
总耗时：10小时21分46秒502毫秒
配置为：

image.png

总量2：采集间隔5s

image.png

image.png

SPOUT.MAX.PENDING的尝试

input 1000
窗口3s，lag1s
max=6000， 5000， 4001，1000，都不正常工作，不输出，不count，理由，输出的tuple不够触发窗口，但是spout还存着，应该增大max

max=10000，正常工作，没有late tuple

image.png

吞吐：991

image.png

storm的metrics的另一种方法：
来源：https://github.com/apache/storm/blob/v1.2.1/examples/storm-starter/src/jvm/org/apache/storm/starter/FastWordCountTopology.java

image.png

image.png

stateful window

image.png

An example topology in storm starter StatefulWindowingTopology demonstrates the usage of IStatefulWindowedBolt to save the state of the windowing operation to avoid re-computation in case of failures. The framework internally manages the window boundaries and does not invoke execute(TupleWindow inputWindow) for the already evaluated windows in case of restarts during failures.

各种语义的理解：

故障恢复后的情况下，后面的计算会不会包含之前计算过的结果？

Storm 的wordcount 的event time 的window的两种版本

stateful window的链接：https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.5/bk_storm-component-guide/content/stateful-windowing.html
①无checkpoint：
window不使用.withMessageIdField("timestamp")，这样的话，之前处理完，过期了但是未到达acker的tuple会重新触发之前的window
②checkpoint：
window使用.withMessageIdField("timestamp")，这样的话，之前处理完，过期了但是未到达acker的tuple会不重新触发之前的window，因为记录了过期的ID。

image.png

storm的Guarantees

为何是至少一次保证，因为会重复计算，没有提供去重的保证

image.png

1000input，启动checkpoint

设置：max=10000，窗口3s，lag1s

image.png

1000input，10window，nocheckpoint

设置：max=50000，窗口10s，lag3s

正常运行的配置

经验总结：topology.max.spout.pending应该设置成比（size+lag）input rate3，一个spout一个partition的情况下。

input 1000, ack，10s+3s

开始时间：2018/12/3 15:9:51，1543820991839
配置：

image.png

运行情况：

image.png

image.png

image.png

手动关闭输入：2018.12.06.14:16:30,1544076990000

吞吐+延迟：

网络+cpu：
根据运行时间设置采集期限

1W，新集群

image.png

image.png

image.png

①跑flink，看看是不是storm的ACK的问题
②benchmark：复杂应用有自己的特征，分布式系统的容错，分布式数据库，流系统有什么特点
③物理核少，executor不能多，20核，总executor不能超过80个，一核最好4个task
④实验数据不跑完，吞吐没什么关系，一组实验跑20分钟够了
⑤代价和input rate成超线性关系