Answer-first summary for fast verification
Answer: The table `orders` was an external table
The persistence of data files in DBFS after dropping the table with `DROP TABLE orders` suggests that the table was an external table. Here's why: - **Managed vs. External Tables**: Managed tables in Databricks have both their metadata and underlying data files in DBFS deleted upon dropping. External tables, however, only have their metadata removed from the registry (e.g., Databricks Catalog), leaving the data files untouched in DBFS. - **DROP TABLE Behavior**: By default, the `DROP TABLE` command removes only the metadata for the table, not the data. This behavior affects both managed and external tables differently regarding the data files. In this case, since the data files remain, the table was likely an external table.
Author: LeetQuiz Editorial Team
Ultimate access to all questions.
A data engineer attempted to drop a table named orders in Databricks by executing the query DROP TABLE orders. Subsequently, the query SHOW TABLES confirmed the table's absence from the listing. However, the data files associated with the table remained in DBFS. The engineer's goal was to delete both the metadata and the data for this table. What is the most plausible explanation for this outcome?
A
The table orders was a managed table
B
The table orders was not dropped properly
C
The table orders was an external table
D
The table orders was partially dropped
E
The table orders should be truncated first before dropping
No comments yet.