盛锐大视界柏燕@揭秘万亿级别的全域数据统计分析平台技术架构演进友盟+数据平台技术架构主要包含数据采

友盟+数据平台技术架构主要包含数据采集&amp接入、数据清洗&amp传输、数据建模&amp存储、计算&amp分析、查询&amp可视化，其SaaS服务部分基本架构参考下图。

文章图片

文章图片
这是一个非常概要的架构图，这个架构被称为lambda+架构。尽管近几年有一些新的架构提法，比如Kappa之类，但lambda仍然是经典架构。友盟+统计分析产品无论是移动分析U-App还是网站分析U-Web ，都为用户预置了功能丰富的报表，这些报表是在多年服务客户的过程中积累的需求。对于预定义报表， lambda架构进行预计算非常适合，客户只需要集成基本的SDK ，就能得到这些丰富的报表。因为结果都是预计算好的，直接查询结果，报表响应很快。
那为什么叫lambda+架构呢，加的部分主要是指adhoc分析， adhoc分析对数据化运营真正进行了赋能。友盟+新的统计分析服务允许客户进行adhoc细分、漏斗、留存、分群等，并对一些常规的分析则可以设置为例行计算。但adhoc分析从时效上可以有两种服务，一种是慢分析，一种是交互式分析。前者能提供精确的全量分析，后者侧重分析探索效率，这种分级方式是我们对成本和效率的折中。
在友盟+新的统计分析平台中，最主要的能力集中于海量数据的实时计算能力和离线计算能力和交互式分析能力，以及这些能力提供出来的数据分析能力。
友盟+实时计算使用blink（flink）， blink功能非常完整，有高效状态存储及checkpoint机制，支持数据幂等计算。实际上友盟+实时计算引擎进行数次更换（storm-&gtgalaxy-&gtblink），以后还可能再换或引入别的引擎（比如私有化），所以我们开发了一套与引擎无关的实时计算框架，该框架整体上分为两层：core层和适配层。 core层定义了一些基本的对象、接口、算子，以及一些通用的辅助对象和业务flow 。这些基本对象、接口、业务flow与前面提到的lambda通用计算框架是一致的。适配层的目的是适配不同的计算引擎，比如blink、beam、sparkstreaming ，这一层实现较薄，其关注点不再是业务逻辑，而是如何选择作业参数、如何配置资源、是否做作业拆分这些问题。
实时计算的挑战主要有以下这些：
数据倾斜问题：个别客户数据量巨大，用户数巨多，站点及应用级别的统计数据倾斜十分严重；某些统计粒度太小（比如按受访页面或来路页面），对细粒度统计进行排序甩尾的节点压力会比较大。数据倾斜的普通解法是通过数据加salt打散局部聚合再汇总的方式，但这种方式需要多加一个处理层，资源消耗较大。我们采取的方式将实时计算变为小批量，然后在map层进行localreduce（类似于hadoopmap层的localcombine）。这种简单处理系统性地既解决了数据倾斜的问题，又减少了聚合计算map层和reduce层传输的数据量，提升了性能。
巨量groupbykey和状态存储：以web统计为例，需要对来路页面、受访页面级别进行pv、uv统计。个别大客户单天key的数量就超过2亿，总key的数量是百亿级。解决办法包括：短key替换长key、长尾key过滤、自动采样还原等。
高tps输出：以web统计为例，因为几乎所有指标都进行实时计算，高峰期每秒更新的统计结果超过300W 。我们一方面通过异步buffer刷新方式牺牲一定时效性（秒级延时-&gt分钟级延时），降低实际数据输出tps；另一方面没有使用通常的hbase等系统存储实时计算结果，而是使用自研的一套系统，该系统不但支持很高的刷写性能，而且还支持不同列的topN索引功能。