大数据日本企业篇（二）：互联网招聘公司Recruit株式会社

Recruit创立于1960年，最早是一家面向大学报刊的广告代理，随后以Rikunabi为代表，开始提供就职、转职等人才领域的信息，并逐步发展到与结婚（皆喜ZEXY）、买房（SUUMO等）、转职（Travail、RikunabiNEXT等）等人生大事，以及美食（HotPepper等）、旅游（Jalan等）等每天的生活方式相关的业务领域。（标注一下，Recruit曾是前程无忧的股东之一）

其传播信息的媒体也并不仅局限于传统的纸媒，从1995年起Recruit便开始涉足互联网，目前，在面向PC、手机平台等网络媒体的收入，已经占到总营业额的1/3。

几乎整个公司都在运用Hadoop

现在，除了SUUMO、ZEXY、Jalan、HotPepper等网站之外，Recruit还 运营 着其他一些将企业与人联系在一起的丰富多彩的网站，如二手车信息网站CarSensorNet、优惠券团购网站Ponpare等。

在这些网站中，大多数都是采用Hadoop及其生态系统（Hive、Mahout、Sqoop等）来实现推荐、关联 分析 1、属性分析等功能。Recruit实现了对分析所需的数据进行高速处理，取得了不错的成果。

购物篮分析中所使用的数据挖掘 技术 之一，目的是发现关于如“在超市中购买纸尿裤的人会同时购买啤酒”这样两种现象之间关联性强弱的规则。

以HotPepper发送的名为“美食电邮”（飲食ぐるメール）的电子邮件杂志为例。原本由于网站访问日志的处理非常耗时，只能处理一周的日志，因此就只能向一部分会员（8万人）发送推荐邮件。然而，将日志处理用Hadoop进行提速之后，现在可以处理一年半的日志，从而可以向约20万人发送推荐邮件了。这样做的结果是获得了约12万人的CTR2（广告点击率），以及使CVR3（网站访问者的转化率）提升了约1.6倍（图表4-3）。

与此同时，HotPepper还将Hadoop运用在对 营销 渠道（条幅广告、自然搜索、付费搜索引擎注册等）转化率的贡献 评测 中。对于拥有日本最大规模互联网广告投放量的Recruit来说，对成本的优化是当务之急。例如，如果发现列表广告的性价比较差，则可以重新考虑预算的分配（列表、横幅、 SEO 等），从而在整体上对营销费用进行优化。

此外，在二手车信息网站CarSensorNet中，车型选择画面上的“经常被同时浏览的车型”推荐功能也是采用Hadoop和Mahout进行实现的。

Mahout是一种在Hadoop上运作的机器学习、数据挖掘的库，其中包含了使用聚类（Clustering）和协同过滤（Collaborativefiltering）技术实现的推荐引擎等功能。

在每次进行推荐的计算时，为了提高匹配准确度，需要从类似Amazon的协同过滤、相同车型等特殊条件、基于关联规则的推荐等多个条件中选择最合适的条件，而通过运用Hadoop的高速处理，则可以以最合适的条件来进行实现。此外，还可以将用户事先按照性别、年龄等进行分类，将汽车数据也按轻型车、敞篷车等车身类型来进行分类，在此基础上进行关联分析，并应用推荐逻辑（图表4-4）。

支撑Recruit大数据分析的Hadoop基础架构

Recruit最早关注Hadoop并开始进行探索和验证的工作，是在2009年的夏天。Recruit并非一家IT厂商，也不是一家系统集成商，而只是一家普通的企业用户，从这个角度来看，其起步可谓相当早。随后，2011年4月起，Recruit开始进行正式的可行性研究，并顺利地完成了正式上线工作。

这是由于该公司以前就积极采用像ApacheWebServer和Tomcat等开源软件，在公司内部拥有一支维护 团队 ，因此对于这种运用难度较高的系统也驾轻就熟。正是因为一直以来都积极地采用开源软件，对于开源的Hadoop才能够毫无阻力地接受，并赶在其他公司之前对其可能性进行了验证。而且，对于以开源方式提供的软件，Recruit并不仅仅是使用而已，甚至还基于Hivea自行开发了一个能够从浏览器执行HiveQL的Web应用程序WebHive，并将其 发布 到了Githubb上，这些 活动 真的不像是一个企业用户所能做到的。

现在，Recruit使用Hadoop管理大约100TB的数据。用于Hadoop的服务器约有130台，但这些服务器决不是最新的高性能机器，而是使用在数据中心迁移时替换下来的服务器，以1台主服务器、2台应用程序服务器、5台从服务器的结构（未将主服务器冗余至2台，只是最小集群的情况）来进行批任务处理，其中主服务器（master）的配置为300GB硬盘、16GB内存，从服务器（slave）的配置为600GB硬盘、8GB内存。尽管规模上存在差异，但这样的思考方式和Google等公司在云计算环境搭建上的思考方式是相通的。

最近，除了上述自主运营的Hadoop环境之外，Recruit也开始使用Amazon在公共云计算平台上提供的Hadoop集群环境AmazonElasticMapReduce，这也就是所谓的混合云计算（hybridcloud）

Recruit之所以要从搭建自主运营的Hadoop环境开始入手，是为了回避技术的黑箱化导致自己的工程师无法掌握相关技术所产生的风险。此外，像Recruit这样的数据处理规模，从计算结果来看，还是自主运营在总成本上更加廉价，这也是理由之一。

当然，现在Recruit已经具备了一定的技术积累，在面对高峰时段等固定时段以及小规模网站时，会将私有云和公有云结合使用。这种充满灵活性的思考方式和运用方式，对于国内的企业用户来说，具有很大的参考价值。

成功的秘诀在于组织体制

Recruit的大数据运用之所以能够有效地执行，其中有诸多原因，笔者认为首要的成功因素，就是它的组织结构（图表4-5）。在Recruit的组织结构中，除了ZEXYNe（t婚庆）、CarSensorNe（t汽车）、SUUMO（住宅）等各个业务组织之外，还有一个支撑各业务组织的横贯整个公司的组织MITUnited。

所谓MIT，就是Marketing&IT的意思。MITUnited是一个负责各业务网络战略推进和系统开发的部门。该部门总共有200多名 员工 ，其中包括担任Hadoop开发等工作的基础架构团队，负责研究市场营销策略、利用统计技术进行数据分析的市场营销/分析团队，以及负责大规模系统开发项目全局管理工作的项目推进部等。MITUnited的主要任务是解决深度分析、大规模基础架构维护等全公司共通的课题。除此之外，还有专门的人员负责对各业务组织提供支持。

在这里值得注意的一点是，负责基础架构的成员和负责市场、分析的成员是从属于同一个部门的。在笔者所知的范围内，在像Recruit这样规模达到近6000名员工（2012年4月）的企业用户中，负责基础架构的成员和负责市场、分析的成员是从属于同一个部门的情况可谓是凤毛麟角。

正是由于这两个团队近在咫尺，才能够共享各自对问题的认识，并迅速反馈出解决方案，并且可以通过实际的数据来进行验证。例如，随着数据量的增大，统计、分析处理需要的时间太长，导致无法重复执行和追溯，对于这样的市场营销/分析团队的课题，基础架构团队马上就提出了部署Hadoop这一解决方案。此外，由能够准确理解各业务组织需求的市场负责人，与统计专家共同工作，就能够利用适当的统计技术对数据进行分析，并及时地执行相应的措施招揽顾客和提升营业额。

Recruit眼中Hadoop的“真正价值”

笔者采访了株式会社RecruitMITUnited项目推进部系统基盘推进室执行经理米谷修先生。米谷先生对于部署Hadoop的真正价值，讲述了一些十分有益的见解，在这里向大家介绍一下。

如果照本宣科地回答的话，Hadoop的好处大致有：以批处理为代表的处理时间增加的对策；作为日志基础系统，实现数据管理的集中化；使用Mahout等生态系统，可快速实现分析引擎和推荐引擎等。

然而，除了上述几点之外，对于Hadoop的真正价值，米谷先生还列举了下列几点。

（1）由于实现了高速处理，可以通过改变条件，进行重复多次的试错。

（2）可以实现采样数据所无法做到的对长尾部分的分析。

（3）缩短开发周期。

我们逐一来解释一下。首先，关于第（1）点，米谷先生指出：“在传统分析中，数据整理和统计要消耗大量的时间，而且灵活性也比较差。”通过部署Hadoop，从提出假设→创建原始数据→统计→分析，这一循环的执行速度得以大幅度提升，因此通过反复试错，就可以提高分析的精度（图表4-6）。

在这个循环中，“（2）采样数据所无法做到的对长尾部分的分析”是非常有效的。也就是说，在验证假设的过程中，通过采用全体数据来替代采样数据进行统计和分析，可以提高分析的精度。如果是事先不知道答案且目标并不明确的探索型分析的话，通过使用尽可能大量的数据，反复进行验证假设的工作，则是一个逼近目标的捷径。

此外，在分析的过程中，创建简单的应用程序，通过对数据的可视化直观地掌握数据的趋势，这一点也是很重要的。对数据的可视化，是我们第8章即将介绍的数据科学家所必需的一项技能。无论数据的统计如何缜密，只有将其用作决策的依据，数据分析才有意义。因此，将数据进行可视化，让人直观理解其含义，这样的工作是十分重要的。

而正如“（3）缩短开发周期”所指出的，如果通过Hadoop能够加快这一循环的运作速度，对于业务的贡献则是非常之大的。

最后，把米谷先生在采访中给我留下深刻印象的下面这段话分享给大家。

“Hadoop能够高速处理大量数据，这一技术层面的视角固然重要，但更为重要的一个好处，则是感受到‘使用Hadoop能够做到以前做不到的事’，改变分析、商品策划人员的意识，从而让曾经无意中放弃的那些灵感得以破土而出。”

节选自《大数据的冲击》

End.