一份数据满足所有数据场景？腾讯云数据湖解决方案及 DLC 内核技术介绍

摘要

OLAP 数据库/引擎日新月异，不断推陈出新，在各种场景下有不同引擎的价值：flink 擅长于实时数据集成/实时计算；spark 批处理、tb 级以上、hive 生态、复杂 join 的数据分析、以及机器学习；presto 联邦分析、较简单 join、tb 级以下 hive 生态 udf 数据分析；clickhouse 大宽表聚合操作、无数据更新、尽量无 join、没有复杂 udf 的亚秒级分析，tensorflow 深度学习等等

即使相同的引擎，考虑资源隔离、成本分摊、数仓研发/使用周期（test，adhoc，prod，backfill）、不同底层资源 sla 保证（spot、on-demand）、不同的大数据产品形态（cdh 自建、半托管产品、全托管产品）等不同场景也需要多个集群。

有没有可能一份数据就能满足上面纯 AP 的场景，甚至部分 TP 分析场景也能容纳进来。分享从“一份数据满足所有场景”的问题出发，引出了腾讯云数据湖解决方案的介绍，紧接着介绍作为数据湖解决方案粘合剂和全托管产品形态补充的 DLC 在稳定性、性能、成本方面的技术优势，最后介绍数据湖趋势下的数仓建模新思路。

图一

哈喽大家好，我是于华丽，来自腾讯大数据，很高兴跟大家一起探讨大数据最火方向——数据湖。

具体分享前，我先来抛出一个问题，那就是“有没有可能只有一份数据就满足所有大数据场景”，大家是如何考虑这个问题呢？我们带着这个问题以及对这个问题的疑问和各自心里的答案开始今天的思想碰撞吧。

图二

先卖个关子，分享之前先做个简单的自我介绍，我叫于华丽，毕业于复旦大学数学系，近十年的大数据和公有云结合经验，有多家云厂商云原生大数据平台建设经验。20 年加入腾讯 TEG 数平，全面负责腾讯云数据湖产品 DLC 的内核架构研发。

一、分享目录

做完自我介绍，简单介绍下今天分享的目录，

首先从开篇提出的问题出发，引出腾讯云数据湖解决方案

第二部分由数据湖解决方案中引出 腾讯云数据湖产品 DLC，重点介绍下 DLC 的技术内核有哪些亮点

第三部分 总结腾讯内部和客户对接过程中的新一代数仓建模思路

第四部分 最后介绍 DLC 的客户案例和专家团队

二、SSOT 架构理念及腾讯云数据湖解决方案

图三

前面说了那么多，大家还记不记得我们最初提出的问题呀，那就是“一份数据能不能满足所有的大数据数据场景”

回答这个问题之前我们先了解下这个问题是怎么产生的？那就是数据库 DB 太卷了。300 多种，tp 数据库就算常见的也是几十种。AP 引擎更如雨后春笋，在如今的科技时代百家争鸣。Hive/spark/presto/impala/ck/doris 等等等等

基于这个背景我们做数据架构的时候就应该考虑很重要的问题就是数据怎么存，有一个很重要的数据架构原则 single source of truth。这个架构原则有两个很重要的好处，一个是减少维护复杂度，防止数据一致性问题，第二个就是节约成本。

那如何应用这个架构原则，有两个角度：

1、多个引擎类型、集群、能不能共用数据？

2、不能共用的情况，能不能引用其他引擎数据而不冗余

图四

从前面 db 内卷的现状，我们提出了数据湖 ssot 架构理念，具体如何应用数据湖 SSOT 架构理念，我们总结四个落实 SSOT 的 tips：

1、80%的湖数据，存算分离、不同 ap 引擎，不同集群尽量兼容、使用同一份湖数据

2、10% TP 数据库 量级不大不影响在线服务的情况下，直接联邦分析。海量、历史数据入湖 #1

3、10% 最后一公里的大宽表、结果数据可以考虑独立的仓存储，追求极致性能毫秒级分析

4、数仓数据也要跟湖数据联动，数仓兼容湖数据，或者联邦分析

那么如果能完全应用了上面的四个 tips，在数据湖 ssot 架构下，可以做到 1 份数据满足几乎所有大数据分析场景

图五

基于数据湖 ssot 架构理念，我们结合腾讯云的各个大数据产品，推出了腾讯云数据湖解决方案，来帮助落地数据湖架构

1、在批处理（emr hive/spark、DLC spark）、实时处理（emr spark/flink、oceanus、DLC spark）、AI（Tione、EMR spark、DLC spark）、mpp 分析（EMR ck/doris CDW ck/doris/pg DLC presto/spark/supersql）各个主要场景下，各个引擎尽量用同一份数据湖数据，可以看到在不同场景下有各种不同的产品供选择，当然即使同一个产品也会有多个集群，大部分都可以兼容数据湖存储 COS 来满足 统一湖存储的架构原则。

2、在追求毫秒级分析的场景下，大宽表、结果数据可以导入到 mpp 数仓 emr/cdw clickhouse/doris 完成最后一公里的分析

3、tp 数据库、数仓 cdw、湖数据可以通过 dlc 联邦分析功能

三、DLC 产品及技术内核介绍

刚才我们从数据湖解决方案看到了频繁出现的关键词 DLC 到底是个什么产品，又有哪些技术特别之处呢？下面我们就解开 DLC 的神秘面纱

1、DLC 产品定位：

图六

腾讯云 DLC 是 datalake compute 的缩写

DLC 一方面充当数据湖解决方案的粘合剂，体现在湖存储管理、元数据管理、联邦计算

另一方面补充了 云上全托管的产品形态，用户免运维、几乎不需要有大数据相关背景就可以几分钟内快速构建数据湖相关功能。

2、DLC 架构理念：适应云原生、Keep it simple，stupid

图七

接着我们来看下 DLC 技术架构，在设计架构 DLC 的整个过程其实是腾讯内部海量大数据经验的上云，但是并不是简单的平移部署，背后架构理念 1、适应云原生 2、Keep It Simple, Stupid

Kiss 体现在几个方面，presto local cache，dlc shuffle manager，统一语法模块等等方面

适应云原生，eks/tke，元数据主存 tdsql，各个服务的多租户支持和隔离，作为一个用户免运维，服务轻运维的全托管 saas 产品

具体来看我们在统一接入层服务提供云 api，jdbc，hmsclient 等对外服务；

SQL 入口是腾讯的 supersql 的统一 sql 服务，进行了权限，validate 等操作以及进行了虚拟集群的管理和路由；

下面是 DLC 的数据管理，计算集群，数据权限和元数据管理；

最后与用户 cos，cdb，emr 的数据打通。

通过内核架构支持，向上提供 sql etl/mpp sql 分析/联邦分析等场景，接下来逐步完成 spark jar/AI 的迭代和升级。

3、稳定性优化

图八

技术内核部分，分成稳定，性能，成本三部分来分享

稳定性三块，其中重点讲下 DLC spark shuffle manager，在这儿简单提两个点：iceberg 和弹性不稳定

Iceberg 作为 table format 解决了对象存储的最终一致性导致的数据写入 commit 过程中 rename 频繁失败问题

弹性计算相对于传统固定集群带来很多问题，比如冷启动慢，hpa 过程中数据倾斜，甚至资源不足的情况，我们在后面成本相关会仔细提到 dlc 的弹性模型。

图九

下面仔细讲讲 dlc 的 shuffle manager

腾讯开源了 firestorm 来解决内部海量数据的 shuffle 问题，在 dlc 场景下，我们进行精简改造，推出了适应云原生场景下的 DLC spark shuffle manager

本质逻辑是保证大部分任务都能利用本地磁盘完成高性能的 shuffle，少数情况 spill to lakefs 保证任务稳定性。

有几个好处 1、绝大部分 job/task/file 都是利用本地磁盘；2、服务及用户无需运维 shuffle service 3、无需购买，几乎零成本。

太细节的就不涉及了，在这儿给喜欢钻研的同学留一个小问题？Spark 都有哪些过程会需要落磁盘呢？

4、性能优化

图十

性能在提高人效方面日益重要，各个层出不穷的 ap 引擎也几乎主要在提升交互响应的性能

DLC 在性能方面有很多架构技术方面的考量

稍后重点分享 2、presto 加速 spark sql+udf 和 3、presto local cache 在 dlc 的应用

在这儿简单提几个点：1、spark sql 共享 spark context，spark thrift server 问题的症结在于 server 本身又是 driver 因此稳定性很大问题，dlc 在这方面 用的 livy+livy session 背后的 spark context 共享，在有一定并发情况下，又通过子集群来隔离。

4、海量元数据的存储和 hms 响应性能提升方面 dlc 也有自己的考量，采用了腾讯云的 tdsql/重新设计范式来满足海量元数据的响应性能

5、在 dlc 的托管存储表下，运用 iceberg hidden 。

图十一

性能相关第一个点就是通过提供 presto 加速 spark sql + udf 的分析性能

因为常驻共享及 push based 内存 shuffle，presto 往往在小数据量下有着不错的表现、但是因为 presto 语法和 udf 与 hive/spark 的差异往往迁移试错成本很高。DLC 统一 sql 语法，几乎还是 spark/hive 的语法，presto hive/spark udf wrapper。两个手段解决了 presto 的迁移问题，hive/spark 用户能够以极低的成本尝试 presto 带来的分析性能提升

图十二

Alluxio 也是当下最热的数据湖加速技术

在 dlc 侧，我们秉承了适应云原生和 kiss 的架构原则，上线了免运维，无需额外费用的 alluxio local cache

有很多好处，local cache 免去了 alluxio 服务的部署和维护，不抢占用户 presto 的计算资源。

同时我们也有一些改进，hash 算法导致的数据倾斜，一致性 hash，split 级别的 hash 等等

5、成本优化

图十三

到了大家很关注的成本的章节啦、提到全托管大家可能会有个误解就是成本高，对于 DLC 来说、数据湖解决方案来说并不是这样的。分两块，一个是存储一个是计算。

图十四

首先是存储成本：

首先我们看下用对象存储作为湖存储相比 hdfs 来说的存储性价比得到了 10x 的提升

1、hdfs 的三备份 vs cos 的 ec 1.n

2、预留空间 vs 按量计费

3、hdfs 的运维成本

4、对象存储的归档和智能存储分层

5、cos 作为存储产品提供的高 sla 和存储可靠性

但是对象存储在降低成本的同时也带来了问题，比如对象存储没有 rename 语义等四个问题，采用 iceberg 表格式来解决，相比直接 hive 表，计算成本也得到了极大的降低

图十五

接下来就是计算成本：也就重点介绍下 dlc 的虚拟集群弹性模型

重点看下右侧的 spark，交互式/sql 都是类似的

我们以子集群为弹性的最小单位，保证子集群的资源整体可用情况下的弹性，子集群多个 query 共享 spark context。

1、能很好的降低延迟，减少拉机器，进程初始化，链接初始化的时间，提升性能。

2、子集群规模稳定，减少了频繁扩缩造成的任务稳定性差和弹性导致的数据倾斜。

3、在前面的前提下，子集群的隔离保证了能够进行高效的 scale in，降低成本。

四、新一代数仓建设思路

接下来，我们把数据湖在腾讯落地过程中总结出的数据建模也分享给大家

图十六

目标还是能够提升分析性能和降低存储计算成本

第一个是海量数据下的稀疏索引技术，如右图所示，构建大宽表或者 dwd 详情层，我们把高基维的相关数据的靠近存放，能够利用引擎的谓词下推技术大大加速分析性能，并且提高压缩比率降低存储成本，同时也可以减少单纯的主题层的数据抽取，更好应用 ssot 一份数据满足尽可能多的场景。

第二个是增量数仓技术：底层逻辑是 funtional data engineerging，也可以叫函数式数据工程，不再维护滚动表这类有状态的数仓建模障碍，而是把 uv 标量进行向量化，以空间换时间，在数据量不大的聚合计算层表有很好的效果，能够极大的提升数仓的构建性能和分析性能。

接下来我们看下 DLC 的客户案例吧

图十七

这个是某电商直播平台基于 dlc 构建混合大数据架构，充分利用了 dlc 的 spark 批处理和交互式分析，计算性能提升，成本节约，运维成本大幅度降低。

图十八

腾讯数据湖能力也在内部大规模落地，接入超过 80，

其中微信视频号，小程序等业务均百亿千亿级别落地

同时我们近百人的研发团队支持，其中大量的业界顶尖技术专家，包括了 spark livy alluxio 等开源项目的 pmc，presto/calcite committer，为 dlc 的稳定/高性能/易用/低成本 保驾护航

图十九

五、总结

最后总结下今天的分享，用三个词来总结：SSOT、KISS、新一代建模

1、首先是 SSOT，如何做到一份数据尽可能满足所有场景，有三个原则。我们根据这三个原则提出了腾讯云上以 dlc 为核心的数据湖解决方案

2、其次 KISS，适应云原生，DLC 产品一方面充当了腾讯云数据湖解决方案的粘合剂，另一方面以 KISS/适应云原生的架构理念补充了腾讯云大数据全托管的产品形态，稳定、高性能、低成本、免运维是 DLC 的重要产品特性。还记得我们留的一个思考问题不 spark 都会有哪些过程和场景需要数据落到磁盘呢？

3、最后新一代建模：稀疏索引来解决 dwd 和大宽表的分析性能，函数式增量数仓来改造聚合层的分析实时性和性能