lec ssmi

我还是比较喜欢看源代码，理解得更加深刻，也便于模型的选择。 请问你说的六篇源码解析文档在哪里呢？

spark的执行粒度都在batch，如果需要保证里面的每条record，那就需要失败后，每次都去遍历batch，代价也比较大吧。

请问一个可能不算是state的问题。在structured streaming中，两个流之间Join， 但是两个流join的时间范围比较大，比如几个小时。那这部分缓存数据，如果内存存不下，会溢写到磁盘吗？

文章里面提到，如果将watermark的生成放到source端，那么会更好。目前最新版本确实已经支持了。 但是，watermark的存在，本身是为了解决window操作中的数据迟到问题。如果在source端就将watermark生成，但是后面没有用到window操作，或者是window操作很少，生成的大量watermark就不会被利用起来，导致性能损失。那为啥在source端生成watermark要好一些呢？不解。

请问下大神，像这种论文，基本上都是方法论，如果自己涉及不到底层开发而偏向业务开发的话，有什么实践的方式吗？

现在基本上都上云了，整个大数据环境机会是封闭的，对于开发人员来说，感觉还是很不利的。中小型公司都是为业务而生。据我所知，包括阿里，也将大部分的开发人员划归到阿里云，可能楼主也是。而其他的业务线更多是一种用工具，而非造工具的情况。如果哪天离开了这个公司，基本上就没什么王牌了。去年面试了一个人就是这样，MaxCompute用得比较熟练，底层基本上不知道。 Matt Wang 于2020年6月10日周三 上午10:56写道： > 请问下大神，像这种论文，基本上都是方法论，如果自己涉及不到底层开发而偏向业务开发的话，有什么实践的方式吗？ > > > 这个不太好回答，因为我是做分布式相关的，上面列的论文也是分布式相关的，对于我来说，看论文可以提高技术加强理论知识以及提高技术深度和视野，做系统（参与相关开源社区）可以提高实践能力。 > 做业务的话，我理解可以分两种：一种是算法（算法涉及的工作比较多，不仅仅是算法工程师）及 AI > 相关的，这种工作需要与理论联系比较紧密，这种工作看论文对工作提供的帮助非常大，另一种是纯业务开发，我个人觉得对工作帮忙比较大的还是提高对业务和行业的理解，也会有一些相关的论文，不过更应该去关注一些一线大厂（特别硅谷一线大厂）他们关于业务思考的一些文章（如果对论文感兴趣，也可以花时间看看，不过最好关注于自己相关的）。 > > — > You are receiving this because you commented. > Reply to...

这种“为什么”比实际的技术实现还要重要！