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 團隊，在下一篇文章里我會來和大家說說這個團隊的前世今生。