本文作者以自己在 Airbnb、Facebook、Yahoo 做數據工程師的經驗告訴大家：數據工程師的主要職責；當代數據工程的範疇；以及要做數據工程師都需要哪些技能。

2011年，我作為一名商業智能工程師加入 Facebook。到了 2013 年離開的時候，我的職稱是數據工程師。

獲得這個職稱，並不是因為我被升職或是分配。而是 Facebook 覺得我們的工作已經超越了典型的商業智能。我們為自己創造的這個新角色是個全新的學科。

我的團隊處在這場變革的前線。我們一直在開發新的技能呢、新的處理方式、新的工具，而且通常與傳統方式背道而馳。

我們是先頭部隊！我們是數據工程師！

數據工程是什麼？

數據科學作為一個學科，已度過其自我肯定和自我定義的青春期。而處在同期的數據工程，是個年齡稍小的弟弟，但是也在度過相似的階段。數據工程學科以其兄長為榜樣，但也在相反的領域定義自己，並找尋屬於自已的身份。

數據工程師也像數據科學家一樣要寫代碼。數據科學家有很好的分析能力，並且對數據可視化很感興趣。與數據科學家不同，而且受啟發於我們更顯成熟的父學科——軟件工程，數據工程師要構建工具、基礎設施、框架和服務。事實上可以證明，相比數據科學，數據工程更接近軟件工程。

如果討論與既有職責的關係，數據工程領域可以認為是商業智能和數據倉庫的超集，而且更多的元素是從軟件工程得來的。這個學科也囊括了所謂的“大數據”分佈式系統的相關領域內容，以及廣泛的Hadoop生態圈、流式處理和大規模計算的相關概念。

在還沒有正規化的數據基礎架構團隊的小公司裡，數據工程的職責也會涵蓋搭建和維護組織數據基礎架構的工作任務。這包括搭建和維護像 Hadoop/Hive/HBase、Spark 平臺之類的活。

在小一些的環境裡，人們傾向使用 Amazon 或 Databricks之類的託管服務，或者從 Cloudera 或 Hortonworks 之類的廠商獲取支持，這本質上就是將數據工程的職責外包給了其他公司。

在大一些的環境裡，由於對數據基礎架構團隊的需求越來越高時，組織更傾向於專門指定或者開設一個正式的角色來處理這些工作。在這些組織中，這個把數據工程流程自動化的職責，同時落到了數據工程團隊和數據基礎架構團隊手中，而且兩個團隊合作解決高級問題也是很常見的。

雖然這個角色在工程方面的範圍在擴大，但其他原本作為商業工程角色的應關注的方面，卻變得越來越次要。比如像構建和維護大量的報表和儀表板，已不是一個數據工程師的主要關注領域。

我們現在有了更好的自服務工具，可以讓分析師、數據科學家和廣義的“信息工作者”變得更精通數據，可以獨自應付數據的使用。

ETL 在變化

我們也觀察到從拖拽式 ETL (Extract Transform and Load) 工具到一種更加可編程化的方式的大體轉變。像 Informatica、IBM Datastage、Cognos、AbInitio 和 Microsoft SSIS 之類的平臺技術掌握在現在的數據工程師中並不常見，取而代之的是更通用的軟件工程技能，和對編程或配置驅動的平臺技術的掌握，像 Airflow、Oozie、Azkabhan 或 Luigi。工程師開發和維護自己的任務編排器/調度器也是很常見的。

有很多不使用拖拽工具開發複雜軟件的理由：但最重要的是代碼才是對軟件最好的抽象。討論這個話題超出了本文的範圍，但是也很容易推導出為什麼要用代碼寫 ETL，原因和寫其他軟件是一樣的。代碼允許任意程度的抽象，允許使用熟悉的方法進行所有邏輯處理，可以很好地和源控制集成，也易於版本管理和協作。事實上 ETL 工具暴露圖形接口給用戶像是數據處理發展史上的一個迂迴，這個話題都可再單獨寫成一篇有意思的博客了。

讓我們強調下這個事實，傳統 ETL 工具所暴露出的這種抽象是達不到目的的。我們當然需要將數據處理、計算以及存儲進行抽象，但我覺得解決的方法並不是將 ETL 元語（比如源/目標、聚合、過濾條件）展現為一種拖拽風格，需要的是一種更高級的抽象。

舉例說明，在現代數據環境中做抽象， A/B 測試框架的試驗設置：整個試驗是什麼樣的？相關的處理操作是什麼？應該暴露給多少比例的用戶？預期每個試驗會影響哪些度量？試驗什麼時候生效？在這個例子中，我們有一個需要接收精確、高級輸入，需要進行復雜統計學運算以及得出計算結果的框架。我們期望如果引入一個新的試驗，就可以相應進行額外的運算並得到額外的結果。在這個例子中，我們要注意的重點是，在這個抽象中輸入變量並不是由傳統 ETL 工具給出的，而且在拖拽界面中構建這樣一個抽象也毫無操作性可言。

對於現代數據工程師而言，傳統的 ETL 工具大多數都已過時了，因為無法用代碼表達邏輯。因此所需要的抽象也就不能用這些工具直觀表達。現在大家知道了數據工程師的職責包括了設計大量的 ETL，並且知道了一套全新工具和方法論是必需的，可以說這迫使這個學科從頭重建。數據工程師需要新的技術棧、新的工具、一套新的約束，並且很多時候，是新的一代人。

數據建模在改變

典型的數據建模技術（比如星型模型），曾經定義了我們典型地通過數據倉庫為分析工作進行數據建模的方法，但現在已不像之前那樣重要。傳統的數據倉庫最佳實踐已經改變。存儲和計算要比以前便宜，而且隨著可線性擴展的分佈式數據庫的出現，工程時間成了更緊缺的資源。

這裡列舉一些數據建模技術方面的變化：

• 進一步反範式化：在維度中維護代理鍵這件事可能很棘手，而且這使得事實表的可讀性變差。而在事實表中使用自然的讓人可讀的鍵和維度屬性變得越來越普遍，省去了在分佈式數據庫中大量繁重的 join 操作。同時要注意像 Parquet 或者 ORC 之類的序列化格式，或者 Vertica 之類的數據庫引擎，都提供了編碼和壓縮的支持，這可以減少通常由於使用反範式化所帶來的性能損失。那些系統本身具備為存儲進行範式化的能力。

• blobs（二進制大對象）：現代數據庫已經逐漸通過本地類型和方法支持 blobs。這讓數據建模師學會了新的招式，並且可以讓事實表根據需要一次存儲多個粒度的數據。

• 動態模式：由於 MapReduce 的出現，以及文檔存儲越來越流行，和 blobs 在數據庫中的支持，不需要執行 DML（數據操作語言）就改進數據庫模式變得更容易。這使得以迭代方式去建數據倉庫更加容易，也免得開發前需要達成完全一致和認同。

• 系統化維度快照（在每個 ETL 調度週期為維度存儲一個全量副本，通常存儲在獨立的表分區）作為一種處理緩慢變化維（SCD, slowly changing dimension）的通用方法，只要很少的工作量，是一種簡單通用的方式。而且這種方式不像經典方式，在寫 ETL 或者類似的查詢時可以很容易掌握。將維度屬性反範式化到事實表，在事務發生時就直接記錄維度屬性值，，也是一種容易並且相對廉價的方式。回想一下，複雜的 SCD 建模技術其實是不直觀的，而且降低了可訪問性。

• 一致性：一致性維度和度量在現在的數據環境中，依然是極為重要的。但是隨著數據倉庫需求的快速變化，隨著更多的團隊和角色被邀請到這項工作中貢獻力量，一致性就少了一分必要性，更多的是一種權衡。當分歧的痛點變得無法控制，其背後也會產生一致和趨同。

角色和任務

數據倉庫

“數據倉庫是一個專門為查詢和分析而構造的事務數據副本。” — Ralph Kimball

數據倉庫是一個面向主題的、集成的、時變的、非易失的集合，用來支持管理層的決策制定過程。 — Bill Inmon

數據倉庫依然像之前一樣重要，數據工程師負責了很多方面的數據倉庫建設和運維的工作。數據工程師的焦點就是數據倉庫和相關工作。

現代數據倉庫應該是比之前更加開放的設施，歡迎數據科學家、分析師和軟件工程師去參與到建設和維護中。如果企業活動限制了什麼角色才能夠管理數據流程，那數據顯然就過於中心化了。雖然這允許隨著組織的數據需求而相應擴展，但是經常導致形成了更混亂的、走形的、不完善的基礎設施。

數據工程團隊通常會擁有數據倉庫中幾片有保證的、高質量的區域。比如在 Airbnb，有一組“核心”模式（schema）由數據工程團隊管理，這裡有清晰定義和度量的服務等級協議（SLA，service level agreement），嚴格遵守命名約定，並且相關的流水線代碼遵循一套最佳實踐。

為數據對象制定標準、最佳實踐和認證流程的“卓越中心”，這也成為數據工程團隊的職責之一。團隊可以進而去參與或領導一個項目來分享其核心能力，以幫助其他團隊成為更佳的數據倉庫公民。比如，Facebook 有一個“數據夏令營”的培訓項目，Airbnb 正在開發一個類似的“數據大學”的項目，數據工程師在這裡主持會議來教大家如何熟練使用數據。

數據工程師也是數據倉庫的“圖書管理員”，編目和組織元數據，定義從倉庫歸檔或提取數據的流程。在一個快速生長、迅速演變、輕度混亂的數據環境，元數據管理和元數據工具成為一個現代數據平臺的關鍵組件。

性能調整和優化

隨著數據變得比以前更加具有戰略意義，企業為他們的數據基礎設施建設所提高的預算確實令人印象深刻。這樣，數據工程師把時間花在數據處理和存儲的性能調整和優化上也就更加合理。由於在方面的預算極少縮減，優化往往從在相同的資源下完成更多事情的角度出發，或者是從試圖使資源利用和開銷的指數級增長線性化的角度。

知道了數據工程棧發展的複雜性正在暴增，我們可以設想優化這個棧和流程的複雜度也同樣充滿挑戰。可能很容易通過很小的努力獲得巨大成功的地方，收益遞減法則通常是適用的。

建設可以隨企業規模增長的基礎設施（或在其上建設），並時刻保持資源意識，無疑是對數據工程師有好處的。

數據集成

數據集成，是通過數據交換來集成業務和系統其背後的實際操作，它和以前同樣重要，也和以前同樣充滿挑戰。由於軟件即服務（SaaS, Software as a Service）逐漸成為企業運營的新標準方式，跨越這些系統來同步相關數據就成為更加關鍵的需求了。不僅SaaS服務本身需要最新的數據來運行，我們通常也想把產生在SaaS側的數據拿到數據倉庫，來和我們其他數據一起進行分析。當然SaaS經常會提供它們自己的分析，但是沒有系統地支持企業中其餘數據所能提供的視角，通常得把這些數據拉取回來。

不集成和共享通用的主鍵，就讓 SaaS 服務重新定義參考數據，這簡直是場災難，應該極力避免。誰也不想人為地在兩個不同的系統中維護兩份僱員和顧客列表。最糟糕的是，必須要在把他們的 HR 數據拉回倉庫時做模糊匹配。

最壞的情況，企業高管經常會在不實際考慮數據集成難度的情況下和 SaaS 提供商簽約。提供商特意計劃好淡化這些集成任務，以促進他們的銷售，然後讓數據工程師受困於去做充滿疑問的、不被重視的工作。更不用說事實上典型的 SaaS API 經常設計不合理、文檔不清晰，並且是“敏捷”的：就是說你可以認為它們會在不做通知的情況下改版。

服務

數據工程師工作在一種更高層級的抽象中，就是說在某些場景下要提供服務和工具來使數據工程師、數據科學家或者分析師要手動來完成的工作自動化。

這裡列舉數據工程師和數據基礎架構工程師可能構建和維護的一小部分服務。

• 數據攝取：圍繞“爬取”數據庫、載入日誌、從外部存儲和API獲取數據的服務和工具

• 指標計算：計算和彙總相關參與指標、增長指標或細分指標量的框架

• 異常檢測：使數據處理自動化，以便當異常事件發生或趨勢明顯變化時警示相關人員

• 元數據管理：可以生成和消費元數據，並方便在數據倉庫中查找信息的相關工具。

• 實驗：A/B測試和實驗框架通常是一個重要的企業分析，並帶有一個關鍵的數據工程模塊。

• 檢測儀：從日誌時間和相關屬性到那些事件，數據工程師

• 會話：為幫助分析師理解用戶行為，為理解時間行為序列專門設計的流水線。

就像軟件工程師一樣，數據工程師必須不斷關注工作自動化、構建抽象來使他們能應對重重困難。雖然環境不同，可自動化的工作的性質不同，但自動化的需求在各個環境是普遍存在的。

技能要求

精通SQL：如果說英語是商業語言，那 SQL 就是數據語言。如果英語都說不好的話，作為一個商務人士又能做的怎麼樣呢？雖然一代又一代技術老去和退出舞臺，但是 SQL 一直作為數據的通用語言頑強地活著。數據工程師應該能夠使用 SQL 表達各種複雜邏輯，比如使用“關聯子查詢”和窗口函數。SQL/DML/DDL 原語已經足夠簡單，對於數據工程師來說應該完全掌握了。除了SQL的聲明特性，數據工程師還應該有能力理解數據庫的執行計劃，並明白每個步驟是什麼，明白索引是如何工作的，明白不同的 join 算法，以及執行計劃的分佈維度（distributed dimension）。

數據建模技術：對於數據工程師來說，應該對實體/關係模型形成一種認知反射（cognitive reflex），並且對範式化有清晰的認識，同時對權衡反範式化有敏銳的直覺。數據工程師應該熟悉維度建模和相關概念和用語。

ETL 設計：編寫高效、可擴展的、“可演化”的 ETL 才是關鍵。我正計劃在接下來的博文中具體討論這個主題。

架構規劃：就像任何專業領域的專家，數據工程師需要對大多數工具、平臺、庫和其他可以運用的資源有一個較高層級的理解。比如不同種類的數據庫、計算引擎、流處理器、消息隊列、工作流編排器、序列化格式和其他相關技術背後的屬性、用例和微妙之處。設計解決方案時，數據工程師必須能夠對使用哪種技術做出好的選擇，能夠想象到如何使它們協同工作。

總而言之

通過過去 5 年在硅谷 Airbnb、Facebook、Yahoo! 的工作，以及和像 Google、Netflix、Amazon、Uber、Lyft 等幾十個各種體量的公司的各種類型的數據團隊的豐富交流，我發現大家對於“數據工程師”的發展成什麼樣，看法越來越趨於一致，而且我覺得有必要分享一些我的發現。

我希望這篇文章可作為某種意義上的數據工程宣言，並且我希望可以在從事相關領域的社區中激起迴應。

End.