关于准实时流数据处理问题

[alexfarm]

场景：生产上有很多客服和用户的会话数据，上游系统通过 kafka 给到我们，我们会对数据做些处理便于运营人员查询会话数据。 实时性：生产 30 分钟后，运营能查询到数据即可，这应该算个准实时场景吧。 问题：其中一个就是调用机器学习模型产出一些标签，目前的处理方式是单通对话同步请求模型得到结果再持久化。算法工程师说并发高的时候离线模型压力比较大，希望数据能平稳点请求模型。 现在就是几个方案，因为上游数据是从 kafka 消费到的，要么控制好消费者的数量，每次请求都同步等待，但感觉比较挫且不易扩展。或者就是用流数据计算框架，但是没什么实战经验。想问问大家有没有什么好的方案。

[MinQ]

batch 呗，比如数据每 10s 且每 100 个一起输入模型

[alexfarm]

@MinQ 10 秒的时间窗口不大好控制 batch size 啊。而且这个有点 spark streaming 的意思，是不是可以用这个去实现?

[bigmercu]

可以考虑使用 structured streaming,参考
https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html#creating-streaming-dataframes-and-streaming-datasets
Rate Source
应该可以实现控制消费数量或时间。

[MinQ]

@alexfarm 时间到了去取，每次取前 100 个，不够的话全部取出

[MinQ]

@alexfarm 本质上就是借鉴了消息队列的削峰填谷的用处

[tairan2006]

Spark 就行

[alexfarm]

@tairan2006 就是感觉没有很多计算的工作，用 spark 有点怪怪的

[alexfarm]

@MinQ 一开始也是这样设计的，但是请求时候是同步等待的，等下游模型处理完了再去取一些数据

[MinQ]

所以你这个是有两个模型，第一个模型会先调用第二个模型，然后等第二个模型处理完了第一个模型才能得到输入所需要的数据？

[alexfarm]

@MinQ 两个模型不相关的，之所以同步等待，还是想匹配上模型处理的速度，不然会堆积许多的请求

[MinQ]

@alexfarm 那为啥不完全设计成异步的形式，同步等待难道性能不是取决于最慢的那个模型，不是会堆积更多的请求？

[alexfarm]

@MinQ 这样这些数据是堆积在消息系统中的。如果异步的话，算法前面没有缓冲的地方，应该自身的线程池满了就挂了

[owenliang]

flink，window 。

[MinQ]

@alexfarm 不明白，消息队列本身不就是缓冲么？

[alexfarm]

@MinQ 我们是中间层，消费消息队列里的数据做一次处理，然后再调用算法层的，算法层之前没有消息队列做缓存的。我说的同步或者异步是中间层调用算法层的。本身生产数据和中间层已经通过消息队列解耦了