我想了解以下内容是否适用于Spark。
在消息队列或包含一批请求的文件中接收对应用程序的请求。对于消息队列,目前每秒大约有100个请求,尽管这可能会增加。有些文件只包含一些请求,但更常见的是数百甚至数千个。
每个请求的处理包括过滤请求,验证,查找参考数据和计算。一些计算引用了规则引擎。完成这些操作后,会向下游系统发送新消息。
我们希望使用Spark在多个节点之间分配处理,以获得可扩展性,弹性和性能。
我设想它会像这样工作:
上述声音是否正确,或者这不是使用Spark的正确方法?
由于
答案 0 :(得分:1)
我们在小型物联网项目上做了类似的工作。我们在3个节点上测试了每秒大约50K mqtt消息的接收和处理,这是轻而易举的。我们的处理包括解析每个JSON消息,对创建的对象进行一些操作以及将所有记录保存到时间序列数据库。 我们将批处理时间定义为1秒,处理时间约为300毫秒,RAM约为100sKB。 流媒体的一些问题。确保您的下游系统是异步的,这样您就不会遇到内存问题。它的真实,火花支持背压,但你需要实现它。另一件事,试图将状态保持在最低限度。更具体地说,您不应该保持随着输入增长而线性增长的任何状态。这对您的系统可扩展性非常重要。
最令我印象深刻的是你可以轻松扩展火花。随着我们添加的每个节点,我们可以处理的消息频率呈线性增长。我希望这会有所帮助。 祝你好运