:::: MENU ::::

TalkingData's Blog

现在开始,用数据说话。

构建新一代移动大数据管理平台

  • Sep 25 / 2015
  • 0
Data, Ideas, News, Tech

构建新一代移动大数据管理平台

以下内容为TalkingData研发VP阎志涛在“SegmentFault D-Day 北京站”的分享

1

我要分享的内容跟数据有关,因为Talking Data做移动互联网大数据,我会将我们摸索的一个如何建设大数据的平台经验分享给大家。说说移动互联网大数据的特点,这块偏虚一些,跟我们自己创业的初衷有关。我们做移动互联网的数据,为什么要做,2011年公司开始创业时,认为未来是一个数据的时代,想到移动互联网是一个比较好的切入点。

移动互联网的数据跟人的关系更密切,大数据有四个V,第一个是Volume,任何一个报道都说移动互联网的数据在爆炸。移动互联网随时随地可能都有不同的数据产生,实际上对我们自己来讲,我们从创业到现在收集到的数据的体量是偏指数级的增长。

另外一个就是Variety,数据的多样性,PC互联网的时候固定在一个工位上或者是一个电脑上来去使用这个电脑。可能很多数据都是被一个Cookie来串起来。而移动互联网更方便能够知道一个人在什么时间,在什么地点做什么事情。位置数据在移动互联网则有很多更有意思的东西。甚至知道你在这个咖啡馆里面做什么样的东西。

第三个V是velocity,对于移动互联网,因为随着这种对数据价值利用的要求越来越高,实际上对于数据处理上速度也越来越高,最初提到大数据大家一说就是Hadoop,但是Hadoop很难做到需要数据马上就出结果,因此需要更实时的一些计算的框架。最后一个V是Value,就是数据的价值,实际上移动互联网的价值远远高于互联网。

就像现在为什么那么多O2O的产生,跟移动互联网大发展有很大的关系。实际上移动互联网的数据能够跟你个人的关系更密切,社会是人构成的,所有数据也都是人产生的。能够收集到人相关越来越多数据的话,对于个性化服务、广告都会产生越来越多的价值。后面移动互联网是万物都联网,从去年到现在越来越多不同O2O创业的趋势,都是在获取更多高价值的数据。

回到技术本身,实际上说构建新一代大数据平台,就要说老一代大数据平台是啥样,我们的老数据平台实际上是以统计分析为主。就是一个报表平台,也是为了做一些统计分析。统计分析主要是宏观分析,如果在互联网时代看到的PV、UV等,在移动互联网每天有多少新增用户,多少留存等等。真正随着大数据应用越来越广泛,这些是不够的。所以我们要变革,这是我们早期的一个架构,实际上是以当时的统计分析为主的一个架构。这个架构大概是前年提出来的,叫lambda架构,当时是我们在刚创业的时候,在对于很多数据的分析场景,已经有实时这种需求。但是实时怎么去解决这个问题。当时对我们来讲就走实时和批处理两条线,结果后来有人总结了叫做lambda架构。

我们在做的时候storm还没有出来,我们自己当时基于Redis做实时流处理的计算。利用Redis的KV自增,通过实时的方式计算今日指标,到晚上的时候我通过一个批处理任务,去做一个最终结果出来。这蕴含一个问题,数据的变化,比如今天你看到的新增用户是500个,为什么到第二天去看昨天的用户就变成499个,这里面就是典型的Lambda架构。数据走了两条线进行计算,会出现不一致性。基于Spark的架构尝试在解决,会用同样的表达式,在实时和批量计算采用同样的算法,不过由于流式计算的数据和批量计算的数据还是两条线,可能还是会存在问题。

这是我们整个技术的选型。当时是2011年到2012年那个时候,也跟我们自己的技术积累有关系。我们当时的技术团队都是Java这套技术背景。当时我们数据量也没有那么大,基本上数据收集就用Java Servlet。实时的计算采用Redis,批量计算采用Hive。大家可以看到这个架构是非常简单的一个架构,这个架构伴随了我们两年到三年的时间。通过它衍生出了不同的产品线。慢慢就发现我们需要对这个东西进行重构,这个架构对很多新的数据业务并不能很好的支持。因为我们逐渐有数据利用的一些需求、有数据探索的的需求、有微观分析的需求,这个架构对这些都不能很好的支持,另外我们实际上是同一架构,拷贝到不同的业务线,但是每个团队基于这个架构开发都会有些自己的想法,于是整个架构的代码就在不同业务线之间开始背离。

对于我们来讲实际上就需要从技术上出发,进行进一步的规范化去梳理。所以说这时候我们就开始想做新一代的大数据平台。实际上想法就是说,我们要统一,把这些能力抽象出来。能够去变成服务化。另外一个就是支持数据探索的需求,我们最早没有太多的机器学习的东西在里面。随着数据量越来越大,随着客户的需求越来越多。包括我们自己数据这种需求越来越多。实际上我们需要整个平台有机器学习的能力,是一个智能的平台。我们公司也在发展,原来可能技术为主。慢慢的有了数据之后就有数据业务人员,希望在数据里面找到数据的价值。所以需要协作,需要微观的分析道具体的某一个设备,而不是统计分析的宏观结果。

另外就是说实际上从数据本身来讲,需要一个透明的平台。因为我是负责公司的数据,负责数据平台的研发,经常有人问我,我们这些数据有多少?我们iOS数据设备有多少?安卓设备有多少?比如昨天iOS9开始出来之后,当天有多少人升级?包括我们在设备上的标签,每天有多少打上去。有多少有问题的数据,这些都需要知道。

于是我们开始构建一个新的平台,新的平台构建以我们过去为基础,基本上就是属于要把存储统一,实际上是一个逻辑的概念,从物理上完全统一实际操作有很大的难度。然后再一个就是统一计算,包括他整体计算框架的选型。而消息总线最初我们是用的轻量级的kestrel,比较幸运的就是kafka的逐渐成熟可以去引入做我们的新消息总线。统一数据挖掘使我们有了数据挖掘的团队,可以把一些数据挖掘的算法去应用到这里面去。关于统一的数据呈现,因为我们都是从传统IT领域出身,最早并不是特别重视数据呈现这块。可是实际上现在所有好的产品,都必须有好的用户交互,所以说在视觉呈现这块也会越来越重视。成为了一个视觉呈现一个研发组专门做前端可视化的一些东西。

关于统一SDK, SDK是我们收集数据最基础的部分,我们所有的数据都来自于SDK,这个对于我们来讲是收集数据的第一步。在SDK统一之前,无论SDK团队还是数据平台团队,都非常痛苦。因为我们有三个业务平台,我要把所有的业务平台数据收集上来,统一之前我算了一下,我们每天在上传数据的SDK版本应该有60多个,对于我来讲,我要把所有的数据规范化处理,每个SDK收集的数据、格式还不尽相同。工程师非常痛苦,我基本上梳理SDK的每个字段含义已经很痛苦了。我后来觉得受不了,我们一定要统一SDK。SDK团队就开始去抽象,SDK变成了一个多层模型,包括基础的数据收集、业务数据收集和自定义事件相关的数据的收集。

从SDK角度来讲,除了统一SDK,我们也在做创新,比如灵动分析的能力。早期的SDK都是产品经理或者业务团队通过与程序员沟通,选择合适的地方埋点,然后打包上架。如果有错的地方,又要重新来一遍。大家知道应用上架是有一定的周期的,这样就会非常的耗时。通过灵动分析,产品经理或者业务团队不再需要程序员的介入就可以自己设定需要进行分析的点,并且不需要程序重新上架,这可以说是一个智能分析平台的一个小的体现。

数据收集统一也是一个渐进的过程。 数据收集的功能非常简单,不过要求却非常高,因为每天有上亿的设备在给我们发送数据,你可以理解成每天有上亿移动设备在给我们做DDOS攻击。第一个需求是要支持高并发,每秒几十万数据发送的请求要高效的接收并且能够保证数据不丢失。随着数据量的增大,后来我们发现早期的数据收集器性能越来越成问题,就开始做改造,这改造也分几个步骤。第一步是想node.js对于做高并发web请求处理应该比较合适,就用node.js开发了一个版本,不过发现node.js本身在处理大并发的时候,处理连接的能力有限,我们往前放一个Nginx。后来想既然引入了nginx,不如开发nginx 插件来做数据接收和处理,于是就变成了Nginx Plugin。另外数据收集器是一个存储转发的过程,于是我们基于lmdb开发了一个嵌入式的消息队列,用来存储接收的数据,后边的消费者在小批次的压缩将数据向后发。 整个架构要求是能够支持分布式的部署,初衷是希望能够将数据收集部署在云上,将压缩后的数据再传到我们IDC,从而能够降低IDC的带宽。新的统一数据收集带来了巨大的好处,因为部署在云上,我们能够更好的应对一些攻击的发生,毕竟云服务商的带宽和抗攻击能力远远比我们自己IDC要好很多。

 

存储这块,数据就是资产,既是客户的资产也是我们资产。对于原始的日志,我们是采用HDFS来进行存储,通过时间进行切片。加工好的中间结果会转成Parquet列式存储,从而提高数据利用的效率,另外,我们在考虑引入EC,对于冷的日志数据,通过EC能够相对的节省一些存储的开销。。

另外一个就是bitmap存储,为什么会有它?这也是为了统计分析而生的一个东西,对于大数据统计分析的话,多维度交叉分析是很重要的概念,我需要知道北京这种用户机型的分布。引入它的办法就是通过预建bitmap索引的方式来解决。这里面有一个问题。就是Bitmap本身,都是二进制的数据,如何有效的存储是一个问题。最初我们是把bitmap存储到MySQL数据库里面去了,在很多Bitmap计算的时候,序列化和反序列化的开销成了很大的问题。于是我们开发了一个针对Bitmap的存储。Bitmap存储是基于RocksDB进行开发的,这个存储还支持bitmap计算,这样bitmap的计算会下沉到存储,从而减少IO次数,提高性能。说到存储,不得不说一下MongoDB,这是一个让我们又爱又恨的东西。因为MongoDB的文档型数据库,你的数据如果是想自由扩充是非常舒服的,但是我们使用过程中遇到了不同的坑。首先是MongoDB默认引擎是基于mmap的,在数据集比较大的时候会有断崖效应。我们尝试去换,当时就说有一个比较好的TokuMX引擎,测试的时候无论性能、稳定性,线性扩充都很好。但是上线之后没多久就开始遇到了crash,对于我们来讲肯定要做主层复制,但凡主从复制出现数据不一致,就会出现crash,你还不知道是哪个key造成的。后来MongoDB收购了WiredTiger,我们又开始尝试WiredTiger,做测试,也还不错。上线,你基本上属于跑一段时间,就系统内存吃满,有内存泄漏,然后就开始查,打补丁,打了补丁之后跑,有好转,但是还是泄漏,原来一个礼拜吃满,现在一个月左右吃满。目前我们的计划是将Mongo的东西迁移到HBase上,HBase也有很多坑,不过我们新来了几个HBase专家,应该可以更好的满足我们的需求。

统一计算我们用Spark框架,Spark这块也是这两年比较火热的,对我们也起了不小的作用。实际上我们关注Spark应该2012年就开始,当时看到硅谷有一个数据的大会,有个关于Spark的演讲,当时觉得他的理念非常的好,于是就开始关注他。在2013年,由于我们机器学习算法用Hadoop效率非常的差,于是开始尝试引入Spark做机器学习。慢慢的我就发现Spark本身整体设计思想非常的好,代表着未来的大数据的一个生态。 另外Scala语言的表达能力非常好,原来用Hadoop MapReduce几百行代码写的东西,基于Spark用Scala,可能几行就能搞定。于是我们整个计算平台开始基于Spark进行构建。然后我们自己开发了一个任务调度系统,实际上对于我们来讲数据探索越来越多。然后有一些任务也要去跑,怎么更合理把这些任务调度起来。

剩下的目标就是把整个计算服务化,原来可能还是探索,把一些算法抽象之后变成一个学习的服务。让我们分析师可以算法叠加。

关于统一视觉效果,现在我们公司的视觉效果好多了,有专门非常有经验的视觉可视化团队进来。目标实际上是说要把可视化做成控件。我们的产品经理希望以后做一个新的分析产品不需要工程师的介入,把公共模块往里边拖一拖转一转。形成一个数据分析的产品。

关于运维系统这块都是运维团队的功劳。运维团队做了很多工作, 现在我们的运维监控平台支持短信、微信、邮件等报警。对于工程师来讲遇到问题马上就出现报警。

新架构带来的好处,第一个是更容易做数据业务的扩充。再一个是工程师的团队,实际上也比较容易专注。

另外前面提到这些东西还是比较粗,细节的东西就是说,我们整个平台起来之后,实际上现在对于数据分析师来讲。现在也在做的一个能够支持他们去看到一些结果。多元交叉的场景可以很快出来,如果当天数据的话他肯定在分钟左右这种时间就能够拿到一些想要的结果。

可是罗马不是一天建成, 架构看起来是美好的,可是实现的时候你就会发现好多当时没有想到的问题。我们的统一数据收集系统刚上去没有多久就出现问题,这还是最有经验的这个工程师在维护的一个东西;当时大家在计算的时候觉得没有问题,实际上有一个问题忽视了一点。我们当时的数据收集服务部署的机器是两台,结果其中一台出故障的时候由于活着的机器一台单独承担不了所有的压力,结果直接造成雪崩。

关于遇到的坑,Hadoop版本的选择也是我们遇到的一个大坑。我们2013年上这个集群的时候处于稳定安全的考虑,采用的是CHD 4.3。随着Spark的引入,我们开始越来越依赖于Spark.我们集群逐渐的扩大规模,数据量越来越多。突然有一天,Spark的升级文档说不在支持Yarn alpha版本,这时候我们才发现一个巨大的坑等着我们,CDH 4.3的yarn是alpha版本。

对于我来讲开始比较痛苦,对于我们来讲两条路,一个是对于每一个新版本Spark,如果想要新特性,就需要自己改Spark代码让他兼容Yarn alpah。另外一个就是升级Hadoop集群。第一个选择显然不划算,很难去维护。升级的选择则意味着要花很长时间去做升级和迁移。直接在生产环境做在线升级我们是不敢做的,怕丢数据。那能做的就是新建一个集群,慢慢的进行数据的迁移。 这个坑要爬出来,估计到今年年底完成就不错了。这算是我们自己,怎么在我们大数据中架构升级的一些经验分享给大家。

3

提问:听您说好多新技术,因为用的时候,其实我看您说的那个在数据收集系统上,集中系统,您这个系统用自己的技术一点一点做出来的…?

阎志涛:这个是第一个要做的事情,我们是2011年开始做这个事情。这个技术演进是这样,很多现在大家认识的技术在当时我们做的时候还没有或者不成熟。后面在做的时候,实际上因为我们整个场景不复杂。还是希望自己能够去把控这种东西。虽然你自己做的肯定是有风险。因为整个收集,SDK没有人给你去做了。他整个业务逻辑不复杂,对于我们来讲要解决这个场景,这是两个出发点。第一个是分布部署,第二个解决带宽的问题。IDC带宽开销每个月往上张。希望有一个可控高效压缩的算法。开源的东西都挺好的。但是我们选择开源还是选择我们自己可能做不了的。比方说我们不可能生产这么一个Spark出来。对于我们来讲如果是核心的东西,同时我们能做,本身我们自己能控制得了,就自己做了。

提问:你统计针对的是设备,苹果对这个设备的跟踪是有限制的。iOS封了UDID的接口,怎么做到这个准确性?iOS跟安卓比这个影响有多大?

阎志涛:这个实际上第一个到了新的iOS之后没有办法做到准确性。我们是基于IDFA生成一个TDID,存到他的存储。对于App来讲尽量保证你能够串起来。但是也不能百分之百的保证。他所有的东西都清掉就没有办法了。我们覆盖的App有很多,实际上我们在服务端尝试建立一个服务端串联的东西,类似用图数据库。但是的确是在iOS来讲,设备唯一性是没法保障的。肯定没有办法百分之百的保障。这个比安卓要差好多。

提问:数据差多少?

阎志涛:目前来看,IDFA稳定性还OK,重置的概率不是那么大。不过和Android还是有很大的差别。

Leave a comment

随时欢迎您 联系我们