2011的時候年我以商業智能工程師的身份加入臉書（Facebook），但在13年離開時我的職位卻是數據工程師。這期間我並沒有升職也沒有被調到一個新職位上，我只是意識到我們的工作已經超越了傳統商業智能的範疇，並且我們爲自己創造的這個角色屬於一個全新的領域。
由於我的團隊處在這種轉變的最前沿，我們正在培養新的技能、新的做事風格、開發新工具，並基本放棄了舊有的方法。我們是這個領域的開拓者。我們是數據工程師！
什麼是數據工程？
▼
現在，當數據科學領域正在經歷它的青春期時，數據工程在肯定和定義它自己，同時它也像數據科學的“同胞兄弟”一樣也經歷着類似的事情。數據工程一邊借鑑着數據科學，一邊也從數據科學的對立面去定義它自己，找到它的身份。
就像數據科學家似的，數據工程師也編程。他們善於分析，並且對數據可視化感興趣。但他們也不像數據科學家，數據工程師受到一位更成熟的“父親”– 軟件工程師 – 啓發。數據工程師創造工具、基礎、框架和服務。事實上，相比於數據科學家，數據工程師可以說是更接近於軟件工程師。
聯繫到過去已有的職位，數據工程領域可以被當作是從軟件工程衍生出的，包含了商業智能和數據倉儲的一個超集。同時，這個學科也整合了“大數據”分佈系統相關的特色，以及拓展了的Hadoop生態系統、流處理、大規模計算有關的概念。
在一些還沒有正式數據基礎設施團隊的小型公司裏，數據工程方面的工作也涵蓋了建設和運作數據基礎設施。具體任務類似於建設和運作像Hadoop/Hive/HBase、Spark之類的平臺。注意到在更小的環境裏，人們傾向於使用由亞馬遜、Databricks提供的託管服務，或者從Cloudera、Hortonworks這樣的公司得到技術支持。這樣的小企業本質上是將數據工程轉包給了其他公司。但在更大的環境裏，企業對數據基礎設施團隊的需求會不斷增加，這使得它們更傾向於創建正式的職位來負責這類工作。在那些組織裏，自動化某些數據工程過程的任務一般是由數據工程和數據基礎設施團隊負責。這些團隊通常也會合作解決一些更高層次的問題。
隨着數據工程角色的工程一面在範圍上不斷提升，舊有商業工程的一些方面慢慢變成次要的了。創建並維護產品組合報告和麪板並不是一個數據工程師的主要關注重點了。我們現在有了更好的自助工具，憑藉這些工具，數據科學家和廣義上的“信息工作者”對數據的理解能力正在提高，他們也能自主地處理數據消耗資料。
數據提取、轉換
和加載方式正在改變
▼
我們也觀察到一種普遍的轉變，就是從拖拽ETL（提取、轉換和加載）工具轉向一種更編程化的方式。在一些平臺，如Informatica、IBM Datastage、Cognos、AbInitio或者微軟 SSIS，上面的產品知識在現代的數據工程師之中並不普及。伴隨着對編程或結構驅動的平臺比如Airflow、Oozie、Azkabhan或Luigi的理解，這些產品知識並正在被更一般的軟件工程技術所取代。同時，發展和管理他們自己的職業規劃，對工程師來說也是相當普遍的。
我們可以找到很多理由來解釋爲什麼我們不使用拖放工具來開發複雜的軟件：最終，計算機編碼對軟件來說纔是最佳的抽象和提煉方式。雖然對這個主題的討論超出了本文的範圍，但是我們很容易就能推斷出，同樣的理由也適用於編寫ETL，正如適用於其他任何一款軟件。編碼允許任意水平的抽象，允許以熟悉的方式進行所有邏輯操作，和源代碼管理結合地很好，也易於進行版本控制和衆人合作。在數據處理的歷史上，ETL工具演化成使用圖形界面似乎是走了條彎路。當然，會有其他有趣的博客來討論這個問題。
讓我們重點強調一下，傳統ETL工具做的抽象提煉是偏離目標的。不可否認，我們對數據處理複雜性的提煉、計算和儲存有需要，但我認爲解決的方式絕不是將ETL的程序要素（數據源/目標、集成、過濾……）塑造成一個拖放的樣式。我們需要的對數據的抽象提煉是更高層次的。舉個例子，在現代數據環境裏我們所需要的抽象是在一種A或B測試框架下的實驗的結構：試驗是什麼？試驗的相關處理是什麼？多少比例的使用者是被試者？每個試驗期望去影響的指標有哪些？試驗何時生效？在這個例子裏，我們有一個接收精準、高水平輸入，能運轉複雜統計計算並傳遞計算結果的框架結構。我們期望每輸入一條新試驗條目，都能有一次計算，並且能得到計算結果。值得注意的是，在這個例子中，進行抽象所需的輸入參數和傳統ETL工具提供的是不同的。同時，在拖拽軟件界面裏建立這樣的抽象是很難辦到的。
對現代數據工程師來說，傳統的ETL工具很大程度上已經過時了，因爲邏輯不能被編碼表達。因此，我們需要的抽象不能被這些工具直觀表達出來。當我們已經知道數據工程師的角色主要包括定義ETL，也知道需要新的一套工具和方法論，我們就能斷言這些將迫使這門學科去徹底重構它自己。新的工作棧、新的工具、新的一套約束條件，在很多情況下，也意味着新的一代人。
數據建模正在改變
▼
典型的數據建模技術，比如“星模型（Star Schema）”就是一個傳統的、定義清晰的數據建模手段。這樣的建模手段是爲和數據倉庫相連的分析工作服務的。但今時不同往日了，傳統最佳的數據倉儲手段的地基正在慢慢鬆動。存儲和計算比過去任何時候都要廉價，並且隨着能夠線性擴展的分佈式數據庫的出現，更稀缺的資源是工程時間。
以下是在數據建模技術上觀察到的一些變化：
更進一步的逆規範化：在多個維度上維持代理關鍵字（“surrogate keys”數據庫名詞，用於維度表和事實表的連接）是不容易的，這會使得事實表格不易閱讀。在事實表中使用自然的或人可讀的關鍵字和維度特徵正變得更加普遍，這減少了對昂貴連接的需要。昂貴的連接對分佈式數據庫來說是個沉重的負擔。同時我也注意到，在序列化格式（如Parquet或ORC）或在數據引擎（如Vertica）中的對編碼和壓縮的支持，解決了絕大部分經常和逆規範化聯繫在一起的性能損失的問題。那些系統已經具有自動地爲存儲規整數據的功能。
BLOBS （“binary large object”，二進制大對象）：現代數據庫通過本地類型和功能正在爲BLOB提供越來越大的支持。這爲數據建模者的“劇本”開啓了新“劇情”。並且，這樣的支持也允許事實表在需要的時候一次性存儲多樣的粒度（“grain”，數據庫名詞）。
動態模型：隨着文件存儲日益流行和對BLOB的數據庫支持，映射歸納（MapReduce）技術的出現使得在無須執行DML（“Data Definition Language”，數據庫模式定義語言）的情況下進化數據庫變的越來越容易。這不僅使迭代式地存儲變得更容易，也降低了在建立數據庫之前獲得完全的共識和支持的需求。
有系統地快照維度（爲每個ETL調度週期的維度存儲一個完整的副本，經常用在不同的表格劃分中）作爲控制漸變維度（SCD）的一般方法，已經成爲一種簡單的方式。它不要求工程上的投入，同時，不同於傳統方式，在寫ETL和提取信息的時很容易掌握。再者，爲了追蹤交易那刻的數值而逆正規化維度的特徵到事實表中，也是更加簡便和相對廉價了。回顧過往我們可以看到，複雜的SCD建模技術不是那麼直觀並且不那麼平易近人。
一致性，正如在一致的維度和尺度下，對現代數據環境來說仍舊是極度重要的。但隨着對數據倉儲的需要的快速增加，同時讓更多團隊以及職位投身於這個領域，一致性的問題又變的不那麼急切，多少可以有一些折衷。但是在問題分歧失控的地方，一致性和收斂性可以作爲一種後臺處理而存在。
而且，更一般地來說，以下這種說法優待商榷：伴隨着計算週期的便利和比過去更多的人瞭解數據知識，預先計算並在數據倉庫中存儲結果的需求降低了。舉個例子，你可以有能夠只進行響應式複雜分析的複雜 Spark 任務，但不用爲了成爲佔用數據倉庫的而提前預定時間。
角色&責任
▼
數據倉庫
數據倉庫是滿足查詢和分析的事務處理數據特定結構的拷貝。——Ralph Kimball
數據倉庫是面向主題的、集成的、隨時間變化的、非易變的用於支持管理的決策過程的數據集合。－Bill Inmon
相應得，數據倉庫還是與以前一樣，數據工程師負責數據倉庫的多方面搭建並在其上操縱。數據工程師總是關注於在數據倉庫及其附屬產品。
現代數據倉庫是一個比它歷史上更開放機構平臺，隨時歡迎着數據科學家、分析師和軟件工程師參與它的構建和操作。由於數據單純的過於集中在公司業務上，侷限了管理數據流向的角色。在規模上滿足了機構的數據需求，卻會經常導致基礎設施更加的混亂、易變不夠完善。
數據工程師團隊往往擁有着數據倉庫中最有保障的、高質量的模塊。例如在Airbnb，數據工程師團隊管理着一組‘核心’架構，其中有着定義明確及可度量的服務等級協議、遵守嚴格的命名規則、最高質量的業務元數據和文檔，以及遵循意義明確的最佳實踐的相關管道代碼。
數據工程師團隊通過制定標準、提供最佳案例和數據對象認證流程，充當了一個“卓越中心”的角色。這個團隊逐漸發展，通過帶領教學項目分享他們的核心競爭力，幫助其他團隊成爲數據倉庫更好的參與者。例如，臉書（Facebook）有一個叫做“數據訓練營（data camp）”的項目，Airbnb正在發展一個類似的“數據大學（Data University ）”項目。在這些項目中數據工程師教會人們怎麼樣更專業地操作數據。
數據工程師同時也是數據倉庫的管理員，編目、整理元數據，定義從數據倉庫抽取數據的過程。在一個急速增長，快速發展及輕微混亂的的數據生態環境下，元數據管理和工具化成爲了現在數據平臺的一個至關重要的組建部分。
性能調整和優化
隨着數據變得較之前更具策略化，企業逐漸投入了可觀的預算在數據基礎設施上。這促使數據工程師花費更多的精力在性能調整、數據處理最優化和存儲上。由於這個領域的的預算幾乎不會縮水，性能優化通常來自於在相同數量的資源下取得更多收益，或者是試圖線性化資源使用率和成本上的指數增長。
瞭解數據工程師工作內容的複雜度爆炸性地提高，我們相信，優化他們的工作內容和流程之複雜同樣也是個挑戰。在投入低卻很容易得到高回報的地方，收益遞減規律一般都是適用的。
確切地說，數據工程師的趣味所在是既隨着公司擴建基礎設施的同時，至始至終又都能節約資源。
數據集成
數據集成，通過數據交換整合業務和系統之間的實踐，像他以前一樣都既重要又具有挑戰性。
由於軟件即服務（SaaS）成爲公司運營的新標準方式，跨系統同步化參考數據的需求愈加苛刻。不僅僅軟件即服務（SaaS）需要最新數據來支持各系統功能，我們還經常想要將在系統端產生的數據寫入數據倉庫與其他數據一起用於分析。當然軟件即服務（SaaS）有它自帶的分析產品，但這些自帶產品系統性地缺乏公司其他數據提供的信息，所以往往必須將某些數據撤回。
讓這些軟件即服務（SaaS）產品再定義參考數據卻不集成和共享關鍵字，是一場在所有工作中都應該避免的災難。沒有人想要在兩個不同系統中人工維護兩套員工或客戶列表。更糟糕的是，數據倉庫中加載的人力資源數據，還不能完整匹配。
最糟糕的是，公司執行層經常在沒有真正考慮數據集成挑戰的情況下，和軟件即服務（SaaS）提供者簽訂協議。爲了促進軟件服務的銷售，銷售人員不合理的評估數據集成的工作量，將不計入工作量的、不會被重視的工作留給數據工程師。更別提SaaS接口的設計不完善，不清楚的文檔和所謂的“敏捷”：不提前通知就隨意改變需求。
服務
數據工程師還會做些更高級別的抽象事務，在一些工作場景中提供服務和工具化使數據工程師，數據科學家和分析師可能人工處理的工作自動化。
以下是一些數據工程師和數據基建人員可能提供和操作的服務項：
-
數據獲取：提供高效利用數據庫，裝載日誌，從外部存儲或API獲取數據的相關服務和將這些流程工具化的工具
-
指標計算：設計框架，計算和總結約束條件、增長量和分段等指標。
-
異常檢測：提供自動化數據資料分析，提醒異常事件的發生，或趨勢變化明顯時提出警告。
-
元數據管理：提供相關自動化工具，方便元數據的生成和更替，更易查找到數據倉庫及其關聯的信息。
-
試驗：提供A/B測試和框架試驗。這是數據工程師參與的企業分析的一個關鍵環節
-
儀表檢測：從登陸開始及之後所有相關連的操作都會進行分析，數據工程師專注於確保可以從上游系統捕獲高質量數據。
-
會話：提供能及時理解一系列業務操作的特殊渠道，讓分析師明白用戶行爲。
就像軟件工程師一樣，數據工程師應該不斷的尋找使他們工作自動化的方式，構建能讓他們爬上更復雜階梯的抽象概念。雖然由於環境不同，可自動化的工作流程性質不盡相同，卻都有着自動化的需求。
所需技能
▼
精通SQL：
如果英語是業務的交流工具，那麼SQL就是數據的交流工具。一個不會流利的英語的業務人員能有多大的成就？不管任何技術時代的產生和更替，SQL一直是數據的通用語。數據工程師應該有能用SQL表達任何‘相關子查詢’和窗口函數複雜度的技術能力。對數據工程師來說初始SQL／DML/DDL簡單到根本沒有難度。即使是沒有接觸過SQL的人，他也能讀懂並明白數據庫的執行計劃，瞭解所有步驟，知道程序怎麼被調用，連接算法的不同和執行計劃內的分佈式維度。
數據模型技能：
作爲一個數據工程師，有對實體－關係模型的認知反射，規範化的清晰認識，權衡反規範化的敏銳直覺。數據工程師應該熟悉維度建模及相關概念與術語。
ETL設計：
能夠寫出有效率、有彈性的、“可發展”的ETL任務是一個關鍵。我計劃在下一博客中深入這個話題。
架構項目：
就如任何一個領域的專家的專業技能一樣，數據工程師需要一個較高層次的綜括，對大多數的工具，平臺，庫，和其他供他支配的資源的瞭解。認識到不同類型的數據庫、計算引擎、流處理器、消息隊列、工作流協調器、序列化格式及其他相關技術的屬性、用例、微妙之處。在設計解決方案的時候，他應該有能力選擇即將要使用的技術，並有一個構想去協調怎麼使他們一起更好地工作。
總體來說
▼
過去在硅谷Airbnb，臉書和雅虎工作的五年裏，跟來自谷歌、Netflix、亞馬遜，優步、Lyft等幾十個不同規模大小，不同類型的公司的數據團隊交談過。我觀察到越來越多的人對數據工程師的職責範圍是什麼達成共識，覺得有必要分享我的感悟。
我希望這篇文章能夠成爲類似數據工程師的一個宣言，我也希望拋磚引玉，使在這個相關領域中，從事這類工作的人之間能產生更多的火花。