New: Cookbooks and AI ExplanationsStep-by-Step recipes to solve problems connected to Roadmaps and Cheat Sheets. Need more details? Use AI buttons for structured and simple explanations with concrete examples throughout the whole platform.Take a look
A column's type needed to change, so someone dropped it and added it back, and now a trusted count is wrong.
What you'll have at the end
A renamed or widened column that still reads six months of old values, verified with a row count before and after
You need
A lakehouse table whose columns are tracked by a permanent id, a query engine already connected to its catalog with permission to run schema changes and a merge, and a column that came back completely null the moment its type changed.
Not covered
Recovering a column whose old data files have already been removed by an expiration or cleanup job; by then the bytes are physically deleted, unreachable under any schema.
A bad write on a lakehouse table, rolled back with time travel
When the wrong numbers came from a bad write to the data itself rather than a schema change, and a plain rollback to the last good snapshot is all that's needed.
Set a snapshot expiration policy before old versions eat your storage bill
For setting the retention window that decides how long the old, renamed column's snapshot stays recoverable before you finally drop it.
Read an Iceberg table with PyIceberg
For getting a Python connection to the table's catalog set up before you use one to inspect column ids here.
Checked 26 Aug 2026
Part of the Data Lakehouse cookbook