李伟轩-Spark SQL 在平安产险的应用

业务背景

业务现状：

• 离线集群在任务高峰期出现CPU资源不足，而内存利用率不高。

业务需求与特点：

• 业务需求： 节省集群资源，提高资源利用率，提升任务运行时效。
• 业务特点：
  • Hive SQL任务：高并发，数据量在100万-1亿占50%，1亿-50亿占30%，50亿+占20%。
  • 数仓任务：定时执行，离线T+1，每日任务量10万+。
  • 引擎对比：
    • Hive：稳定性高，但时效性较低，资源利用率低，适用于SQL复杂、稳定性要求高、数据量巨大的离线任务。
    • Spark：时效性较高，对内存资源利用率高，节省队列的CPU资源，适用于SQL规模相对较小、稳定性要求低、复杂SQL场景下数据量较小的离线任务。
    • Presto：低延迟查询，支持多数据源，但对集群内存资源要求高，无法处理大数据集的查询，适用于实时性要求较高的交互式查询。

部署方式的选择

部署模式优劣对比：

• ThriftServer：
  • 优点：资源利用率高，参数和资源管理成本低，无启动开销。
  • 缺点：无高可用，资源未隔离，SQL任务相互影响，稳定性低，无多租户功能，权限无法隔离。
• Spark-SQL：
  • 优点：各个SQL任务之间相互隔离，互不影响，稳定性高。
  • 缺点：资源利用率低，有启动开销。
• Kyuubi：
  • 优点：Kyuubi Server支持高可用，稳定性较高，支持多租户，管控SparkSQLEngine的启动时机、销毁时机和占用资源等较复杂。
  • 缺点：较复杂。

部署模式的选择：

• 小数据量任务（100GB以下）：ThriftServer。
• 执行耗时短任务（15min以下）：ThriftServer。
• 非关键型任务（对稳定性要求较低、下游依赖较少、失败易恢复）：ThriftServer。
• 大数据量任务（100GB以上）：Spark-SQL。
• 执行耗时较长任务（15min以上）：Spark-SQL。
• 关键型任务（稳定性要求高，任务被众多下游依赖）：Spark-SQL。
• 开发人员/运维人员验证任务：Kyuubi。
• 演练任务：Kyuubi。

迁移流程

语法兼容性校验：

• 人工修改、复核提交Spark任务。
• 自动化批量校验，自动化识别兼容性问题，输出解决方案参考。
• 开发平台SQL开发页面提供SQL语法兼容性检测功能，自动生成测试SQL。

一致性校验：

• 评估标准：一致性、资源、时效、稳定性、任务失败容忍度。
• 工具自动化校验。

创建演练任务：

• Hive+Spark双跑一周灰度阶段与上线阶段。
• 自动化统计执行时长、资源消耗、记录异常运行状态。
• 自动化解析演练任务审计日志，分析资源利用率，自动调整资源参数。

典型问题与经验

ThriftServer稳定性建设：

• 运维与治理：服务异常自动拉起，定期分析日志，识别异常任务，实时预警和监控，健康检查、告警。
• 高可用&可扩展：搭建代理服务缓解Driver压力，增大Driver内存，降低广播join阈值，多服务分摊压力，结果集分批返回，限制提交结果集过大SQL任务，合理调控SQL任务的并发度。

并行度：

• 合理提高并行度，充分利用集群资源，加快整体执行效率。
• 相关参数：spark.sql.shuffle.partitions、spark.default.parallelism。
• 配置建议：ThriftServer模式，服务端无需额外设置；Spark-SQL模式，Application总CPU核心的2-3倍。

合理配置通信与重试参数：

• 降低重试次数，增大交互超时时间和心跳时间间隔。
• spark.executor.heartbeat.maxFailures、spark.executor.heartbeatInterval、spark.network.timeout、spark.rpc.numRetries、spark.task.maxFailures、spark.yarn.max.executor.failures。

Spark-SQL资源预估：

• 单Executor CPU Core：spark.executor.cores。
• Executor个数：explain+尝试运行分析耗时久task较多的stage，获得该stage的