极致性价比｜从存算分离到 Serverless，数仓要解决的关键问题

2024-12-19
浙江
本文字数：3229 字
阅读完需：约 11 分钟

Serverless 数据仓库面临的挑战

在存算分离的架构下，数据仓库可以利用云平台 IaaS 层的弹性能力，通过动态地申请机器资源构建数仓集群，在没有负载的时候，动态地释放机器资源，从而对用户提供 Serverless 的体验。这样可以有效地降低用户的成本，并提高资源利用率。用户无需关注底层基础设施的运维，只需专注于数据分析和业务逻辑。

本期，我们邀请质变科技AI-ready数据云团队布道师文军与大家分享话题《数据仓库：从存算分离到 Serverless》。

实现 Serverless 数据仓库，往往面临如下几个方面的挑战：

弹性伸缩的粒度: 如何更精细地控制资源的伸缩粒度，以及如何更快地响应负载变化，是 Serverless 数据仓库需要解决的关键问题。例如，面对突发流量高峰，如何快速高效地扩展计算资源以满足需求，避免性能瓶颈？同时，在负载降低时，如何快速释放资源，避免资源浪费？
冷启动问题：Serverless 数据仓库的一个挑战是冷启动问题。当一个新的查询请求到来时，如果所需的计算资源尚未启动，则需要一定的时间来启动和初始化，这会增加查询延迟。如何减少冷启动时间，提高响应速度，是 Serverless 数据仓库需要解决的重要问题。例如，可以采用预热池、快速启动技术等来优化冷启动性能。
查询性能优化: Serverless 数据仓库的性能受到多种因素的影响，例如计算资源的分配、网络延迟、数据存储的访问速度等。如何优化这些因素，提高查询性能，是 Serverless 数据仓库需要解决的重要挑战。例如，如何利用缓存技术加速数据访问？如何优化查询执行计划，减少计算量？
安全性: 在 Serverless 架构下，数据的安全性和访问控制也需要特别关注。例如，如何确保只有授权用户才能访问数据？如何防止数据泄露和恶意攻击？

冷启动问题

以基于云平台 IaaS + K8S 架构作为资源底座的架构为例，从申请机器资源到最终拉起数据仓库的服务进程，需要大致需要经过经历如下调用栈：IaaS -> K8S -> Pod（磁盘/网络挂载） -> 进程 -> 线程 -> 服务初始化逻辑。从向 IaaS 层发起请求到最终 Pod 拉起完成，往往就需要花费几分钟时间。这几分钟的资源申请延迟，往往成为数据仓库由存算分离到 Serverless 转型遇到的第一个拦路虎。这也是为什么不少数据仓库最开始声称具备"Serverless 能力"，本质上只是做到了 auto suspend、auto resume 的体验。

对于 Serverless 数据仓库而言，能接受的资源申请的延迟需要在百毫秒甚至是毫秒级别。这个延迟量级，在可预计的未来 Iaas + K8S 是无法达到的。并且从架构分层的视角来看，也不期望数据仓库层的流量同比例打穿到 IaaS + K8S，这样对于资源申请的稳定性来说也是非常大的挑战。

为了满足资源申请的低延迟诉求，往往需要采用预热池的技术，预先从 Iaas 层申请好机器资源。新的资源申请，优先从预热池申请，从而旁路掉 Iaas + K8S 的资源申请链路。同时后台异步预热池的容量，当机器资源过多时，将机器释放回给 IaaS 层，当预热池容量不足时，提前从 IaaS 层申请机器资源加入预热池。

当然，在 Iaas 层、K8S 层的快速启动技术优化，也是有必要的，当预热池出现容量不足情况时，可以加快预热池的水位补充。

弹性伸缩的粒度

当资源申请延迟解决后，Serverless 数据仓库又面临着一个严峻的问题：如何更有效地控制弹性伸缩的粒度以优化资源利用率和性能。

数据仓库的查询性能并不一定随着资源扩展而线性增长，这由数据并行、查询负载特征、集群规模等多维度的原因共同决定。以小数据量查询为例，查询本身处理的数据量并不大，随着集群规模扩大，任务下发的性能消耗占比可能上升，反而导致查询性能下降。

正因为数据仓库的规模与性能之间的不确定性，snowflake 官网建议使用 multi-cluster 来提升查询的吞吐。

Multi-cluster warehouses are best utilized for scaling resources to improve concurrency for users/queries. They are not as beneficial for improving the performance of slow-running queries or data loading. For these types of operations, resizing the warehouse provides more benefits.

另外，snowflake 建议 resizing a warehouse 来提升慢查询的性能。

Resizing a warehouse to a larger size is useful when the operations being performed by the warehouse will benefit from more compute resources, including:

Improving the performance of large, complex queries against large data sets.
Improving performance while loading and unloading significant amounts of data.

Amazon redshift serverless 团队则试图引入 Mosaic AI 来解决其 auto-scaling 问题，以期望在性能、成本之间取得比较好的平衡。

查询性能优化

与传统的数据仓库相比，Serverless 数据仓库在性能上存在天然的劣势，所有的数据都需要远程访问对象存储进行加载。因而，scan 算子往往成为查询最大的瓶颈，大部分的耗时消耗在远程对象存储的访问上。

local cache：local cache 看起来是解决该问题比较好的一个选择。通过将对象存储的文件 cache 到本地，并基于一致性 hash 的算法，避免不同节点间对相同文件进行冗余 cache，可以有效提升 cache 的命中率。
remote cache：local cache 虽然能获得极致的性能体验，但是 Serverless 数据仓库如果被高频释放，local cache 又会面临丢失的风险。像 snowflake 就建议针对不同场景设置不同的 auto-suspension time。为此，一个高效的 remote cache 服务，将 cache 与数据仓库的计算节点解耦，不失为一个比较好的选择。当然，对应的存储成本也会有所增加。

About the cache and auto-suspension

The auto-suspend setting of the warehouse can have a direct impact on query performance because the cache is dropped when the warehouse is suspended. If a warehouse is running frequent and similar queries, it might not make sense to suspend the warehouse in between queries because the cache might be dropped before the next query is executed.

You can use the following general guidelines when setting the auto-suspension time limit:

For tasks, Snowflake recommends immediate suspension.
For DevOps, DataOps, and Data Science use cases, Snowflake recommends setting auto-suspension to approximately 5 minutes because the cache is not as important for ad-hoc and unique queries.
For query warehouses, for example BI and SELECT use cases, Snowflake recommends setting auto-suspend to at least 10 minutes to maintain the cache for users.

成本优化

在确保机器资源弹起性能的前提下，预热池的容量管理是否做到足够优秀，就关乎数据仓库厂商的成本及利润空间。如果预热池有大量的空闲机器资源没被利用，这部分成本就由数据仓库厂商持有。如果预热池的空闲水位较低，则资源持有成本转移到云厂商身上。如何做好预热池的容量管理，既关乎 Serverless 的体验，又关乎数据仓库厂商的成本。

当前云厂商都推出了 spot instance，其价格往往只有普通 instance 的 1/10，但资源使用时长相对较短。如果在预热池中大规模地应用 spot instance，是一个比较好的选择，既确保了机器资源弹性的性能，又不会过多地增加资源持有成本。

在如何应用好 spot instance，对数据仓库的内核又提出了比较高的一个要求：需要解决好 spot instance 被回收对查询延迟、成功率带来的影响。这方面，Databricks 得益于 spark stage by stage 执行的容错能力，已支持选择 spot instance 来创建 instance pool。

创作场景