Recall that Spark is a compute engine, it's not for storing data. Data on the Spark cluster disappears when the cluster is terminated unless it saved elsewhere. In this lesson, we'll look at managed and unmanaged tables. By the end of the lesson, you will have written to both managed and unmanaged tables, and explore the behavior of dropping those tables on the underlying data. Now, let's take a look at managed and unmanaged tables. In this walkthrough, we're going to write to both managed and unmanaged tables, and we're going to explore the effect of dropping those tables on both the metadata and the underlying data. Let's start by attaching to our cluster and then running our classroom setup script. A managed table is a table that manages both the data itself as well as the metadata. That metadata is usually some schema information in the location of the data as well. In the case of managed tables, if we dropped that table, we'll move both the metadata for the table as well as the data itself. Unmanaged tables perform a little bit differently. Unmanaged tables manage the metadata, but the data itself is sitting in a different location often backed by blob stores like the Azure Blob or S3. In this case, Spark is not going to delete that table when we perform a drop table operation. Let's take a look at how this works. First, I'm going to use the default database. I'm going to create this table called table managed and I'm going to insert a couple of values into it. Now, if I call this described extended command, we can take a look at the type of table and we can take a look at where that underlying data is actually sitting. So here, we can see the type of tables managed and we can see the location is under dbfs user hive warehouse table managed. Now, let's create an unmanaged table instead. In some other environment, you might see this referred to as an external table instead of an unmanaged table. Now, when we perform describe extended on this, we'll see that we have an external table, and we'll see that the location of this data is a little bit different. It's under tmp/unmanagedTable. Now, let's take a look at this table to make sure our values are in here. Let's grab the result. Great. So this is exactly what we would expect. Now, we can view the underlying files where the data was persisted. Here, you can see these files. Now, let's switch back to the managed table. Let's take a look at those files, and let's see what happens when we drop that table. So let's go ahead and drop it here. Now, let's take a look to see if those files are still there. As you can see, those files are now gone. Now, let's take a look at the unmanaged table. I'm going to go ahead and drop that, and now I'm going to take a look at the underlying files. As you can see, those underlying files are still there. So to sum up, use an external or unmanaged table when you want to persist the data once the cluster has been shut down. You can also use managed tables if you only want ephemeral data.