云器Lakehouse：Multi-Cluster弹性架构如何实现湖上高并发低延迟分析

导读

在当今快速发展的大数据时代，数据平台的性能和效率对于企业来说至关重要。云器Lakehouse的Multi-Cluster弹性架构为我们提供了一种全新的视角，以应对数据湖上高并发和低延迟分析的挑战。本文将深入探讨云器Lakehouse如何通过其独特的技术理念和架构设计，实现在数据湖上进行高性能实时分析的目标。

本次分享会围绕以下几方面展开：

• 面客实时分析场景对数据平台的要求

• 基于数据湖实现高性能实时分析的挑战

• 云器Lakehouse存算分离架构下实现高性能实时分析

• 典型案例分析

• 总结

面向客户的实时分析场景对数据平台的要求

实时分析不同于传统的BI分析和流式分析，常用于面向客户的数据产品。常见的分析场景主要有以下三类：

• BI分析：常见的 BI 分析场景对并发要求不高，分析相对比较复杂（如钻取），对查询的要求相对中等。
• 流式分析：比如常见的风控实时大屏，对数据的时延要求非常敏感，但对并发要求不高，数据处理规模通常不会特别大。
• 实时分析：要求数据要及时，查询很快能拿到结果，同时能够支撑比较大的并发，很可能有成百上千人在同时使用这个数据产品。另外，查询有简单的查询，也会有较为复杂的查询，要求数据范围更广。

本文重点介绍的是实时分析场景，实时分析常见于面客(Customer-facing)的数据产品，对查询数据的新鲜度、查询时延、并发、实时和历史数据的实时对比分析都有很高的要求。

基于数据湖实现高性能实时分析的挑战

在上述要求下，现在非常流行数据湖架构和湖仓一体架构。数据湖天然具有很多优势：

• 低存储成本，所有的数据可以放在统一的存储上，减少冗余。
• 扩展性较好，可以很好地做存算的分离。
• 统一的数据管理能力，支持批量更新、删除等能力。
• 多场景支持，能够很好地支持批、流、分析、 AI 等处理场景。

在数据湖上做数据分析，也面临一些挑战：

• 存算分离架构，计算和存储离得比较远。数据湖存储本身面向吞吐，时延 IO 性能不是特别好。在数据湖的解决方案中，主流的数据湖查询引擎，并发能力往往不太突出。这也是我们能看到市面上开始流行一些并发性能更好的分析引擎的原因。
• 由于数据湖的写入需要去落文件、管理Meta，写入的频率不能太高、间隔也不能太短，否则对 Meta 压力很大，往往做不到低延迟的写入可见性。
• 严重依赖缓存，其实数据能够被缓存的话，可以获得较好的可预测性能。而一旦有新的数据进来，或者是不在缓存中的历史长周期的数据，整个的性能抖动就会非常明显，这对于分析数据产品来说，往往是不可接受的。
• 因为数据湖要存大量的数据，随着数据的变化更新，数据规模的增大，在湖上建数据分析产品，查询的性能会逐渐地劣化。

怎么才能够更好地发挥数据湖的优势，解决这些实时的挑战呢？

云器Lakehouse：“Single-Engine”为技术理念的数据平台产品

云器在产品设计之初，就考虑到了这些分析场景。产品的设计要点如下：

• 所有的云器产品，有两种部署模式，云上的多云 SaaS 服务，以及大型客户的私有云部署。
• 使用对象存储，通过一套元数据去管理结构化数据和非结构化数据。
• 作为一个 SaaS 化的多租户系统，我们会维护一个大的 serverless 弹性资源池，客户在使用的时候能够快速地按需使用资源，不用的时候可以交还给云器，减少不必要的资源持有成本。
• 在计算侧，基于这样一个大的资源池，云器的产品支持创建多计算资源，相互隔离互不影响。资源有很好的弹性，能够独立地伸缩，根据并发场景做快速的弹性来满足用户侧的并发变化。
• 我们的核心特性是基于一套自研的 SQL 引擎，支持常见的大数据处理ETL、流式处理，提供基于增量计算这种近实时的流式处理，基于一套数据，可以在数据集上直接进行在线的交互式分析。
• 为了保证整个系统的数据能够很好地处理流式数据，我们设计了实时的写入服务能力。提供 Streaming 的 API，能够把流式数据很好地写入进来，支持秒级可见。
• 更上层，是一套 SaaS 化的服务，产品内建了数据同步、数据开发、监控运维、数据资产管理、数据质量等工具。将这些日常使用的开发管理工具，做成一体化的产品，以Web应用的形式对外提供服务。

1. 基于Multi-Cluster弹性、实时架构，应对规模化的实时数据和查询并发挑战

前文中提到，数据湖并不太适合做实时化的作业，而且数据湖上的加速分析引擎往往对并发支持也不够好，云器基于 Multi-Cluster（多计算集群）+ 实时化的架构（多集群的弹性和实时化的架构）来应对这样的挑战。

传统的MPP架构，是存算耦合的方式（如图左半部分），每个节点有自己的分片数据单独做处理。这种紧耦合带来的挑战是数据一旦需要扩展，就要重新分布，会对业务造成影响，很难做到快速扩展。同时这种模式，对实时写入的支持也不够友好，当然很多厂商也在做进一步的优化。

受制于这样一个存算耦合的架构，整体的扩展性和弹性是相对偏弱的。同时 MPP 架构，在传统的 Lambda 架构里常用于做 OLAP 分析，对接 BI 报表。它的批处理数据的准备、数据的加工往往需要和大数据批处理系统结合，把加工好的数据再导入到里边，会产生额外的数据冗余和整体系统的复杂性。

云器从以下几个层面来解决上述问题：

• 读写分离：采用存算分离的架构，数据和计算无关，计算可以独立地扩展，不受存储的影响。同时为了更好地应对实时数据的挑战，我们设计了一套实时摄取的服务。常见的数据库 Binlog 的 CDC 写入、 Kafka 消息服务的写入，都可以调用streaming 的 API 快速地写入，写入之后秒级可见。
• 支持基于主键的更新，基于这样的读写分离的架构，数据的写入后使用单独的集群读取、处理、分析数据，写入任务不影响数据加工和分析，它们之间做到了解耦。这样一个独立的写入服务本身具有很好的伸缩性。在实践中，能够支持每秒千万级TPS的写入吞吐，很好地解决了数据新鲜度和规模化的问题。
• 在计算层，Multi-Cluster 有两层含义。第一层含义是，不同的计算任务有独立的计算集群，它们共享一份数据，但计算是隔离的，这是多计算集群的内涵之一。第二层含义是，计算资源支持垂直和水平的弹性伸缩能力。举例来说，当数据产品刚刚上线的时候，使用率并不高，随着数据产品的推广，大量的用户开始使用，并发就会更高，对于平台的诉求就是能够很好地去承接变化的高并发需求，这也需要计算资源具备很好的弹性能力。Multi-Cluster 的核心是一个计算资源里有多个可独立承担并发任务的计算资源。
• 前文提到数据湖严重依赖缓存，我们设计了cache机制，基于数据湖上对象存储的一份数据，提供动态的cache 能力，cache 本身随整个计算资源的生命周期产生和消亡。当创建计算资源时，查询会把数据拉到本地cache，当释放掉资源的时候，cache本身也会销毁掉。通过这样一套模式来更好地利用本地计算资源的本地cache。
• 分析引擎：云器产品内置的 SQL 引擎是其核心的一个差异化点，我们自研了一套 C++ 的高性能更新引擎。一个独特的优势是这套 SQL 引擎支持不同的负载模式，使用不同的任务调度模式来满足。比如常见的数据加工场景，往往需要基于任务独立申请资源，基于 DAG 依赖关系的调度模式来更好地保持吞吐和可靠性。分析场景，往往需要 MPP 以及 Pipeline 的执行模型来更好地支持加速分析和高并发。
• 一体化：所有对用户的接口，都是一套 SQL 语法来满足批处理、流式和分析。

2. 弹性并发（Concurrency Scaling）以低成本满足动态变化的分析要求

弹性并发方面，常见的方案是使用固定的计算资源，比如要支持 200 位用户的并发使用，需要申请12个计算节点，即使没有人访问，这12个计算资源也一直占用着。如果突然有业务峰值，业务方需要提前提出扩容诉求，才能进行扩容，造成了很多的资源浪费。由于用户的请求是动态的，用户什么时候来访问、分析数据产品是不确定的，所以这种固定资源 + 容量规划的模式往往滞后于用户的使用，会造成用户体验的下降。按峰值规划又造成了资源浪费。

在云上我们借助云原生能力把计算资源虚拟化，通过大的 Serverless弹性资源池，能够快速地申请资源。云器产品中，我们抽象了资源对象VirtualCluster 虚拟集群，集群本身有纵向和横向扩容的能力。如上图右侧所示，用户在创建计算资源的时候，可以选择资源的大小（纵向扩容）和并行计算实例的数量（横向扩容）。如果把方框看成一个计算资源的话，用户的 Query 是下发给计算资源的。内部至少包含一个计算资源实例，资源规格在创建时指定，并可以快速调整。同时也可以通过设置整个资源的最小实例数和最大实例数，形成从实例 1 到实例 10 的多计算集群资源模型。

举例来说，某个数据产品需要支持最高80个并发请求。在设计资源的时候，我们创建了1~10 的资源实例，每个资源实例支撑 8 个并发，当有 80 个并发同时来的时候，通过横向的动态扩容，可以毫秒级地将资源实例弹出来，把新增加的并发请求接住。由于是毫秒级的弹性能力，所以客户是无感的，几乎不知道资源做了扩容。当用户的请求负载下降，能自动回缩，这样整体的资源成本会很低。举例说明：单个计算资源实例在 8 并发时，可以保证每个实例下 P99 的查询都小于 1 秒，这是我们对业务方的承诺。通过设置最大实例=10这样的方式，当有 80 个并发来的时候，横向扩展出 10 个计算实例，通过横向扩容能够保证每个用户的查询都可以达到 P99的SLA，这也是云器的一大亮点，能够精细地控制资源和并发延迟之间的线性关系。

3. 使用Preload cache提升实时查询的性能稳定性，消减实时数据带来的查询抖动

前文中提到，数据湖天然要对数据做持久化，所有的数据进到湖里，要先落盘做数据持久化，防止数据丢失。之后这些数据就在对象存储上，可以视为冷数据，查询延迟会较高，在分析时就会导致很多查询抖动和毛刺。

云器提供了 Preload cache 能力，主要面向两种场景：

• 离线场景，数据本身是 T+1的，数据的变化不高频，只要定期及时地把 T+1的数据加载到本地缓存就可以了，这样分析就是稳定的，类似于存算一体的 MPP。这里采用的方式是创建计算资源的时候，增加 Preload 的参数，能够把数据产品涉及到的表都配置进来，系统自动根据配置把数据拉到 cache 中，不再根据用户的 Query 去唤醒。
• 实时分析场景，有大量的流式实时数据，比如订单数据，每秒都有大量的变化。这些数据往往要被及时地分析，云器在数据写入持久化的同时，立即主动 trigger 一个 cache动作将心数据缓存至 计算集群的本地缓存中。通过这样的方式，能够有效避免大量地读冷数据，从而保持对业务的高SLA。举个实例（如右图），以TPCH 100G数据测试，如果这些数据100%都是在本地cache中，整个的查询时延很低，9秒即可完成。如果有30%数据在对象存储上，整个查询时延就要翻倍。特别是实时分析场景里有大量实时更新的数据进来，即使有1%，也会极大地拉低整个的查询延迟。这也是为什么我们去做Preload的工作。

4. 借助自动化、智能化的托管能力，降低性能优化投入、支持分析应用持续高效运营

产品建设初期，因为数据规模不大，使用的人也并不多，性能容易得到保障。随着产品的持续运营，数据规模和用户量都不断增长，就需要一些手段来持续优化。云器提供了一些手段来自动管理。

• 全托管、免运维：提供全托管、免运维的 SaaS 化服务，用户不用考虑底层的基础设施，我们有专业的团队做相关的运维，监控底层的基础设施，提供商业化的 SLA保障。同时会以比较高频的节奏做版本迭代，增加功能、提升性能，整个服务是通过客户无感知的方式自动做升级。同时我们有大量的自动化服务，比如 Compaction 合并小文件，特别是实时场景有大量的小文件，这些数据往往需要去做更好的数据分布和收集统计信息，这些工作都由系统自动化地完成。
• 自助管理能力：弹性计算资源，通过 SQL 接口或者 Web UI 接口，能够让分析人员、一线的业务人员直接创建、管理、销毁、扩缩容资源，不用再依赖 SRE 或者平台团队人员，能更好地实现资源使用的民主化。数据排布上，有大量的优化手段，比如对慢查询可以做针对性的优化，同时也提供了配套的监控诊断工具。
• 自动化/智能化：有些部分通过 AI 的方式驱动。比如数据排布的场景，很多分析查询往往需要做字段的快速过滤，因此建数据模型时会建 Sort 的模式，提升过滤效率。随着新的数据不断进来，Sort 本身的排序就不好了，系统会自动帮它做排序。另外还可以做自动的文件大小处理，分析场景的热数据文件往往较小，能够被快速地去分析检索；当这些数据变成冷的历史数据的时候，更多要考虑历史查询的成本，需要把单个文件变大，优化吞吐。同时还提供了索引推荐，基于算法找到热点的Key进行推荐。Cache方面，包括自动/主动的cache，也支持偏分析场景的 result cache。在数据的建模方面，有AutoMV，能够基于算法模型，结合日常的作业模式，在ADHoc或者 BI 分析和ETL 场景下，都能够找到其中的Pattern，主动地帮你做中间层的模型，生成物化视图，这样作业不用改就能做透明加速。

典型场景分析

接下来结合一个例子，来对产品核心功能进行展示和讲解。

以SaaS 企业的实时运营分析为例， SaaS 企业里有很多的多租户数据在数据库中产生，有大量的分库分表。这类场景，往往需要将这些交易订单数据快速地分库分表地合并到数据仓库中，并立即开放给租户进行数据分析，几乎没有任何的数据加工。

这里具体展示的场景是，数据来自于数据库qn_pg，通过日志模式去订阅它的 CDC 数据。产品具有实时同步的能力，能够支持多表一键同步。例如订阅了一张表，把这张表同步到云器Lakehouse的表中。

任务创建完之后，可以看到，能够以秒级延迟的速度，将最新的数据写入到 Lakehouse中。

从云器的 Lakehouse中检查一下新写入数据的新鲜度，能看到即时增加的数据，这些数据都是通过主键的方式实时更新进来。

实时数据通过运营大盘展示给客户。上图中的DashBoard包含8个Query，能够查询到最新的实时的数据。

上图中可以看到在BI报表查询时发起的query，这些 query 在云器平台能够以毫秒级的延迟完成。

再来展示一下弹性计算能力。

刚才是单并发，单个计算资源是 8 并发。同时创建 4 个这样的计算实例，同时可以支持 32 并发。

以我们的压力测试工具来验证，每个作业跑 100 遍， 以 32 个并发连接，不停地去发。可以看到并发情况，32并发，整个 QPS 在 120 秒，每个 query 在百毫秒就已经结束了。这就是客户端查询的情况。

这些 Query 的查询延迟分布是在一个比较低的水位上，P99在百毫秒级别。

这就是前文讲到的，通过多并发的横向扩展能力，支持精细的并发控制，以满足业务的并发和延迟的要求。

刚才是使用了 4 个计算资源，现在调整为一个，也就是默认只启动一个资源，后面三个是不启用的。只有当并发来的足够多，超过 8 个的时候才去弹性伸缩。

进行同样的测试，同时发起 32 并发。

可以看到，由于并发请求触发了计算资源的自动的横向扩容，计算实例由1个变成4个。在这个场景，整个 Query 的延迟还是保持在比较低的水平上， P99 也没有明显的变化，还是能够满足业务SLA。

从上面的演示可以看到，单个用户可以达到毫秒级的查询体验，当多并发时，仍能够通过弹性能力，让每一个用户在其 BI 产品上得到相同的体验。

总结

本次分享主要探讨了如何在数据湖上更好地实现高并发、低延迟。主要包括三个关键点：

• 充分利用弹性能力提升性能、降低成本。云器Lakehouse具备很好的分析加速引擎能够支持多并发，同时借助云原生的能力在横向、纵向上的快速弹缩能力，能够快速匹配业务的弹性要求，无需提前进行业务容量预估，就可以及时满足业务需求。
• 实现湖上数据的实时更新、主动cache，保障数据新鲜度和分析性能。特别是实时数据的cache，我们通过 Preload cache 的方式能更好地破解挑战。
• 借助自动化、智能化的平台托管能力，持续优化分析性能。丰富的配套工具和产品化的管理能力，能够为业务、开发和分析人员助力，同时我们也希望能够提供更多智能化的方式，持续地去做产品的优化。

问答环节

Q1：云器支持事务吗？A1：不支持数据库级别的事务，更多使用分析场景中的版本事务隔离。
Q2：查询引擎是基于 C++ 实现的吗？A2：是的，我们的引擎核心分为两部分。我们的编译器、优化器这是一套。然后从执行引擎上，根据两种不同的业务负载模式，我们实现了两种不同的任务调度模型。所以从用户的接口层面，我们能用一套的 SQL 语法和接口。从执行上，可以显示地创建不同的计算资源来拉起不同的执行引擎，分别去面向批处理、分析场景进行优化。
Q3：目前增量这块只支持微批实现吗？纯流有做吗？A3：我们的微批可以做到一分钟级别，已经能满足很多场景，熟悉这个领域的话都知道，在很多场景上做到分钟级的这种实时微批已经是非常大的挑战了。实时的这部分也在我们的规划中，后续会分享更多进展。关于增量计算，后续也会有单独的专题来介绍。
Q4：跟 Spark 还有 Flink 的整合如何？A4：跟 Spark 和Flink的整合后期会有另外的专题来介绍。云器内部只有一个 SQL引擎，没有 Spark 或 Flink 引擎。但是支持Spark、Flink、Presto这些引擎来访问。访问的方式不一样，比如 Flink 访问云器Lakehouse，更多的是通过的 Connector 方式去调我们的实时写入的 API， 能实时地写进来。Spark 访问云器Lakehouse的时候，更多的是希望直读存储以提高吞吐，所以我们在整个的元数据系统设计之初就考虑了开放性，提供云器Catalog 的SDK， Spark 可以直接使用我们的 Catalog 的 SDK 包，通过云器产品的用户名和密码授权地对接到云器的数据，访问底层的存储群。

往期推荐

点个在看你最好看

SPRING HAS ARRIVED