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

阅读数:6908 2012 年 2 月 22 日

话题:语言 & 开发

在前不久的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 这种架构是不错的。如果它比较成熟的话,应该是很有希望成为下一个超级明星。


给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。