我在同一个HDFS文件上的不同驱动节点查询上有多个Spark会话，我们说TableT1． 以下是T1结构。
- 按日期分区
- 然后按用户id的前2位进行分区
- 用户id字段
- 用户的其他相关信息。
| 分区日期 | 分区前2位 | 用户id | 其他信息 | 17 | 01 | 01234 | … |
|---|---|---|---|
| 18 | 01 | 01234 | … |
| 18 | 02 | 02345 | … |
理论上，在这两种情况下，性能应该是相同的，但是还有其他因素可能会影响作业的调度。根据我的经验，您可能会遇到这些限制中的任何一个。
- 正在启动spark作业的作业池的资源少于8个作业实例所需的资源。假设每个实例/运行需要4个执行器，那么当您运行8个作业实例时，这意味着您总共请求32个执行器。如果您的作业队列配置为支持20个执行器(执行器可能受到分配给队列的内核数量或内存数量或两者的限制)。您的8个作业无法实现最大并行性，因此与同时运行的单个实例相比显得很慢，因为单个实例可以获得所需的所有资源并能够实现最大并行性
- 您的集群正在全力运行，并将大部分资源用于其他prod作业，因此同一作业的8个实例同时等待资源。
- 如果您对8个实例运行单个测试，则可能存在在父目录或hive表上发生写作业的可能性，这可能导致您的作业进入等待状态。
这些是我在职业生涯中看到的一些问题，也可能有其他因素。我建议从系统管理员那里访问yarn调度或队列，看看其中一个是否是罪魁祸首。