微信邦

 找回密码
 立即注册

QQ登录

只需一步,快速开始

查看: 346|回复: 0

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

[复制链接]
发表于 2023-1-4 09:02:37 | 显示全部楼层 |阅读模式
导读|过去几年,数据湖能力已经在腾讯内部包括微信视频号、小程序等多个业务大规模落地,数据规模达到 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 的工具,达到一个非常好的分析性能,架构简单明了,无需各种建模。

回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则


微信邦网联系QQ|Archiver|手机版|小黑屋|鲁公网安备 37082802000167号|微信邦 ( 鲁ICP备19043418号-5 )

GMT+8, 2023-2-4 03:11 , Processed in 0.123781 second(s), 20 queries .

Powered by Discuz! X3.4

© 2001-2013 Wxuse Inc. | Style by ytl QQ:1400069288

快速回复 返回顶部 返回列表