无法读取U-SQL托管表：查询长期处于Preparing状态被Yarn终止

我碰到过不少类似的U-SQL托管表查询卡Preparing最终被Yarn终止的案例，结合你这张存储了36000条审计记录的表的场景，大概率是元数据过载、查询计划优化压力过大或者资源配置不足导致的，给你几个针对性的排查和解决方向：

1. 给表加上合理的分区策略 #

如果你的托管表没有做分区，当数据量（哪怕是元数据量级）上来后，查询时需要扫描全表的元数据分片，会让Preparing阶段的计划生成耗时剧增，直接超出Yarn的超时阈值。

• 建议按审计记录的生成日期（或者你批量处理文件的批次时间）来做分区，这样查询时可以精准定位到需要的分片：

  -- 示例：按日期分区重建审计表
  CREATE TABLE IF NOT EXISTS AuditTable
  (
      FileName string,
      StoragePath string,
      RecordCount long,
      AuditDate DateTime
  )
  PARTITIONED BY (AuditDate)
  WITH (
      DISTRIBUTION = HASH(FileName), -- 选择查询中常用的过滤字段作为分布键
      CLUSTERED INDEX(AuditDate ASC)
  );
  

• 后续查询审计报告时，一定要带上分区过滤条件，比如：

  SELECT StoragePath, SUM(RecordCount) AS TotalRecords
  FROM AuditTable 
  WHERE AuditDate BETWEEN DateTime.Parse("2024-01-01") AND DateTime.Parse("2024-01-31")
  GROUP BY StoragePath;
  

2. 优化表的分布和索引配置 #

不合理的分布键或者缺失聚簇索引，会让查询计划生成时需要处理大量数据分片的关联逻辑，拖慢Preparing阶段：

• 选择查询中频繁用来过滤/分组的字段作为分布键（比如你的FileName或者AuditDate），避免用高基数但很少用到的字段；
• 给表添加聚簇索引，让数据按查询常用的顺序存储，减少计划生成时的排序和扫描成本：

  -- 如果已经建表，添加聚簇索引
  CREATE CLUSTERED INDEX IX_AuditTable_AuditDate ON AuditTable(AuditDate ASC);
  

3. 调整Yarn和U-SQL作业的资源与超时设置 #

Yarn终止作业通常是因为作业在Preparing阶段占用的资源或时间超出了预设阈值：

• 提交查询时，手动指定更大的资源池或者延长作业超时时间：

  SET @@JobTimeout = 7200; -- 把超时设为2小时，可根据实际情况调整
  SET @@ResourcePool = 'LargePool'; -- 使用配置好的大资源池（如果你的环境有）
  

• 检查Yarn的核心配置，比如yarn.nodemanager.resource.memory-mb和yarn.scheduler.maximum-allocation-mb，确保有足够的内存分配给U-SQL作业的计划生成环节。

4. 彻底清理表的无效元数据 #

虽然你执行了Rebuild Table，但可能表的元数据中还存在无效的分片或文件引用，导致计划生成时反复尝试解析无效资源：

• 执行全分区重建命令，彻底刷新元数据：

  ALTER TABLE AuditTable REBUILD ALL PARTITIONS;
  

• 同时去Data Lake对应的表存储路径下，检查是否有冗余的、未被表引用的文件，手动清理这些无效文件后再重新执行查询。

5. 拆分审计数据的存储 #

如果36000条记录已经让单表的元数据压力超标，可以考虑按时间批次拆分审计数据，比如按季度或者月份创建独立的审计表，查询报告时通过UNION ALL合并所需时间段的数据，减少单表的元数据处理量。

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