数据库、REST节流和容量限制/限制

Question

我已经适当地扩展了azure集群(“通用”集群)上的硬件，以便它能够处理大量的工作。应用程序的设计方式是，输入的数据以较小的、离散的块处理。作业在20到30秒内运行。但是有很高程度的并发作业需要同时执行(例如。从0到50个同时作业的任何地方)。

向集群交付作业的唯一方法似乎是在azure中使用REST (doc：https://docs.databricks.com/dev-tools/api/latest/jobs.html )。

一切正常运行，直到并发作业的数量达到10个左右为止。在这一点上，我看到吞吐量不合理的下降。但如果我检查ganglia或自定义遥测，似乎没有理由使性能恶化。

我怀疑REST本身引入了一个人为的瓶颈，它们限制了我可以发送到集群的作业数量。这对我来说并不是不言而喻的。如果我正在为一个大型集群付费，应该允许我向它发送工作机会。REST似乎只是作为一个通信通道，允许我将请求发送到集群。这个API是我最不希望找到资源瓶颈的地方。星火开发者自然会研究他们的代码，然后是集群硬件。REST并不是Databricks引入一些额外的秘密限制的合理场所。

有没有人知道有另一种方法可以将不同的作业传送到集群，而不通过REST呢？例如：集群中的驱动节点是否有一种方法可以生成额外的/不同的/一流的作业而不计入REST允许量？

这个问题似乎很愚蠢，而且是人为的。这些限制的秘密性质也使我感到烦恼。如果他们正在节流REST，那么应该有一个警告、错误或ganglia图表。否则，开发人员将使用试错和猜测来解决性能问题。

任何帮助都是非常感谢的。我不想一路上回到画板上，因为他们的REST受到了人为的限制(可能是为了保护动力不足的“控制飞机”)。

Answer 1

星星之火是很棒的，但它不是设计成一个高并发性数据库。Databricks的工作人员已经做了很多工作来消除Spark的并发限制，但它仍然不是一个高度一致的解决方案。

换句话说，您的问题不是REST .这是数据库中的火花引擎。

我知道你不想回到画板上，但这里的选择都是糟糕的：

• 您可以运行多个Databricks集群( https://docs.databricks.com/clusters/index.html )，并使用NGINX或其他负载均衡器分发API请求。
• 如果您的用例支持它，尝试使用支持高并发性的实时数据库。我喜欢Druid (如果您想要托管版本，请参阅https://druid.apache.io或https://imply.io )，但也有一些属于同一类别的