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的体系。我们实时数据条数超过两百亿条基本上是零误差的现状。
