Azure下Simba JDBC连接Databricks拉取大数据量时无响应如何解决

排查方向 #

• 超时配置核查
  报错核心是NoHttpResponseException，属于典型的长耗时请求触发链路超时断连，优先核查两处超时配置：
  1. Simba JDBC驱动默认httpSocketTimeout仅为300秒，connectionTimeout为60秒，大结果集拉取时Driver侧需要长时间计算、拉取ADLS Gen2数据，无回包时会触发驱动主动断连
  2. Azure网络网关默认空闲连接超时为4分钟，无数据包传输的连接会被网关主动销毁
• 连接池配置核查
  从报错栈可见使用Denodo内置的DBCP2连接池，若testOnBorrow开启但校验超时时间过短、或者minEvictableIdleTimeMillis小于请求耗时，连接池会提前销毁正在使用的连接，触发连接校验失败
• Databricks集群状态核查
  去Databricks工作区查看对应时间段的：
  1. Driver节点GC日志，确认是否频繁Full GC导致服务无响应
  2. Thrift JDBC服务日志，确认是否存在连接数超限、请求限流的报错
  3. ADLS Gen2访问日志，确认是否存在存储侧限流、访问超时的问题

修复方案 #

• 调整JDBC连接参数
  在Denodo的Databricks JDBC数据源配置中，给JDBC URL追加以下参数：

  ;httpSocketTimeout=3600000;connectionTimeout=300000;tcpKeepAlive=true;UseNativeQuery=1
  

  其中httpSocketTimeout设为1小时适配大结果集拉取耗时，tcpKeepAlive开启TCP保活避免Azure网关断连，UseNativeQuery禁用驱动端SQL转换减少额外开销
• 优化数据拉取逻辑
  避免单次拉取全量600万条数据，改为按主键分页拉取，单次拉取量控制在10~20万条，或者在Databricks侧提前将查询结果缓存为临时表后再拉取，降低Driver侧实时计算压力
• 调整连接池配置
  修改Denodo JDBC连接池参数：
  • testWhileIdle设为true
  • timeBetweenEvictionRunsMillis设为120000（2分钟）
  • validationQueryTimeout设为30
    避免空闲连接被提前销毁，同时降低连接校验的性能开销
• 集群侧优化
  若使用Databricks Serverless集群，切换为固定资源的经典集群避免冷启动波动；经典集群可调整spark.thriftserver.maxThreads参数至50以上，提升Thrift服务的并发处理能力

内容的提问来源于stack exchange，提问作者AmitG