别再盲目上 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;
执行时：
- 自动分配计算节点
- 扫描数据
- 查询结束自动释放
你只看到 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
最后结果：
| 指标 | 改造前 | 改造后 |
|---|---|---|
| 运维机器 | 200台 | 20台 |
| BI延迟 | 40秒 | 5秒 |
| 成本 | 高 | 降低40% |
五、什么时候该用 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 不是万能架构，而是一个非常好用的工具。
用对场景：
成本低、效率高、开发快。
用错场景：
账单爆炸、性能糟糕、团队背锅。
技术从来不是问题。
真正的问题永远是：
架构决策的人有没有想清楚。
