作者：成一鹏
导语： 在云计算资源管理中，热迁移是实现资源配置的重要手段，常常会因为多种场景需要发起热迁移：例如资源调配，母机负载均衡以及运维人工热迁移等场景。 而在当前热迁移任务中，热迁移在经过多次条件过滤后还是会不时遇到迁移超时失败的情况，在不恰当时机发起迁移任务，不仅影响了客户了SLA体验，也影响了热迁移效率。
简要
主要解决热迁移对象在内存利用变化快，磁盘读写速率快等状态的情况下无法判断其是否适合发起热迁移。
本次任务方案选择了多集成学习算法的投票选举，这是一个基于RandomForest,Adaboosting,Xgboost业界主流算法的混合voting预测模型。30%真实数据集作为验证，预测精度97.44%，实现对热迁移发起任务的成功率预测，对于超时迁移识别的样本识别率实现，也就是说可以减少原来热迁移超时失败情况数量的80%。
1. 需求背景
在云计算资源管理中，热迁移是实现资源配置的重要手段，常常会因为多种场景需要发起热迁移：例如资源调配，母机负载均衡以及运维人工热迁移等场景。
而在当前热迁移任务中，热迁移在经过多次条件过滤后还是会经常遇到迁移超时失败的情况，发起不合适的热迁移任务，不仅影响了客户了SLA体验，也影响了热迁移效率。
按以往人工经验去进行判断是否适合热迁移，例如内存变化率高会影响热迁移，CPU使用率 过高也会影响热迁移，
在这之前尽管我们知道内存变化率过高，CPU使用率过高，乃至内外网吞吐量过高都会影响到热迁移的成功， 但我们无法去构建一个衡量标准。并且如果频繁去监控获取子机的这些数据，也会对虚拟机性能造成影响，并且人工也无法去判断什么时间点哪些情况下哪个指标更重要，因此无法形成一个综合而客观稳定的判别标准。
2. 实现目标
所以我们引入了机器学习&深度学习，希望能够拟合一个复杂模型去计算并量化出一个适合热迁移的状态标准，实现对热迁移发起后是否会超时失败进行预测。
3. 实现简介
3.1特征空间
3.2特征处理
考虑到每列数据的差异有6个数量级差别，所以需要对大数量级的列数据 进行缩放。常用的做法有 np.sqrt，np.log。
3.3 HeatMap特征相关性分析
热力图是最直观的展示特征之间的线性相关性，从图中我们可以看到cpu和mem呈强相关性，这是显然的结果，高性能cpu往往伴随大内存；其次呈现中等相关的是出入流量。由此简单可以看出各个特征参数都是相对独立的，从线性相关角度看。
3.4算法简介：为什么选择随机森林与Xgboost
随机森林
如果从深度学习的角度去理解，可以认为随机森林的决策树随机分裂，隐含地创造了多个联合特征，并能够解决非线性问题，
可以相对离散地自动提取特征与权重学习。某种意义上实现CNN的卷积池化提取作用。
并行计算，对于个别特征缺失不敏感。
当构建决策树时，每次分裂时，都从全特征候选p集中选取m个进行分裂，一般m=sqrt(p)。
随机森林不会出现过拟合，只要树的个数（B）足够大时会使得错误率降低。
Xgboost
在Kaggle比赛中的必备算法，属于Gradient boosting的高效实现。并且有以下三处的改进：
(1). xgboost在目标函数中显示的加上了正则化项，基学习为CART时，正则化项与树的叶子节点的数量T和叶子节点的值有关。 (2). GB中使用Loss Function对f(x)的一阶导数计算出伪残差用于学习生成fm(x)，xgboost不仅使用到了一阶导数，还使用二阶导数。 (3). CART回归树（GB）中寻找最佳分割点的衡量标准是最小化均方差，xgboost寻找分割点的标准是最大化，lamda，gama与正则化项相关。
AdaBoost
通过迭代实现把弱分类器训练成强分类器，每一次迭代后会对错误数据的关注度更高（策略为最小化分类误差率），使得下一个基学习器会对上次迭代数据更有更多的针对性，最终构建成附带权重的线性组合集成学习。
在数据清洗干净的情况下，效果会更好。
4.模型性能
4.1 Recall召回率
4.2Accuracy：97.44%
5.把模糊的行业经验变得更科学，更精准：
根据模型预测结果计算出影响热迁移的重要指标:
CPU使用率对热迁移成功最关键，其次是包的进出流量，磁盘读取速率反而影响力很低。
由图我们可以看到cpu使用率对热迁移成功与否的影响力占比去到21.4%，显著高于其他特征参数，这也是符合人的经验逻辑的，
当一台子机cpu使用率占用达到一定比例之后，如果后台再发起热迁移必然会占用部分系统资源，
而形成热迁移超时往往也是因为没有足够资源进行响应。
其次我们可以看到进出包量的影响力是同等（9.7%, 9.1%），再然后是内存使用率(8.3%)以及磁盘使用率(6.2%)。
可以注意到的是进出包量的影响力比我们想象的要高很多，而磁盘读取速率(4.6%),磁盘写入速率(5.1%)的重要性却要比我们想象的低，
这样的反馈结果根据我们的直观经验是无法获得的。
再往后热迁移发起任务中，我们也可以依据以上的分析结果，
如果迁移策略能够提前分配额外资源（cpu,mem,进出带宽）给到迁移对象，相信会大大减少热迁移超时失败的情况。
6.后续改进
6.1经验总结
在实际工程实施中，除了模型的构建 特征处理以外，第一步的数据收集，输入参数空间的构造都是至关重要的，数据集的大小以及质量直接决定了模型性能的上限。一方面除了收集实践经验判断相关的重要参数，另一方面也不能去简单排除其他看起来似乎不相干的特征参数，因为往往判断结果有可能与人的直觉相左右，总之尽可能的收集所有相关参数，然后再通过特征工程进行筛选去重是比较合理的做法。
在本次预测模型构造中，数据预处理去除脏数据，缺失数据后剩下的负样本数量还处在5k级别，一般而言对于一个机器学习任务 样本数量级别达到10万个是比较合适的，
另外目前正负样本比例不均衡也给模型性能的提升和预测带来很大困难，这个问题相信伴随数据量的增长以及改善采集数据缺失情况后会得到较大改善。
6.2 后期展望
部署优化
在后期优化中，会联通我们的数据仓库CDW实现数据自动采集，模型自动训练以及自动部署。
功能扩展
在后续热迁移技术改进中：我们会根据在不同的资源约束和VM工作负载下去预测不同实时迁移算法的关键参数。对基于实时迁移算法的迁移任务，构建机器学习模型预测迁移任务的总迁移时间，停机时间以及传输的总数据量。
7.技术框架
主要包含Serving服务框架，Model仓库，WEB服务层，后期的所有预测服务/数据挖掘分析都将在这个框架下运行，不限于数据采集 模型训练 版本管理以及部署发布。
TensorFlow Serving
是一个工业级可用于机器学习模型 serving 的高性能开源库。它可以将训练好的机器学习模型部署到线上，使用 gRPC 作为接口接受外部调用。将tensorflow训练出来的模型更好的应用在生产环境中,通过API等等支持的方式来方便对外提供稳定可靠的服务 WEB服务器结构
Flask-uWsgi-Nginx： Flask负责任务调度，uWsgi-Nginx负载转发，
目前已实现3台机器容灾部署，统一接入TGW实现负载均衡。
TensorflowClient
主要负责与TensorflowServing通信和调用模型api，通过调用TensorFlow Serving 的 Predict API 和 gRPC 的 implementations.insecure_channel 从而构建一个 request。
8.接入流程：
