 All right, so we kind of went really deep, which is good in the sense that you guys kind of see how this tech evolves. So just let's kind of recap things and then connect the dots. So a hoodie allows some of this data management capabilities that we talked about. You guys saw that. And you have to add all that sophistication to get more than just working with files. And what we ended up doing, and we're going to now go back to Presto, right? So what did we end up doing? So if you look at the typical workflow, you have your operational sources. You're going to ingest it into your data lake. And then you're going to read it somehow. So Nadine was writing these files as hoodie tables. She was using primarily Spark. We're going to show it how you can read those tables with Presto. In the particular lab, what we ended up doing was we kind of made mock data with CSV. So that's what she was doing. She was reading CSV, make that operational data using Spark, writing these hoodie tables. And we can verify that. So for example, I was doing the lab alongside you guys. I just gave myself ID number 16. So if you look into the data lake, I have these parquet files. So that's what we're there. Those were the little blocks that Nadine was showing. But we have this dot hoodie folder. And that's where all the metadata is about, hey, how do I interpret these parquet files? Is it a merge on read? Is it a copy on write? Things like that. So that's what we did. And so now what we want to do is we want to say, we have these hoodie tables. Let's go ahead and use Presto to query it. So what I'll do is I'll go back here. I'll go ahead and connect to my instance. So it doesn't really matter which instance, because all the Prestos are connected to the same data lake. So I can go ahead and let's go ahead and navigate this. So let's go ahead and see the schemas that I have in the glue table. I misspelled stuff. And I have hoodie. So I can go and show tables in glue dot hoodie. And this is going to be long, because we have a bunch of IDs. So I'm going to see a bunch of them. So what I'll do is, so Nadine was, I think, 51 or 50? What are we using? 52. 52. So what I'll do is I'll just go ahead and, so first I'll just use this. So I'll name space it there. And then I'll go select star from cart status cow 52 limit 10. Boom. And this is basically the table that she wrote. And I'm reading it in with Presto. Obviously, there's additional columns. So let's go ahead and say, I should be able to do a describe on this. So we have those variables that you saw that we were working with. And then, obviously, hoodie adds a bunch of columns for us. Commit times, record key, things like that. Those are all the parameters that were set. All I'm really basically telling you here is, look, you can ingest your data with hoodie. Why is that important? Because like Nadine said, it depends on your workload. Do you want to merge on read, copy, and write? You're taking your data from your operational source, putting your data lake. But you're putting it in a format that then can be queried and have all these benefits of the data management. We're using Presto here. So again, another advantage of the data lake, right? You have one system interacting with the files. It's an open standard. Another system, which didn't create those files, she created those files with Spark, didn't even use Presto. But Presto is able to read it, because again, it's an open format. All right. So that kind of basically gave you, in a nutshell, very quick tour of how do you build a lake house with these technologies. The final thing I'll do, I'll just demo it. You guys can obviously work on it, is federated querying. So while we're focused on the lake house, Presto is a very flexible engine. And it was designed to be flexible. So you can actually query across data sources. That's another reason why you might want to use Presto, not just for the lake house, but then you can also combine with other data sources. So let me go ahead and show you. So for example, in this picture, I have data in S3. I showed you transactions. And then I have data in SQL, MySQL. So let's go ahead and look at some data. So if I say show catalogs again, we know what's inside of GLU, right? So just to kind of review, if I go select star from GLU.pq, parquet, transactions, limit five, let's say. So I have transaction data. Now let's say in some other system, MySQL, I have customer data. So I happen to know the schema, so I'll spare you that. So it's in MySQL, it's in temp, and I have customers, limit five. So here's a database of my customers, which is in MySQL. And what I do know is this customer ID here maps to this ID that's in MySQL. So in theory, I should be able to join these two tables, even if they live in different data sources. And so Presto can do that. So if I go back here and I run this query, so let's say I want to figure out which of my customers spend the most money. Well, what I could do is I could take my customer, join it, and then aggregate it by that customer. So I'll go ahead and show you what that looks like. I'll just go do the answer, and then we can dissect the query. So I'll do the answer, dissect the query, and it gave me this last name Smith, who lives in California, spends the most money, spends about $118,000 with us. So how did I do that? I said, give me the ID, the last name, the state, sum all the amounts, but get it, start with the customer, which lives in MySQL, join it with the transactions, which lives in my data lake, match them with the IDs. That's the keys, group by the ID, last name, state. So there might be multiple people named with the last name Smith, and so make it unique, and then order it by the total in descending order and give me the last 10 results. And so that's an example of a federated query using Presto. And that concludes the summit. We covered a lot, a lot of deep stuff. I know you're kind of ready to clap, appreciate that. Any questions, either from the audience or online? General question, if we compare elastic versus data lake Presto hoodie, except for SQL interface, what differentiates Presto tech versus elastic? So I'm not as familiar with elastic search. I think the use case is a little probably different. I think one is really more of a search use case, versus this one is more like relational analysis. I know you're saying forget the SQL interface, and that's fine. That's just how you express it. But the engine itself, the operators that you're doing are more relational, like group buys and aggregation. I think performance is also a big thing. So again, maybe I might be missing something. I'm not as familiar with the elastic search architecture. But again, Presto, a couple of things with Presto. First, it's in memory. So it's really fast. You're not reading and writing from disk. It puts the data in memory. And then it's also continuing to improve on a performance. So a big thing is what we call the VLocs project. And so what this is is this is a highly optimized runtime written in C++ that Presto can leverage. So using VLocs under the hood, you can run Presto or Spark with VLocs. And this is basically a faster runtime. So I don't know if it's an apples to apples comparison to compare elastic with Presto. I'm not saying it isn't. But I think the other dimension that I would call out is specifically performance on top of the data lake. So I'm just addressing the question. I don't know, John Aghan, if I am answering your question or not, you can kind of respond on the slack. Yeah. Yeah, yeah, yeah, yeah. That's a good point, exactly. So elastic's kind of like another technology that's working with its own kind of data versus, you know, Presto, obviously you guys seen it's working with an open format, which allows for interoperability as well. And that's kind of the idea behind the lake house and the data lake, right? It is a centralized place where you're going to aggregate all your operational data and then allow multiple engines to work on it. Not just SQL. Again, we're focusing on the SQL side because that's a Presto query engine. But you could run machine learning and whatever on top of it with other engines. And today you actually saw the same data being worked on with Spark and Presto. Yeah, I think the other thing is the search index, like elastic, was originally used for log analytics. The use case is very different. OK. Great. Yes. So my community manager wants to make everyone aware that soon we'll be having Presto Condé. This is a virtual event. I think you can register for free. Check out the program. It's pretty awesome. You'll see talks both from the community leaders. But you'll also hear a lot from actually people running Presto in production for lake house use cases. So we've got Adobe here. We've got Place Informatics. We've got Bolts, Alibaba, HPE. So check it out. All right, folks. It's been a pleasure walking you today through Presto and the lake house. Appreciate everyone's participation live, as well as virtually. Enjoy the rest of the summit. And that's a wrap. Thanks.