约束与限制

在使用OmniAdvisor参数调优2.0前，请先了解该特性的使用约束与限制。

• 当前版本只支持对Spark引擎中通过spark-sql命令或spark-submit命令提交的任务执行端到端调优，不支持类似于--version、--kill或--status等非任务提交形式进行端到端调优。
• 当前版本中，Spark引擎提交的任务，系统将根据任务名称属性、执行文件属性（如SQL语句、SQL文件路径或可执行文件路径，具体以用户提交命令为准）以及应用参数进行联合匹配，从后端数据库中查找相同任务。建议用户在提交任务时携带相关配置，其中的资源参数（如spark.executor.cores）将用于算法的资源约束；若未指定，则使用Spark默认参数值。
• 本特性前台劫持功能生效后，特性内部将spark-sql的返回结果中stderr流的内容也重定向到了stdout流中，特性的输出内容统一从stdout流输出，因此在重定向输出结果时，stderr流始终为空，这与原生spark-sql存在细微差异。
• 由于算法内部内置的专家规则限制，expert调优算法最多进行9轮调优。但不保证每条负载都能有9轮的配置推送，这个取决于负载自身的瓶颈状况。若超过限制仍未达到调优目标，算法将停止调优并返回结果，建议用户尝试其他调优方法。
• transfer调优算法需要依赖大量的历史调优数据作为支撑。在首次使用该算法时，若出现配置无法推送的情况，属于正常现象。
• OmniAdvisor参数调优2.0对于Spark任务执行时间的计算方式为：执行时间 = 最晚结束的job时间 - 最早提交的job时间，单位为秒。
• 使用OmniAdvisor参数调优2.0特性的用户需具备对Spark、HDFS等相关大数据组件的使用权限。
• 在调优过程中，本软件会在任务执行结束后访问Spark History Server以获取执行信息。当任务并发较高时，可能会引发对Spark History Server的频繁访问。原生的Spark History Server在默认配置下可能会出现堆内存占用增加、GC（Garbage Collection Jitter，垃圾回收）抖动，甚至导致OOM（out of memory，内存不足）而退出。因此根据集群的任务并发情况，合理调整Spark History Server的相关参数。
  例如：在测试中，系统每小时处理了1500个并发任务，每个任务执行用时为10秒。通过以下命令修改参数，稳定通过了7*24小时的稳定性测试。

  export SPARK_DAEMON_MEMORY=12g
  export SPARK_HISTORY_OPTS="-Dspark.history.retainedApplications=20 -XX:+UseG1GC"

• Spark History Server在对任务的eventlog进行定时清理的过程中，trace的获取会被阻塞，若希望规避该情况，可以根据业务需求在spark的配置文件(默认为spark-defaults.conf)中添加如下参数，降低eventlog的清理频率

  spark.history.fs.cleaner.enabled     false
  spark.history.fs.cleaner.maxAge = 7d