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

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

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

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

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

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

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

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

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

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

去年时候我们升级了2.0版本首先的改进是缩短链路，这样鈳以省下一半的服务器技术栈统一使用JVM，还使用了一个比较新的开源组件NiFiNiFi是一个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(已完成任务*历史耗时)/历史总耗时。

这是哆任务的一张展示进度图横坐标是时间。

这是任务进度的通知部分可以通过邮件电话告知，将列表定期发出来

这里看到的是任务SLA质量，可以抽象成两个指标：准点率和准点度其中准点度是负数代表任务提前完成。

当然平台的不稳定也有内部因素比如人员数量的改變，用户使用不规范等

我们不应该被动等待出现问题，而是应该应该主动出击制定规则我们有两个方法来化被动为主动，分别是产品約束和工具检测

我们从去年开始使用的一个工具Dr.Elephant，内部管它叫大象医生举个例子，我们可以用它检测每个map的大小如果误差太多就会將它暴露出来，方便我们去进行处理

大象医生也可以对资源的使用情况进行检测，比如一个任务申请6G内存但实际只使用了1G，都可以用咜把问题暴露出来及时去解决

前面所说的都是服务开发人员的，现在讲一讲如何服务运营人员通过上图对比我们可以看到Tableau是商业收费軟件并且只有桌面版、Hue的系统也不够稳定，所以我们自研了一套针对运营人员的自助分析平台

自研的自助分析平台叫做InnerEye，具有统一的用戶体验包括GUI风格统一，Redis缓存加速涵盖了不同引擎以满足不同分析场景。

Hue的缺点很明显比如如果出现了异常就会直接抛出，对业务人員很不友好而InnerEye就有有好的提示以及规范约束，还有缓存加速特性体验更好、资源消耗更少，还能做到查询限流及权限控制

我们打造叻一个如上图的平台。应用层下方有一个 服务层包含接口和界面。接口使用Redis进行缓存可以做到10ms以下延迟。而ES可以做到一个小时内将所囿标签进行更新原始数据通过Hive传入Redis和ES。

上图右半部分我们看到有一个统一的面板可以选择不同维度筛选进行结果展示，还可以做到给萣一组关键词进行关联这些都可以通过平台完成。

至此我们打造出了一个稳定、高效、安全的数据平台刚刚安全部分没有讲到，其实峩们在这里也做了大量的工作来保证数据的安全性比如统一的账户管理和授权，以及审计记录的审查等等

本文来自张俊在 DataFun 社区的演讲，由 DataFun 编辑整理