2016年4月23日下午，华为开发者社区携手51CTO在魔都上海启动了“华为开发者汇”的第一场沙龙。本次活动共邀请了华为公司、星网信通、优酷土豆的五位讲师做了分享。其中，来自优酷土豆大数据平台的高级架构师杨大海分享了他在优土所经历的大数据平台发展历程。里面从前后端的技术选型一直讲到自己遇到的Hadoop问题和挑战。让大家领略到大型视频网站在数据处理方面的不易之处，相信大家在看到杨老师填过的坑之后，能少走很多弯路。
现场实录如下：
杨大海：感谢大家。我先介绍一下我今天分享的内容。因为我这个团队是从12年开始去做，经过将近五年的时间，从零开始，做到支撑整个集团的数据平台团队。我目前为止还是在优酷，现在的话给我们一个合作伙伴，然后独立出来一家公司，现在还没有开始推广，也是一家做大数据的公司，包括数据平台、用户精准运营、网站流量运营这一块的东西，算是一个硬广吧。然后这一块，我拿PPT，就是上周在背景之上，51CTO一次的技术论坛，我给他们分享的模板，但是内容是重新又开始做的。
我先介绍一下我们这个团队的情况。我们是一个做技术平台的团队，因为前面两位老师已经介绍过，第一是搭建了这么一套内部的类似于github的管理平台。庄老师也介绍了一些软件管理、软件开发的一些系统管理方面的经验。我这边就是一个实现，就是非常苦逼的一个实现。我们这个团队主要支撑的是，整个优酷、土豆视频的日志收集。这个日志包括网站前端所有的点击日志，就是你点了哪些按纽，浏览了哪些页面。另外一些是视频播放，你看了什么视频，看了多长时间，什么时间开始看的，然后在什么时间点了拖拽，快进了，还是又拖回来了，然后什么节点的广告等等，就是所有的行为日志，大概每天30个T左右。然后现在的集群规模，现在做了存储，整个集群现在也做了一千多台了。整个存储一千多台的机器，整个存储扩到38T，现在用到的存储将近30个T，其实使用率还是蛮高的。另外支撑服务，第一是日志收集的服务，需要把网站这么多的日志收集过来，第二这些日志需要很快的存储到不同平台上去。第一个，就是我刚才说的(02：40英语)平台，需要把这些日志给存上去。另外有一些我们有实时计算的东西，所以需要类似于卡夫卡的消息队列里面。然后计算模型的话，这一块是指我们会基于(02：55英语)等等这些开源的系统，在它上面搭建一些平台和一些管理系统运营，来支撑其他团队的业务开发。
我先介绍一下这个前提，因为当一个业务团队去开发一个业务系统的时候，你不能要求他，你这边团队需要一个懂hadoop的人去搭建一套hadoop平台。再需要一些懂缓存的人，搭建一套缓存系统，当然这个在这样的公司，是不现实的，在团队内部也是不现实的，所以才有我们这个团队出现。然后我们提供了一堆平台，然后你们用的话，就是在我们内部系统里面申请一个账号接入，然后申请直接去用就好了，服务器什么都不用管。缓存就是我们自己搭建的一套缓存系统，每天就是支持的QPS将近两千亿左右。队列的话，也是基于开源卡夫卡去做的。监控的话，刚开始我们自己开发了一个名字叫天眼镜(音)的监控系统，可以接入所有这些分布式平台的监控，包括业务监控、流量监控等等，但是后来做着发现，我们做了一件和外面一个开源的系统非常像的一件东西，所以我们现在又重建搭了一套。现在支撑的业务系统，有广告系统、推荐系统，来疯就是我们现在优酷的直播，类似于六间房的直播。移动就是我们APP的业务，openApi前面智勇提到过，其实就是公司对外的一个数据接口的平台，其实量还蛮大的。然后云娱乐，就是优酷最近做的广告盒子，游戏导流这块的业务。其实我们这个平台，基本上支撑了，优酷80%以上的团队。
其实现在我来分享的目的是，告诉大家我们组建这么一个团队，把这个经验分享给大家，因为我自己独立出来做这个数据公司的时候，因为我现在还没有完全离职。到下一周的周五，可能是我工作的最后一天。刚刚华为的两位老师已经说了，他们可能是仅代表的是个人观点，然后星网的这位哥们说了，他代表的是公司观点，如果我讲的对的话，可以代表公司的观点，如果讲的不对的话，仅代表个人观点。然后这个问题是因为，我自己做公司的时候发现之前有过一些培训机构，包括51CTO、(05：34英语)等一些做大数据的开源社区里面，有一些合作，他们这边会推荐我跟客户去解释一些问题，但是我发现客户一些问题是非常多的。因为他们从一个做传统企业的应用团队，突然间接了一些大数据的项目，需要做大数据的工作，然后发现第一就是技术储备不足。为什么说技术储备不足?我跟他讲过你要用hadoop，要用这些东西可以解决现在的问题，他告诉我这些东西我们都没玩过，突然你给我介绍这么十几套开源的系统进来，然后在后面完全是一个黑匣子，我不敢用。包括很大的企业，像中电普华开源下面的一家国企，挺大的一个企业，他们营销处的主任这么跟我说的，另外一个他接到项目以后，时间周期是非常有限的。他没有时间再去，从一个零都没有的团队，从研究这个技术到市场投入使用，是这么一个情况。
然后技术选型上面，现在基于大数据的技术越来越多了，这些技术也是非常杂乱，其实每个技术都有它自己的特点，但是我们拿了这个方案去和客户讲了的时候，客户会觉得，我之先就用一个java，或者用一个.net什么，就开发一套系统，顶多有一套数据库、缓存技术，但是你现在突然间告诉我，我用这么一堆的开源东西，我真不敢用。其实就是一个技术种类繁杂，他们在选择的时候，出现迷茫，就是说这个查询，我可以用ES去实现，也可以用(07：15英语)，也可以用HB实现，我深知可以用(07：14英语)实现，我怎么去选择的一个问题，其实每个技术都有它自己的特点，当然这里面不排除，比如说(07：23英语)都能干成同样的事情，但是你的团队更适用于哪些技术，你的团队哪些技术里面有特长，出了问题我们更好解决，这是一方面。另外一个就是适应场景。有的技术，大家用来解决相同的问题，但是有的技术架构比较艰难，用来解决数据量不是太大的问题。有些技术他搭建这么一套系统，他的系统本来设计也特别复杂，因为分布式系统越完善，他设计越复杂，因为他要为他分布式，包括为他的高可用、高并发来付出很大的精力去这些这块的东西，就造成他的系统非常复杂。所以在这一块，使用场景你是不是需要这么一套更复杂的系统?因为你的数据量非常大，其实就是根据我们不同的业务场景，不同的数据场景去来挑选的。
另外一块，就是服务的挑战。为什么说服务的挑战?就是说之前的话，比如说华为和移动做了一套(08：18英语)系统，上线之后现场需要运维在那儿运维着，大部分的开发就撤出来了，但是你上这么一套系统，给客户上了之后，这个hadoop的玩意儿，Stor指不定哪天挂了一个节点，或者你需要处理了，这些东西我们专业做服务运维的团队，不一定能去解决，甚至是需要开发，就是更专业的一些做开发的去解决这些问题。然后并不是说你重启一下就能解问题的。另外一个，就是我刚才提到的易控、简单，找最适合，最简单的方案。因为越复杂的话，出了问题之后其实坑是越大。
然后系统特征，基于大数据的系统特征，往往有一个，就是分布式，为什么我们一直在推广分布式?因为分布式可以横向拓展、纵向拓展。它的拓展能够满足你，数据量日益递增的需求，能满足你的吞吐量的需求，但是它做到分布式之后，这个系统在设计的时候，因为要满足分布式，满足你本身业务需求的情况下做了很多基于分布式这块的设计。因为它要跨多个虚拟机甚至多个服务器来做，甚至多个机房来做这件事情。假如说我举一个例子，本来这个系统在一个机房都能搞定的，你类似于阿力的ODPS，现在他们要跨多个机房，机房之间的带宽问题怎么解决等等，这 问题基于分布式的特性，需要去考虑的。
然后高吞吐量，因为这些系统往往一天需要处理多大的数据量，这样的一个系统，我们需要对它进行不断的优化。为什么呢?可能我们一套系统在一千台机器或者两千台机器上去搭建，如果我们提供10%的性能，我们可能剩了两百台服务器，这一点是非常乐观的。另外一点高可用，因为高可用的话，也就是说我平台越大，我的业务越多，那就需要保证我这个平台足够的稳定，如果这个平台出现某一天宕机或者有一个小时不可用，这个带来的问题是非常大的。其实在一个月前，美团的缓存系统，他用的是淘宝(10：33英语)缓存系统出现问题，整个持续恢复了一个过程，好好坏坏的过程，持续了将近一周，这个影响是非常大的。所以就需要做高可用，高可用这块，我们需要做多机房，多活等等的方案，这里面我对系统的设计提高更高的要求，所以就导致分布式系统非常复杂。另外一个就是大规模。大规模的话，也就是说这个系统，可能去满足我们比如说整个网站等等这些非常大规模的业务，或者是数据这种需求。最后这个不稳定，我加了引号，并不是说这个系统不稳定，因为他加了这么多因素，这么多业务额外的工作在系统里面，就导致这个系统出现问题的可能性比较大。我举一个例子，如果你这个系统基于一台服务器去部署的，这个服务器很可能两年、三年，甚至五年、十年都不会宕机一次，但是如果你这个系统基于一万台服务器基于部署的话，可能这一万台服务器里面每天都会有十台、八台服务器去宕机重启的，这个不稳定需要我们不断的有人去完善它，去维护它，所以就造成需要我们使用这些技术的团队，去对这个技术更了解，然后做更多的跟踪，并不是说我们把系统给你部署，就OK了，这么一个工作。当然现在有一些自动化，我们也想尽办法去做一些，把人脱离出来，交给我们系统去干的一件事情，但其实这一部分还是没法往前脱离的。
然后我这边觉得这么一个做大数据开发的团队，需要这么几点特质：第一点，就是经验、前辈。我说经验、前辈并不是说我花五十万的年薪，去其他公司招一个大牛过来，这个对于很多公司来说眼前不能很快的实现，也不是这个意思。我的意思是，我们在研究一门技术的时候，我们这个团队要引入这个技术，要使用这个技术的时候，是不是找一个人专门去研究它，这个人到两年系统上线之后，是不是能够成为这一方面技术的专家?然后推进我们其他团队去使用。其实这也是就是一个专业、专注的问题。我们团队并不大，我们支撑整个公司的数据平台也就七八个人。比如说缓存出了问题，我知道这个人能解决，OK，我找他。然后，我们平台出了问题，我说这个人能解决，我找他。每个人都有自己的特长，然后能非常快速的解决问题。学习能力我指的，因为社区迭代非常快的，社区基于大数据是非常快的，有很多新数据出来，并不是说老的技术不用了，但是这些新的技术可能在一定程度上，可以替代我们老的技术，或者说是它的性能各方面会更好，我们花一定的，在团队里面抽出来一部分精力，去尝试，去解决这个，就是说一些更好的技术方案，引进一些更好的技术方案进来。另外就是思考，就是我们做一个阶段之后，我们思考一下这个阶段得到了什么，如果觉得我们是有问题的，或者说我们迭代比较慢的话，是不是我们的方向不对等等。然后责任心，因为我觉得做大数据的是比较苦逼的，特别苦逼，苦逼到什么程度。晚上可能告诉你一个数据有问题，然后你出来需要解决。另外一点责任心的话，因为基于大数据，大家都知道这里面有一个非常不好的问题，我们的数据来自互联网，互联网上的数据是非常乱的，因为我们对外的协议大部分都是(14：12英语)谁都可以给你发，给你发什么内容都可以，现在反作弊我们也在做。责任心就是说，很可能因为某一个程序的问题，或者你程序写的不好的问题，造成(14：26英语)任务有问题等等，你需要起来去处理，而不是说我把这个任务挂上之后，我再也不管了，这个其实是特别重要的，就是团队里面成员的责任心。然后沟通、分享和影响，这块的话，我这个人我对这块技术研究OK了，我觉得可以用了，我把这个平台给搭建起来了，我去推广了，然后我是不是在内部进行一些公开会议，去推广一下?教大家怎么去使用这个东西。因为推广并不是说，让大家知道我们的东西，你让大家知道的，大家都知道，但是大家都不知道怎么去用，也不行。就是我们需要举行一些内部分享的机制。告诉其他团队，用了我这个东西有什么好处，然后怎么去使用我这个东西，最重要的是怎么去使用，能给你带来好处，这样的话对这个平台推广有非常大的好处。
技术挑战，我觉得就是这几个方面，因为对于一个传统的小团队做项目的团队来说，因为我这边也在优酷面试过很多人。你问他，多线程了解吗?了解。你问他虚拟机了解吗?了解，但是你解决过这一方面的问题吗?没有，这种人非常多，但是你去做大数据的技术，你必须去解决这些问题，你做一个平台之前这些问题每天是有的，你必须解决这些问题。因为你做一个面向全公司或者是全集团的一个平台，然后你这些问题，第一他们本来的数据量就很大，所以你遇见这些问题的概率是非常大的，你不知道他们什么业务，都在你这个平台上去跑，甚至更令人恐怖的，之前我们平台初期不完善，我见过一个人写过一个(16：16英语)语句，一个java信息占了一百个G的内存，这一方面需要我们自己更专业的人去做管理、去做处理。服务器底层的原理，我们既然去做平台，我们需要快速派发一些问题，我们需要做压力测试，我们在做压力测试的时候，究竟是为什么?是什么原因导致我们的吞吐量上不去，程序的性能不好?这需要我们去对服务器的底层原理去做一些理解。比如说我这个人本来只会java，那OK，现在问题解决不了，我现在这个人懂操作系统，现在CPU使用百分之百了，或者CPU使用90%，或者IO非常高等等这些问题，就需要团队去融入其他一些技术进来。另外就是数据除噪，其实刚才有提到，我们的数据是面向互联网的，谁都可以发任何的数据给我们，其实对于ETR这块，每天都会收到日志里面。我们的日志当然不是直接存到数据库，当然日志里面每天都会大量收到大量的(17：22英语)注入到日记里面，这个非常多，虽然是非常低级的工具手段，但是每天都会有。所以这个数据除噪，第一面向web的攻击，另一方面是数据的质量。因为数据除噪做的好，做的不好，对你后面数据分析，包括数据挖掘的模型，最后的解决其实造成蛮大的影响。另外一个，就是我们庄老师又讲过，也有嘉宾提到过，我们用开源的时候遇到一些坑怎么办?其实这些坑蛮多的，特别多，有的坑甚至大到我们这个团队无法接受的，都有很多，都有遇见过。所以这些其实开源的bug，其实我觉得总结出来方案有两种。第一种是我们索性不解决，绕过去，等到下一个版本，他就解决了。另外一个，就是如果觉得我们可以接受的话，我们花一个人或者两个人在两周之内把这个bug给攻坚，给搞定，把这部分的源码给运维那边，然后把bug一搞定，原理解决，也是一种解决方式。
这块的痛点，主要是说现在对于好多，我接触过很多客户，很多做架构的，都告诉我，我现在需要一个十亿级或者二十亿级量的数据库，而且我需要支持多维查询。这么一个系统是有的，但是这么一个系统其实它基于好几套系统搭建起来的，并不是给你安装一个就可以这么干了，并不是去的。可能里面用到一些索引、缓存等等一些东西去做。甚至说，因为我们华为其实也是开源了一个基于(19：00英语)索引一个解决方案，其实代码也已经开源出来了，我们之前也有在用。这块根据以前的开源东西自己去实现一些东西，才能满足你的需求，并不是说直接开源拿来就能用。然后吞吐量这块，可能很多系统在上线初期支持每天几十万或者几百万、上千万的请求，但是上线之后也没问题，运行一年也没问题，突然间运行两年公司规模壮大了，因为优酷的日志量从之前的12年每天几百亿，到现在的每天上千亿，其实也是上升了一个指数级。这样有很多问题会在后面的数据量增长的过程当中暴露出来。实时的话，对于报表分析，我之前是我们国内另外一家做电信的公司，可能在座的下面有华为的同事的话，有的可能会了解雅信联创(音)，做商业BI的。之前BI方式基于数据仓库，直接在仓库上面建模，去做一些固定的报表分析出来就OK了。但是对于现在的互联网监测，一些数据也好，要看到实时的数据，对于报表的要求越来越高了，实时这块需要更多的技术去支持。每一种方案都有优缺点，选择自己最合适的方案。
然后我下面介绍一下我们公司内部的hadoop平台成长的一个过程，和它升级的case。在12年的时候，我刚进公司，这个时候公司已经有一个集群了，当时有30多台，我去了之后扩到了50台左右。当时这个集群是裸奔的，为什么叫裸奔呢?就是阿帕奇直接部署驾起来，跑起来，什么也没给，什么控制也没做，就是给我们一个推荐团队来用。我当时应聘的团队就是推荐团队，给他们在用，帮他们做这件事情。然后用着用着发现，别的团队需要我们推荐团队的数据，后来我们就自己思考了，其实我非常感谢我遇到了一个好的领导，就是我提前转正了。在他那边他是(21：26英语)，但是对于我来说，我已经是全力在干这件事情了，这件事情是很好的，就是他给了我尊严，让我去做这件事情，所以就是说我们当时有这么一个打算，就是说做一套全公司开放的平台出来，然后当时是在这个50台的基础上，推广其他团队去用，当时那几年团队还不多，就是四五个团队的时候，已经有很多团队在质疑了。就是说，假设我们的数据被别人删了怎么办?所以在13年时候，我们这个集群做到两百台规模的时候，我加入了权限控制等等，包括用户的目录规划、空间规划，因为你不能保证你的用户突然间存一个，今天存个1P的数据过来，我要对他的目录做配合，我要对他的数据权限做控制等等，这些控制，我在13年的时候全部做完了。这个时候，其实挺稳定，挺好了，看起来什么问题都没有，但是后来又发现问题了。在13到14年的时候，做了一次版本升级，因为在12年到13年的时候是1.0到1.3的版本，然后在13年的时候，因为发现1.0.3版本，社区里面很多东西无法支持了，类似于(22：42英语)等等，他们新版本升级的时候，对于hadoop老的版本不支持了，都直接二点几的版本了。所以这次做了一次升级，其实也有办法去解决，当时因为我觉得，直接升级，但其实也是低估了这个升级的代价是非常大的。然后升级当时升了2.3的版本，其实我们升级还有一个，我当时因为觉得使用团队的越来越多了，我们需要做高可用，所以在1.0.3的(23：10英语)存储的主节点还不支持HN的，然后升级2.3主要解决这个问题，但其实没有解决。因为升级2.3之后，我们的文件读写太频繁了，导致阿帕奇的版本2.3的一个bug，HN只有一次耗时，就是一个挂了这个可以切过去，挂了这个再也起不来了。当时其实是花了将近两周时间，把这个问题给解决了，然后也反馈到社区了，他们在2.4其实都已经修复了，他们其实当时打了一个快捷出来给我们，其实已经解决了。
在14年到15年的时候，从14年下半年到16年这段时间，公司的数据规模和团队是越来越多。当时13年底的时候，优酷全公司只有大概不到两千人，现在整个公司五六千人了，所以对于团队来说越来越多，业务来说越来越多，数据也是越来越多。整个数据涨了好几倍。你看这个集群到13年的时候是两百台，12年是五十台，其实也没增长多少，但是从14年年底到16年直接奔一千台去了，而且我们中间还做了很多删数据等等控制数据规模的一些控制用户存储数据规模，包括给他数据设定一些数据周期等等一些运营策略，还涨这么快。就是说这中间遇到了很多用户的问题。
下面一张PPT会介绍说整个数据平台在不同的生长阶段面临的问题。到现在为止，已经超过一千台了，每天将近有三四万作业在这个平台上运行，就是(24：54英语)等等这些作业在这个平台上运行。
问题演变，其实50台左右的时候，我们暴露了什么问题就是生态圈的完善。当时生态圈什么(25：04英语)全部涌出来了，但是这些问题其实本身也不完善，踩的坑比较多，bug比较多。当时我们团队技术功底还可以，但是你推荐给其他团队用，其他团队没有这方面的技术功底，所以他们需要去学习，需要引入这方面的人来解决这方面的问题。所以当时面临的问题是这样。但当时不存在集群管理的问题，因为使用特别少。主要问题是，这个人给我发一个(25：36英语)，我应该怎么写，你能不能告诉我，我觉得这个问题太简单了。所以当时主要是这种问题，到两百台的时候，就是权限控制，需要控制我的权限了，用户管理，就是说我需要有单独的账号，需要保证我的文件只有我自己能看到。然后资源管理，就是说我不能因为某一个人提交了一个非常大的任务，跑了一整个晚上，占了五百台服务器，导致其他团队任务没法跑，就是调度的问题，因为我们基于云去做这件事情，一千台机器在一个大池子里面，谁都可以占用这个资源，所以这个资源需要做一些更好的调度处理。
另外就是数据安全。数据安全特别重要，对于一些核心团队来说，比如说我们的广告团队，他们的团队是不允许任何的团队看到的，但是我们还需要帮他去做这件事情。
目录规范是指，如果你只给他做权限处理，你给他制定一些规范进去的话，这些用户乱放，最后你的GPS都不知道放的什么，整个文件数乱七八糟的，哪一些文件有用，哪一些没用，你怎么对用户的目录去做大小的控制，这些都没法去做了，所以用户规范也在这个时间点去做了。
然后参数规范，当时我们的hadoop集群没改什么参数，后来做了一些参数的优化。然后也做了一些自动化运维的工具进去了。等到一千台规模左右的时候，暴露的问题更高级了。用户水平都高了，他给你提的问题真的是问题，需要花一周甚至两周时间去解决。比如说用户(27：16英语)的bug，比如说我现在平台需要升级(27：18英语)版本，其实从1.6到1.7是有问题的，但是版本内存是没有问题的，但是这些问题真的是问题，需要解决。就是用户高级了，我们遇到的问题也高级了。
可用性要求更高了，不允许平台去管。你想我们网站每天那么多日志进来，那么多推荐系统，都从这个数据里面算数据，假如说这个平台挂了，然后第二天大家都不用干活了，直接就是在重跑你的任务就好了。小文件的问题，做这个hadoop的都知道，hadoop会把这个文件结构、目录结构等等块的信息，全部存在一个java进程里面，这个java进程不能无限大，我们现在这个java已经开到120G内存了。就是用到256G的内存，现在已经开到120G了，我们可想而知它触发一台(28：05英语)就是几分钟了。然后这个问题，我们现在有很多方式，也有很多运行策略，就是我们合并小文件，或者压缩文件，减少文件块等等这些方式去处理，但是其实现在在社区还是一个瓶颈，我觉得hadoop这个东西，可以允许你发展几百台的规模，但是你像阿里这种，上万台的规模还是需要自己去做很多改造的。因为阿里多机房，做多(28：33英语)这套方案。
这个问题另外一个就是数据迁移。这个数据迁移，我是指的有些系统可能用的(28：46英语)这个数据已经跑了很久了，在这个目录里面，但是突然间告诉他，我这个目录需要开放，但是这个目录里面另外一些数据不需要开放，所以就需要在这个目录规范上再做一些处理，去满足其他团队的数据需求。任务问题，就是任务越来越多了，一天三四道任务在上面运行，就像一个高速通道一样，然后一百个没问题、两百个车没问题，一天几万个车在上面运行，会出现堵的问题。但是堵你不能一直扩容，你扩容也解决不了堵的问题。因为不排除我们有一些专业的分析师，非常专业的分析师，不是非常专业的技术，但是他会写(29：26英语)，比如说直接查询一年、两年、三年的VA，你这个查询需求一天那么几十T的数据，一下查询好几年的数据，谁也没法控制你，所以我们还是要控制他。我也没法说直接扩容能办法你的需求，我只能说我控制你了，你跑的慢一点，你只能占50台机器跑，让你跑半个月，只要你跑出来就行了。这种需求，就是给任务划一个优先级。存储计划需要去做，我现在基本上一天30T的话，做三副本的话就是100T左右，100T的话，也就是将近一台服务器来做。一天需要扩容一台，一个月就是三十台，一个G就是一台。其实这个规模还蛮大，我需要去做一些存储规划，就是说多长时间的日志需要删除，究竟需要扩多少服务器出台。因为我们的运营团队也需要提前给他报备。
资源增强然后资源分类，就是说我刚才提到的，这个资源基于平台上面跑的任务越来越多了，然后大家相互争抢资源，他说我的优先级比较高，我说我的优先级比较高，我不能让你俩打架吧，但是我还得让你俩都跑，怎么办?我自己会对集群做一些管理系统，我让集群看出来，我让你们看出来，在哪个时段，我的集群比较显，你们可以很快的跑完，就是让用户自己选择时段。另外的话，任务的优先级不能用户自己设定了，让你自己设定已经不OK了，我需要有一些机制控制这件事情。假如说我给你们团队优先级任务高的，就100个资源，一百台机器让你们跑，同时你们占有100台机器，再多的话，需要你们内部自己协调了，这个太复杂了，我不能一直通过扩容来满足你的手段。服务器如果这么做的话，最后这个集群扩到一发不可收拾了。然后任务监控，现在用户发现我的任务报错了，现在日志是能看到，但是我要知道我为什么报错。比如说内存(31：32英语)的监控，这样的话刚开始我们监控，只是说这个节点挂了，这个服务器的内存用了多少，然后我们这边是有，但是用户要看到自己的任务，或者某一个(31：46英语)用的内存整个情况，没有的，所以我们之前开发的那套监控系统还在用着，但是现在又搭了一个(31：55英语)加了一个插件，在跑的过程中会采集一些(32：00英语)系统里面，给它展现。等等这些问题，到现在为止处理的差不多了，但是后面有一张PPT我会讲到，就是整个升级过程和面临的挑战。
整个平台升级，升级的必要性分为两部分：第一次升级是为了保养，其实可以不升的，但是升了，是为了保养。第二次升级，其实就是为了治病，不升不行了，面临了很多问题，需要去升级了，必须要升了。然后准备的话，准备这块调研、测试、包括修改、适应现在的环境等等这些问题都小，最主要的是你怎么让用户接受你这个升级。因为hadoop的升级，可能并不是想像的说我换一个新版本，把文件系统升级，就OK了。我们公司所有的(32：42英语)程序，里面有30%是需要修改的，它和API是不兼容的。所以我们考虑到两种方式，就是说我们尽最大的努力，让它做到兼容，我们去修改它一部分API，修改它一部分插件，让他做到兼容。另外一部分的话，真的需要修改程序了，所以这个需要给我们的团队去沟通。
方案的话，就是说制定升级方案，哪些系统先升级，哪些系统后升级，系统之间的依赖需要处理明白，究竟哪些系统，别遗漏了。因为当时最后一次升级，我们处理了大概有五六十个业务系统，你像我一次升级，牵扯到这么多系统需要改程序，现在想想其实也是一件挺好玩的事情。升级的过程中，我们做的还是比较谨慎的，整个文件树的结构，就(33：43英语)镜像文件，如果这个一丢，相当于整个公司的存储丢完，虽然说存储没丢，但是数据已经找不回来了，这个备份我们做了一级防备份，全做了，包括回滚的代码都已经写好了，脚本全部写好了，基本上可以避免所有的意外发生了。无非是宕机时间的问题，其实在升级当天晚上遇到的一些问题，还是比较突发性的问题。第一个问题是触发了操作系统(34：18英语)的一个bug，测试那天没有测出来的。另外一个问题是，升级时间我们把安装包，安装包将近有一个G，就GDK安装包，包括hadoop安装包，整个包将近一个T，从一台机器往下分发的时间，我算算这个带宽，分完之后需要分发两个小时。本来升级只需要40分钟都能搞定，分发包的过程需要两个小时。都是在之前没有考虑到的。然后再接下来，就是我们这个坐享成果了，升级完了，其实也没这么爽。升级完之后，一周的时间还是在解决测试时间没有测到的bug。那一周我们很苦逼，但是过了这一周，我们很爽了，集群再也没有出现过宕机了，高可用也OK了，我们省心多了，能睡着觉了。
然后这个集群面临的挑战，其实我觉得这个挑战，就是我刚刚提到一点Nmenode瓶颈，因为我们现在在做多机房方案了，一个机房现在在青岛那个机房，将近有一千五百台服务器，现在没有机架了，需要做多机房的方案了。另外一个日志系统，对于大小的控制，我需要满足Nmenode瓶内存的要求。集群规模大小，Nmenode瓶性能瓶颈，一直都是在围绕Nmenode瓶。因为它这个性能瓶颈，并不是说内存的瓶颈，就是说它对于HDF分布式的东西来说，它对于存储是分布式的，它对于计算是分布式的，但是对于我去找一个文件，这个文件下面有哪些文件，这个瓶颈是落在Nmenode瓶主节点上的，这个节点是管理总文件数的。所以我们查找的服务，类似于(36：04英语)的服务非常多，造成Nmenode性能瓶颈，它一个节点已经搞不定了，我现在已经用到40核的CPU，256G的内存了，他已经搞不定了怎么办?我还是需要想办法处理。另外就是议案的问题，议案调度还是不够个性化。因为我们现在跑到议案上面的任务，有(36：28英语)等等，我们还有开发一些自定义的应用，也是基于议案去做的。也就是跑在上面的任务这么复杂，我就需要一个更牛逼的系统去做。但是hadoop2.7支撑基于标签的调度，但是它这个东西一点都不完善，只有一个调度，它内置了三种调度器，只有一个调度器支持，其他两种调度器都不支持。而且他最支持的调度器是最原始的。因为资源调度器是非常傻的一个调度器。
资源隔离的话，这块我想说一下，因为我现在做的内存控制了，做到资源控制了，但是我没法完全做到资源控制。我说的这块就是虚拟化，可想而知大家这么一堆任务都跑在一千台服务器上。这一千台服务器，有一台服务商同时起到十个java进程，是属于十个用户的。我能分配你这个java只占两个G的内存，这是没有问题的，但是我没法保证你的java内存只能用一个CPU，如果不基于虚拟化去做的话。或者是(37：34英语)策略去做的话，我没法保证CPU的完全隔离，其实这个也是一个挑战，因为现在发现，你要做平台做到最后就是资源的问题，你怎么把这些资源控制好，怎么把这个平台的权限控制好，让用户更好的去用，就完了。
然后数据仓库的必要性。我想说一下我们集群为什么出现这么多任务阻塞的情况，就是大家都在争抢资源的情况?其实我们少一个数据仓库，没有一个非常牛逼的数据仓库团队来做数据仓库。也就是说我需要一个数据就拿，这个架构肯定是不OK的，所以我需要一个数据仓库。
更加强大的监控平台，就是说我需要监控到甚至说某一个任务，某一个用户，某一个任务的(38：14英语)的情况，对于磁盘读写的情况或者说他突然发现，我这个任务本来每天都半个小时都运行完，今天怎么走了两个小时，是不是让他发现他读文件的节点刚好出现(38：30英语)问题，需要这方面的支持。
另外客户端，我的打算是，因为现在我们团队有几十个，我们的客户端有几十个，每个团队有一个或者两个hadoop客户端，就是提交任务的机器，不运行任务，就是我只提交的机器就将近一百台了。然后我每次升级这个问题是非常头疼的，就是说有一部分客户端管理权限在我这儿，有一部分人客户自己装的，我只能汇总，但是肯定会有漏的，所以我现在基于(39：00英语)去做这种无状态的客户端工作，我就发一个(39：04英语)的镜像，升级的话你自己重新装就完了。
配置问题，我需要一套自动化运维的工具，因为不可能说这一千多台机器，每天还是写这么多脚本，我给一个(39：15英语)写个脚本下发，通过一个脚本直接拷到每台机器上，还是需要一些自动化运维的工具在里面，来帮助完成这件事情。业务依赖升级的问题，尽量想办法去，就是我们怎么尽量想办法去避免，因为你的系统升级造成业务也需要升级呢?
行，我的分享基本上就到这里，谢谢大家。
嘉宾：我想问一下，就是我们有一个数据库平台，转成hadoop平台的话，有没有可能?
杨大海：其实我觉得你单纯说一个数据库转化hadoop平台，因为它们在两个不同的战线上。基于hadoop平台上能够满足你某些数据查询的这些要求，比如说(40：09英语)等等可以满足你数据查询的需求，但是这个平台干的事情和你现在数据库，就是单纯hadoop来说干的事情和你数据库干的事情，是完全两码事，你数据库是满足一下业务需求的查询。比如说我点一下前端就要出来了，但是hadoop这个，我要写一些(40：29英语)语句两个小时算出结果的。
嘉宾：就是现在有很多产品，本身是(40：38英语)语句的一些产品，那么对这个支持?
杨大海：我帮华为宣传一下，其实华为基于(40：49英语)方案，而且在(40：55英语)社区里面基于(40：59英语)查询的一个东西，这些都可以去做(41：02)的多位查询。因为(41：02英语)本身是KV的查询，基于这些方案可以做多余的查询，而且满足你这个数据量的需求，因为(41：10英语)其实对存储的数据量是没有要求的，它只对并发吞吐量有要求，每秒钟是多少KOBS这种是有要求的，他能支撑到服务是有限的，但是你只要有足够大的硬盘，你有多大的数据，你都可以往里面写，这个对他性能是没什么影响的。
