共计 4417 个字符，预计需要花费 12 分钟才能阅读完成。
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% 左右的晋升。
图 7 Shuffle Service 性能测试后果
4. 数据湖存储
OPPO 的数据存储，经验了三个阶段。
阶段一：全 HDFS 存储。阶段二：引入对象存储。阶段三：自研 ADLS 数据湖存储。
阶段一到阶段二，次要是将数据通过数据资产平台的周期设定，在达到某个工夫点后，主动作为冷数据迁徙到对象存储。阶段二到阶段三，则是对立文件，对象存储，由降级后的文件系统解决元数据瓶颈，冷热温分层存储。自研存储，关键技术有多协定适配，分布式元数据，扁平命令空间减速，多级缓存等。上面我逐个做下介绍。
图 8 文件目录树
文件系统提供的是档次命名空间视图，整个文件系统的逻辑目录树分成多层，如上图所示，每个元数据节点 (MetaNode) 蕴含成千盈百的元数据分片（MetaPartition），每个分片由 InodeTree（BTree）和 DentryTree（BTree）组成，每个 dentry 代表一个目录项，dentry 由 parentId 和 name 组成。在 DentryTree 中，以 PartentId 和 name 组成索引，进行存储和检索；在 InodeTree 中，则以 inode id 进行索引。应用 multiRaft 协定保障高可用性和数据一致性复制, 且每个节点汇合会蕴含大量的分片组，每个分片组对应一个 raft group；每个分片组隶属于某个 volume；每个分片组都是某个 volume 的一段元数据范畴（一段 inode id ); 元数据子系统通过决裂来实现动静扩容；当一分片组资源 (性能、容量) 紧接邻近值时，资源管理器服务会预估一个完结点，并告诉此组节点设施，只服务到此点之前的数据，同时也会新选出一组节点，并动静退出到以后业务零碎中。
单个目录反对百万级别容量，元数据全内存化，保障优良的读写性能，内存元数据分片通过 snapshot 形式长久化到磁盘以作备份及复原应用。
图 9 扁平目录缓存
而对象存储提供的是扁平命名空间；以拜访 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 实现得更简洁，更高效，无需任何转换即可轻松实现一份数据，多种协定拜访互通，且不存在数据一致性问题。
图 10 多级减速
数据湖架构带来显著的收益之一是老本节约，但存算拆散架构也会遇到带宽瓶颈和性能挑战，因而咱们也提供了一系列拜访减速技术：
一. 多级缓存能力
第一级缓存：本地缓存，其与计算节点同机部署，反对元数据和数据缓存，反对内存、PMem、NVme、HDD 不同类型介质，特点是拜访时延低，但容量少.
第二级缓存：分布式缓存，正本数目弹性可变，提供地位感知能力，反对用户 / 桶 / 对象级的被动预热和被动缓存，数据淘汰策略也可配置
多级缓存策略在咱们的机器学习训练场景有不错的减速成果。
二. 谓语下推操作
另外存储数据层还反对了谓语下推操作，可显著缩小存储与计算节点间大量的数据流动，升高资源开销并晋升计算性能；
数据湖减速还有很多粗疏的工作，咱们也在继续欠缺的过程中。
5. 瞻望
最初，联合方才提到的三点技术方向，说下咱们将来的一些布局和瞻望。
批流一体的计算，咱们做到了元数据对立，存储对立。计算引擎对立，是能够积极探索的方向。尽管以 Flink 为代表的计算引擎，一直地声称本人能做到批流一体，然而从实际角度，一个零碎想做得多，往往不能再每个方向上都做到极致。对立的计算引擎我持保留意见，但不排挤这个方向的摸索。这点上，我集体更倾于在批、流和交互式计算引擎上有一个公共层，通过这个公共层屏蔽不同引擎带来的适配老本，而非在引擎层实现齐全的计算对立。
云数交融调度，目标是实现资源弹性，目前次要通过定时机制实现。因为咱们晓得业务资源利用法则，把这样的法则通过规定配置到咱们弹性策略中。然而，弹性调度应该是更麻利型，更灵便的，零碎能够感知负载状况，主动进行资源的开释和回收。因为日常业务中会常常会有大规模工作重跑，工作突增等状况。这种状况下，灵便自主的扩缩容策略会对咱们的业务有更好的帮忙。
存储方面，方才咱们提到的冷、热、温分层存储目前还须要用户来定义。如某张事实表数据多久变冷存，某张维表是否始终须要热缓存减速。随着业务的变动，冷数据可能变成热数据，也须要手动做参数调整。其实，数据冷、热、温的划分，能够依据动静监测到的一些指标数据，通过算法主动地进行标识，转化，以达到不同数据应用不同存储介质，进而领有更正当的存储老本。
最初还想说一点，数据平台咱们会继续与云的交融。近年来宽泛探讨的 Snowflake，将数据仓库搬到云上，同时反对多云部署，十分有代表性。咱们的产品和能力嫁接到云上，能够更宽泛的输入咱们的服务。
作者简介
Keung Chau OPPO 数据架构负责人
负责 OPPO 数据平台的建设与技术演进。
获取更多精彩内容，扫码关注 [OPPO 数智技术] 公众号
