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，也知道需要新的一套工具和方法論，我們就能斷言這些將迫使這門學科去徹底重構它自己。新的工作棧、新的工具、新的一套約束條件，在很多情況下，也意味著新的一代人。
資料建模正在改變
典型的資料建模技術，比如“星模型（Star Schema）”就是一個傳統的、定義清晰的資料建模手段。這樣的建模手段是為和資料倉儲相連的分析工作服務的。但今時不同往日了，傳統最佳的資料倉儲手段的地基正在慢慢鬆動。儲存和計算比過去任何時候都要廉價，並且隨著能夠線性擴充套件的分散式資料庫的出現，更稀缺的資源是工程時間。
以下是在資料建模技術上觀察到的一些變化：
更進一步的逆規範化：在多個維度上維持代理關鍵字（“surrogate keys”資料庫名詞，用於維度表和事實表的連線）是不容易的，這會使得事實表格不易閱讀。在事實表中使用自然的或人可讀的關鍵字和維度特徵正變得更加普遍，這減少了對昂貴連線的需要。昂貴的連線對分散式資料庫來說是個沉重的負擔。同時我也注意到，在序列化格式（如Parquet或ORC）或在資料引擎（如Vertica）中的對編碼和壓縮的支援，解決了絕大部分經常和逆規範化聯絡在一起的效能損失的問題。那些系統已經具有自動地為儲存規整資料的功能。
BLOBS （“binary large object”，二進位制大物件）：現代資料庫通過本地型別和功能正在為BLOB提供越來越大的支援。這為資料建模者的“劇本”開啟了新“劇情”。並且，這樣的支援也允許事實表在需要的時候一次性儲存多樣的粒度（“grain”，資料庫名詞）。
有系統地快照維度（為每個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等幾十個不同規模大小，不同型別的公司的資料團隊交談過。我觀察到越來越多的人對資料工程師的職責範圍是什麼達成共識，覺得有必要分享我的感悟。
我希望這篇文章能夠成為類似資料工程師的一個宣言，我也希望拋磚引玉，使在這個相關領域中，從事這類工作的人之間能產生更多的火花。
作者 | Maxime Beauchemin
編譯團隊 | Yawei Xia,邱猛，賴小娟，張禮俊
注：本稿件摘自大資料文摘