[MUSIC]
>> I'm Cheng from China.
I'm actually, working in AI Platform Team.
I'm the Program Manager of Anomaly Detector.
In our previous AI shows,
we have talked about Anomaly Detector on the Cloud,
and Anomaly Detector On-prem as Containers,
and you know that both of them are available to you.
But now, I'm going to introduce to you some more interesting tips.
Actually, three tips to help you build
your Anomaly Detection solution
that's going to be used in production.
We are going to start with the first step as Batch vs Streaming.
So Anomaly Detector APIs,
we have provided a two functionalities or endpoints,
and namely /entire for batch scenarios,
and /last for streaming scenarios respectively.
When you want to detect all anomalies,
every anomaly from the entire data
set that you've sent in a single API call,
a single HTTP call,
/entire is what you need as it will create
a single statistical model and
apply that to every measure point in the data set.
On the other hand, when you
want to detect anomalies from a stream of data,
/last is [inaudible] as it returns only when the last data point,
whether the last data point in
your [inaudible] is anomalous or not.
In general, entire is for Batch and last is for Streaming.
However, /entire is a bit slower than /last,
so customers would prefer to use
the /entire in the cases when latency in seconds is not an issue.
For example, historical data analysis or you
want to take a preview the data set,
what's the pattern of the data is or there are
some business KPIs with really large granularity,
like hours, days, or even weeks,
you can go with /entire,
and it will tell you-all anomalies.
Now, /last is most suitable for real-time monitoring cases.
For example, IoT metrics or
cases when the data is in a streaming session,
although latency is not a concern.
For example, business metrics in
production that constantly updates with new data points.
So that is still streaming data,
but it's not the fine granularity like some IoT data.
Anyway, those are all suitable for the /last API.
I'm going to show you some examples.
So these are the examples of endpoints because
the service so far is still in public preview as we speak,
and we will host
the service and the API Service more Azure regions.
But now, you have less westus2 and westeurope.
These are the different endpoints for those Azure regions.
As you can see in the table,
I've highlighted the /entire and the /last.
Now, when more Azure regions will come,
the endpoint for the region will change.
Apart from those Azure regions,
we also have Containers.
So with Containers, you are able to spin up
the Anomaly Detector Containers with the local host IP address.
It could be your local host or a host
that's sitting side-by-side with their production environment.
Anyway, you'll get an API endpoint with your local host address.
Then the rest of the URL,
just resemble the Cloud Endpoint.
Yeah, so that's it.
That's the first tip, the /last vs the /entire.
/entire for the batch scenario
while the /last is for the streaming scenario.
That's pretty straightforward.
Now, let's go to the second tip.
This is about streaming.
We have the last /endpoint,
and that is designed exactly for streaming scenarios,
no matter where your streaming data is coming from,
Event Hubs, IoT Hub, or Kafka.
You could write code to load that data
in sliding windows and send over HTTP
requests to Anomaly Detector APIs
to detect anomalies in a streaming session.
However, from time to time,
some developers who start to call you with Anomaly Detector APIs,
get really confused about the /last API.
They will find it a bit difficult to
connect the API with the streaming data source.
In order to build a streaming anomaly detection solution
with Anomaly Detector,
Developers and Architects, they really
need to keep two important things in mind.
Firstly, it's about the caller
because with the service as REST APIs,
what you need is really
an application that's play the role as caller,
to load, to cache,
and to prepare the time series data,
and make the HTTP calls with the data that you've prepared.
This application could be implemented with.NET, Python.
Basically, any programming language that it
can load data from your streaming source,
Event Hub, etc, and make an HTTP call.
The compute infrastructure for
your caller application for
Data Prep application could be Azure Notebooks,
Jupyter notebooks or Azure Databricks,
Azure Functions or even some infrastructure as
a service solution only your
On-prem infrastructure and also Power BI.
I'd like to highlight this,
Power BI can also do this.
I mean, Power BI is not only a visualization tool,
it can [inaudible] and it will call
Anomaly Detector APIs with customized queries.
The second thing that you'd like
to keep in mind is about sliding window.
It's basically a part of
the data preparation because I'd like to mention,
I think is in the previous slide,
you see the endpoint,
there's 1.0, which means,
this is the first version.
This is 1.0 version of APIs.
This version is stateless.
It means, every API request is independent from each other.
If you call the API with your data,
and then you make a second call,
there's correlation between the two API calls.
With that, the /last API will pass
a window of data points from your request.
It runs detection only on
that data set that you send over each individual request.
You cannot send over only one single data point,
even if you have already sent over a lot of data in prior to that.
Therefore, you need to create
a sliding window over your streaming data,
and move the sliding window as new data streams in.
The sliding window could be sent over the API Endpoint
over HTTP at the same cartons with your data granularity.
I'm going to show you a really cool and interesting demo,
that's going to explain much better about
how the sliding window works.
This is basically a demo that you can
access from internet aka.ms/addemo,
and you will be able to play with it.
Now, the first thing that you need to grab from
Azure pothole is that API key and endpoint.
If you create your Anomaly Detector resource on westus,
you have this, otherwise, there's westeu.
Input your key anomaly detector resource here.
Now, you are ready to play with it.
We can actually play with this sample.
So this is the last API.
It's about streaming. Now, I'm going to run it first.
As you can see, on
the right side in the current end request input,
there's the data that's being sent over HTTP.
On the left side,
there's this gray shade which is moving,
this is my favorite part.
It is the sliding window of the data
that's being sent over HTTP to the API Endpoint.
The response that's on the bottom on
the right side is basically telling you
whether the last data point in this API call is anomalous or not,
together with something like upper margin, lower margin.
You can play with it, tune the sensitivity,
and change some next detecting window.
It will actually change the size of the shade.
So this is very intuitive,
and we'll show you how streaming works with
Anomaly detector, the slash API.
Lets dive into the code.
Here's some snippet of Python code that gives
you an overview of how to create such an application.
As you can see the second function,
the stream detection function,
it really creates a sliding window with maximum size,
this predefined sliding window size.
So this is predefined.
Then call the other function detect last,
which will call the endpoint slash endpoint to detect anomaly.
Back to this function,
you will see a loop here,
this loop is how you build a demo.
It moves to the sliding window from left to right.
In production applications, in
real life what you want to do is increment
something like scheduled job
to move the slide window instead of just a rope, right?
Because it should move
when new data streams in in your data granularity.
On the right side, this is
output that you also see in the previous demo.
Now, the remaining question is,
How do we actually determine
the number of data points that we should
send over to the API endpoint over one single HTTP request?
In the streaming case,
What is the best deciding window size?
In the batch scenarios,
How many data points should be sent when your data
has different granularity and patterns?
We have the third tip,
is going to address that.
Tip number three, it's about data preparation,
because of performance and accuracy of
anomaly detection results really
can be impacted by how your data is prepared,
how your parameters, although there are only
one that you see previously,
how that parameter is used,
and the number of data points in your API request.
So starting with some basic requirements that your API,
the anomaly data had a API.
It requires time-series data formatted into JSON request object.
The minimum number of data points that it accepts is
12 and the maximum is 8,640 points.
You're data point that's sent over to the API must have
a valid UTC timestamp and a numerical value,
and that defines a time series.
Then with the basic requirements met how to make it work better.
If your data is evenly
distributed that's good because that's what the API needs.
If your data is randomly distributed over
timeline as you can see in this slide,
this is evenly distributed,
and these are the cases when data is not evenly distributed.
The left one is like a random distribution,
and the right one is more like missing data point.
When data is randomly distributed,
you should aggregate it by a unit of time such as per minute,
per hour, or daily so that it will be evenly distributed.
If there are missing data points,
well it's common, there are sometimes missing data point.
What you need to do is to have
a statistic algorithm here to fill the gaps.
I would just say normally missing
less than 10 percent of the expected number of data points,
is not a big issue,
it will not have a negative impact on the results.
While in other cases, if
the missing data points are more than 10 percent,
you can fill the gap based on it's characteristics
like substituting data points from an earlier period,
or linear interpolation, or maybe a moving average.
Anyway the goal is to make it evenly distributed.
Finally, if your data have seasonal patterns,
normally we call it seasonality,
so if your data has seasonality,
which means the pattern actually occurs
at regular intervals like what do you see on this chart,
you can actually improve the accuracy and the performance.
One way to do that is to specify
a period that this is another parameter that's hidden,
and you don't normally use it.
But with seasonality, you can specify
this period perimeter when you construct your additional request.
It can actually reduce the latency by up to 50 percent.
This period is basically an integer,
and it specifies roughly how many
data points the PAM series takes to repeat a pattern.
Let me give you an example,
if you have a time series data with
weekly pattern and one data point per day,
so it means seven data points per week,
and there's a seasonality occurs every week,
then the period could be specified as seven.
If the weekly pattern
is with some time-series with like one point per hour,
then you want to have your period as seven by 24.
This parameter is actually optional.
So if you're unsure of the data patterns,
unsure about the seasonality,
you'd have to specify it.
Another practice here for best results is,
if you provide full periods
worth of data points plus additional one,
that it will make the API worked
better with better accuracy; for example,
if you have hourly data with
weekly pattern as described previously,
you could provide 673 data points in your request body.
So which is seven by 24 by
four plus one extra data point, that's it.
Those are straight tips of using anomaly detector.
If you want to build a production environment,
you may want to check that out.
Also with anomaly detector shaped as API service,
and we have these quick links for you.
So firstly, go to
aka.ms/AnomalyDetector or search on Bing to check out
the overview of the API service,
or you can join our community where
there are our engineering group,
as well as other customers,
and the Microsoft partners,
and the Microsoft teams
by going to aka.ms/adAdvisorsJoin,
and to get the containers,
you can go to
aka.ms/adContainer to apply for
the container credentials.
Thank you for watching.
[MUSIC]