共计 4139 个字符，预计需要花费 11 分钟才能阅读完成。
导读|过来几年，数据湖能力曾经在腾讯外部包含微信视频号、小程序等多个业务大规模落地，数据规模达到 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 的工具，达到一个十分好的剖析性能，架构简单明了，无需各种建模。
你可能感兴趣的腾讯工程师作品
| 一文读懂 Go 函数调用
| 内存泄露？腾讯工程师 2 个压箱底的办法工具
| 十亿人都在用的衰弱码，运维体系是怎么设计的
| 将云原生进行到底：腾讯百万级别容器云平台实际揭秘
技术盲盒：前端 | 后端 |AI 与算法| 运维 | 工程师文化
公众号后盾回复“湖仓”，领本文作者举荐的更多材料