Airbnb數據工程師的進階指南：技術基礎

做者 | Robert Chang

譯者 | 大愚若智

編輯 | Emily

AI 前線導讀：這一有關數據科學系列文章的第一篇，重點介紹了分析工做涉及到的不一樣技術層，以及一些基礎性的工做，例如數據倉庫的構建。此外還簡要探討了構建 ETL 時涉及的不一樣框架與範式。

更多幹貨內容請關注微信公衆號「AI 前線」，（ID：ai-front）

本文最初發佈於 Robert Chang 的博客，經原做者受權由 InfoQ 中文站翻譯並分享。閱讀英文原文：https://medium.com/@rchang/a-beginners-guide-to-data-engineering-part-i-4227c5c457d7

寫做動機

隨着在數據科學領域的經驗逐漸豐富，我愈來愈確信，數據工程是任何數據科學家最重要也最基礎的必備技能之一。我發現不管項目評估、就業機會，甚至職業成長等方面均是如此。

在早前的一篇文章中，我曾提出數據科學家的主要能力在於將數據轉換爲價值，但這樣的能力大小主要取決於其所在公司數據基礎架構的完善程度，以及數據倉庫的成熟度。這意味着數據科學家必須極爲了解數據工程，才能妥善判斷本身的技能是否與企業的現狀和需求相匹配。此外我所認識的不少知名數據科學家不只擅長數據科學領域，並且都能從戰略上將數據工程做爲本身的毗鄰學科，進而駕馭更大規模、有着更廣大目標，他人每每沒法駕馭的項目。

儘管很重要，但數據工程方面的教育其實很欠缺。從起源的角度來考慮，不少時候爲了接受有關數據工程的培訓，惟一可行的方式是從實踐中學習，但有時這就太遲了。我曾十分有幸可以與一些數據工程師合做，他們很耐心地教我掌握這個課題，但並不是每一個人都能有這樣的機會。所以我撰寫了這一系列新手指南，對我學到的內容進行了簡單總結，但願能讓更多人獲益。

本新手指南的內容安排

這一系列文章的涵蓋範圍不管從哪方面來看都不會十分全面，而且內容主要圍繞 Airflow、數據批處理以及 SQL 類語言。然而除此以外，讀者也能夠自行學習有關數據工程的基礎知識，但願這些內容能讓你產生興趣，並在這個依然快速發展的新興領域中取得必定的成果。

• 上篇（本文）將從較高角度進行總體式介紹。我會將我的經歷與專家看法結合在一塊兒帶你思考數據工程究竟是什麼，爲什麼充滿挑戰，以及這個課題如何幫助你和你的公司成長。本文的目標讀者主要是有抱負的數據科學家，他們可能但願瞭解一些基礎知識，進而評估新的工做機會；或者多是早期階段的創業者，他們可能但願組建公司的第一個數據團隊。

• 中篇 的技術深度更高一些。這篇文章將專一於 Airbnb 的開源工具 Airflow，介紹如何以編程的方式建立、調度和監視工做流。尤爲是我將經過演示介紹如何使用 Airflow 編寫 Hive 批處理做業，如何使用星型模型（Star Schema）等技術設計表 Schema，最終將介紹一些有關 ETL 的最佳實踐。這篇文章的目標讀者是但願掌握數據工程技能的新手數據科學家和數據工程師。

• 下篇 將是這一系列文章的最後一篇，我將介紹一些高級數據工程模式、高級抽象以及擴展框架，藉此簡化 ETL 的構建並提升效率。經驗豐富的 Airbnb 數據工程師曾教給我不少此類模式，我以爲這些看法對具有豐富經驗，但願進一步優化工做流的數據科學家和數據工程師頗有用。

我本人很是擁護將數據工程做爲一個毗鄰學科來學習，不過說出來也許會讓你吃驚，幾年前個人態度是截然相反的。我在本身的第一份工做中曾很是糾結數據工程這件事，動機上和情感上都有不小的糾結。

研究生畢業後，個人第一份業內工做

研究生畢業後，我在華盛頓郵報旗下一家關聯性質的創業公司裏任職數據科學家的工做。當時，滿腔抱負的我確信他們能夠提供能直接用於分析的數據，隨後我就可使用各類先進的技術幫助他們解決最重要的業務問題。

就任後很快發現，個人主要職責並不像本身設想的那麼迷人。其實我當時的工做很是基礎：維護一些關鍵流程，藉此追蹤網站的訪客數，瞭解每位讀者閱讀內容花費的時長，以及人們點贊或轉發咱們文章的頻率。這些工做固然也很重要，由於咱們要將有關讀者的各種看法提供給出版商，藉此免費換得一些高質量內容。

然而暗地裏，我一直但願能儘快完成手頭工做，隨後就有時間開發一些真正高級的數據產品，例如這裏介紹的那些。畢竟這纔是數據科學家的本職工做，我當時這樣對本身說。過了幾個月，一直沒找到適合的機會，我對這家公司也絕望了。然而對於處在早期階段的創業公司（需求方）或數據科學家新手（供給方）來講，對我這樣的親身經歷可能並非徹底陌生，畢竟雙方在這個新的人才領域都沒什麼經驗。

圖源：正在勤奮開發 ETL 流程的我（中央穿藍衣的人）

反思這段經歷，我意識到本身所感覺到的挫折，其根源在於對現實世界中的數據項目究竟是如何進行的，實在是知之甚少。我被他們直接丟到了盡是原始數據的曠野中，但距離通過預先處理的，井井有理的.csv 文件還有很遠的路程。身處一個以這種狀況爲常態的環境，我以爲本身徹底沒有作好準備，哪都不對勁。

不少數據科學家職業生涯開始時都遇到過相似狀況，而只有能快速意識到實情以及相關挑戰的人才能最終取得成就。我本人也已經適應了這種新的現實，只不過速度很慢，步調很緩。一段時間來，我發現了工具化（Instrumentation）這個概念，適應了機器生成的日誌，解析了不少 URL 和時間戳，更重要的是，學會了 SQL（是的，你也許會好奇，工做前我對 SQL 的惟一瞭解僅僅來自 Jennifer Widom 的 MOOC 公開課）。

如今我已經理解了，分析重在仔細、聰明的計算。而面對咱們身處的，始終充斥着各類喧囂和炒做的世界，這些基礎工做尤其重要。

分析的層次劃分

不少倡議者認爲數據科學領域存在的「棱角」和媒體時不時渲染的美好將來之間存在矛盾，在這其中我最喜歡 Monica Rogati 的觀點，她對火燒眉毛但願擁抱 AI 的公司提出了一些告誡：

人工智能能夠認爲處在需求金字塔的最頂端。沒錯，自我實現（的 AI）很棒，但首先你得有食物、飲水以及容身之處（數據讀寫、收集以及基礎架構）。

下面這個框架體現了不少技術間的透視關係。在任何一家企業能夠優化業務效率或構建更智能的數據產品前，必須首先完成不少基礎工做。這一過程相似於咱們每一個人必須首先知足食物和飲水等最基本的生存需求，隨後才能最終實現自我。這也意味着企業必須根據自身需求僱傭數據方面的人才。對於創業公司來講，若是僱傭的第一個數據領域的專家只懂得建模，但不精通，甚至徹底不懂如何構建做爲其餘工做前提要求的基礎層，那麼最終的結果將會是災難性的（我將其稱之爲「亂序招聘問題」）。

來源：Monica Rogati 的文章「AI 需求的層次結構」

然而不少企業並未意識到，咱們現有的大部分數據科學培訓課程、學術機構以及專家都趨向於專一在這座知識金字塔的頂端。就算一些鼓勵學生們經過公開 API 調整、準備或訪問原始數據的新課程，其中大部分也不會教你們如何妥善設計表 Schema 或構建數據管道。現實世界中數據科學項目必不可少的關鍵組成元素就這樣在「轉換」中遺失了。

好在就如同軟件工程能夠用來從專業角度區分前端工程、後端工程以及站點可用性工程，我以爲日漸成熟的數據科學領域也會如此。隨着時間發展，人才的具體組成將越發專精化，會出現愈來愈多具有足夠技能和經驗，能夠順利打造出數據密集型應用程序所需底層平臺的人才。

對數據科學家而言，這種將來設想到底意味着什麼？我並不想爭論說每一個數據科學家都必須成爲數據工程領域的專家，然而我也確實認爲每一個數據科學家都必須對這些基本信息有所瞭解，這樣才能更好地評估項目以及工做機會，真正實現學以至用。若是你發現本身須要解決的不少問題都要求本身具有更深刻的數據工程技能，那麼就絕對有必要付出時間精力學習數據工程。實際上我在 Airbnb 的工做過程當中就是這樣作的。

構建數據基礎和數據倉庫

不管你對數據工程的學習抱有怎樣的目的或多強烈的興趣，都必須首先明白數據工程的重點所在。Airflow 的原做者 Maxime Beauchemin 在數據工程師的崛起一文中將數據工程總結爲：

數據工程領域能夠看做商業智能和數據倉庫的超集，同時也包含更多源自軟件工程的要素。這一學科還蘊含了所謂的「大數據」分佈式系統運維所需的相關技能，以及與龐大的 Hadoop 生態、流處理，以及大規模計算有關的概念。

在數據工程師須要負責的各類重要任務中，最吃香的能力之一是設計、構建、維護數據倉庫。與零售商在本身的倉庫中存儲商品幷包裝銷售的作法相似，咱們須要在數據倉庫內對原始數據進行轉換，並存儲爲可查詢的格式。

來源：Jeff Hammerbacher 的 UC Berkeley CS 194 課程講義

在不少方面，數據倉庫都是實現更高級分析操做，實現商業智能、在線實驗以及機器學習必不可少的引擎和燃料。下文列舉了幾個具體示例，從中也能夠看出數據倉庫在處於不一樣階段的企業中所扮演的重要角色：

• 500px 構建的分析系統：Samson Hu 撰文介紹了 500px 但願在「市場匹配」的情況下更進一步增加的過程當中面臨的挑戰。他詳細介紹了從零開始構建數據倉庫的全過程。

• 擴展 Airbnb 的實驗平臺：Jonathon Parks 介紹了 Airbnb 的數據工程團隊如何構建專用數據管線，爲實驗性報表框架等內部工具提供支持的作法。這些成果對 Airbnb 產品開發文化的塑造和擴展相當重要。

• Airbnb 使用機器學習技術預測房屋價值：由我本人撰寫的這篇文章介紹了爲什麼在構建批處理訓練和脫機計分機器學習模型時會須要在前期進行大量有關數據工程的準備工做。本文還特別介紹了特徵工程、構建和回填訓練數據等不少相似於數據工程的任務。

若是不具有數據倉庫這個基礎，與數據科學有關的全部活動或者會極爲昂貴，或者將徹底沒法擴展。例如，若是不具有妥善設計的商業智能數據倉庫，數據科學家可能將沒法針對相同的基本問題給出不一樣結果，而這仍是最好的狀況；最糟糕的狀況下，數據科學家可能會無心中直接針對生產數據庫進行查詢，致使生產事務延遲或中斷。同理，若是不具有實驗性的報表流程，也許就只能經過很是原始的重複性手工操做進行實驗性質的深度探索挖掘。最終，若是沒法經過適當的數據基礎架構爲標籤集合（Label collection）或特徵計算提供支持，訓練數據自己的籌備也將會耗費大量的時間。

ETL：提取、轉換和加載

上述全部示例都遵循了 ETL 這一常見模式，ETL 表明「提取、轉換和加載」，這三個概念性的步驟決定了大部分數據管道的設計方式和構造，能夠充當將原始數據轉換爲可分析數據的藍圖。爲了更精確地理解這個流程，我從 Robinhood 的工程博客中找了一張很實用的圖片：

來源：Vineet Goel 名爲 Robinhood 爲什麼使用 Airflow？」的文章

• 提取：在這一階段，傳感器等待上游數據源加載（例如上游數據源多是計算機或用戶生成的日誌、關係型數據庫副本、外部數據集等）。加載完成後，須要將數據從源位置移出以便進一步轉換。

• 轉換：這是全部 ETL 做業的核心，經過應用業務邏輯並執行篩選、分組、聚合等操做將原始數據轉換爲可分析的數據集。這個步驟須要對業務以及不一樣領域的知識有全面理解。

• 加載：最後加載處理完成的數據並將其移動到最終位置。一般這類數據集可被最終用戶直接使用，或充當後續 ETL 做業的上游數據源，藉此造成所謂的數據族系（Data lineage）。

雖然全部 ETL 做業都遵循這樣的通用模式，但實際做業自己在用法、工具以及複雜度等方面可能各不相同。下文列舉了一個很是簡單的 Airflow 做業範例：

來源：DataEngConf SF 2017 研討會上 Arthur Wiedmer 的分享

上述範例可在到達執行日期後等待一秒鐘的傳遞操做，隨後直接輸出天天的日期，但現實世界中的 ETL 做業每每更復雜。例如，咱們可能會經過一個 ETL 做業從生產數據庫中提取一系列 CRUD 操做，並派生出各類業務事件，例如用戶註銷。隨後可經過另外一個 ETL 做業接受實驗性的配置文件，計算該實驗的相關指標，最終向 UI 輸出 p 值和置信區間，藉此告訴咱們產品方面的相關變化是否有益於防止用戶流失。此外還有其餘示例，例如經過批處理 ETL 做業天天計算機器學習模型的特徵，藉此預測用戶是否會在將來幾天裏流式。這樣的作法有着無窮的可能性！

ETL 框架的選擇

在構建 ETL 的過程當中，不一樣公司可能會採起不一樣的最佳實踐。過去多年來，不少企業經過不懈努力總結了構建 ETL 的過程當中可能會遇到的通用問題，並開發了各類框架幫助咱們妥善解決這些問題。

在數據批處理的世界中，目前存在好幾個開源的競品。例如 Linkedin 開源了本身的 Azkaban，該產品能夠簡化 Hadoop 做業依賴項的管理工做；Spotify 在 2014 年開源了本身基於 Python 的 Luigi 框架；Pinterest 也開源了 Pinball；Airbnb 則在 2015 年開源了 Airflow（一樣基於 Python）。

每種框架都有本身的優點和侷限，對此不少專家已經進行了細緻的比較（可參閱這裏以及這裏）。不管選擇哪一種框架，都須要考慮下列幾個重要功能：

來源：Marton Trencseni 對 Luigi、Airflow, 和 Pinball 的對比

• 配置：ETL 本質上就很複雜，咱們必須能簡潔地描述數據管道內的數據流動方式。所以有必要對 ETL 的建立方式進行評估。是否能經過圖形界面配置，仍是要使用面向特定領域的語言或代碼？目前「配置即代碼」的概念很是流行，這種方式可讓用戶以編程的方式構建表達式管道，而且可定製。

• 圖形界面、監視、警報：須要長時間運行的批處理做業不可避免會在運行過程當中出錯（例如羣集失敗），哪怕做業自己並不包含 Bug。所以監視和警報能力對長期運行做業的追蹤工做相當重要。框架對做業進度提供可視化信息的能力如何？可否以及時準確的方式提供警報或通知？

• 回填：數據管道構建完成後，一般還要時不時從新處理歷史數據。理想狀況下，沒人願意構建兩個獨立做業，一個用於回填歷史數據，另外一個用於計算當前或將來的指標。框架對回填的支持如何？可否用標準化的方式高效、可縮放地進行？這些重要問題都必須考慮。

做爲 Airbnb 的員工，我固然喜歡使用 Airflow，該技術以優雅的方式解決了我在數據工程相關工做中遇到的常見問題，對此我十分感激。目前已經有超過 120 家企業公開宣稱在使用 Airflow 做爲本身既成事實的 ETL 編排引擎，我甚至能夠大膽猜想 Airflow 將成爲之後新一代創業公司執行批處理任務時的標準。

兩種範式：以 SQL 或 JVM 爲核心的 ETL

如上文所述，不一樣企業在構建 ETL 時可能選擇大相徑庭的工具和框架，對於數據科學家新手，可能很難決定如何選擇最適合本身的工具。

對我而言就是如此：以前在華盛頓郵報的實驗室工做時，最初咱們主要經過 Cron 進行 ETL 的調度，並將做業組織成 Vertica 腳本。在 Twitter 工做時，ETL 做業使用 Pig 構建，不過如今他們已經轉爲使用 Scalding，並經過 Twitter 本身的編排引擎調度。Airbnb 的數據管道主要使用 Airflow 在 Hive 中開發。

在我數據科學家職業生涯的前幾年，大部分時候我會直接使用公司肯定的工具，提供什麼就用什麼。但在遇到 Josh Will 後，個人作法徹底不一樣了，通過與他討論，我意識到實際上 ETL 有兩種典型範式，而數據科學家應當慎重決定到底要使用哪一種範式。

視頻來源：Josh Wills 在 @ DataEngConf SF 2016 所作的主題演講

以 JVM 爲核心的 ETL 一般使用基於 JVM 的語言（例如 Java 或 Scala）開發。這些 JVM 語言中的工程數據管道一般須要以更加命令式（Imperative）的方式考慮數據的轉換，例如使用鍵值對。此時用戶定義的函數（UDF）的編寫過程會更爲輕鬆，由於不須要再使用不一樣語言來編寫，一樣由於這個緣由，測試做業也能夠大幅簡化。這種範式在工程師之間很是流行。以 SQL 爲核心的 ETL 一般使用諸如 SQL、Presto 或 Hive 等語言開發。ETL 做業一般須要以聲明式（Declarative）的方式定義，而且幾乎一切都以 SQL 和表爲核心。UDF 的編寫有時候會略微麻煩，由於必須使用另外一種語言（例如 Java 或 Python）編寫，也正是所以，測試做業也會顯得困難重重。這種範式在數據科學家之間很是流行。

做爲曾經用過這兩種範式構建 ETL 管道的數據科學家，我天然而然更傾向於使用以 SQL 爲核心的 ETL。實際上我甚至願意說，做爲數據科學家新手，若是使用 SQL 範式，你將能更快速地掌握數據工程。爲何？由於 SQL 遠比 Java 或 Scala 容易學（除非你已經熟悉後二者），藉此你能夠將更多精力專一於數據工程最佳實踐的學習，而不是在一個不熟悉的新語言基礎上學習全新領域內的各類新概念。

新手指南上篇總結

本文介紹了分析工做涉及到的不一樣技術層，以及一些基礎性的工做，例如數據倉庫的構建，這是企業進一步擴展必不可少的前提需求。此外還簡要探討了構建 ETL 時涉及的不一樣框架與範式。不過須要學習和探討的內容還有不少。

在這一系列的下一篇文章中，我將深刻細節，介紹如何用 Airflow 構建 Hive 批處理做業。尤爲是將介紹與 Airflow 做業有關的基礎信息，並經過分區傳感器和運算符等構造切實體驗提取、轉換和加載操做。咱們將一塊兒學着使用數據建模技術，例如星型架構來設計表。最後，我還將介紹一些極爲實用的 ETL 最佳實踐。

更多幹貨內容請關注微信公衆號「AI 前線」，（ID：ai-front）