专访QQ大数据团队,谈分布式计算系统开发

标签: qq 大数据 团队 | 发表时间:2014-07-14 17:44 | 作者:manzhizhen
出处:http://www.iteye.com

NoSQL是笔者最早接触大数据领域的相关知识,因此在大家都在畅谈Hadoop、Spark时,笔者仍然保留着NoSQL博文的阅读习惯。在偶尔阅读一篇Redis博文过程中,笔者发现了 jacksu的个人博客,并在其中发现了大量的分布式系统操作经验,从而通过他的引荐了解了QQ成立之初后台3个基础团队之一的QQ运营组,这里我们一起走进。

QQ大数据团队

CSDN:首先,请介绍一下您的团队?

聂晶:我们团队是社交网络事业群/社交网络运营部/数据中心/平台开发二组,前身是QQ成立之初后台3个基础团队之一的QQ 运营组。目前团队成员10人,主要负责社交网络事业群的基础数据挖掘系统和产品应用系统的研发和运营。作为腾讯内部较早研究并使用Hadoop的团队,结 合Hadoop、Spark等开源系统,推出面向应用的数据解决方案ADs(Aggregate Data services),涵盖数据整个生命周期;曾经面向复杂关系链计算,研发出圈子分布式计算系统等。目前,兴趣在于面向计算的分布式快速应用开发部署系统 ——R2,以及数据可视化的应用。

CSDN:贵团队是ADs的作者,可否为我们介绍一下当下ADs在腾讯的使用程度,比如支撑的业务,处理的数据集,集群规模等。

聂晶:ADs是腾讯即时通信线通用的,负责数据收集、分发的基础设施。ADs是一系列组件的统称,这些组件绝大多数为自主研 发,可以灵活组合起来支持实时和离线的多种数据需求。目前,ADs集群共700台各型服务器,日处理数据在2300亿左右,存储数据10PB+。为腾讯内 部5个部门,20多个业务线提供有效的支撑,比如数据查询、数据分析、产品统计、数据挖掘和用户推荐等。像QQ,手机QQ,以及其他通过即时通信工具接入 的业务,其基础数据都经由ADs对外提供服务。

图一 ADs架构图

CSDN:众所周知,扩展性是大型网络架构中必不可少的一环,请结合腾讯的实践经验做一些node rebalance相关分享?

聂晶:扩展性,在我们看来,包含两种含义:第一种是功能的扩展性,还有一种是整个系统吞吐的扩展性。

对于功能的扩展,从系统层面上,可以做的是根据系统承载的功能,抽象成不同组件,不同组件之间的结合,可以灵活扩展出面对新场景的功能。比如,ADs就抽象出接入自动解析的GAS(General Analyses Service)组件,高吞吐存储的COW组件,数据转换的DataT组件。GAS+COW就能提供应用的数据获取服务;GAS+DataT提供给离线模型计算使用。

对于整个系统的吞吐扩展,一般都会设计成去中心化的结构,每个节点提供对等的服务能力。比如GAS就是如此,每个机器负责的是对等 的服务能力,如果机器死机或者阔扩容,通过配置中心更新节点路由,保证服务一致,加上一些消息探测的机制,即使在某些极端情况下没有更新路由,也不会丢失 消息。

CSDN:在线处理环节,你们自主研发了R2,可否分享一下与当下流行计算框架Spark及Storm的对比?

聂晶:首先,R2 跟已有开源项目最大的不同在于它从一开始就是为了面向实时服务而设计的,所以它对性能和低延迟和系统可用性要求更强,比如,在推荐好友业务中,需要在 200ms内返回数据,但是涉及处理的数据却可能高达几百MB,怎样提升计算降低延时,是一个挑战。其次,从架构上看,R2是一个对称的结构,没有单点。 节点可以做到即插即用,扩容缩容不影响服务,这对存在一定资源空闲的大型机房来说,可以随时使用空闲资源,节省成本。再次,从功能上讲,R2对一些特定的 迭代计算做了大量优化,使得很多智能算法的实现变得简单高效。

CSDN:在ADs中,你们使用Hadoop做离线处理,那么如此规模下,主要的挑战是什么,会遇到哪些坑,及需要避免的地方?

聂晶:

1. 目前前主要使用的还是1.0版本,由于1.0版本的单点问题,如果主控机器死机,对业务会造成较大的影响。

2. 对模型计算,涉及到大数据的频繁读写计算,效率着实不高。所以,对于此类业务,我们在逐步迁移到spark。

3. 多用户同时使用集群,千万要根据业务特性使用不同的调度器。

4. 在Hadoop自身文档还不够完善时,有些细节千万不能想当然,需要多试试。比如配置机器host时,hostname不能带下划线。

5. 千万不要让集群节点的磁盘容量差异太大,否则在大数据写入并且集群使用率较大时,容易出现写失败等问题。

CSDN:在海量数据存储的过程中,在读写上是否遇到哪些问题?有没有调整系统默认的I/O调度策略或者是自己重写相应的文件系统?我说的是和Ext3/Ext2一个级别的文件系统。

聂晶:默认机器一般是对硬盘做RAID5,但是RAID5相对于RAID0,写性能也是比较差,而且比较浪费空间 (Hadoop自己对数据有容灾),我们使用的磁盘都是RAID0。不同的调度器对性能影响很大,通过测试使用比较适合业务的调度器,SSD和机械硬盘的 差距就比较大,分别使用不同的调度策略。Ext3不同的日志级别对性能影响很大,建议关键业务进行性能测试,使用适合业务本身的日志级别。这里只是使用比 较成熟的调度策略,自己没有进行重写。

CSDN:贵团队自主研发了数据解析服务GAS,可否为大家介绍一下主要特性?据悉即将开源? 

聂晶:GAS是一个通用的、实时的高性能数据解析框架,支持把不同格式的数据源,自动转换成一种格式,为后续组件提供无差别的流式数据服务。目前,GAS支持二进制协议、ProtoBuf协议、Json协议的解析。GAS的主要特点有:

  • 吞吐量大,单机峰值可到10w+/s,可充分利用机器资源
  • 提供通用的接口,方便扩展其他不同类型的协议
  • 单个数据格式修改方便,实时修改,实时生效

GAS目前已经在公司内部开源,目前正积极准备对外开源的有关事项。

CSDN:说到开源,可否透露一下腾讯当下使用的开源技术?都在系统中扮演着什么样的角色?顺便给大家谈谈使用开源技术的经验吧。

聂晶:在两种情况下我们会使用开源技术:第一种情况,在较简单非关键的应用中有使用开源的技术,比如thrift, 我们在数据查询等一些小系统中有使用,开源技术的优点显而易见,可以节约开发成本,很容易的可以实现简单的需求。第二种情况,一些绕不过去的,比较成熟 的,会使用开源系统,比如Hadoop,Zookeeper。我们系统中,底层和关键模块都是自己开发,做到完全可控。

开源技术良莠不齐,一些冷门的或者不成熟的最好不碰。即使是成熟的开源技术,在使用中也是有各种坑。不过,成熟或者热门的技术,好处在于可以利用各种网络资源,也有成熟的社区,你遇到的问题,大部分别人也遇到过,容易解决。

CSDN:无缝体验一直是服务交付中重要的一环,对于消除中间人,让实际使用者拥有一个更好的体验贵团队做了哪些努力?

图二 数据接入图

聂晶:ADs可以拿出说说。原来我们接入一个数据需要产品、开发、数据管理员多次沟通、多次联调以及多次数据质量确 认,才可以完成一个数据的接入,效率极低。ADs出现之后,减少了数据管理员环节。产品通过ADs去管理、验收数据;开发根据产品的提单开发、自助测试, 确认数据质量,知会产品验收数据。

ADs系列之通用数据解析服务GAS(即将开源)

面对成百上千的生产系统用户操作数据接入落地,你是否厌倦了每次机械编写打包解包代码?在一次性接入多个数据时,还要对不同人联 调,费时费力,你是否还会手忙脚乱,忙中不断出错?是否当数据出问题了,用的时候才发现,数据已经损失大半,产品/领导压力巨大,费一天劲才能定位问题, 关键是下次还是不能实时发现,快速定位。

怎么办?GAS(通用解析服务)就是为了解决上述问题,结合即通多年数据方案实践,提出的一个数据接入的组件。一杯清茶,轻点鼠标,轻松面对大批数据接入问题。

GAS在ADs中的位置

图 1  ADs整体框架

GAS(General Analyses Service)通用数据解析服务,用协议描述语言(Protocol Description Language – PDL)去描述数据,动态解析数据,实时按规则去除脏数据,实时整理数据,实时告警(需结合网管系统monitor使用)。即可作为分布式,也可作为单机版使用。解析引擎是插件式的,针对不同的协议,只需要开发相应插件即可。

GAS实现原理

GAS的整体框架

图 2  GAS整体框架

GAS master负责数据服务描述文件的管理,所有数据服务描述文件的添加、修改都在GAS master管理。GAS框架的主要优点:

  • interface主要分发不同数据到不同GAS broker、分发相同数据到不同GAS broker、分发不同协议的数据到运行不同解析插件的broker,分发数据到不同的对外应用,interface只是一个逻辑层。
  • GAS slaves分成不同的broker,每个broker接收不同的数据,或者一个数据可以在不同的broker接收多份,broker之间完全独立。分 broker可以分等级运营数据,方便运营,并且不同broker可以运行不同的解析插件,还可以减少路由表的下发包。
  • GAS slaves是去中心化的,GAS master死机只会影响服务描述文件的更新,不会影响已有数据的接收。
  • 数据之间是相互独立的,一个数据协议的错误,不会影响到其它数据。

GAS master

图 3  GAS Master框架

1. master机器上的配置模块,负责生成新数据的注册信息,可以登录ads.server.com,填写相关协议描述,就可以自动生成协议描述语言的配置文件。

图 4  服务描述配置页面

2. 检查配置文件模块,负责将新的配置读到内存,生成数据解析状态机,以检查是否能正常生成,可以测试协议是否正确。

图 5  协议抓包实时调试页面

3. 将正确的数据注册信息更新在测试环境,如果用户确认正确,那么我们可以一键发布到正式环境。

4. slaves每分钟访问一次master,检查是否有新的注册信息,如果有更新,则拉取服务描述文件到本地。

GAS Slave

图 6  GAS Slave框架

slave服务器主要分为两部分:agent进程和数据处理进程,两个模块主要通过共享内存head_mem进行交互,详情如下:

  1. agent进程负责每分钟检查一次配置文件是否有更新,如果有更新,则拉取新的服务描述文件到本地磁盘,将更新信息写入共享内存head_mem中,然后修改共享内存中head_mem的版本号。
  2. 先说明一下,我们每个数据都有一个唯一的标识,我们称为topic_id。每个数据的组包格式必须是Stx+topic_id+stBody+Etx,stBody是用户信息。这样我们收到一个包,就可以判断这个包是那个数据。

服务描述文件大致可分为3部分:基础信息配置,解析字段配置,导入信息配置。基础信息配置中包括日志相关、本地ip、端口、项目负 责人等一些全局的配置信息。解析字段配置是收到一个包后,按什么顺序解析、以及按什么格式解析字段。由import_opt_name配置项关联导入信息 配置。当在解析过程中,遇到某个字段有import_opt_name配置项时,触发该配置项对应的写共享内存操作。

数据处理主要做以下两个工作:

  • 每次接收数据后都检查head_mem中的版本号是否与已知版本号相同,如果版本号不同,则可以判断是那个 topic_id的服务描述文件更新了,如果这个topic_id的服务描述文件是新增,那么根据该topic_id服务描述文件生成对应的数据解析状态 机。如果是修改,则根据该topic_id配置文件生成对应的数据解析状态机。加载成功,那么释放该topic_id对应的原有数据解析状态机。
  • 收到一个数据包,根据topic_id判断调用哪个数据解析状态机,解析生成结构化数据,然后调用COW的接口进行存储。

状态机生成和数据解析实例

一个数据的协议为 Stx+topic_id+dwIP+cFlag+wCount+stUin+Etx;stUin=ddwUin+dwID。wCount是stUin的 大小,stUin为一个UIN、ID的结构体,假设wCount=2,那么stUin包含ddwUin1、dwID1和ddwUin2、dwID2。解析 字段列表为dwIP(short)、cFlag(char)、stUin(数组),stUin后面是导出字段列表dwIP、cFlag、ddwUin、 dwID。

Stx、Etx是协议的开始、结束标志,topic_id是协议的唯一标识。

状态机生成过程

图 7 状态机生成过程

状态机生成的过程是:(1)读取服务描述文件,动态生成Config对象,根据服务描述文件中的基础信息配置,填充Config的 属性,包括Socket属性。(2)根据服务描述文件中的解析字段配置,动态生成Socket中Field列表IP对象、Flag对象、Count对象、 stUin对象;stUin对象依赖Count对象,包含Uin对象、ID对象。(3)根据stUin对象后的import配置,生成stUin对象的 Import列表信息。

数据解析过程

数据解析过程与状态机生成过程类似,通过topic_id找到对应的Config对象;然后根据IP对象解析出IP的值,根据 Flag对象解析出Flag的值,根据Count对象解析出Count的值为2,根据stUin对象,stUin对象包含Uin对象、ID对象,那么解析 出Uin的值、ID的值。stUin对象有import列表,重新组包IP、Flag、Uin、ID的值写出。因为Count为2,再解析出Uin、ID 的值,重新组包IP、Flag、Uin、ID的值写出。数据解析状态机是预先生成的,不是动态生成的,这样可以提高数据解析性能。

性能测试

使用部门平均包长度进行测试,测试结果如表1。

表 1 协议解析性能测试

机器类型

cpu 70%解包量

最大解包量

B1老机器(Intel(R) Xeon(R) CPU E5405  @ 2.00GHz cache size: 6144 KB 4核)

8w/s

14w/s

C1新机器(Cpu:Intel(R) Xeon(R) CPU  X3440  @ 2.53GHz cache size : 8192 KB 8核)

18w/s

30w/s

展望

从上面介绍,我们还有一些工作需要做:protobuf协议插件,已经在测试中;txt协议插件,正在开发中;增强协议修改前后的兼容性。

博文链接: ADs系列之通用数据解析服务GAS(即将开源)



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [qq 大数据 团队] 推荐:

专访QQ大数据团队,谈分布式计算系统开发

- - 互联网 - ITeye博客
NoSQL是笔者最早接触大数据领域的相关知识,因此在大家都在畅谈Hadoop、Spark时,笔者仍然保留着NoSQL博文的阅读习惯. 在偶尔阅读一篇Redis博文过程中,笔者发现了. jacksu的个人博客,并在其中发现了大量的分布式系统操作经验,从而通过他的引荐了解了QQ成立之初后台3个基础团队之一的QQ运营组,这里我们一起走进.

爬取QQ空间3000万用户,玩玩大数据分析

- - FreeBuf.COM | 关注黑客与极客
这是我近期使用C#写的一个QQ空间蜘蛛网爬虫程序. 程序断断续续的运行了两周,目前总共爬了3000万QQ数据,其中有300万包含用户(QQ号,昵称,空间名称,头像,最新一条说说内容,最新说说的发表时间,空间简介,性别,生日,所在省份,城市)的详细数据. 目前已经爬到我的第7圈好友(depth=7)共3000万数据.

为什么腾讯 QQ 的大数据平台选择了这款数据库?

- - IT瘾-tuicool
来源:大数据DT(ID:hzdashuju). 00 为什么QQ要选择InfluxDB. 从2016年起,笔者在腾讯公司负责QQ后台的海量服务分布式组件的架构设计和研发工作,如微服务开发框架、名字路由、名字服务、配置中心等,做了大量分布式架构、高性能架构、海量服务、过载保护、柔性可用、负载均衡、容灾、水平扩展等方面的工作,以公共组件的形式支撑来自QQ后台和其他BG海量服务的海量流量.

腾讯做了个新的聊天应用TIM:在QQ上“动刀”的团队协作软件

- - 博客园_新闻
不知道你的公司现在还用不用企业微信,从今年 3 月份起,还未正式发布的它就广受关注,微信想以此试水企业服务市场,媒体想搞个大新闻,大家也想在生活和工作夹杂的、铺天盖地的微信消息中喘口气. 不过,至少从我自己的使用经历来看,企业微信没能实现任何一个目标. 它没有帮我们把工作和生活分开,就像我们自己本身就做不到一样.

成功大数据团队的“三驾马车”

- - IT经理网
对于那些着手尝试大数据应用的企业来说,成败的关键是组建一个优秀的大数据团队,但是不要指望一个“ 首席数据官(CDO)”或者数据科学家搞定所有的事情,成功的大数据团队需要三驾马车:一位业务分析师、一位机器学习专家和一位数据工程师. 随着大数据企业应用的火热开展,数据科学家正在闹人才荒,可谓一将难求,但是Lithium公司的首席科学家Michael Wu博士在接受IW 采访时表示:数据科学家的人才荒是因为人们对数据科学家的期望值过高,希望他即懂业务也懂最先进的大数据技术,这样的人才自然是奇货可居,而且不是每个企业有钱就能招募到的.

打造顶级大数据团队的几个偏方

- - IT经理网
出人意料的是,音乐人才、物理学家和工商管理人士能为大数据团队带来全新的视角. 你的企业正在打造数据科学团队吗. 首先,你应当从业务部门抽调专家来提出正确的问题. 然后考虑招募一些物理学家、音乐人才,当然,还有统计人才和计算机科学家. 这些才是顶级大数据团队的关键“配方”,至少管理咨询与技术顾问公司Booz Allen的战略创新部门副总裁乔什沙利文是这么认为的.

大数据团队必须设置的五种职位

- - CSDN博客云计算推荐文章
大数据团队必须设置的五种职位. 作者:chszs,转载需注明. 博客主页: http://blog.csdn.net/chszs. 麦肯锡认为,大数据团队必须有五种职位:. 1)数据卫生员(Data Hygienists) - 这些人,确保数据总是干净的、准确的. 2)数据探索者(Data Explorers) - 这些人在大数据项目找到你真正需要的数据.

唯品金融大数据团队的图数据库实践

- -
在大数据时代,社交关系趋于复杂化,越来越多的互联网项目都和社交关系联系起来. 而对社交关系的良好契合,使得图数据库(Graph Database)在互联网领域迅速崛起. 通过图数据库可以高效地进行社交关系查询、分析和数据挖掘,以发现有价值的信息. 近几年互联网金融发展火热,用户对消费分期、现金贷等需求也越来越高.

雅虎BigML团队开源大数据分布式深度学习框架TensorFlowOnSpark

- - IT瘾-tuicool
雅虎 Big ML 团队今日宣布开源 TensorFlowOnSpark,用于在大数据集群上进行分布式深度学习. 下面是该团队官方发布的开源说明. 近几年,深度学习发展的非常迅速. 在雅虎,我们发现,为了从海量数据中获得洞察力,需要部署分布式深度学习. 现有的深度学习框架常常要求为深度学习单独设定集群,迫使我们要为一个机器学习流程(见下图 1)创建多个程序.

QQ表情 for iPad

- 小趴 八足趴 八足 ramener - 腾讯CDC
  QQ HD for iPad 2.2已经发布了~其中全新的高清QQ表情也跟大家见面了.   在这里奉上新表情的安装包同时还有赠品哟亲~.   QQ HD for iPad 2.2 表情菜单效果图.   QQ表情for iPad.   表情安装包在附件中~希望大家喜欢~.   QQ HD for iPad 2.2 表情安装包 下载.