火山引擎 ByteHouse：4000 字总结，Serverless 在 OLAP 领域应用的五点思考

更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群

作为云计算的下一个迭代，Serverless 可以使开发者更专注于构建产品中的应用，而无需考虑底层堆栈问题。伴随着近年来相关技术成熟度的增加，市场对 Serverless 的接受程度也变得越来越高。可以说时至今日，Serverless 已迈入了向成熟稳定方向发展的高速轨道。

作为一款火山引擎推出的云原生数据仓库，ByteHouse 基于开源 ClickHouse 构建，并在字节跳动内外部场景的检验下，对 OLAP 引擎能力、性能、运维、架构进一步升级。除此之外，ByteHouse 也在 Serverless 方向探索，基于 cloud-native 云原生的理念构建了全新一代的数据仓库，架构上进行了三层解耦，期望在 Serverless 的加持下，提供更稳定、可靠、可信的分析服务，让开发人员时间精力从基础设施运维优化上解放，更聚焦在核心业务功能中。

本文来自于火山引擎 ByteHouse 产品负责人李群的分享，从场景选择、应用门槛、落地应用等 5 个方面，介绍 Serverless 在 OLAP 领域应用思考。

哪些应用场景适合选择 Serverless 架构？

在 OLAP 数据分析领域，我们先看哪些分析模式不适用于 Serverless 架构：

1. 长任务，大 Job：如果分析任务需要长时间运行（如超过 20 分钟），使用 Serverless 技术会受到限制。因为 Serverless 平台通常设置了最大运行时间的限制，超过限制时间会导致任务中断。

2. 计算密集型：Serverless 技术通常适用于处理轻量级任务，而对于高计算密集型任务，需要更多计算资源，但行业上目前当前尚未有商用的 Serverless 数据仓库能够提供超过 2000 vcore 的算力规模，而 2000vcore 折算成通用的物理机或裸金属，也不过是 20 台服务器的算力规模，往往一些中型的分析型系统的算力需求就远远超过这个规模。

3. 高并发读写型：Serverless 技术特点是资源共享，对有高并发诉求的分析任务，很可能会出现性能瓶颈，一方面原因是共享资源池的规模上限，一方面是多租户对共享资源的争用。

4. 负载模式稳定、波动少：Serverless 平台通常是按需运行，如果需要长时间运行的应用程序，则不适合使用 Serverless 技术。

总之，Serverless 技术适用于处理轻量级、耗时短、低并发型的分析业务，适用于负载模式有明显波动性特征的业务；也适用于管道型、中间件型的业务，如 flink 实时计算、kafka 消息队列以及 ETL 任务执行等。

对于长时间运行、计算密集型、高并发读写、需要持续运行的分析业务则不适合使用 Serverless 技术。

应用 Serverless 技术存在哪些门槛

在 OLAP 领域，无论是经典的 MPP 架构向 Serverless 架构演进路径，还是基于 Cloud-Native 云原生理念全新构建的 Serverless 架构，都面临着同样的技术挑战：

1. 存算分离

把计算和存储进行解耦，是 Serverless 架构关键的第一步，但其中的技术挑战非常大，例如：如何保障性能少劣化甚至不下降；近数据计算(NDP)技术，把哪些算子下推到存储侧；分布式缓存技术如何提高缓存的命中率，这些目的都是尽可能减少计算和存储之间的网络开销。

此外，从 25GE 网络，到 RDMA/RoCE 等高速网络，再到下一步的内存型网络的融合，如何减少延迟、提高吞吐也是业界在持续解决网络通信层面的难点之一。

1. 计算无状态

计算侧通常还是采用经典的 shared-nothing 架构，具备良好的水平伸缩扩展性，但是计算侧的无状态化程度直接关系到弹性能力的优劣，这其中元数据的管理和同步、统计信息的自动化、优化器的智能化都是关键的技术难点。

形象一点描述，则是，在弹性过程中，背负东西越多，状态化越重，弹性效率就越低，用户体验越差。

1. 全局资源调度

存储资源池化、计算池化、网络池化，未来还会实现内存池化等，而且理想的 Serverless 架构需要能够自动地根据用户请求的负载进行智能的动态伸缩，在不需要时自动释放资源，业务浪涌时自动分配更多资源。以上对全局的资源调度能力提出了更高的要求。

1. 混合负载

在 Serverless 架构下，不同的租户在同一个计算资源池里提交各种类型的分析任务，如何给上层应用提供稳定可靠的 SLA 保障，混合负载管理的难度被进一步放大。

基于静态化的配额负载策略很难在 Serverless 的多租户模式下落地，需要逾越智能、动态的资源分配、限流、熔断等负载管理的技术难点。

如，“低效 SQL 耗尽资源”的老大难问题的影响半径在 Serverless 模式下会被放大，甚至是灾难性影响。

1. 资源池上限

Serverless 模式下，多租户都在共用一个资源池，理想上这个资源池应该可以无限扩展，但当前只有存储侧基本上做到这一点，计算侧资源池还是受限于软件能力会有一个天花板上限，比如说目前几款主流云厂商的 Serverless 的数据仓库还没有超过 2000vcpu 的算力规模。如果再叠加多租户并发的因素，将导致当前的 Serverless 架构在 OLAP 分析领域还比较难以大规模推广使用。

此外，旨在进一步降低计算侧负载而引入新硬件并提供池化服务，比如 FPGA 资源池，也是当前云场景的发力方向。围绕 Serverless 架构下的全场景多层级的数据安全也是要考虑的关键问题。

这里简单给大家分享一下 ByteHouse 在这方面的一些思考和实践：

ByteHouse 基于 cloud-native 云原生的理念构建了全新一代的数据仓库，架构上进行了三层解耦。由下向上看，

1. 在存储层，ByteHouse 已经实现了 Serverless 化、弹性伸缩、容量无限扩展。为提升存算分离架构下的性能问题，在存储侧做了一系列的技术优化，比如

   针对 HDFS 语义，合并小文件减少文件数、改进的 Hedge Read、Fast Switch Read 等使得带宽仅增加 10%的情况下，延迟减少 3 倍；

   针对 S3 语义，通过 memory cache、独立 IO 线程池等技术提升数据的存取性能。

2. 在网络通信上， 连接复用、RDMA、传输压缩等技术，大幅缓解了网络放大问题。

3. 在中间的计算层，ByteHouse 是通过 virtual warehouse 为用户提供弹性的计算服务，提供 pay as you go 的记账模式，为用户节省成本。

     在技术上，ByteHouse 实现了无状态化，基于容器化部署、秒级弹性伸缩、秒级按需启停。ByteHouse 增强的本地缓存技术，使得数据预热、预取更加智能高效，缓存数据的命中率也更高。

     在计算层，ByteHouse 通过不同的 VW 来做负载隔离，如按读写进行隔离、按应用类别进行隔离，这种 tenent-aware 租户感知的负载隔离模式虽然还不是 Serverless 模式，但是能在一定程度上满足用户的需求，也是向 Serverless 架构演进的路径之一。

4. 在最上层的 cloud services 云服务层，ByteHouse 提供集中化的 catalog 元数据服务、集群管理服务等。我们把元数据从计算层解耦出来，让计算层实现了无状态化，获得了秒级的弹性伸缩和启停能力。基于分布式 KV 的元数据存储，通过高效的 part 缓存技术，也进一步提升了元数据的访问性能。

如何看待可观测性和 Serverless 哲学相悖的问题？

随着 Serverless 的深入，人们发现 Serverless 架构下的问题定位比传统应用更困难。对此，一部分人认为应该支持可观测性的需求，另一部分人则认为可观测性与 Serverless 本质相悖，Serverless 就是为了让用户不需要关心底层计算资源情况。

我认为，这个问题本质上是跟当前 Serverless 技术成熟度相关。举个例子，现在我们每天都在用水、用电，但是很少有人会再去关注怎么发电、如何配送，饮用水的处理环节等等，因为我们得到的用水、用电的服务标准是稳定的、可信的和可靠的，所以不再关注过程细节。

与此类似，Serverless 要实现的目标就是提供稳定、可靠和可信的分析服务，让开发人员不再把时间和精力花费在下层的基础设施和运维优化上，而是聚焦在业务功能的实现上面。

但是当前 OLAP 数据分析领域的 Serverless 技术成熟度还远未达到这个目标，前面提到的一系列技术难点尚未完全解决，最简单的例子是如何解决困扰业界 40 多年的“低效 SQL 耗尽资源”的老大难问题，在 Serverless 模式下，账单跟资源用量紧密相关，账单上资源用量的合理性、可信性是客户当前的最大疑虑。

此外，通过日志记录、 跟踪监控、可视化指标等技术工具为用户提供过程中的可观测性，也是 Serverless 平台应该具备的能力，也能够增加用户对系统的信任感。

因此，两者并非相悖。我们相信会有一天 Serverless 会给用户带来标准、稳定、可靠、可信的分析服务，就像我们今天用水、用电一样。

落地 Serverless，自研和云厂商方案如何选择？

21 世纪最宝贵的还是人才。对企业来说，每一笔投入的目标都是围绕着如何去获取更深入本质的分析洞察、更灵敏的风控感知和预警、更快速的用户增长，所以说，企业的 IT 更多的是站在开发的视角去看待投入决策，使能业务，并能更近一步，让 IT 从传统的成本中心向赋能中心、盈利中心去演进，人才储备的重点是技术开发方向。

而云厂商的商业逻辑是为用户提供标准的云计算技术服务，通过持续、高强度的研发投入，为用户提供差异化的云服务，人才储备的重点是技术研发方向。开发和研发，仅一字之差，但含义迥异。

特别是对于 OLAP 领域的 Serverless 技术实现来说，涉及到存储、网络、操作系统、数据库、AI 等 IT 领域几乎全栈的技术点，更需要厂商做持续的、高成本的研发投入，而且这些投入短期内难见市场回报，一旦中途停顿则意味着前期的投入全都“打水漂”。

所以，对中小企业来说，还是建议在 OLAP 领域的 Serverless 技术投入上保持慎重态度，对 Serverless 的技术研发、演进迭代还是交给技术人才储备更雄厚、技术投入也更专业的大型云厂商来做。

Serverless 距离大规模应用还有多远？

在 OLAP 数据分析领域，虽然已经有几款商用的 Serverless 架构的数据仓库，但是前面提到的技术难点依然存在、尚未逾越，并且期提供的算力规模也很难支撑中大型规模的数据仓库或者分析平台的需求。

但是，Serverless 的架构理念还是面向未来的，而且技术挑战也会随着时间的推移会有更好的应对方案和措施，并且当前也能够在部分中小型分析负载场景中适用和推广。

最后想提一点，影响 Serverless 大规模应用的因素，除了技术层面持续演进和迭代之外，另外一个非常关键的就是 Serverless 服务的标准化，尤其是对 OLAP 分析领域。Serverless 的初衷是让用户聚焦在业务实现上，但没有一个标准化的规范会导致用户被平台锁定，无法实现应用的平移、无缝搬迁，比如，用户无法把基于 MySQL 的应用无缝搬迁到 PostgreSQL，因为下面的数据库是 Serverless 了，但是与业务逻辑进行交互的接口还没有标准化。因此，Serverless 的规模化应用，还需要有与之配套的标准和规范体系。

总而言之，Serverless 架构已经越来越受到欢迎，随着云计算和 Serverless 技术的进一步发展和完善，Serverless 架构将在未来成为更多大规模应用的首选架构之一，用户会像今天用水、用电一样，方便、快捷地享用 Serverless 化的 OLAP 数据分析服务。

点击跳转ByteHouse了解更多