导读 本文将分享 OPPO 公共云上大数据成本优化的一些成果。
文章主要分为以下 5 个部分：1. OPPO 大数据在公有云的原生架构
2. 大数据上云主要考虑的一些问题
3. 近期在公有云上降本的指标性成果
4. 对 CloudCamel 的展望
5. 问答环节
分享嘉宾｜付庆午 OPPO 大数据架构师
编辑整理｜李本培
内容校对｜李瑶
出品社区｜DataFun
01
OPPO 公有云上大数据成本优化方案的名字叫 CloudCamel，寓意是在公有云上，以最低的成本完成大数据的计算。1. 国内架构
OPPO 国内的大数据架构如下图所示，最上层由 Oflow 作为资源调度，提供一些实用化的工具，例如链路识别、链路接入的保障、关键路径识别以及时间预测、报警等。在接入层，有 OPPO 自研的 SQL 画像、统一接入、多引擎路由适配等功能。在引擎层，主要用 Spark、Trino、Flink 分别对应批计算、流式计算、及时查询，并自研了 Shuttle，后面扩展了分布式排序、Broadcast 广播优化。在元数据层，主要采用开源组件 WaggleDance，并在此基础上，进行了优化改造：把元数据分成了多个 Group，实现容灾和加速的效果。在云数融合调度层，实现了很多调度上的创新，比如资源的限售、超卖、分级等任务，实现分级的调度，以及故障、资源的自愈。在湖仓一体层自研了 Glacier，在湖仓的上一层有一个管理层，实现了秒级入湖和索引的自动创建。在最下层存储，采用 HDF 作为热数据的存储，Cubefs 作为冷数据的存储。架构图右侧主要是运维和诊断方面的一些功能。
2. 国外架构
OPPO 在海外公有云架构，基本都是用的 EMR，也就是云厂商提供的开箱即用大数据计算服务，整个架构与国内相似。上层任务编排也是采用 Oflow；任务接入层，采用 HiveServer 来执行 HiveSQL。下层提交任务路由到不同的 EMR 集群上采用的是 AWS，AWS 在新加坡分 ABC 三个区，三个AZ 供给的比例也不一样。在三个 AZ 的 EMR 集群上，根据任务的优先级程度采用不同的 spot 比例。在公有云上有两种资源，一个是 spot，资源随时会被云厂商回收，所以成本很低；另外一个是 on-demand 资源，成本高但稳定性好，使用期间不会主动去收回。底层存储使用 S3 自动降冷服务,会根据任务的数据访问频次自动进行冷存储，例如超过三个月不访问的数据，会放到冷存层。对比相同的数据量，冷存成本会降低很多。
3. 架构的优化
以上是之前 EMR 服务的大数据架构。最近，研发集群已基本全部迁移到了自研的 EKS 极致弹性的架构上，架构上所有的组件都进行了弹性化改造，部署到 EKS 上，这样就释放出了很多资源。在数据任务的结构层，会根据任务的量，按照任务的波动自动伸缩所用资源量。在EKS上，主要是使用 spot 资源，基本上把整个计算的算力全部用成了 spot 资源。最底层的数据存储层，还是用 S3 的自动降冷。我们也曾尝试过其它优化，如数据的手动降冷，通过实时监控数据访问情况，比如哪些数据多久访问一次，对数据进行积累，当积累有几个月的数据之后，会把一些数据定义成冷存。经过对比，手动降冷与S3 的自动降冷相比，成本上并没有太大的优势，反而会带来很多不便利之处。所以数据存储层全部使用 S3 的自动降冷。
4. 弹性架构
下面是控制计算的主力弹性架构图，包括了自动伸缩调度的管理模块、机器的选择模块等，通过自动伸缩的管理模块不断地更新交互资源。没有用 K8S 的原因：一是整个运维系统，包括监控、运维、任务管理，基本还是延续了 Yarn 的模式，如果要整体改造，成本将会比较大；二是我们在 Yarn 上做了很多的优化，并将优化的策略和在国内积累的经验，输出到海外的环境；三是 Yarn 在高峰期的调度效率，明显优异于 K8S 远程调度的效率。
5. 自研组件 Shuttle 功能简介
自研组件 Shuttle 突破了 Shuttle Service 单一的功能定义，而是将其定义成为了引擎的加速器，不仅是做了 shuffle 的加速，还做了单点排序的加速。另一方面，突破了 Spark Driver 内存的限制，把 Spark 的 broadcast 搬到了 Shuttle 上，把内存从原来的 10M 放大到 10G 左右，可以在 10G 以内去做各种广播，在线上的效果收益非常明显。
1. 便利性
云厂商提供的像 EMS 资源基本上是开箱即用的，便利性非常强，但是如果有定制化技术的需求，可能就不太容易实现了，甚至会被厂商技术团队拒绝。2. 成本
成本要综合考虑计算资源、人员的成本、规模等因素。首先计算成本确实比较高，因为 CPU 很贵，在计算上建议尽量使用 EKS 资源。关于人员成本，如果一个团队去维护小规模的数据量，成本也会比较高。其中规模是一个变量因素。3. 响应速度
OPPO 是云上的大客户，会有常驻人员及时进行调查、回答、解决问题。小问题可以快速解决，但如果是专业问题，如计算任务出问题，还是需要提 case 走流程。
4. 上云的收益
大数据上云，可以快速搭建大数据的基建，如果公司业务发展比较快，开箱即用的资源比招一个大数据团队会省力很多。5. 是否适合上云
大数据是否适合上云，决定因素还是在规模，规模不大的情况可能会不太适合，当然也要从机型选择、账单分析、资源评估等方面去考虑。6. 上云的方案
上云方案有以下一些建议。首先，存储建议使用 S3，S3 提供的服务很划算。第二，计算尽量使用 EMS 资源，而不要用 EMR 资源。第三，有研发能力的团队，建议基于云原生模式在云上自建。第四，针对数据量规模比较小，且性能要求比较高的情况，可以选择 OLAP 模式。
公有云降本指标效果
1. 资源看板大屏
通过资源看板，可以对 AZ 集群进行管理。在看板上，对节点数、资源利用率、任务数等很多指标的情况进行了详细反馈，实现了对运行过程的问题管控，从而可以方便地针对问题进行算法调优。
2. EMR 资源图
EMR 资源图最左边是调度效率，反映了整个集群 24 小时的 vcore 和内存使用情况。
3. 快速扩缩方案
采用快速扩缩的方案去优化扩缩效率，提升资源利用率。如下图所示，上面是扩容的步长，要尽量降低扩容的速度，把资源利用率提升上来。下面非常长的是缩容步长，要尽量快速地把计算节点放下来。资源波动呈波浪式，是因为每个小时都会有迅速地扩和缩，尽量将资源用满。
4. 物理资源利用率
线段的长度代表着时间的长度，红线代表利用率在 70% 以上的长度，白色线段代表着 60%。平均利用率在 75% 以上。
5. container 热力图
调度策略尽量把 container 的热力扎堆起来，避免长尾的节点缩容一直缩不下来，整个资源率就会浪费掉。
6. 成本看板
在成本看板中可以实时看到运算时候用了哪些机器、用了多长时间，并且算出每一分钟的成本情况，实现对成本的实时管控。
对 CloudCamel 的展望
1. 技术迭代方向
从技术上讲，一是深入引擎的优化，提升计算效率，每做一次计算优化，都会节省一些成本；二是引擎扩展，目前只有 Spark、Flink，后面会在 Trino 上去进行扩展；三是在任务编排上，做 QoS 的调度服务，通过优化调度策略，尽量提升资源利用率，避免资源的快速扩缩容；四是在离线的混部，技术已经比较成熟，会尝试实际应用起来；五是数据治理体系化，目前只进行了底层技术架构上的优化，后面会开展数据治理，并形成体系化；最后是将公有云运维平台进行白屏化。
2. 运营方向
运营方面，计划去做账单的分析诊断，把更多的账单服务慢慢接入进来，从而可以更方便地查看需要优化成本的地方。同时尽量将 CloudCamel 整个方案进行产品化、平台化。
问答环节
Q：Hive、Spark、Flink 用的什么版本？
A：Hive 用的 2.3 版本，Spark 是 3.1.2，Flink 是 1.6。因为引擎上做了很多资源的优化，所以不能很快去跟进社区版本的更新。
分享嘉宾
INTRODUCTION
付庆午
OPPO
大数据架构师
目前在 OPPO 数据架构组负责架构演进研发，是 Spark 开源 RSS 项目 Shuttle 发起人，曾供职去哪儿网大数据，阿里云 MC 团队。
点个在看你最好看
SPRING HAS ARRIVED