MARK MIRCHANDANI: Manufacturing creates a lot more
than just physical goods.
It also creates a tremendous amount of data.
Join us as we talk to Oden technologies
about how they built a system to help manufacturers
analyze their data using IoT on this episode of "Stack Chat."
John, thanks so much for joining us today.
Tell us a little bit more about what Oden Technologies does.
JOHN TUREK: Mark, thanks for hosting me today Oden
is a company that focuses on the internet of things
for the industrial sector with the specific mission
of improving the efficiency of the manufacturing process.
For example, we have customers that
produce $500 million to $1 billion worth of product a year
with high scrap rates.
And by leveraging the Oden platform,
they're able to reduce, as one factor, the amount of scrap
material that they create.
In one case, we've had a customer
that has managed to reduce their scrap
levels from 23% down to 9% after implementing the Oden solution.
MARK MIRCHANDANI: That's great.
So it kind of captures a lot of data,
and then can somehow relay that back to the customers.
What does that actual architecture look like?
JOHN TUREK: A big part of our architecture
is around managing the data that we've collected from the users
and making that data available and actionable.
The starting point for all of this
is, of course, the collection of data.
We start with a device that sits on the factory floor, which
collects data through the PLCs.
That data then gets sent up to the cloud using Google IoT.
We pull the data off of Google IoT using Pub/Sub.
We process that data in real-time.
We run whatever learning models we have against the data.
We also move the data over into a time series
database that sits on top of Bigtable,
as well as into BigQuery.
In addition to collecting data from the machinery,
we also collect data from other sources,
for example, the operators through an operator interface
that we have on the factory floor.
If a machine is down or there's a production problem,
the operator will be able to add data or add annotations
that allows us to then go back and do further analysis.
And that comes back in through the cloud as well.
Much of that data then gets stored into Google SQL.
And we can then pull that data out as well using BigQuery.
MARK MIRCHANDANI: If you could kind of go back
to when you started, were there any decisions
that you think you might change?
JOHN TUREK: In hindsight, there are always decisions
that we would make differently.
One example is our choice of to use a graph
database to represent the entities that
sit on the factory floor.
At the time that the decision was made,
the observation was that the factory floor does not
follow a strictly hierarchical model
and the way that you want to view data on the factory floor
does not follow a strictly hierarchical model.
You will sometimes want to organize your data
by factory line.
You will sometimes want to organize your data
by, for example, type of machine.
We decided to use a graph database at the time.
We thought that it would accelerate our development
efforts, and it did.
However, as we have scaled up, we
have started to run into the limitations of that graph,
of the graph database.
One of the areas of concern is the fact
that graph databases tend to follow--
be schema-less.
And so what we have found is that sometimes engineers
will introduce new features.
And because there isn't a lot of structure,
by introducing new features, assumptions
that are inherent in the scheme-less architecture
end up creating issues down the road.
A second choice that we made was to use an abstraction layer
on top of Bigtable to support our time series database.
The choice of Bigtable has been great.
Bigtable scales wonderfully.
And more recently, Google has added replication capabilities.
That has been highly beneficial to our redundancy strategy.
So we feel that we're much more reliable.
However, at the time, we had a choice
between a few different abstraction layers.
And the abstraction layer that we chose
has reached somewhat of a dead end in the public community,
which means that it is not being actively developed or worked
on by others.
And so features that were missing at the time
remain missing, while other abstraction layers
have moved forward.
If we were to start again today, we would probably use TSDB.
And I fully expect that over the next 12 to 18 months,
we will be making the move to using TSDB as our abstraction
layer.
MARK MIRCHANDANI: Thanks so much for coming in and telling us
about how you kind of built this architecture to scale.
JOHN TUREK: Thank you for hosting me today.
And I really enjoyed our chat.
MARK MIRCHANDANI: Try setting up your own data pipeline
by using this hands-on solution that walks through using
Dataflow and BigQuery.
[MUSIC PLAYING]
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]