Hadoop in 360——专访360系统部总监唐会军

在前不久的Hadoop in China 2011大会上,360系统部总监唐会军接受了InfoQ的专访,谈到360公司内部对Hadoop的使用,并对Hadoop项目和HBase面临的挑战提出了自己的看法。以下是采访实录。

InfoQ:现在360的技术团队规模有多大?

唐会军:大概有八九百人,现在360发展挺快的,人员扩张每年翻倍,今年又比去年翻了一倍,去年又比前年翻了一倍。

InfoQ:如何测试基于Hadoop的应用?您能否分享⼀一些相关的最佳实践?这些最佳实践所基于的上下文是什么?

唐会军:Hadoop应用的测试,我们现在主要两个方式,一个是做Code Review,提交到Hadoop上面的应用程序,我们会去复查代码,发现问题;第二个就是先在小范围的测试跑一跑,观察几天或者一周,没问题了,我们再在更大规模继续去跑,就是这两种方式。

InfoQ:360采取的第二种测试方式,在测试中会关注哪些指标呢?

唐会军:重点关注应用在测试过程中,它持续的时间、消耗的资源是否符合预期,因为Hadoop集群是个公用集群,不能因为某些程序没写好,把所有的 资源都给占掉了,然后影响其他机器。它使用的CPU、I/O、网络这些资源能符合预期,是我们的焦点,如果太多的话,肯定是程序有问题。

InfoQ:对于这些指标,是否有一个相对的正常预期范围?

唐会军:对,在开发团队提交一个任务之前,我们会让他估计一下会从我们集群提取多少数据,他会大概估一个范围是多少T到多少T之间。比如是一T到两 T之间。如果运行过程中发现他用了十个T以上的数据,那就有问题,我们就去查一下,这是数据消耗量;第二种就是程序运行过程中对CPU的消耗,如果他说基 本上一百个单位就可以了,然后半个小时就可以跑完。那真正跑了一百个单位以后,花了一个多小时还没有跑完,这肯定就是有问题。我们会去查,会看到程序里面 有一些东西写得不太合理,导致一些错误,出现不断的重试。资源,实际上就体现在CPU的资源;数据量就体现在I/O的资源。计算机无非就是I/O、网络、 CPU这三个资源,关注他这个资源的消耗情况。

InfoQ:360现在主要用Hadoop具体做什么样的应用?

唐会军:Hadoop用得很多,我们会做一些样本的存储,因为我们样本特别多。用户在做云查杀的时候,我们会去 扫描用户电脑上的样本文件。同时用户在安全浏览器里面去下各种应用的时候,我们也会扫描下是否有病毒。如果发现一个未知的样本,我们会把这个样本的一些特 征给抽取出来,存到后台,由后台服务器判别。这些数据存下来以后,我们用一些数据挖掘引擎去扫一下,这个数据量非常大,每天会超过10个T。

InfoQ:超过10个T?

唐会军:对,我们会结合Hadoop自己开发一些程序来处理。

InfoQ:你们会把这些程序像豆瓣一样开源吗?

唐会军:暂时还没有,还没到时候吧。有些软件的架构需要在内部用得更成熟一点,再开源出来。现在看时机还不到。另一个原因,开源出来以后,外部用的话,还需要投入人力去帮助大家用,因为现在内部人力还比较紧张,或许过个一两年,慢慢会这样去做。

InfoQ:360内部用Hadoop的时候,你觉得遇到最大的困难和障碍在哪?

唐会军:虽然Hadoop是个比较成熟的开源分布系统,但是它在不同场景下,还会有一些特定问题会出来。所以刚 用的时候,包括我们在用的过程中,会出现各种异常现象和问题,包括计算进程被杀掉,有一些读写超时等等。这可能需要我们花很长时间去研究和讨论代码,然后 再结合产品去定位问题。这方面各种问题其实也不少,包括它的Bug。

InfoQ:有很多Bug?

唐会军:对,很多Bug的出现跟你的应用场景有关系,可能我们有些应用场景跟一般的不太一样。比如我们 Hadoop上存大文件,也有很多小文件,然后这些小文件多了以后,就会导致一些特殊问题。这时就需要我们去把Hadoop的代码弄清楚,我们准备做一些 修改和优化,这方面对我们的挑战比较大。

InfoQ:能不能说下Hadoop在360的下载系统的使用情况?

唐会军:我们大概尝试了一年多,现在已经是下载集群的标配了。除了传统的大数据的分析和挖掘,我们也在尝试把它 用在在线下载服务上面,目前用的还挺好。当然也遇到很多问题,包括Hadoop的代码里面有一些不太适合做在线下载应用,我们根据需求,把Hadoop的 很多代码做修改,现在已经用得非常非常好。

InfoQ:从技术上来讲,主要的挑战在哪?

唐会军:Hadoop设计出来的初衷是解决离线大数据的挖掘,它追求的性能指标是吞吐量。但是在线应用的要求是 低时延,可能吞吐并不是最重要的。用户每个下载服务请求对时延比较敏感,所以这两个需求之间不完全匹配。现在下载面临最大问题是:原来很多设计是追求高吞 吐,但是时延会受到影响,我们做了很多工作,把原有算法做调整以后导致它的时延会降低下来,吞吐会下降一些,因为这两个需求是不太一样的,一个是高吞吐, 一个是低时延。

InfoQ:这跟视频的服务是否类似?

唐会军:我们的下载应该是跟视频这样的业务是比较类似的。所以我们觉得出来分享一下这个架构,可能对下载和视频服务有一定的借鉴意义。

InfoQ:2012年的QCon技术大会设计了海量视频处理的议题。大家现在上网带宽越来越宽,又有移动3G,所以视频的需求肯定越来越大,我相信越来越多的公司都面临这个问题,您能否再分享一些相关经验?

唐会军:真正要把Hadoop在一个完整的下载集群里面用好,要做很多方面的调整,包括P2P的一些算法。包括 客户端P2P的一些算法,还有后端的下载服务器,他们两个要做配合。其次,每一块下载的数据大小也是需要优化的,原来P2P客户端的开发只需要从自己的角 度考虑,他并不会考虑到后端的承载能力和实际情况,现在下载的时候,需要客户端和后端两方面做一些协商,看数据块多大是最合适的。第三个,nginx本身 针对下载服务也有很多可以优化的地方,包括它的一些参数,它的一些读取文件方式,用pread还是sendfile,还是其他方式,这些方面都可以调整。 第四个方面,因为nginx服务和Hadoop用Fuse方式去做接口,包括Fuse的方式也要做很多调整,才能适合下载业务去使用,保证低时延,高性 能。所以实际上我们在把Hadoop用在下载业务中,并不仅仅是针对Hadoop HDFS做了一些优化,而是相当于是Fuse、nginx、包括P2P客户端等,都做了一系列优化。

InfoQ:您认为Hadoop现在在哪些方面还有欠缺,需要什么样的框架来弥补它的这些问题?

唐会军:HDFS、MapReduce和HBase,这可能是Hadoop里面用得最多的三块了。我们觉得 HDFS现在面临最大的挑战是:怎么能够解决更多小文件持续存储的问题。因为小文件多了以后,会带来好几方面的问题:一个是name node内存占用会比较多,这个需要解决。第二个是,小文件多了以后,每个根目录下的小文件也会多,很多机制在面对小文件很多的情况下,也不太适应,一些 配套服务响应的时间会非常非常长。然后时间长以后,会堵塞更多的Hadoop之间的一些心跳,name node会认为这个data node是死掉了,其实是没有死的,等等一系列的问题吧。所以我们觉得HDFS将来面临的一大问题就是:如何处理一个亿、两个亿,甚至更多的小文件,毕竟 很多应用中还是会有很多小文件的。

MapReduce这个框架体系结构是比较成熟了,下一步挑战就是实时性方面的改进。这样我们既可以利用MapReduce这个框架的优势,同时保证它的实时性达到我们要求的范围内,并不是说一定要越快越好。

HBase出现时间比较晚,它现在面临的最大挑战就是稳定性不够,我们在用的过程中就发现:相对HDFS和MapReduce这两个组件来讲的话,HBase的bug比较多,所以希望HBase能尽快成熟起来。

InfoQ:Doug Cutting也说HBase会是下一个明星开源项目。

唐会军:对,结构化的Key Value存储需求是非常非常大的,以前没有一个很好的方式去满足海量的Key Value存储,很多公司也在做一些自己的开发,尤其淘宝和FaceBook等公司,他们都做自己的开发。但我们觉得HBase这种架构是不错的。如果它 比较成熟的话,应该是很有希望成为下一个超级明星。

This entry was posted in DB. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s