cancel
Showing results for 
Search instead for 
Did you mean: 
Data Engineering
Join discussions on data engineering best practices, architectures, and optimization strategies within the Databricks Community. Exchange insights and solutions with fellow data engineers.
cancel
Showing results for 
Search instead for 
Did you mean: 

Read Snowflake Iceberg tables from Databricks UC

jeanptello
New Contributor

Hi folks!
I'm trying to read Iceberg tables that I created in Snowflake from Databricks using catalog federation. I set up a connection to Snowflake, configured an external location pointing to the S3 folder that contains the Iceberg files, and used that to create a catalog.

The first time, I'm able to query the Iceberg table from Databricks successfully. However, if I update the table in Snowflake and then try to query it again from Databricks, I get the following error:

Failed to convert the table version 2 to the universal format iceberg. Clone validation failed - Size and number of data files in target table should match with source table. srcTableSize: 168818176, targetTableSize: 314383872 srcTableNumFiles: 25, targetTableNumFiles: 25 SQLSTATE: KD00E

The table contains around 5 million rows.

1 REPLY 1

Isi
Honored Contributor II

Hey @jeanptello 

It’s possible that there’s a mismatch between what Snowflake has written and what Databricks is trying to read. This often happens if Snowflake has performed an operation that rewrites the table files (like compaction or a bulk update), and then Databricks tries to validate an older version that no longer matches the current state.

I’d recommend:

  • Refreshing the table from Databricks to ensure it’s accessing the most recent version.

  • Checking the table history in both Snowflake and Databricks to verify whether both systems are seeing the same snapshot, or if there’s a discrepancy in recent operations (like file size or number of files).

The error likely stems from a difference between the current state of the table in Snowflake and what Databricks expects. Reviewing the history should help confirm if there was a shift or an operation that triggered this conflict.

Hope this helps, 🙂

Isi