OPPO 大数据混合云之路
为应对持续增长的存算能力的需求，OPPO大数据采用混合云的技术路线。
自建IDC 如大陆一样固定，但是大数据算力需求，有着明显的潮汐模式；云计算的模式犹如海上方舟，任凭潮涨潮落，仍然能从容应对。OPPO大数据就是结合了两者的各自优势，坚若磐石，伸缩自如。
将庞大且复杂的大数据架构改造成在混合云底座之间指哪打哪，极致弹性，远非简单的“迁移”问题。不仅面临近百万离线计算任务，还要处理不同系统和架构的依赖问题，单纯的上云不能体现混合云的优雅。
OPPO的数据平台为什么要用混合云？如何混合？需要解决哪些核心挑战？也许 OPPO大数据的混合云之路，可以给业界带来一些启发。
一、面向未来，大数据基础设施混合云化正在成为共识
过去两年，混合云在互联网、制造、金融等行业已经是常态，但真正推进到数百 PB 数据、近百万离线的大数据混合云模式，并不多见。
OPPO 是较早开始这项工程的终端企业之一。决定启动整个大数据平台公有云结合IDC模式，是因为 OPPO 意识到，随着企业的不断发展壮大，未来的数据体量、任务规模和技术演进路径，将越来越需要一种全新的基础设施来支撑。
相比传统数据中心，云提供的极致弹性资源调度、灵活的存算分离架构以及多维度可观测能力，更符合企业中长期演进节奏。这意味着企业不再需要为少数高峰业务维持长期过量的算力配置，资源可以根据任务变化在分钟级完成调度。
同时，云下自建IDC的在线服务器，在夜间刚好是负载低谷，通过混合云调度，充分利用起来云下机器夜间算力，尽量降低公有云成本。
公有云与IDC的资源合理的搭配，是大数据基础设施未来发展的趋势。
二、大数据混合云不仅是一个技术问题
混合云，顾名思义，公有云和IDC的各自优势均要充分利用，这里就要考虑存算上云的问题。
混合云从技术层面看，其中三部分最为关键：
1、海量数据和任务迁移到云上的过程
2、云上大数据基础架构建设
3、混合云存算资源调度能力建设
前两项决定了上云的进度和稳定性，上云和云上建设方案，需要具备坚实的技术基础，更重要的是，对集群作业复杂度和云上环境要有清晰的认识。最后一项能力，决定了混合云的成功关键，大规模的存算能力，如何在云上云下方便且稳定的切换，是一个比较大的考验。
同时，数百 PB 数据量，数十万任务量，涉及公司软硬件、互联网服务等多种业务数据，规模大、业务复杂度高。面对上云这个命题，不仅对 OPPO 大数据本身的技术能力提出考验，同时也是对阿里云的基础设施能力的一次考验。
图1： OPPO 大数据混合云基础架构概览
如图所示，整个实时、离线架构在云上的 IAAS 层，存储使用云上对象存储 OSS和云下HDFS，上层的弹性调度、计算引擎、RSS 等由 OPPO 自建。
三、混合云先决条件-上云
对于大规模体量和复杂度的大数据平台搬迁，仅靠一个系统或一个团队并不能完成全链条协作。OPPO 大数据平台部门与业务部门高效协同，仅仅八个月完成上云目标，提前一个季度完成。
3.1 关于上云的三个核心问题
如何能快速凝聚公司多个系统达成上云共识，要先回答好大家对上云的三个最关注的问题：
1、数据安全问题
上云后，如何保障数据安全？
OPPO 在上云前已经对数据安全等级做好分级，高优数据必须加密才可上云，并且上云数据不涉及用户数据。另外，头部云商均已具备工信部信通院颁发的大数据安全评估认证以及可信云安全评估认证，其云上数据安全保障机制已得到互联网和金融等严苛行业验证，是值得信赖的。
2、公有云成本问题
公有云一直给人的印象成本要高于自建IDC，尤其是前两年海外有些公司开始下云。其实从云上资源成本分析看，关键要看如何用云，用好公有云的弹性算力以及云上对象存储的成本优势，做好云上降本策略。并且，混合云模式充分利用IDC和云上资源，能使得云上成本更优。
3、云商绑定问题
上了某家公有云，会不会被某家云商绑定，能不能方便迁移。大数据混合云模式，可以不仅可以解决云上降本的问题，同时天然的解决供应商绑定的问题。
回答好以上三个问题，也就解答各级老板以及业务系统伙伴的核心关注，才能更快的达成一致，配合好上云工作。
3.2 上云方案及云上底座建设
上云的技术方案建设原则——轻量化。
通过建设迁移平台，自动化迁移、对比任务，业务方最终确认结果正常即可。对于算法类任务，数据平台部专项支持迁移，算法任务情况比较特殊，代码里固定路径，迁移平台自动识别 云上云下路径，算法任务无需修改代码即可完成上云迁移。通过技术优化，流程优化，使得上云整体公司顺滑优雅，降低对业务的打扰。
云上大数据底座建设原则——灵活弹性。
云上存算整体架构选择存算分离，计算和存储互相不影响，稳定性强。另一方面，资源各自扩缩，各自按量付费，足够灵活。存储选择云上对象存储，一方面足够有性价比，另一方面，数据灵活降冷。计算在云上选择 Yarn on K8S 方案，充分利用Yarn和K8S的各自调度优势，调度性能更好，任务调度可定制，更可控，从而能达到更高的资源利用率。
最后，对于云商选择，进行全方位测试对比，选择最合适的云商。
OPPO大数据团队经过一个多月的详细测试，从CPU芯片性能，到云上对象存储的各种详细指标，使用行业标准测试集任务以及线上大任务多种场景整体表现测试。
实践方面，上云过程足够丝滑高效，云上资源利用足够极致。当然，经过这么大规模的大数据任务压力，也是对选择的云商底层资源支撑的考验。这个项目的成功，是两个团队在“长期协同”中逐渐建立起的问题共识与节奏同步，是一次面向未来的能力共建。
四、OPPO 混合云大数据架构的持续创新
大数据完成上云只是第一步，如何在混合云模式下跑得更快、更稳、更省以及更自主，是 OPPO 大数据混合云重点攻克的目标。
图2：OPPO 大数据混合云演进
此前提到，大数据计算架构以混合云上的 Kubernetes（K8s）作为计算资源底座，云上对象存储（OSS）和自建HDFS 作为存储基础，并在上层调度与计算引擎层使用了业界主流的开源组件，如 YARN、Spark 和 Flink。
但在这套架构中，还有几个看似“陌生”的自研组件发挥了关键作用：HBO、Curvine Cache 和 MCN。
这些组件分别承担着什么职责？它们又是如何提升云上大数据平台能力的？
HBO（History Based Optimizer）：顾名思义，这是一款基于历史任务运行数据的优化器，能够通过任务运行记录，智能调整资源参数，提升整体执行效率。
Curvine Cache：基于 Rust 自研的高性能分布式缓存系统，旨在解决大规模数据处理过程中的 I/O 瓶颈问题。目前已正式开源（见附录），适用于提升数据访问速度并降低存储开销。
MCN：一个基于 HDFS NameNode 改造的元数据路由组件，支持与云上对象存储系统的兼容集成，增强了平台在云环境下的数据透明迁移能力。
这三个组件从三个维度提升了其云上大数据平台的能力：
1. 更省资源：借助 HBO 对任务参数的动态优化，有效压缩云上资源使用。例如，通过任务资源压实，云上 ECS 的物理 CPU 平均利用率可达 80% 左右。
2. 更高稳定性：Curvine 提供了高性能的读写能力，支持重写 Spark Shuffle 的底层逻辑，解决了 Spark RSS 在云盘下出现的热点问题，并同时兼容 Map Local Shuffle，实现一套方案覆盖两种 Shuffle 模式，提升系统稳定性。
3. 更快执行：云上的存算分离架构在一定程度上打破了“大数据移动计算不移动数据”的初心。Curvine 作为缓存中间层，在离线计算中承担热数据缓存角色，显著提升了数据读取速度；在实时计算场景下，也可用于缓存 Checkpoint，缩短任务重启加载时间，加快任务恢复速度，同时还能有效控制 OSS 的读请求次数和峰值带宽成本。
4. 更自主:大数据计算基于云上容器化方案实现高可用，核心技术在于大数据所依赖的存储技术有自有技术能力，如果要保持在云上技术可控自主度，解决不同平台间数据透明管理是关键。
此外，我们通过将传统 HDFS 的NameNode 改造成支持多种对象存储的元数据节点，既继承了 HDFS 在高性能和高可用方面的优势，又实现了数据的透明化迁移。
这一系列架构增强手段，使得 OPPO 能够在混合云真正做到算力利用最大化、任务运行更稳定、整体效率更高，并为未来多集群环境下的灵活扩展打下坚实基础。
五、混合云是起点，更是未来架构的方向
OPPO 这次大数据平台的搬栈上云以及混合云建设，是一次面向未来的基础设施升级。
从结果看，上云让任务调度更快了，资源使用更高效了，平台运维更可观测了。数据不只是“一个平台”，而是“平台能力的一部分”，必须做好基础设施的准备。而云原生架构提供的弹性调度、统一资源池和策略化治理，恰恰是这种准备的组成部分。
因此，OPPO 的这次混合云尝试不是终点，而是一个起点：企业如何通过基础架构调整，为下一代能力体系留出空间。这种空间，不是物理意义上的容量，而是系统演化的余地——当底层架构需要重构，平台是否能在“不中断”的前提下完成切换。从IDC到云，从任务调度到数据迁移，从资源使用到能力开放，OPPO 选择的不只是一种部署方式，而是一次架构哲学的转变。它背后隐含的是一个判断：未来企业的技术核心，不再是某个系统，而是系统之间能否高效组合与持续演化。
OPPO混合云的成功要素
1、公有云经过多年的技术积累，提供坚实的技术设施支撑，同时，近些年不断降低云上资源成本，使得云上大规模数据成本逐步接近甚至低于自建IDC，才使得用户有了将大规模数据存算上云的动机。
2、OPPO 主动拥抱云上“技术方舟”，充分利用云上弹性特点，实现降本增效，实现大数据轻量化运营。
高效，灵活，低成本，正是大数据混合云架构带来的技术红利，希望OPPO的实践能给业界带来一些新的启示。
