thrift - 为什么我的 Spark Thrift 服务器使用 HTTP 时速度非常慢？

Question

我的组织设置了一个 Spark Thrift 服务器，该服务器配置为使用 HTTP 上的 SSL。目的是使 Power BI 能够通过 Spark 安全地检索数据。然而，仅仅检索架构信息可能需要长达 10 分钟的时间，并且前 1000 行数据还需要 10 多分钟!

显然，这是行不通的，因此我们着手进行消除过程。我们捕获了大量数据和其他详细信息，但我认为我们的发现可以归结为:

1. Wireshark 用于 Power BI 计算机。这显示了 Power BI大部分时间都在等待数据包:不是客户端的处理。
2. 我们使用管理 UI 来获取 Power BI 向 Spark thrift 服务器发出的确切命令:客户端的命令不是高效但并非不合理。
3. 使用 Beeline(在同一集群中的另一台计算机上)连接并执行与 Power BI 完全相同的命令执行:执行速度很快。
4. (在工作站上)使用 Simba ODBC 驱动程序连接并执行简单的 SELECT * 命令:执行速度很慢(每 1 秒检索行)。
5. 在 Thrift 服务器上使用了 TCP 转储。这表明大部分时间都花在等待 thrift 服务器发送数据包上:with#1，这不是网络延迟问题。
6. 我们将服务器配置更改为“标准”或二进制协议(protocol)，并与 Power BI 连接:执行速度很快!
7. 我们将服务器配置恢复为“HTTP”，但没有 SSL:执行速度慢。

这些信息是否表明我的消除过程中存在任何漏洞或我们遗漏的明显潜在问题？

所以这似乎表明了一个与 HTTP(通过端口 10001)的使用有关的问题？

Answer 1

经过数周的研究后，顺便说一句，有人重新启动了下游 YARN用于管理集群中 Spark 作业的服务器。突然之间，从 Thrift 服务器返回的所有数据都以 HTTPS 模式闪电般地快速传输。

事实证明，由于错误的垃圾收集策略，YARN 服务器内存不足。因此，Thrift 服务器响应数据的速度很慢，因为 YARN 服务器正在崩溃。垃圾收集器已完全更换并重新配置，现在似乎工作正常。

所以我想我的故事的寓意是检查整个堆栈是否存在问题，也许只是从重新启动所有涉及的内容(在非生产环境中)开始，看看这是否会产生影响!在我的特定实例中，我无法访问所涉及的大部分底层基础设施，因此无法广泛且自由地进行故障排除。