流式计算还有什么研究方向可以研究？
这个是原题，没有原题答不上来。 我看题主是北大的博士，倒是可以先去各家公司看一看现在 Flink 是怎么解决流式计算的问题的。 你要问有什么方向可以研究，那势必是回答不了你的。如果是已有方向，那就称不上【还有】。要真有崭新的方向，那人家还不自己开垦处女地，留与你作嫁衣裳？ 从应用层面来讲，我也不知道这些主题有没有现存研究，只能说说现有流式计算系统的一些问题。 Flink 对迭代计算的支持非常差，应该说没有，而迭代计算是在线学习的一个比较基础的需求。这方面的主要难点在于计算图的抽象大多是有向无环图，但是迭代计算会要求有环，环在网络通信和容错上是个大问题。Naiad 和 CIEL 各自有一套方法来搞定这种需求，现在它们的精神继承人 Ray 也由蚂蚁金服入场做 ray-streaming，不过代码质量目前看堪忧，设计上也乱糟糟的。 Flink 是静态的逻辑。整个流图必须在一开始就描述完成，不存在 CIEL 那种一个 task 拉起另一个 task 的场景。当然，你可以说通过胶水来粘合两个 Flink 程序，但是实践中这样的成本较高，而且粘合的整体比较脆弱。本身端到端一致性就不好保证，使用两个程序综合完成一个功能是相当难调的。 Flink 是静态的调度。它把所有的物理子任务都对应到一个抽象的槽（slot），并且在流的场景下大抵还是使用 EAGER 即一次性调度起所有子任务的调度方式。这里存在两个问题。 一个是同质化的槽不能描述异构的资源后端，同时不能细粒度地控制不同子任务的资源需求，常导致浪费。 另一个是调度的主动性（active），缺资源就去要资源，资源不够就调度不起来。后者也就是不能应对动态资源集合的扩缩容。这是一个很麻烦的问题，因为有状态的流计算在扩缩容时涉及的自适应并发度场景下需要重新分发状态，即使没有发生故障，在不停止数据处理的前提下重新分发状态都很困难，更不要说还要考虑任意的故障情形。这个问题学界暂时没看到讨论，或许是过于工程不屑于讨论，但是工程上的实现没有理论指导，基本只能靠工程直觉来模型化，没什么安全感。这一块内容 Flink 社区有 Till 和宋辛童博士在搞资源模型的整理和动态扩缩容的实现。 说到容错，Flink 的容错也存在或多或少的问题。虽然 Chandy-Lamport 算法的 checkpoint 还算不错了，总不像 MillWheel 那样依赖 BigTable 而且容易被 ack 死，也不像 Storm 一样只能靠上层应用自己，但是... 总的来说，工程实践上，上云是个问题，较真的正确性是个问题，性能又是个问题。不会真有人以为批流统一了性能就能吊打专门为批优化的执行引擎吧？ 回到题目，虽然我也没知道还有啥问题，不过倒是可以看一下《Streaming Systems》（Google Dataflow/Apache Beam 的模型）和《Fundamentals of Stream Processing Application Design Systems and Analytics》（IBM InfoSphere 的总结反思）看一看发展历史，看看有没有未解决的问题现在还没解决。