Unknown: Tree schema is a data catalog that is making metadata management accessible to everyone.
With TreeSchema, you can create your data catalog and have it fully populated in under 5 minutes when using 1 of the many automated adapters that can connect directly to your data stores.
Tree schema includes essential cataloging features such as first class support for both tabular and unstructured data, data lineage, rich text documentation,
asset tagging, and more.
Built from the ground up with a focus on the intersection of people and data, your entire team will find it easier to foster collaboration
you'll love Tree Schema as much as you love your data. Go to data engineering
you'll love Tree Schema as much as you love your data. Go to data engineering podcast.com/treeschema
today to get 1 month free. And if you contact them and mention this podcast, you can get an additional 50% off the first 3 months after the trial. And when you're ready to build your next pipeline or want to test out the projects you hear about on the show, you'll need somewhere to deploy it. So check out our friends over at Linode. With their managed Kubernetes platform, it's now even easier to deploy and scale your workflows or try out the latest Helm charts from tools like Pulsar, Pachyderm, and Dagster.
With simple pricing, fast networking, object storage, and worldwide data centers, you've got everything you need to run a bulletproof data platform.
Go to data engineering podcast.com/linode,
that's l I n o d e, today and get a $60 credit to try out a Kubernetes cluster of your own. And don't forget to thank them for their continued support of this show. Your host is Tobias Macy. And today, I'm interviewing Dale Kim about Hazelcast,
the distributed in memory computing platform for data intensive applications. So, Dale, can you start by introducing yourself?
Unknown: Hi, Tobias. Thanks for having me on your podcast.
My name is Dale Kim. I'm the senior director of technical solutions at Hazelcast, and I'm responsible for the go to market strategy of our in memory computing technologies, which essentially means that I talk to our engineering team, our product management team, analysts,
customers, partners, and so on to try to get a feel of the different requirements
for some of the computing needs that our customers have. And so this often entails large scale data management and data processing requirements for some of these modern architectures today.
Unknown: And do you remember how you first got involved with data management?
Unknown: Yeah. Actually, I have a degree in computer science.
And so I've been a technologist for a very long time, and 1 of the first companies I worked at was a relational database company. And that was the time when relational databases were really hot, and so suddenly, there's a lot of focus on what you can do with data online.
And from there, I kind of drifted over towards more the of the nonstructured
or the non relational data types. So the next company I worked with was in full text search, even before
the Internet or World Wide Web were household names. And so having the ability to search for textual information in a way that is very consistent with the way we think about finding information was very fascinating. And from there, I've just worked for a number of data management platform companies
in a variety of different fields. And I think that everybody is dealing with data today in some form or another, even in a private consumer oriented way. And I think the technologies that are coming out to be able to address some of these newer ideas and newer challenges is is fascinating. So I've been with data management
pretty much from the start.
Unknown: So now you've ended up with Hazelcast. So I'm wondering if you can give a bit more of a description about what it is and some of the origin story for that.
Unknown: What fascinates me about Hazelcast
is its focus on high performance, so high throughput data,
low latency responsiveness.
You you hear about all these different data management platforms that talk about these things, but Hazelcast's advantage is around in memory. And in memory
isn't a new concept. It's been around for a while, but there have been some limitations about what it could do in the past, and some of these limitations are being mitigated so that in memory speeds are opening up to more and more companies. And Hazelcast was founded a little more than 10 years ago, actually, in Istanbul, Turkey by a couple of very smart engineers, and they came to Silicon Valley to start his cast as a formal company. And it was all about in memory computing. And so the first product was the IMDG product, which stands for the in memory data grid. So very much like a database, but a bit more capabilities in terms of distributed computing,
ways to simplify building applications that could be spread across multiple nodes in a cluster, and thus enable parallelization
much more simply. And so from the early roots, it was all about trying to get applications that ran faster, but at the same time, maintaining some of these enterprise qualities like
security and reliability and availability. So ensuring that you're not getting speed at any cost, but getting the right amount of speed that you need to address your use cases while also protecting your data. And we've added on stream processing since then, and we have a set of technologies that work extremely well together and are fitting in quite well with some of the types of use cases that people are building today.
Unknown: And you mentioned that it's not being built at the expense of some of the reliability and durability guarantees that you might care about is particularly if you're working on mission critical applications. So I'm wondering if you can dig a bit more into some of the benefits and the potential trade offs of in memory compute, particularly for data intensive workloads and things that are going to be operating on stateful sets of operations.
Unknown: Yeah. The benefits of in memory computing
have largely to do with the fact that you have fast access to data that's stored in memory. And so I've heard some people say that this notion of in memory computation or in memory processing
is redundant, when in fact, if you think about it, the processing isn't done in memory. The processing is done in the CPU or, these days, increasingly more in the GPU.
And the in memory simply means that all of the data is stored
within memory and not necessarily spilled out to disk. And so when you have a system that's designed
to optimize that pattern where you have all your data in memory, that means that you can get fast access to a lot of fast processing
and be able to deliver on some of these use cases that have very narrow windows for service level agreements. So you get performance, but at the same time, when you have a fast system, you need to incorporate some of the typical
characteristics of a distributed system, like replication in a variety of ways, and you need to have consistent replication. So we've after doing some research, some competitive research, we've seen at least 1 technology where
at certain levels of throughput,
it pauses some of the replication
to be able to handle that throughput. And so most people won't notice it, but it's 1 of those things that if you're not watching, then you could potentially have a big problem when your data isn't replicated and nodes go down and you get failures, and then you might see a lot of unexpected data loss when you thought that all of the data protection capabilities were in place. But for us, we don't make those trade offs when we run our benchmarks. So we say, here's what you get in a true production environment in terms of performance, and you can be sure that we keep everything retained for the business continuity that you would expect. And and certainly some of the trade offs are pretty clear and and people are pretty familiar with these. It's mostly about how much data you can store. So you wouldn't use Hazelcast
as your, say, your system of record for petabytes of data. We're talking more about operational data where you want to process it very quickly. So things like payment processing or fraud detection are good cases where you might have a good amount of data in memory as a lookup, but also have the engine processing in parallel
and being able to use that data in in almost a transient way. So it's it's data that's persisted somewhere else, but we put it into our engine so that we can have those very stringent, very data intensive workloads running.
Unknown: My understanding
is that the actual implementation
is as a library
that can be embedded into other applications, or it can also be built into a standalone
sort of object storage
for in memory operations as well as some of the particular algorithms for being able to handle
conflict resolution
and concurrent access. Access. I'm wondering if you can dig a bit more into some of the common use cases for the data grid that Hazelcast implements.
Unknown: Some of the common use cases
involve payment processing. So a lot of banks use us as part of the mechanism for authenticating and
settling payments.
And 1 part of that 1 important part of that is also fraud detection, especially
based on machine learning models.
So with machine learning and and fraud detection as potentially a huge competitive
advantage factor for a lot of these companies where the better they are with detecting fraud and the better they are about not getting false positives, that represents real revenue for them. So a lot of these use cases that that involve being more accurate, being better with your data for the purposes of cutting costs and and adding revenue are great use cases for Hazelcast.
Other use cases involve
transmission of data between different nodes.
Another great use case is having a cache as a service. So a lot of companies know that they have applications,
both internal, external, that that need to access data as quickly as possible, but they may think about building a a cache specific to that application.
And we've seen among our customers that they quickly recognize that that's not a scalable way to go. It'll take them months for them to essentially recreate the wheel. So what if you had a centralized
and multi tenant
role based access controlled
caching layer that can be shared across
multiple development teams. So they can all leverage that as their caching layer to provide fast access to data, while also segmenting it properly enough so that you get the separation of the sensitive data from the more public data. That's a common use case across industries.
And I think there are many types of different use cases where fast processing, including things like ETL,
so very technical use cases that are appropriate for Hazelcast.
Unknown: So in the caching scenario, it sounds like you could use it as a replacement for things such as Redis or a memcached where you need to be able to have that common access layer to avoid having to do expensive calls out to on disk storage.
Unknown: Yeah. Absolutely. And in fact, you know, we've had a number of customers migrate to Redis, not necessarily because of
specific
differences in the architecture. It's it's more about what capabilities are provided to Hazelcast. And as I mentioned, we're not only a database, so we provide data storage, but we're also an in memory data grid. And what that means is that you can write applications
that are deployed across multiple nodes in a cluster. So it's very much like the Apache Spark model where you have processing that's delivered to the nodes versus moving data to the node where the computation is. And that notion of moving computation,
people refer to as data locality, and that's still a very important concept in trying to handle some of these large scale data problems.
And being able to add that capability
as part of your
overall solution, in addition to caching, has become a very powerful capability
when using in memory.
Unknown: So in terms of how the HASEL cast grid is implemented,
can you dig a bit more into the architecture? And I'm also interested in the approach that's taken for the sort of distribution or balancing of data across the cluster.
Unknown: 1 thing that the architectures that the original architects did very well is try to model the Hazelcast framework
on existing Java best practices. So you can almost think of Hazelcast as
a Java
object store that's distributed
across multiple nodes. And so whereas a lot of these primitives within Java are mostly for single JVM on a single node. Imagine if those objects that you're creating in your application can be seen with proper access, of course, by other applications
running in your network. It basically extends
a common familiar programming model of Java
across into a distributed
environment.
And so using that as a starting point for the architecture
makes Hazelcast very familiar for a lot of Java developers. And then since then, we've added a number of clients in different languages like Go and Node. Js and dotnet so that you can use it as an object store and get fast access to data. But that simplicity has always been a hallmark of ours so that it's very easy to get started and very easy to integrate with your existing system and then start building from there.
Unknown: 1 of the first times that I came across Hazelcast was when I was starting to take a look at OrientDB and realized that it was using Hazelcast as its coordination mechanism. So I'm wondering if that's a common approach and just some of the other patterns that you tend to see with developers who are building on top of Hazelcast?
Unknown: I do think that a lot of companies are taking advantage of the underlying plumbing of Hazelcast, interestingly enough. So while performance
is our big thing, because of the foundation of interprocess communication that we provide. You know, the OrientDB example that you gave is a perfect example where an open source company
saw a foundation and decided to leverage that instead of having to build their own cluster management software.
And the interesting thing about Hazelcast is that it has a auto provisioning mechanism so that, say, if you build an application and run 2 instances of it, it can be configured for them to auto discovery each other by broadcasting and that you automatically form a cluster so that you don't have to pre
other
applications per node, and when configured to do so, they will discover each other and they will automatically create that distributed system without a lot of effort. And that's why we can package our system as a very lightweight library without a lot of external dependencies,
and you can embed it in your application,
and you get that clustering mechanism basically for free simply by embedding that technology, the the Hazelcast Foundation, into your software.
Unknown: And in terms of the underlying principles and the system design of Hazelcast, what are some of the ways that it has evolved since it was first built and particularly in recent years?
Unknown: Certainly, there are a lot of very low level technical
capabilities that we've added on. 1 of the more fascinating ones is our CP subsystem.
So a lot of distributed systems today follow the AP model, and AP referring to the cap theorem where you can have consistency or availability,
but not both, in addition to the partition tolerance of a distributed system. Most distributed systems out there are of the AP model, which means that availability
is preferred over consistency. So you might get stale data, but you will get an answer. 1 thing that we added, as I mentioned, was the CP subsystem,
which is used in very stringent environments where the data has to be consistent. In those environments, it's better to have the right answer, meaning the most up to date data
element coming from the store, versus the system being available. So it's okay for you to get an error saying the system's not available. But if I do get an answer, it haps absolutely has to be correct. And 1 implementation of that is as a transaction ID in 1 of our financial services customers where they needed a distributed system so they can handle bigger loads, but also they needed the reliability. So should a node go down, the other nodes can take over. And they needed the CP subsystem as that counter or the ID generator so that they had that monotonically
increasing number that could represent a transaction ID and be sure that there is no overlap. Because if you think about it in in any financial services environment where if you have a duplication of a number for a transaction ID, that could be disastrous. So they had some guarantees that they had to to deal with and having this CP subsystem mechanism
along with the associated persistence.
So all of the memory associated with the consistent data is also saved to disk, they had a very reliable way of handling scale and dealing with accurate, consistent data.
Unknown: Another interesting aspect to the in memory computing ecosystem
is some of the recent developments with hardware, particularly
such as NVMe drives that provide very high speed throughput on disk access and the better durability.
And there's also been some recent research with memory stores for being able to have memory that's actually durable.
I'm wondering how that has impacted the overall market for in memory compute or the ways that HASEL cast is able to leverage some of these new hardware capabilities?
Unknown: I think the growth and the evolution of a lot of these NVMe technologies
has certainly allowed companies to take advantage of more data and get faster speeds. And 1 observation in the market is I've seen that some companies pivot their messaging
from more of an in memory model to more of NVMe optimized.
And maybe that's a result of them not truly being in memory because they would have some dependency on spilling to disk, and therefore, the NVMe optimization was a better overall story. But we're always seeing more need for a faster speed, for the ability to do more in less time. And so I think NVMe's will be a great complement to a lot of these in memory technologies like Hazelcast. And as we start exploring other ways that we can take advantage of it, I think it'll be great for the industry. I mean, 1 thing that we do is we have an option where you can store your in memory content to disk
and you save it in an asynchronous manner so that if you need some kind of downtime,
then you can shut down your entire cluster, do some maintenance, and then start it back up. But rather than repopulating
your in memory from data directly from the system of record, you can get it back to the state where it was prior to you shutting down the system and quickly repopulate the memory and and get going again. So a great way to reduce that downtime associated with planned maintenance.
And 1 other technology I'm really excited about is from Intel, their Optane DC persistent memory technology,
which runs in 2 modes, basically. 1 is you can use it as persistent memory, as you would expect, in in a nonvolatile
memory mode. So that's great when you wanna use persistent memory. And again, that fits in with our hot restart store capability so that you can write to memory. And then after you restart the cluster, you can read it quickly back in. But they can also use their Optane technology as an alternative to RAM that's far more cost effective and more scalable. And so that potentially opens up a new world for a lot of companies who previously might thought that in memory processing was out of their reach, so they had to trade off on using disk based systems that represented
much more latency that maybe they were okay with to live with. But having that extra speed and having a more cost effective solution on the hardware side allows them to try to do more things. And, you know, with machine learning and artificial intelligence being really hot these days, a big part of that of those deployments involve doing a lot of exploration. And if you don't have a lot of performance overhead, you don't really have a lot of room to try new things. And that's where I think in memory systems will continue to grow. The notion of trying to do more things, try new experiments all at the same time rather than trying to make a compromise on what's only the best use case that we can run given our resource limitations.
Unknown: You mentioned of capacity is something that's worth digging into as well in terms of how HASEL cast is able to
take the full advantage of the available memory and the overhead that's necessary for the Java heap or things like that, the other things that are resident in memory to make sure that you don't have to deal with things like the out of memory killer on Linux. Also, for cases where you have machines that are entering or exiting the cluster, being able to rebalance across the available nodes and not lose state or lose data in the process.
Unknown: Yeah. A lot of interesting innovations there to address those issues. For 1, the notion of
dealing with garbage collection pauses on a Java system is a long running headache for anyone building large scale systems. And to address that, we've built our own memory manager. So with our enterprise version of our software,
you can
allocate
many gigabytes, up to a 100 gigabytes
of memory onto your HASEL cast managed heap. And so you avoid a lot of the the headaches associated with garbage collection that will impact performance and ongoing operation.
So that's 1 way that you can work around some of the the limitations of the default Java garbage collector.
And Hazelcast is a true distributed system, so it's
designed to deploy across multiple nodes in a cluster. And so the data protection facilities
you expect
are are in place such that there is replication.
If if a node goes down, then the remaining clusters
will
rebalance the data
and accommodate that missing node so that you restore to a state that's fully protective of all your data.
And the CP subsystem that I mentioned earlier also has provisions to be able to protect the data like like the file system. But also, the notion of split brain handling is an important consideration.
So, for example, what if your cluster is partitioned into 2 due to some network outage? That's a very complicated product problem that all the distributed systems need to be able to solve. So it's not as simple as you just keep on running as 2 independent clusters. You need to determine which cluster is gonna be the master cluster based on which has more nodes. And so you have to do a lot of calculations
to determine that and then decide
what that
master cluster can do and what the secondary clusters can do. So that split brain
logic is handled within Hazelcast as well. And we've added recently some some more intelligence around some of these edge cases where a node might appear to be down by some of the cluster, but appears fully available by other members of the cluster. And whenever that happens, and it does happen unfortunately
due to some of the intricacies of of a large scale network,
then you need to be able to handle that properly. And so we have some logic to be able to decide based on what the other nodes are seeing whether that's truly a down node or not. And so you don't create any inconsistency as a result of having the incorrect view of that node.
Unknown: You mentioned earlier too that there are streaming capabilities that you have built on Hazelcast on top of the data grid. And I had seen a mention of the JET project recently, so I was interested in digging more into that as well and some of the ways that it's implemented and the motivation for building that as a streaming engine for in memory compute.
Unknown: Yeah. Hazelcast is
a very high performance distributed
streaming stream processing engine, and so you can definitely compare it to the likes of an Apache Flink or Spark Streaming.
And so a lot of the capabilities that you would expect on a stream of data like windowing, aggregations,
and fast processing, and then sources and syncs that you can easily connect to are there. And 1 of the differences in how we approach JET is how we can tie it together with a separate data store. And, architecturally, JET was built on top of our IMDG.
So with the distributed
computing capabilities
that IMDG provided, it was relatively easy. Relatively is a is a very subjective word, but relatively easy to build JET on top of that where we had the JET jobs that are submitted across the different nodes handling 1 of the many tasks within a pipeline.
And that pipeline is represented by a directed acyclic graph as a means of identifying all the different subtasks and optimizing each of those and distributing them across the cluster.
And running this on top of of IMDG made a lot of sense because a lot of companies
a lot of our customers were were trying to do something similar. They wanted to follow the streaming model of reading in data from a technology like Apache Kafka, doing some processing, and then spitting it out to some sort some sync, whether it's a database or or even INDG
or back to Kafka. And so when we saw that people were trying to do that, we thought we could probably simplify it for them by providing an API that allows this capability. And we actually provide 2 APIs. 1 is for building your own complex data pipeline
in a DAG model. So it's a very low level API. But what's making more sense is our higher level declarative
API where you can specify the different functions or the different actions to take on your data in a more understandable way. So allows you to write less code while still getting most of the advantages
of being able to handle the stream processing.
Unknown: Another interesting element of the work that you're doing at Hazelcast is the fact that the foundational technologies are open source, and so anybody can take them off the shelf and build on top of them. So I'm curious how you manage the governance of those open source projects
and the guiding heuristic that you use for determining what
to build into the open source versions versus your commercial offerings?
Unknown: We absolutely encourage the community to
add new capabilities, to make new suggestions,
and add whatever functionality that will will suit their some of their needs. And we're in the process of adding a whole set of new capabilities
to
serve this this notion of technology convergence, especially in the in memory side where there is this convergence of in memory databases,
in memory data grids, in memory analytics. And so there there are some provisions we're working on for this year to be able to build out that larger scale, more built out comprehensive
environment. But at the same time, that there are some capabilities that we we restrict to the enterprise version. And those tend to be the the capabilities that the open source community doesn't want to build as as far as I've seen throughout my career. So things like the high density memory
that involved our own heap. Now that's certainly a complicated product, and so that's something that we wouldn't necessarily see the community work on. Business continuity is the 2nd big area of where we build in more capabilities to ensure a 24 by 7 operation. And then, of course, security. I like to joke that if you're a good engineer, you'll say,
I can build those capabilities
myself, so I'll take the open source and just work on those capabilities.
So that's what a good engineer would say, but a great engineer would say, I am not gonna risk my career building those things and take the fallback of any problems that occur as a result of trying to build a high available system
or the security. So why not let a company like Hazelcast, with all of their expertise and experience,
build those really critical pieces
and we'll pay for it versus trying to do it ourselves?
Unknown: So for developers who are building on top of Hazelcast
or contributing new functionality to it, what is it actually involved in getting started working with it and the interfaces that are available to them for being able to use as primitives within their own applications?
Unknown: Yeah. So we we follow the standard model. We have our source code available on GitHub, so you're welcome to to,
fork it and make your modifications, add any pull requests, and our team will will take a look at those and add different capabilities.
So
very much like any other open source company that you've seen that has that that availability
and
many many contributors
are familiar with that model and are able to make contributions here and there for the different capabilities.
And like I said, you know, we always welcome more input to this. You know, so, certainly, we don't have
the type
of communities that an Apache project would, but we still have a lot of good contributions.
And it is a fairly technical and and complicated product, and so we encourage anybody who has that background to take a look and see what they can do to try to add more capabilities
on top of, you know, something that we think could potentially be really big as a result of this movement towards higher performance and more in memory focused systems.
Unknown: For people who are building their application in Java, it seems that they would just add the Hazelcast library as a dependency to their Maven or Gradle specification
and just build it as they would with any other Java project. But for people who are building in other languages, what's actually involved in getting a cluster of the Hazelcast data grid set up for being able to interact with it and start developing and experimenting with it?
Unknown: Yeah. Since we supply a a JAR file, you simply run a command line script that will start up Hazelcast
as a server. So the model that you described was embedding it within your application, and then you've got that self contained Hazelcast
application. But you can use the JAR file to run as a server, and so you deploy that across your servers in a cluster.
And then we provide clients that can talk to
that server, to that cluster,
and be able to use it as an in memory data store so that you can build applications on the clients that are running separately
from
the HASEL CAS cluster, but still having
similar functionality.
Unknown: For people who are building and maintaining a cluster of HASEL CAS servers, what are some of the operational considerations that they should be aware of or potential edge cases that they should guard against?
Unknown: A lot has to do with data scale. So if you're looking at
a persistent
storage mechanism that's dealing with,
say, 100 of terabytes or maybe even petabytes of data. We're not gonna try to say, let's see if that works for us. This is all about the operational aspects of your data, so trying to process it at a very high speed. So definitely think about HASEL cast as another component in a stack rather than necessarily a replacement. And so we're very good at complementing
relational databases, NoSQL databases,
you know, streaming environments. So if you think of us as a new set of capabilities versus a replacement,
that's where you should really focus on in terms of how we fit in.
Unknown: In terms of the ways that you've seen Hazelcast being used, what what are some of the most interesting
Unknown: or innovative or unexpected projects that you've seen built with it? Yeah. I think there's a a pattern emerging that is is very interesting in terms of how JET and IMDG are being used together. So notion of the kappa architecture
is 1 that was created by Jay Krebs, the CEO of Confluent, and he talked about how you have a
streaming database like Kafka and you read in data, do some processing, potentially some indexing, and then spit it out to a database or some other store for analytics.
It's a very simple model, but it's extremely powerful. And a lot of people might think of the Kappa architecture
as a real time system only,
when in fact, 1 of the provisions within that architecture is that if there's any mistake that's made in your code or if you wanna make any changes, you can go back to Kafka and replay that data stream and process it again. And that description sounds very much like batch processing.
And so what we've discovered for some use cases that we're working with customers on,
what if you could do that batch processing in a very fast way so that you're essentially
mimicking a real time system and that you're essentially creating indexes and aggregations
on demand. And in fact, 1 of the really innovative and almost crazy implementations that I've seen was from a very big technology company who's a customer of ours. And I don't think we I can talk about too much of the details, but the solution sounds very simple in terms of of what it's providing. It's essentially a recommendation engine
for a certain segment, certain industry. And so business people will log into their system, run a query, and get a recommendation
based on their query. And so you think that data warehouse might be able to provide that the response, but but it can't because there's some processing and some artificial intelligence built into their architecture that needs to be done. So you might think that they would add Apache Spark and get that going, and so now you have a data warehouse complemented with Apache Spark, and that would provide you the answer. And it turns out
that they've done some testing, and a configuration like that would take many hours, like over 10 hours to give you a response.
And if you think about how people do analytics and running queries, you they typically want to submit follow-up queries to further refine the answers. And so if you're limited to 1 query per day, essentially, the the 10 hour response time isn't going to work. And so they did a lot of research, and they determined that if they had a fast
stream processing engine,
they could be able to do all types of calculations on demand so that they could get an answer in a matter of minutes. And so the the underlying foundation is, in fact, the kappa architecture where they're not necessarily storing all the data within the recommendation engine. They have their repositories and their systems of record. They'll read in data and only the appropriate data based on the query, do a lot of processing, run through a lot of AI algorithms,
save some data, do some more processing. So at any given time, they could be running hundreds of Jet jobs within their system. And all of that processing can give them a comprehensive
recommendations list after a few minutes, which is well within the range of what their customers would expect. So being able this this notion of on demand indexing is, I think, going to be extremely powerful in the near future. 1 other use case that I found interesting
was this idea of trade monitoring within capital markets
for the back office folks. So the front office folks, the traders will have these expensive high end systems that provide real time analysis, and that's expected because they're the revenue generators. But what about the finance people? What about the regulatory compliance people or the risk people? They don't necessarily have the same amount of budgets. So how can they get a near real time system to be able to do analytics? So if there's something strange going on in the market, they wanna be able to assess what's their risk, what's their position within the context of the rest of the market. What if they could just read all the relevant data for a given query, like what's going on with, say, IBM stock? Why is it rising so quickly? Then they can get that data, process it really quickly, index it, and then do some additional queries that are stored in IMDG.
So, again, the underlying model is that kappa architecture but used for an on demand
analytics type of scenario.
Unknown: As somebody who has been working with the HASEL Cast product and supporting customers, what are some of the most interesting or unexpected or challenging lessons that you've learned while working with HASEL cast and with the in memory computing ecosystem?
Unknown: I think 1 of the challenges that we faced is just the limits in terms of how people view what in memory computing can do. And I think a a great example
of what people should be thinking about is what is that additional thing I could be doing? And so if I can go back to the fraud detection model, we have 1 customer
who,
because they recognized that they could gain a lot more revenue and would cut a lot of costs associated with fraud, they want to get the most accurate fraud detection system possible. And
using Hazelcast
allowed them to try new types of algorithms
simultaneously to come up with a composite score that represented a better prediction
of what transactions could be fraudulent.
Now most people wouldn't think I need faster speed because I'm gonna try a lot of different things. But since they did, they were able to get some real value there. And so I think my recommendation to a lot of folks is don't think in terms of what I have to do now, but think in terms of what else I could be doing, and that's where a lot of the performance will provide additional benefits. Being able to do more things, and it's not necessarily about only trying to meet your specific SLAs.
And I I think a lot of people get trapped in thinking that's what their goal is, only trying to fit within the time frame that they're given. But rather, they should be thinking about what else that they can do as a result of investing in in memory.
Unknown: For people who are considering in memory compute or taking a look at the Hazelcast Grid or a JET product, what are the cases where that's the wrong choice?
Unknown: Definitely for IMDG. If you're currently thinking about using it as some type of system of record, that that probably isn't the greatest choice. I would expect, even if you think that you don't have enough data
that it'll overrun
your memory
availability,
you probably will be in an environment where that data will continue to grow. So using it purely as a storage mechanism is probably not a great choice. And in fact, there are NoSQL databases out there where if you want to use them as a basic cache, you could and you wouldn't get the same type of latency. But for the type of scale of data you might have, that might work. So I think basic caching is not a terrible choice. It's just not ideal. But at the same time, think about what else you could be doing on top of caching, like the distributed computing, like the stream processing so that you can grow out your architecture to do far more than you initially imagine.
Unknown: And as you continue to
build on top of Hazelcast and work with customers and explore its capabilities, What do you have in store for the future of the product and the business?
Unknown: Yeah. On the business side, we have some great opportunities working with some very big partners. So I had mentioned Intel earlier with their Optane technology, and so we're certified to run on them. And they're really excited to work with us as we are with them on trying to tell the story of how to use these newer storage
technologies
to a greater extent and be able to get the performance you need for some of your more advanced systems. So we're we're doing some work with them, and I think that relationship will grow to new levels for us. We've also recently partnered with IBM and have closed a huge deal jointly where we fit into their technology known as CloudPAX.
IBM is taking a very strong push towards cloud native technologies,
and their cloud packs are software packages
that have a variety of technologies embedded so that you can build out a cloud native environment
either in the public cloud or on premises. So you get that same agility that you would expect from any cloud deployment. We're working closely with them, and we're embedded and OEM ed as part of their cloud packs.
So we expect that to be a big story in terms of getting the word out of in memory.
And as I alluded to earlier, we're we're making a few changes to our architecture to be able to expand in terms of capabilities. So perhaps 1 day, people will think of us as more than just a data grid, which means that we could be that converged
technology that handles
system of record type of data for longer term storage.
Unknown: Are there any other aspects of the Hazelcast product or the in memory computing space or the work that you're doing at HASELCAST that we didn't discuss that you'd like to cover before we close out the show?
Unknown: Yeah. 1 thing I like talking about, and and this has been resonating really well, is the fact that in memory goes together with stream processing extremely well. And if you think about these event driven architectures today
where you're getting data from, say, in an IoT environment
where the data might be fairly sparse in terms of what you get, you might get a a machine ID and you might get some
device readings
and not much more than that. But for the purpose of analytics, you need a little bit more information about the machine and about all the different readings that you're getting, and that requires a lookup. And the fact that JET is based on top of IMDG means that you get this in memory store for free. And the fact that they're working together,
being collocated
within the nodes across a cluster,
you get that fast lookup for the absolute fastest, lowest latency. And I think that's 1 of the differences that we're providing in the market, but
there are other technologies
that have strengths in other areas where
scale might be the important aspect as part of their data storage or certain types of libraries that are available.
So
I think depending on what your needs are, a lot of cases, there'll be technologies that you commonly use that'll be appropriate. But for some of these newer use cases, we're seeing that, you know, in memory and streaming working together
is a very powerful combination,
especially if I can comment if I can add to that, including at the edge where there are a lot of restrictions around how much processing power, how much
physical space you have, how much access you have to the computing technology for the purposes of maintenance.
So having a lightweight but powerful streaming and in memory system running on the edge as well as in the cloud provides that edge cloud connectivity for processing data, you know, where it's created while also providing that large scale analysis across all of the different data sources that you have.
Unknown: Well, for anybody who wants to follow along with the work that you're doing or get in touch, I'll have you add your preferred contact information to the show notes. And as a final question, I would just like to get your perspective on what you see as being the biggest gap in the tooling or technology that's available for data management today.
Unknown: I think 1 of the biggest gaps today is some of the technologies that allow
companies to expand
beyond their existing architectures. So, certainly, there
are ETL tools. There are data integration tools.
There are new sorts of databases
and data management platforms that you can add altogether. But for the most part, connecting them all together has been a big challenge.
And I think 1 approach that can help alleviate that is using some some of these newer technologies,
1 of which Gartner refers to as a digital integration hub, which acts as a data layer that
incorporates data from a variety of sources
into 1 common platform that exposes an API for many
back end processing. So any type of ETL you wanna do from systems of records
or just large scale storage, whereas this digital integration hub tends to be more front facing, forward facing in terms of closer to the consumers
and the application users.
And
deploying these types of systems
that we've seen quite a bit, especially in in banks for the purposes of higher speed accesses and and
better responsiveness for customer
satisfaction.
I think that has been underserved so far. So I think
building more focus putting more focus on
these digital integration hubs, I think, will represent a next wave of technology
for managing data for this, you know, increasingly distributed world.
Unknown: Thank you very much for taking the time today to join me and share the work that you're doing at Hazelcast and the insights that you've got into the use cases for in memory compute and storage. It's definitely a very interesting problem space, and it's exciting to see some of the ways that it can complement some of the traditional architectures. So definitely look forward to seeing the ways that that evolves, and I appreciate all of your time and effort on helping to drive that forward. So thank you again for your time, and I hope you have a good rest of your day. Thank you very much, Tobias. It was great talking to you.
Listening. Don't forget to check out our other show, podcast.init@pythonpodcast.com
to learn about the Python language, its community, and the innovative ways it is being used.
And visit the site at dataengineeringpodcast.com
to subscribe to the show, sign up for the mailing list, and read the show notes. If you've learned something or tried out a project from the show, then tell us about it. Email hosts at data engineering podcast.com
with your story. And to help other people find the show, please leave a review on Itunes and tell your friends and coworkers.