数据库中的高并发簇

Question

这来自Databricks文档：

高并发集群 高并发性集群是托管云资源。高并发性集群的主要优点是，它们提供Apache本地细粒度共享，以最大限度地利用资源和减少查询延迟。 高并发性集群仅适用于SQL、Python和R。高并发性集群的性能和安全性是通过在单独的进程中运行用户代码来提供的，而Scala则不可能这样做。

• 为什么Scala不可能这样做呢？这个问题的主要方面。
• Apache本机细粒度共享，以最大限度的资源利用率和最小的查询延迟。我很清楚星火是如何工作的，但如果有额外的考虑，我可以在这里澄清一下。
• 顺便说一句，大多数人都在使用自己的标准集群，或者使用SQL等。我认为HAC是最好的选择--一般情况下。

Answer 1

高并发性集群可供多个用户使用，共享集群资源，并隔离所有提到的语言，为所有提到的语言创建单独的进程，并执行仅限于Spark向该语言公开的API的代码。但是Scala代码将在所有用户之间共享的Spark (每台机器)中执行，因此您可以访问JVM中的所有内容。

通常，在使用高并发群集时，还启用了表ACL (仅针对SQL或SQL+Python)，因此您可以控制谁可以访问哪些数据、强制行/列级访问控制等等。

Answer 2

“高并发性”集群是Databricks重新创建正常开源火花(OSS)性能的尝试。在普通操作系统中，集群上的多个应用程序彼此独立运行。请参阅https://spark.apache.org/docs/latest/cluster-overview.html

在OSS中，火花驱动程序逻辑驻留在单独/独立的进程中。Spark应用程序是共享集群硬件的协等号。这是一种适合于数据工程师的环境类型，数据工程师希望最大限度地利用可用硬件来并发运行应用程序。

但是Databricks的目标是为希望共享集群和相关笔记本的“数据科学家”开发一种有状态或协作体验。为了实现这些目标，Databricks通过他们的“驱动守护进程”开发了一种有状态集群技术。它是在驱动节点上运行的单个进程，它协调集群上需要运行的任何驱动程序逻辑。

当您考虑标准Databricks集群时(即。一个“通用”集群)，您应该把它看作一个具有与“高并发性”集群相反的特性的集群。(见https://learn.microsoft.com/en-us/azure/databricks/clusters/configure)

• 高并发性集群具有“细粒度共享”。而默认集群在“驱动程序守护进程”的上下文中执行许多有意的资源同步(导致临时冲突)。当大量同时提交的工作被提交时，这是最明显的。
• 高并发性集群具有“最大的资源利用率”。而默认集群通常会在该JVM进程中的内部资源(“驱动程序守护进程”)上遇到瓶颈，而且集群很少会在驱动节点上使用超过的一个 CPU核心(这意味着集群中执行的所有驱动程序逻辑的序列化)。
• 高并发性集群具有“最小查询延迟”，而默认集群上的延迟非常高--即使只有5或10个独立作业正在运行。
• 高并发性集群“在单独的进程中运行用户代码”，而Databricks集群将在单个大规模JVM进程(也称为“驱动守护进程”)中承载所有驱动程序逻辑。由于各种技术原因，这一过程成为一个实质性的瓶颈。

总之，Databricks体系结构是围绕单个“驱动程序守护进程”构建的(JVM代码主要是用Scala开发的)。这可能成为某些火花工作负载的瓶颈。但是，SQL、Python和R的语言绑定已经设计成在JVM之外执行它们(进入单独的“运行时”/“侧”)。因此，我猜对体系结构的调整会更容易一些，以便在这些语言已经在自己的侧服务器中执行时，将这些语言的并发冲突降到最低。

与这些语言(SQL、Python和R)不同，基于Scala的逻辑被同化到“驱动守护进程”进程本身，并且没有单独的运行时。Scala的高并发模式是可以实现的，但可能需要避免使用“驱动程序守护进程”。这将是他们的架构的一个巨大的逆转。它基本上会让平台重新看起来像开放源码软件。他们可能认为这会削弱他们的竞争优势，或者会导致他们的集群模式之间出现一些令人困惑的不相容。