Growth@Airbnb，从数据危机开始

编者按：文章的作者 Henry，是 Airbnb 的第一个华人工程师，在硅谷工作 7 年多，负责技术和产品控制。前不久离职来北京和 Pinterest 的小伙伴 Leo 一起创办了一家移动互联网公司，并获得顶级机构的投资。他把在 Airbnb 的工作经验整理成了文章，本篇是讲述一只并不具有丰富技术经验的团队如何成长为以数据为基础的公司的。

现在我还依稀记得 2012 年加入 Airbnb 时候的样子。没有现在如此高大上的办公楼，没有全球的房东大会，北京对我们来说还只是地图上个的一个标记。由工程师、设计师和产品经理组成的团队大约有 50 个人， 管理扁平到所有的工程师直接向创始人兼 CTO Nate 汇报。团队的划分是流动的，跟着项目走。每个季度甚至某个月如果需要做某件事情，那就会在 24 小时内临时组成一个团队去做某个项目。直到项目做完，这个临时团队解散。这样看起来有些混乱的管理方式，却支撑着公司经历了最为高速增长的岁月。这种管理 方式为团队提供了极大的灵活性，也极大的激励了他们的创造力。有时我在想，如果你在走一条别人没有走过的路，不断快速地尝试各种可能也许是那个时段很合理 的 growth hacking 方式。

但是随着我们用户量的激增，这种没有太多数据作为支撑的开发方式很快就带来很多头痛的问题。新版的搜索算法出来了，但是预定量却出现了下降，问 题出在哪里？主页的改版业内人士和媒体都叫好，但是用户转化率骤减，为什么？要回答这些问题，脱离了数据分析都是纸上谈兵。好在到了 2012 年底，公司意识到了问题的严重性，下决心开始向数据驱动性的公司转型，而不再只是跟着感觉走。

我到 Airbnb 的第一个主要任务便是帮助公司搭建数据平台。全新的团队由 4 个人组成，领头人是 推ter 的早期资深工程师。我们最主要的任务是建立搜集和处理数据的平台。当时数据收集由各个项目团队负责，有时候为了赶工期，数据收集往往被排在了最后。更为糟 糕的是，网站和移动端的数据收集是完全分开的，每个产品经理用着他们自己喜欢的数据工具。每个人只能摸到大象的一个部分，无人知道大象长得啥样。而和我们 合作的数据科学家们更是苦不堪言，受制于不全的数据，他们往往无法给出准确的决策建议。

为了改变现状，我们做的第一件事情就是让数据收集变得不费吹灰之力。目标是使得每个应用开发工程师能从一个项目开始就自觉地收集数据。很快我们 开发了第一版系统。这个数据收集系统由 3 部分组成–日志组件，日志服务器，数据 pipeline。日志组件是一个对底层日志服务器所提供服务的一个封装，它提供一个简单而通用的接口。通过它，应用开发工程师只需一行代码就能记录他想 要记录的事件，无需关心日志服务器在哪，日志存在哪里，出错怎么办。通过简单易用的日志组件，我们统一了网站和移动端的数据收集。而日志服务器是一个小集 群，他们是分布式的，每个应用服务器会自动找到一个正常工作的日志服务器，并通过 REST API 来传递日志。数据最终被日志服务器存储到 AWS 的 S3 里，然后由 EMR 上运行的数据 pipeline 来进行各种处理，最后导出到传统的 SQL 数据库供分析使用。这个系统工作了一段时间，越来越多的团队开始使用它，而随之而来数据压力也暴露它在设计上的不足。小量的掉数据事件时有发生，而且排查 起来也十分困难。好在这个时候由 LinkedIn 主导开发的 Kafka 发布了最新的 0.8 版，这个一度由于没有很强的容错能力而被内部团队否定的系统，随着新版本的大幅改进的再次进入我的视线。我极力主张基于 Kafka 来开发新版本的日志服务系统。于是我们很快开发了一版基于 Kafka 的系统，事后的结果证明，无论从性能还是可靠度来看，新系统比老的系统好了一个数量级。再也没有数据丢失发生，而且系统的运营也变得极为简单。

除了在数据收集上的挑战，我们在数据分析工具上也遇到了各种问题。最早的数据分析全由 CTO Nate 一个人在一台 SQL 服务器上进行。后来数据科学家团队开始建立，大家依旧沿袭了在一台 SQL 上做分析的习惯。随着需要使用数据的团队越来越多，而且大家在写 Query 时的各种漫不经心，导致 RDS 不堪重负，死锁时常发生。为了解决这些问题，并保证分析工具跟上数据和用户的增长，我们开始着手搭建自己的大数据平台。第一版的大数据平台很简单，基本上 是基于 EMR 的接口进行了一个接单封装，然后数据科学家们用一个 crontab 来调度数据处理任务。很显然，这种方式有着诸多问题。第一，由于数据需要在 S3 和 EMR 的 HDFS 之间倒腾，I/O的代价非常昂贵。第二，如果 crontab 里的某个任务失败，而该任务是一系列的任务中的一个， 我们不得不从头执行这个序列。第三，EMR 是个黑盒子，排错很困难。

痛定思痛，我们决定基于 Mesos 来搭建我们的大数据平台。不熟悉 Mesos 的朋友可以把它想象成为一个 Linux 服务器集群的操作系统–集群对使用者来说如同一台服务器，而 Mesos 在集群内部处理各种资源的调度和任务的执行。之所以选择 Mesos，第一是由于他给分布式服务的将来绘制了一个十分美好的未来（尽管我们在使它的时候它还十分地不成熟），第二是由于团队里有员工在 推ter 一直实践 Mesos，而且 推ter 当时已经有非常多的服务跑在了 Mesos 上面。第三，作为一名工程师，有什么比尝试最炫酷的技术更让人激动人心呢？这个投资获得了客观的回报，数据在组织内部唾手可得，在需要数据为决策做支撑的 时候，人们不再抓自己的后脑勺。我们还基于 Mesos 开发了一个任务调度系统叫做 Chronos，利用这个系统，我们可以随意的创建一系列相互关联的计算任务，即便其中某个任务出错，它能够很智能的纠错以及报警。Mesos 还提供了用户界面帮助我们排查某个出错的 Job。要知道以前，我们还得靠非常原始的 shell script 去 EMR 的各个节点服务器上去抓取相关的日志，查错异常痛苦。Mesos 上面不仅可以跑 Hadoop，Kafka，而且许多内部服务都运行在它上面。最神奇的是，这些完全不同的服务，动态地运行在同一个集群里互不干扰。（想了解更多关于 Mesos 的信息，可以去瞅瞅 Mesosphere 这家公司）。对于不太会使用 Hadoop 工具的用户，我们还试着引入了 AWS 的 Redshift，极大的提升了数据用户的工作效率。（具体详情可以参见我在 Airbnb 工程师 blog 上的这篇文章）。我们还很早地尝试了由伯克利 AMP 实验室开发的 Spark/Shark，由于我们的数据科学家大多只有 SQL 的背景，加上当时系统的不成熟，只好在短暂使用以后很无奈的暂时放弃了（不过现在的 spark 和 shark 已经做的非常好了，做机器学习的朋友可以了解一下这个技术以及由伯克利的这个团队开创的 Databricks 这家公司）

至此，我们拥有了基本的数据收集和分析的能力，产品的开发变得越来越理性–一个功能最后发布与否，不取决于人们的直觉，而是用户的真实行为。是 时候开始建立一个团队来专注于 growth 这件事了。2013 年底 Airbnb 正式成立了 growth 团队，在下一篇文章里我会来和大家说说这个团队的前世今生。