Yo, hey, yo, hey, yo, yo. Pack the chrome styles, fly like Mrs. Jones. Lyrical mathematics will have the devil smoking stones. I put heads to bed, lick shots, and rap with me. Yeah, I'm so sorry for doing it. It was Anticipal. He sent me an invitation for the wrong hour. All right, so yeah, hi, everybody. My name is Cipo. I work for Amazon. I'm going to spend a lot of my, I have spent a lot of my time working on analytics. And one of the services I'm very close with is Amazon Redshift. And this talk is going to talk about the evolution of this service the past 10 years. If you are taking Greg Ganger's class, I did pretty much the same talk last week for Greg's class. So some of you, you may want to just skip the class and do those other stuff. Yeah, I have three students. You're good. All right, so that is probably will be the only marketing slide I will have. But Amazon Redshift is Amazon's cloud data warehouse. It is a very large service. We're kind of very careful when we make public statements. And we have gone publicly and said that daily we have tens of thousands of customers using Redshift to process exabytes, plural exabytes of data in AWS's global infrastructure of 30 regions and 96 availability zones. So this is a massive system, you know, since it's already 2 PM in escows, you can safely assume that for the day we have had, our systems have processed at least one exabyte of data, if not more. So this is a very, very, very big system. And our goal is to be easy, secure, and reliable. We want the customers to be able to analyze all of their data using Redshift data that are complex, either scalar or complex, nested, data stored in operational systems with data lakes, warehouses, and whatnot. And we want to do that offering the best price performance at any scale. But how did we, how the socials it's made now? So if you look on any large service or a system like Redshift, you will see that there are some thematic areas, some areas of focus for the service. And for Redshift, if you screen, there are kind of six basic areas where we are putting most of our energy and investment. The first one, and there is a reason I put them in that order, the first one in terms of priority is security and availability. Usually when I do this kind of talk in a class in person, I ask at that point people to say, OK, raise between security and availability, which one is the most important? So can somebody answer this question? Hello? I'm sorry. Yeah, I'm asking the class between security and availability, which one is the most important? It just depends on your use case. No, no, it does not depend. Security is by Trump's everything. So the most secure system is the one that it is down. And security is the highest priority and availability after you are secure. So customers do, we have tens of thousands of customers giving us exabytes of data to process and have them available. And that is our primary goal. And when it comes to security, we keep on pushing the envelope of the things that the customers can do and can control. There are very interesting challenges there. For example, being able to offer high performance analytics on top of encrypted data to offer dynamic data masking to be able to do identity management through our systems, are there are a bunch of complicated problems to do that? So and, for example, in a in a Redshift case, all this processing is happening to the customer's VPC network and the data does not go out of these boundaries. When it comes to availability now, once you get all these security features, when it comes to availability, we try to make our systems very available. So one of the biggest architectural chains that Redshift did over the recent year since the inception of the service, since we launched the service, was the separation of compute and storage. So when we launched the Redshift, the data was the system of the place where we were persisting the data was on the local attached SSDs storage of the individual Redshift environments. And we went through a very big project and we separated now storage and compute. By separating storage and compute, we have the ability to guarantee that the recovery point objective, RPO, is zero. Meaning that whenever a customer commits, sends a transaction to commit some data and we say we committed your data, we can guarantee that there will be a no loss of data at that point on. And once we separate now storage and compute, you can do very interesting things by offering improved availability to your systems. For example, we have the ability whenever there is an environment running in one availability zone and something happens with this availability zone, we can easily, when the press of a button remove this environment, spin it up in a separate availability zone and start consuming the managed data from the point of the last commit. Now we're taking this thing a step further and we are offering multi AZ Redshift. So what we do is we run two separate environments to independent environments in two availability zones. The data gets committed and written in the Redshift managed storage which is essentially Amazon S3. And then we monitor the health of the systems and if something goes wrong, we very quickly failover to the second environment and continue being available. During happy hour, during the health state when the systems are healthy the customers do get the throughput and the performance of having two environments and when there's something wrong happens we go and we do this very quick failover and we offer the best of both worlds availability and good performance. If you said it's essentially S3 but is it, is there something special above it? S3 that you guys have prioritized Redshift or is it like, like if I try to build my own version of Redshift now that I'm going to but like, could I do the same thing or do you have an extra layer there that's doing the next step? So I mean, Redshift managed storage is the data the blocks are stored in a proprietary columnar format in S3 bucket, S3 buckets, right? Now, what constitutes a format is a little of a philosophical discussion, right? Iceberg, if you take iceberg, what is it? Iceberg is parquet at the core of it but there is something more on top of that, right? It's a protocol manifest. In a similar fashion, Redshift managed storage is the data, the bulk load is one megabyte blocks, columnar blocks in S3. There is obviously some protocols, transaction processing protocols and whatnot that make this very efficient and very performant, right? So there is more to that. I'll take it. Okay, but the bulk load, like the physics the data is stored in S3. Yeah, yeah. Okay. All right, so security and availability are very important things for customers when they want to run a database. And then the second area of importance for us is performance kind of the DNA of Redshift is to offer very, very good performance. In order to understand why Redshift achieves this good performance, we need to take a look a bit under the hood and start understanding how Redshift is implemented internally. So let's, you know, in the next couple of slides I'm gonna get into details of how Redshift is implemented. In Redshift, we have two layers, the compute layer and the storage layer. Within the compute layer, we have two types of nodes, execution nodes. The first one is the one in a green box there. It's called the leader node.  They are the ones that are doing most of the work whereas the leader is the brain. It does the brain, which is the one that gets is the point of connection from externally to the system. And it is where the customers submit their requests, the statements, and this is where the catalog leaves.  We take the query, we parse it, we do semantic rewritings. We try to rewrite it in a way that we generate an equivalent SQL query that it is more efficient. And then we go to a cost-based query optimization based on statistics that we maintain and we generate a distributed query execution plan that may look like the one I have on the right-hand side. There are some interesting properties in Redshift. For example, we have the option for the customer to, the tables in the database to have distribution keys and short keys. So physical properties. So for example, you may decide to have, if you have a customers and orders table and both of them are distributed by customer ID and every query you have joins the customers and orders on the customer ID, then we don't have to shuffle data across nodes. We do call what we call collocated joins them. So the query optimizer obviously takes all these physical properties into consideration to generate efficient distributed query execution plan. And after we are done with this cost-based query optimization process, an interesting thing in Redshift is that for every query fragment, query fragment being something, a pipeline that ends in a stop and go operator, what we do is we go and generate C++ code. We almost literally open a C++ file and print def code into that file. And we take this generated code, we compile it and we take it, we send it down the executables down to the compute nodes, which are the workhorses. The compute nodes that are run on EC2's Nitro hardware. So we have obviously a lot of hardware optimizations in there. They start running, executing this tight loop of the individual query fragments. And what they do is they are assigned some data partitions from the managed storage and they start processing these partitions and doing whatever this query wants them to do. And we do all sorts of tricks that you can read in the modern literature efficient query execution. We have, we do min max pruning. We use vectorized AVX to SIMD processing on the data. We use vectorized execution friendly encodings, compressions on the data block so that we can operate on, apply, do a lot of processing on encoded data. We do late materialization. We do all sorts of stuff that in order to make this processing very efficient. Sorry, you may say this, are you doing first or full processing? It's literally, it's a push-based model. Okay. So what we do is we take a query fragment. We kind of generate the code. We generate one executable for all the operators within this query fragment. We put them together. So it's a one piece of code. It's not a staged execution. And then this push piece of code, what it does, it takes data from blocks from the storage layer and pushes them up. Got it, thank you. Okay. So, you know, in one slide, that it is, you know, by now you are experts in the design of Redshift. This is a very, very simple design. Are you using GCC or using some proprietary app hands-on compiler? We use GCC, you know, obviously, we start code with a bunch of compilers and we keep on updating that. And, you know, that is always an area of optimization for us. Are we having a question? I have a question about, yes, sir. How do you distribute the table data? Like, do you have third storage? And like, how do you decide where to run the table? Yeah, are you using something like a different app to like, ensure the level? So, yeah, so the way we do it is we have a fixed number of buckets of data buckets. And then we do a deterministic assignment of these partitions to compute nodes. And I'm gonna talk about it later, you know, when we change the compute size, then we kind of in a consistent fashion, we move these things. So we maintain the ability to perform collocated joints. Thank you. All right. So let's dive a little more into this code generation with this something that it is kind of unique in Redshift. And let's take a very simple example of a query like the one I have up there that applies a filter in one table, joins two tables together and calculates an aggregation on top of that. What the Redshift ends up doing is it generates some piece of C++ code that looks a lot like the one I have on the left-hand side, which you can actually read it, right? It opens a while loop, it starts pulling data from the scan, it applies a filter, this predicate less than 50, it calculates a hash value and then goes and probes the hash table. And if there is a match, it applies the aggregation on the match. It's a very, very simple. It's like, you can actually read it.  For example, we do some, we have a FIFO queue where we push and pull from the end of this queue in order to improve the L1 cache hit rate and we minimize cache mislatencies. This version of the code is the scalar version. What we run in production is actually an AVX2 vectorized version of this code in which would have been a little more complex than that. This version actually is doing the late materialization and does not do this late materialization and being max pruning, we do all these things. But in a nutshell, you can get a gist that the feeling that what Redshift ends up doing is generates this very, very efficient piece of code that runs the tight loop. Okay. Whenever I'm giving this kind of talk, at that point, somebody raises their hand and says, hey, this is cool, but don't you worry about the GCC compilation costs at run time that may incur? And the answer is absolutely yes. We do worry about the cost of compilation. I'm proud of you. The reason why the class isn't asking you is we already talked this. Okay. Okay. So to answer this thing is traditionally when we kind of, what we see is that, okay, in workloads where the individual queries would run for minutes or four hours, adding some seconds of query compilation may not have been a problem. But what we see is a shift, especially the recent years towards more real time and lower latency analytical workloads where the potential cost of GCC compilation at the critical path would be a problem.  For example, just by just putting a cache of the compiled snippets on the leader note of any Redshift computing environment. And because there is a lot of repeatability in what queries customers run within an environment we were able to improve the hit, we were able to achieve up to 99.5% compile code cache hit rate by just putting a small cache on the leader note of every individual Redshift environment. But we took it to the next level, you know, now that we are in the cloud. And what we do is anytime we see a query fragment that we have not seen before, we push this query fragment to S3. And then we have a form of machines that compiles this code with the maximum optimization, compilation optimizations. And we put the compile code in a global cache and that we made that available to other clusters in the fleet. And by doing this very simple trick we were able to improve the cache hit from 99.5% to 99.96%. So we were able to improve the cache hit by an order of magnitude by taking advantage of the fact that we run in a cloud as a service. And the reason why this thing works is because of the pincer hole principle, right? There are that many tables in the world that have five integers. And there are that many queries that run, they apply a symbol integer predicate on one column of a table. And, you know, in a large service such as Redshift where we have tens of thousands of customers, hundreds of thousands of computing environments and billions of queries running daily, the probability of having repetition is very, very high. Obviously we do all sorts of tricks right there to minimize the, to minimize the, you know, to try to have mostly stable code, stable generated code when we do this query processing. And there are a lot of details I'm omitting here. So do you explore using NLGF to work in cluster? Yes, yeah, okay. So that is, you know, deterministically the second question I get when I am in this slide. So the first one usually is don't worry about the compilation cost. And then the second question is, why don't you use LLVM for that? And to, honestly, you know, we kind of, we start building Redshift, you know, more than a decade ago and that was actually kind of preceded LLVM. So we have a huge code base, a very stable system that it has the kind of C++ based generation. And that's why we stuck with that. The hyperpapers 2011, right? You guys started building this 2001. So we, we were, we were already developed. So presently, it predates the hyperpaper. Yes. I mean, to be very, you can compile it into the system. Can you please repeat the question? It's a little difficult to hear. A comment is, sorry, what is your comment? Sorry, the comment was that if you don't create, if you can really compile it into the system, you should, you should be able to do that. And I remember the thing was, they couldn't compile it into the system because they were facing issues with conversion. Yeah, so his comment is that if you, since you can't convert this into a plus, you have readable debugable code with, in the hyper case, you have to be cracked, now a BAM land, can you compile it into an IR, you're looking at a separate. So the fact that like you can, you need to bug this.  But after that, it is quite easy to develop and maintain because the code they generate is C++ code. So it's, you can, you know, you can reason, you can read it and understand what the query did as we did in the previous slide, right? We, you could, you were able to read the query. All right. For the ADX2 stuff, how much you rely on GCC to auto-vectorize that and how much that is the right size? We are right at all. Okay. Yes. You have a world expert in sending there, so. Yes. Yeah, yeah. A Greek guy, something like that. All right. So, you know, and, you know, we are, as a service, we are, you know, very much focused on improving performance. The good thing when you are running some service in the cloud as a service is that you can put a lot of telemetry and you can understand what are your customers doing and where they are spending their time and what you need to work on in order to improve their experience. And that's what we do, right? In a repeat fashion, for example, in this graph, I'm showing back what we did back in 2018 where we looked on the fleet and we said, okay, let's keep on improving performance and doing, you know, start, you know, like a walk-a-mole game of improving performance in various places. And we were able to improve, for example, the performance of Redshift in the, you know, TPCDS benchmark by 3.5 times within a year. And there was not a single silver bullet that did that, but it was very much focused on where the time goes and fixing that going to the next. And we keep on doing interesting stuff there. For example, we just released, like string processing is one of the most important, strings in general is one of the most important data types in a warehouse. And, you know, we are starting now to becoming really, really smart on how we do efficient processing of strings. We just released some, you know, we just announced now that we can get up to 64, 63 times speed ups on a special strings with low cardinality. And we keep on innovating in this area. And can you talk about what are you doing here?  I know how to, like, do quick, like, look up on it or like, or like, yes, no, it's not obvious, like. Yeah, I mean, to be honest with, like for the low cardinality strings, I mean, there are, you can do so. First of all, there are very, very many columns with low string columns with low cardinality in the world. You would be surprised how many there are. And if you know that you have a domain of strings that has very, very low cardinality and take advantage of that, then you can do a bunch of tricks. For example, you could like, you can either do something like a dictionary coding that has low cardinality, or you can even encode them as byte, this is what we do. We use a dictionary, a byte dictionary in order to encode the data. And then we use AVX execution in order to process them very efficiently in press code. But you're only doing this for like red ship managed storage. Like someone doesn't look parquet file, it has this, just get in and you can't do anything. So we, so the answer is yes, like these encodings are the encodings that I'm talking about here are on the kind of, on the managed storage version, not on the external one. So, you know, very much focused on performance. And this is, you know, you can see it in kind of in the public domain. For example, I'm showing a graph here that this is a graph we showed back in a tree event last year where we went and said, okay, red ship provides up to five times better price performance than other popular cloud data warehouses. And this is an out of the box benchmark. Out of the box means that we don't spend any time tuning any of the warehouses. We just define the schemas, we load the data and we start running the benchmark. As a database practitioner, one universal rule, I can share with you a secret maybe is that the highest performing data warehouse in the market is the one that it is consistently second in all the competitors benchmarks. And you know, you can go and check which one is that in currently. And I would claim that this is resist. So we feel very well in the performance we are getting. A workload that it is very, very interesting and it is becoming increasingly common in warehouses right now is more near real time or operation and analytical workloads. So what we see is that customers start running workloads that have higher concurrency, more concurrent request and the response times of the individual request is smaller. And we're spending a lot of our energy in trying to improve this particular type of workload. And because Redshift generates this C++ code that is very, very tight and very small in terms of consumption of resources, Redshift does very well in this type of workloads. So in this graph, we are comparing Redshift against other popular cloud data warehouses in a workload that we have an increasing number of smaller requests, very small and short running requests. And you can see that Redshift achieves up to seven times higher throughput than competition. So we did all that Redshift achieves pretty good performance. And the next thing our customers went and told us is okay, performance is good, but we would like to put more data into the system and we would like to have also more concurrent users using this system. Can you please do something about it? And this is where kind of the bigger architectural changes in Redshift happen over the recent years. As I told you earlier, by the way, Andy, I hope I have 30 minutes, right? Yeah, you're turning the time, keep going. Okay, okay, okay. So, okay. So the biggest architectural change as I told you was the separation of compute and storage in Redshift. When we launched the service, the highest network bandwidth you could get out of EC2 was 10 gigabits on a full droplet. And that was becoming a challenge as you were trying to offer high performance, high performance in a disaggregated compute and storage environment. But as we moved now to in an EC2 world where it commonly offers instances with hundreds of gigabits of network, now this kind of evolution in the network speeds enable this disaggregation of storage and compute. And that's what we did. We separated storage and compute and you can see now that EC2 has announced instances that have 200 gigabits in a droplet, 400 gigabits, 800. And I think at the last event we even announced the Nissan's that had 1.6 terabits of network within a single EC2 droplet. So we separate storage and compute and now we are able to operate on more data within a single database. In this graph where it's one of my favorite ones, what we did is we start running the TPCDS benchmark and we scale the dataset size from 30 terabytes all the way up, oh, sorry, from 10 terabytes all the way up to one petabyte. So we increased the dataset size of the database by two orders of magnitude from 10 terabytes to one petabyte. And what we did is we increased proportionally the hardware we were using, the size of the computing environment to run this benchmark. And what you can see is that the time it took to run this benchmark it stayed pretty much the same around two to two and a half hours. Even though this is the expected thing and you say, okay, da, you use two times proportionally more hardware than the dataset size, this thing should scale. This is a very hard engineering challenge and we are able to actually achieve it in the petabyte scale. This is a very nice property, like customers, they can use this kind of nice linearity in the increasing performance and scale to be able to forecast their expenses, do their planning and say, okay, I will need that. My data growth is X, it will cost me that much and they can do the proper planning and type and management. So by doing that, we were able to kind of solve this data scalability challenges in Redshift. The next area where we looked at was on the scaling on the compute side. Scaling compute was a challenge in Redshift and we were able to address it with two different techniques. The first one was to, we implemented the ability to change the size of any individual Redshift compute environment by up to 4X, either 4X up or 4X down. And the way we do it is we bring some nodes in as you asked me earlier, if it is consistent hashing, what we do is we take, we, at the metadata level, we assign some of the data buckets from managed storage, from the old nodes to the new nodes. And then we start, we resume operations. And by doing so, we are able to increase the size of the system up to 4X up or 4X down. And the customers use that in order to hunt you the SLA of then individual workload to meet their SLA. So they can fine grain tune the size of the environment to meet their needs, their SLA's. And once they fine tune the environment, there will still be the Monday mornings where all the, you know, all the employees of a company will come in and start running workloads. And there will be some, you know, at some point the system will not be able to process more concurrent requests, right? It will, it will be, there is a finite number of resources that are being used there. So at some point it will say, you know, I cannot admit any more requests at this point. Can you please wait? And what we do in order to even, to solve this problem of bursts of concurrent requests was we built an auto scaling capability which we call concurrency scaling, which what we do is the requests still come into the main Redshift computing environment. But if there is queuing happening and the customer has elected to auto scale, we bring equalized computing environments and we start running the queries, still, you know, overflowing the queries to this computing environment and them accessing the data from their managed storage to keep on improving the throughput of the system. The customer does not need to do a single change in their application and they start getting auto scaling capabilities. There was a question. But the scaling is done at sort of like, like within a timeframe of I need this for five minutes to run the queries and then it goes away. Like, so again, we discussed Snowflake has their flexible compute and probably tell it's doing that on a temporary basis. Like, you know, when you grab some nodes and resume stuff sounds like what you're doing here is you're bringing up a whole nother like compute cluster. So it's not something you want to do on a temporary basis. You're doing for some period of time. Yeah, yeah, it is very economical because now say you have, you know, I say, I'm just doing some rule, a simple example. I'll say you can run five concurrent queries in one environment and then you have 10 concurrent. So then you bring the other concurrent scaling environment you start running another five. So you can actually amortize and you have more efficient, you know, process. You are getting this auto scaling capability but at the same time the cost is, the cost remains low, right? It does not scale with the number of queries but it scales with the number of environments that run there and you can multiplex multiple queries within this environment. Yeah, thank you. Yeah. And the cool thing is, you know, customers do not need to do a single change in their application. And in this graph, what we're planting it's an experiment we did in the lab when we, before in 2019, at the beginning of the year we did not have the ability to auto scale. At the end of the year we were done implementing this capability and you can see that the beginning of the year the maximum throughput one could get was from five concurrent users submitting queries from this DPCDS benchmark and they could achieve approximately 200 queries per hour in this workload. By the end of the year for the same experiment we were able to achieve over 12,000 queries per hour from 210 concurrent users submitting queries with zero think time. This emulates a realistic environment where you have thousands of concurrent users running using this environment in Redshift. So we were able to achieve 60X improvement in concurrency without having a single change in their application. The only thing that the customer had to do is to enable in a box enable concurrency scaling in my environment. You know, this is, it's an impressive improvement in the throughput of a system which was unheard of in the traditional on-prem days to have this type of elasticity and go back contract when the burst of activity goes down. Right? We did that and by doing both the ability to online and elastically resize any computing environment then auto-scale to improve the throughput we were able to address the needs of our customers in elasticity on the compute side within a single Redshift environment. The next thing our customer said after that was we like this elasticity but now we would like to have separate environments separate computing environments to run our analytics. Say because we want to charge the individual environments to different business groups or we want to have isolation because we have data scientists where they want to run on their own environment and whatnot. And that's what we did. We built the ability to set data, live data in a transactionally consistent function across Redshift environments. So you can have a producer environment, producer cluster writes the data, we enforce a snapshot isolation in Redshift and the data gets committed into Redshift managed storage and then you can have other consumer clusters or serverless environments that read this data in a read-only fashion and in a transactional consistent way. And those things can fail independently and you get this isolation and you can charge back and whatnot. And these systems can also auto-scale independently like auto-scale or online resize independently. And you can do this thing within clusters and environments within one account or even across accounts or even across regions. We do have customers that have business in say the US and the Europe and they have separate environments in different regions and they are able to run analytics in their environments across regions without having to move data and build weird pipelines to move the data in one place in order to do this. So building a transactional consistent global data sharing layer in Redshift, we were able to do it and customers really like this ability. So by doing all these things, we were able to address the needs of our customers in terms of storage elasticity, computer elasticity, computer isolation and ability to serve data across accounts, across regions and whatnot. So we did all these things and our customers were quite happy. They said, they were saying, okay, performance is good, elasticity is good. Still Redshift is a little difficult to use. I still have to think about, have to have a dedicated database administrator to tune my environments. Can you please do something about that? And that's what we did. So since in the cloud, essentially what our customers are doing are reading some compute time. What we do is we take advantage of any idling cycles in the systems and we try to run machine learning based optimizations to take all these mundane operations that usually are where is possibility of database administrators and make them a service problem. So what we do is we monitor the workload. We see what the customers are running and then we have a list of tasks that we would like to execute to perform on behalf of the customer in the background. And we rank these operations in terms of priority and impact, right? Which the biggest bank for the back is the one that it's prioritized first. So we may decide to run some analysis, analyze some tables to update the statistics of these tables to get better query execution plans or we may decide to vacuum a table or we may even decide to change the physical schema of a database if we decide that this is the right thing to do. In order to be able to make this kind of decisions, you need to have very strong and high confidence signals. And we have to keep on improving on the algorithms we use in order to make these such recommendations. There is, for example, this VLDB paper back in from 2020 where we kind of describe the algorithm we use in order to make distribution key recommendations for the tables in Redshift. When we started this capabilities, we were just sending these recommendations in the console. We were saying to the customer, hey, you may want to have, you may want to change the distribution key of your tables because we feel that this will improve the throughput of your system, the performance of your system. As we gain confidence by getting some feedback that those recommendations were good, we actually took it to the next level and we start doing them on the fly, on behalf of the customer without asking, without having requesting the customer to take an action. So in particular, we introduce a new type of table, which we call it an auto table. And when the customer defines a table as being auto, it gives the responsibility to Redshift to go and perform all these optimizations. And in this graph, what I'm showing is one of my favorite graphs is what we did is we emulated, we did an experiment where we loaded the tables of TPCH, one of the benchmarks, we loaded 30 terabytes of data and we start running this workload without doing anything else. And what you can see is that within some hours, the performance of the system improved by almost the two exit, went from running within 100 minutes and went down to running within 60 minutes, without the customer having to do anything. And the way this happened is was the system picked change distribution keys, short keys and coding and whatnot in order to bring the performance of the system down, to improve the performance of the system. And now we are taking it to the next level and we not only go and change the physical schema of the physical properties of some of the tables in the database, but we may even go and decide to create materialized views if we feel that this is the right thing to do. So what think about it is if you have every morning at 9 a.m. a specific report that the customers are using, we may decide to create a materialized view for this report and keep on refreshing it so that the system does not have to go and execute this query on the fly. If the customer stop using this particular materialized view, we may decide to drop it. So this very active monitoring and continuous enhancements in the performance is something that again, it's kind of a theme that you can see in the cloud. It's auto tuning capabilities is kind of now the expectation in the cloud, in the cloud database world. So what isolation level do you provide for the customers? Like if you insert something to the table and they see the update immediately from the machine-like view or like they're only using waves. So what we do is we have auto-refresh. Like we're gonna, we have a materialized views technology in Redshift is we have a very wide set of operations where we do incremental maintenance of those views. And for the ones that we do incremental maintenance, we also, we have the ability to auto-refresh them. So with the combination of those two allows us to go and keep the materialized views fresh. So the question is like, if I have a transaction, I do an update on something. Do you refresh the materialized view on commit or inside the transaction? No, no, we don't refresh it on the commit. We actually refresh it off, right. It's like a cron job where you can push the refresh. Yes. Yes. It's based on post-graphs. Yeah. Yeah. But actually you don't might see some O data either after a third form of data taken from the machine-like. The standard is a customer might see old data, stale data, if they make a change that they expect them to get applied to the materialized view, they commit and then merely query something that is materialized view, they may not get back the result that they expect. So, yes. So what we do is, yes. So we try to immediately refresh the materialized views. The customer, if he wants to always see the transactional consistent data, they can simply run a refresh of the view prior to running the query. And the refresh will become a no-op if there is nothing to refresh. Again, it's not a transactional, it says that you don't, it's not materialized. We're done here, sorry. Yeah. Keep going. Okay. So another nice area of using machine learning in the database has been in the area of workload management. Like, if you have taken more class about operational research, if you have big jobs and small jobs in a queuing system, the best way to improve the throughput of the system is to get the small jobs, admit them as fast as you can, get them in and out of the system quickly and then for some kind of queuing for the large jobs. And this is something that Redshift has been doing for several years. Now we have a very, a symbol classifier there that tells us whether a job is big or small. And if it is small, we get it in and out of the system as fast as we can. We took this technology and now we have been building the ability to predict not only the runtime of a job, but also the resource consumption of this job. So we can predict the CPU, IO, memory needs of the particular job query. And by using this information now, we are able to bin pack more queries into the system and get better, more efficient utilization of the hardware that the customers are running on. So we are able to pack more, improve the workload admission, the admission control algorithm by having this knowledge of the resource consumption of those queries. Can you say anything about like, what that pre-production model looks like? Does it look like Ryan Marcus's QBB net or is there something else? It's something else, but we work, Ryan Marcus is working with us a lot.   All right. So we did all these things, the autonomics. And the last thing the customer said, okay, we like that, but still there are some decisions we need to make in order to size our Redshift environments. We need to decide how many nodes we are gonna put, what kind of FISTAs types we're gonna use and what not. Can you please make our lives easier? And so the culmination of our autonomics efforts was the introduction of Redshift serverless. Redshift serverless is a new experience we introduced this past summer, which takes all this automatic, machine learning based workload management, monitoring and management, the auto scaling, the auto tuning, the auto maintenance. And we kind of wrapped it around an intelligent, compute management layer. So we take decisions about the sizing, the auto scaling and what not. We don't give options to the customers to decide about instance types and stuff. We can change the hardware and there is as EC2 hardware improves, we are improving, we are improving. So we are offering the whole capabilities of the SQL capabilities of Redshift in a serverless experience. And we get very, very positive feedback so far with that. We have thousands of users using it. And you still get kind of all the SQL servers that Redshift used to has from data sharing, manage storage, also integration with streams, operational databases, SageMaker, Lambda, everything. So we did all these things. And with all these things, I kind of, I tried to give you an overview of, we took Redshift from and we kind of changed the architecture of the guts of the system and we are able to offer now a system that has separation of compute and storage, can auto scale, has autonomics and it is offered in a serverless experience. And so that is kind of the core of the system. The last area where we are putting a lot of our energy is in the area of integrations. So now once you have this very strong core in the warehouse, what we are trying to do is to integrate with the rest of the ecosystem. Analytics is not a single, you don't buy a warehouse and you are solving analytics. The data lifecycle is coming from, is complex. So customers have data in their operational stores or they have the data, they put them in a bus, in a stream or they just have files and they want to use machine learning on them. So there is more to that than a basic cloud data warehouse. So what we have done, for example, we have been having the ability to query data in open file formats in S3. We have the ability to query also the data that sit in operational stores in RDS Aurora and RDS MySQL and Postgres databases or RDS and Postgres and MySQL databases. But now we're taking it to the next level. So we have the ability to have streaming ingestion from the streams from Kinesis and Kafka but we also introduced the zero ETL capability where we went and we integrated with Aurora's storage layer and we can move data from the Aurora storage layer to the Redshift managed layer and you have this zero ETL capability between Aurora operational store and Redshift. So, and that is on kind of on making easy to ingest data, move data and process data in Redshift. And then on the consumption side, not only we have been offering SQL capabilities but we have integrated with SageMaker which is the suite of machine learning tools at AWS. So you can go and create models from SQL within your SQL to create a model based off of data that are managed by Redshift and those models then can be consumed as inference for inference as SQL functions within Redshift. So you can go and write SQL queries and then you can do select something where inference or scoring function from column two from table block. So there is a lot of integration happening on the other side. And then at the core of it is the data warehousing technology based off of Redshift managed storage, separation of computer storage, data sharing and serverless. And we are quite excited with where we are and we're getting very positive feedback of how the service have changed and how it can address the needs of the customers as they move to more modern data architectures. And that's what was it. So over the past 45 minutes, I went and gave you an overview of how we have evolved Amazon Redshift over the past 10 years. We have tens of thousands of customers processing exabytes of data daily. We have strong security posture. We are very focused on performance and scalability. And then we use a lot of machine learning in order to make Redshift easy to use, to build autonomics and build a serverless experience out of that. And we have also very tight integration with the rest of the, you know, the broad set of AWS services. And we enable integrations as well, data-based architecture on top of that. And we are excited for the future. And as we like to say at AWS, it is still day one. And we believe that we are still scratching the surface of what customers can do in the cloud for analytics and data management in general. And that will conclude my talk. Thank you. All right, any questions? Yes, go ahead. We have a question. So the Redshift support UDF and the Redshift support UDF consolidation. Redshift, we need to, Redshift for UDF, yes. And do you guys do UDF compilation? So we have two UDFs, right? We have SQL UDFs and we have Python UDFs, right? So the SQL side, yes, of course. On the Python, we run the Python code in a contain. Do you support PLG SQL? Yeah. Oh, okay. All right, but you don't compile that. Yeah, I'm sorry. But you don't compile PLG SQL. We do compile PLG. Oh, okay. Yes, yes, absolutely. All right, that's your question. Anybody else? Yeah, and by the way, also the very interesting is related to that is when you are training a model in SageMaker, for many of the models we have in SageMaker, which you could have trained it in Redshift data, the SQL, the inference function, what we do is we use SageMaker Neo, which is a compiler. And for these one P models, what we do is we generate C++ code for the model and we link it as part of the executable. So then we run filtering and predicates and inference within one C++ executable, which makes it very, very efficient. Yes. I have two questions. I have two questions. My first one is, is there anything you've seen in another kind of database, data warehouse, and so we've covered in this class, we've covered Dremel, we've covered BigQuery, we've covered, oh, no, no, no, no, sorry. BigQuery, we've covered Photon, we've covered Snowflake. Last class was Bellox. We didn't cover anything with Microsoft. Is there any feature or anything about those particular systems that you thought, like, that's a cool idea. We'd like to do that in Redshift one day or if I need to cover it, but recording off, like, I can do that too. Yeah. I will tell you that, you know, as I told you in the last sentence, is I still feel, you know, we are very excited with what customers are, what you can do in the cloud. Like, you know, as we learned the data, you know, you and me, we were, you know, learning about databases using the cow book, there were specific rules, like, for example, you could then auto scale, you could, there was finite set of resources, you couldn't think about storage and compute separation and all that stuff. So we are very excited with, we are still, I think, scratching the surface of what customers can do in the cloud with all these kind of interconnected services and things that they can scale on demand.  I see, I have a third question. Do you guys use kernel bypass or anything, like dbdk, spdk? I mean, obviously we are very close to hardware, right? We do all sorts of stuff to make efficient usage of the underlying hardware resources. And we work very closely with the EC2 teams on that. Yeah, okay. All right, and this one we can cut off for the video. You know, there's a lot of students are worried about the, you know, the big layoffs in the tech companies. Amazon is not new to this. And I can be telling them database companies or database divisions in these cloud companies are still making a ton of money. Is Redshift still hiring? That's my favorite all right. What is it? Yes, it's the S.T. Cricut, I.D.E.S. I make a mess unless I can do it like a G.O. Ice cube with the G to the E to the T.O. Now here comes Duke, I play the game where there's no roots homies on the cusley, I'm a Foucault, I drink brook with the bus a cap on the I.D.S, bro Bushwick on the goal with a blow to the I.D.S. Here I come, Willie D, that's me, I'm a four six pack 40 act gets the real pass I drink brook but yo I drink it by the 12 they say Bill makes you fat But saying eyes is straight so it really don't matter


Hi, I'm Amanda Mahaffey. I work for the Forest Stewards Guild and I'm going to help introduce your handy habitat assessment tool for forestry for Maine birds. So, first step is to take your three fingers on each hand and point them like this. On your left hand, we're going to talk about live things. On your right hand, we're going to talk about things that aren't alive, but are really important habitat features for forest birds. So, first on your left hand, we are going to talk about overstory, mid-story, and understory. Since I am in the understory, I'm going to talk about that first. If you imagine zero to six feet, any any woody vegetation that you see in zero to six feet, there are going to be certain forest birds that will key in on that. We're going to get into detail in a little bit. Mid-story is between six and thirty feet. So, you can imagine between six feet off the ground and approximately three stories up in the air. That's the mid-story and in that mid-story you can have stems, you can have branches, you can have leaves that all provide really important habitat for forest birds. And then, we have the overstory. So, if you can picture a three-story building thirty feet in the air and all the woody vegetation that is up in the canopy up in the tops of those trees, that's another key area that certain forest birds will key into. So again, on the left hand, we have live things. Overstory, mid-story, and understory. Now, coming back to your handy assessment tool, on the right hand, we have things that aren't so live. First, we'll talk about snags and decaying trees. Then, we'll talk about coarse woody material and fine woody material. So, snags and decaying trees. As you look around your wood lot, you're probably going to see some trees that look like they're in kind of rough shape. You might find some that have really thick trunks that might have holes in them. You might hear certain kinds of woodpeckers and other forest birds that are really taking advantage of those, those big dead and decaying trees. So, snags and dead and decaying trees are one habitat feature you want to look for. Then, we have coarse woody material. We'll show you some good examples, but coarse woody material might be some big pieces that are thicker than the stuff you see here, and you can find those after a logging job. We'll show you some good pictures of that as well. So, piles of coarse woody material are something that other forest birds will key in on. Last but not least, we have fine woody material. So, tops and branches, smaller material that you find, provides habitat for insects, which is a good foraging habitat for other forest birds. So, a quick review of these, and then we have some bonus features for you. So, on your left hand, live things, over story, mid story, under story, and on your right hand, things that were once live, snags and decaying trees, coarse woody material, and fine woody material. Another habitat feature we have some bonus features for you is leaf litter. So, the oven bird, which was singing right before we started filming, really keys in on hardwood leaf litter. So, that's a habitat feature that you'll want to think of for your oven bird. Pizza, pizza, pizza, pizza. Also, you want to think about tree size and stand age. So, as you look around, size matters. Basically, the bigger the better, whether it's live or dead. So, again, our bonus features over here, we have leaf litter, hardwood leaf litter, and we have tree size and age. Now, your bonus features on your left hand, we have canopy gaps and riparian areas. So, canopy gaps. After a timber harvest, or as would naturally occur when a tree falls in the forest, you get these beautiful openings, and in those, you probably have seen some nice pools of sunlight, where insects like to fly around, like they are right here. And birds, certain birds, the eastern wood peewee and others, will come in and swoop in and catch those insects on the wing. So, canopy gaps are an important habitat feature to look for in your wood lot. And then, riparian areas. So, riparian, meaning waterways. So, we'll go visit a riparian area in a little while, but just down the hill here, there's a nice little quiet stream, and there's some nice cool shady features and certain kinds of trees and shrubs that like to use that habitat. And then, there are forest birds that also like riparian habitat created by those trees and shrubs. So, once again, for your bonus features, on your left hand, we have canopy gaps, and then we have riparian areas. So, it's a lot to remember, and you can always come back to your original six of live things and used to be live things. Overstory, mid-story, understory, snags and standing woody material, coarse woody material, fine woody material. So, thanks for tuning in. Thank you so much, Amanda, for that great introduction to our Forestry for Main Birds habitat features. And next up, we're going to have Andy Schultz from the Maine Forest Service dive in deeper on the live features of the forest that birds queue into. So, come back soon!


Hello guys, this is Dr. Ahmed Ergen. I'm an endocrinologist, a diabetes education specialist and a metabolism expert. Today, we are talking about how to bring blood sugar down in the morning, or the fasting blood sugar. So, let's get started. So guys, a lot of you in my clinic and in the questions in the YouTube, asking about how to bring fasting blood sugar down. And that is a good question, because a lot of people have high blood sugar in the morning during the day that are fine in the morning that are high. They're like, hmm, what's going on here? Because I'm going to bed with an okay blood sugar. I wake up with a high blood sugar and I'm doing nothing. I'm sure I'm not, you know, sleep eating or I'm not doing anything at night. So then why is the blood sugar high? Well, we have a video about this, very comprehensive. Why is fasting blood sugar high? You can click on that link below in the description. But today, we are talking about how to fix it. So again, that's not going to be one way street. So you have to be patient here, because what works for you may not work for someone else. So you may want to see what will work for you. Now, if you know the reason, sometimes you will figure out how to fix it too. Insulin resistance is the biggest problem, right? Insulin resistance in addition to what we call relative insulin deficiency. So your body for most diabetics are insulin resistant and somewhat insulin deficient based on the need. So I always give this financial examples, because it makes resonates with people more. You know, if you have an expensive car, an expensive house, you have to make a lot of money. If you keep buying things, you know, credit card expenses go up. If you're not making any more money, it looks like you're actually poorer because you're in debt.  So same thing with diabetes. You know, your body when you have abdominal circumference, a lot of fat in your body and you're not eating good food, et cetera, et cetera, or you have not done good in the past. And now you're trying, but you're still insulin resistant because insulin resistance does not develop overnight and it doesn't go away overnight. So when you have insulin resistance, your body is not able to keep up with it. Now, how does really blood sugar go high in the morning? You know, your liver makes sugar and wants to maintain your blood sugar at a healthy level. But your poor liver has no idea what to do unless your insulin tells him what to do. I said him, I'll say it. Unless your insulin will tell it what to do. Now, the liver may also be insulin resistant. So your insulin may be not in the door, but your liver is not responding. So as a result, your liver is thinking that there's nobody coming to saying, okay, don't make too much sugar. So your liver goes crazy because it's like, if you don't know how many people are coming to your house for dinner, then you better make a lot of food, right?  I'm just going to make a lot of sugar. Then the question is, do you need insulin? Well, maybe you do. Or there are alternative ways of, you know, making that insulin or cutting the expense with just insulin resistance. So what we need to do here is either make more insulin, right? Your body has to make more insulin if it can, which it can. We know that because there are a lot of non-insulin medications that can help you with that. If you don't want to take a medication, what you have to do is you have to reduce the insulin resistance. Now, there are some medications actually that help reduce the insulin resistance as well, which we will talk about. And by the way, our supplement, sugar MD Advanced Glucose Support is on its way. I'm going to tell you guys in two weeks or so, it should be on Amazon and it should be in some local stores as well. But I am going to tell you when it's time and you will be able to purchase that. That new supplement will be able to make your body make insulin and reduce your insulin resistance in a totally natural way.  Sometimes insurance doesn't cover the good medications, etc. There are so many reasons that made me produce or manufacture this new supplement that brought together a lot of natural things that I know for a fact helps the blood sugar, especially in the morning. Having said that, you know, we said that there are medications or there are some supplements we are coming up with can help to bring the blood sugar down. Now, if you don't want to do any of that, then you really have to take some action. You have to really up your game with the exercise. Now, exercise is very important. Now, a lot of people will tell me, oh, doc, I'm busy. I'm always on my feet. That's not really exercise. What we are looking here is a consistent 30 minutes to an hour exercise with a rhythm where your heart rate goes up, your muscles continuously uses the glucose, reduces the inflammation in your body and make you more insulin sensitive. And you have to keep doing that almost every day because once you take a break, your body goes back to where it was. So insulin resistance and exercise go hand in hand. If you do not exercise, you become insulin resistant very quickly. So you do not want to give a break more than 48 hours if you're exercising and you have to keep your heart rate up as much as you can. I mean, if you have a heart disease, etc., it may not be possible for you, but at least whatever you can tolerate, discuss with your doctor first. Sometimes you guys may need a clearance if you already have some chest pain or some exercise intolerance. But for most of you, you should be able to start walking and gradually increase your exercise capacity. Start walking a mile and then a two miles and a three miles every week. You can put yourself a goal. Now, walking is not the only thing. There are a lot of you have joint problems, hip problems, knee problems. You can try bicycling, stationary bicycle. You can even use your upper body.  Your body is not just your back and hip and knees. You have a lot of body parts that you can actually use to get your heart rate up. If you start doing that, you will realize that you are definitely bringing your blood sugar down that way. Another way of reducing insulin resistance as we always talk about is intermittent fasting. So if you, for example, do not eat after six o'clock and increase that fasting period, your body, that 12-hour period overnight, at least 12 to 16 hours, your body is going to be able to handle sugar a lot better. And if you fast even longer, like 16 hours, 20 hours, of course, then you first start, it's not easy to get to those levels. But I always tell my patients, hey, if you're not able to fast for four hours, try it four hours first and then try five hours and then try eight hours. It's like an exercise. The more you do it, the more conditioning you get. The more fitness you get out of it. So same thing with the fasting. You just need to condition yourself, train yourself to stay hungry longer, and that definitely will help you bring your blood sugar down in the morning. Again, if you have excessive abdominal obesity, if you have excessive insulin resistance, unless you get rid of that excessive fat, or unless you push your body to stay hungry for a long time, or you push your body to exercise more, you are not going to be able to do that. Now, when you exercise more, you get hungry more, and when you break a fast, you may feel like you may want to indulge in. The trick here is to have a high protein and high fat diet because your appetite will immediately go down if you're starting your breaking fast with water. Very important, you have to have a glass of water before you eat anything that helps to prevent overeating.  Although you may be dreaming about carbs when you're fasting, your body is craving, but instead of reaching out to that bread, or reaching out for that pasta, reaching out for the potato, if you eat your protein and fat first, you're going to realize that that carbohydrate is not as appealing to me anymore. You know what? I can go without it. And as a result, you're not introducing more carbohydrates to your body. You're fasting longer. You're eating healthy protein and fat. First of all, you're going to feel amazing. You're going to feel great. You're going to want to do it again. It's just an exercise.  Your body is aching.  You feel like, oh, my God, I feel so much better. Or next day, you feel better. Your exercise capacity gets better. So same thing with fasting. Initially, it's kind of a little hard, but then once you get the hang of it, then things are a lot easier. You're satisfied because your morning blood sugars are better and so forth. As I said, guys, do your best, whatever you can do with these diet and exercise measures we talked about. Metformin is a drug, a pharmaceutical drug. Pyagulatazone is another pharmaceutical drug. They have data drawbacks. Not everybody is a candidate for those drugs. There are GLP-1 drugs we like because they help with the appetite control, such as Ozympic, Rubellis, Trilicity, a bunch of brands out there. They help. We call them a GLP-1 class. So I prefer if I have to use a medication. I try to use those medications. The only barrier in front of me is typically the insurance. Insurance companies wants you guys to use the cheap drugs. Again, we are not trying to give you expensive drugs, but like everything in life, something is good. It comes with a price, especially these regulations. They are somewhat very expensive for that reason because the production cost is too high. But thanks to the supplements, the FDA still regulates them, but not as tight as pharmaceuticals because, you know, they're called considered dietary supplements. We are basically using hundreds of years of experience, an actual experience that people have used for diabetes, loss of sugar management, insulin resistance management. So we came up with a sugar-empty supplement that may be a great option for you. Now, don't ask me how to buy it because it's not available. As of today, it will be available at the end of February or early March on Amazon. It's called Sugar MD Advanced Glucose Support. And again, we'll definitely announce that on YouTube as well.  Make sure you give a like and comment and share this video. We'll see you in the next one.


Hey everybody, Matt here for Layton Sports Cards, ripping eight boxes for Chris G. We have five boxes of 2022 Bowman Chrome Baseball Sapphire and three boxes of 2023 Bowman Baseball Sapphire. Again, these are for Chris G. Good luck, Chris. Start off with your 22 Bowman Chrome. I don't like mixing my sapphires. Just got restocked in on Bowman Soccer. That stuff is really nice. I love the card stock on it. There's Junior Perez and Aqua Sapphire. Oscar Coloss. First Bowman. This is one of 99. Nice one, Chris. Good start. Zeke Yoltovar and Kyle Tucker. Rosamond Verdugo and Edward Cabrera, James Wood and Francisco Lindor. Yendri Rojas, Joey Bart, Francisco Alvarez and Bryce Harper. Come on. Let's see a monster. Michael Hernandez, Lubaab, Zach Veen and Gabriel Arias. Rookie, Ryan Reckley, Joe Adele, Ladies Jordan and Hunter Green. Rookie, Ysoma Robelle, Rafael Devers and Orange Sapphire to 75. Irrigal Anjeles. There's Juan Soto, Otto Wilfred Verras, Randy Rosarena and Jay Allen. West Cath, Bryndella Cruz. Rookie, Dylan Carlson and Benny Montgomery. Comes box number two. I still only have five boxes in two after this. Only five. Pelonzo, Jose Rodriguez, Matt Manning and Cesar Prieto. Junior Perez and Orange Sapphire to 75. Jose Rodriguez, Kyle Tucker and Nelson Velasquez. Let's activate some mags here. There's Edward Cabrera, Rosamond Verdugo, Francisco Lindor and Ezekiel Tobar. Yendri Rojas, Joey Bart, Francisco Alvarez and James Wood. Michael Hernandez, Lubaab, Gabriel Arias, Rookie and Bryce Harper. Ryan Reckley, Joe Adele and Marcus Simeon, Aqua Sapphire to 99. Zach Veen. Dude, Marcus Simeon is just so under the radar. Yeah. Last year, everyone in 2021, 265, 45 homers, 102 RBI's. Yeah, Yisalmer Obel, Rafael Devers, Blaze Jordan and Hunter Green. Rookie, Wilfred Verras, Joey Vado, Jay Allen and Juan Soto. Similar boxes there. Box number three. Bryndella Cruz and a Rookie Orange Sapphire. It's a cardinal, so you know he's a winner. Juan Yepez to 75. Winner. Winner, winner, it's your container. That's right. That's Yepez, Benny Montgomery and Randy Rosarena. Luis Heel, Westcath, Roberto Campos and Dylan Carlson, Joey Gallo, Henry Davis, Yerling Compadon and Redalpo Castro. Hope he don't. Hope he don't. Keep Ryan Hayes, Everson Artega, Christian Vecchero, Christian and Joe Ryan Rookie. Well, he's just turning the lights laser on. What's his name, Christian? Nick Ladolo, Warming Bernabell, Jonathan Mejia and Christian Pache, Wilson Contreras, Liova Piguero and Rookie Yellow Sapphire to 50. Nick Ladolo, Ladolo, Ladolo, Ladolo. Nick Ladolo, Yellow Sapphire to 50. J.D. Martinez. How's Ladolo down this year, huh? He's been hurt by the majority of the season. Henry Mendez and Maddison. Aqua Sapphire to 99. Kyle Lewis and Arribilo Angelas. Royce Marquintana, Vidal Brujan, Rookie, Giancarlo Stanton and Khalil Watson. Box number four. Again, just five boxes in queue after this. If you get a box now, you will not be waiting long. O'Neal Cruz, Rookie. Swar Garcia and Julio Rodriguez. That is Rookie variation. There you go, Chris. Nice J-Rod. Awesome. More of that, please. Jose Ramirez, Max Scherzer, Edinson Paulino, Jordan and Luis Mesa. Jose Altuve, Matt McClain and Orange Sapphire. Pietalonzo, 50 of 75. There's Willie Vasquez. I want to see Pietalonzo turn villain, like turn baseball villain. There he is one. There's Byron Buxton, Eric Hernandez, John Kinsey Noelle and Aaron Ashby, but to like fully commit to it. I think he's getting there. I mean, I don't have people liking it. Reed Detmer's Rookie, he wasn't the same after Stubby Clav took him down. Brian Acuna, Carson Williams and Juan Yepez. He's not like Correa or bad. No, he can like, like when he does interviews with the reporters, answer every question with a question, start referring to himself in the third person. Andrew Vaughn, Jason Churio, Anthony Volpe and rookie MJ Melendez. Start referring himself as Polar Bear. Like, yeah, always in the third person. Polar Bear did well today. The team did not. Lloyd Jimenez, Alex DeJesus, Sal Freilich and Bryson Stott, rookie. Polar Bear did nothing wrong. Jackson Joe and Yellow Sapphire, Leo Verpeguero to 50. Nice Pirates color match. Luis Rodriguez and Mackenzie Gore, rookie. Polar Bear struck out three times today, but Polar Bear had to do what he could to try to help the team because the team wasn't doing much to help the team. Sometimes pitches ain't there. Sometimes you got to try to make them there. All right. Polar Bear did what he could. I'm the one Polar Bear. Nine men on the field on the other side. There's Drew Baker, Ryan Valade, rookie. Noel V. Marte and Jazz Chisholm. Faunas, there's Mookie Betz, Oral Vera and Jose Miranda, rookie. Robert Hassell, Christian Yelich, Will Mendeaz and Helio Ramos, rookie. Come on, let's see something big here. PCA, CJA, Jordan Lawler and Vlad. Victor Acosta, George Kirby, rookie. Jordan Walker and Marcus Simeon. Stephen Kwan and Yellow Sapphire. That is Jazz Chisholm Jr. to 50. Oscar Coloss and Manny Machado. George Valera and... This is going to be a variation too. This is rookie. Yellow Sapphire to 50. CJ Abrams, variation. That is rookie to 50. Very nice Abrams. Jordan Delo Santos and Brandon Marsh. Abrams turning into a pretty good ball player. Shane Boz and Aqua Sapphire to 99. Manny Machado, Samuel Zavala first bowman and Brandon Crawford. All right, on to 23. The Nationals have been playing pretty well recently. For the Nationals.   There's Henry Davis, Jose Perosa. Like just sweep a team and knock them out. Yeah, I get what you're saying. I mean, it's definitely possible with that AOS. Yeah. First bowman, Orange Sapphire. Drew Jones to 50. 11 of 50. Chris G, congrats. Let's go, man. Let's go. Nice, Drew Jones, 11 of 50. Orange Sapphire, first bowman, Orange Sapphire. I'll tag that one for you. There's Alex Sol Sanchez, Michael Arroyo, Wilbur Sanchez, Mikey Romero and Jefferson Rojas. Yeah, man, that's awesome. All right, we just set the bar with the Drew. Let's see if we can top it here. It's Javier Osorio, Glider Figuero, Chrisian Vecchero and Alejandro Suna. Good luck. Chrisian. Yeah. Chris, Chrisian. Miguel Blyce, Newellian Sidenio, Ronnie Simon, and Sedan Raffaella. Colton Couser, Elijah Green and Green Sapphire. Chrisian Vecchero to 60. Chase the Louder. Blaze Jordan, ooh. Kumar and Red Sapphire. First bowman, Roman Anthony, 8 of 10. Nice. First bowman, Roman. Very nice. Red Sapphire. Nice Red Sox color match. He's starting to get some momentum, too, and stuff. We'll mag that one for you. There's William Lugo, Daniel Montesino, Max Wagner, Kyle Harrison, and Jafri Solano. Luis Garcia, Junior Garcia, and Purple Sapphire. Tamar Johnson, Otto, 2 of 10. There you go, Chris. Nice, Tamar. Not his first bowman, but good prospect, Leandro Arias. As we only have five boxes in queue after this. Martín Gonzalez, Jet Williams, James Wood, and Manuel Beltre. And PG. Gabriel Gonzalez, Jacob Berry, and Daniel Guillarté. Brock Jones, Jorge Burgos, and first bowman, Purple Sapphire, Otto to 10. Jace Avina, another Purple Otto, Jordan Lawler. Nelson Rada, Abarth Julian, Abel Bostetus, and Gavin Cross. Drew Jones, William Bergoglia, and this is Green Sapphire, Oscar Colas to 60. Yasir Mercedes, Tamar's on base percentage is nice this year. 414, he's only hitting 236, but 414 OBP. Jackson Holiday, Roderick Arias, and Joshua Baez. That's Purple Sapphire to 25. Braylon Bishop, Luis Rodriguez, Samuel Zavala, and Neurilian Sedeño, Aqua Sapphire to 50. Dion Frias, Colby Thomas, Brevillean Cronacion, and Everson Artega. Alright, one more box. We're going to recap the autos and numbered parallels on this one. So Montgomery, Tamar Johnson, sorry, Jackson Churio, and Xavier Isaac. Zach Galoff, Jason Dominguez, and Alex Ramirez. Orange Sapphire to 50. Nice Metz color match. Ryan Acunha, Jake Zedifuipo, Acame Nero, to 25 or better. He'll do the chicken dance behind me while I continue to break. Michelle DeSone, Jason Churio, and Manuel Beltre. Justin Henry Molloy, Drew Gilbert, Jonathan Madea, and Dion Jorge. Justin Crawford, Jorge Ruiz, and Daniel Susak. That is First Bowman Purple Sapphire to 25. Serda from Martinez, Max Muncie, and Marcus Lee Sang, what do you do? Marcus Lee Sang. He'll see you do when you're taking a lead off the first. Robert Perez, Andres Mesa, Lionel James, Brooks Lee, and Juan Alonso. All right, last pack. Let's finish strong. Good luck, Chris. Junior Caminero. Nice. Daniel Susak and Jorge Ruiz, First Bowman Sapphire Auto. Angel Ganal on the back. All right. Recap here. Grab your boxes. The link to personal boxes is in the... It's pinned to the top of the chat there. All right. Noah's in for a box of NT football. So six boxes in queue. I'm going to pull a shield. Yeah. Aqua Sapphire to 99. Matt Olson, Marcus Simeon, Madea Machado, First Bowman, Orange Sapphire to 75. Jose Rodriguez, Peter Alonso, Juan Yepez, Rookie, Green Sapphire to 60. Krythian Vicaro, Oscar Colas, Aqua Sapphire to 55. Marcus Lee Sang, Andres Sedeño, Yellow Sapphire to 50. Leovar Pagaro, Jazz Chisholm, Nicoledolo Rookie, CJ Abrams Rookie Variation, Purple Sapphire to 25. Joshua Valles, Daniel Seussac, Daniel, Daniel Seussac, Daniel. Otto's, we had Jorge Ruiz, Purple to 10, Tirmard Johnson, and Purple to 10, Jace Avina. We had a rookie photo variation, Julio Rodriguez, First Bowman, Gold Sapphire to 50. Drew Jones, Andred Sapphire to 10, Roman Anthony. Good stuff. That'll do it for your break, Chris. Appreciate it. We'll get these right out to you.


So I have a question so these so I don't really so you know how like all these artists have like debut studio albums and whatnot no like since everything is like very but independent do it on your own type of stuff now how do you how do I know when to put out these stories in a sense like I don't want these stories to go to waste right exactly so that starts off man honestly either you can put out a project that's not heavy on the story or you can just put out singles until you get enough of a fan base where it makes sense to put out the story okay so in my Spotify like about bio it would actually talk about like like the struggle and whatnot but like all the singles I drop would just be like the instances and stories of like and the feelings and whatnot during those moments I guess no you don't even have you don't even have to go straight into explaining that or you could start just do some music just have good music and connect with those people through a few good songs and then bam right give the full-on story they like you for some songs and then you give the full-on story that way you have a little bit of an audience coming in and you give them something to really connect to you with and then on the back end now you're at a point where you're you're actually going to push this project heavily and then you have the people who introduced to who are introduced to you for the first time through the actual project does that make sense yeah um so I guess like one of the so what I really don't like so I have a hard time like what do you call it weighing like artists against artists if that kind of makes sense because I know everything's based on like how many fans you have that's kind of like how much you sell that's kind of like how big you will become especially like around the beginning like how do I know if I'm like um like let's say I'd release a couple songs how do I know if I'm like at this stage of like the process or like this stage where I could start like giving more like like worthy posts in a sense like content worthy like that are like quote unquote juicier right that'll uh get like better interaction then because I don't want to make it too early or like too late in a sense right or like if I release too much like standard like music in the beginning before going to the story would I risk like collecting a bunch of fans who just like me for the sound and not like for the story well you want people to like you for the sound okay but it's it's kind of like just like a given fact type of thing that people will get deterred if I switch to the story because why would the story be a completely different sound I mean the story is not a different sound per say like I'm singing on all of them it's just that I it's um it's I guess the lyrics are different in the sense that the lyrics are a little bit more like simpy and like the ones where I'm talking about like the real stuff compared to like the uh other ones where it's just more like surface level in a sense right so would that not throw off like a fan that might throw off somebody but that's the attrition right um retention is always gonna be a part of everybody's growth right like and then the lack thereof is the part of everybody's growth as well like no matter what there's gonna be that turnover that that turnover so just look at it that way some people will like you for all sides of you just like some people this side they only like when Drake raps people love when Drake sings right like and then some people love both it's you're gonna have those sides to you it's just more important that you understand the sides to yourself and then understand how to package each side when that time comes okay but don't like say oh well they're gonna like this song and then they're not gonna like that song you're you can't like in that case you're gonna start splitting yourself up and and it's too much okay so I gotta make sure they become a fan of me rather than the music in a sense overall that's the goal that's goal right okay


This paper compares two different approaches to solving a bus route scheduling problem. One approach uses a multi-agent system while the other uses a traditional mixed integer linear programming, MILP, model. The authors tested both methods on a small network and then extended their comparison to real data from the Maltese Islands. They found that the multi-agent system was more efficient than the MILP model when dealing with larger networks. This article was authored by Sadi Sharma, Somesh Bhattacharya, Deep Kiran and others.


Check it out, folks. As I promised, listen, I haven't forgotten all of y'all, especially my over-the-road truckers, right? Listen, today I'm gonna show you guys just how easy and simple it is to make a crock pot, you know, pot roast. Okay, so look, just for the record, I've already cleaned, washed, you know, my potatoes and my carrots, right? I got myself a peeler right here. I'm gonna go ahead and peel these carrots. Then I'm gonna show you how to cut them. But I think the first thing we're gonna do is we're gonna start with the star, right?  Now I don't know if I said earlier, but this is a four pound, you know, pot roast anywhere between three to four pounds would be great.  I can actually do it all in that size bowl right there, which I think I am, because listen, like I say, I'm the one to do the dishes. So I'm gonna set this off to the side. Get yourself a whisk. We're gonna put a couple of teaspoons of this brown sugar in there. Right, it's okay. Number one question you guys gonna ask is like, man, is that gonna be sweet? Trust me, folks, it's not. And then if it's a little bit over, it's okay. You just want a little bit of balance with this, right? Get your whisk. All right, real simple, right? All we're gonna do is, you got it. It's no need for me to, you know, use some kind of words like, all we're gonna do, this stuff right here be self-explanatory, right? I just like to get this on here, let it sit on here, get it all in all of the crevices, right? Okay, so now would be a great time before we put the flour on. We're gonna use, like obviously I'm using my cast iron, I'm putting it on medium heat, right? I'm finna add a little bit of this infused olive oil. Now we're getting ready to come with that flour, right? I just put a little bit on here and I'll just give it a little pat. This is gonna help with the browning too. All right, so I'm looking over here. Let me get you guys over here to just cast iron. If you look at the cast iron, I don't know if you can see them little ripples in there, but now I'm getting ready to drop just down on the bottom. Now don't forget, we just want a brown to put some flavor on there, right? And seal it up. We don't wanna go ahead and cook it. Okay, folks, so just after about three or four minutes, you know what I mean? You wanna look at the bottom, look at that right there. That's it. But don't forget I got a fire underneath the bottom of this, so it's gonna be a little bit on the, how could I say it? You know what I mean? This is where the heat is concentrated. You know what I mean? So you just wanna make sure that it doesn't, you know, it'll burn. Okay, so after you brown on all your sides, you don't have to like brown it completely, you know, on the sides, right? Cause it, just trust me, the browning that you put on these two flat sides, that's gonna bring a lot of flavor to it. So listen, I just cut everything off. We just go ahead and let this sit here and let it rest just a little bit. No worries, folks. There's so much inside of that. When we put it in that crack pot, it's gonna render out something really, really nice. All right, folks, so look, any of the fine that's left over or anything like that, I take out the bigger chunks. You know what I mean? That's up to you guys, but for the video purposes, I did, but as you can see, look, I still left it in like this, right? So I got a medium flame underneath the bottom. I'm getting ready to just start adding this in here. Now, when I say gravy, you guys are start thinking like, where's the roux? You know, how come he not putting no flour in there? We getting our taste together first, right? Then you see a little bit of the fat that came off of the roast. You see it on top? You see the bits? Uh-huh. It looked like this is the start to a great gravy, right? But after about five or six hours, and then we thicken it up a little bit, you guys know the rest. Now we're getting ready to add just a little bit of this soy, soy sauce. Now look at that right there. That's that 33% less soy. I mean, salt, right? Just want to put about a teaspoon in here. That's all you want. We just want a little bit of that flavor. You know what I mean? When you see the soy, you're probably thinking like, what's happening? This is when I tell you guys, trust the process. You know why? Because it's the combination of all of the flavors together that makes something amazing. Now, while this right here is, you don't mix them together. Look, we're going to add some extreme flavor, right? So this is that better than bouillon. Look, this is that beef version, right? So just go ahead and get yourself about a teaspoon. That might be a little bit more, but who's going to say, you know, that's too much, especially when it comes to flavor. We don't need to do nothing with it. We don't need to taste it or nothing like that. Just trust this combination of flavors right here is it, right? So now I'm going to turn this off. This is my crock pot. I'm going to go ahead and just pour this inside of there right now, right? It's the reason why I didn't put that, you know, I didn't put my pot roast in because I don't want it to get over the top, wash nothing off, right? So we just start like this. Now we bring our roast, right? And we just go ahead and set this in there, right? And if you guys pay attention, look at that. See how it comes around. This is what helps with it to start cooking it, right? Now we're going to work on the veggies. Now those are real cool and real simple, right? Don't forget, I've already washed, cleaned and did all of that, right? So now it's just a matter of me taking this and just, you know, skinning these down, cut them up. Then I'm going to show you the size that I cut them in. Then how are we going to arrange them? Then we just set the timer. Super simple. All right, so look, I just pulled out a couple of sprigs of rosemary and thyme. Because when you say pot roast, I love to have these flavors in there too, right? So I'm just going to put this like this. I'm going to let the crock pot do the work. And I'm going to let that, you know, like, just push this down. You'll see, you know, it'll melt, release its juices on top, and then it gets down into the flavor. But that's how I do it. Now we're going to put our top on, right? Now they got a sand, right? I always tell everybody, especially when you cook them with a crock pot or you outside on like a charcoal grill. If you looking, you ain't cooking. This whole design for a crock pot is for this top to be on. And that's part of how the process works, right? So every time you take this off and you look down there, add 30 minutes on to it for it to build back to, you know, the heat that it needs. Now with that being said, what should I say now that we all educated? Let me go ahead and say it. All right, folks, so look. Now we just hit power, right? I'm going to go ahead and hit high because I want to do it in six hours, right? Now a four pound go, I like to do six, right? I could have went five, but I know just from experience that this is going to be what I need, right? So we'll just put this on six hours. Like that we hit start. And I'm not going to take that lid off. No more, I'm going to let it cook. I'll see y'all in six. Okay, folks, after six hours, look, I already started like taking out some of my, you know, my veggies, right? So I just want to show you guys these are soft. That's why I'm using a set of tongs. You know what I mean? I'm picking them up, you know, lightly, right? You don't want to like turn them in the musk, but you see they hold the integrity. Just put them in a bowl or wherever you'd like to put them on. If you got a serving platter, you can put them in there also. So let me get these out and I'll show you what we do next. Here's my roast. Remember, we put that color on there. This is nice. It's nice and tender. Don't forget, we got to like cook, you know, when you do chuck or anything like that, you got to like put some time under it. You got to get that heat in there to get it, you know, give it some time so it'll like loosen up their muscles so it'll be chewable, you know what I mean? And then right here, you can see these potatoes and these carrots. Ooh, I could have put celery in there. You guys can just level up however you would like to level up, right? So now, I don't have anything left, but a great, I'm gonna just call that the aizhuda. We're getting ready to turn that into a major, major, you know, gravy, right? So I'll just take it. I'm just gonna add it to it right now. Now, don't forget, this is equal parts. You know, cornstarch and, you know, cold water, right? So that's three and three. Now I'll just go ahead and add it. And I'm gonna start whisking. I want to continue with my heat because this is what's gonna thicken it up, right? Take this, put that in there like that. Just open them up a little bit. Might go ahead and get myself one more piece. But when you do it right, it's been in that crock pot the right amount of time. Right? Check it out. Let me just go ahead and get this out also. We don't want to eat it. All right, now check this out. Look, come in here and get in here close. Look at the way that gravy just worked. Oh my goodness. Hey, when your veggies is nice and soft and cause I cut mine big, you know what I mean? I did it like that cause we was going a long time, right? So when they big like that, I can't just get potato and that without cutting that potato. But I feel like I'm over talking folks. Check this out. Cheers y'all. What you want me to do? Ball us up and drop this napkin. This right here is fire. You can even see it on the top. When you get your gravy consistency like that, that's all I can say. Now don't forget, you want to taste it after that. You want to add any salt, pepper to it. I got mine just the way I like it. It's really, really good this way. And just for those of you guys, you can, I want you to let me know down in the comment section below what else would you add to it? Sometime I like to add when I'm doing the crock pot version, I like to go ahead and add them frozen peas to it like the last 30 minutes. Outside of that, you guys let me know. Don't forget, this full printable recipe is on my website, smokingandgrillingwithab.com. Now with that being said, listen, I'm bringing back that crock pot series it's that time of the year. So guess what folks, if you're new to my channel, don't forget to like, subscribe, and tell everybody out there, I'm your guy. And with that being said, I'm out.


The melting point of a substance is a characteristic property of the substance. Metals melt over a very wide range. Metals like copper melted about 1,000 to 1,100 degrees Celsius. What we have is an alloy of bismuth tin and lead. It has a low melting point. In fact, it melts below the boiling point of water. I've got a spoon made out of the alloy. I'm going to put my spoon into the boiling water.


With your look around the Air Force, I'm technical sergeant Chandration Mitchell. Acting Secretary of the Air Force, John Raugh, told a congressional subcommittee that the Air Force's vision is to use the fiscal year 2022 budget to focus on capabilities needed to win in the long-term strategic competition with China and Russia, devoting resources to a defense that will meet future conflict. In line with Secretary Austin's priorities to defend the nation, take care of our people and succeed through teamwork, our fiscal year 2022 budget is the beginning of a journey to the air and space forces of 2030. It builds capabilities that allow the department to modernize while continuing to meet national security objectives and defend the high ground. For the first time, an autonomous unmanned aircraft flew on a test range, demonstrating what one official called an early version of the brain of the Skyborg system. The Skyborg Vanguard program is working to integrate full mission autonomy using low-cost unmanned air vehicles that can perform missions on their own or teamed with manned crews. The flight test of the Skyborg Autonomy Course System, or ACS, was the first step to integrating these aircraft into a complex operational environment. During the test, the ACS was put through its paces in basic aviation capabilities, responding to navigational commands and demonstrating coordinated maneuvering. It also stayed within defined areas for flight. Deploying to a bare-base environment and setting up everything needed to project combat power quickly was the focus of the Air Mobility Command's 19th Airlift Wing and Exercise Rock Guide 2102. Putting the lead-wing concept into action was a first for the command. The concept brings units together from their home bases with the skills to quickly establish a new main operating base in a deployed environment. And that's your look around the Air Force.


triadic interactions are higher-order interactions relevant to many real complex systems. The authors develop a percolation theory for networks with triadic interactions and identify basic mechanisms for observing dynamical changes of the giant component such as the ones occurring in neuronal and climate networks. This article was authored by Hanlin Sun, Filippo Radicchi, Eugen Kofes, and others.