|
他们前身是QQ成立之初后台3个基础团队之一的QQ运营组，当下致力于腾讯内部的分析系统，在离线及交互式计算系统上积累了大量经验，更是面向应用的数据解决方案ADs的作者。
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进行交互，详情如下：
- agent进程负责每分钟检查一次配置文件是否有更新，如果有更新，则拉取新的服务描述文件到本地磁盘，将更新信息写入共享内存head_mem中，然后修改共享内存中head_mem的版本号。
- 先说明一下，我们每个数据都有一个唯一的标识，我们称为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协议插件，正在开发中；增强协议修改前后的兼容性。
|
