“OPPO与阿里云的合作,不只是一个项目,而是一个方向。
日益增长的计算和存储需求,使得越来越多的企业将目光投向——上云。IDC如大陆一样固定,但是业务的需求,尤其是大数据场景,有着明显的潮汐模式;云计算的模式犹如海上方舟,任凭潮涨潮落,仍然能从容应对。
将一个庞大且复杂的大数据平台迁移到云端,远非简单的“资源迁移”问题。尤其对于像OPPO这样的大中型企业来说,涉及到数百PB的数据、近百万离线计算任务,还要处理不同系统和架构的依赖问题,单纯的“lift & shift”(迁移式上云)已经不再适用。
那么,企业的数据平台为什么要上云?如何上云?需要解决哪些核心挑战?也许OPPO与阿里云的合作案例,可以给我们带来一些启发。
大数据平台上云,正在成为越来越多公司的共识。
过去两年,这类项目在互联网、制造、金融等行业已经是常态,但真正推进到数百PB级别的完整数据迁移,并不多见。
OPPO是较早开始这项工程的终端企业之一。决定启动整个大数据平台的“搬栈上云”,是因为OPPO意识到,随着企业的不断发展壮大,未来的数据体量、任务规模和技术演进路径,将越来越需要一种全新的基础设施来支撑。
相比传统数据中心,云提供的极致弹性资源调度、灵活的存算分离架构以及多维度可观测能力,是更符合企业中长期演进节奏的选择。对于OPPO而言,这意味着不需要再为少数高峰业务维持长期过量的算力配置,资源可以根据任务变化在分钟级完成调度。同时平台能力从“资源提供”转为“任务治理”,更多运维规则被固化进系统和策略中。
OPPO和阿里云有多年的合作基础,双方在多个系统级项目中已形成协作默契,对阿里云的技术栈和服务交付能力也已经非常熟悉,此次数据搬栈上云,更是双方协作进行了整个数据平台资源能力的整合升级,依托阿里云稳定高效的计算、存储、网络能力,上云过程充分发挥OPPO大数据基础架构技术能力。
很多公司对上云持有一种怀疑的态度,其中一个最关键的担心是:上云后,数据安全是否有保障?OPPO上云前已经对数据安全等级做好分级,高优数据必须加密才可上云,并且,上云数据不涉及用户数据。另外,阿里云具备工信部信通院颁发的大数据安全评估认证以及可信云安全评估认证,目前已经有多家互联网公司和一些对数据安全要求最严苛的金融公司使用阿里云,说明云上的数据安全保障机制已经得到行业验证,是值得信赖的。
技术层面看,上云,其中两部分最为关键:海量数据和任务迁移到云上的过程;云上大数据基础架构建设。
这两部分决定了上云的进度和稳定性,上云和云上建设方案,需要具备坚实的技术基础,更重要的是,对集群作业复杂度和云上环境要有清晰的认识。
数百PB数据量,数十万任务量,涉及公司软硬件、互联网服务等多种业务数据,规模大、业务复杂度高。面对上云这个命题,不仅对OPPO大数据本身的技术能力提出考验,同时也是对阿里云的基础设施能力的一次考验。
我们先看一下OPPO在云上大数据基础架构概览:
如图所示,整个实时、离线架构在阿里云的IAAS层,存储使用阿里云对象存储OSS,上层的弹性调度、计算引擎、RSS等是OPPO自建。
那么,这么难的项目,OPPO和阿里云是如何做成的呢?对于如此体量和复杂度的大数据平台搬迁,仅靠一个系统或一个团队并不能完成全链条协作。OPPO与阿里云的合作,更像是一次“联合技术项目”——双方不是简单的甲乙方关系,而是在架构目标、任务拆解、问题攻坚上共同推进的团队。搬迁从一开始就不是“只把数据从A移到B”,而是涉及海量任务、数百PB级数据迁移,为了保证迁移过程中的业务连续性和性能稳定,OPPO承担了任务识别、架构调整与业务节奏控制,阿里云则在产品能力、底层弹性架构、调度调优等方向提供体系化支撑。
比如在IO调度上,双方经历了一个典型“系统级修复”的过程。初期,当一些大任务在云上运行时出现读写不均衡、实例打满等现象,OPPO业务团队通过内部指标快速定位风险,阿里云则用内核采样工具追踪到了IO调度在高吞吐场景下的瓶颈成因。最终通过链路优化、架构调整,将最耗资源的任务转至独立链路,解决了吞吐受限的问题。
还有一个常被提起的协作场景,发生在夜间任务高峰时段。为满足OPPO快速弹性调度的需求,双方围绕ACK组件上线做了多轮优化。从磁盘选型、镜像缓存策略到操作系统PageSize调整,逐步将节点上线时间从数分钟缩短至1分钟内,使得弹性伸缩能真正应用在日常的波峰波谷中,而不仅停留在“理论弹性”。
值得一提的是,双方在应急处理机制上也建立了快速协同流程。曾有一次规模化测试中,某类任务“水位”陡升,短时间内引发了ACK Coredns的性能瓶颈。OPPO发现问题后,第一时间联动阿里云技术服务团队介入,双方基于实时观测体系完成诊断,并迅速调整部署架构,异常恢复时间控制在可接受范围内。这样的快速反应能力,成为系统级稳定性的保障。
在架构设计上,OPPO与阿里云也选择了相对一致的“融合平台”思路:统一的资源调度基座(ACK+倚天ARM)、统一的存储链路(OSS-HDFS+Jindo加速)、统一的可观测体系(ARMS+CMS+SLS),以及具备趋势感知的弹性调度机制(Delete Cost+模型预测),共同构建出一个既灵活又可控的云原生调度平台。这一系列成果的达成,并不依赖某项技术的突破,而是基于双方在业务理解、架构能力、产品深度上的高匹配程度。OPPO提供了具有工程约束意识的业务拆解逻辑,阿里云则在每一个瓶颈点上提供了稳定的产品与技术服务重保。
这个项目的成功,是两个团队在“长期协同”中逐渐建立起的问题共识与节奏同步,是一次面向未来的能力共建。
大数据完成上云只是第一步,如何在云上跑得更快、更稳、更省以及更自主,是OPPO大数据团队接下来要重点攻克的目标。我们先看一下整体架构:
图:OPPO云上大数据架架构
此前我们提到,OPPO的大数据架构以云上的 Kubernetes(K8s)作为计算资源底座,采用阿里云对象存储(OSS)作为存储基础,并在上层调度与计算引擎层使用了业界主流的开源组件,如YARN、Spark和Flink。
但在这套架构中,还有几个看似“陌生”的自研组件发挥了关键作用:HBO、Curvine Cache 和 MCN。
这些组件分别承担着什么职责?它们又是如何提升云上大数据平台能力的?
HBO(History Based Optimizer):顾名思义,这是一款基于历史任务运行数据的优化器,能够通过任务运行记录,智能调整资源参数,提升整体执行效率。
Curvine Cache:基于Rust自研的高性能分布式缓存系统,旨在解决大规模数据处理过程中的 I/O 瓶颈问题。目前已正式开源(见附录),适用于提升数据访问速度并降低存储开销。
MCN:一个基于HDFS NameNode改造的元数据路由组件,支持与云上对象存储系统的兼容集成,增强了平台在云环境下的数据透明迁移能力。
据OPPO介绍,这三个组件从三个维度提升了其云上大数据平台的能力:
1.更省资源:借助HBO对任务参数的动态优化,有效压缩云上资源使用。例如,通过任务资源压实,云上ECS的物理CPU平均利用率可达80%左右。
2.更高稳定性:Curvine提供了高性能的读写能力,支持重写Spark Shuffle的底层逻辑,解决了Spark RSS在云盘下出现的热点问题,并同时兼容Map Local Shuffle,实现一套方案覆盖两种Shuffle模式,提升系统稳定性。
3.更快执行:云上的存算分离架构在一定程度上打破了“大数据移动计算不移动数据”的初心。Curvine作为缓存中间层,在离线计算中承担热数据缓存角色,显著提升了数据读取速度;在实时计算场景下,也可用于缓存Checkpoint,缩短任务重启加载时间,加快任务恢复速度,同时还能有效控制OSS的读请求次数和峰值带宽成本。
4.更自主:大数据计算基于云上容器化方案实现高可用,核心技术在于大数据所依赖的存储技术有自有技术能力,如果要保持在云上技术可控自主度,解决不同平台间数据透明管理是关键。
此外,OPPO通过将传统HDFS的NameNode改造成支持多种对象存储的元数据节点,既继承了HDFS在高性能和高可用方面的优势,又实现了数据的透明化迁移。
这一系列架构增强手段,使得OPPO能够在云上真正做到算力利用最大化、任务运行更稳定、整体效率更高,并为未来多集群环境下的灵活扩展打下坚实基础。
需要指出的是,OPPO这次大数据平台的搬栈上云,不仅是一次系统性迁移工程,也是一次面向未来的基础设施升级。
从结果看,上云让任务调度更快了,资源使用更高效了,平台运维更可观测了。越来越多企业意识到,数据不只是“一个平台”,而是“平台能力的一部分”,必须做好基础设施的准备。而云原生架构提供的弹性调度、统一资源池和策略化治理,恰恰是这种准备的组成部分。
因此,OPPO的这次搬迁不是终点,而是一个起点:企业如何通过基础架构调整,为下一代能力体系留出空间。这种空间,不是物理意义上的容量,而是系统演化的余地——当业务需要重构,模型需要上线,链路需要重排时,平台是否能在“不中断”的前提下完成切换。从IDC到云,从任务调度到策略驱动,从资源使用到能力开放,OPPO选择的不只是一种部署方式,而是一次架构哲学的转变。它背后隐含的是一个判断:未来企业的技术核心,不再是某个系统,而是系统之间能否高效组合与持续演化。
阿里云和OPPO一起做对了什么?
1、阿里云经过多年的技术积累,提供坚实的技术设施支撑,同时,近些年不断降低云上资源成本,使得云上大规模数据成本逐步接近甚至低于自建IDC,才使得用户有了将大规模数据存算上云的动机。
2、OPPO主动拥抱云上“技术方舟”,充分利用云上弹性特点,实现降本增效,实现大数据轻量化运营。
也许,这场合作,正预示着行业内大数据上云“奇点"的来临……