Spark流与静态数据链球三分表的可靠性如何可靠

发布于 2025-01-22 10:46:10 字数 284 浏览 2 评论 0原文

在databricks 有一个很酷的功能使用Delta表加入流数据框。很酷的部分是,对于随后的联接结果,增量表中的更改仍会反映出来。它可以正常工作,但是我很想知道这是如何工作的,这里有什么局限性?例如,预期更新延迟是什么?随着增量表的增长,它如何变化?在生产中依靠它是安全的吗?

In the databricks there is a cool feature that allows to join a streaming dataframe with a delta table. The cool part is that changes in the delta table are still reflected for a subsequent join results. It works just fine, but I'm curious to know how this works, and what are the limitations here? e.g. what's the expected update delay? How it changes as the delta table grows? Is it safe to rely on it in production?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

牛↙奶布丁 2025-01-29 10:46:10

是的,您可以依靠此功能(实际上是Spark) - 许多客户在生产中使用它。关于其他问题 - 这里有多个方面,取决于因素,例如,表更新的频率等:

  • 由于静态三角洲表没有缓存,因此在每个联接上都重新阅读了 - 取决于群集配置,因此可能不会如果您使用 delta caching 所以,文件不是每次都重新下载,仅重新下载新数据。
  • 如果您有很多小文件等,则阅读性能可能会受到影响 - 这取决于您如何写入该表格&如果您做的事情(例如优化)。
  • 根据三角洲表更新的频率,您可以缓存&定期刷新它,

但要完全完全回答,您需要提供更多特定于代码,用例等的信息。

Yes, you can rely on this feature (it's really of Spark) - many customers are using it in production. Regarding the other questions - there are multiple aspects here, depending on factors, like, how often table updates, etc.:

  • Because static Delta table isn't cached it's re-read on each join - depending on the cluster configuration, it may not be very bad if you use Delta Caching, so files aren't re-downloaded every time, only new data will be re-downloaded.
  • Read performance could be affected if you have a lot of small files, etc. - it depends on how you're writing into that table & if you do things like OPTIMIZE.
  • Depending on how often the Delta table is updated, you can cache it & periodically refresh it

But really to answer it completely, you need to provide more information specific to your code, use case, etc.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文