PB 级数据秒级分析：腾讯云原生湖仓DLC 架构揭秘

微信邦

导读｜过去几年，数据湖能力已经在腾讯内部包括微信视频号、小程序等多个业务大规模落地，数据规模达到 PB至 EB 级别。在此基础上，腾讯自研业务也启动了云原生湖仓能力建设。云原生湖仓架构最大的挑战什么？腾讯云原生湖仓 DLC 从哪些方面着手解决问题？接下来由腾讯云大数据专家工程师于华丽带来相关分享。

云原生湖仓的诞生背景、价值、挑战

当前这个阶段，相信大家对于数据湖，数据仓，湖仓一系列的名词已经不算陌生了，我用最直白、最狭义方式去解释“湖仓”的话，就是数据湖跟数仓存储架构统一。

数据湖最初的需求是，要存储和分析海量的半结构化、非结构化的数据，以及数据仓备份和温冷数据存储。在公有云找到了对象存储（海量、低价、高 SLA 和高可靠性）这样一个全托管的存储产品后，成本方面对象存储对比客户 HDFS 自建大概为 1：10，非常有吸引力。

这个存储系统看起来这么好，有没有可能把数仓一起解决，结构化数据是不是存在这里？伴随着这个需求的升级，现代湖仓架构的基础也随之产生。

云原生湖仓又是什么呢？最狭义的理解就是容器计算 + K8s。更加广义的理解应该长在云上，更多的使用云上已有的全托管产品，比如利用对象存储、本身服务云原生化等。

在云原生湖仓架构下，会面临很大的挑战就是“性能”。为什么有“性能”的挑战？第一：对象存储有很好的成本优势，但是引入对象存储之后变成了存算分离的架构，损失了本地计算，整体性能损失 30% 以上；其次弹性计算跟分析性能是矛盾的变量，ScaleUp 需要时间，甚至有可能弹不出来，没有文件缓存，弹性会引起数据倾斜；最后是敏捷分析，海量明细数据直接分析也是很直接的需求。

腾讯云原生湖仓产品 DLC 如何应对挑战

1）DLC 产品定位

DLC 的第一个特点，简单三个字概况便是——“全托管”，不同于 EMR，DLC 是开箱即用的，例如交互界面、元数据、安全、Spark DDL Server、Spark History 服务等都是全托管、免搭建的，甚至有很多是免费提供的。

第二个特点，DLC 是腾讯云数据湖解决方案的粘合剂，不同产品能够用一份湖仓数据，带给用户低成本，低维护成本的价值。

2）DLC 架构理念

接下来讲 DLC 的架构理念。DLC 是腾讯大数据自研能力的上云，但是并不是简单平移部署，产品形态便是最大的差异。DLC 是多租户的全托管产品，我们秉持两大原则：保持简单 KISS、云原生。保持简单上我们是非常执着的。

对于服务引用非常保守，服务能少则少。取而代之的是 SDK 的接入，例如上图右侧的 Presto 的 Local Cache 就不会引入 Alluxio Cluster，Spark 这儿不引入 RSS 服务而是轻量简单的 Shuffle Manager 等等。

降低使用复杂度，DLC 集成了腾讯自研 SuperSQL，去实现统一函数和语法来去两个引擎无缝切换。上图右侧大部分服务都是托管的，如元数据、调度、权限、DDL 服务、Spark History 等这些服务都是用户免搭建，开箱即用的，大部分是免费的，而且我们还给到了用户一定的免费额度，只要配置得当，基本是能满足客户需求的。

云原生原则：狭义的说，DLC 都是基于容器的，包括计算引擎和各种服务容器化。广义的说，云原生更应该“长在云上”，DLC 是直接使用云上的对象存储、云数据库、云 Kafka、TDSQL 等等全托管 SaaS 服务的。

LC 实现 PB 级数据秒级分析

回到最开始的问题“高性能”，PB 级数据秒级分析该怎么去做，从三个大维度展开。我们从三个层面出发讲，第一从多维 Cache 的角度出发，包括文件缓存，中间结果缓存等；第二从弹性模型出发；第三从三维 Filter 的模型：分区、列、文件出发。

1）多维 cache

多维 Cache 分了三个角度：文件缓存、Fragment 结果缓存以及中间结果缓存、元数据的缓存，重点说说前两个。

文件缓存：我们在 DLC 上线了 Alluxio  Local  Cache，优点是没有单独的 Alluxio 集群，也不占用计算资源，免运维。当然也会有需要优化的地方，比如文件 /Split 级别、跨租户 Cache 缓存数据安全、缓存一致性、弹性影响、监控、黑名单等，这些优化空间 DLC 都会帮客户完成。在一些情况下，访问 Cos 的性能有 3—10 倍的提升。

Fragment 结果缓存：优点是不需要预计算，我们知道物化视图也非常流行，但是物化视图的利用率往往不好量化，事实上通常很低，而根据访问行为缓存下来的是用户行为肯定的；另外是用户几乎没有什么成本，同时也很大程度上降低底层存储的压力。当然，还会涉及到一些问题需要大家注意，例如缓存一致性、跨租户的安全等。性能方面，从来自 Presto 社区的数据看，Raptorx 有接近 10X 的提升。

2）虚拟集群弹性模型

刚才讲两种缓存效果接近 10 倍的性能提升，对弹性模型就有了很高的要求，因为缓存的命中是很依赖集群拓扑的稳定性的。另外资源启动要时间，新拉容器和镜像最快也要 1—2 分钟；最后 Client 预热很重要，包括各种服务都是 Lazy 加载的 Module 等等，这也都是需要 30 秒甚至 1 分钟的时间，这跟我们要求的秒级分析就差太远了。

那 DLC 是如何解决这个问题的呢？我们采用了虚拟集群架构，以子集群为最小单位去横向弹子集群，这样子集群拓扑稳定，资源跟 Client 都有很好预热。而且因为子集群的 Query 隔离，子集群也是很容易缩容的。

3）多维 Filter 过滤

继续说性能提升，还是 IO 优化，技术也是比较成熟的，只是还不怎么普及。先看第二个，列存 Parquet/ORC，结合引擎 Project 的下推，这样只有关心的列才会被扫描。第三个分区 / 分桶也比较常规了，但是最新业界的新特性比如 Dynamic Partition Puning，可以很好地加速分区需要推断的场景。

下面仔细说说稀疏索引。Bloomfilter、Zordering 本质逻辑上是类似的，需要结合引擎的谓词下推减少 IO扫描，加速分析。

在大数据的海量低成本要求下，稀疏索引可以做到降低存储成本并且加速分析性能，通过减少数据扫描量达到性能提升。具体分两步：第一步数据要进行 Cluster，类似的数聚在一起，结合引擎谓词下推，性能达到10X 以上的提升。同时也能带来存储的下降，这个原理其实很容易理解，类似的数据在一起了，Encodin 压缩能起到更好的效果。这也是大数据引擎，比如说像 CK、Doris 很重要的性能加速模型。

稳定性也是大数据很重要的诉求，前面看到像索引的构建都需要进行大规模的数据 ETL。对于稳定性我们遇到了很多挑战，包括虚拟集群弹性模型本身减少了弹性引擎的数据倾斜、Iceberg 减少底层 List、Rename导致任务失败等等问题。这里我们主要分享下 DLC 的 Spark Shuffle Manager 架构。

我们知道腾讯开源了 RSS 的服务 Filestorm，在全托管云原生的场景下我们做了简化和改造，原理是：优先使用本地磁盘，不足的时候 Spill 到 Cos，下面是业界几种典型的思路，DLC 的做法秉持着减少服务引入、保持简单、降低用户成本、减少用户/服务的运维。效果也很明显，大部分任务 /Task 都会以原有的性能完成，少量数据倾斜的任务 /Task 会损失一定的性能，但是依然能稳定完成。

DLC 作为全托管的产品，还是要强调一下低成本和易用的特性。COS 湖存储 VS 自建 HDFS 的成本优势，其实 80% 以上节省来至于 EC、HDFS 要预留资源以及 COS 有各种冷热分层策略进一步降低成本等。基于 EKS 或者 TKE 弹性资源，对比固定资源节省约 50% 以上的成本，如果是交互式分析场景，周六周日两天成本就是节省的，晚上也是节省的，离线是类似的。

最后 DLC 是全托管的免运维的一个产品，统一的 SQL 在两个引擎平滑迁移，SaaS的元数据、DDL服务、权限、调度、SaaS级别的Spark History 保障了用户开箱即用，而且这些公共服务大部分免费，有的是有免费额度的，正确使用都完全够用。

湖仓背景下的建模新思路

接下来一起看下，在云原生湖仓架构下，建模有有哪些新思路：

第一个，扁平湖仓架构，核心是不再维护复杂的数仓分层，而是把明细层的数据能够直接高性能分析；第二个是离线增量；第三个，现在业界比较时髦的新方向实时增量湖仓。

仔细讲一下扁平湖仓的结构，要解释为什么需要扁平湖仓建模，首先要看一下为什么要一层层去做分层建模。首先是在传统的数仓架构下，明细数据的分析的性能不够高，被迫去进行的预计算，同时因为多个结果可能会重复利用一部分公共数据，进行了 ETL 抽取。但是在 PB 级数据秒级分析的能力下，这些几乎都是不必要的。

层层建模的问题：第一是模式是固定的，不够敏捷。响应需求，从需求对接、历史数据刷新、测试验收，一两个周就过去了；其次是计算利用率往往是低的，尤其 Cube。Cube 虽然命中很快，单 Cube 的利用率往往是个大大的问号，从我们的经验来看其实非常低；另外分层离线更新是比较慢的，而现在特别火的实时增量更新并不是成熟和稳定，即使落地了对于存储和计算硬件的需求往往也是很高的。

结合前面讲的云原生湖仓做性能提升的各种手段，在明细层直接分析的扁平湖仓架构的时代自然是大势所趋了。当然最好能结合 BI 工具的时序结果缓存，这样 BI 层都可以省去。

最后介绍下一个游戏客户的案例：实时扁平湖仓秒级分析——逻辑架构非常简单直接，数据都是在 Kafka，通过 DLC Spark 去做实时数据的接入，直接写入几百张Iceberg 明细表，并且能够保证幂等。值得注意的是一个 Kafka 里面有很多张表的数据，保证幂等也有一些比较有意思的逻辑。入到明细表之后，开启明细表背后的一些优化，用 DLC  SuperSQL—Spark，进行清洗、合并小文件、以及稀疏索引构建等，最后达到的效果直接用 DLC SuperSQL-Presto 去做秒级分析，最后去对接 BI 的工具，达到一个非常好的分析性能，架构简单明了，无需各种建模。