### 资源
可压缩 -> CPU -> 降速
不可压缩 -> 内存 -> 异常终止（OOM kill）

为避免服务中断，用户习惯性申请更多资源，造成资源浪费
autopilot 自动调节资源，提升资源利用率
主要目标，降低申请的资源上限和真实资源使用率之间的差值
Autopilot依据资源利用率的历史数据，依靠AI算法计算
可以将slack（limit-usage）降低到23%，人工调整的均值在46%

### 云用户
为作业声明单个实例的资源需求（limit）和实例数量，但资源limit往往造成麻烦
CPU/内存/实例数量很难测算
- 通常资源请求都是基于压力测试结果设定的，但是实际的资源需求会随时间不断变化，比如昼夜，星期模式
- 同时随着应用变得更流行或更不流行，并发请求也会随时间变化，影响资源占用率
- 随着软件功能变更，软件和硬件的性能优化和升级，资源需求同样不可控
### Recommender基于聚合的资源使用率输入信号
#### 𝑟𝑖[𝜏] 
- 原始的，单个Task的CPU/MEM时间序列，1秒解析度
- i代表第i个Task，𝜏代表数据采样时间
- 每1秒一个采样数据
#### 𝑠𝑖[𝑡] 
- 汇聚的，单个Task的CPU/MEM的时间序列Histogram，5分钟解析度
- 为降低数据存储量以及计算资源上限时的计算量，原始时间序列通常会被按5分钟汇总
- i代表第i个Task，𝑡代表5分钟的时间窗口，𝜏 属于（∈） 𝑡
- 针对CPU，𝑠𝑖[𝑡]被汇聚成切分成400个bucket的Histogram𝑠𝑖[𝑡][k]
- 针对MEM，𝑠𝑖[𝑡]只记录5分钟时间窗口的内存用量最高值
#### 𝑠[𝑡]
- 一个Job中所有task在5分钟窗口中的资源使用聚合向量，是一个简单的SUM(𝑠𝑖 [𝑡][𝑘])
#### h[𝑡]
- 一个Job的负载调节Histogram
#### 𝑏[𝑘] 
- Histogram第k个bin值（bucket的边界值）
### Moving window recommenders
基于汇聚信号s进行数据统计，并计算资源请求上限
我们期望资源Limit快速提升，以快速响应资源利用率上升的场景。
但希望资源Limit慢速降低，以防请求波动时，资源被过快回收
为使针对压力高峰的响应平滑，我们通过指数消亡权重（exponentially-decaying）来处理信号
𝑤[𝜏] = 2^(−𝜏/𝑡1/2)
𝜏采样时间
𝑡1/2half life，权重下降一半的时间
autopilot为long-running job优化，其中CPU的的half life是12小时，MEM的half life是48小时