摘要
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和大宽表的分析性能，函数式增量数仓来改造聚合层的分析实时性和性能
