4

我的组织设置了一个配置为使用 SSL over HTTP 的 Spark Thrift 服务器。目的是使 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 服务器发送数据包上：对于 #1，这不是网络延迟问题。
  6. 我们将服务器配置更改为“标准”或二进制协议，与 Power BI 连接：执行速度非常快！
  7. 我们将服务器配置恢复为“HTTP”，但没有 SSL：执行速度很慢。

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

所以这似乎指向一个问题，特别是使用 HTTP（通过端口 10001）？

4

1 回答 1

1

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

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

所以我想我的故事的寓意是检查整个堆栈是否有问题，也许只是从重新启动所涉及的所有内容（在非生产环境中）开始，看看这是否会有所作为！在我的特定情况下，我无法访问所涉及的大部分底层基础架构，因此无法广泛而自由地进行故障排除。

于 2019-08-23T06:27:32.997 回答