当结构化流中使用的Spark DataFrame的底层数据在源端更新时，会发生什么？

Question

我有一个用例，在这个用例中，我加入了一个流式的 DataFrame 静止的 DataFrame. 静态 DataFrame 从一个parquet表（一个包含parquet文件的目录）中读取。这个parquet数据由另一个进程每天更新一次。

我的问题是，我的静态DataFrame会发生什么？

• 它会不会因为懒惰的执行而自己更新，还是有一些奇怪的缓存行为可以防止这种情况的发生？

• 更新过程会不会让我的代码崩溃？

• 能否以任何方式强制DataFrame每天自我更新一次？

我没有任何代码可以分享，因为我还没有写过任何代码，我只是在探索有哪些可能性。我使用的是Spark 2.3.2。

Answer 1

一个很大的（一组）问题。

我自己还没有实现所有的方面（还没有），但这是我的理解，也是我从同事那里得到的一组信息，他们执行了一个方面，我觉得很有说服力，也很符合逻辑。我注意到，关于这个话题的信息还不够多。

所以，如果你有一个JOIN（流--&gt；静态），那么。

• 如果应用了Databricks的标准编码实践，并且应用了.cache，SparkStructuredStreamingProgram将只读取一次静态源，在后续的处理周期中看不到任何变化，也不会出现程序失败。

• 如果应用了标准的Databricks，并且没有使用缓存，那么SparkStructuredStreamingProgram将在每一次循环中读取静态源码，并且在后续的处理周期中会看到所有的变化。

• 但是，对于大的静态源，JOINing不是一个好主意。如果大数据集明显，使用Hbase，或者其他键值存储，如果是volitatile或非volatile，则使用mapPartitions。这虽然比较困难。这是我工作过的一家航空公司做的，数据工程师、设计师告诉我，这不是一件容易的事。的确，不是那么容易。

• 所以，我们可以说，对静态源的更新不会造成任何崩溃。

• "......是否可以用任何方式强制DataFrame每天更新一次......" 我没有在文档中或SO上看到任何这样的方法。你可以用var把静态源做成一个dataframe，然后在驱动上使用一个计数器。由于每次都会对微批物理计划进行评估和genn，所以我认为没有广播加入方面的问题，也没有优化的问题。这是否是最优雅的，值得商榷--也不是我的偏好。

• 如果你的数据足够小，替代方法是使用join读取，从而执行查找，通过使用主键在技术列中增加一些最大值，使主键成为复合主键--数据在后台用一组新数据更新，从而不被覆盖。在我看来最简单，如果你知道数据是不稳定的，而且数据量很小。版本化意味着别人可能还会读取旧的数据。这就是为什么我说明这一点，它可能是一个共享资源。

• 最后我要说的是，如果静态源很大的话，我不希望用最新的信息来JOIN--比如有些中国公司有100M的客户! 在这种情况下，我会用KV存储作为LKP使用mapPartitions而不是JOIN。请看 https:/medium.com@anchitsharma1994hbase-lookup-in-spark-streaming-acafe28cb0dc。 这提供了一些见解。另外，这也是老的但仍然适用的信息来源。 https:/blog.codecentric.deen201707lookup-additional -data-in-spark -streaming.... 两者都是不错的读物。但需要一些经验和见仁见智。