MARK MIRCHANDANI: Understanding the sentiment
and meaning behind language requires an architecture
that can handle a lot of data.
Join us as we talk to Mito.ai about how
they handle their data processing on this episode
of "Stack Chat."
Thank you so much for joining us today.
Can you tell us a little bit more about Mito.ai
and what you do?
MARIT RODEVAND: Yeah, so we help large corporations increase
sales by finding insights and sales triggers
about their existing customers and potential prospects,
and we do this by analyzing large amounts
of unstructured data on the internet.
MARK MIRCHANDANI: So what's the technology
behind how you make your AI?
MARIT RODEVAND: We need to do a lot of things
with all of this information.
The first thing is detecting-- or separating apple from apple.
People think that's trivial, but it's actually quite hard.
And we do it in a language-agnostic manner,
which means that, through our data-processing pipeline,
we can process any language, and being
able to do this for all very difficult cases, not just apple
and apple, but similar ones in Norwegian and Swedish
and German.
And that's also what makes our technology unique,
this combination of having a language-agnostic knowledge
graph, and on top of that one, building a lot
of machine learning modules to solve all
these really hard questions.
And we are using Apache Spark as our main data processing
platform, which Patrick can talk more in detail about.
PATRICK SKJENNUM: So once the Spark Streaming application
has pulled all of its content from Pub/Sub,
it processes it through our NLP pipeline.
This is where we do the entity extraction,
we cluster the content, and we interact
with all of these machine learning models
that we have trained.
These models, they are trained in Apache Spark
as well, in a batch processing unit,
which runs on ephemeral clusters with preemptive nodes, which
is awesome, because then we can just spin up 1,000 nodes,
and we can train a really expensive model
for a short time and not have to leave them running.
And once we have done that, the last step
in the stream of processing pipeline
is to index the data back into the knowledge graph.
And for that, we're using Elasticsearch,
which is also a really awesome piece of software.
It's got really great searching capabilities, so
you we search for "apples" and get hits for "apple,"
and that sort of thing.
And once the data is indexed into Elasticsearch,
it is made searchable from our APIs, which run in GraphQL.
These APIs run in a microservice architecture in Kubernetes.
So that is kind of the ecosystem that
interacts with all of the data that
is processed in Apache Spark.
MARIT RODEVAND: We make this API accessible to our customers,
because that's how they integrate, also,
with our service, taking data from us
and into their internal CRM and prospecting systems.
And we've even open-sourced a programming language in order
to customize APIs in GraphQL very easily.
So people should check that out if they want to do that.
MARK MIRCHANDANI: So obviously, over the last couple of years,
you've learned a ton about your architecture.
If you could go back and start again,
what would you take with you that you felt
was the most important thing?
PATRICK SKJENNUM: One takeaway here
is that we're using Apache Spark quite heavily,
and that means that we have to configure Apache Spark
clusters.
And if I would get a dollar for every hour
I spend configuring Spark clusters,
I would be a rich man.
Configuring Spark clusters is not
something that should be underestimated.
You need to configure the topology,
you need to configure how many nodes you should have,
and all that sort of things.
What you do get from Spark though
is all of these machine learning libraries and a lot
of utilities in this ecosystem.
But we could have utilized those either way,
by using other kinds of systems, either in Python or likewise.
So one obvious thing that we, perhaps, should consider more
is utilizing managed services like Dataflow,
where you can use this managed service that
can do all of the transformations,
and then you can use external APIs to do the machine learning
stuff.
And then you would also decouple the system
and have the data processing in one place and the machine
learning contained in other services.
So when we started off, we had a single messaging queue
where we published all of the content.
This meant that if either that queue went down
or some other service interacting with a queue
went down, we were clogging the queue.
We would have a backlog or a lot of things that
would have to be processed.
And that wasn't sustainable, at least not when, the customers,
they require that the delay through our system
is as low as possible.
So as a solution to that, we swapped over to Pub/Sub
and created this priority concept
where you, using machine learning,
can determine which priority queue
should this content be put on.
And that is based on feedback from our customers,
either directly through our API, where
the customers can choose what is relevant
and what is not relevant.
And based on this, we can infer what content matters the most
to our customers.
And based on that, we can utilize
this to route the content through the right queues, such
that, for instance, a stock market update is
put on the high-priority queue because we
know that our customers would want that as soon as possible.
MARK MIRCHANDANI: Thank you so much for joining us today.
MARIT RODEVAND: Thanks for having us.
PATRICK SKJENNUM: Yeah, thanks for having us.
MARK MIRCHANDANI: Get started with Dataflow
using these templates and tutorials.
Thanks for watching, and make sure to subscribe
for more great Google Cloud Platform content.
We'll see you next time on "Stack Chat."
[MUSIC PLAYING]