中国最具影响、规模最大的大数据领域盛会—— 2013中国大数据技术大会(Big Data Technology Conference，BDTC)于2013年12月5-6日在北京举行。数十家领军企业，近七十场主题演讲，不仅覆盖hadoop生态系统与流式计算，实时计算与NoSQL、NewSQL等技术方向，还对互联网、金融、电信、交通、医疗等创新案例，大数据资源的法律法规、大数据商业利用的政策管制等有深入讨论。
BDTC 2013中国大数据技术大会首日全体大会上，腾讯数据平台部助理总经理蒋杰发表了题为《大数据处理的规模化与实时化演进 》的演讲。他分享了大数据技术在腾讯的实践，其中包括基于Hadoop的平台TDW、实时数据收集系统TDBank以及基于Storm的流处理系统TRC。同时，蒋杰还透露，腾讯将在12月开源内部的Hadoop平台TDW。
以下为演讲实录：
蒋杰：谢谢张老师和CCF。我今天给大家做的报告是大数据平台规模化和实时化。这是腾讯一年内所做的总结给大家汇报一下。其实分为三部分内容：
腾讯里面大数据应用分为哪几类做了哪些事情。
技术相关平台化、规模化、实时化。我们主要建了三个平台，第一个平台基于Hadoop的数据仓库，第二平台腾讯数据银行，这是实时采集的平台。第三个也是今天上午第一位嘉宾所讲我们基于自己做改造实时的计算平台。
基于推荐系统一个架构的演进。
腾讯数据线就是这样的，这个图很容易概括腾讯所有的业务，和腾讯目前数据仓库承载的数据。腾讯是以QQ起家的，有八亿用户，四亿移动用户，加上腾讯网17亿的PB和手机端13亿的PB等。在数据仓库存储的数据量单机群数量达到4400台，总存储数据量经过我们压缩各种数据处理以后在100PB左右，这是80家当时的数据，每年日新增在200TB到300TB之间，每月增加10%的数据量。在这样一个数据体系下我们怎么应对我们的数据体系？这是我们面临很关键的问题。腾讯的数据分为很多种，国内互联网体系里面腾讯数据最全，比如说阿里和百度在搜索和电商拥有了所有的数据，阿里90%以上的电商都在他们那里有他们数据，百度有70%所有的市场份额拥有了搜索数据。电商和搜索腾讯都有，腾讯更多在社交领域，社交领域积累数据有文本、音频、还有视频和关系类的数据，这是我们主要的数据来源。这个数据当中我们有代表性就是社交图谱。我们有了QQ关系链、朋友网、微博、朋友圈加上QQ本身的关系链我们对用户梳理了一个比较深的用户社交图谱，目前我们对八亿QQ用户和4亿移动用户做了一个系统，可以做相关广告和服务业务。我们经典应用主要精准推荐。目前腾讯有广点通，还有腾果，腾讯两大效果广告平台都在我们这一套实时的推荐体系上承载的。目前承载200多亿的请求访问。腾讯视频以视频为代表的推荐服务，腾讯视频整个推荐服务也是在这套平台上，包括目前腾讯的电商还有腾讯的易讯网都在这个平台上，还有关系链、微博、腾讯秀各种APP，一些阅读和音乐在这套平台做精准的推荐服务。为什么做精准推荐？其实精准推荐能够给我们带来直接的效益。以前从雅虎开始是一个基于网页分类的广告的模式，到搜索引擎做了搜索广告，基本上现在都是基于社交个性化广告的引擎，基于Facebook为代表这样的。腾讯做的广告推荐我们用的热度协同过滤等包括我们后来改的基于LR的算法等，这些算法我们是混合算法模式不是单一的，这个过程当中我们为什么达到这么高的精度？我们把更多数据变成实时行为的模式，去做一些策略。同时我们基于历史数据和社交关系链数据等进行提取，提取出来一个比较全的画像，基于混合式的算法我们才会对各种推荐类服务给予各种支持。
我们做了用户的信誉体系，基于用户属性，电商行为，财付通支付的行为，还有虚拟Q币体系，在Q币体系有一些对虚拟购买行为做了积累，这个积累之上做一些信用体系，我们可以做一些信用支付和信用支持这是一个应用。数据更多做可视化，我们用强大的数据平台刚刚中国移动同时也在讲实时的监控，我们用实时的体系做实时的监控。同样我们对微信全球整个的实时的这种CGI的接口做了监控可视化的平台，190多个国家，哪个国家网络出现问题，调运接口出现问题都可以在这个平台实时做很好的体现。这是整个我们目前做数据应用典型的几个案例给大家简单介绍一下。
接下来我们对三T平台的介绍。我相信这一个体系其实每家在做可能有BIT的三大公司，大家都有可能做的方式有一些不同，我来介绍一下整个腾讯数据的服务体系。
这是我们整体的架构图，通过实时采集和分发，我们同时给Hadoop离线计算平台和在线计算平台，在这套平台我们承载精准推荐引擎和服务，提供整个社交广告和电商视频其他业务整个精准服务。当然也有传统的自主提取调度原数据管理的体系，承载这样的数据服务必须承载这样一个体系存在。我一个一个给大家介绍。
TDW，我们经历从400台机器到4400这样的飞跃，当时集群很多有16个以上，当时我们资源利用率不到30%，现在我们把所有集群合成一个大集群，最大是4400台，这个集群我们资源利用率提高90%，数据的孤岛，各个BG数据比集中起来了。不像原来一样我们每次要倒会员数据，跟QQ数据两边都倒这样的效率很低，一旦这样集中我们成本得到比较好的下降，我们下降50%整体的成本。这个过程当中我们其实经历了这么一个规模、存储量包括CPU、核数、内存，包括我们承载每天的呼叫100万以上，每天扫描在4个TB，集群到达了极限，我们所有方法都用上，包括压缩，包括修改，包括做HadoopLeip的模式，目前我们存储利用率达到83%，CPU利用率85%，网络利用率85%，这个数据看到我们要进到扩容的时代，我们单集群规模扩到8800台左右，为什么是4400？大家知道对Hadoop是一个原因，还有机房是最大问题。我们计划2015年达到2万台，可能在内蒙新建的机房实施，现在机房不能提供服务。4400台我们做了哪些核心的技术？具体技术细节我们还有一个同事明天会来讲，我主要讲讲几个核心的一点。我们做了一个Master容灾，做了Master分散化，不对Master做更改到3500台到4000台，你Master承载不了这么多台的规模。到了4000左右的时候你必须对Master做分散化否则你不能往上扩，扩到八千台，扩到两万台的时候，因为Master的机制造成的，所以我们修改公平调度的算法做资源合理的调度，也做了HadoopOER的事情，目前这个没有上线，有一些问题我们在解决。做了差异化的存储，我们有AEDO或者EP这种解决量的问题，对节点机型选择也做了一些工作，这一块依靠网络资源部做的。从2007年开始应该说从2008年开始真正做现在有五年多的时间。今年我们做了一个联包数据库的功能，也做了HBase实时查询的功能。每天已经超过1200个人，每天有550活跃在上面去做。这是我们整个成本的下降，我们原来成本每TB是233，去年大概是123，大概我们每TB做到65左右的这么一个成本。对互联网公司来说你规模一大，你的单位成本是我们面临的挑战，还有一个最关键的问题，像我们部门是支撑的部门，数据平台部是支撑的部门要把成本分摊给各个BG，各个BG对你的挑战，如果你成本很高，高于互联网公司和业界平均水平其实受到很大挑战，这个体系我们在成本方面做了比较大的努力。
这是明年我们会做这样一个体系，我们现在已经实施了，包括我们机房的搭建，一月份应该把它上上去，其实Hadoop本身已有的改造方面基本上已经没有问题了。我们主要做JITS统一样的管理，上面可以跑流式计算，图计算这样的模式等。我们明年主要的工作是灵活，我们要跑更多的并行计算框架也要更高效，当然也要降低成本，因为我们目前用的是腾讯自己的一个基于裂存储压缩的系统，没有用社区的，我们每年可能往社区靠做整个存储的结构。
明年我们目标成本再下降50%，这个其实还是非常大的压力。这个平台目前我们整个TDW的整个线上的版本随着腾讯的开源，腾讯开源做的不是特别好，这一次刚刚开源六个产品，我们是其中一个TDW作为一个Hadoop平台开源给大家，大家可以在上面用，我们可以持续维护腾讯自由的Hadoop版本，希望大家提供更多建议和意见。
第二块是实时化的TDBANK，腾讯业务基本上是全球部署，微信全球部署，国内也有上百个机房，还有CDN和POO点，每天有30万台的PC服务器在腾讯，我们要把服务器里面把数据及时的收集上来，我们每天有200TB的新增数据，要从全球更多的机房同步到深圳我们一个机房里面其实面临一个很大问题。当时我们面临一个问题就是延时大，入库压力也很大，原来我们各个BG报到一个集群，Hadoop去读，这时候前期没有问题这个做法，成本也很低。但是后来碰到很多这样问题，我们整个数据流通过程当中路程太长，经常丢包，数据核对不准确，还有跨机房的模式，通过桥头堡方式解决，设计很多模式成本也很高，现在实时数据需求过来的时候这个架构不能满足我们需求了，我们经历了这样一个过程，通过采集的模式防盗一个体系里面，我们给离线计算也给实时计算。这个过程当中我们解决几个问题，实时的问题从一天缩到一秒变成主动采集，我们解决用公网传输，原来全部用专线，每天十几个G专线成本也很高，现在我们基本上用了六七十G的公网传输，我们成本得到非常大的下降，我们除了非核心的数据基本上走公网加密传输。这个面临单机的故障造成数据的丢失，数据重传效率不高，后来我们基于分布式集群消息队列，基本上把整个消息队列，这个消息队列我们有几百台机器做，解决容灾和数据缓冲的问题，所有消息过来在消息队列存10到15天，如果你机器出问题你可以恢复，比如说两条数据要做合并可以在这个里面做，一个表里面有20个字段，你需要一两个字段，这里面可以帮你排序筛选这个可以解决。我们可用率得到比较好的提升从2个九到4个九的提升，这是我们体系架构。我们有一个采集过来通过接口网络适配过程放到一个消息队列里面，这里面把集成过来，我们分发到两个平台，实时和在线的平台上，这样解决我们实时和在线数据需求的问题。因为Storm的集群单集群过了三百台以后是支撑不了的，如果你没有做资源管理和资源隔离，一个业务出现故障其他业务就会发生瓶颈，所以我们用Yarn管理Storm的体系。我们实时数据条数超过两百亿条基本上是零误差的现状。
我们基于实时化到TRC平台，我们基于Storm的平台做一些改造和提炼，社交、游戏、营销这几块用到实时在线服务的平台。TRC其实我们有三个模块，第一个模块是基于流式计算的，这块我们基本上基于Storm做一个流式计算的引擎，在整个Storm流转过程当中你要落地，对整个进行存储做了一个数据库，我们参考淘宝来做的，我们把两个融入一下做了一个适合自己平台的平台。在这个体系中我们去支撑一个秒级延时基于流式计算的引擎，这个引擎我们除了本身Storm改造你更多需要做配置和任务管理的模块。我们分位几个模块一个是TDP、一个TPE。集群统一的管理和资源的隔离和权限的控制这是Storm本身不具有的，同时我们丰富很多开发的接口，这个过程当中我们做到良好平滑扩容和容灾切换能力。这个过程当中我们把几个平台分为几个模式。第一个平台层基于任务的调度和资源的管理。我们原有是java开发做接口，在这里和阿里走的路线是一样的，就是为了降低开发人员整个开发成本和调试成本。
这个上面是我们自己特有的产品，我们包装应用服务层，我们实时的服务可以在这里面定制化出来。同时我们上面做了一些监控的模式，这是我们在Storm上面做了一个演进的过程，希望给在座大家有一个启发和帮助。
这是我们用Yarn做整个资源调度和管理，我们主要解决资源管理和资源隔绝的问题，我们把Storm容灾机制交给Yarn管理，我们对地层CPU和内存资源扩容打下比较好的基础。因为成本不一样，应用场景不一样，我们存储引擎是一套，但是存储的介质和结构不一样，其他大家都见过比如说路由管理迁移怎么做备份，很多互联网公司有类似的这些东西，不多讲了，这是我们对整个NDB、RDB、TDE的支持。
这个主要是我们支持精准推荐业务和秒级监控包括微信的监控，每天我们请求量比较厉害的，大概我们TBE请求量是5200亿，TDE在2万6千亿左右，目前单集群数量不够大，明年我们主要在扩容量方面。这是我们三大平台的介绍。
最后我们介绍一下我们推荐，我们推荐其实分为几种。上面这几种推荐都是基于这套平台来做的。我们最老的模式我们有一个海纳，现在替换到放到我们分布式里面做实时查询，这是早期的互联网公司都是这样做的，基于离线模型算好，算好以后做实时查询，我们新架构不是这样做的，是2012年到2013年的架构，通过实时采集，到实时计算，到实时引擎，这是秒级的架构图。我们从一小时的实时计算提升到15分钟，我们CPI提升了42%，再到15分钟提升到秒级我们又提升了12%，这是我们提升架构速度改变一切，包括速度改变我们整个收入的过程。我们管理通如果提升10%就是三个亿的收入，这块非常值得提升。包括谷歌和百度在这一块他们也是一样看到了效果，我只是今天把效果给大家列出来。刚才说是我们第二代架构，我们第三代架构跟谷歌差不多我们把算法和模型用Spark计算完之后，我们数据和模型在同一起提供对外的服务。我们CPI提升10%的过程。把算法和模型结合一起，Spark每分钟或者更短时间运算一次。三亿流量请求，我们每秒钟投出的广告在几千万个，大概每个请求业务给我们时间只有50毫秒。这样过程当中我们推荐引擎经历了20亿次每秒的访问速度，这是运行的情况。
