 Hello, everyone. Welcome to our session today at Ospoke on this session is about Presto today and beyond the open source SQL engine for querying data lakes. I'm Dipti Borkar. I'm the co-founder and Chief Parked Officer at HANA. Also the chairperson of the Outreach Committee for the Presto Foundation. And with me today presenting is Tim Meehan. Tim is a software engineer on the Presto team at Facebook and also the chairperson of our technical steering committee for the Presto Foundation. So thank you for joining us today. We'll talk about and start off with an overview of Presto. We'll talk about some of the use cases, and then we'll talk about the Presto roadmap that's that's in plan for the next several months. All right, let's get started. So Presto, also known as PrestoDB is the de facto query engine that data platform teams are increasingly using to query their data lakes. There's a couple of reasons that Presto emerged. So Presto was built at Facebook, created at Facebook, and it was built as a replacement for the Hive query engine from the Hadoop ecosystem for a few reasons. In general, businesses are getting more data driven. There's a lot more data that's that's being generated, and hence the need for interactive querying on top of all that data. Presto is an interactive query engine that is extremely fast, much faster than Hive. In addition, there is another big technology trend that's driving adoption of Presto. And that is the disaggregation of compute and storage. The rise of cloud data lakes, the rise of the S3, for example, GCS object stores. In addition to on-prem file systems like HDFS is further created momentum around these disaggregated query engines that are that can be used for analysis, structured analysis as well as for semi-structured data within data lakes. Now, Presto is an open source Apache dodo license, but more importantly, it is hosted under the Presto foundation that is part of the Linux foundation. It is a community-driven project. Facebook donated the Presto code itself to the Linux foundation, and along with Uber, Twitter, and Alibaba founded the Presto foundation. Ahana and I was a very early member of the foundation. And since then, a lot of other members have joined as well, including Intel and HPE and others. So what is Presto? So Presto is a distributed SQL engine. It's anti-SQL compliant, and it can be used to query both data lakes as well as databases. It's designed to be interactive. So it's really not kind of, it's going beyond the batch-oriented approach that Hadoop had and can be used for interactive query, interactive querying, ad hoc querying, if you will, on large amounts of data. And in addition, it is designed to be a federated engine. That means that it is highly pluggable and has a bunch of connectors that are available for you to query a range of different data sources. These can be databases, data lakes, streaming engines, no SQL databases, search engines, and so on. It is built for petabytes of data. It's running on massive scale at Facebook. And it is, as I mentioned, open source under the Linux foundation. Here's the URL, the GitHub repo where it lives. So it lives under the PrestoDB repo. So let's take a look at the architecture. So Presto is a coordinator worker architecture. So here you see on the top you have a range of BI tools or you have notebooks. You can run SQL notebooks on top. You can run data science workloads, analytics workloads, and as well as increasingly and slowly transformation workloads as well. Now, Presto itself is a distributed engine. And so the workers then connect to the data sources underneath to pull the information in, process it in memory, and then returns this information to the coordinator, which then returns it back to the clients that are querying it. The most popular data sources underneath tend to be the data lakes, which is HDFS on-prem as well as S3 in the cloud. You see some GCS as well. But you see a range of connectors here. And so you can query data warehouses like Redshift, you know, SQL server databases, relational databases, MySQL, Postgres, and others streaming engines like Kafka, Elastic Search like Elastic and NoSQL databases and so on. And so there are a range of connectors that you can access where data lives in many different places, but also you can join and correlate data across these data sources. So some of the common questions that we actually get is, you know, is Presto a database, right? How is it related to Hadoop and how is it different from a data warehouse? So let's talk about some of these. So Presto is a disaggregated query engine. So in some ways it only is the top half of the database. It does not include the storage engine which lives, is typically outside of it, like S3 or HDFS. And so you can consider it as part of the database. It's the top half of the database. Now you do need the other components. For example, the catalog, which could be AWS Glue or a Hive Metastore, which then maps the tables, the schemas tables and the columns within those tables to the objects or the files that actually live in the storage system. And so the catalog is a very important point that connects the ecosystem. Increasingly there's transaction managers or table formats that are being used as well. And together they kind of form a database. I call it the deconstructed database where each of these parts are in a traditional data warehouse. They were all part of a single integrated system. But with Presto and in the data lake world, there are many different components that together create an open source data warehouse. Presto came out of the Hadoop ecosystem. So in some ways, it is related. It uses the Hive Metastore and that was the first catalog that was supported. But today AWS Glue is also supported, but it's also HFS-comparable. And you can query files of storage like HDFS underneath the covers. But unlike the Hadoop ecosystem, which was extremely complex, Presto is fairly self-sufficient. And so along with Presto once you have the catalog and you really don't need any of the other pieces of Hadoop to be installed on the system. How is it different from a data warehouse? Now, data warehouses are tightly coupled systems where storage and computer or co-located together. It's basically a proprietary, proprietary formats also end up being very expensive. Presto is a great engine because it allows you to query S3 in place, query data leaks in place. You don't have to move your data to another source and to another system. And so in that it is different from a data warehouse. It also becomes cost-efficient because as you have large amounts of data, some of the object stores are extremely cheap and ubiquitous and allow for you to query and manage large amounts of data. So what has made Presto different? Presto has a highly scalable architecture. It's extremely pluggable. We talked a little bit about this and it's extremely performant. Let's take a look at each of these areas. So the first one is the architecture. In Presto there are two roles, server or node has two roles. You have a coordinator as well as the workers. The coordinator is responsible for, it takes in the queries. So the clients essentially connect to the coordinator node and it is responsible for parsing the query, creates the ASTs and comes up with the optimizer as part of it as well. The plan gets created, the logical plan gets created. And then at that point this plan gets sent over to the workers, gets converted into the physical plan. The splits, the parts of the pieces of the data get split across all these workers. And then the workers go and talk to the data sources underneath. It could be an S3 bucket. It could be a MySQL or a relational database underneath. Now Presto is highly scalable. It can scale up to 1,000 workers. And today while you see a single coordinator here, Presto has introduced in-app multiple coordinators. This is going to make it even more scalable from a scale perspective, but also helps from a high availability perspective. So let's take one more kind of deeper look underneath. So here you have the Presto CLI, the clients essentially. These can be BI tools. It can be notebooks or other clients like JDBC or DBC. They send the SQL query to the coordinator node. As I was mentioning earlier, the coordinator itself has the parser, the analyzer, the planner, the optimizer, and then the scheduler, which actually schedules out these queries. Now the coordinator also needs access to the schema and the table definitions, for example. So that's the metadata API. The metadata API gets called to go look up the HMS or GLU system and the information about the table, the schemas, columns, statistics if available get pulled in. And then this gets used by the analyzer and the planner to actually come up with a logical plan. Once a logical plan is created, the scheduler queues it up, they queues up the queries and also splits it up into different parts depending on where the data is actually located. And that calls the data location API, which can look up where the data is located, what buckets, what folders, and those then get assigned to all the workers. Now the workers go and pull this information from the underlying data sources. Could be a data lake or database. And once data gets pulled in, you might have, in some case, you might have a predicate pushdown where the predicate gets pushed all the way down where it's reading the information so it can skip certain parts of the file if it's not relevant, for example. In some cases, depending on what the plan looks like, you might have a shuffle across these workers. And this is where data actually exchanges, you know, it moves around from one worker to another for the additional processing. And sometimes it happens in the case of a broadcast join, for example. Now, once the data is processed, this gets sent back to the coordinator the results, and then the results that's our return back to the, to the, the client. The next piece in terms of how Presto is different is it's extremely pluggable, and has comes with a range of different connectors is very easy to build connectors for Presto because there is a, it has a nice API, it's called the SPI that you can use for plugins as well as for connectors. And as you see here, these are some of the popular connectors you can connect to a range of different data sources and query this information in you can also join across different data sources. Now, the Presto connector model itself so you have, you know, you have a driver for each data source. So for example, for HDFS and S3, you actually have the Hive connector it's kind of a confusingly named Hive connector. It's better, I would have been better called the data lake connector today, but the, the, the Hive connector essentially allows you to connect to HDFS or file systems essentially, as well as S3 compatible stores. So there's that's that's the most popular connector which tends to be the workhorse for Presto. There's a range of other connectors as well that are popular that you can try out. Now the catalog itself, as I mentioned, includes contains the schemas for the data source that's specified by the connector. And so every connector you create a catalog dot properties file, which has access to the gives give Presto access to the data source and has information about authentication and so on. And this is our properties, configuration properties that might be needed. And so that's the, that's considered the the catalog properties file. And there's there's one needed for every, every connector that that you want to access with Presto schemas. You are namespaces, if you will, they're organized into tables and tables like a traditional database or a set of rows are organized into columns with with types. And so that's that's essentially the data model that Presto uses. Another example here where you see a slightly more specific use case. So you have a coordinator node and you have the hive metastore that is the catalog in this case the operational catalog, you have a set of workers, which can then connect with the data lakes so HDFS S3 or GCS. Now, Presto's hive connector, which is the data lake connector, as I mentioned, supports a range of different types. It includes or can park a which tend to be the most a performant ones from these are column formats. These both include some metadata that are part of the file for the file format itself. So that is what makes it a lot more performant so that Presto when reading this information, this data can skip some parts, skip some parts or skip some segments of the of the file for faster and better performance. Others that are supported are JSON text CSV Avro others you see here. The org or parquet tend to be the most popular. As an example, Facebook uses or see Uber runs on parquet and Twitter as well uses parquet heavily. And the other ones are JSON. We see quite a bit of a lot of IOT data event data tends to be JSON. In some cases you might want to convert this into parquet or or see depending on the performance in the query latencies that you're looking for. At a high level, though, no ingestion is needed and this is in this it's quite different from a data warehouse where you don't need to explicitly ingest any data into yet another system. It queries it in place wherever it sits. Now, Presto is also very fast and one of the reasons it is in memory. The processing is done all in memory and it's streamed into memory. It's a pipeline architecture which is different from spark architecture which tends to be more stage driven. And at every stage you are actually persisting maybe some some information with Presto it's all streamlined and and so that's that's what makes it significantly faster than some of the other general purpose computational engines. It also has a columnar execution. And that is why the org and parquet formats tend to do much better because for analytics, those tend to be much more performant. For example, you might have aggregates or order by sorts, things like that. And, and so it is it has a columnar approach to execution. Now let's take a quick look at the query itself right so so here you have an example of a pretty simple query select star from from orders. And you have a simple predicate discount equals zero. Now, what would the logical plan look like so you have the scan table scan goes and scans the orders table which you see here. It's then the you have the filter, which is discount equals zero and then that gets to turn in as an output. So here you have a query where slightly more complicated where you have an aggregate some you have a projection left join of orders with line item and and then you have a predicate as well as a as a group buy. So here, you know it's a simple logical simple logical plan as well you have the line item table, which is in the outer you have the filter, which is the on the discount column. You have a left outer join with a scan on the orders, and then there's an aggregate which then gets pushed to the output. So in some ways it's very similar to a database. And if you're familiar with plans, explain plans out of from databases, then it is these these will look similar to that. Next, let's take talk about some of the use cases that Presto supports before we have Tim talk about the road now. So, Presto was built for the interactive query use cases, reporting and dashboarding and data science tend to be the most popular use cases. And this is with a tableau or a looker on top. And as well as a federated access and to be interactive as well where you want to query data from different range of data sources either from an app for an access perspective, or for or for joints. And then there's a couple of emerging use cases that are becoming slowly again getting adopted and you have the data lake house use case where you have transaction managers like hoodie or Delta Lake that are coming up as well as transformation use cases. The transformation use cases tend to be in data lake transformations using and and now Presto actually supports spark execution engine underneath and so Presto on spark feature that you can use to actually run the as I sequel with Presto, but actually have the spark engine around your transformations underneath. So let's go a little bit of a deeper dive into some of these use cases and see what the stack looks like. So here, you have, you know, two different stacks, if you will one you have to blow you typically have the JDBC ODBC driver on top, and you have the Presto cluster. In this case, you have the hive metastore and your data sources may be RDS and my sequel. And, and then you have here you have looker as another example of a reporting tool, and you have the glue metastore so Presto allows you to connect to it. Different different types of catalogs as I mentioned earlier. And so these tend to be the more popular stacks from interactive reporting and dashboarding perspective. Next is data science. So for data science, typically I've seen, you know, Jupiter being widely used. So you have a Python notebooks essentially sequel notebooks that that that are running on top of data scientists might run this and science team might run. Again, you have the JDBC driver, and then you have the, the S3 data lake underneath it with either glue or hive metastore. Now for the federated use case, essentially, you have a similar stack, but you can have a range of different connectors underneath, and you can perform joins across these tables. So you might have some data in my sequel might have some data in redshift, you might have some data in S3, and you can perform a joint across these three systems where the Presto will essentially go and pull the tables that are in my sequel. Pull the tables that are in redshift, as well as an S3, and then perform the joint in memory in the, in the, in the workers and return the results back to the coordinator as we looked at earlier. So here is a look at the transformation stack and we see this different kind of simple transformations. Some of some of this tends to be more of the CTAS or create table as is a is a popular one where you might want to change the format of the data from one one format to another, let's say Jason to parquet and create another derived table or create another copy of the table in a different format. We've also seen just simple select statements that to pull data from one place, and then insert it into another place inserting into a different location into S3, for example, and these simple workloads simple sequel transformation workloads can run quite effectively using Presto. Now, we have also seen a Presto on Spark that that can be used for this. And so if they're longer running queries longer running transformation jobs, longer running bad jobs then spark is the better engine for that and so the Presto on Spark feature can be used would be a better fit. And then finally from a use case is perspective we have the data lake use case that is getting to be more popular. You have here are the you know the difference is what we've seen earlier, you have a new layer in between. So in between the Presto cluster and and S3. So transaction managers are also called table formats are allow for mutations to be performed on data leaks. Now, this is quite different because typically S3 objects is what are stored in S3 and these are immutable. And so we transaction managers you can now version the data you can actually have have a delta or your versions for the schema itself, where you might add a column and you have versions of different schemas, but you got to have obviously versions of the rows it's as well. And and Presto has a very good into integration with Apache hoodie. This the Presto plus hoodie stack is is what runs at Uber and is used widely across across the company delta lake and Presto and Delta Lake also have an integration and there's more work that's being done here to actually build an even tighter native integration with the delta reader and writer. And then Lake formation is something that is emerging as well. There's early act early preview of transactions that's that's that's coming up. That's that's available. You can take a look at some of their blogs. And this is something that's that's a work in progress for Presto. So with this more and more data warehouse workloads can be run on the data lake. And over the next few years, we'll start seeing adoption of this stack quite widely. Just to give you an idea of, you know, where Presto sits with some of the other query engines as you look at options and building your data platform. There's a few different options out there. So, you know, drill, for example, Apache drill was based on the Dremel paper that came out of Google. And then Presto was created about the same time at Facebook and open source. But you see the tremendous growth of Presto as the cloud data stores as an adoption of the cloud data stores and increased over the last few years. And more options, more and more managed service options, more cloud options of Presto were available. The adoption of it has increased. This is DB engines. It is a ranking that is that's that's been it's quite popular. They track a range of different relational databases. And then you also see Spark SQL, right? So Spark continues to be used quite widely for transformations. And Presto seems to be catching up quite a bit. So what we are seeing is from an interactive query perspective on the ad hoc query perspective, Presto is turning out to be the de facto query engine for the four data lakes. And, and we're very excited about the moment, the momentum and the second half road map, all the features that are that are being added into Presto and will continue to get better, faster and easier to use. A quick note about Ahana. So I've I created Ahana as a managed service for Presto. Ahana is a part of the Linux foundation and the Presto foundation. And we've made it really easy to use Presto with a single pane of glass. We bring compute and Presto into your environment in AWS. And so we use the cross account access and an in VPC approach so that the data and the compute never are come into the vendors environment. Unlike a data warehouse, you don't have to ingest anything in on up and restore clusters that that you can bring up can query the data directly in place wherever it sits. So, so that's on at a glance we've got a few awards and some good acclaim over the last year. And with that, I'm going to pass it over to Tim. Tim is going to talk about Presto for all the the road map as well as a deeper dive in some of the use cases. Thanks everyone. Tim, over to you. Thank you, DPD. We've learned about the history of Presto and what makes it unique. Next I'd like to talk about the technical improvements we're making to Presto to make it an even better platform for analytics. And it can be summed up simply as Presto for all. Presto works really well as an interactive query engine. It can unify various data sources in your warehouse and provide a consistent interface into the data. We want to make the experience effortless going into many other use cases so that you have a one stop shop with a single language for most needs analytical needs in your data warehouse. One such use case is reporting and dashboarding. We want Presto to be the default choice for dashboards and to effortlessly handle the volume and query shapes these tools send to Presto. We want to think BI tools, think, you know, things that are sort of generated on the fly programmatically that may be challenging for databases. We want to extend our support and make this even more seamless and even more reliable. It would be a great choice for interactive and ad hoc analytics. We want to make it even better. We want to improve the reliability. We want to improve the ease of use for this use case even further. We want Presto to be able to efficiently serve data without having to ETL from your warehouse. So we want Presto to be able to handle very high QPS external serving across efficiently and with minimal ETL to other storage solutions and without a different language that another storage solution may have. We want Presto to be able to use the same Presto SQL that you use for dashboarding that you use for ad hoc analytics for also these types of these cases as well, serving types of these cases. Finally, at the totally opposite end of the spectrum, we want Presto to be able to handle large workloads with ease. What I mean by large workloads is long running workloads could be, you know, tens of minutes into several hours ETL type of workloads. So create table selects, select insert into ETL or transformation type of use cases. And this depending on the query shape is currently challenging because Presto is an in-memory query engine and depending on the size of the data or the type of joins required, it may run into local memory limits. But as I'll be describing, we're constantly improving this and have some exciting improvements to make this use case in particular, much easier for Presto users. And the most important thing is that we want to consolidate on the same language to do all of this with a similar ETL and a unified storage backend. The more tools that you need to support these use cases, the more complicated and expensive it gets for operating them in the warehouse and all the different sorts of expertise required to maintain them. We want Presto to work very well across all of these use cases so that you don't have to reach for a different tool or a different solution. You can use your same familiar Presto SQL with its semantics and its performance characteristics across all of these use cases without you needing a different tool to support these other use cases. So then the big question is what are we doing to help scale Presto to fit these these different workloads to support them all. And one very obvious thing is we're continuing to add more connectors. DeepD explained the connector architecture and why it's so critical to Presto. Obviously, we're adding more. And we're also improving the support for these connectors in various different ways such as improved filter pushdown, additional file format support, and also adding new connectors in particular for Alibaba connectors as well. And this list is non exhaustive. We have a public roadmap that I would definitely encourage you to check out and give it a read since there's a lot of exciting features coming down the road. So next we have workloads that don't fit within Presto's memory limits. In particular this tends to be batch ETL type of workloads. But it could also be, you know, sort of ad hoc analytical use cases that require complex joins or large aggregations. These may hit Presto memory limits. And every time a memory limit is hit, it requires intervention from the user and requires time from the user to make this work better. So we've really put a lot of effort into adding more operators to participate in spilling to help overcome this limitation. So in addition to adding support for join windowing functions or to buy an aggregation and improving the reliability of the spilling operators, we've also added more spilling strategies. So you can pick and choose the strategy that is relevant for your cluster and your reliability needs, rather than using a single default. And we've also added plugin support for external spilling. So in case storage is limited in your particular setup, or you don't have good reliable storage, a fast external storage service could be used for spilling this intermediate data. So long as the plugin is supplied. So then next we have workloads that span many 10s of minutes or even hours. The ultimate goal that we have for this, these workloads is to prevent the need for rewriting the query in a different engine, which may have different semantics, different support for functions, have its own learning curve, and require essentially learning it from scratch. We don't want you to start from scratch in case you hit some sort of batch ETL type of work, work, use case. We want you to use the same Presto SQL that you're familiar with for all these other use cases for this one as well. That's why Presto has migrated its entire engine to a library that can run inside Spark. By leveraging Spark's resource management, we can now enjoy the benefits of desired gearshuffle and recoverability that Spark gives you without having to rewrite the query plan, without having to rewrite the query that ran on Presto Classic. So an example is a query that, let's say, used to run fine on Classic, but now suddenly has hit memory limits, where it takes much longer to complete because of an influx of data that causes the query that used to run fine to hit local memory limits, let's say, building a hash table for aggregation or joint. The queries can now be reliably executed on Spark without having to rewrite the query. You can leverage Spark's execution model to partition the data in a much finer manner by giving it much larger parallelism. And in case there is a reliability issue, you can leverage Spark's recoverability features to do a partial failure recovery without having to rerun the entire query. So we're very excited about that feature. And finally, at the opposite end of the spectrum, we have Presto being used for online analytics or something that may be customer driven, something that has strict latency requirements and strict reliability requirements. We want to use the same query engine here as well. Once again, we want to prevent the need from having to reach for a different tool, you know, to handle these other use cases. We want to use the same Presto query engine for all of this. And we've put a lot of improvements into Presto's caching architecture. Raptor X with caching has, is fully implemented and offers a hierarchical data cache in Presto from a data cache reading device at the scan stage to a cache accessing the metadata from the metastore to a cache of the partial plant, the partial fragment of the data in case of selective queries, you just need to read the partial, the partial fragment rather than the having to reread all of the files all over again. So we have several layers of caching that tend to give us a pretty big performance wins up to 10 times depending on the work, the workbook. We also put a lot of investment into materialize views which offer better performance against roll up tables could involve some complex, you know, like a pre aggregated data that you would like to use for a dashboarding use case materialize you can support this without you having to manually create an intermediate table to serve the results materials use can be defined to seamlessly define the pre aggregation that you would like to run on top of the data. So we've talked about a lot of the enhancements that we've done. So now I would like to talk about the future. Where do we want to take Presto going into the future. And I call this Presto plus plus. So we want to make Presto even more efficient, even more reliable and even more schedule. So, what are we doing to improve the reliability of Presto. The first step is to serve a coordinators and Presto. We now have support and to run the Presto coordinator across multiple processes which gives better isolation and the ability to handle larger cluster sizes than is possible on a single coordinator. And it also helps. It's also very helpful for high court high qps use cases where the Presto coordinator maybe bottleneck. We now have a means to horizontally scale the coordinator itself to handle all sorts of different problems that you might experience with a single coordinator including single point of failure and loss of availability. On improving Presto's tasks scheduling to take into account the current memory and CPU distribution in the cluster. The idea here is as Presto schedules tasks to pick estimates for how how the task will cost and to pick the least utilize nodes. The idea here is to have a better quality and spread across all the nodes, so that we are less likely to run into local ooms and have better can support more throughput by more evenly placing workload across all the nodes in a cluster. We've also added we're also adding the ability to add to client side retries. So, in case the Presto query encounters some intermediate reliability issue and no results have been sent to the client the query can simply be retried transparently without intervention from the client. In terms of efficiency. We are working on a very large project to add a native accelerator to Presto for heavily used connectors. So think for example the hive connector, which is extremely heavily used. We have a native accelerator that supports a very efficient work reader written in native C++ that supports vectorized execution and full filter push down into the scan stage to allow for efficient pruning of of data before it you know ends up being shuffled to downstream stages. The Presto eval is being rewritten entirely so this means join algorithms and hash aggregation and all these other operators are being rewritten in a native manner to support vectorized execution on the local on the local worker. We're planning to have a an update to share on this later this year, but the early results are extremely promising in terms of performance efficiency improvements. In addition, on the Java eval side. We're also planning to invest in improvements on aria scan which is our presto's filter push down support aria scan has already pretty good support on the org format. We're bridging the gap and bringing all those enhancements to the park a format as well. So the reliability and efficiency next up let's talk about how we're making presto more extensible. The first is we're adding, we've added support for SQL functions. So rather than. To close, you have a complex expression or complex function that you would like to share with your colleagues or like to encapsulate it because it's very verbose and very ugly. We now have the ability to define SQL expressions in pure SQL and simply invoke it as a function. So that it can be shared among colleagues checked in or, you know, save for later use. And in addition to SQL functions we now have also support for external UDF servers. And the idea for external UDF services. It could be that you have a particular function that is written in let's say C++ or some other native language. So you can support this by simply implementing a threat interface that Presto can talk to and can remotely execute these SQL functions by executing code on these servers. It's also a good way to sort of allow authoring and custom UDFs to customers without having to. Add it to the Presto core code base. So this opens up the possibility of dynamic functions and loading them up dynamically on UDF server without having to integrate into the core engine. So it really makes the UDF authoring experience a lot more flexible. So I've talked a lot about Presto's technical direction and many of the projects that Presto is working on to make Presto. It's getting faster even more reliable and even more extensible. You may want to get involved and we would love to have you. If there is, if you have a question about how to operate Presto or if you, you know, sort of like want to get started, you know chatting on how you can contribute to Presto. So if you would like to be dot slack dot com join the slack group and let us know what your questions are. There's also a blog post. We have a blog. If you have a particular use case that you would like to showcase with Presto we would love to see it. So if you have any tips with Presto. Or people present different initiatives or different use cases that you're they're using Presto. And finally, we would love to see code contributions. So if you have an idea for a connector, let's say, new functions, improving documentation. If you're contributing to the even the core engine or contributing to code reviews, all such contributions are welcome and we'd love to see all of that. And that's all I had for my slides. I would thank you all for attending this presentation and I'd love to see if you have any questions.