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任務是一個關鍵。我計劃在下一部落格中深入這個話題。
架構項目：
就如任何一個領域的專家的專業技能一樣，資料工程師需要一個較高層次的綜括，對大多數的工具，平台，庫，和其他供他支配的資源的了解。認識到不同類型的資料庫、計算引擎、流處理器、消息隊列、工作流協調器、序列化格式及其他相關技術的屬性、用例、微妙之處。在設計解決方案的時候，他應該有能力選擇即将要使用的技術，并有一個構想去協調怎麼使他們一起更好地工作。
原文釋出時間為：2017-02-09
本文來自雲栖社群合作夥伴“大資料文摘”，了解相關資訊可以關注“bigdatadigest”微信公衆号