OPPO大数据平台运营研发实践分享_大数据_DataFunTalk

AIGC在金融场景是如何落地的？了解详情 



 写点什么

今天想给大家分享一下 OPPO 大数据平台规模极速增长历程中我们所做的一些工作，包括我们之前遇到的一些坑和收获的心得。

之前已经提到过 OPPO 的互联网发展是非常快的，对应到我们数据的规模和平台的规模在过去两三年也是在极速增长，那么我们怎么应对这些挑战呢？

我们在内部有一个口号就是要打造稳定、高效、安全的数据平台，上面这张照片是整个数据中心在公司的一个门面。这六个字说起来简单，但是在实际运营过程中碰到了许多坑，今天给大家分享一下如何面对这个挑战。

首先给大家介绍一下数据平台的一个总体架构，这里列出了主要的部分，我们把整个平台架构分成了三个层次。

首先是最底层，这是一个基础的系统。我们会用到 Hadoop 生态中的一些组件，包括一些实时的处理和离线的处理，还有数据的采集以及 OLAP 分析。这些组件目前主要是应用的开源组件，也有一部分是自研的定制化系统。

在这些基础系统之上，我们开发了很多自主的服务。面向开发者的平台包括数据接入和任务调度，面向应用平台的主要是服务我们内部的运营人员和产品人员，我们要帮助他们去做一些多维分析、报表分析还有用户画像等等应用。

在最上层就是数据的一些应用，一些点击预估和优化推荐、个性化推荐、运营指标分析、用户标签计算等都是基于这里来做的。

然后我们看一下架构的左右两边。左边是一些平台运营部分，用来支撑平台的运营；右边是数据安全的部分，用来保证我们的数据隐私性和安全性。

今天因为时间所限，我主要介绍一下平台的运营和自主的服务研发部分。

刚刚提到了我们整个平台的两个基本服务，其中一个是数据接入。我们接入的平台也经过了一次版本的演进，在 1.0 时代我们的数据来源主要是两部分：一个是服务器日志，另一个是我们手机上的客户端埋点。这些埋点我们统一通过一个 Go 语言开发的 HTTP Server 落到一个本地的文件，再通过一个 Python 开发的类似 Tail 的工具，把这些实时滚动的内容集中到 Flume 集群，然后再转到 Kafka 集群做实时计算和 HDFS 做离线的处理。这个架构支撑了我们前期的一些工作，但是也有很大的瓶颈：涉及的系统多、链路长、技术栈多、协调性不够好、维护成本高。

去年时候我们升级了 2.0 版本。首先的改进是缩短链路，这样可以省下一半的服务器。技术栈统一使用 JVM，还使用了一个比较新的开源组件 NiFi，NiFi 是一个 Apache 的顶级项目。我们通过这些组件对整个架构做了精简。

那我们为什么要用 NiFi 的系统来替代 Flume 呢？第一点也是最大的优势是 NiFi 是一个可视化界面，而 flume 都是一些配置文件。上图中每一个框都是 NiFi 的一个环节，可以把它们抽象成一个个处理器。处理器和处理器之间有数据的流转，同时支持集群的模式，把数据处理好以后它可以自动分配到集群上，去做数据的接入。再有一点是 NiFi 可以支持丰富的数据转换（包括格式转换，加解密操作等），对数据落在 Kafka 和 HDFS 上提供了很好的支持。NiFi 每个处理器和处理器之间都有一个消息队列，每个队列可以实现一个缓冲来保持架构稳定。我们基于 NiFi 进行了很多的扩展开发来满足定制化数据转换需求，同时实现端到端的性能测试和优化以及指标采集监控。

第二个就是任务调度平台，也是从 1.0 进化到了 2.0 版本。1.0 是一套自研的 Shell 脚本，在到达上千个任务的时候及时升级到了 2.0 版本的 OFlow。

那么新版本的任务调度平台优势是什么呢？我们总结了有三个优势。

一、可视化界面。新的平台跟 NiFi 一样是一个可视化界面，每个任务之间的依赖可以进行可视化管理。

二、任务树。通过任务树可以方便查看到任务的历史执行情况、运行时间状态等。

三、甘特图。整个任务做成一个甘特图，通过任务链条和基于时间的执行情况，方便诊断问题。

其次我们基于 AirFlow 做了下面这些改进：BUG 修复、细粒度权限控制、运营时发现的任务执行同比监控。通过上图我们可以很清楚看到是在哪个阶段出现了问题，看到这个阶段对比历史有延后。

我们的运营数据平台也会面临很多有困境，比如 Hadoop 系统非常杂、监控指标过多、诊断成本高等。

这个冰山图大家都见过，我们从上往下看，上面是大数据生态、抽象成一个平台画像的概念，类比于用户画像。我们把平台画像抽象成三个方面：数据、资源、任务。下面我们从这三个角度看剖析我们在平台画像上做了哪些工作。

首先来看看数据。数据这一块怎么看是否满足业务需求呢？数据接入吞吐量有一个监控曲线，可以跟历史曲线对比。如果哪一天相差比较大，那就需要我们进行紧急介入处理。

然后是监测数据接入是否出现堵塞，如果像图上出现了一条红线说明数据接入遇到了堵塞，需要做紧急处理。

再有我们还需要考虑跟下游系统有衔接的问题。如果下游接收速率跟不上也会产生影响，这里可以检测是否跟得上。这是从数据的三个角度来看的。

从资源方面我们也有 5 个角度去看。第一个就是资源池的使用率，这是一个最简单的指标，当然资源池使用率指标也可以用于参考不同业务的资源分配情况。

再一个也是很重要的指标叫资源池缺口率。若是缺口率很高，说明资源严重吃紧，需要紧急调配资源进行介入。

第三个叫做资源池透支量。为了保证各个业务公平高效的使用资源，我们允许透支资源，毕竟每个业务的高峰期不是一样的。但是如果透支量达到一定程度时，就要进行介入防止风险。

第四个是资源池作业量。通过密切的监控，我们可以看到 Container 数和 App 数情况平均值。

第五个是资源消耗占比，这是一个汇总的展示。

现在说一下任务 SLA 管理，我们整个数据平台上有几千个任务，其中一项重要的工作就是梳理核心业务。我们去跟不同业务去聊，比如有些数据需要每天上报给高层领导，那么就把这些认为是核心任务，优先处理。

我们会根据核心业务要做一些平台画像，从三个角度去看。

第一个是任务进度。有一些任务有很多前置的依赖任务，比如我们有一个任务有 20 多个前置任务，如果不做任务监控，延迟会越来越大。上面这个图可以显示这个任务历史上进度的情况，上方曲线是历史进度、下方曲线是今天的进度，可以看到此时已大大落后历史进度，这就已经很危险了，必须紧急介入处理优先保障服务。那这个任务进度怎么计算呢？我们有一个公式：任务进度=sum(已完成任务*历史耗时)/历史总耗时。