除了编译器和优化器外，另外有一个关键模块就是执行器。那么，如何保证MaxCompute运行器是正确执行的?避免在快速迭代中的正确性问题，从而避免重大的事故?同时，如何保证数据的安全性呢?

　　传统方式验证运行器，最经典的是用测试集群来验证，该方式验证的缺点如下：

　　浪费巨大

　　– 调度或者scalability等方面的改进往往需要建立一个相同规模的测试集群

　　没有相应的任务负载，无法构造对应场景

　　数据安全问题，使得我们需要脱敏的方式从生产集群拖数据

　　– 容易人为疏忽，造成数据泄露风险

　　– 脱敏数据可能造成用户程序crash，并且往往不能反映用户运行场景

　　– 整个测试过程冗长，不能达到测试的目的

　　所以我们引入了flighting工具来做测试和验证，将99% 机器资源使用线上版本运行生产作业，1% 机器资源用来为程序员上载的测试版本进行验证。

　　资源隔离

　　那么，怎么保证测试验证的作业不去影响线上生产的作业呢?这就需要我们完善资源隔离，具体包括：

　　CPU/Memory: 增强cgroup，任务优先级

　　Disk：统一的存储管理，存储的优先级

　　Network：Scalable Traffic Control

　　Quota管理

　　所以我们能够在保障线上核心业务需求情况下进行flighting的测试。

　　数据安全

　　从数据安全角度来说，我们的测试不需要人工干预进行数据脱敏;Flighting的任务的结果不落盘，而是直接对接分析任务产生测试报告：

　　– 结果正确性：MD5计算，浮点等不确定性类型的处理

　　– 执行性能的分析：straggler，data-skew，schedule quality

　　灰度上线

　　SQL的关键模块如编译优化和执行都可以得到有效测试和验证，接下来就可以上线了，上线时也会有很大风险，因此，我们实行灰度上线。按照任务的重要性进行分级，支持细粒度发布，并且支持瞬时回滚，控制风险到最小。

　　开发新功能后做回归，回归后发布，开始时往往有新功能后，就进行验证，如果新功能是针对编译器、优化器，就用playback验证，针对Runtime就用flighting验证，atv直播，atv，所有测试验证结束后，就到灰度发布阶段，直到所有任务百分百发布上线后，我们就认为这一次开发迭代是成功的，以此类推，不停的向前演进，既能保证服务可靠稳定运行的同时，将我们的性能提升，以满足用户的各种需求。