Databricks 中的高并发集群答案

【问题标题】：High Concurrency Clusters in DatabricksDatabricks 中的高并发集群
【发布时间】：2021-04-28 08:25:43
【问题描述】：

来自 Databricks 文档：

高并发集群

高并发集群是托管的云资源。高并发集群的主要好处是他们提供 Apache Spark 原生的细粒度共享，以最大限度地资源利用率和最小查询延迟。

高并发集群仅适用于 SQL、Python 和 R。高并发集群的性能和安全性由在单独的进程中运行用户代码，这是不可能的斯卡拉。

为什么 Scala 不可能做到这一点？这个问题的主要方面。
Apache Spark 原生细粒度共享，可实现最大资源利用率和最小查询延迟。我对 Spark 的工作原理有一个很好的了解，但如果有一些额外的考虑，可能会在这里澄清一下。
顺便说一句，大多数人都在每人运行自己的标准集群或使用 HAC 使用 SQL 等。我认为 HAC 将是要走的路 - 一般而言。

【问题讨论】：

标签： scala apache-spark databricks

【解决方案1】：

高并发集群旨在供多个用户使用，共享集群资源，隔离每个笔记本等。对于所有提到的语言，都会创建单独的进程并执行受限于 Spark 公开的 API 的代码语言。但 Scala 代码将在所有用户共享的 Spark JVM（每台机器）内执行，因此您可以访问 JVM 内的所有内容。

通常，在使用高并发集群时，Table ACLs 也会启用（仅适用于 SQL 或 SQL+Python），因此您可以控制谁可以访问哪些数据，强制执行行/列级别的访问控制等。

【讨论】：

你能解释清楚吗？当然，我得到了并发使用的概念。我当然得到了 jvm，但每个用户都有自己的 jvm？显然遗漏了一些东西。 yarn 下的批处理 spark 应用并发运行。
我已经添加了JVM在用户之间共享的说明
也许我真的很无知，但我总是了解到并观察到我们有一个 Spark 应用程序，我们有自己的 JVM 用于驱动程序和一组执行程序（使用 YARN）。 Databricks 上似乎不是这种情况？
@AlexOtt 如果我可以在其中托管十几个并发作业（就像使用 OSS 一样），标准集群不会相对昂贵。就您而言，“作业集群”可能需要三分钟才能启动，即使使用池也是如此。太长了……特别是如果我的一些应用程序可以在十分钟或更短的时间内完成。很明显，“高并发”集群正在解决 Databricks 中的性能瓶颈。奇怪的是，Databricks 从来没有详细说明或描述过这个问题，也没有告诉我们为什么他们不愿意在 Scala 方面解决同样的问题。
如果 Databricks 解释了为什么存在“高并发”集群、避免了哪些问题/瓶颈、为获得这些好处做出了哪些妥协以及它们在内部工作方式与标准的不同之处，我会很高兴簇。最重要的是，他们需要解释为什么 Scala 被冷落了。

【解决方案2】：

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

在 OSS 中，Spark 驱动程序逻辑托管在单独/独立的进程中。 Spark 应用程序是共享集群硬件的同等应用程序。这种环境适合希望最大限度地利用可用硬件来同时运行的应用程序的数据工程师。

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

当您考虑标准 Databricks 集群（即“通用”集群）时，您应该将其视为具有“高并发”集群的相反特性的集群。（见https://docs.microsoft.com/en-us/azure/databricks/clusters/configure）

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

总之，Databricks 架构是围绕单个“驱动程序守护进程”进程（主要使用 Scala 开发的 JVM 代码）构建的。这可能成为某些 Spark 工作负载的瓶颈。但是 SQL、Python 和 R 的语言绑定已经设计为在 JVM 之外执行它们（进入单独的“运行时”/“sidecar”）。所以我猜想，当这些语言已经在自己的 sidecar 中执行时，对架构进行调整以最大限度地减少并发冲突会更容易。

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

【讨论】：

您可以将 Databricks 集群视为一个交互式 Spark 作业，通常由驱动程序和工作程序组成。它们运行在从云提供商的机器池中分配的机器上，通常您只受提供商配额的限制。这些“作业”由外部集群管理器协调。从这个角度来看，该架构类似于 OSS Spark - 您有一些“集群管理器”，负责分配资源以供执行，并且您有可以在其上执行的机器。
但是在 OSS 集群中，您通常有一组固定的机器运行 Spark 作业。在 Databricks 中，您通常只受云提供商可能为您分配的机器数量的限制。 Databricks 上的集群用于交互式工作负载，当人们开发代码、构建模型等时 - 如果您需要执行批处理作业，您应该使用将在单独的一组节点上执行的 Databricks 作业。而且它们更便宜。您可以在现有集群上运行作业，但通常不建议这样做，而且成本会更高