https://community.databricks.com/t5/data-engineering/new-remote-dbfs-caching-python-library/m-p/158503#M54722 <P>Thanks for sharing this. It looks useful, especially for iterative notebook development where the expensive part is not just reading source files but recomputing a complex intermediate DataFrame after several joins or transformations.</P><P>I can see the value compared with normal Spark cache or Databricks disk cache: Spark cache is cluster/session dependent, while disk cache mainly accelerates reads of remote data files and does not really persist arbitrary intermediate query results as reusable DataFrames. Your approach of explicitly materializing the DataFrame to a persistent location/table could help a lot for EDA and repeated debugging loops. Databricks doc&nbsp; also describes disk cache as local node caching of remote data files not as a general cache for arbitrary subquery results. <A title="https://docs.databricks.com/aws/en/optimizations/disk-cache" href="https://docs.databricks.com/aws/en/optimizations/disk-cache" target="_self">https://docs.databricks.com/aws/en/optimizations/disk-cache</A></P><P>How does the library decide that an existing cached DataFrame is still valid? For example, if the source Delta table changes or if the notebook logic changes slightly, is the cache key based on the logical plan, user provided key, source table versions or params?</P><P>Since Databricks now recommends against DBFS root and DBFS mounts for most Unity Catalog-enabled workspaces, it would be good to document the recommended storage location clearly, for example UC managed tables, external locations or volumes rather than legacy DBFS root.</P> Sun, 07 Jun 2026 13:59:37 GMT amirabedhiafi 2026-06-07T13:59:37Z https://community.databricks.com/t5/data-engineering/new-remote-dbfs-caching-python-library/m-p/117671#M45543 <P><SPAN>I had some problems getting much speedup at all from spark or DB disk cache, which I think is essential when developing PySpark code iteratively in notebooks. So I developed a handy caching-library for this which has recently been open sourced, see&nbsp;</SPAN><A href="https://github.com/schibsted/dbfs-spark-cache" target="_blank" rel="noopener">https://github.com/schibsted/dbfs-spark-cache</A><SPAN>&nbsp;. This adds support for remote caching through an explicit method to the pyspak DataFrame, which previousely was only supported for <A href="https://www.databricks.com/blog/understanding-caching-databricks-sql-ui-result-and-disk-caches" target="_self">SQL UI cache</A>&nbsp;. Proper use of remote dbfs caching also seems to avoid the slow queries and poor worker utilization that you often get after complex queries with multiple joins.</SPAN></P><P><SPAN>I'd be interested to know if others in the Databricks community will find this useful.</SPAN></P> Mon, 05 May 2025 07:05:49 GMT https://community.databricks.com/t5/data-engineering/new-remote-dbfs-caching-python-library/m-p/117671#M45543 nito 2025-05-05T07:05:49Z https://community.databricks.com/t5/data-engineering/new-remote-dbfs-caching-python-library/m-p/158503#M54722 <P>Thanks for sharing this. It looks useful, especially for iterative notebook development where the expensive part is not just reading source files but recomputing a complex intermediate DataFrame after several joins or transformations.</P><P>I can see the value compared with normal Spark cache or Databricks disk cache: Spark cache is cluster/session dependent, while disk cache mainly accelerates reads of remote data files and does not really persist arbitrary intermediate query results as reusable DataFrames. Your approach of explicitly materializing the DataFrame to a persistent location/table could help a lot for EDA and repeated debugging loops. Databricks doc&nbsp; also describes disk cache as local node caching of remote data files not as a general cache for arbitrary subquery results. <A title="https://docs.databricks.com/aws/en/optimizations/disk-cache" href="https://docs.databricks.com/aws/en/optimizations/disk-cache" target="_self">https://docs.databricks.com/aws/en/optimizations/disk-cache</A></P><P>How does the library decide that an existing cached DataFrame is still valid? For example, if the source Delta table changes or if the notebook logic changes slightly, is the cache key based on the logical plan, user provided key, source table versions or params?</P><P>Since Databricks now recommends against DBFS root and DBFS mounts for most Unity Catalog-enabled workspaces, it would be good to document the recommended storage location clearly, for example UC managed tables, external locations or volumes rather than legacy DBFS root.</P> Sun, 07 Jun 2026 13:59:37 GMT https://community.databricks.com/t5/data-engineering/new-remote-dbfs-caching-python-library/m-p/158503#M54722 amirabedhiafi 2026-06-07T13:59:37Z