一大堆问题。
我自己还没有实现所有方面，但这是我的理解和同事提供的一组信息，他们执行了一个方面，我觉得很有说服力，也很符合逻辑。我注意到关于这个主题的信息还不够。
因此，如果您有一个连接（流-->静态），那么：
如果应用了符合databricks的标准编码实践，并且应用了.cache，sparkstructuredstreamingprogram将只在静态源中读取一次，并且在随后的处理周期中看不到任何更改，并且没有程序失败。
如果应用了符合databricks的标准编码实践，并且没有使用缓存，sparkstructuredstreamingprogram将在每个循环中读取静态源代码，并且在随后的处理周期中可以看到所有更改。
但是，加入大型静态源不是一个好主意。如果数据集很大，可以使用hbase或其他一些键值存储，如果是volitile或non-volatile，则使用mappartitions。但这更困难。设计师告诉我，这是由我工作过的一家航空公司完成的，数据工程师的任务并不容易。事实上，这并不是那么容易。
所以，我们可以说，对静态源代码的更新不会导致任何崩溃。
“…是否有可能强迫Dataframe以任何方式每天更新一次…”我在文档中或这里没有看到任何类似的方法。您可以使用var使静态源成为Dataframe，并在驱动程序上使用计数器。由于每次都对微批量物理计划进行评估和生成，因此我认为没有广播连接方面或优化方面的问题。这是不是最优雅，是有争议的-不是我的喜好。
如果您的数据足够小，则另一种方法是使用联接进行读取，从而执行查找，方法是使用主键，并在添加到主键的技术列中添加一些最大值，以使主键成为复合主键，并且使用一组新数据在后台更新数据，因此不会被覆盖。在我看来，最简单的方法是，如果你知道数据是不稳定的，而且数据很小。版本控制意味着其他人仍然可以读取较旧的数据。这就是为什么我说，这可能是一个共享资源。
对我来说，最后一句话是，如果静态资源很大，我不想加入最新的信息-例如，一些中国公司有1亿客户！在本例中，我将使用kv存储作为lkp，使用mappartitions而不是join。看到了吗https://medium.com/@anchitsharma1994/hbase-lookup-in-spark-streaming-acafe28cb0dc提供了一些见解。此外，这是一个古老但仍然适用的信息来源：https://blog.codecentric.de/en/2017/07/lookup-additional-data-in-spark-streaming/. 两本书都读得很好。但是需要一些经验和见识。