跳到正文
Hacker News· skadamat·· 10 天前AI 评分62

作者用 iPhone 17 Pro 跑 TPC-H 对比 Databricks 集群

I benchmarked Databricks against my iPhone

AI 导读

Fivetran 作者在 iPhone 17 Pro 上用 DuckDB 运行 TPC-H 的 22 条分析查询,与 Databricks Serverless SQL 的 XS、S、M 三种集群规模对比,在 25、50、100、200 GB 四个数据规模下,iPhone 除最大规模外均快于 Databricks 集群,最大规模下也具竞争力。

正文 · AI 翻译

译文尚不完整,完整内容请切换到原文。

Big data is dead. Those of us who have spent the last decade working on data management systems know that real-world business data sets are much smaller than the ones that get talked about in benchmarks. What is less well understood is just how much faster everyday hardware has gotten. Workloads that once required a distributed system can now run on an iPhone. To prove that this isn't hyperbole, I went ahead and did just that.

我的 iPhone 17 Pro。存了很多我家狗的照片,还能轻松处理巨型数据集。

我选择的工作负载是 TPC-H。TPC-H 是一组针对一个虚构批发供应商数据库的 22 个分析查询。

TPC-H 可以按不同规模生成。我想选择一个能代表现实业务用户工作负载高端的规模。Snowflake 和 Amazon 已经发布了关于查询规模在现实世界中的分布的统计数据,我们可以用它来校准基准测试。我运行了 4 种规模:25、50、100 和 200 GB,以近似现实世界分布的高端。

我在手机上使用 DuckDB 运行这些查询,并在 3 种不同规模的 Databricks 集群(XS、S 和 M)上使用 Databricks Serverless SQL 运行。我的 iPhone 上的 DuckDB 在除最大规模外的所有规模上都比 Databricks 集群更快,即使在最大规模上也很有竞争力。

这很令人惊讶:即使是最小的 Databricks 集群,其 CPU 核心数也比 iPhone 多:
‍

Databricks XS Databricks S Databricks M iPhone 17 Pro
CPU 24 40 80 6
内存(GB) 128 224 448 12
每小时成本(美元) 4.20 8.40 16.80 不适用

这些结果有两个原因。首先,尽管以现实世界业务分析的标准来看,这个工作负载很大,但与现代 CPU 的能力相比,它相当小。因此,在这个基准测试中,查询规划和编译的固定成本很高。DuckDB 的设计擅长快速运行小查询。

其次,DuckDB 是单节点数据库,而即使是 Databricks XS 也是多节点系统。在每个大型 JOIN 和 GROUP BY 上,Databricks 都必须执行 shuffle 来将数据分布到各个节点:

如果你的查询能放在单个节点上,避免这些成本会更高效。现在已经很少有查询不能放在单个节点上了:AWS c9 系列可提供 192 个 Graviton5 核心。

这一发现最重要的意义在于成本。如果你只是使用 Databricks 或 Snowflake 这样的系统对业务数据运行 SQL 查询或 Python 数据框,那么你正在为底层计算支付非常高的加价。

在过去 10 年里,云计算成本下降了 10 倍,而主要数据基础设施提供商的利润率却在增长,导致了我们今天看到的巨额加价。 

在 iPhone 上运行 TPC-H 是个有趣的噱头。大多数公司不会采用 iPhone 作为他们的数据仓库——不过如果你这么做,我建议你把它放进冰袋里,否则你会因为热节流损失大约 30% 的性能。

这个噱头向我们展示的是,现实世界的业务工作负载对现代计算机来说根本不算什么挑战。大多数现实世界的工作负载都可以在单台机器上运行,使用像 DuckDB 和 Polars 这样旨在利用非分布式执行效率的执行引擎。重要的是,使用单节点执行引擎并不意味着你整个公司的工作负载都必须在一台机器上运行。来自许多用户的查询可以分布到许多工作节点上。

这就是我们的 Lake Compute 服务的工作方式:我们有一个庞大的工作节点池,但每个工作节点一次只处理一个客户的 dbt 模型。判断你的工作负载是否适合单节点执行引擎很容易:现在所有主要的数据平台都内置了对话式分析功能,直接问就行了!

‍“给我展示一个生产数据仓库中查询所读取数据大小的直方图,x 轴用对数刻度,单位为 GB。”

我保证你会震惊于绝大多数查询有多小。我们都在用昂贵的分布式执行引擎来跑本可以在 iPhone 上运行的查询。我们要利用更便宜的算力,方式就是迁移到一种新架构,让湖仓中的所有参与者直接与存储层通信。

你以逐步、逐层的方式采用这一架构。

  1. 将你的数据摄取改为写入 Iceberg 表。如果你是 Fivetran 用户,可以使用我们的 Managed Data Lake 迁移工作流将现有表(包括历史数据)转换为 Iceberg。你数据仓库中的现有表将被透明地迁移为外部表,因此你的查询可以继续正常工作。 
  2. 重新配置你的转换任务,使其输出到 Iceberg。所有主要的计算引擎都支持输出到 Iceberg,所以这主要只是改一个设置的问题。如果你是 dbt 用户,可以使用我们的 Lake Compute 服务来执行 dbt 模型。它在实现中使用了 DuckDB 和单节点执行。
  3. 将选定的读取工作负载(如 notebook 和即席查询)迁移到使用本地算力。最便宜的 CPU 就是你桌上的那块!

利用廉价和免费的算力不仅仅是为了省钱。这意味着你不再需要对用户限量分配算力。AI 智能体已经让每个人都拥有了自己的分析师,可以回答他们能想到的任何问题,但前提是他们不会因为共享一个小而昂贵的计算集群而成为瓶颈。如果我们要把 AI 与数据连接起来,我们就需要开放的数据基础设施,利用我们周围无处不在的廉价算力,甚至就在我们的口袋里。

复现此基准测试的详细信息见 github.com/fivetran/iphone_benchmark

[CTA_MODULE]

直接阅读来自 Fivetran + dbt CEO 的更多见解

阅读更多

来源:Hacker News · fivetran.com