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 最佳實踐。

如果你喜歡我們的內容，記得給我們「留言」和「點贊」，給編輯鼓勵一下！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！