更多幹貨內容請關注微信公眾號“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 代表“提取、轉換和載入”，這三個概念性的步驟決定了大部分資料管道的設計方式和構造，可以充當將原始資料轉換為可分析資料的藍圖。為了更精確地理解這個流程，我從 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 的過程中可能會遇到的通用問題，並開發了各種框架幫助我們妥善解決這些問題。
在資料批處理的世界中，目前存在好幾個開源的競品。例如 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 將成為以後新一代創業公司執行批處理任務時的標準。
如上文所述，不同企業在構建 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）