Merge pull request #42 from dengyaomo/main

Add sql demo for forecast model and multi-metric anomaly detection

.vitepress/siderbars/getSqldemoSider.js

@@ -133,6 +133,14 @@ function getSidebar() {
           text: '在阿里云日志服务轻松落地您的AI模型服务',
           link: '/sqldemo/deploy_ai_model_with_alilog_service',
         },
+        {
+          text: '阿里云日志服务的傻瓜式极易预测模型',
+          link: '/sqldemo/forecast',
+        },
+        {
+          text: '阿里云日志服务的多指标综合异常检测',
+          link: '/sqldemo/multi_metric_anomaly_detection',
+        },
         {
           text: '实现大规模预测模型和服务',
           link: '/sqldemo/实现大规模预测模型和服务',

src/sqldemo/forecast.md

@@ -0,0 +1,85 @@
+# 阿里云日志服务的傻瓜式极易预测模型
+
+## 什么时候您需要预测服务？
+
+预测的作用是帮助提前规划，减少资源消耗，降低成本，未雨绸缪。
+
+最简单的例子，就是天气预报。提前几天预测台风的到来，可以提前做好准备，降低损失，这样不会措手不及。提前预测是否会下雨，可以帮助管理出行计划。
+
+在企业生产里，产品的需求是波动的，有了对产品将来一段时间的需求比较准确的预测，可以帮助合理提前安排采购计划，生产计划，方便人员排班部署。否则，会出现产品过剩、库存积压、资金不能通畅流转；或者用户想买产品而买不到，选择竞争对手的产品，浪费机会成本，降低自己的竞争力。这是因为采购或者生产都需要时间的，在物流供应链里的术语叫提前期(lead time)。如果采购、运输或者生产不需要时间，能够瞬间完成，这时候是不需要提前预测的。
+
+在IT系统自动化领域里，用户的请求是波动的，用户的请求量决定了资源的消耗量。资源的调度也是需要时间的，比如为了实现服务的弹性伸缩，自动租用和释放虚拟计算机来满足高峰期的用户的请求和减少低谷期的资源的消耗。由于租用、启动VM，安装特定的软件包等等都需要时间，提前预测好用户的请求量，就能帮助提前规划资源调度。否则，如果资源不足，用户的请求可能没法及时地响应，超时出错，用户体检非常差。如果资源过多，造成资源浪费。有了准确的预测，就能帮助在正确的时间准备正确数量的资源。
+
+总之，在企业生产或者计算机服务里，用户的需求是外部的，生产和资源调度等是企业内部的(Logistics)，内部的可控性通常比外部的可控性要高很多，预测能够帮忙连接企业外部需求和内部的组织管理，让内部生产和组织平滑运作，降低成本，提升用户体验。
+
+
+## 阿里云日志服务的AI预测服务
+
+阿里云日志服务提供的预测服务，不同于其他的预测服务，阿里云日志存储提供的AI预测服务把所有数学建模的细节都包起来，对用户没有任何数学建模知识上的任何要求，只要求会点SQL，把数据表对应的列填到指定的函数参数就可以了。这样可以降低AI预测模型的使用门槛，让您的AI预测服务更容易落地。
+
+另外，阿里云日志服务提供的预测服务不仅可以用于短期的预测，还可以比较准确地对远期的情况进行预测。
+
+对于预测服务，我们直接用图来描述吧。我们提供了三个预测效果的可视化展示，参考下面的三个图。其中蓝色的曲线表示到目前为止的最近一段时间的历史数据，红色的曲线是模型预测出来的未来的时间点的指标数值。对三个指标数据组成的时间序列数据分别进行预测，分别对预测了接下来的1440个时间点(分钟)的指标数值。其他的大部分预测模型对近期的几个时间点预测比较准确，如果往前预测很多个时间点，预测效果就变得很差了。但是，可以看到阿里云存储日志服务在往前预测超过上千的时间点的情况下，还能保持比较高的准确度。
+
+![时间序列预测范例一](/img/src/sqldemo/forecast/05-time-series-prediction-01.png)
+<p>图1. 时间序列预测范例一</p>
+
+![时间序列预测范例二](/img/src/sqldemo/forecast/06-time-series-prediction-02.png)
+<p>图2. 时间序列预测范例二</p>
+
+![时间序列预测范例三](/img/src/sqldemo/forecast/07-time-series-prediction-03.png)
+<p>图3. 时间序列预测范例三</p>
+
+指标数据通常是以高维二维表指标数据的形式保存的，参考下面的高维指标数据。这一类的指标数据都有一个时间维度列、一个或者多个指标数值列、一个或者多个上下文维度列。
+
+_高维指标数据例子: metric_data_table_
+
+|cluster|server|metric_name|time_period|metric_value|
+|--|--|--|--|--|
+|Cluster-A01|Server-01|request_count|2024-01-01 00:00:00|180|
+|Cluster-A01|Server-01|request_count|2024-01-01 00:01:00|200|
+|Cluster-A01|Server-01|request_count|2024-01-01 00:06:00|150|
+|Cluster-A01|Server-01|request_count|2024-01-01 00:08:00|175|
+|Cluster-A01|...|...|...|...|
+|Cluster-A01|Server-01|network_ingress|2024-01-01 00:00:00|2000000000|
+|Cluster-A01|Server-01|network_ingress|2024-01-01 00:01:00|2500000000|
+|Cluster-A01|Server-01|network_ingress|2024-01-01 00:02:00|1200000000|
+|...|...|...|...|...|
+
+在这个例子的数据中，每个cluster的每个server的每个metric_name的time_period和metric_value的两个字段构成一个时间序列。可以使用阿里云日志服务中的ts_forecast(…)函数按照下面的SQL语句来对每一个cluster的每个server的每个metric_name的指标数据分别进行预测。
+
+```sql
+select cluster,
+    server,
+    metric_name,
+    ts_forecast(
+      array_agg(time_period),  --时间序列中的时间数据拼成的数组
+      array_agg(metric_value), --时间序列中的指标数值列拼成的数组
+      '2024-01-01 00:00:00',   -- 时间序列历史数据开始的时间点(该点有历史数据)以便自动填充数据
+      '2024-01-08 00:00:00',   -- 时间序列历史数据结束的时间点(第一个时间点没有历史数据)以便自动填充数据
+      '2024-01-10 00:00:00',   -- 指定要预测的结束的时间点(不包含该点)
+      '1 minute'               -- 指定时间序列的相邻点的时间间隔以方便自动填充数据
+    ) as forecast_outcome
+from metric_data_table
+where time_period >= '2024-01-01 00:00:00'  -- 指定历史数据开始的时间点
+  and time_period < '2024-01-08 00:00:00'   -- 指定历史数据结束的时间点
+group by cluster, server, metric_name
+
+```
+
+ts_forecast(…)函数的参数规范参考这个例子的注释部分。这个例子是把2024-01-01 00:00到2024-01-07 23:59的分钟级别的数据交给ts_forecast(…)函数，让其帮忙预测从2024-01-08 00:00一直到2024-01-09 23:59的分钟级别的2880个时间点的指标的数值。
+
+这里的每个cluster的每个server的每个metric_name的预测是相互独立的，阿里云日志服务能够自动地把预测计算分发到后台成百上千台计算机进行分布式并行计算，因此，计算速度会非常快。
+
+另外，用户在存储数据的时候，为了节省空间，通常会把数据值为0的数据点移除。ts_forecast(…)函数能够帮我们把这些数据自动地填补回来，帮助用户在预测时减少了数据预处理的工作量。
+
+因此，阿里云日志服务的预测服务的接口非常简单，不需要数学建模的知识，计算速度快。
+
+## 阿里云日志服务中的ScheduledSQL——让AI模型计算成为自动计算服务
+
+之前介绍的阿里云日志服务的AI计算，是以SQL的形式介绍的。这仅仅是ad hoc的分析。我们可以结合阿里云日志服务中的ScheduledSQL的功能把AI计算形成定期计算的服务。要在阿里云日志服务生成持续执行的预测计算任务，在查询分析的界面上提供了一个 “定时保存分析结果”的按钮，点击这个按钮，参考下图，之后会弹出窗口，然后在这个窗口上配置这个定时执行的AI计算就可以了。
+
+![日志服务中的定时SQL服务](/img/src/sqldemo/forecast/14-sls-scheduled-sql.png)
+<p>图4. 日志服务中的定时SQL服务</p>
+
+ScheduledSQL任务的配置很直观。ScheduledSQL计算任务会定时把预测计算的SQL所产生的计算结果写入到另外一个日志库，如果这个目标日志库还不存在，需要先创建。另外要配置的是调度时间间隔和SQL读取的数据窗口等。

src/sqldemo/home.md

@@ -54,4 +54,6 @@
 | 案例名称                                                                                                                                       | 描述                        |
 | ---------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- |
 | [在阿里云日志服务轻松落地您的AI模型服务](./deploy_ai_model_with_alilog_service.md) | 提供了一系列的AI应用的实践范例，帮助阿里云日志服务用户快速落地AI模型服务。 |
+| [阿里云日志服务的傻瓜式极易预测模型](./forecast.md) | 介绍把模型细节都包起来低使用门槛的但高准确度的预测模型和服务创建。 |
+| [阿里云日志服务的多指标综合异常检测](./multi_metric_anomaly_detection.md) | 介绍如何对多个指标变量进行综合模式提取，并且用语异常检测的案例。 |
 | [实现大规模预测模型和服务](./实现大规模预测模型和服务.md) | 介绍阿里云日志服务提供的ARIMA时间序列预测模型，以及如何实现大规模预测服务。 |

src/sqldemo/multi_metric_anomaly_detection.md

@@ -0,0 +1,93 @@
+
+# 阿里云日志服务的多指标综合异常检测
+
+## 多指标综合异常检测
+
+线上服务运作的指标数据很大一部分的作用在于自动地诊断服务系统是否有异常、如果有问题，问题出在哪里。这些指标的历史数据会呈现出一定的模式，比如大概率在那个范围内波动，如果超出了某个范围将是很罕见的现象等。指标之间可能还会有关联关系，比如系统的请求压力会影响系统请求的平均延迟。
+
+阿里云日志服务提供的AI异常检测服务通过自动分析一组指标的潜在模式，然后判断指标是否遵循这些潜在的模式。如果指标的数值和潜在的模式不匹配，则判断为异常。判断的异常分等级，一级异常表示概率为0.1左右的小概率事件才会出现的指标值，二级异常表示概率为0.01左右的小概率事件才会出现的指标值，三级异常表示概率为0.001左右的小概率事件才会出现的指标值，以此类推。
+
+例如，参考下面的例子，假设我们把收集到的两个指标数据的数据投射到一个二维平面上。可以使用阿里云日志服务提供的模式分析函数帮助分析指标数据内在的模式。模式分析函数发现这两个指标的数据以99%的概率落在红色内圈里，即如果落在内圈外外圈内，为二级异常。两个指标的数据以99.9%的概率落在红色外圈里，即如果落在外圈外，为三级异常。当然还有四级、五级异常等等，为了简化，没有把对应的圈画出来。用户可以自主地选择过滤保留哪一个级别以上的异常。
+
+![指标数据分布模式的识别](/img/src/sqldemo/multi_metric_anomaly_detection/08-multi-metric-pattern.png)
+<p>图1. 指标数据分布模式的识别</p>
+
+我们用一些范例数据和SQL语句来描述如何用阿里云日志存储的AI服务来进行异常检测。这个过程分两步：第一步，在历史数据中分析指标模式；第二步，结合最新收集的数据和前一步分析出来的模式进行异常检测。
+
+_高维指标数据例子: metric_data_table_
+
+|cluster|server|time_period|request_count|network_traffic|latency_us|
+|--|--|--|--|--|--|
+|Cluster-A01|Server-01|2024-01-01 00:00:00|180|2000000000|100|
+|Cluster-A01|Server-01|2024-01-01 00:01:00|200|2500000000|120|
+|Cluster-A01|Server-01|2024-01-01 00:06:00|150|1200000000|110|
+|Cluster-A01|Server-01|2024-01-01 00:08:00|175|1800000000|115|
+|...|...|...|...|...|...|
+
+上面的表格展示了对每个cluster的每个server的每个数据采集周期的三个数量指标：request_count、network_traffic和latency_us。我们可以用下面的SQL语句对每个cluster的每个server的最近一段时间的三个指标的数据进行联合模式分析，每个cluster的每个server都有属于自己的统计的联合指标模式分析。这是给每个cluster的每个server一个私人定制的模式分析。我们可以使用下面的SQL语句进行模式分析，然后把指标联合模式分析的结果保存到metric_pattern_table中，也可以放在带with语句的通用表表达式(Common Table Expression)中。
+
+```sql
+select cluster,
+    server,
+    '2024-01-01 00:00:00' as time_window_begin,
+    '2024-01-08 00:00:00' as time_window_end,
+    summarize(
+        array_agg(array[request_count, network_traffic, latency_us])
+    ) as metric_ pattern
+from metric_data_table
+where time_period >= '2024-01-01 00:00:00'  -- 指定历史数据开始的时间点
+  and time_period < '2024-01-08 00:00:00'      -- 指定历史数据结束的时间点
+group by cluster, server
+
+```
+
+_模式分析结果表: metric_pattern_table_
+|cluster|server|time_window_begin|time_window_end|metric_pattern|
+|--|--|--|--|--|
+|Cluster-A01|Server-01|2024-01-01 00:00:00|2024-01-08 00:00:00|{...}|
+|...|...|...|...|...|
+
+上述分析中使用了多指标的数据模式分析函数summarize(...)。这个函数主要是对多指标的数据样本综合分析，抽象出统计特征，如果仅仅是要把这些统计特征应用于异常检测的话，这些抽象的统计特征不需要深了解，只需要知道如何把模式分析函数summarize函数返回的结果交给anomaly_level函数就可以了。
+
+然后我们可以用下面的SQL语句，结合之前从历史数据中识别出来的指标模式，对最新收集到数据进行异常检测，过滤保留4级以上的异常(万分之一的小概率的异常)。结果类似于metric_anomaly_table结果表中的数据。
+
+```sql
+select md.cluster,
+    md.server,
+    anomaly_level(
+        mp.metric_pattern,
+        array[md.request_count, md.network_traffic, md.latency_us]
+    ) as anomaly_level,  -- 结合统计出来的数据模式和最新收集到的数据，计算异常等级
+    md.request_count,
+    md.network_traffic,
+    md.latency_us
+from metric_data_table as md
+    join metric_pattern_table as mp
+        on md.cluster = mp.cluster
+        and md.server = mp.server
+where md.time_period >= '2024-01-08 00:00:00'  -- 指定异常检测数据开始的时间点
+    and md.time_period < '2024-01-08 00:01:00'      -- 指定异常检测数据结束的时间点
+    and anomaly_level(
+        mp.metric_pattern,
+        array[md.request_count, md.network_traffic, md.latency_us]
+    ) >=4
+
+```
+
+_异常检测结果表: metric_anomaly_table_
+
+|cluster|server|time_period|anomaly_level|request_count|network_traffic|latency_us|
+|--|--|--|--|--|--|--|
+|Cluster-A01|Server-01|2024-01-0800:00:00|5|180|2000000000|100000|
+|...|...|...|...|...|...|...|
+
+anomaly_level函数是根据summarize函数学习出来的多变量模式(summary)对给定的一组新样本计算Mahalanobis距离，然后再向下取整，然后得到0，1，2，3，4，...，等之类的表示异常级别数字，来大致近似0.1、0.01、0.001、0.0001等等表示的小概率的位数，即对应一级异常、二级异常、三级异常、四级异常等等。异常级别为0表示在一个平均振幅以内；异常级别为1表示检测的数据样本在整体数据的一个平均振幅和两个平均振幅之间，大致表示0.1 (=10 ^ 1)的小概率事件；异常级别为2表示在两个平均振幅和三个平均振幅之间，大致表示0.01 (=10 ^2)的小概率事件；以此类推。异常等级越大，表示概率越小，该样本点越值得怀疑。一般来说，至少要3级及以上的才被认为是异常。所以我们通常会对异常检测结果进行过滤，如只保留3级以上的异常。
+
+## 阿里云日志服务中的ScheduledSQL——让AI模型计算成为自动计算服务
+
+之前介绍的阿里云日志服务的AI计算，是以SQL的形式介绍的。这仅仅是ad hoc的分析。我们可以结合阿里云日志服务中的ScheduledSQL的功能把AI计算形成定期计算的服务。要在阿里云日志服务生成持续执行的预测计算任务，在查询分析的界面上提供了一个 “定时保存分析结果”的按钮，点击这个按钮，参考下图，之后会弹出窗口，然后在这个窗口上配置这个定时执行的AI计算就可以了。
+
+![日志服务中的定时SQL服务](/img/src/sqldemo/multi_metric_anomaly_detection/14-sls-scheduled-sql.png)
+<p>图2. 日志服务中的定时SQL服务</p>
+
+ScheduledSQL任务的配置很直观。ScheduledSQL计算任务会定时把预测计算的SQL所产生的计算结果写入到另外一个日志库，如果这个目标日志库还不存在，需要先创建。另外要配置的是调度时间间隔和SQL读取的数据窗口等。