美图数据统计分析平台架构演进

摘要：美图拥有十亿级用户，天天有数千万用户在使用美图的各个产品，从而积累了大量的用户数据。随着App的不断迭代与用户的快速膨胀，产品、运营、市场等愈来愈依赖于数据来优化产品功能、跟踪运营效果，分析用户行为等，随之而来的有愈来愈多的数据统计、分析等需求，那么如何应对和知足不断膨胀的数据统计与分析需求？业务的不断发展又怎么推动架构实现的改造？本文将介绍大数据业务与技术的碰撞产物之一：美图大数据统计分析平台的架构演进，但愿经过此次分享能给你们带来一些解决数据业务与架构方面的思考。 

若是有作过大数据相关开发的同窗应该知道数据统计是一个比较尴尬的事情，第一个它可能不是一个很是有技术含量的事情，对于技术人员的成长来讲不是很是好。第二它多是一个比较重复工做的事，须要解决一些简单的需求的重复工做。

 

美图其实有很是多的App，每一个 App 基本上都会有相应的产品运营、销售以及数据分析的同窗，这些同窗会提各式各样数据统计的需求，好比数据报表或者数据分析的需求。这么多的分析或者说数据统计的需求，在美图是怎么解决的呢？今天主要想介绍下在美图的解决方案，但愿你们在平时工做中有遇到相似的问题的话能有一些共鸣之处。

内容主要分三块，第一部分是统计业务与技术碰撞。通过第一部分的演进之后，咱们有沉淀下来一些东西，有一些思考知道怎么去解决这些问题，因此第二块主要是介绍美图统计平台架构的实现。第三部分将介绍咱们正在作的事情以及将来的一些规划。

 

统计业务与技术碰撞

这基本上是我本身亲身的经历，刚开始一我的作这一块的业务，会碰到一些有意思的点，可能分三个阶段，第一个阶段是在项目的初期，咱们是怎么样去应对一些产品的初期需求的。第二个阶段是当用户量爆发之后，业务数据源上来之后咱们又是怎么迭代的。第三是做为一个有一点追求的技术人员来讲，怎么让本身去脱离一些业务，获得一些成长。

第一阶段——项目初期

这个阶段特色很是明显：以美拍为例，初期总体的数据体量小；统计需求比较少主要是一些基础的统计指标；产品的迭代很是快，要求数据的统计指标可以快速地跟上产品的迭代速度。

 

 

这一阶段的解决方案在如今看来很是的简陋：一个是业务的服务端可能会有多个节点，保证可用性，每一个业务节点的服务会打相应的日志到本地磁盘，而后会经过rsync的方式统一同步日志到一个数据存储节点，在这个节点上写一些简单的shell或者php脚原本实现统计逻辑，配置相应的crontab来定时触发统计任务，最终把数据结果存储到MySQL供展现层调用呈现报表。

 

第二阶段——快速发展阶段

当用户量忽然爆发之后，数据量会不断的增大，产品运营、数据分析的需求愈来愈多，相应第一个阶段的解决方案会存在比较大的问题，主要有几个：第一个是单点存储的容量很是有限，第二是计算瓶颈很快就会赶上瓶颈，不少时候统计报表由于计算瓶颈致使报表次日延迟产出，第三是咱们用shell或者php脚原本实现统计逻辑，总体后续的维护成本比较大，须要调整一个统计逻辑或者增长一些过滤条件等都比较不方便。

 

 

因此咱们作了一些调整：第一是实现了一套数据采集的系统，负责作服务端日志的数据采集工做，将数据最终落地存储到HDFS；第二是前面有提到说存储和计算的单点问题，因此咱们本身搭建一个Hadoop集群来解决单点的存储和计算；第三是基于Hive来解决编写过多统计逻辑相关的代码。

 

第三阶段——有追求的程序员

当需求不断膨胀的时候，做为一个有追求的程序员会考虑到，重复的代码量很是多，即便咱们有架一层Hive来写相应的代码，最后作一层数据的过滤或者一些聚合。其实每个统计需求咱们都须要写一个相应的 java 的实现。这个工做量很是的枯燥，也是不断重复。

 

 

一个有追求的程序员的话，可能不会甘于天天作重复的工做。由于在平时接触业务与实现过程当中，深有体会统计业务逻辑的流程基本上是一致的，因此考虑抽象出这样一个相对通用的业务处理的流程，基本的流程是从数据源Query出数据，而后作一些业务方面的聚合或者过滤，最终把数据存储到DB。那在代码实现层面作了一层抽象，抽象一个统计的组件，包含Query、Aggregator以及DBStore，而后分别有一些不一样Query和Store场景的实现。当作了一层这样的抽象之后，相比于前面的方案，生产力仍是获得了比较大的提高。当时我一我的，一天可以作四五个统计需求，而抽象后一天从了解需求开始到实现大概能作七八个统计需求，总体效率有不错的提高。

 

美图统计平台的架构实现

作了上面的抽象之后仍是有很多的痛点，一个是业务的依赖，指的是咱们作一个统计需求最花时间成本的是去了解数据业务方的需求背景，了解他们的产品长什么样子或者他们的运营是作了什么活动，业务沟通背景的成本很是高。第二是即便作了抽象仍是会有一些相应的重复代码的编码量，还须要作一个统计的组件选择相应的query，相应的业务逻辑的处理以及存储层的DBstore。第三主要是运维成本高，当时上线一个任务须要作一个包到线上，还须要改一些shell等脚本。第四是涉及到我的成长方面，当一我的长时间在作这样事情的话，对我的的技术成长实际上是有比较大的瓶颈。

 

 

基于上面的痛点，咱们来介绍一下咱们是如何解决这些事情的。咱们考虑去作一个平台，让业务在咱们这个平台去使用，咱们提供服务就好。图 4 是咱们当时作平台化的大概思路，好比左边这个业务方有很是多的报表数据需求，也可能有App的数据场景、商业广告等的数据需求，咱们但愿可以提供这样的一个平台，业务的数据需求方在这个平台上面配置他们想要的数据指标，而这个平台负责数据的计算、存储，以及最终吐出相应的数据给数据应用方。

 

更进一步，在作这个平台时，咱们可能须要考虑如下几个比较重要的点：第一，咱们可能须要对统计任务有一个比较清晰的元数据描述，能够描述出这些统计任务的计算方式是什么样子，算子是什么。第二是这个统计任务的数据源来自于哪里，以及数据须要存储在什么地方更合适业务查询。第三个是须要有一个调度中心来统一调度全部统计任务的执行。第四要确保任务的最终的正确执行。

基于上面这几个点，考虑须要有一些不一样的模块来负责上面的说的几大功能。咱们大概有设计三个模块：第一个模块是JobManager，主要是提供平台，供应用方比较方便的配置，能管理任务元数据信息以及其余的数据仓库、app信息的管理等。第二个模块是Scheduler，就是任务的调度中心，负责调度全部的统计任务。第三是任务执行模块JobExecutor，负责任务从查询、聚合到最终的结果落地存储。

接下来详细介绍下这三个模块大概的功能点以及实现的方式。先说第一个模块JobManager，如图5，主要须要提供一个应用方在这个平台上去配置他们想要的数据，另一个点是咱们须要有整合数据仓库，整合数据仓库主要是为了业务方可以查看到他相应业务表的信息。右边这一块主要是对于元数据统计任务的描述，主要包含这几个大块，好比说数据的来源，统计的算子是什么以及存储的介质或者特殊场景的数据过滤器、维度聚合以及任务与任务之间的依赖关系描述。这个模块主要是抽象统计任务，对任务的元数据作统一的配置管理。

 

第二个比较大的模块就是任务调度scheduler。当前的实现方式比较简单，是单点的方式。当前有实现的几个点，一是可以根据任务的优先级来调度，二是可以根据任务定时的策略进行调度，三是可以调度工做流，就是依赖关系的调度。

 

第三个模块是任务执行的模块JobExecutor（图6）。根据任务的源信息从插件池里组装出具体的query组件，而后到具体的Query层（好比Hive）跑相应的数据，出来后的数据作一些过滤、维度方面的聚合，最终根据任务的信息来组装数据的存储层的组件，把统计数据结果写入到存储层。

 

 

讲完三个模块之后，咱们来回顾一下这个统计平台的基础架构。左边有一个JobManager管理元数据，根据元数据去作统计任务的总体标准流程：查询、过滤、维度聚合、存储。有了这样基础的框架之后，能够知足一部分的基础数据统计的场景，但若是是要支持更多的数据统计的业务场景的话，须要作更多的功能的拓展（图8）。

 

 

这里面有四个大方向的功能拓展，第一个是针对临时取数的场景。不必定全部的业务都须要常规例行跑，有很是多的临时跑数场景，好比分析人员须要临时看一个相应app的功能数据或者是说运营须要看一个临时组织活动的数据指标等等，平时会遇到比较多的临时取数相应的需求。对于解决临时取数这一块的需求，咱们作的功能有两个，一个是有提供直接填写SQL的功能，支持有SQL基础的用户临时提取数据。这块是扩展Hive自集成的antlr来作HOL语法解析，解析出来之后，须要校验HOL的合法性，主要是排除一些相似insert、delete操做，以及限定跑数的时间范围以避免长时间占用集群计算资源。

 

第二个功能扩展是尽可能丰富数据源，在平时的需求中，会愈来愈多遇到须要导入业务方的MySQL的数据来作简单的数据统计或者join计算。因此这一块咱们是有基于sqoop开发一个插件，来支持导入业务MySQL库表到Hadoop。第三就是Bitmap。这是咱们美图自研的一套系统，主要是为了便于多维度去重以及作新增、留存等相应的计算，其原理主要是基于位bit之间的操做。

 

第三个功能扩展是多存储，当前大部分的数据是存储在MongoDB，介于传统关系型数据库以及NoSQL之间，既能大部分知足业务的查询场景，又能保证分布式的数据存储。第二就是有临时比较大的数据导出状况，业务方须要获取批量比较大的数据，他们可以导入到HDFS上面，而后业用方从HDFS导出数据用于不一样的业务应用。第三也支持一些普通文本，好比csv等。第四就是MySQL，这个当前有支持一些分表的策略的存储。最后一块就是要丰富统计算子，当前有实现一些去重、数组、TopN等统计算子。

 

另一个大的功能拓展方面主要是数据可视化（图9）。由于存储层是多样多样，原来的方式是咱们的存储层直接暴露给应用的数据后台，他们从咱们的存储层查询数据解析，这个方式有一些不太好的地方，第一个是数据台若是不去透明化这个存储层的话，展现层开发须要学习Hbase、MySQL、Mongo等，有比较大的学习成本。第二是数据安全方面的考虑，或者对数据存储的统一的管理，都是有比较很差的地方，因此后面整了一套统一通用的API，有定制一套统一数据的协议，方便展现层统一对接数据作展现。

 

但接下来还会有一些问题，咱们须要去考虑平台化的数据安全（图10）。好比一般状况下，美拍的后台只可以获取到美拍相关的数据，而不容许美拍后台能获取到其余app商业广告的数据，因此咱们有实现一个统一的认证中心CA，就是业务方后台须要先去CA获取相应的受权token，而后去请求统一通用API时都会带上acess token，通用API做为一个通用服务方，会去CA认证这个token是否是合法，合法的话才会在存储层查询相应的数据，最后返回给应用方。

 

 

因此到这边，回顾下美图统计平台的总体架构：有一个统一的任务调度中心调度全部的统计任务，而后是JobExecutor负责从插件池来找相应的插件，作一些查询、过滤等，最终数据存储到DB，会有一个统一的API封装存储层，而后处于一些安全方面考虑有接入CA，最终各个数据后台对接通用API来作数据展现。

当前正在作的事情以及将来小阶段的规划

 

当前正在作的事情有两块，尚未正式上线或者接入。第一块是咱们本身开发一套分布式调度，这套调度主要偏一套通用调度平台，不只调度统计的任务，后续能够调度全部的离线计算的任务以及离线统计的任务，接下来全部的统计任务都会迁移到这个通用分布式调度平台上作统一的任务调度，替代当前单点的简单版本的调度中心。后续也会去支持资源方面的隔离和资源方面的调度。第二块就是数据可视化。咱们刚刚看到的前面那一块，业务方的全部数据后台须要一遍遍重复地接入咱们的统一通用API，是有比较多的重复工做，另外一个痛点是确实是涉及到一些比较大的APP，好比美拍他们总体的统计报表很是多，后台基本上多是成百上千这样的数据，若是一个数据需求方想看到他们本身的数据，对于他们从成百上千个数据指标去定位到本身的数据指标是很是困难的。数据可视化这么一个平台就是解决这样的问题，我不须要全部的业务方都接入这个通用API，在同一个平台能够选择想要的数据源或者本身可视化的报表，而后呈现本身个性化的数据指标，不须要再去跟全部应用的数据后台去对接咱们的API，而后作一些图形方面的展现。因此数据可视化这一块主要是作统计以及提供定制化、个性化的数据报表，有点相似于网易的bdp或者阿里的dataV等平台。

另外两块是接下来一段时间规划要作的事情，第一是数据分析人员常常抱怨说这个数据能不能有更快的查询方式，因此是考虑搭建一个OLAP服务，好比基于kylin等来构建。第二个是实时统计方面，刚刚前面讲的要么是定时的常规的统计需求，要么就是临时的统计需求，没有实时。因此这一块考虑说后面这个平台也能对接实时的统计需求，能更快速地对接知足实时统计需求场景。