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

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