大数据培训新三板挂牌机构 股票代码:837906 | EN CN
阿里巴巴菜鸟级数据产品经理半年回顾总结篇
干货教程:如何绘制业务流程图(二)
干货教程:如何绘制业务流程图(一)
技术贴:如何在数据库中秘密地查询隐私数据
攻略教程:信息图(infographic)是怎么做出来的?
分析师一定要看!用数据讲故事的五个步骤
技术篇:怎样玩转千万级别的数据?
北漂书生:大数据时代SEO数据如何搜集和分析
干货,从十大问题重新认识并读懂互联网
相似图片搜索、算法、识别的原理解析(下)
相似图片搜索、算法、识别的原理解析(上)
制作信息图时请遵循这10条原则
提高表格可读性的一些技巧,适用于Excel、PPT等数据报表
实用教程:如何让Excel图表更具“商务气质”?
一张数据信息图是这样制作完成的
菜鸟读财报,如何从上市公司财报中挖情报?
北大数据分析老鸟写给学弟们一封信
如何一步一步制作出高品质数据信息图?
总结:海量数据分析处理的十个方法
【实战经验】数据分析师如何了解老板真正想法?
零售业数据分析那些事儿
数据分析时l常用电子表格公式【大全】
用数据来告诉你 上市公司财报的秘密
这12个数据能 帮你搞定淘宝店铺
首席工程师揭秘:LinkedIn大数据后台是如何运作的?(四)
首席工程师揭秘:LinkedIn大数据后台是如何运作的?(三)
首席工程师揭秘:LinkedIn大数据后台是如何运作的?(二)
首席工程师揭秘:LinkedIn大数据后台是如何运作的?(一)
淘宝网店从激活到挽留,4步走玩转数据营销
文案怎样写才有意思、不空洞、打动人?
入门级扫盲贴:数据分析的步骤有哪些?
关系即数据,论社交媒体的关系转换
数据的力量,苹果教你用数据鄙视竞争对手
谁说文科生不能做数据分析?数据分析入行→技能提升→优势
产品运营数据分析——SPSS数据分组案例
如何追踪iPhone和iPad等移动设备的用户行为数据?
阿里巴巴中国站:用户满意度指标权重计算方法
广告中的AdNetwork、AdExchange、DSP、SSP、RTB和DMP是什么?
信息图制作教程:关于数值的表现
为什么大数据会如此轰动?(值得深度的文章)
多图技术贴:深入浅出解析大数据平台架构
面板数据分析中标准误的估计修正——根据Peterson (2009)的归纳
财务官、投资人、CIO看过来:给企业数据定价
推荐系统中常用算法 以及优点缺点对比
探索Weotta搜索引擎背后的大数据技术
如何识别虚假数据?
为什么我们像驯化小狗那样驯化算法
程序员必须知道的10大基础实用算法及其讲解
电子商务:最影响转化率的九大要素
如何迅速成为一名数据分析师?
想从事大数据、海量数据处理相关的工作,如何自学打基础?
如何用亚马逊弹性MapReduce分析大数据?
译文:机器学习算法基础知识
给hadoop新手的一封信:Hadoop入门自学及对就业的帮助
从入门到精通,我是这样学习算法的
小商家,从老客户身上获取的数据才更有意义
13页PPT讲述:大数据下网站数据分析应用
40页PPT详解:京东大数据基础构架与创新应用
67页PPT解密搜索引擎背后的大技术:知识图谱,大数据语义链接的基石
营销洞察力——10个营销度量指标
技术篇:前端数据之美如何展示?
董飞:美国大数据工程师面试攻略【PPT】
easel:如何制作好的信息图——来自专家的顶级技巧
大数据实操:以3D打印机为例,如何知道卖点有没有市场需求?
大数据建模 需要了解的九大形式
用户画像数据建模方法
从规划开始,公司or企业如何入手和实施大数据?
干货:商品信息数据分析和展现系统的设计与开发
高手教你用Excel制作百度迁徙数据地图
50篇干货:淘宝店/电子商务如何玩转数据分析?
精华索引:大数据实际应用案例50篇
验证最小化可行产品 (MVP) 的 15 种方法
干货:数据分析师的完整知识结构
大数据技术Hadoop面试题,看看你能答对多少?答案在后面
用SPSS做数据分析?先弄懂SPSS的基础知识吧
怎样做出优秀的扁平化设计风格PPT? 扁平化PPT设计手册#3
解答│做大数据过程中遇到的13个问题
40页PPT│社交网络发展的新动力:大数据与众包
以Amazon、豆瓣网为例,探索推荐引擎内部的秘密#1
怎样做出优秀的扁平化设计风格PPT?#2
怎样做出优秀的扁平化设计风格PPT?#1
36页PPT│大数据分析关键技术在腾讯的应用服务创新
如何丰满地做SWOT分析?
【35页PPT】TalkingData研发副总阎志涛:移动互联网大数据处理系统架构
27页PPT|以珍爱网为例,如何构建有业务价值的数据分析系统?
国外数据新闻资源分享
21页PPT重磅发布:Mariana——腾讯深度学习平台的进展与应用
从0到100——知乎架构变迁史
PPT解读:百度大数据质量保障方案探索
45页PPT|大数据环境下实现一个O2O通用推荐引擎的实践
从数据看豆瓣兴衰
深度学习系列:解密最接近人脑的智能学习机器——深度学习及并行化实现(四)
重磅推荐:129页PPT讲述移动时代创业黄金法则 via:腾讯企鹅智酷
重磅推荐:大数据工程师飞林沙的年终总结&算法数据的思考
OpenKN——网络大数据时代的知识计算引擎
大数据下城市计算的典型应用
技术贴:大数据告诉你,如何给微信公众号文章取标题?
你的QQ暴露了你的心——QQ大数据及其应用介绍PPT
如何从企业报表看企业的生存能力?
实用的大数据技巧合集
技术帝揭秘:充电宝是如何盗取你的个人隐私的?
重磅!50页PPT揭秘腾讯大数据平台与推荐应用架构
原创教程:饼图之复合饼图与双层饼图(1)
PPT:大数据时代的设计特点——不了解这个你做不了今天的设计
教程贴:如何用方程式写春联?
原创教程:如何用Excel制作简易动态对比图
深度译文:机器学习那些事
教程帖:数学之美——手把手教你用Excel画心(动态图)
董老师走进斯坦福,聊聊硅谷创业公司和大数据的事儿(附课件PPT下载)
【限时】年度钜献,108个大数据文档PDF开放下载
董飞专栏:大数据入门——大数据相关技术、Hadoop生态、LinkedIn内部实战
亿级用户下的新浪微博平台架构
一张图了解磁盘里的数据结构
浅析数据化设计思维在阿里系产品的应用
美团推荐算法实践
一个P2P创业公司有哪些部门,都是做什么的?
一个P2P平台的详细运营框架是怎样的?
机器学习中的算法——决策树模型组合之随机森林与GBDT
神经网络简史
58页PPT看懂互联网趋势,大数据/物联网/云计算/4G都有了
广点通背后的大数据技术秘密——大规模主题模型建模及其在腾讯业务中的应用(附PPT)
微信红包之CBA实践PPT——移动互联网海量访问系统设计
一文读懂机器学习,大数据/自然语言处理/算法全有了……
搜狐新闻客户端的背后大数据技术原理——推荐系统(PPT)
原创教程:用Excel做动态双层饼图
半小时读懂PMP私有广告交易市场
怎样分析样本调研数据(译)
PPT:支付宝背后的大数据技术——DataLab、Higo的实践及应用
大数据技术人员的工具包——开源大数据处理工具list(限时下载)
计算机视觉:随机森林算法在人体识别中的应用
24页PPT:机器学习——支持向量机SVM简介(附下载)
互联网高手教你如何搜集你想要的信息
深度:对地观测大数据处理、挑战与思考
原创教程:用Excel做饼图之复合饼图与双层饼图(2)
移动大数据时代: 无线网络的挑战与机遇(附pdf下载)
Excel使用技巧——25招必学秘技
【年度热门】加上这些 Excel 技能点,秒杀众人(多图)
原创教程:用Excel做纵向折线图
知识图谱——机器大脑中的知识库
何明科专栏:用数据化的方式解析投资条款
DT时代,如何用大数据分析创造商业价值(23页PPT)
MIT牛人梳理脉络详解宏伟现代数据体系
你的老婆是怎么算出来的?揭秘佳缘用户推荐系统
飞林沙:商品推荐算法&推荐解释
PPT:如何成为真正的数据架构师?(附下载)
开源大数据查询分析引擎现状
董飞专栏:打造数据产品必知秘籍
译文:如何做强大又漂亮的信息图
如何使用Amazon Machine Learning构建机器学习预测模型
如何运用数据协助货架管理(内附26张PPT)
SVM算法
主流大数据系统在后台的层次角色及数据流向
PPT:阿里全息大数据构建与应用
人脸识别技术大总结——Face Detection & Alignment
教程:用Excel制作成对条形图
易观智库:大数据下的用户分析及用户画像(18页PPT附下载)
技术向:如何设计企业级大数据分析平台?
电商数据分析基础指标体系
IBM SPSS Modeler 决策树之银行行销预测应用分析
拓扑数据分析与机器学习的相互促进
基于 R 语言和 SPSS 的决策树算法介绍及应用
用php做爬虫 百万级别知乎用户数据爬取与分析
另类新浪微博基本数据采集方法
以10万+阅读的文章为例 教你做微信公众号的运营数据分析
破解数据三大难题:变现?交易?隐私?
微店的大数据平台建设实践与探讨
阿里巴巴PPT:大数据基础建议及产品应用之道
基于社会媒体的预测技术
人工智能简史
技巧:演讲中怎样用数据说话
马云和小贝选谁做老公?写给非数据人的数据世界入门指南
掘金大数据产业链:上游资源+中游技术+下游应用
原创教程:手把手教你用Excel做多层折线图
销售分析:如何从数据指标发现背后的故事
如何一步步从数据产品菜鸟走到骨干数据产品
也来谈谈微博的用户画像
行走在网格之间:微博用户关系模型
如何拍出和明星一样美爆的自拍照?斯坦福大学用卷积神经网络建模告诉你
运营商如何玩转大数据? 浙江移动云计算和大数据实践(PPT附下载)
大数据分析的集中化之路 建设银行大数据应用实践PPT
腾讯防刷负责人:基于用户画像大数据的电商防刷架构
创业提案的逻辑
友盟分享 | 移动大数据平台架构思想以及实践经验
寻路推荐 豆瓣推荐系统实践之路
“小数据”的统计学
重磅!8大策略让你对抗机器学习数据集里的不均衡数据
小团队撬动大数据——当当推荐团队的机器学习实践
微博推荐架构的演进
科普文 手把手教你微信公众号数据分析
信息图制作的六个注意点
【权利的游戏】剧透新玩法:情理之中?意料之外
推荐系统(Recommender System)的技术基础
核心算法 谷歌如何从网络的大海里捞到针
Quora数据科学家和机器学习工程师是如何合作的
阿里巴巴PPT:大数据下的数据安全
数据建模那点事儿
全民拥抱Docker云–Lhotse系统经验分享
实时股票分析系统的架构与算法
架构师必看 京东咚咚架构演进
什么叫对数据敏感?怎样做数据分析?
推荐系统基础知识储备
刘德寰:数据科学的整合与细分 数据科学的七个危险趋势(视频)
实际工作中,如何做简单的数据分析?
分布式前置机器学习在威胁情报中的应用(附PPT下载)
数据科学 怎样进行大数据的入门级学习?
扛住100亿次请求 如何做一个“有把握”的春晚红包系统?(PPT下载)
从 LinkedIn 的数据处理机制学习数据架构
大数据会如何改变管理咨询公司(I)
优秀大数据GitHub项目一览
生硬的数字和数据新闻:这么近,那么远
经典大数据架构案例:酷狗音乐的大数据平台重构(长文)
揭秘中兴大数据在银行领域的系统部署
基于大数据的用户画像构建(理论篇)
【R】支持向量机模型实现
数据图处处有陷阱?五个例子教你辨真伪
如何用R绘制地图
你确定你真的懂用户画像?
数据模型需要多少训练数据?
【接地气】01 数据报表的颜色怎么配
游戏价值和数据分析新思路
【R】异常值检测
快的打车架构实践
豆瓣还是朋友圈:大数据、新方法和日常问
PPT数据图表,怎么做才好看?
大道至简的数据体系构建方法论
数据的误区及自身业务
新浪微博的用户画像是怎样构建的?
面试干货!21个必知数据科学面试题和答案part1(1-11)
易观智库:中国大数据产业生态图谱2016(附下载)
Airbnb的数据基础架构
50PB海量数据排序,谷歌是这么做的
大数据时代工程师如何应对–今日头条走进硅谷技术讲座
D3.js教学记(下)
D3.js教学记(上)
飞林沙:企业级服务公司如何赚钱?只有平台级产品才有大数据的理论
一个母婴电子商务网站的大数据平台及机器学习实践
7大板块 组成数据分析师的完整知识结构
干货:SaaS领域如何分析收入增长?
学术 | 词嵌入的类比特性有实用意义吗?
6个用好大数据的秘诀
一个数据库外行眼中的微信优化 (附专家补充)
大数据调研,如何实现快全准?
数据大师Olivier Grisel给志向高远的数据科学家的指引
数据堂肖永红:数据交易的是使用权或数据的增值,而不是数据本身(PPT附下载)
淘宝商品详情平台化思考与实践
刘译璟:百分点大数据理念和实践(图文+PPT下载)
如何快速搞定一份看起来还不错的演示文档?
【BABY夜谈大数据】决策树
数据驱动设计:数据处理流程、分析方法和实战案例
美图数据总监:Facebook的法宝,我们在产品中怎么用?
树的内核:量化树结构化数据之间的相似性
拿到用户数据之后,LinkedIn怎么赚钱?
GrowingIO张溪梦:增长黑客的核心 企业应该重视产品留存率(附PPT下载)
[译]Airbnb是如何使用数据理解用户旅行体验的?
微博推荐数据服务代理: hyper_proxy的设计和实现
星图数据谷熠:消费领域DaaS 大数据重构未来商业游戏规则(附PPT下载)
鲍忠铁:TalkingData大数据技术与应用实践(PPT下载)
【干货教材】数据分析VS业务分析需求
九枝兰专访:数字营销的核心—企业如何使用数据管理平台(DMP)进行精准营销
我们的应用系统是如何支撑千万级别用户的
R应用空间数据科学
Excel进行高级数据分析(上)
Excel进行高级数据分析(下)
国内各大互联网公司2.0版技术站点收集
网站数据分析思路导图
大数据分析报表设计开发要素
大数据需要的12个工具 推荐
YARN/MRv2 Resource Manager深入剖析—NM管理
YARN/MRv2 Resource Manager深入剖析—RMApp状态机分析
Hadoop 1.0与Hadoop 2.0资源管理方案对比
Hadoop 2.0中单点故障解决方案总结
Hadoop 2.0 (YARN)中的安全机制概述
Hadoop 新特性、改进、优化和Bug分析系列1:YARN-378
Hadoop 新特性、改进、优化和Bug分析系列2:YARN-45
Hadoop 新特性、改进、优化和Bug分析系列3:YARN-392
Hadoop版本选择探讨
探究提高Hadoop稳定性与性能的方法
《Effective C++》读书笔记(第一部分)
Hadoop分布式环境下的数据抽样
Hadoop计算能力调度器算法解析
如何编写Hadoop调度器
数据结构之红黑树
Hadoop pipes设计原理
《C++ Primer plus》学习笔记之”类”
《C++ Primer plus》学习笔记之”类继承”
《C++ Primer plus》学习笔记之”C++中的代码重用”
《C++ Primer plus》学习笔记之”异常”
《C++ Primer plus》学习笔记之”RTTI”
Hadoop pipes编程
Hadoop Streaming高级编程
《C++ Primer plus》学习笔记之”标准模板库”
《C++ Primer plus》学习笔记之”输入输出库”
Linux Shell 命令总结
算法之图搜索算法(一)
awk使用总结
素数判定算法
《C++ Primer plus》学习笔记之“函数探幽”
使用Thrift RPC编写程序
如何在Hadoop上编写MapReduce程序
怎样从10亿查询词找出出现频率最高的10个

友盟分享 | 移动大数据平台架构思想以及实践经验

于2017-04-01由小牛君创建

分享到:


友盟

摘要友盟大数据平台的架构借鉴了Lambda架构思想,数据接入层让Kafka集群承担,后面由Storm消费,存储在MongoDB里面,通过Kafka自带的Mirror功能同步,两个Kafka集群,可以分离负载;计算有离线和实时两部分,实时是Storm,离线是Hadoop,数据仓库用Hive,数据挖掘正在从Pig迁移到Spark,大量的数据通过计算之后,存储在HDFS上,最后存储在HBase里面,通过ES来提供多级索引,以弥补HBase二级索引的缺失……

友盟从 2010 年成立开始就专注移动大数据, 5 年来不仅积累了大量的数据,而且积累了丰富的技术和经验,那么友盟的大数据平台是怎样架构的呢?在刚刚结束的MDCC 2015 大会上,友盟的数据平台负责人吴磊在 Android 专场为大家做了技术分享。

以下是吴磊的口述,整理时略有删减。

关于友盟大数据平台

目前,友盟合作的 App 超过 64 万 ,同时为 23 万开发者团队提供服务,截止到2015年7月底,友盟数据平台总量 9 PB,每天增量压缩后有 7TB,每天要处理接近 82 亿的对话,实时处理 100K QPS,离线处理 800 多个常规任务,集群规模是 500 多台服务器, 14000 个 CPU 核心。

关于友盟数据架构

友盟架构思想友盟的架构主要参考了Twitter提出的Lambda架构思想。

移动大数据如上图所示,最下面是快速处理层,新增数据在快速处理层计算,这部分数据比较小,可以快速完成,生成实时视图。

同时,新增数据会并入全量数据集,进行批处理,生成批处理视图。这样,系统同时具有了低延迟实时处理能力,也具有离线大数据处理能力。之后通过数据服务层,把两个视图合并起来,对外提供服务。在外部看来,这是一个完整的视图。 就这样,通过 lambda 架构我们可以将实时处理和批处理系统巧妙的结合起来。

友盟数据平台整体架构根据友盟的业务特点,数据平台由下向上分成这几个部分:最基础的是日志收集,接下来进入离线计算和实时分析,计算后的结果,会进行数据挖掘,有价值的数据进入数据仓库。接下来友盟会提供一个基于 REST Service的数据服务,在此服务之上做各种数据应用例如:报表、数据分析报告,数据下载等等。两边的部分提供辅助的功能:包括任务调度和监控管理。

移动大数据友盟数据流水线结合友盟的业务架构和 lambda 架构思想,最终的系统如下图所示:最左边是数据采集层,友盟提供手机、平板、盒子的SDK给App集成,App通过SDK发送日志到友盟平台;首先进入到Nginx,负载均衡之后传给基于finagle框架的日志接收器,接着来到数据接入层。

移动大数据友盟使用两个 Kafka 集群来承担数据接入功能。上面这个Kafka集群被实时计算消费。下面的kafka是用于离线数据消费,两个集群之间通过Kafka的mirror功能进行同步。这么做的主要目的是IO负载的分离,避免离线部分过大的IO请求影响到实时计算部分;以及实时离线部分的业务解耦,方便两部分业务独立发展。

接下来是数据计算层,分别由离线计算层和实时计算层组成。离线部分,我们主要是基于Hadoop Mapreduce框架开发了一系列的MR任务。同时使用Hive建立我们的数据仓库,使用pig进行数据挖掘,现在我们也在逐步使用Spark来承担数据挖掘相关的工作。实时部分是通过storm来进行流式计算。

实时部分的计算结果会存储到 MongoDB,离线部分的数据存储在 HDFS 。离线分析的结果存储在 HBase 。因为 HBase 缺少二级索引的相关功能,所以我们引入了 Elastic Search 来为 HBase 相关表提供索引查询功能。最后通过统一的 REST Service 来对外提供数据服务。

关于友盟实践

通过以上的介绍,大家可能对整个大数据平台的结构和概念有了初步的了解。正如Linux 之父的名言,“Talk is cheap, show me the code!”一样,其实知道是相对容易的,难的是如何去实现。所以接下来,我给大家分享一些友盟在实践中得到的一些经验。

友盟实践之数据采集首先是从数据采集来说起,数据采集部分面临了很大的挑战。

  • 第一是大流量,友盟服务大量开发者,接受数以亿计的设备发来日志,每天要处理80亿次对话,数据量非常大。
  • 高并发也是移动互联网的特点。比如:用户在早上上班路上,中午吃饭后以及晚上睡觉前,是使用的高峰期,这个时候会对我们造成非常高的并发请求。
  • 还有扩展性,因为移动互联网是在高速发展的,最开始我们一台机器就可以抗住,随着发展我们现在可能需要10台,20台,如果系统没有横向扩展能力将会是很痛苦的事情。

友盟的数据平台经历了一个发展的过程。在2010年刚开始的时候,因为快速上线的要求,我们是基于RoR开发的,在后台通过Resque进行一些离线的处理。这个架构,随着互联网的爆发,面临巨大的数据压力,很快就不能适用了。

接下来,我们就切换到基于Finagle Server的日志服务器。这个Finagle Server是Twitter开源出来的一个异步服务器框架,很适合移动互联网的访问特点:高并发,小数据量。切换到Finagle Server之后,我们单台服务器的处理能力得到了极大的提升。同时日志收集服务的无状态特性可以支持横向扩展,所以当我们面临非常高压力的时候可以简单地通过增加临时服务器来解决。

友盟实践之数据清洗大数据的特点之一是数据多样化,如果不进行清洗会对后面的计算产生困扰。在数据清洗方面,我们花了很多精力,并踩了很多的坑。

1、首先说“唯一标识”。

做数据分析,第一件事情就是要拿到“唯一标识”。安卓系统里作为唯一标识的,常用的是IMEI,MAC, AndroidID。首先因为安卓碎片化问题,通过API在采集这些数据的时候,常常会有采集不到的情况。

还有其他一些异常的情况,比如有很多山寨机没有合法的 IMEI,所以会很多机器共用一个 IMEI,导致IMEI重复;有些 ROM 刷机后会更改 MAC 地址,导致 MAC 重复;大部分电视盒子本身就没有IMEI。这种情况下我们单纯用 IMEI 或者 MAC ,或者安卓 ID ,来进行标识的的话,就会出现问题。

友盟采用的办法是由单独的服务来统一计算。后台会有离线任务来进行计算,发现重复率很高的标识符,加入到黑名单里。在计算的时候,直接跳过黑名单里的标识,换用另一种算法进行计算。

2、在“数据标准化”时,也遇到了很多的坑

比如:“设备型号”,并不是直接采集 model 这个字段就可以解决的。拿小米 3 举例,这个手机会有很多版本,不同的批次 model 字段不一样。对于这种情况,如果我们不进行统一标准化,我们算出来的结果,肯定有问题。

还会出现多机一型的情况,例如 m1,大家都知道是这是一款2011年出现的热门手机,很有意思的是时过三年之后活跃设备数量发生了再次突增。经过调查发现,原来是他的一个对手厂家,在2014年底生产了一款畅销的产品,model字段也叫m1。因此,我们就需要把设备型号,通过专门手段来和产品名称对应上,统一标准化。

另外在数据标准化过程中,还会遇到“地域识别”的问题。地域识别是用 IP 地址来识别的。因为中国 IP 地址管理并不是非常规范,所以经常会出现,上一秒钟大家还在北京,下一秒就到深圳的情况。对于解决这样的问题,我们是选用设备一天中最常出现的 IP 地址作为当天的地域标识。

还有“时间识别”,也是很大的问题。最开始我们采用的都是客户端时间。但是客户时间有很大的随意性,用户的一个错误设置,就会导致时间不一致;另外一些山寨机会有 Bug,机器重启之后,时间直接就变成1970年1月1号了;还有一种可能,产生数据的时候没有网络连接,当他重新联网了,日志才会汇报到平台,这样的话数据就会产生延迟。

为了解决这些时间不一致的问题,我们统一使用服务器端时间。但是这样又带来了新的问题:统计时间和真实时间的差异,但是这个差异值是从小时间窗口(例如一个小时,或一天)观察出来的,从大的时间窗口来看是正确的。

3、“数据格式的归一化”也很重要。

因为我们 SDK,经过很多版的进化,上报上来的日志会有多种格式。早期的时候我们是采用 Json 格式,后期的话我们使用Thrift的格式。在数据平台处理的时候,两种格式切换很麻烦,所在我们在处理之前,我们把它统一成 Protobuf ,来进行后期计算。

友盟实践之数据计算在数据计算的时候,根据不同业务对于时延的容忍程度的高低,分为实时计算,离线计算和准实时计算。

实时计算,面临的挑战之一是时效性。因为实时计算是对延时非常敏感的,毫秒级的水平。如果说,你把不合适的计算,比如一些很耗cpu的计算放进来,会直接导致实时计算的延迟。所以在架构时,需要考量,把哪些放到实时部分合适,哪些不适合。另外实时计算往往会在写数据库时会产生IO延迟,需要对实时数据库专门进行专门优化。我们实时计算部分选用了MongoDB存储数据,同时不断优化MongoDB的写请求来解决这个问题。

另外一个挑战是突发流量。用户使用 App 的频率并不均匀,早上、中午、晚上会有很高的使用率,尤其是晚上10:00-12:00这个时间段会对我们系统带来非常大的压力,得益于之前的架构设计,在达到一定的阈值之后,会触发报警,运维的同学会进行临时扩容来应对这些突发流量。

因为实时计算通常是增量计算,因此会产生误差积累的问题。Lambda架构决定了实时和离线是两套独立的计算系统,所以必然会出现误差。如果你长时间使用实时计算的结果,这个误差会越来越大。我们现在解决的办法是在实时处理时,不要给他太大的时间窗口,比如说最多不要超过一天,超过一天之后,就要开始清理,离线部分的计算每天计算一次,保证在这个时候离线部分的数据计算完成,这样我们就可以用离线的数据来覆盖实时数据,从而消除这个数据误差。

离线计算,也会面临一些问题。最常遇到的麻烦是数据倾斜问题。数据倾斜这个事情,几乎是天然存在的,比如说一些大App的数据量,和小的App的数据量存在着巨大的差距,常常会在离线计算的时候产生长尾现象,并行的MR作业中总是有一两个任务拖后腿,甚至超出单机计算能力。

产生数据倾斜的原因有很多种,针对不同的原因,有不同的解决办法。最常见的原因是因为粒度划分太粗导致的,比如说我们计算的时候,如果以App ID来进行分区,很容易导致数据倾斜。针对这种情况,友盟的解决办法的是进行更细一步的划分,比如说我们通过App ID 加设备ID进行分区,然后再将结果聚合起来,这样就可以减少数据倾斜的发生。

第二个问题是数据压缩的问题。离线计算的时候,往往输入输出都会很大,因此我们要注意时时刻刻进行压缩,用消耗cpu时间来换取存储空间的节省。这样做能够节省数据传输中的IO延迟,反而能够降低整个任务的完成时间。

接下来会面临资源调度的困难,因为我们各种任务优先级是不一样的,比如一些关键的指标,要在特定时间算出来,有些任务则是早几个小时都可以。Hadoop自带的调度器无论是公平调度还是能力调度器都不能实现我们的需求, 我们是通过修改hadoop的调度器代码来实现的。

另外我们还有一类任务对时延比较敏感,但是又不适合放到实时计算中的。这类任务我们称之为准实时任务。例如报表的下载服务,因为是IO密集型任务,放入实时不太合适,但是它又对时间比较敏感,可能用户等三五分钟还是可以接受的,但是等一两个小时就很难接受了。对于这些准实时任务我们之前采用的是通过预留一定资源来运行MR来实现的。现在用spark Streaming 专门来做这些事情。

在进行准实时计算时,里面也有一个资源占用的问题,在预留的过程中,会导致你的资源占用率过低,如何平衡是个问题;第二点很多实时计算的任务,往往也采用了增量计算模式,需要解决增量计算的误差累计问题,我们通过一定时间的全量计算来弥补这个缺陷。

友盟实践之数据存储数据存储,根据我们之前的计算模式,我们也分为在线存储和离线存储两部分。在实时部分的计算结果我们主要存在 MongoDB 里面,必须对写IO进行优化。离线数据计算结果一般存储在 HBase 里。但是HBase缺少二级索引。我们引入了Elastic Search,来帮助HBaes进行索引相关的工作。

在做数据服务的时候通过数据缓存能够解决数据冷热的问题。友盟数据缓存用的是 Redis,同时使用了 TwemProxy 来作负载均衡。友盟在数据缓存这方面的经验就是需要预加数据,比如:每天凌晨计算完数据之后,在用户真正访问之前,需要把部分计算结果预先加载上去,这样等到用户访问的时候,就已经在内存里了。

友盟实践之数据增值整个大数据的系统,价值最大的部分,就在于数据增值,对于友盟来说,目前数据增值主要分两个大的方向。

1、首先是内部数据打通。

友盟实现了个性化“微”推送,基于用户事件,结合用户画像、以及和阿里百川合作提供更多的维度信息,来为开发者提供更精准的推送。

比如:对一个汽车电商类的 App,可以圈定一部分有车的用户来推送汽车配件相关信息;然后圈定一部分无车用户来推送售车相关信息。

2、友盟在数据挖掘方面做了很多工作。

友盟针对现有的设备,进行了用户画像相关计算,通过用户画像能够了解用户的属性和兴趣,方便后续的数据横向打通。同时我们提供了设备评级这个产品。这主要是针对一些作弊行为来设计的。比如说一些App,进行推广的时候会发现,有些渠道的推广数据会有不真实的情况。

为此通过数据平台的统计算法和机器学习算法,把我们现有的所有设备,进行评级,哪些是垃圾设备,哪些是真实设备,能够很好的识别出来。这样一来,如果开发者有相关需求,我们可以提供设备评级相关指标,来帮助开发者测评这些推广渠道,到底哪些可信,哪些不可信。

围绕着这些渠道刷量的问题,我们还推出了健康指数。设备评级产品,只是从设备和渠道的角度,来观察作弊的问题;而健康指数是从一个App整体的角度来观察作弊情况。

作者:一木Grace
链接:http://zhuanlan.zhihu.com/umeng/20290418
来源:知乎

End.