别再盲目上 Serverless 了：聊聊 Serverless 数据分析的真相、成本和适用场景

作者：Echo_Wish

很多人最近跟我聊天时都会问一句：

“Echo，数据平台是不是未来都会 Serverless？”

说实话，这个问题我听得有点多了。很多团队一听到 Serverless 数据分析 就两眼放光，感觉像找到了数据平台的终极答案：
不用运维、不用集群、自动扩容、按量付费。

听起来确实很香。

但我见过不少团队 上线三个月后账单翻倍，又灰溜溜迁回自建 Spark 集群。

所以今天咱们不讲宣传册里的 Serverless，而是聊点真实的：

Serverless 数据分析到底值不值得？什么时候该用？什么时候千万别用？

一、什么是 Serverless 数据分析？

简单一句话：

不用管服务器，直接跑 SQL 或代码，按使用量付钱。

典型代表：

• AWS Athena
• BigQuery
• Snowflake
• 阿里云 MaxCompute Serverless
• Azure Synapse Serverless

传统架构：

数据 → HDFS/S3 → Spark/Flink → 集群

Serverless：

数据 → 对象存储 → SQL查询 → 自动算力

开发体验大概像这样：

SELECT 
    user_id,
    count(*) AS orders
FROM orders
WHERE order_time >= '2026-01-01'
GROUP BY user_id
ORDER BY orders DESC
LIMIT 10;

执行时：

1. 自动分配计算节点
2. 扫描数据
3. 查询结束自动释放

你只看到 SQL。

服务器在哪？不知道。
多少节点？不知道。
运维？不存在。

二、Serverless 最大的优势

我总结过一句话：

Serverless 不是技术升级，是运维革命。

核心优势其实就三个。

1 不用维护集群

很多人低估了数据平台的运维成本。

传统 Spark 集群要维护：

• Yarn / K8s
• HDFS
• Spark版本
• Shuffle
• 容量规划

很多团队其实 30%时间在救火。

而 Serverless 的模式是：

对象存储 + SQL

举个例子：

直接查询 S3 数据：

import boto3

client = boto3.client("athena")

query = """
SELECT count(*)
FROM logs
WHERE day='2026-03-01'
"""

client.start_query_execution(
    QueryString=query,
    QueryExecutionContext={"Database": "analytics"},
    ResultConfiguration={"OutputLocation": "s3://query-result/"}
)

你甚至不用启动 Spark。

2 自动扩缩容

传统集群的问题：

高峰期资源不够
低峰期资源浪费

Serverless 的逻辑是：

任务来了 → 自动扩容
任务结束 → 资源释放

比如：

一个 BI 查询突然需要 500 个并发节点。

Serverless 可以瞬间扩容。

自建 Spark 集群？
可能得提前准备几十台机器。

3 成本按查询付费

很多云厂商的计费方式：

按扫描数据量收费

例如：

$5 / TB 扫描

如果查询只扫描 10GB：

成本 = 0.05$

这对 轻量分析场景 非常友好。

三、Serverless 的真实问题

很多文章只讲优点，但我更想讲讲 坑。

1 成本失控

很多团队上线后发现一个问题：

账单不可控。

原因很简单：

查询扫描数据太多。

举个例子：

假设表是 5TB。

一个简单 SQL：

SELECT *
FROM logs
WHERE user_id = 1001

如果 没有分区：

扫描 5TB。

成本：

5TB × $5 = $25

一个 BI 看板每天跑 100 次：

$2500 / 月

所以 Serverless 的核心优化：

一定要做好分区。

比如：

s3://logs/year=2026/month=03/day=10/

SQL：

SELECT *
FROM logs
WHERE year=2026
AND month=3
AND day=10
AND user_id=1001

扫描数据从 5TB → 20GB。

成本瞬间降 200 倍。

2 延迟问题

Serverless 有一个天然问题：

冷启动延迟。

很多查询需要：

3 ~ 10 秒启动

对 BI 系统来说：

用户会觉得卡。

很多公司后来会做混合架构：

实时 → ClickHouse / Druid
离线 → Serverless

3 SQL 成本很难预测

开发时经常遇到：

两个 SQL 看起来差不多，但成本差十倍。

例如：

SELECT count(*)
FROM logs
WHERE day='2026-03-10'

vs

SELECT *
FROM logs
WHERE day='2026-03-10'

第二个扫描更多列。

成本直接上升。

所以数据团队必须建立：

Query Review 机制。

四、一个真实案例

我之前帮一家互联网公司做过数据架构升级。

他们原来的架构：

Kafka
 ↓
Spark
 ↓
Hive
 ↓
Presto

问题：

• 集群 200 台机器
• 运维成本高
• BI 查询经常排队

后来改成：

Kafka
 ↓
Flink
 ↓
S3 Data Lake
 ↓
Athena / Trino

关键优化：

数据分区

s3://datalake/orders/year/month/day

Parquet 格式

压缩率提升：

10TB → 2TB

列式扫描

SQL：

SELECT 
    country,
    count(*) AS orders
FROM orders
WHERE year=2026
AND month=3
GROUP BY country

扫描数据：

200GB → 12GB

成本：

$0.06

最后结果：

五、什么时候该用 Serverless？

我一般给团队一个简单判断。

适合 Serverless：

• BI 查询
• 数据探索
• 数据湖分析
• 偶发任务
• 数据科学

不适合 Serverless：

• 高频 ETL
• 实时计算
• 长时间任务
• 高频 API 查询

比如：

实时推荐系统：

QPS 5000

Serverless 基本不合适。

但 运营分析系统：

每天几十次查询

非常合适。

六、未来趋势：Data Lake + Serverless

数据架构正在变成：

Object Storage
   +
Serverless Compute

核心理念：

存算分离。

未来的数据平台可能是：

S3 / OSS
   +
Athena / BigQuery / Snowflake
   +
实时引擎

甚至很多团队正在尝试：

Lakehouse

比如：

• Iceberg
• Delta Lake
• Hudi

让 Serverless SQL 直接查询数据湖。

最后说点真心话

很多技术都有一个阶段：

新技术 → 过度吹捧 → 理性使用

Serverless 数据分析现在正处在 第二阶段。

我的观点很简单：

Serverless 不是万能架构，而是一个非常好用的工具。

用对场景：

成本低、效率高、开发快。

用错场景：

账单爆炸、性能糟糕、团队背锅。

技术从来不是问题。

真正的问题永远是：

架构决策的人有没有想清楚。