[[276983]]

一個沒有數據工程經驗的人成了一家初創公司的第一位數據工程師，這是一項艱巨的挑戰，但回報也是很可觀的。

公司在招人的時候不僅要找到合適的人，還要讓他們相信加入公司是正確的選擇。 

當我收到 EmCasa 公司的面試邀約的時候，我是另外一家公司的數據科學家。他們想找一位可以幫助他們組織數據的人。我問他們現在已經有哪些數據了，他們真誠地回答我：“我們只有 PostgreSQL 數據庫里的幾張表，還嘗試使用了一些 BI 工具，僅此而已”。聽了他們的話，我也很誠實地告訴他們：我沒有亮眼的學位，之前也沒做過數據工程師，不懂 Spark，不會 Airflow，不是 ETL 方面的專家，也不懂測試和 Git 之類的東西，我也不是一名開發人員。但我見過很多東西，有一些很好，有一些還不錯但仍有提升的空間，還有一些完全不行。我的想法是要盡量避免去嘗試已知不可行的東西。

我不知道他們是怎么想的，總之最后我成了他們公司的第一位數據工程師。

在加入這家公司后，一切都像他們之前所說的那樣。我有足夠的施展空間，可以按照我認為的最好的方式去做每一件事情。第一周，我們就制定了一些季度 OKR：   

• 從 Facebook Ad、Google Ad、SalesForce 和其他第三方服務獲取數據；
• 實現一個 BI 平臺；
• 將物業估價算法準確度提高 20%；
• 將評估模型設計成獨立的 API；
• 更新和改進 Web 爬蟲。

為了從第三方服務提取數據，我們開始調研 ETL 解決方案，比如 StitchData、Fivetran、Segment、Alooma、Rivery，等等。要為每個第三方服務 API 構建自定義集成方案需要花費很多時間，但我們速度要快，而使用 ETL 服務解決方案可以為我們節省幾個月的開發和維護時間。我們決定使用 Rivery，并在兩周內搭建了一個 Redshift 集群，用來每天更新來自第三方服務的數據。這個時候，Luca 加入了我們，成了我們的 BI 分析師。他現在有很多數據可以玩了。我們還使用 Metabase 作為儀表盤。到目前為止，一切都很順利。我們終于有了真正的數據，而不只是 PostgreSQL 里的幾個表了！

下一步是改進物業估價模型，并將其作為一個獨立的 API（之前的模型是與后端綁定在一起的）。但我們沒有足夠的數據來創建新模型（雖然確實有了一些數據，但還不夠）。于是，我把目光投向了我們的 Web 爬蟲工具。它是用 Elixir（我們的后端就是用 Elixir 開發的）開發的，但我不懂 Elixir，于是我決定用 Python 從頭開始開發另一個爬蟲。我創建了一個叫作 Spatula 的 Python 包，它可以從其他網站爬取數據清單，并將它們保存到 S3。這個時候，我們的數據科學家 Priscila 也加入進來，她負責處理舊數據。我在本地運行 Spatula，她就可以使用 Athena 查詢數據，然后開始建模。

接下來，我開始研究 Airflow，不過我遇到了一些麻煩。一個是學習如何編寫 DAG，一個是學習如何將 Airflow 可靠地部署到 AWS 上。我花了很多時間學習 Airflow、Terraform、Docker 和 AWS ECS，才順利地在 AWS 上進行了第一次部署（https://github.com/nicor88/aws-ecs-airflow），然后又花了更多的時間按照我們的需求進行了定制。我擔心這項任務會占用太多時間，所以我問經理是否可以把時間往后推一點，并換一種方式來安排任務（我知道這種方式從長遠來看是行不通的）。經理的回答是：“我們在面試你的時候就知道你的情況，有些東西你也不懂，但你可以花時間去學，找到正確的方式來完成這些任務”。這種管理姿態和”做正確的事情“的承諾是我在其他公司從未見過的。隨后，我們花了更多的力氣部署好了 Airflow，讓 Spatula 爬蟲每周爬取一次數據。

收集用戶信息，用來預測房產銷售價格。我們會詢問物業的詳細信息，如有多少個房間、套房、浴室和車庫。

這個時候，Priscila 的新估值模型也準備就緒，但還沒有準備好用于生產環境。我開始和她結對編程，并告訴她我修改了哪些東西，以及為什么和怎么改的。然后我們一起部署了 Priceteller，這是我們的第一個機器學習模型。它是運行在 AWS Lambda 上的 Flask API 和 API 網關。在部署之前，我們還與開發團隊討論了很多與代碼質量、測試和文檔相關的問題。他們不想在生產環境中向不可靠的 API 發送請求——他們提出這樣的高標準絕對是有道理的。當我們達到他們的標準，我們的第一個機器學習模型就可以上線了。最近，我們還部署了第二個實時模型 Selekta，它可以根據用戶的偏好來推薦清單。

我們的第一個機器學習模型，從數據抓取到部署

Priscila 告訴我她以前的公司是如何使用 Airflow 的。因為我之前都沒有用過 Airflow，所以試著通過反復試錯來學習。她提出了一個改進清單，我全盤接受了。從那時起，我們開始在 AWS Glue 上運行 Spark 作業，并用一個 Airflow 任務來觸發和監控它們。我們的作業每隔一個小時從后端獲取數據。我們還有其他一些負責保存用戶日志事件的任務。我們還創建了一個推薦模型，每天以批次的方式運行。不知不覺地，我們現在在 S3 上有了一個數據量超過 2TB 的數據湖。

我們目前的數據基礎設施

那么，我們從中學到了什么？

如果目標明確，學習就不是個問題

對于有數據科學背景的人來說，數據工程并不復雜。作為數據科學家，我們感覺到沒有可用的數據或工具來完成這項工作是多么的痛苦。但我們可以學習，Airflow、AWS、Spark、Git、Python，凡是你能想到的東西。只要你知道目標是什么，就能在短時間內學會它們。漫無目的的學習很難有成效。

了解公司

知道要做什么和動手去做是兩碼事。這與公司的文化有關。在面試的時候我就知道，我加入了一個可以讓我擁有自主權的公司，可以用我認為正確的方式去解決問題。你可以在面試中問他們數據對公司來說有多重要。只是用于提供支持嗎？還是公司發展戰略的一部分？他們對你是真誠的嗎？如果數據并不是公司發展戰略的一部分，那么你很可能沒辦法花很多時間去計劃和做正確的事情。

數據就是產品

將 API、模型和儀表盤作為獨立的產品，這為數據團隊提供了極大的靈活性。但它們必須符合某些標準，這樣才能將它們打通。將數據作為一種產品，并形成文化，保護團隊免受日常業務問題的困擾——可以讓分析師們去回答這些問題。我們的經理可以讓我們免受外界的干擾，讓我們能夠集中精力學習，把事情做好。

尋求幫助

有時候你需要獨自完成一些工作，但有時候向那些有經驗的人尋求幫助會為你節省很多時間。如果團隊里有經驗豐富的人，可以問問他們之前在其他公司是怎么做的。即使他們不知道該怎么做，至少也會知道什么行得通，什么行不通。尋求幫助肯定會把你引向正確的方向。

把時間花在刀刃上

有些事情可以通過第三方工具輕松搞定，比如我在本文開頭所說的 ETL 解決方案。如果你的數據倉庫中沒有來自 Facebook 的數據，那就沒有必要浪費時間學習如何連接 Facebook Insights API；如果沒有運行在 EMR 上的作業，就不需要學習如何在 EC2 上搭建 Spark 集群；如果沒有 Glue Job，就不需要使用 EMR；如果沒有 Athena 查詢，就不需要 Glue Job。

先從嘗試使用最簡單的解決方案（不需要花很多時間維護的解決方案）開始。當簡單的解決方案不能滿足需求時，再開始學習其他工具。如果從一開始就使用復雜的解決方案可能會浪費你的時間。要專注于用最簡單的解決方案盡可能快地提供業務價值。

構建不需要花太多時間維護的東西

花大半天時間去修復一個有問題的東西，這是最糟糕不過的事情了。如果經常出問題，那么要么是你做事的方式錯了，要么沒有用對工具，或者兩者兼而有之。從一開始就做對事情可能會花掉你更多的時間，但在未來會為你節省時間。

誠實

如果有什么東西是你不懂的，請說出來，但也要證明你可以以及愿意去學。這樣你就可以用工作時間學習新東西。

分享你的知識

向其他團隊成員分享他們不知道的東西。這樣有助于你專注學習，也有助于減少不同工種之前的工作摩擦。如果數據工程師、數據科學家和機器學習工程師之間有了默契，工作就會變得更加順暢。結對編程是一個很好的實踐，可以借機分享你的知識，并獲得實時反饋。花點時間分享你的知識，看看你能為別人提供些什么。

花點時間小憩

在完成一個大項目后，比如部署了一個新的 ETL 管道，就可以花點時間做一些次要的任務，比如寫文檔或修復遺留 bug。欲速則不達，馬不停蹄地開始另一項大項目可能會讓你走得更慢。