写点什么

QCon-OPPO 数据平台 Cloud Lake 降本增效实践

  • 2021 年 12 月 07 日
  • 本文字数:3925 字

    阅读完需:约 13 分钟

1. 背景

OPPO 从 19 年开始,用了两年时间,以 K8S,容器化为核心,完成了公司混合云建设,并实现 100%在线业务上云。OPPO 的业务,目前覆盖国内,南亚,欧洲,美洲,在国内我们有自己的机房,在海外,更多是和公有云合作 ,有 AWS,Google。 OPPO 的云是朵云上云,与共有云的合作,更多只是采购机器资源,部署我们自己的服务。OPPO 云给我司带来了数亿的降本红利,得到了公司的广泛认可。

图1 OPPO混合云

目前 OPPO 的数据平台规模, 计算资源近万台,存储接近 1 个 EB,离线任务数近百万,实时任务数千。统计我们过去几年的增速,平均下来,每年大概有 30%的规模增长。   如此的一个规模增长下,系统 SLA 三个 9, 任务 100%准点,是我们必须要保障的,同时,公司希望数据平台能够把过往快速增长的成本降下来。所以 业务快速增长、系统 SLA 和任务准点率保持高水平的前提下,如何进一步降本增效是我们必须要解决的问题。

图2 OPPO数据平台业务规模

对于这样一个问题,我们的解法是进行一系列的技术升级,主要包括批流一体、云数融合调度、数据湖存储三个方面。

2. 批流一体

图3 批流一体架构

如上图,上半部分,典型的 Lambda 架构。 批流两条计算链路,元数据分开。应用侧的多种 OLAP 引擎,也有各自的存储方法与元数据管理。


我们通常说的批流一体,一般涉及到三个方面的统一,元数据,存储,引擎。这三方面,OPPO 更看重前两点。为了元数据的统一,我们以 HMS 服务为主,同时通过 Waggle-Dance 进行了加固。为了存储的统一,我们引入了 Iceberg ,打破实时数仓,离线数据的存储边界,同时提高数据仓库的实时性。

图4 Iceberg


最近两年,开源界以 Delta, Hudi, Iceberg 为代表的 Data Lake  Format 非常流行。他们近实时,ACID 语意,支持快照语回溯等特性,吸引的不少开发者。刚才的介绍,大家也看到了,OPPO 的选择是 Iceberg,其中最重要的是支持 CDC 的近实时特性。 但是近实时的特性在我们做业务推广是,却显得有些鸡肋。离线场景,小时任务可以满足大部分场景的时效要求。实时场景 ,对退化为成本更低的近实时,业务上对延时很难接受。

图5 Iceberg实时化

为了实现 Iceberg 的实时化,我们对它做了一些技术改进,下面分两个场景介绍。


场景一:是数据库的 CDC 入湖场景,需要支持数据变更。大数据领域,解决数据实时写入问题,通查会使用 LSM 结构。因此我们在架构上引入了 Parker,一个支持分布式 LSM 的 KV,在 Iceberg 前,承担数据缓冲。KV 的引入,对基于主键的 upsert 也能够得到比较好的支持。


场景二:基于手机埋点的数据上报,每天的数据上报量非常庞大,万亿级别。 这条链路中,使用了大量的 Kafka 资源。我们实时数仓的链路,Kafka 的数据存储周期是 T+3 ~ T+1 天,这个过程中,我们选择通过 Iceberg,使用效率更高的列式存储,降低 Kafka 的存储水位,使 Kafka 的数据存储周期变为 T+3 小时。既保障实时性,同时又降低 Kafka 存储成本。

3. 云数融合调度

OPPO 每年 30%的算力增长,评估下来,2022 年大概有 8w 核算力缺口。如果不外采,算力缺口是否有补齐途径。有平台经验的伙伴,一般都了解,白天,通常是在线业务高峰。而夜间,往往离线计算会把集群计算资源打的很满,白天的负载,通常在 50%左右。实现潮汐调度,在线、离线算力融合,是我们的必然选择。

图6 融合调度


实现算力融合,我们并没有完全走云原生的路径,计算资源完全由 K8S 调度。 因为 YARN 的调度逻辑比 K8S 简单,对于大数据任务资源频繁释放回收的场景,效率上远高于 K8S。因此,我们选择了 YARN+K8S 的调度逻辑,在 K8S 上实现 yarn-operator。任务高峰,有 K8S 给大数据集群释放资源,过了高峰期,则自动回收。


云数融合调度中,大家可能会担心一个问题,就是容器释放的算力,性能上是否能够满足计算要求。这里可以得大家看下我们的一些测试。测试对比项是物理机、SSD 容器,SATA 容器,VM 容器。 从测试中可以看到,同等配置条件下,物理机性能最好,SSD 容器和 SATA 容器性能次之。VM 上的容器性能下降的比较厉害。所有,SSD 容器和 SATA 容器性能损耗,是可以接受的。

云数融合调度中,大家通常会面临一个问题,就是如何稳定保障计算引擎的 Shuffle 效率。我们使用的是 OPPO 自研 Shuffle Service。OPPO 自研 Shuffle Service 的初衷,是为了降低大任务的 Shuffle 失败率。我们的平台推出计算账单后,时不时会有用户因为 Shuffle 失败,希望我们减免计算费用。因为要知道 Shuffle 跑失败的任务通常规模不会小,费用可能是成百上千元。从平台的角度,当然不希望任务失败,就减免费用。云数融合中,Shuffle Service 也起到了很好的作用,远程的 Shuffle 服务,有效降低了本地存储压力,在资源扩缩容过程中,也能够保障计算稳定。

图7 Remote Shuffle Service

这里,可以给大家,看一下 Shuffle Service 的测试数据。 这是 TPC-H ,1TB 数据下的测试结果。Shuffle Service 并不是说对所有的 SQL 任务,都能提高执行效率。但对 Q16,Q21 这样的大任务,效率提升还是非常明显的。 平均下来,大概有 16%左右的提升。

图8 Shuffle Service性能测试结果

4.数据湖存储

OPPO 的数据存储,经历了三个阶段。

阶段一:全 HDFS 存储。 阶段二: 引入对象存储 。阶段三: 自研 ADLS 数据湖存储。

阶段一到阶段二,主要是将数据通过数据资产平台的周期设定,在达到某个时间点后,自动作为冷数据迁移到对象存储。阶段二到阶段三,则是统一文件,对象存储,由升级后的文件系统解决元数据瓶颈,冷热温分层存储。自研存储,关键技术有多协议适配,分布式元数据,扁平命令空间加速,多级缓存等。下面我逐一做下介绍。

图9 文件目录树

文件系统提供的是层次命名空间视图,整个文件系统的逻辑目录树分成多层,如上图所示,每个元数据节点(MetaNode)包含成百上千的元数据分片(MetaPartition),每个分片由 InodeTree(BTree)和 DentryTree(BTree)组成,每个 dentry 代表一个目录项,dentry 由 parentId 和 name 组成。在 DentryTree 中,以 PartentId 和 name 组成索引,进行存储和检索;在 InodeTree 中,则以 inode id 进行索引。使用 multiRaft 协议保障高可用性和数据一致性复制, 且每个节点集合会包含大量的分片组,每个分片组对应一个 raft group;每个分片组隶属于某个 volume;每个分片组都是某个 volume 的一段元数据范围(一段 inode id ); 元数据子系统通过分裂来完成动态扩容;当一分片组资源(性能、容量)紧接临近值时,资源管理器服务会预估一个结束点,并通知此组节点设备,只服务到此点之前的数据,同时也会新选出一组节点,并动态加入到当前业务系统中。


单个目录支持百万级别容量,元数据全内存化,保证优秀的读写性能,内存元数据分片通过 snapshot 方式持久化到磁盘以作备份及恢复使用。

图10 扁平目录缓存

而对象存储提供的是扁平命名空间;以访问 objectkey 为/bucket/a/b/c 的对象为例,从根目录开始,通过”/”分隔符层层解析,找到最后一层目录(/bucket/a/b)的 Dentry,最后找到的/bucket/a/b/c 对于的 Inode,此过程涉及多次节点间交互,层次越深,性能较差;因此我们引入 PathCache 模块用于加速 ObjectKey 解析,简单做法是在 PathCache 中对 ObjectKey 的父目录(/bucket/a/b)的 Dentry 做缓存;分析线上集群我们发现,目录平均大小约为 100,假设存储集群规模在千亿级别,目录条目也才 10 亿个,单机缓存效率很高,同时可通过节点扩容来提升读性能;在同时支持"扁平"和"层次"命名空间管理的设计,与业界其他系统相比,CBFS 实现得更简洁,更高效,无需任何转换即可轻松实现一份数据,多种协议访问互通,且不存在数据一致性问题。

图11 多级加速

数据湖架构带来显著的收益之一是成本节约,但存算分离架构也会遇到带宽瓶颈和性能挑战,因此我们也提供了一系列访问加速技术:


一. 多级缓存能力

第一级缓存:本地缓存,其与计算节点同机部署,支持元数据和数据缓存,支持内存、PMem、NVme、HDD 不同类型介质,特点是访问时延低,但容量少.

第二级缓存:分布式缓存,副本数目弹性可变,提供位置感知能力,支持用户/桶/对象级的主动预热和被动缓存,数据淘汰策略也可配置

多级缓存策略在我们的机器学习训练场景有不错的加速效果。

 

二. 谓语下推操作

另外存储数据层还支持了谓语下推操作,可显著减少存储与计算节点间大量的数据流动,降低资源开销并提升计算性能;

数据湖加速有还很多细致的工作,我们也在持续完善的过程中。

5.展望

最后,结合刚才提到的三点技术方向,说下我们未来的一些规划和展望。


批流一体的计算,我们做到了元数据统一,存储统一。计算引擎统一,是可以积极探索的方向。虽然以 Flink 为代表的计算引擎,不断地宣称自己能做到批流一体,但是从实践角度,一个系统想做得多,往往不能再每个方向上都做到极致。统一的计算引擎我持保留意见,但不排斥这个方向的探索。这点上,我个人更倾于在批、流和交互式计算引擎上有一个公共层,通过这个公共层屏蔽不同引擎带来的适配成本,而非在引擎层实现完全的计算统一。


云数融合调度,目的是实现资源弹性,目前主要通过定时机制实现。因为我们知道业务资源利用规律,把这样的规律通过规则配置到我们弹性策略中。但是,弹性调度应该是更敏捷型,更灵活的,系统可以感知负载情况,自动进行资源的释放和回收。因为日常业务中会经常会有大规模任务重跑,任务突增等情况。这种情况下,灵活自主的扩缩容策略会对我们的业务有更好的帮助。


存储方面,刚才我们提到的冷、热、温分层存储目前还需要用户来定义。如某张事实表数据多久变冷存,某张维表是否一直需要热缓存加速。随着业务的变化,冷数据可能变成热数据,也需要手动做参数调整。其实,数据冷、热、温的划分,可以根据动态监测到的一些指标数据,通过算法自动地进行标识,转化,以达到不同数据使用不同存储介质,进而拥有更合理的存储成本。


最后还想说一点,数据平台我们会持续与云的融合。近年来广泛讨论的 Snowflake ,将数据仓库搬到云上,同时支持多云部署,非常有代表性。我们的产品和能力嫁接到云上,可以更广泛的输出我们的服务。


作者简介

Keung Chau OPPO 数据架构负责人  

负责 OPPO 数据平台的建设与技术演进。


获取更多精彩内容,搜索关注[OPPO 数智技术]公众号

发布于: 16 小时前阅读数: 16
用户头像

还未添加个人签名 2019.12.23 加入

OPPO数智技术干货及技术活动分享平台

评论

发布
暂无评论
QCon-OPPO数据平台Cloud Lake 降本增效实践