大型开源分布式平台实践心得
大型开源分布式平台实践心得
最近几年,得益于国内网民红利,互联网公司发展迅速。互联网公司的用户数和公司市值越来越大,随之而来的是数据量急剧膨胀,很多国内互联网公司的数据规模都进入EB时代。在大数据概念越来越热的今天,为了最大程度地发挥数据价值,对数据的各种处理和挖掘需求也越来越多,这也促进了大型分布式存储和计算软件的快速发展,导致集群规模也越来越大。对于国内的BAT而言,大型分布式集群的总服务器规模都在几万到几十万之间,这在四五年前都是难以想象的。2006年左右的时候,如果听说某家公司服务器规模超过一万台,都觉得是个非常了不起的数字,现在回头来看,就觉得只是一个很小的数字了。
我是2010年入职360的,记得刚入职的时候,这边的基础平台还比较薄弱。至今还能清晰的记得2010年年底我们和许许多多的小公司一样,刚刚建立起了公司第一个6台服务器的Hadoop集群(2台主节点、4台存储服务器),规模小得可怜。但随着公司业务的快速发展,在不到4年的时间里,我们的Hadoop集群的总规模很快突破了10000台,单个最大集群规模也达到5000台左右,数据量也从TB级别增长到了目前接近EB的级别。无论是集群规模还是数据量都发生了翻天覆地的变化,而且发展速度越来越快,远远超过我们的预期,每次总结的时候都会发现实际数据规模远远超过之前的规划。
目前在360,除了Hadoop在公司的大规模发展外,同时根据不同业务的需求,我们在Cassandra、HBase等平台方面也逐步发力,集群规模也快速膨胀(Cassandra和HBase规模目前应该都是国内最大的)。在存储集群发展的同时,MapReduce、Storm、MPI机器学习等计算平台也同样在快速发展中,尤其是我们利用公司大量CPU较空闲的服务器搭建了一个超大实时计算集群,提供各种实时统计分析、搜索网页处理、安全样本分析等业务使用,大大提高了空闲服务器的使用效率,节省了公司大楼硬件采购支出。
从研究生期间,实验室研究方向是并行与分布式计算,毕业后在互联网公司一直从事分布式软件方面的开发和优化等工作,在经历了公司这几年在平台方面的大发展后,我遇到了问题,踩了很多坑,但最后都算有惊无险地解决了面临的调整。我总结了一下最近几年在大型分布式软件实践方面的几点心得,一方面是对自己工作的梳理,同时也希望能对业内负责同样工作的各位有一些参考价值。
开源还是自主开发,取决于企业诉求
在大型分布式软件方面,很多公司会面临使用开源软件还是自主从头开发两种选择。像国内的大型互联网公司BAT在使用开源软件的同时,也在并行地开发类似的平台,经常会有人问我这个问题,到底是用开源还是自主开发呢?
对于刚起步的创业公司或规模较小的公司而言,基本上是不可能投入大量的人和时间成本去开发这样大型的系统。因为对资源有限的公司而言,应该将有限的资源投入到公司最核心的业务开发或产品试错上,拥抱开源应该是最好的选择。
那对于有一定实力的大公司而言,是否就一定需要自主开发呢?个人认为从技术的角度或者从快速满足需求的角度,如果某个领域已经有相对比较成熟的开源软件了,那直接使用开源软件基本上就能满足公司需求了。有些不满足的地方,自己的技术人员也可以根据需要定制开发一些自己独特的功能来解决,大可不必浪费大量人力和时间成本去重复造轮子。站在巨人的肩膀上,当然要比从零开始快,同时风险系数也小很多。所以开源加定制是一个比较好的选择。
当然这只是从技术或实用的角度来看。有些公司可能会出于市场公关的角度或个人成就的角度选择自主开发,还有大家听得非常多的所谓自主可控等原因去投入大量人力自主开发,企业诉求不一样,选择也不一样,选择适合自己的最重要。
选型很重要,根据不同的需求选择不同的方案
在分布式存储方面,数据类型是多种多样的,有结构化数据,也有非结构化数据。有些数据由海量大文件组成,也有些数据由海量小文件组成……这就导致数据存储需求多种多样。同样在分布式计算方面,不用业务的计算需求也多种多样,有要求高实时性的计算,也有要求高吞吐的计算,有多轮迭代的计算,也有流式处理的计算……因此对计算平台的需求也是多种多样的。
如何选择适合业务需求的平台就变得非常重要了。在使用之初,一定要对即将使用的开源软件进行仔细研究和分析,主要是研究不同平台的优缺点及适合应用类型,然后为不同应用需求选择最适合的方案,例如HDFS这种架构的平台,不适合存大量小文件,因此存储海量小的业务(如小图片、小文档等)就非常不适合直接存储到HDFS上,相对而言采用HBase这样的方案就要好于HDFS。例如像M/R这样的计算平台不适合处理有大量迭代的计算任务(每次迭代数据都要写入HDFS并从HDFS读出来,效率很低),所以机器学习相关的计算就不是很适合在M/R平台上运行,采用数据都基于内存的计算平台就会比M/R平台更适合。曾经有公司用HDFS这种类似的系统存网络收藏夹这样的小文件,当文件个数很快超过1亿的时候,主节点的内存压力马上就出来了,差点造成事故。
目前360内部针对存储特点,考虑到在线业务对服务可靠性的高要求,在线业务存储平台采用和离线业务存储平台不同的方案。在线业务的存储方案采用无中心架构的平台,这样很好地避免了某些关键节点宕机所导致的服务不可用情况的出现,同时也可以做到类似平台升级而业务部门完全透明。离线存储需求考虑到追求的是高吞吐的大数据处理,可以容忍短时间的不可用,所以可以用HDFS这种有中心的架构(当然现在最新的方案里面HA也有了),同时在计算方面,针对不同的计算需求,分别运行在M/R、Storm、机器学习、Spark等平台上。
代码阅读和分析是基本功
如果选用了相对成熟且和自己业务特点很匹配的方案,那基本上满足需求就没问题了。基本可用性问题解决了,能否用好那又是另外一回事了。
很多人都会觉得,开源软件用起来也没什么问题了,尤其是很多相对成熟的开源软件在小规模使用的时候出现较大问题的概率还是比较小的。那么,是否就不需要花人力在对它的研究尤其是分析代码了,只是用就可以了呢?
平台在实际使用过程中,因为环境变化、规模增加、服务压力变大等各种变动都会导致集群不能提供稳定且高效的服务,如服务变慢、请求拒绝、各种报错等。这时如何定位问题产生的原因就非常重要了,只有将问题原因找到了,才能有针对性地解决。如果对平台不了解,定位问题就是两眼一抹黑,无从下手。有些热门问题可能社区和网上可以搜索到现成的答案,但大量非热门的问题(如仅仅因为自己的环境才导致的问题)是很难直接从网上找到答案的。那怎么办呢?就只能靠自己的技术人员一点点地去分析平台代码、算法、各种处理流程等,如果平时基本功打好了,关键时刻出现问题解决起来效率就高了。
在定位问题之后,很多的Bug修复或性能优化都会涉及代码修改,如果对代码和架构不熟悉,是不敢轻易修改上线的,轻易修改后的结果可能会在解决一个问题的同时引入更多的Bug。所以要用好一个大型开源平台,是需要对开源平台有大量研究和分析的,包括阅读大量代码、分析各种处理流程和实现算法。我们公司的任何平台都是由专门技术人员不断分析各个关键模块代码和算法,在不断使用各种循环迭代,最后对平台的掌握越来越多,定位问题的速度也越来越快,解决Bug效率也越来越高,技术人员对于掌控平台的信心也越来越足。最后导致的结果是Bug越来越少,平台越来越稳定。
阅读和分析代码是一个很艰难也很枯燥的过程,很多技术人员喜欢自己写代码而不是阅读别人的代码。这也是很多技术人员在接手别人项目时都倾向于推倒重来而不是基于原有代码修改的原因。如何让技术人员快速通过阅读代码加深对平台的理解呢?我们有一个好的经验是将开源平台切分成若干部分,每个部分安排一个人一段时间如一周重点阅读,然后给相关技术人员串讲,串讲过程中大家会问很多问题,通过这些问题的反复讨论加深对平台的了解,同时讨论过程中会发现很多理解不透彻的地方。记录下有疑惑的地方后下周继续分析和讨论,一轮轮迭代、长时间的积累之后对平台的理解就慢慢加深了。一般而言,个人经验是好的技术人员需要将这个过程持续一年左右,才能保证对平台有一定的理解,另外一个就是重视各种问题的分析,分析问题和验证问题的过程也是一个很好的加深代码理解的过程。
重视运维,为平台保驾护航
基础平台作为一个大型服务,时时刻刻都有大量的业务进行各种各样的访问。服务的稳定性决定了业务部门使用平台的信心,很多平台最后以失败告终,很大程度都是因为稳定性无法保证,三天两头出问题的平台估计谁都不愿意继续使用。如何确保平台的稳定性呢,其中很重要的一点就是运维工作要做到位,对运维工作再重视也不为过。
首先监控要尽量全,保证能监控到系统重要的各个方面,尤其是主节点这样的关键节点监控更是要全,确保重要信息能监控到。监控的信息不仅包括系统级别的如CPU、网络、I/O等信息,还要包括进程级别的各种信息如进程个数、打开文件句柄数、Socket连接数等信息,甚至还要监控到应用各种日志级别的信息。
其次是报警要做到位,将系统各种隐患或问题通过短信、邮件或其他方式报告出来,以便及时处理。这时会面临一个通用问题,那就是报警信息的筛选问题,随着监控信息越来越多,产生报警的信息页也越来越多,如果报警内容和策略设置太严格,可能会导致有些关键信息报警报不出来。但如果报警内容和策略太宽松,就会导致大量垃圾信息报出来,就像狼来了似的,久而久之接收报警的人就麻木了,真正关键的报警报出来后反而没人处理了。所以在报警策略设置、报警信息的去重等方面需要随着变化不断调整和优化,做到关键信息一定要报出来,无用信息或冗余重复信息尽可能少报或不报。
最后是数据分析,没报警不代表集群没有问题,很多问题的爆发也不是突然发生的,它有一个累积过程,也就是很多隐患其实在事故前就已经存在了很长时间了。如果在平常对系统各个指标加强数据分析,发现不符合预期的指标,然后去查背后产生的原因,往往都能找出很多隐藏的Bug,一定要提前修复而不是等到出问题后再去补。
对问题要较真,大胆假设,小心求证
在使用过程中,平台会产生各种各样的问题,这时候很多工程师容易犯的错误是想当然。想当然认为问题的原因是什么样的,然后要么忽略,要么按照想当然的原因去找解决办法,其实很多想当然的问题的原因其实是错误的。如果按照错误的原因去解决,就会出现南辕北辙的情况,想了很多办法,花费很长时间,但最后仍然解决不了问题。现实中经常会出现这样的情况,一个问题总是彻底解决不了,因为问题本来就不在这。好了一阵,过一段时间又暴露出来了,无论怎么做都无法彻底解决这个问题。即使是经验非常丰富的工程师也很难保证每次猜测的原因都是对的,那怎么解决呢?这时就应该发挥大胆假设、小心求证的精神。可以允许你大胆猜测各种可能的原因,但每个原因必须通过实验或数据的验证,保证结论的可靠性,而不是默认猜测原因是对的。有时甚至从一个方面求证还不够,还需要从不同方面分别求证,直到各个方面求证的结果都符合猜测预期,才算真正求证成功。
在公司平台持续使用过程中,在问题定位过程中,针对可能的问题原因,我们提到最多的是有什么证据或用数据证明你的假设,反复地挑战各种假设。多问为什么,最后经过几轮反复的验证和讨论,才能逐步找到问题的所在。只要问题真正的原因找到了,解决起来相对于定位问题的话就要简单很多了,做技术的同事应该对此深有体会。
在求证的过程中非常难的一点是怎么做到快速验证,因为一个问题的原因在猜测阶段会有很多种可能,如果每个可能验证都花费大量时间,这样会极大地影响定位效率。所以在求证过程中一定要非常注意效率,如果某种方法求证时间过长,那应该尽快调整换一种更快更高效的求证方法。
结束语
分布式存储和计算领域目前还在以极快的速度发展,新的平台不断涌现,老的平台随着数据规模和计算规模的扩大,问题不断暴露,需要不断改进。给从事基础平台的人员提出的挑战也越来越大,只有怀着不断学习的心态,才能与时俱进,跟上业界步伐。
唐会军
2006年加入百度,百度系统部技术负责人,负责Linux系统优化定制、搜索架构优化、虚拟化、分布式、硬件等基础架构相关工作。2010年加入360,任系统部总监,负责公司大数据存储、计算、云主机等基础架构相关工作,支撑公司搜索、安全、云计算等业务的快速发展。
进化——大型开源分布式平台实践心得 @唐会军
书名: 进化
作者: 北大首届互联网CIO-CTO班全体同学
出版社: 人民邮电出版社
副标题: 我们在互联网上奋斗的故事
出版年: 2014-10
页数: 272
定价: 39
装帧: 平装
ISBN: 9787115369178