All righty, welcome back to operating system. So where we left off last time Which was yesterday we implemented a lock and it was crap didn't work So today we get to fix it So as an aside in some courses you can actually implement locks with minimal hardware So your hardware requirements can be as low as loads and stores are atomic and your CPU executes instructions in order and Some courses they'll let they'll walk you through Peterson's algorithm or lampards bakery algorithm Basically, this tries to simulate, you know taking a number and then they call numbers in order and that's the order you get Served it's kind of like a lock problem is that these are all computer Sciencey and they don't scale very well in the real world. No one actually uses this as a Proper lock implementation, so I will show you the proper way. We actually implement locks in today's day and age So let's assume we have this magical atomic function It is called compare and swap and again atomic means it either happens all at once or it doesn't happen There's no in-between so this magical Atomics function takes an address to a pointer and then two values an old value and new value and what it will do is it will try and Read the current value if it matches Whatever this old parameter is it will change that value to be new and it will do that Atomically and this compare and swap oops will always return the original value at that address so you're guaranteed if I use it like this if I do a compare and swap and Use the pointer to that integer and then give it the old value as 0 and the new value as 1 Well, this function will only return 0 if it if it successfully changed the 0 to a 1 Otherwise if the current value is 1 it will just return 1 So this way we can implement a lock So if the initial value is 0 if one thread calls lock Well, it would do a compare and swap on that Its current value is 0 So it would change the 0 to a 1 Atomically and then return 0 since it returns 0. Well while 0 that is other words for false So it would fall out of this while loop and continue so that one thread would make it through that lock call Now if another thread tries to call lock well the current value of that L is currently 1 So compare and swap will return 1 so 1 is otherwise true So this while loop will just keep on going over and over again And this way we only allow one thread to make it past lock at any one given time assuming that this Compare and swap function is atomic So everyone agree with that So this is an implementation of a lock. It works only one thread can make it past lock that lock function at any given time Yeah, this works. So This is now safe Right, so it works as a lock only one thread makes it through at a time but it still has that problem while if we only have one core on our machine and Another thread has locked so the current value is 1 well The other thread is just going to execute this while loop over and over and over and over again And it's not going to make any progress. So we're just wasting some time So this is a proper implementation of a lock. It just has that problem where it has that busy weight So that lock is a valid implementation And it's given a special name because it's actually kind of useful it it's called a spin lock Why is it called a spin lock? Well, they call it that because of that while loop that constantly keeps on retrying it over and over again and This compare and swap function that I used here That is the atomic instruction that supported on all your CPUs on x86 They happen to call it comp exchange or Why I don't know they want to shorten it for some reason. What's it supposed to stand for well It's supposed to stand for compare and exchange compare and exchange compare and swap mean the same thing So again, this is an implementation of a lock it works, but still has that busy weight problem So again like if you have a unit processor system So a system with only a single core on it If you can't get the lock you should be smart enough to realize that while you shouldn't retry or anything Just yield put yourself to the back of the queue. Let the kernel schedule another process or another thread Hopefully that one calls unlock and then you can proceed so if you have however, have a Machine with multiple cores on it you might actually want to use a spin lock because every time you read While some other thread because it could have executed in parallel might actually Unlock that mutex so it might be worthwhile to just try again Depending because as we'll see the implementation of a mutex is much more complicated than this This is essentially one line for lock one line for unlock. That's it. Can't really get much simpler than that So any questions? Nope, we're good. We got a lock. It is a spin lock. All right so Here is what would happen if we tried to make it a bit more efficient. So We will change that while loop to do wall compare and swap So if compare and swap returns one that means some other thread has the lock So we should just yield So if we do this well now we have a new issue and it is something called a thundering herd because You might be in a situation where one thread has a lock then eight threads are trying to acquire that lock and Essentially all those eight threads will just fight for each other as soon as you unlock that so That's kind of a waste of time So if you have eight threads all fighting for the same lock and it's a mutually exclusive lock You know that only one thread is going to be able to get it any way So why would you let all eight threads fight for it? Only one thread should try. Yep Yeah, so the problem is Exactly exactly that so if I have eight threads well, they all yield and they'll come back. So say another thread unlocks this So we have eight threads that are yielding What one thread unlocks a lock and then all eight threads are going to check So the first one is going to acquire the lock and then pass But all the other threads are just going to check again Seven of them are going to fail and you already know seven of them are going to fail your wasting time Waking them up and having them yield again, right? Yeah, so say you have 10,000 threads Yeah, so if I have 10,000 threads, I don't want Like if I unlock it, I only know one of those 10,000 is going to get the lock. I don't want all 9999 of them to just try again. They're gonna fail. They'll get a yield again. Why bother? So we want to fix that problem so The other problem with the thundering herd is well They'll all try again and you're not guaranteed which one of those threads is actually going to acquire that lock So if eight threads were waiting for that lock Well, all eight of those threads should be able to acquire a lock before some new thread tries to acquire a lock You want to be fair maybe form an orderly line so you can reason about it So that's why we say FIFO is okay. That's just first in first out. That's a normal cue That's you know going to McDonald's or something like that So here is our solution. So instead of that We can if we fail to acquire the lock will add some pseudo code here We'll just add ourselves to a weight cue for this specific lock And then we will put ourselves to sleep sleep is a bit different than yield So sleep will just block this thread from executing until another thread calls wake up and wakes it back up again So it will block until another thread wakes it up Assume this is you. I don't know during finals week. You go to sleep. Someone needs to wake you up So probably a bad example, but anyways, so in the unlock How we change that is while we change the value from a one to a zero and then we could check If there is a thread in the weight cue so say there's 10,000 we just wake up whatever is at the beginning. That's it so This is a good try But there's two issues from this because well, there's probably some data races here So there are two issues and we should be able to argue about them one is lost wake up so that means is there a situation where One thread has the lock already and another thread tries to acquire it Is there a situation where it will just put itself to sleep and then it won't get woken up again So essentially it will be in a coma. Let's say so just goes to sleep Nothing ever wakes it up. Is that a possible situation and another situation that might happen is Creatively named the wrong thread gets a lock, which means is it possible that there is a thread waiting for a lock and It should be next in line But is it possible that another thread can acquire that lock before the thread that's patiently waiting gets it so let's think of this and then see if you can come up with a Order of threads executing on a single core So just by context switching just by having concurrency Is there a situation where I will have a lost wake up or some other thread will steal a lock from a thread that is currently in the waiting queue and If we can come up with a situation that means that our implementation is incorrect No matter how unlikely those context switches may be if it is at least feasibly possible It means that your program has an error in it Even if you run it 10,000 times and it seems to work. Well, you're not guaranteed it will always work. Yep If you keep getting like No, so if a thread So say thread one has a lock and thread two tries to call lock It will check the value the value will be one So it will go into the while loop and then it adds itself to the queue and then puts itself to sleep Yeah, so unless something wakes it up No, unless something wakes it up. So sleep just blocks until someone wakes you up Yep set L to the first thing in the queue So if I want to hand the lock to the next thread, I would Need to change my implementation of it. Keep that in mind because we'll do that for a better implementation But given how it's written out, is there a situation where I will get, you know, the lost wake up or the wrong thread kind of butts ahead So here let us go there. So say we have thread one that has a lock So the lock is currently one. So you said thread one starts executing and Changes the lock from a One to a zero Okay You can contact switch so we could So right now thread two is just calling lock. It's not blocked at all So in this situation, well if thread two starts executing now Well, it would call compare and swap The current value is zero So it would change it from zero to one and then it passes. So it makes it through a lock, which is fine So that that seems to work. That's not a problem. So let's reset this Nope, so thread two is just calling lock. It's not in the queue yet. Okay, so let's first think about this lost wake-up So is it possible? So if thread one has the lock and it's calling unlock and thread two is calling lock is it possible that thread two will put itself to sleep and Thread one will never call wake up on it. Yep. So Here we'll just assume concurrency so nothing happens at the same time either thread two executes or thread one executes So which one do you want to run first? Doesn't work. Yeah Yeah, so to explain that again, let's see so first initially we could have thread two executes if Thread two executes while currently thread one has a lock the value of it is one So thread two would execute compare and swap What it would it return? So it always returns the value pointed to it So it would turn one because it didn't change it from a zero to a one because thread one has the lock So it would go into the while loop So at this point we could contact switch. So now we could contact switch back over to thread one thread one can set the value from one back to zero and Then if thread one continues executing it will check. Is there any threads in the weight queue? Is there currently any threads in the weight queue? No, so I'm done my job here. It's done. So thread two just finishes the unlock Now if I come back to thread two Well, now it would add itself to the weight queue. So now it's part of the weight queue now It puts itself to sleep Yeah Yeah, so compare when thread two calls compare and swap because Here we said that thread one has the lock the current value of the lock is one and thread one changed it So it should not be able to acquire it until thread one calls unlock All right. Yep When does what so thread two? Got into the weight queue in this situation Right after thread one finished unlocking it So here we can back up again. So in this situation If we reset everything again We're essentially in a situation where thread two executed first It called compare and swap it failed because thread one has the lock. So it would Want to start executing inside the while loop now we could contact switch before it adds itself to the queue So we contact switch back over to thread one it unlocks the lock it would check the queue there's nothing in it because thread two was about to add itself to the queue, but we contact switched away from it because unlucky for him and Then we finished and then if we come back to thread two thread two will just resume So we'll add itself to the queue put itself to sleep and there's no one to wake it up It's going to miss its final exam and fail the course Which our final exam is 9 30 if you haven't seen that yet. So yay Yeah, it's scheduled for December 8th at 9 30 9 30 a.m. Yeah, so I will be up at like 4 a.m. That day. Yay Yep So you yeah, you can't make oh like the whole body of the while loop So yeah, I guess I could solve it if I made the whole thing like I'd have to make that whole function atomic that whole lock atomic Right, so if I just like put a mutex around this I still have that problem because it could not acquire the mutex until Right, so I still have a slight issue right What about this situation where the wrong thread gets the lock? So Let's change our scenario a little bit So we can start off where thread one Has lock it's calling unlock. So if it starts executing it would start executing here Let's assume thread two is in the So thread two is in the weight queue It should be the next thread that gets the lock as soon as thread one unlocks it, right? So let's assume we have a thread three calls Lock so Is there an ordering by just switching between these threads such that Thread three will acquire the lock before thread two gets it. We all agree with that that one ended fast so Let's go over that real quick if you didn't hear it. So what we could do is initially Thread one has the lock. So the value of it is one We could start executing thread one So thread one could change the value of the lock from a one to a zero and Then we could get unlucky and then context switch immediately to thread three In which case if we context switch now immediately to thread three, well, it will do this compare and swap What's the value of the lock? Zero so it will change so compare and swap will change the value from a zero to a one To indicate that this thread has the lock. So thread three now has a lock So it has the lock if threat if for some reason if thread at this point thread one continued executing Well, it would check the queue. Oh, there's a thread in the queue. Okay, great I will wake up thread two and then I will finish So when thread two wakes up It would resume right after the sleep So it would go back to the while loop and then try this compare and swap again and then oh, no the value is already one because Thread three came in swoop my lock damn thread three So it would see that the value is now one Then add itself back to the weight queue sad day and then put itself back to sleep again So we so everyone agree that that is also an issue thread Three butted ahead in line thread two was patiently waiting there in the weight queue like a good thread I don't know why I'm persona-fying a thread But anyways, it was waiting there thread three came in butted ahead Just rude so any questions with that So let us solve these issues So in the slides there's an example for lost wake up Which is what we went over and then also an example for the wrong thread getting the lab Although or thread although I swift swap the names of thread one and thread two Doesn't matter as long as you are consistent So here is our fix and it looks ugly looking at this just looks like a Big block of code, but there is a trick to reading this So let's go here So the trick to reading this is well before in our first attempt at doing this We essentially had a lock so the value we were using as our mutex and We also were maintaining a queue. So the new thing here is this guard So this guard we are going to use that as a spin lock. So remember Way back here At the beginning we said that this was a valid implementation of a lock. It just kind of Spun it would try over and over again, but this worked to ensure mutual exclusion So if we switch back to the big ugly thing Well, this guard we are using as a spin lock and we will only use that spin lock within this lock and unlock So this big ugly thing Well, if we wanted to rewrite that as something that's more manageable This is essentially a lock of guard Then if we went through if we set guard to zero Well, that's essentially the same thing as an unlock To guard So remember everything between the lock and the unlock That's the critical section only one thread can do that at a time And we have an if branch here We want to make sure that whenever we lock it lock the spin lock we eventually unlock it That's why we have an unlock in each of the branches of this if statement Now if I go back and read this unlock well, the first thing it does as well is It will try to lock the guard and then at the end This line is the same as unlocking the guard So that this is kind of like your idea where I should make the body of that while Atomic essentially right So let's see if we fixed this lost wake-up example So lost wake-up what happened was well while thread one was trying to unlock the mutex It was done halfway and then thread two woke up or sorry. We context switch to thread two After it read it knew that it was already locked and that's how we got into that bad situation So now in this case We would have thread one and thread two One of those goes first and because the first thing it does is lock the guard as soon as one of them goes through The other you can't context switch to the other thread. I mean you can but it's not going to pass the lock So what would happen? Well thread one could start executing it could lock the guard So it could acquire the spin lock then it would check If there's anything on the queue if the queue is empty All I would do is change the lock. So the lock is our original value It would just set it to zero So it would change it from a one to a zero and then just finish Otherwise if the queue is not empty, this is your idea here. So that was a good idea I will just transfer the mutex to the next thread So all I have to do is just wake up the next thread if I don't have any data racers or anything the value of the lock is still One and I just woke it up. So it's going to resume somewhere It's going to resume after it fell asleep and just finish. It's going to immediately finish the lock so Thread one will eventually unlock that guard or unlock that spin lock and then thread two can execute So in this case, it could acquire the guard. It would check the value of the lock You'll notice here. We don't need compare and swap because well if we have a spin lock We don't have any data racers because only one thread can be doing this at a time So we don't need compare and swap anymore So we could check the value of the lock if it's zero well We change it to one because we now have acquired it then we can just unlock the guard and then We finish the lock call and keep on going otherwise Well, we could add ourselves to the weight queue if we Were if the current value of the lock is one Add ourselves to the weight queue and then unlock the guard and then put ourselves to sleep and Then if threat if we put ourselves to sleep then if thread one tried to execute After we put ourselves to sleep and put ourselves on the queue. Well, it could get the guard check the queue then Well, there's something in the queue. So it would go into this else Then it should just wake up thread two and then it should be able to resume with the lock So is there any issues with this or does this work? Data races are like a fun puzzle. You get to solve every time you program now Yeah, so a guard is a spin lock to ensure that Essentially to ensure that our lock and unlock functions Have mutual exclusion. So only one of them will execute at a given time Because our problem before was we started executing it We got like halfway through it then we swapped to another thread and that's where our issues came from So the idea is yeah, we use a lock so we can implement our lock. So we Get rid of data races while we're implementing our lock. Yeah Yeah, so this Lock so it should solve the thundering herd problem So whenever you unlock only one thread tries to wake up and acquire it And it should also solve the problem that we saw before was it should also solve lost wake up so that shouldn't happen anymore and The wrong thread getting the lock also should not happen anymore.  So spin locks don't guarantee that spin locks also have the thundering herd problem but Depends on your application if your critical section is really really small a spin lock might be fine But if your critical section is really big well if you have a spin lock It's gonna waste a lot of time just retrying over and over again So you might not want to use that in which case this would be way more efficient again situation if there's like a Thousand threads all sharing this one lock and all trying to lock it at the same time This is going to be a lot better because well, it's only gonna wake up one thread at a time The rest are just gonna go to sleep block. They can't execute. Yeah So you won't have a thundering herd at the guard each thread. So say one thread has the lock Then ten thousand come in to try and acquire it those ten thousand threads are all going to put themselves on the queue And then go to sleep Yeah, but if another thread tries to call lock while another one is in the middle of it It has to wait right just happens serially. So we don't have any data races But yeah, there's a lot of threads trying to call lock at the same time But the code in here doesn't do that much adding yourself to a queue. That's a few memory writes And that's it. We're just Doing a few memory writes. That's it That's probably a lot better than just having ten thousand threads each trying to read read that value over and over and over again Then just doing like a few memory writes once Yeah, so spin locks are totally appropriate if your critical section is very small So you might even want to use spin locks sometimes like the answer is it depends So sometimes spin locks might be better if your critical section small Sometimes mutexes might be better if your critical section is bigger Also depends on how many threads are trying to acquire it. So there's lots of trade-offs. That's why we have different different implementations All right, so is there a problem with this implementation a subtle one and I will give you a hint What is happening to the garden unlock? What do you mean? So after thread wake-up is done, it would just execute the next line and set it to zero If it continued, yeah wake up just unlocks that thread doesn't context switch. I Mean you may context switch, but if you context switch to it, I mean it just gets the lock That's it. It would just resume. It doesn't unlock it or anything Yeah No, so it's subtle and the hint is the arrows where the threads are currently at pretty much demonstrate it Yeah Yeah, so I could context switch. So let's say thread two thread one has the lock and thread two goes ahead and tries to get it while It would get the guard Put itself on the queue and then unlock and then it could context switch right now before it puts itself to sleep And then thread one could start executing right before it puts itself to sleep It would do compare it would get the guard and then check the queue Oh, there's something in the queue and then it would try and wake up thread two, which is currently not asleep So this is a very subtle data race, but it's also not that big of an issue because Well, you didn't have a data race with the queue. So thread one If you're a thread one right now, you actually know thread two the next thing it's going to do is put itself to sleep So if you wanted to fix this If you just detect that. Whoa, I'm trying to wake up a thread. That's not asleep yet All you have to do is just retry it until it eventually puts itself to sleep because you know It's going to so I only omitted that from the slide just because it makes it way uglier than it currently is but this actually has a very subtle issue, but You could detect it. So if you try and wake it up and it's not asleep yet Just yield and wait for it to go to sleep and then you can successfully wake it up Or if you're implementing this thread library yourself, you could go ahead You could cancel the next sleep of it or do whatever mechanism you want But you know what the next thread is going to do so if you wanted to In your lab four, I don't make you write thread sleep and thread wake up But if you really want to I took it out. But if you really want to you can So feel free to implement that yourself so last thing So remember What causes data race? So this is going back to that discussion of oh, should I use a spin lock? Should I use a mutex? Again, there's a series of trade-offs. So going on with that series of trade-offs remember the definition of a data race So two concurrent accesses to the same variable And at least one of them is a write which implies that we can have as many readers as we want and we don't have any data race so You wouldn't even if you only read You only you don't even need a mutex only reading is fine value doesn't change Nice and safe So you may be in the situation where you write an application You want to prevent data races But writes are fairly infrequent and you have a lot of threads trying to read so ideally You would want You know, there's eight threads You want all them to read in parallel all at the same time because that's safe And then as soon as one tries to write you want to prevent any of the other ones from writing If they're infrequent, that's pretty good Otherwise if you had that scenario right now all you have in your arsenal is a spin lock or a mutex In that situation Well, no matter if a thread is reading or writing only one thread can execute at any given time Probably really bad for performance so There is another type of lock called a read write lock. So This a lot. This is a special type of lock that has two As it kind of implies it has two types of locking calls There is a lock for writing and then a lock for reading And the difference between them is if you acquire the lock for writing You should be the only thread that has that lock and there should be no other threads trying to read that variable because again We don't want any data races The other side is well if a thread has the lock for reading While other threads should be able to acquire that lock for reading. They should be able to execute Concurrently or in parallel likely you only care about parallelism because of performance So ideally you want them all executing at the same time So this is how we would implement a read write lock So in our implementation for a read write lock We could keep track of the number of readers And we could just have a generic lock to represent our guard This could be a mutex or a spin lock. In this case, it's the same idea we had when we were implementing mutexes So we could just use a spin lock because we're only using it internally And then here is the lock that we're using to represent our mutual exclusion So it could just be something like a mutex So the easy implementation for it is Well in the write lock we want to guarantee that only one thread has the lock So we just use that mutex directly. So for a write lock Just lock the mutex and then for a write unlock Just unlock the mutex simple the more The harder situation is for the read call. So let's go through it So it would let's say it has a spin lock. So it acquires a spin lock called guard And the idea behind this guard is we want to prevent data races on this number of readers variable because we're going to keep track Essentially, we're going to keep track of how many threads are sharing the mutex for reading So we want to guarantee that there's no data races when we increment this Because we saw when we had that plus plus count example with multiple threads You don't the value can get inconsistent. We don't want data races So here we would increment the number of readers If initially we increment it from zero to a one It means we are the first thread that tried to acquire the lock for reading So we would just try to lock the mutex directly If we can lock the mutex directly We just unlock the guard because we're done modifying the number of readers and we can just continue Now if another thread tries to Tries to acquire the lock for reading It could acquire the guard Set the number of readers from one to two and then it wouldn't go in this if because they're all sharing that mutex And then it just unlocks the guard We could have any number of readers it could increment from two to four four to five Five to six do to do to do then eventually In the unlock what that will do is decrease Acquire the guard so we don't have any data races with the number of readers Decrement the number of readers because now this thread is not going to have that lock for reading Then it would check If it has decremented it from one to zero it means it's the last reader So it should give up the mutex And then it would give up the mutex and then unlock it. So this way If we had two threads that are called that have the lock open for reading While they are sharing that mutex if a writer comes along It's going to sit here at this lock call until eventually there are no more readers anymore And then the readers unlock that mutex and then the then we can have a single writer So any questions about that? Yeah, so it's kind of like I know if I gave you a key to a lecture hall or something like that It's like the rule the first person that comes in can use the key unlock it And then let as many people in as you want If you want that lecture room to be secure the rule is the last person that leaves like locks the door when they're done So it's the same kind of situation. So I'm essentially yeah, I have one mutex and either the readers One of the readers acquires it and then shares it with all the rest of them until no threads are reading anymore Or a single writer gets it But because I'm sharing that mutex between This I'm using the same mutex here Here and here between for the right Lock and the read lock. So I'll either have a bunch of readers or one writer And that's it Which is safe, right? So I can have as many threads reading as I want, but I should only have one thread writing Yeah, so if Say even one thread has the mutex like acquired the mutex as part of this read lock Well, if someone tries to call right lock, well, it will try and lock the mutex that The reader already has So it'll just sit there until it can acquire it eventually Yeah, yeah, so like that lock is just like a normal mutex. So it would just be blocked until eventually The reader reaches this and unlocks that mutex Yep Yeah, so there is a slight problem here because all the readers are essentially sharing that lock Well, if you have a lot of readers They might this might unlock might never happen right, so That is a problem for a realistic read write lock So this is just a simple implementation that has an issue The smart developers that actually implemented the proper read write lock has have thought of that so Ideally you would want it if you request the lock for reading No new readers or for writing Any new readers that come in should have to wait until you get it for writing Yeah, yeah in this case There is this lock it would be a mutex and it's shared between the readers and the writers Yeah guard could be a mutex in this case. It could also be a spin lock It's kind of small. So like it's only protecting an increment Which is pretty fast. So spin lock would probably be more appropriate But it could be a mutex if you really wanted it to be Yeah, well, so Sorry in a natural implementation, you can use a spin lock or mutex. They both have a lock So there's a p thread spin lock. There's a p thread mutex. There's also a p thread read write lock So luckily you don't have to implement that but this is basically the gist of it that gives you the idea So any questions about that? All right, we are good. So again Summaring up all this locking stuff. So We want to prevent data races. How do we prevent data races? Well, we put any code that might be susceptible to a data race in a critical section Such that only one thread can execute it at a time And we should know what data races to concurrent accesses to the same memory location With at least one of them being right So our mutex or spin locks are the most straightforward locks They only ensure one thread is in that critical section at any given time If we want to implement them ourselves So we had to implement a spin lock Then we use a spin lock to implement our mutex and then we could you know implement read write locks on top of mutexes and spin locks But to implement that spin lock you need some hardware support So we need that compare and swap instruction for You would need some if you're implementing a mutex You would need some kernel support for like wake-up notification for threads So you need to be able to put a thread to sleep and be able to wake it up So you would need to implement that so that's missing from your lab for but if you wanted to you could implement it and there's also The case that if we know we are reading a lot through multiple threads and writing infrequently Well, we should probably use something like a read write lock for performance because All the threads reading at once perfectly safe to do So just remember pulling for you. We're on this together


From theCUBE Studios in Palo Alto in Boston, bringing you data-driven insights from theCUBE and ETR. This is Breaking Analysis with Dave Vellante. In the words of famous people like Nobel Laureate Niels Bohr and baseball legend, Yogi Berra, predictions are very difficult, especially if they're about the future. Hello and welcome to this week's theCUBE Research Insights powered by ETR. In this special breaking analysis, we're pleased to host our third annual data predictions power panel with some of our collaborators in theCUBE, collective and members of the data gang. With us today are five of the top industry analysts focused on data platforms, Sanjeev Mohan of Sanjmo, Tony Baer of DB Insight, IDC's Carl Olson, Dave Meninger, who was with Ventana Research, now part of ISG and Doug Henschen with Constellation Research. Guys, thanks, we really appreciate you and we are very excited for our annual look ahead on data. Now, before we get into it, I want to briefly share some ETR data from an October survey of more than 1700 IT decision makers. This graphic shows a net score or spending momentum on the vertical axis and the overlap of these platforms within those 1700 accounts, representing the pervasiveness of the platform within the dataset. And this is data isolated for the analytics, business intelligence, database data warehouse and ML AI sectors. And we've selected a subset of the companies in this group of sectors that are representative vendors of today's discussion. Notice that red line at 40%. Anything above that indicates a highly elevated spending velocity on a platform. So a couple of quick points and then we'll get into it. First of all, the presence of Microsoft and AWS is impressive and notable well ahead of Google Cloud. The momentum of open AI at a net score of nearly 80% is astoundingly high. And its presence on the X axis represents about seven times the account penetration of Anthropic, which you see in the left hand side of the chart just above data IQ. Snowflake and Databricks remain above the 40% mark with pretty strong momentum. And you can see a number of other companies that we'll discuss directly or indirectly across this graphic in this basket of sectors that we've chosen, MongoDB, SAP, IBM, Watson, and then we've got governance metadata, pipeline and ETL tools like Informatica, Calibra, Alation, Altrix, et cetera. You got BI platforms like ThoughtSpot, Click, Tableau and Looker, and of course a number of database and data analytic platforms like CouchBase, Cloudera, SAS, and of course Oracle. So this gives you a general quantitative sense of the relative position of these platforms and what is a multi-hundred billion dollar TAM. Okay, let's get started by looking back at this team's 2023 predictions and looking at how the analysts fared. This graphic just shows all of the 2023 predictions for each analyst in one table. It's got a little commentary on evidence of whether the prediction was a direct hit, which is green, a glancing blow, which is yellow or a miss, which is the red. So a quick scan of the heat map shows that the data gang did pretty well in its 2023 predictions, notwithstanding that these were self-evaluated by each of our analysts. Okay, so let's get into the 2023 predictions review starting with Sanjeev Mohan. We're showing Sanjeev your prediction about unified metadata becoming the kingmaker and your expectation that data products would rise in popularity. And you're sharing evidence of Microsoft Fabric, Databricks Unity Catalog and some other proof points. Take it away and explain your logic and your assessment. Yeah, so when we came up with these predictions last year, this is before AI took off, my whole thesis was that data catalogs are going to become more powerful, they'll add more use cases and go far beyond just being catalogs. And at that time I was thinking data quality, security, privacy, some of those things. And then Unity Catalog came up and we see it has merged the AI model catalog, along with the data catalog, Microsoft Fabric I thought is a really great concept that brings together different disparate pieces of the architecture of the stack into one place. So this is how I see metadata is starting to converge for different use cases. The second prediction I had was on data products. I was so upbeat about data products that I ended up writing a book called Data Products for Dummies on that. I feel data products have now become mainstream. I have multiple conversations every week where people are now starting to create these data products. For example, I was at KubeCon countries a couple of months ago. I met with the Intuit team. They have 900 data products and I was told that the mandate for them is that in the future, all access to data is going to be through a data product. So I feel data products have become a common theme. In fact, the definition, the examples of data products have also increased. Last year at this time, like I said, AI was not in the picture, but now that we are so deep into the space, so think like rag pipelines, for instance. I'll be talking about agents, AI agents. A lot of these are actually data products. So you could do your LLM inference and have a whole mechanism and wrap it up into a data product. So that's why I rate both of these as green. Okay, great, thank you. Okay, next, we've got a Tony Bear. We're going to be rapid fire here. Tony, you predicted that the industry would begin to rethink the modern data stack and you've cited some evidence of that with a mix of green, yellow, and red. So appreciate the self-evaluation. Explain your 2023 prediction in more detail in your assessment of its accuracy, please. Yeah, thanks, Dave. Number one, the modern data stack was a whole idea to basically modularize all the different pieces that you need to go from transactional to analytic data. Great idea, except for the fact that in execution it resulted in a lot of complexity, a lot of anti-complexity. So if we're looking at how this prediction performed over the past year, I'd say a metaphor here, and I may be guilty of overusing this, would be like having one leg in a bucket of boiling water and one leg in a bucket of ice. On average, I guess it was middling. It was okay. Let me break this down into several areas. Some areas basically showed more progress than others. I think in the area of flattening the analytics and transaction data stack, we saw pretty impressive progress. And this was progress that was already ongoing when we made this prediction last year. For instance, basically Oracle rethinking my SQL group with heap when I wish to combine both an analytic and transaction database. The first time that my SQL actually had been applied towards analytics. And Google doing similar things with Postgres in LODB. I think what was really interesting this past year is seeing what Amazon's done. And what Amazon did, Amazon has, now I've lost, 15, 16 databases, whatever. It wasn't like all of a sudden that they were going back to database Pangea or anything like that. But they were now putting in more, what I call seamless connections. And they did it in a fairly ingenious way. They took advantage of the technology they used in Aurora, which is basically looking at logs and doing and replicating change logs. So that basically are their transaction database on Aurora, the performance would not be impacted instead it would generate a change stream, which would automatically feed to Redshift. And basically the first announcement was with MySQL, which went GA. What's impressive is that Amazon AWS expanded this now to Postgres. And even more interestingly, to the NoSQL side with DynamoDB and OpenSearch. And so that was actually very significant progress for basically a cloud provider hyposcale that really has been known more for its complexity in the past to start to find a look to put things together. Another area which I think was we're sort of very strong progress is in database machine learning, fast becoming table stakes, fast becoming a check box. It's been implemented in different ways. For instance, with Redshift, basically it's a matter of calling in models that you've developed in SageMaker. Whereas say for instance, with Oracle or Google BigQuery ML, it's a matter of dealing with canned machine learning models that are already in database. I think going forward in the future, I think there'll be a lot of very interesting progress in terms of how we can incorporate let's say foundation models in this as well. So I see very impressive progress there. We're essentially, it's not that you'll necessarily do all AI within in database, but for those use cases where you would like to compress the stacks, I think there will be so expanding array of alternatives there. Whereas say progress has been more halting has been in the area of basically of essentially data transformation and streaming. ELT has been a good, it's been an area of progress and which has been made possible in the cloud because of course storage is so cheap. So when I do the transformation in database and that eliminates a whole layer of a stack, that whole staging server. So that's been impressive, that's been going on, and that's become basically a standard part of the modern data stack in the cloud. On the other hand, the continued popularity of tools like five transfer transformation, indeed, I should say five transfer for extraction load and DBT for transformation. Point to the fact that there's still a tool that there still is a stack of tools here and there's some needed integrations. And I'm looking forward to basically how they become more seamlessly integrated into their most platforms. Finally, I would say where we've had the least progress I think is with streaming and building and managing data pipelines. I do think I'm going to hold out an array of hope which we'll go into in the predictions because I think generators of AI could make a contribution here in terms of simplifying and integrating data pipeline, generation and data pipeline management. Great, good tease there. Thank you Tony, good stuff. All right, moving right along, Carl Olson, you said that SQL is back and you're showing a sea of green in your evidence column. I gotta ask you, was SQL ever gone? Please explain your 2023 prediction and your proof points that led you to that direct hit evaluation. Well, okay, so to begin with about two years ago, the CEO of MongoDB declared that SQL is dead, nobody's teaching it in school anymore, it's going away, nobody cares. And then of course, very short time after that, MongoDB came out with its own SQL query mechanism for documents on Atlas. So that immediately tells you that there's a reason for that pivot. In fact, in addition to that couch base, which was their competitor in the JSON document space, is offering Capella columnar, which is a column based SQL analytics engine that is a company's couch base on the Capella cloud platform. And Redis has been supporting SQL for the past couple of years. Databricks, which was once militantly Spark based. In fact, if you had conversations with Databricks three or four years ago, they would have said, nobody cares about SQL anymore, everybody's moving to Spark. Well, now they have their own SQL capability called Databricks SQL and SQL statement API that they recently announced, so that you can invoke SQL in the form of select queries directly through this API. Certainly suggesting a shift in emphasis. The top most popular DBMS engines, according to DB-Engines, which is an online ranking site, are Oracle, MySQL, Microsoft SQL Server and PostgreSQL, which are all, of course, based on SQL. And Oracle has greatly expanded its footprint in the SQL space, well beyond Oracle Database, making big investments in MySQL with HeatWave on OCI and also on AWS, and also with their newly announced native OCI service for open source PostgreSQL. So in all those ways, they're increasing their footprint because they're adding in their investment because they see that there's growing opportunity in the SQL space, and that in order to take advantage of that opportunity, they need to move beyond the boundaries of their flagship Oracle Database. So we're seeing a number of other, there's a time to go into all the other ways in which SQL is rising to the top of the tree, but it was the case that people were saying, oh, that's old fashioned, we don't need SQL anymore, we do these other things. And actually, when you look at it on the transaction processing side, there was a distinctly negative attitude towards SQL amongst the application developers. Now, we do know there's a strong preference among application developers for document products like MongoDB, and that's going to continue. And by saying SQL is back, I don't mean it's washing away everything else. My personal belief is that going forward, we're looking at what we might call multi-model future, where databases may support more than one format, both internally and externally, and more than one method for accessing and organizing data. And in fact, with the advent of AI and generative AI, in the environment where people want to see data put together in different forms, there'll be even stronger push to have databases that support multiple different formats for data. But I believe that through all of that, SQL will remain the primary way of doing a business data analysis because for this very simple reason, kind of SQL is by far the most powerful mechanism for doing analysis of data without having to anticipate in advance in the structure of the database, what kinds of questions are going to be asked? Well, nice call, Carl. SQL remains the killer app of big data, as Armour Aua-Della said years ago. All right, David Menninger, you predicted that the definition of data is expanding using excited metric stores, feature stores, model management and data sharing as examples of what we could expect in 2023, and you show a mostly green level of accuracy for that prediction. Could you please elaborate? Sure. So, I mean, clearly the definition of data is expanding and maybe we should give ourselves all a red X because we didn't capitalize on what was happening around Gen AI, but Gen AI has certainly expanded the definition of data. But with specifically with respect to the four items I mentioned, Gen AI has also brought a greater focus on AI and the processes around AI. So we see much more interest in feature stores. We see much more interest in model management and trying to bring together managing LLMs and other types of models as well. On the data sharing front, we've got Databricks and Snowflake battling over establishing standards on how data should be shared into some of Sanjeev's points earlier about data products. So I think those are all, I would give those all green ratings as you've displayed there. On the metric store front, there are a couple of vendors who are focused on metric stores specifically, but I think it's gotten analytics and metrics broadly speaking have gotten less attention around the whole governance process. I'd like to see more of Sanjeev's predictions and desires for the market to expand the catalogs and to incorporate these things more fully. And then I think I would have given the metrics store a green rating as well. But I don't think there's as much focus on that as there ought to be right now. So I'll keep my comments a little briefer and we can get to the 2024 predictions. Thank you for that, David. Appreciate it. You keep an eye on the clock. All right, last but not least for the 2023 look back, we have Doug Henschen with the forecast last year that BI analytics reporting and dashboarding would be commoditized and embedding and automation would ascend. You've got some examples here and this looks like a direct hit. Please elaborate, Doug. Yeah, I've been talking about embedded BI analytics being on the rise for a few years, I've written a lot of reports about it and the trend continued in 2023. So it's green, we saw, it's about embedding these insights at decision points, not forcing people to go off to separate reports and dashboards and then come back to their work and then make their decision. So to do that, we saw more SDKs, more granular APIs to let developers bring those insights into apps, more GitHub integration with CICD capabilities, more low code, no code development options. We also saw more workflow from some of these BI analytics vendors and use of event architecture to automate. So use those insights not to trigger an alert to drive you off to a report or a dashboard but to trigger an action in an application. And of course we saw the enterprise apps vendors like Oracle, SAP, Salesforce, Workday all increasingly embedding insights at decision points within their enterprise applications. And then the late 2023 announcements I alluded to, in my book, we really didn't really miss the GenAI thing because I think Microsoft was kind of premature in its GenAI announcements. Very precious few actual GenAI capabilities for enterprise are generally available. Most everything is still private preview. Microsoft co-pilot in Teams and use of Power BI, accessing a natural language query of Power BI exposed through Teams. Public preview finally, November 2023. Tableau announced Pulse. This is more of a business user focused insights embedded in things like Slack and email and later probably this year, more Salesforce apps. Amazon Q, which is really inspired by QuickSight Q but now it's bringing that natural language query into many places within the Amazon ecosystem. Also a preview at this point. So lots coming that will further advance this trend in 2024. Great, some really good examples there, thank you. All right guys, appreciate you looking back on 2023 but let's get really to the heart of our call today and turn our attention to the 2024 predictions. We're going to keep the same order. The designated analyst will present his prediction and then we'll have time for one or two other analysts to chime in on that forecast. Here's a table showing all of the predictions for 2024. 100% of them have AI included but spanning new data platforms, governance, metadata, database, skills gaps and more. So let's really get into it. Sanjeev, you first please. You've got the rise of intelligent data platform. We've been talking about the next data platform beyond the so-called modern data platforms of Snowflake, Databricks, Google, AWS, Microsoft. You could probably include Oracle in there in that mix as the database king. You've got that plus a call on governance and open source LLMs going after proprietary foundation models, lots to cover. So please take it from there and elaborate. So thank you for that, Dave. I have so many predictions, I'm going to keep it short. I published a blog recently with 10 trends for them are rising, all of them have to do with AI. The number one prediction I have on my list is the Intelligent Data Platform. What I'm saying here is that we've been talking, in fact, a lot of our predictions last year were on a data stack. So modern data stack, whatever you want to call it. So my prediction for this year is that we are bringing AI into the mix. We are not taking data out to a separate data stack just to serve AI use cases. That would be too much of data movement and which brings all sorts of issues with it. But how do I bring AI into my existing data stack? And that's what I'm calling it an Intelligent Data Platform. So essentially what we are doing here is that we've got an infrastructure layer which is cross cloud or super cloud, as you call it. And then we've got a unified storage layer. We've talked quite a bit about it and we may even talk more about a unified storage layer. Now we've separated out storage and compute. Now we are also separating out analytical engines. So we already did that. We have a Spark layer, we could have Panda, we could have even DougDB, SQL of course. In that layer of analytics we are now bringing algorithms. These foundation models could be either open source or proprietary. So I could have open AI or anthropic cloud or I could have any of the models from hugging phase. So we are bringing the model catalog on top of data stack. Also we are adding vector search along with that. The idea is that we expose this analytical layer through an API or an SDK layer. So then on top we can still have data products. So the data products don't go away or the BI dashboards which are actually data products. But now we are also adding more than just data artifacts. We could even have AI agents which is going to be, in my opinion, a very big move in 2024. These AI agents will work on top of LLMs but instead of just summarizing documents or translating it, they will kick off some sort of an orchestration of a task. So AI agents, chatbots, so all that together is what I'm calling an intelligent data platform. Along with bringing data and AI together, we are also going to converge the governance of each. So we are now going to have AI governance which will build upon data governance. In data governance, we had this ability to see what artifacts I have, technical metadata, business metadata, operation metadata. Now I should also be able to see what models are in use. In my company, are these models certified for use? What business cases are associated with those models? Because in fact, we just talked about multi-modal, so we've got many use cases. So this is the prediction that I'm making and I see a lot of vendors are moving in this direction, a lot of hyperscalers, data breaks. I'm sure we'll see stuff coming out of Snowflake and then Oracle, Cloudera, TerraData, in my opinion, they all start converging into this integrated stack that I'm calling an intelligent data platform. I'll give you a quick data point on your comment about open source going after proprietary foundation models in the latest ETR survey of 1700 IT decision makers. Lama 2 had approximately 17% more installation citations than Anthropic and the other interesting data point was about 30% of those were on-prem. So topic for another day, but Doug Henschen and Dave Meniger, you got a quick comment on Sanjeev's predictions. I'd start by saying very ambitious and visionary and I think the marketplace is a long way from seeing the sort of sophistication you're talking about, maybe like the top one or 2% of companies that are sophisticated being able to do that sort of thing, even vendors are struggling with these things. We're starting to see some database vendors build their own models, their own generative models, but we're really in the stone knives and bear skin rug stage of Gen AI. And I even talked to a lot of CXOs and very few of them are aware of even, the Calibrizolations, Atlands, Microsoft Proviews, AWS Data Zones, Google Dataplex. I think analysts shouldn't get too far ahead of where the market really is and the appetite for these things. We're just starting to get to the early stages of previews. GA is still a long way off and actual usage. I think that OpenAI stat you had, Dave, indicated a lot of tire kicking in experimentation, but not a lot of real production use. I was gonna make a similar comment that I think, but I wanna get to the heart of why I think the consolidation into Ensel's room platform is gonna lag a little bit and that has to do with the skill sets that are involved in the different activities. Clearly we have to have the analytical processing in the platform, but the tooling around it, I believe, will continue to be separate. So maybe I'm nitpicking a little bit, but, and the other point, I had similar data to you, Dave, that we see the open source models being used and adopted at similar levels to the commercial models. So in aggregate, so not picking one versus another, but in aggregate, the OSS models are being used as much as the commercial models. Great, thanks guys. Okay, Tony Bear, up next. We're showing your prediction that GenAI will simplify database design, deployment, and operations. How so? Okay, thanks, Dave. In essence, basically what I'm talking about here is actually I'm kind of double clicking down what Sanjeev said. It's a less ambitious view, but looking at not so much, our enterprise is going to buy GenAI tools. It's more there to see GenAI, or GenITV AI, and machine learning for that matter, further working their way in terms of how we operate databases. So it's not necessarily gonna be an extra skew or anything like that. It's just gonna be more a matter of like some invisible automation that's gonna happen underneath. And so I'll just give some examples of what I kind of expect to see. And I think one reason why I'm fairly bullish in the near term is that these are, for the most part, this is fairly incremental improvements because we've been working machine learning into the operation design of databases for your life, for instance, like you're deciphering data structures. So I see this is being kind of an incremental improvement. For instance, for database designs, I think the biggest bank for the buck is gonna be with essentially whatever deals with the content of the data. And this is where we basically can take advantage of some of the, for instance, like the document entity extraction capabilities of foundation models. Again, we're not trying to ask enterprises to go full bore into adopting GenITV AI, but I could see some of this automation creeping inside the database design tool. So for instance, I could imagine, for instance, you put in some requirements document and basically some developer or constituent, basically the folks who are collaborating and putting in annotations and comments on the side, that the large language model could essentially do some entity extraction and based on requirements and requests, could start to suggest, let's say some ER, to do some data modeling, some very rudimentary data modeling. I'm not talking about the lights out here, but here's your start. Here's a rough data model. Here's some rough entity relationship, ER diagrams, we'll start to generate a schema. I could also say, and this one is, I think, relatively a no-brainer, is this could be used for a synthetic data generation, which we use for a lot of testing. In other words, based on the characteristics of the actual data, in other words, have a language model, look at that data and generate synthetic based on the characteristics of data that's already there. That's relatively speaking, a no-brainer. Further down the line, and I think this gets more into Sanjeev's AI agents, and I don't necessarily expect this to be a done deal in 2024, but I could start to see the first steps towards basically taking the code generation capabilities of generative AI to help start to create some of those data transmission pipelines. Now, we're seeing the first steps of this today with SQL code generation. It's not a concept leap, it's more of a technology leap, which is going to take further more time because designing the orchestrations and optimizing how we use compute for all of this, that's going to be, those are going to be details that are going to take a while to work out. So I don't expect that to mature in 2024, but I expect to see some first steps there. I also see in a related sense, I could see generative being applied towards the governance aspect of database management and I think a good example here, I'd like to point to is Atlin, which is a data catalog provider, and which is focused on, many different types of data catalogs. This one focuses on data ops. They start with kind of a common natural language search function, which is kind of akin to some of the, so the natural language or conversational query functions that you're starting to see in like in queue, data breaks in your lake house IQ, so on so forth, but this is being applied towards like a cert, kind of go search of basically of metadata. It can auto discover, database metadata, and this also basically builds incrementally on what we've had with machine learning all these years, which can basically deduce things like table and column names, schema specifications and data lineage, and then doc, and then this is the, the generative part, generate the documentation in plain English. Atlin is already starting to do that. So this is the type of thing I expect to see more of this year. Great, thank you, Tony. Carl, you've got a comment on Tony's prediction. Yeah, I just, I think it's a great prediction. And I think that actually it dovetails pretty well with what Sanjeev was saying, because the whole idea behind it is that we can take what is inherently very complex, which is enterprise data, and we can render it into a form. The database, the data itself doesn't actually get simpler. The physical database doesn't get simpler, but our interaction with the data gets simpler because it's being mediated by this generative AI capability, which I think is what Tony was talking about, but it also makes it possible to do things like create the intelligent data platform, because now we can, you know, building the intelligent data platform requires all of these little steps, all these incredibly precise actions that you need to take to make sure that the data is synchronized and that it makes sense together and all this kind of stuff. Human beings usually get, you know, they fall down on these things. The projects start and stall and then you get abandoned because it's too hard. But, you know, generative AI doesn't get tired. It doesn't get bored. It just does its job. So I think that, you know, to look at it that way, you know, Tony's idea of the simplification of the data environment, not necessarily the database, but the whole data environment and the way you build and maintain data dovetails nicely with what Sanjeev was saying. All right, Carl, let's stick with you and take a look at your prediction that gen AI and other developments are going to catalyze a rationalization of what I infer data silos based on your prediction to enable combinatorial data use cases, which will ultimately create governance challenges. So I would say, you know, this may seem obvious to some people, but you're predicting, are you predicting that organizations are going to be able to succeed in 2024? Or will this governance challenge create insurmountable barriers to outcomes this year? Please explain. Okay, so this prediction is kind of a cousin to Sanjeev's prediction in that he was talking about intelligence data platform. I'm just saying right now, the data organization of most enterprises is a total mess, okay? It's not well-coordinated. Data is created for individual applications and then people take data from the databases that were created for individual applications. They combine it together for specific analytic problems. They put it in the data warehouses and that kind of thing or they drop it in a data like, but they're not really creating a coherent environment for the data overall. So it continues to be a mess. In order, when generative AI comes into the picture, it's going to start combining data in ways that was never designed to be combined. You're either going to get irrational combinations because it's just going to make assumptions that are not valid. Or it's going to expose things that we didn't expect to have exposed because it's picking data from different places that were previously not connected at all. So we need to think about that. And we also, we need to think particularly about how this impacts legacy data. So to answer your question, this is not a prediction that says, this is all that we did not in 2024. No, that's ridiculous. This could be a 10-year process of trying to rationalize data, but it has to be done. You'll never get the full value of generative AI data capture, combination, presentation unless you also deal with these issues and come up with decisions that say, for instance, we can't put this data together with this data or this data can't be exposed because it's confidential. We didn't market confidential before because we didn't think it would ever be combined with something else that exposes that confidential nature. But now we have to, there's a lot of work there. So, I mean, Sanjeev was talking about a structure, which is the intelligent data platform. I'm talking about human effort, which is going to be messier. Even with generative AI helping, it's still going to be a big effort. Gotcha, thank you for that. Tony and Doug, I believe you've got comments on Carl's prediction. Okay, I'll dive in first, which is that kind of like, I guess my prediction was kind of the bright side of this, but I think, you know, Carl basically very much points to the fact that this also gets us into deeper, more complex waters. And it's actually, it sort of echoes what happened with the modern data stack, which was supposed to bring all this stuff together, but added lots of complexity. So, yes, as we start putting data together that we didn't, that wasn't necessarily put together before because it was, let's say, in different formats and different systems. It was in different contexts. But, yes, it is going to start to, we will start dealing with some Frankenstein type table combinations. So, I mean, and I think here, what's going to be really important is data lineage, you know, to kind of figure out like, so we understand the provenance of all this data and understand what happens to it. And as Carl's saying, when we start getting into this recombinance stuff, we're getting into some deeper waters and it is going to take time for essentially our ability to cope with this is going to catch up. Great, thank you. Yeah, I would totally agree. I think the reality for enterprises is heterogeneity. We have seen efforts for this proverbial intelligent data platform. I think Microsoft Fabric is this idea that goes across their collaborative products, across their enterprise apps like Dynamics, across their productivity apps. But most organizations, even mid-sized organizations, aren't that heterogeneity, heterogeneas, and organizations aren't necessarily interested in putting all their eggs in one basket. So some of the chaos that Carl talked about is spot on it and it's a tough challenge. It is a tough challenge and also I would just point out in furtherance of what Doug was saying that the heterogeneity is important. And so no data platform that arises out of this can be uniform, it can be just one thing. It has to be more like a data environment. And maybe even a data environment that tolerates the idea that in different contexts, different sets of facts are true. In other words, you may have a different temporal context. You may say on last Tuesday what was true and then it'll tell you what was true last Tuesday, which is different from today. So all of that needs to be part of the system. Giving new meaning to alternative facts. Okay, up next, Dave Menegar with the prediction that despite all the hype around Gen AI, it won't replace traditional AI in the most demanding use cases. And you're predicting also a continued AI skills gap. Again, this feels like a lock, but add some color and some data points that increase the degree of difficulty for us, please. Well, so the reason I think it's important to discuss this is that generative AI is sucking all the air out of the room. And so I think people need to be aware that, yes, there's a lot of attention. It's doing a lot of great things. It's making various software products easier to use. It's easier to code software products. But in the most demanding use cases, it really isn't there. That's not what it's designed to do, at least not yet. So for instance, we have some research that shows that in areas like document summarization or in natural language assistance, clearly generative AI is more likely to be valuable there. It's gonna have a greater impact. In our research, one and a half times is likely to have a greater impact there. However, when you go to the other end of the spectrum and this particular set of research was around banking, if you look at things like credit risk, fraud detection, algorithmic trading, even customer acquisition, predictive AI models, traditional AI was twice as likely to have an impact over the next two years than generative AI. So there are these areas where it's important to recognize we need more advanced skills and capabilities to develop those types of models. Data scientists have to understand a lot of things. They have to understand the biases in the data. They have to understand the training processes. They have to worry about overfitting and poor sampling.  You need to evaluate the impact of false positives and false negatives. So while AI, generative AI is making tooling better, including the use, the generative AI process to create models, I'm not trusting my personalized medical care to anything that wasn't developed by a Stanford trained biomedical PhD, right?  And our research shows the skills don't exist today. One quarter of organizations report they have the skills they need to develop AI models and two thirds report that they can't get those skills and they're the most difficult skills for them to find and retain in the market. So I want to make people aware, don't put all your eggs in the generative AI basket. It's absolutely valuable, but don't put all your eggs in one basket. David, I love how you always bring the data to back up your opinions. And Sanjeev and Carl, do you have anything to add here? So it's since I've taken on this role of being an insufferable optimist, so I may say that we are maybe just insufferable. What I want to say is that in 1994, if somebody had told me that don't put all your eggs in one basket called worldwide web because it's just toy. All it does is just show static data. I would have never imagined that 10 years later, my entire tax code would be online. I would never have to go to a travel agent. I could buy stuff. So I agree that it's early in its journey, journey AI, but I have faith that in a few years, and this is going to be the new norm. If I look at the history before worldwide web took over, we already had Markup languages on Unix, I used to use SCMF, but HTML made things very easy. TCPIP had been in existence for 25, 30 years, and then HTTP came and it became pervasive. So I feel Gen AI is at that early stage of worldwide web in 1994. And another 10 years, it could be a different story.  Yeah, I just, I wanted to reinforce what Dave said and offer this observation that if you recall a movie called The Right Stuff, you'll remember that in that movie, the scientists believed that the astronaut or astronauts would just be passengers and that the computer equipment would run the whole thing. And if they had gotten their way, John Glenn might not have survived because he did go manual in order to adjust the angle of entry for his capsule because of something else that went wrong. And so, and of course, in Apollo 13, because there were three highly trained pilots, they were able to save their own lives by making adjustments that were involving a little bit more than just calculations. It involved just sort of sea of the pants, rough estimates and looking and based on knowledge, doing the right thing. So my point is this, General AI does indeed do a lot of work for us so we wouldn't need to do it and it relieves the responsibility from non-technical people so they can do their jobs without having to learn a lot of stuff. But at the same time, I believe along with Dave that it will ultimately open up more opportunity for highly trained individuals to guide it in the right directions, to help set up the environments so that everything works right and to avoid problems. I'm not even talking about hallucinations which I think are relatively easy to avoid but more problematic things that involve misinterpretation and improper combinations of data and that kind of thing. So I totally agree that this is actually an opportunity for more not less skills development. And nice throwback references, Carl, thank you. All right, we just got about five minutes left. The last prediction comes from Doug Henschen who's predicting that Gen AI will have a material impact on how organizations approach BI and predictive analytics. Doug, this is a prediction with big implications for data analysts, data pros working in the pipeline, Tableau jocks, and end business users, very exciting. Are you saying we'll see this transformation before the end of the year? No, no, I'm saying this is continuing the trend I talked about in 2023, increasing use of embedding, increasing use of insights being exposed where people are doing their work. The most adopted and most used feature in the augmented analytics trend that started five, eight years ago was natural language query. And Gen AI in 2024, 2023 was all about announcements. Late 2023, we started to see public previews. 2024, we're gonna start to see GA's and the most material impact on BI analytics is going to be putting natural language query on steroids, more accuracy, more verbose, more interpretive. And Gen AI will help you as the examples I gave, Microsoft Copilot, Tableau, Einstein Copilot, you know, AWS, Amazon Q, we're gonna start to have this query anywhere you need it in apps, in places other than just a BI platform. I think the caution is that it's still gonna be important, a really important role for analysts and that's gonna be curating the data, curating the question, curating the prompts. You know, mainstream business users don't necessarily know what to ask. So when you see natural language query interfaces, often there are questions, sort of their prompts to get them started and they're gonna be curating business metrics. They're gonna be, maybe we won't, we'll have Gen AI building the dashboards and reports for those that are still needed as sort of a system of record. But I think the analysts class are going to be focused more on deciding the key metrics that matter, determining whether is this good or bad for business and guiding users in their natural language query interactions on decisions they need to make. So business users will need those prompts, will need guidance as they start to use Gen AI instead of toggling between dashboards and reports and their transactional interfaces. You have more of a change in role versus an elimination of that role. Dave Menninger, I know you gotta run and Tony, you've got some quick comments here and then we'll wrap. Yeah, I'll make a quick comment. Thank goodness, in three quarters of organizations, less than half of the workforce has access to analytics. This is the solution for solving that problem. Prior to Gen AI, we saw that about a quarter of organizations were using natural language processing. 80% were using dashboards and reports. We need to see the inverse of that so that more of the organization can access analytics. All right, Tony, give you the final word here. Yeah, a quick point, which is that, I think the thing what Doug said here, which is that where the importance is gonna be is curating data questions and prompts. It's knowing how to ask the right questions of the data because basically technology will be there to get it. So I think what Doug is saying right there, it's all gonna come down to people knowing how to ask the right questions. Guys, can I just add one quick thing on that because this is, see, I wanna just continue this dialogue I had earlier about like how technology advances. So to me, prompt engineering today is highly complex and it just keeps changing. But to me, this reminds again, back to the time when internet search first came out. Remember, we had to put double quotes and put some hints here and there. Now we don't even think about it. So same thing, we are at this early stages of prompt engineering. Yeah, no doubt. Guys, I'm sorry we gotta go, but I wanna share my personal gratitude. It's amazing to me, this has been our third year through. It kind of started back at AWS re-invent in 2021 and looking forward to more collaboration in the future. So thank you. Thank you. Thank you, Dave. All right, also I wanna thank Alex Meyerson. Yes, happy new year. Who's on production and manages the podcast. Ken Schiffman as well. Kristin Martin and Cheryl Knight help get the word out on social media and in our newsletters and Rob Hof is our editor-in-chief at siliconangle.com. Remember, all these episodes are available as podcasts wherever you listen. I don't know if you know this. I'm really proud to say we hit almost 650,000 downloads of breaking analysis this past year. Wow, all you gotta do is search breaking analysis podcast. I publish each week on siliconangle.com and thecuberesearch.com and you can email me at david.balante at siliconangle.com or DM me at davilante.com on our LinkedIn post and check out etr.ai. They get great survey data, constantly updating the dataset. This is Dave Vellante for theCUBE Research Insights powered by ETR. Thanks for watching and we'll see you next time on breaking analysis.


Welcome back, welcome folks, we have a down industrial trading down $32, Nasdaq is off 105, S&P is off 21, Gold contract up $2, trade at $18.78 an ounce, we have silver down $0.15, $22.25 an ounce, light sweet crude up $0.86, trading at $74.25 and notes and bonds, you get the 10-year note down 29 ticks, trading $1.1316, the 30-year offer for point plus two ticks at $129 and we get the 10-year right now yielding $3.61 folks, so the range for the last three months, 3.3 is the low, 4.2 is the high and $king dollar, $king dollar is on the move man, $king dollar is trading up $700 ticks, $103.16, the euro is at $107, the yen is trading out here at a price point of $132.51 and the British pound is at $120 to $1 US dollar. Now we get some divergence out here and what it is, you know, you're pulling back but the bottom line you're pulling back on the spy and the dow, we're tremendously light of volume so we'll see where the shake's out coming into the close. Now what it has done is got back inside the lower range, this being the, oh it's close, well yeah, this being the S&P, so if we're at 410.18, it's 410.49, that you get underneath that, that's the lower range and you can see the volume, it's light, it's 40 million chairs going into 101. Now that being said, they end the X100s to different animals, so if we go take a look at the cues, cues out here, bottom line, volume is also light on the cues but that being said, I'm going to show you something inside the composite, the composite is pulling backward volume, the composite already, we've done $4.2 billion already, so the composite is going to bang out that $5 billion chairs. Gold, gold contracts moving sideways out here today, we got a high of $18.94, you got a low of $18.73, right now you're trading at the $18.79 level and when you just, when you do look at this folks, okay, strength and a 30%, 38% retracement line up kind of at the same place, so I suspect what we're going to have here is that this thing's going to run somewhere down, it's like basically the 1837 to the actual .382 is 1849, but 1837 is somewhere about 1821. That's where the strength is, that's where gold took off from and of course it's going to be about all this good old US dollar because the US dollar on a dead cat bounce can get to 106.200 and right now you're at 103.615. Stay right there folks, come right back.


of my general practice placement is done, I've only got one week left guys, what am I gonna do when I finish? What am I gonna do? So I've had an amazing week again. Monday I saw some wounds which is really good because I love wounds, I love the nasties, I'm very strange like that and one of the wounds that we saw on Monday was a surgical wound on the chest area and he had a couple of stitches to remove and my mentor looked at me and she said oh do you want to remove these stitches and I was like um never removed a stitch before, sorry to disappoint you but can I watch you first and then I'll do what? My mentor was like Claire you're not supposed to say that in front of the patient but we had a laugh about it, it was a comedy moment it was quite funny and the patient was lovely he was like don't worry Claire if you want to practice on me you can practice on me everyone's got to learn so I was like okay so well I'll watch my mentor do it first and then I'll have a go that's all right and then he was lovely about it I was very nervous I don't know if it's like this everywhere I don't know if different countries have different ways of removing stitches but you literally just you pull it with the tweezers like a little a tie so you pull it with the tweezers and then you get a blade and you just slice it off it's a bit nervous I've got a blade in my hand I was there like um sorry if I got you no that's a joke I would never do that I'm far too gentle to even harm anybody I've done the clips little metal clips anyone that doesn't know what I'm on about they're like staples in the skin so I've removed those before no problem I did that on my first placement but I've never actually removed a proper stitch it's bizarre like I didn't really anyway it's may be a day it may be a day that I did something new I learned a new skill I removed a stitch I had some of my own patients as well so I did my own patients I have been doing a mixture of working with my mentor and doing my own clinics so doing the diabetic book checks the blood pressures asthma clinics which have been great it's so good you don't realise um in general practice how much you're working autonomously and it's just fantastic like it's your clinic you can run it how you want you've got your family time the doctor's amazing the doctor of that clinic is fantastic and he's always saying you know it's about you it's about your family work family life as long as the patients are seen they're safe they're healthy all the checks are being done all the computer systems done all the paperwork and everything's done he doesn't mind what hours you do how long you work he's fine he's really good in fact he said to um one of the other doctors he was saying what are you still doing here you were supposed to go an hour ago your little girl's gonna absolutely hate you if you don't get home now and told her off for actually staying over so that was really really nice to see something you don't see often so I'm just loving it and then Tuesday we had baby immunisations in the morning and we had a couple of blood pressures thrown in there as well just for good measure and then in the afternoon we had minor surgery and minor surgery was really interesting this week we had a couple of steroid injections into the joints which was fantastic and we had a couple of skin tags warts and mole removals so I was really excited for that because yes I haven't seen this before and it was really great like the surgeon's really good he's very precise in what he's doing and he doesn't leave the tiniest little bit like you can see he's quite a perfectionist so that was quite interesting to see and he was quick he was just like he was really good at his job he's like yeah yeah done fine see later in out in out so there's non-stop in minor surgery but that was really good to see it was great to see a new thing this week um especially mole removals oh you have to he injected it with a local anesthetic around it and then he sort of trimmed got the scalpel and just dug like a little tiny bit around the area and then just sliced it across and then the mole came off and then went into a little pot pot of fluid to be sent off to be examined by the lab make sure there's nothing sinister going on and the results will go back to the patients so that was really good to experience and then Wednesday I had the asthma and COPD clinic with my buddy mentor who is fantastic she's really good she's so knowledgeable with asthma and COPD it's fantastic so I worked alongside her with that she was showing me how to work out the spirometer readings as well actually I've got I've got a copy let me show you so this is the spirometer readings look at that how is anyone supposed to understand this writing oh gosh so that's spirometer readings so to blow a breathing test basically to test the lung capacity and the force volume things like that and you you have to minus the best from the worst and get over percentage so it's quite tricky to understand and work out so I'm not going to go into that and then Thursday we had a home visit so another wound some blood pressures diabetic foot checks again I was given a task as well to go online this wasn't at the home visit this was in the clinic when we got back to clinic I was given the task to print off some of the hand washing techniques which I'll post the link below again so you can see what those are if we're in a different country or something it might be different so share your ideas with me guys comment give me a comment if you have a different sort of hand washing technique in your country but let me know please so I'll post a link below have a look let me know if there's anything different and so I printed off the hand washing techniques and then I laminated them oh I love laminated things I've got my own laminator here at home I love laminating I love making things and then I put them up around the clinic all by the sinks for people to see and then Friday Friday I was sat with the doctor so on Friday we saw a variety of patients again from general coughs and colds someone had lost their voice a couple of mental health patients as well so just assessing their needs and referring them on to the appropriate services because one was quite they needed a referral basically so I did that and I faxed it to them and everything and I finished at two o'clock I finished nice and early on Friday so I got home did some exercises chilled out for the night I didn't nothing I didn't even touch my phone I sat and I watched Nashville anyone does anyone watch Nashville Nashville is amazing if you don't watch Nashville have a look go and check it out watch Nashville because it's amazing I'm on season two now so I've been binge watching that like crazy lately and today is Saturday and as I'm going to post another video all about the Haas scholarship but I had my funding I'm creating my blog site today that's what I'm going to be doing all weekend is making my blog site look amazing and professional and hopefully it's going to be much better than it already is so links below for my blog site if you want to have a look at it and see what I do to it and hope everyone has an amazing weekend Monday oh I'm going to be gutted next week next week's vlog is going to be emotional I said this in my last vlog it's going to be really emotional and I'm not looking forward to finishing and we'll just I'll see you next weekend have a great weekend enjoy this lovely beautiful rain that we're having go dance in the rain if you want to dance in the rain and I'll see you all next week