“从测试Databricks SQL Serverless + DBT中学到的5个教训”
从测试Databricks SQL Serverless + DBT中学到的5个经验教训
我们进行了一项价值12,000美元的实验，测试了无服务器仓库和dbt并发线程的成本和性能，并获得了意外的结果。
作者：Jeff Chou，Stewart Bryson
对于希望简化生产SQL查询和仓库的公司来说，Databricks的SQL仓库产品是一个令人心动的选择。然而，随着使用规模的扩大，这些系统的成本和性能变得至关重要。
在本博客中，我们深入探讨了他们的无服务器SQL仓库产品的成本和性能，利用了业界标准的TPC-DI基准测试。我们希望数据工程师和数据平台经理能够根据这里提供的结果做出更好的数据基础设施选择。
Databricks的SQL仓库产品有哪些？
在我们深入研究特定产品之前，让我们先退后一步，看看今天提供的不同选项。Databricks目前提供了3种不同的仓库选项：
- SQL经典版 — 最基本的仓库，运行在客户的云环境中
- SQL Pro版 — 改进的性能，适用于探索性数据科学，在客户的云环境中运行
- SQL无服务器版 — “最佳”性能，并且计算功能完全由Databricks管理。
从成本的角度来看，经典版和Pro版都运行在用户的云环境中。这意味着您将为Databricks使用支付两笔费用 —— 一笔是纯粹的Databricks成本（DBU），另一笔来自云服务提供商（例如AWS EC2账单）。
为了真正了解成本比较，让我们看一下基于其报告的实例类型运行在一个Small仓库上的示例成本详细分解：
在上表中，我们还对按需与现货成本进行了比较。从表中可以看出，无服务器选项没有云服务成分，因为这一切都由Databricks进行管理。
如果您使用的是所有按需实例，则与Pro版相比，无服务器可能更具成本效益。但是，如果有廉价的现货节点可用，Pro版可能更加便宜。总体而言，我认为无服务器的定价相当合理，因为它还包括了云成本，尽管它仍然是一个“高端”价格。
我们还包括了等价的作业计算集群，这是整体上最便宜的选择。如果成本是您关注的问题，您也可以在作业计算中运行SQL查询！
无服务器的优缺点
Databricks的无服务器选项是一个完全托管的计算平台。这与Snowflake的运行方式几乎完全相同，用户对计算细节一无所知。总体而言，这有其优点和缺点：
优点：
- 您不必考虑实例或配置
- 启动时间比从头开始启动集群要少得多（根据我们的观察，大约需要5-10秒）
缺点：
- 企业可能会对所有计算都在Databricks内部运行的安全性有顾虑
- 企业可能无法利用其云合同对特定实例提供的特殊折扣
- 无法优化集群，因此不知道Databricks选择的实例和配置是否适合您的作业
- 计算是一个黑盒子 – 用户不知道发生了什么或Databricks在底层实施了哪些更改，这可能导致稳定性问题。
由于无服务器的固有黑盒性质，我们对人们仍然拥有的各种可调参数及其对性能的影响很感兴趣。因此，让我们深入研究一下我们所探索的内容：
实验设置
我们试图以“实际”方法进行此研究，并模拟当一家真实公司想要运行SQL仓库时可能会做的事情。由于DBT在现代数据堆栈中非常受欢迎，因此我们决定研究并评估两个参数的范围：
- 仓库大小 – [‘2X-Small’，’X-Small’，’Small’，’VoAGI’，’Large’，’X-Large’，’2X-Large’，’3X-Large’，’4X-Large’]
- DBT线程 – [‘4’，’8’，’16’，’24’，’32’，’40’，’48’]
我们选择这两个参数的原因是它们都是任何工作负载的“通用”调整参数，并且它们都会影响作业的计算方面。特别是DBT线程有效地调整了作业在DAG中运行时的并行性。
我们选择的工作负载是流行的TPC-DI基准测试，规模因子为1000。这个工作负载特别有趣，因为它实际上是一个模拟更真实数据工作负载的完整流水线。例如，下面是我们的DBT DAG的屏幕截图，可以看到它相当复杂，改变DBT线程的数量可能会对这里产生影响。
顺便说一句，Databricks有一个绝妙的开源存储库，可以帮助您在Databricks内完全设置TPC-DI基准测试。（由于我们正在使用DBT，我们没有使用此功能）。
为了深入了解我们如何运行实验，我们使用具有dbt任务类型的Databricks Workflows作为dbt CLI的“运行器”，并且所有作业是并发执行的；由于Databricks方面的未知环境条件，不应该有任何差异。
每个作业都会启动一个新的SQL仓库，并在后续进行销毁，同时在同一个Unity目录中的唯一模式中运行。我们使用Elementary dbt package来收集执行结果，并在每次运行结束时运行一个Python笔记本，将这些指标收集到一个集中的模式中。
成本通过Databricks系统表提取，特别是Billable Usage的表。
请自行尝试此实验并克隆Github存储库
结果
下面是成本和运行时间与仓库大小的对比图。我们可以看到，当您达到VoAGI大小的仓库时，运行时间停止扩展。任何大于VoAGI的仓库几乎对运行时间没有影响（或者可能更糟）。这是一种典型的缩放趋势，它表明扩展集群大小并不能无限制，它们总是有一个添加更多计算提供收益递减的点。
对于那些计算机科学爱好者来说，这只不过是基本的计算机科学原则——阿姆达尔定律。
一个不寻常的观察结果是，VoAGI仓库表现优于接下来的3个更大尺寸（large到2xlarge）。我们多次重复这个特定的数据点，并获得了一致的结果，所以它不是一个奇怪的偶然现象。由于无服务器的黑盒特性，我们不幸地无法知道底层发生了什么，并无法给出解释。
由于在VoAGI处停止了扩展，所以从下面的成本图中可以看出，在VoAGI仓库尺寸之后，成本开始急剧上升，因为基本上你是花费更多的钱购买更贵的机器，而运行时间保持不变。因此，你为额外的性能支付了无益的代价。
下面的图表显示了在线程数量和仓库尺寸改变时运行时间的相对变化。对于大于水平线的值，运行时间增加（这是一个不好的事情）。
这里的数据有点嘈杂，但根据仓库的尺寸，可以得出一些有趣的观点：
- 2x-small — 增加线程数量通常会使作业的运行时间更长。
- X-small到large — 增加线程数量通常有助于作业的运行速度提高约10%，尽管收益相当平坦，所以继续增加线程数没有价值。
- 2x-large — 实际上有一个最佳的线程数，为24，如清晰的抛物线所示。
- 3x-large — 在线程数为8时，运行时间出现了非常异常的峰值，原因不明。
为了将所有内容整合成一个综合图表，我们可以看到下面的图表，它绘制了成本与作业总时长之间的关系。不同的颜色代表不同的仓库尺寸，而气泡的大小代表DBT线程的数量。
在上面的图表中，我们可以看到更大的仓库通常会导致更短的时长，但成本更高。然而，我们还发现了一些不寻常的点：
- VoAGI是最佳选择 — 从成本和运行时间的角度看，VoAGI是最佳的仓库选择。
- DBT线程的影响 — 对于较小的仓库，改变线程数量似乎可以使持续时间变化约为+/- 10%，但对成本没有太大影响。对于较大的仓库，线程数量对成本和运行时间的影响相当显著。
结论
总之，关于Databricks SQL无服务器+DBT产品，我们学到的五个重要教训是：
- 经验法则是不准确的 — 我们不能仅仅依赖于仓库尺寸或DBT线程数量的“经验法则”。某些预期的趋势确实存在，但它们并不一致或可预测，而且它完全取决于您的工作负载和数据。
- 巨大的差异 — 对于完全相同的工作负载，成本范围从5美元到45美元不等，运行时间范围从2分钟到90分钟不等，这都是由于不同线程数量和仓库尺寸的组合造成的。
- 无服务器扩展有限 — 无服务器仓库无法无限扩展，最终较大的仓库将不再提供任何加速，并只会导致成本增加而无任何好处。
- VoAGI很优秀？ — 对于TPC-DI基准测试，我们发现VoAGI无服务器SQL仓库在成本和作业持续时间上超过了许多较大的仓库尺寸。我们不知道具体原因。
- 作业集群可能更便宜 — 如果成本是一个问题，使用笔记本和标准作业计算可能会更便宜。
这里报道的结果表明，黑盒“无服务器”系统的性能可能导致一些异常。由于这一切都是在Databrick的墙后进行，我们不知道正在发生什么。也许这一切都是在巨大的Spark on Kubernetes集群上运行，或者他们与亚马逊在某些实例上有特殊的交易？无论如何，这种不可预测的性质使得成本和性能的控制变得棘手。
由于每个工作负载在这么多维度上都是独特的，我们不能依赖“经验法则”，或者昂贵的实验只针对当前状态下的工作负载而言的真理。无服务器系统的更加混乱的性质确实引起了这样的问题，这些系统是否需要一个闭环控制系统来使它们受到控制？
作为一种自省的注释-无服务器的商业模式确实具有真正的吸引力。假设Databricks是一个理性的企业，它不希望减少他们的收入，并且他们希望降低他们的成本，必须问一个问题：“Databricks是否有动机改进底层的计算？”
问题在于，如果他们使得无服务器快两倍，那么突然间来自无服务器的收入就会减少50%——这对Databricks来说是非常糟糕的一天。如果他们能够使其加快2倍，然后将DBU成本提高2倍以抵消加速，那么他们的收入就会保持中性（实际上Photon就是这么做的）。
所以Databricks真的有动机降低他们的内部成本，同时保持客户的运行时间大致相同。虽然这对Databricks来说很好，但很难将任何降低成本的无服务器加速技术传递给用户。
想了解更多提升您的Databricks流水线的方法吗？请与Jeff Chou及其余的Sync团队联系。
资源
- 尝试通过克隆Github仓库进行此实验
