2011的時候年我以商業(yè)智能工程師的身份加入臉書（Facebook），但在13年離開時我的職位卻是數(shù)據(jù)工程師。這期間我并沒有升職也沒有被調(diào)到一個新職位上，我只是意識到我們的工作已經(jīng)超越了傳統(tǒng)商業(yè)智能的范疇，并且我們?yōu)樽约簞?chuàng)造的這個角色屬于一個全新的領(lǐng)域。

由于我的團隊處在這種轉(zhuǎn)變的最前沿，我們正在培養(yǎng)新的技能、新的做事風格、開發(fā)新工具，并基本放棄了舊有的方法。我們是這個領(lǐng)域的開拓者。我們是數(shù)據(jù)工程師！

什么是數(shù)據(jù)工程？

▼

現(xiàn)在，當數(shù)據(jù)科學領(lǐng)域正在經(jīng)歷它的青春期時，數(shù)據(jù)工程在肯定和定義它自己，同時它也像數(shù)據(jù)科學的“同胞兄弟”一樣也經(jīng)歷著類似的事情。數(shù)據(jù)工程一邊借鑒著數(shù)據(jù)科學，一邊也從數(shù)據(jù)科學的對立面去定義它自己，找到它的身份。

就像數(shù)據(jù)科學家似的，數(shù)據(jù)工程師也編程。他們善于分析，并且對數(shù)據(jù)可視化感興趣。但他們也不像數(shù)據(jù)科學家，數(shù)據(jù)工程師受到一位更成熟的“父親”– 軟件工程師 – 啟發(fā)。數(shù)據(jù)工程師創(chuàng)造工具、基礎(chǔ)、框架和服務。事實上，相比于數(shù)據(jù)科學家，數(shù)據(jù)工程師可以說是更接近于軟件工程師。

聯(lián)系到過去已有的職位，數(shù)據(jù)工程領(lǐng)域可以被當作是從軟件工程衍生出的，包含了商業(yè)智能和數(shù)據(jù)倉儲的一個超集。同時，這個學科也整合了“大數(shù)據(jù)”分布系統(tǒng)相關(guān)的特色，以及拓展了的Hadoop生態(tài)系統(tǒng)、流處理、大規(guī)模計算有關(guān)的概念。

在一些還沒有正式數(shù)據(jù)基礎(chǔ)設施團隊的小型公司里，數(shù)據(jù)工程方面的工作也涵蓋了建設和運作數(shù)據(jù)基礎(chǔ)設施。具體任務類似于建設和運作像Hadoop/Hive/HBase、Spark之類的平臺。注意到在更小的環(huán)境里，人們傾向于使用由亞馬遜、Databricks提供的托管服務，或者從Cloudera、Hortonworks這樣的公司得到技術(shù)支持。這樣的小企業(yè)本質(zhì)上是將數(shù)據(jù)工程轉(zhuǎn)包給了其他公司。但在更大的環(huán)境里，企業(yè)對數(shù)據(jù)基礎(chǔ)設施團隊的需求會不斷增加，這使得它們更傾向于創(chuàng)建正式的職位來負責這類工作。在那些組織里，自動化某些數(shù)據(jù)工程過程的任務一般是由數(shù)據(jù)工程和數(shù)據(jù)基礎(chǔ)設施團隊負責。這些團隊通常也會合作解決一些更高層次的問題。

隨著數(shù)據(jù)工程角色的工程一面在范圍上不斷提升，舊有商業(yè)工程的一些方面慢慢變成次要的了。創(chuàng)建并維護產(chǎn)品組合報告和面板并不是一個數(shù)據(jù)工程師的主要關(guān)注重點了。我們現(xiàn)在有了更好的自助工具，憑借這些工具，數(shù)據(jù)科學家和廣義上的“信息工作者”對數(shù)據(jù)的理解能力正在提高，他們也能自主地處理數(shù)據(jù)消耗資料。

數(shù)據(jù)提取、轉(zhuǎn)換

和加載方式正在改變

▼

我們也觀察到一種普遍的轉(zhuǎn)變，就是從拖拽ETL（提取、轉(zhuǎn)換和加載）工具轉(zhuǎn)向一種更編程化的方式。在一些平臺，如Informatica、IBM Datastage、Cognos、AbInitio或者微軟 SSIS，上面的產(chǎn)品知識在現(xiàn)代的數(shù)據(jù)工程師之中并不普及。伴隨著對編程或結(jié)構(gòu)驅(qū)動的平臺比如Airflow、Oozie、Azkabhan或Luigi的理解，這些產(chǎn)品知識并正在被更一般的軟件工程技術(shù)所取代。同時，發(fā)展和管理他們自己的職業(yè)規(guī)劃，對工程師來說也是相當普遍的。

我們可以找到很多理由來解釋為什么我們不使用拖放工具來開發(fā)復雜的軟件：最終，計算機編碼對軟件來說才是最佳的抽象和提煉方式。雖然對這個主題的討論超出了本文的范圍，但是我們很容易就能推斷出，同樣的理由也適用于編寫ETL，正如適用于其他任何一款軟件。編碼允許任意水平的抽象，允許以熟悉的方式進行所有邏輯操作，和源代碼管理結(jié)合地很好，也易于進行版本控制和眾人合作。在數(shù)據(jù)處理的歷史上，ETL工具演化成使用圖形界面似乎是走了條彎路。當然，會有其他有趣的博客來討論這個問題。

讓我們重點強調(diào)一下，傳統(tǒng)ETL工具做的抽象提煉是偏離目標的。不可否認，我們對數(shù)據(jù)處理復雜性的提煉、計算和儲存有需要，但我認為解決的方式絕不是將ETL的程序要素（數(shù)據(jù)源/目標、集成、過濾……）塑造成一個拖放的樣式。我們需要的對數(shù)據(jù)的抽象提煉是更高層次的。舉個例子，在現(xiàn)代數(shù)據(jù)環(huán)境里我們所需要的抽象是在一種A或B測試框架下的實驗的結(jié)構(gòu)：試驗是什么？試驗的相關(guān)處理是什么？多少比例的使用者是被試者？每個試驗期望去影響的指標有哪些？試驗何時生效？在這個例子里，我們有一個接收精準、高水平輸入，能運轉(zhuǎn)復雜統(tǒng)計計算并傳遞計算結(jié)果的框架結(jié)構(gòu)。我們期望每輸入一條新試驗條目，都能有一次計算，并且能得到計算結(jié)果。值得注意的是，在這個例子中，進行抽象所需的輸入?yún)?shù)和傳統(tǒng)ETL工具提供的是不同的。同時，在拖拽軟件界面里建立這樣的抽象是很難辦到的。

對現(xiàn)代數(shù)據(jù)工程師來說，傳統(tǒng)的ETL工具很大程度上已經(jīng)過時了，因為邏輯不能被編碼表達。因此，我們需要的抽象不能被這些工具直觀表達出來。當我們已經(jīng)知道數(shù)據(jù)工程師的角色主要包括定義ETL，也知道需要新的一套工具和方法論，我們就能斷言這些將迫使這門學科去徹底重構(gòu)它自己。新的工作棧、新的工具、新的一套約束條件，在很多情況下，也意味著新的一代人。

數(shù)據(jù)建模正在改變

▼

典型的數(shù)據(jù)建模技術(shù)，比如“星模型（Star Schema）”就是一個傳統(tǒng)的、定義清晰的數(shù)據(jù)建模手段。這樣的建模手段是為和數(shù)據(jù)倉庫相連的分析工作服務的。但今時不同往日了，傳統(tǒng)最佳的數(shù)據(jù)倉儲手段的地基正在慢慢松動。存儲和計算比過去任何時候都要廉價，并且隨著能夠線性擴展的分布式數(shù)據(jù)庫的出現(xiàn)，更稀缺的資源是工程時間。

以下是在數(shù)據(jù)建模技術(shù)上觀察到的一些變化：

更進一步的逆規(guī)范化：在多個維度上維持代理關(guān)鍵字（“surrogate keys”數(shù)據(jù)庫名詞，用于維度表和事實表的連接）是不容易的，這會使得事實表格不易閱讀。在事實表中使用自然的或人可讀的關(guān)鍵字和維度特征正變得更加普遍，這減少了對昂貴連接的需要。昂貴的連接對分布式數(shù)據(jù)庫來說是個沉重的負擔。同時我也注意到，在序列化格式（如Parquet或ORC）或在數(shù)據(jù)引擎（如Vertica）中的對編碼和壓縮的支持，解決了絕大部分經(jīng)常和逆規(guī)范化聯(lián)系在一起的性能損失的問題。那些系統(tǒng)已經(jīng)具有自動地為存儲規(guī)整數(shù)據(jù)的功能。

BLOBS （“binary large object”，二進制大對象）：現(xiàn)代數(shù)據(jù)庫通過本地類型和功能正在為BLOB提供越來越大的支持。這為數(shù)據(jù)建模者的“劇本”開啟了新“劇情”。并且，這樣的支持也允許事實表在需要的時候一次性存儲多樣的粒度（“grain”，數(shù)據(jù)庫名詞）。

動態(tài)模型：隨著文件存儲日益流行和對BLOB的數(shù)據(jù)庫支持，映射歸納（MapReduce）技術(shù)的出現(xiàn)使得在無須執(zhí)行DML（“Data Definition Language”，數(shù)據(jù)庫模式定義語言）的情況下進化數(shù)據(jù)庫變的越來越容易。這不僅使迭代式地存儲變得更容易，也降低了在建立數(shù)據(jù)庫之前獲得完全的共識和支持的需求。

有系統(tǒng)地快照維度（為每個ETL調(diào)度周期的維度存儲一個完整的副本，經(jīng)常用在不同的表格劃分中）作為控制漸變維度（SCD）的一般方法，已經(jīng)成為一種簡單的方式。它不要求工程上的投入，同時，不同于傳統(tǒng)方式，在寫ETL和提取信息的時很容易掌握。再者，為了追蹤交易那刻的數(shù)值而逆正規(guī)化維度的特征到事實表中，也是更加簡便和相對廉價了?；仡欉^往我們可以看到，復雜的SCD建模技術(shù)不是那么直觀并且不那么平易近人。

一致性，正如在一致的維度和尺度下，對現(xiàn)代數(shù)據(jù)環(huán)境來說仍舊是極度重要的。但隨著對數(shù)據(jù)倉儲的需要的快速增加，同時讓更多團隊以及職位投身于這個領(lǐng)域，一致性的問題又變的不那么急切，多少可以有一些折衷。但是在問題分歧失控的地方，一致性和收斂性可以作為一種后臺處理而存在。

而且，更一般地來說，以下這種說法優(yōu)待商榷：伴隨著計算周期的便利和比過去更多的人了解數(shù)據(jù)知識，預先計算并在數(shù)據(jù)倉庫中存儲結(jié)果的需求降低了。舉個例子，你可以有能夠只進行響應式復雜分析的復雜 Spark 任務，但不用為了成為占用數(shù)據(jù)倉庫的而提前預定時間。

角色&責任

▼

數(shù)據(jù)倉庫

數(shù)據(jù)倉庫是滿足查詢和分析的事務處理數(shù)據(jù)特定結(jié)構(gòu)的拷貝。——Ralph Kimball

數(shù)據(jù)倉庫是面向主題的、集成的、隨時間變化的、非易變的用于支持管理的決策過程的數(shù)據(jù)集合。－Bill Inmon

相應得，數(shù)據(jù)倉庫還是與以前一樣，數(shù)據(jù)工程師負責數(shù)據(jù)倉庫的多方面搭建并在其上操縱。數(shù)據(jù)工程師總是關(guān)注于在數(shù)據(jù)倉庫及其附屬產(chǎn)品。

現(xiàn)代數(shù)據(jù)倉庫是一個比它歷史上更開放機構(gòu)平臺，隨時歡迎著數(shù)據(jù)科學家、分析師和軟件工程師參與它的構(gòu)建和操作。由于數(shù)據(jù)單純的過于集中在公司業(yè)務上，局限了管理數(shù)據(jù)流向的角色。在規(guī)模上滿足了機構(gòu)的數(shù)據(jù)需求，卻會經(jīng)常導致基礎(chǔ)設施更加的混亂、易變不夠完善。

數(shù)據(jù)工程師團隊往往擁有著數(shù)據(jù)倉庫中最有保障的、高質(zhì)量的模塊。例如在Airbnb，數(shù)據(jù)工程師團隊管理著一組‘核心’架構(gòu)，其中有著定義明確及可度量的服務等級協(xié)議、遵守嚴格的命名規(guī)則、最高質(zhì)量的業(yè)務元數(shù)據(jù)和文檔，以及遵循意義明確的最佳實踐的相關(guān)管道代碼。

數(shù)據(jù)工程師團隊通過制定標準、提供最佳案例和數(shù)據(jù)對象認證流程，充當了一個“卓越中心”的角色。這個團隊逐漸發(fā)展，通過帶領(lǐng)教學項目分享他們的核心競爭力，幫助其他團隊成為數(shù)據(jù)倉庫更好的參與者。例如，臉書（Facebook）有一個叫做“數(shù)據(jù)訓練營（data camp）”的項目，Airbnb正在發(fā)展一個類似的“數(shù)據(jù)大學（Data University ）”項目。在這些項目中數(shù)據(jù)工程師教會人們怎么樣更專業(yè)地操作數(shù)據(jù)。

數(shù)據(jù)工程師同時也是數(shù)據(jù)倉庫的管理員，編目、整理元數(shù)據(jù)，定義從數(shù)據(jù)倉庫抽取數(shù)據(jù)的過程。在一個急速增長，快速發(fā)展及輕微混亂的的數(shù)據(jù)生態(tài)環(huán)境下，元數(shù)據(jù)管理和工具化成為了現(xiàn)在數(shù)據(jù)平臺的一個至關(guān)重要的組建部分。

性能調(diào)整和優(yōu)化

隨著數(shù)據(jù)變得較之前更具策略化，企業(yè)逐漸投入了可觀的預算在數(shù)據(jù)基礎(chǔ)設施上。這促使數(shù)據(jù)工程師花費更多的精力在性能調(diào)整、數(shù)據(jù)處理最優(yōu)化和存儲上。由于這個領(lǐng)域的的預算幾乎不會縮水，性能優(yōu)化通常來自于在相同數(shù)量的資源下取得更多收益，或者是試圖線性化資源使用率和成本上的指數(shù)增長。

了解數(shù)據(jù)工程師工作內(nèi)容的復雜度爆炸性地提高，我們相信，優(yōu)化他們的工作內(nèi)容和流程之復雜同樣也是個挑戰(zhàn)。在投入低卻很容易得到高回報的地方，收益遞減規(guī)律一般都是適用的。

確切地說，數(shù)據(jù)工程師的趣味所在是既隨著公司擴建基礎(chǔ)設施的同時，至始至終又都能節(jié)約資源。

數(shù)據(jù)集成

數(shù)據(jù)集成，通過數(shù)據(jù)交換整合業(yè)務和系統(tǒng)之間的實踐，像他以前一樣都既重要又具有挑戰(zhàn)性。

由于軟件即服務（SaaS）成為公司運營的新標準方式，跨系統(tǒng)同步化參考數(shù)據(jù)的需求愈加苛刻。不僅僅軟件即服務（SaaS）需要最新數(shù)據(jù)來支持各系統(tǒng)功能，我們還經(jīng)常想要將在系統(tǒng)端產(chǎn)生的數(shù)據(jù)寫入數(shù)據(jù)倉庫與其他數(shù)據(jù)一起用于分析。當然軟件即服務（SaaS）有它自帶的分析產(chǎn)品，但這些自帶產(chǎn)品系統(tǒng)性地缺乏公司其他數(shù)據(jù)提供的信息，所以往往必須將某些數(shù)據(jù)撤回。

讓這些軟件即服務（SaaS）產(chǎn)品再定義參考數(shù)據(jù)卻不集成和共享關(guān)鍵字，是一場在所有工作中都應該避免的災難。沒有人想要在兩個不同系統(tǒng)中人工維護兩套員工或客戶列表。更糟糕的是，數(shù)據(jù)倉庫中加載的人力資源數(shù)據(jù)，還不能完整匹配。

最糟糕的是，公司執(zhí)行層經(jīng)常在沒有真正考慮數(shù)據(jù)集成挑戰(zhàn)的情況下，和軟件即服務（SaaS）提供者簽訂協(xié)議。為了促進軟件服務的銷售，銷售人員不合理的評估數(shù)據(jù)集成的工作量，將不計入工作量的、不會被重視的工作留給數(shù)據(jù)工程師。更別提SaaS接口的設計不完善，不清楚的文檔和所謂的“敏捷”：不提前通知就隨意改變需求。

服務

數(shù)據(jù)工程師還會做些更高級別的抽象事務，在一些工作場景中提供服務和工具化使數(shù)據(jù)工程師，數(shù)據(jù)科學家和分析師可能人工處理的工作自動化。

以下是一些數(shù)據(jù)工程師和數(shù)據(jù)基建人員可能提供和操作的服務項：

數(shù)據(jù)獲?。禾峁└咝Ю脭?shù)據(jù)庫，裝載日志，從外部存儲或API獲取數(shù)據(jù)的相關(guān)服務和將這些流程工具化的工具

指標計算：設計框架，計算和總結(jié)約束條件、增長量和分段等指標。

異常檢測：提供自動化數(shù)據(jù)資料分析，提醒異常事件的發(fā)生，或趨勢變化明顯時提出警告。

元數(shù)據(jù)管理：提供相關(guān)自動化工具，方便元數(shù)據(jù)的生成和更替，更易查找到數(shù)據(jù)倉庫及其關(guān)聯(lián)的信息。

試驗：提供A/B測試和框架試驗。這是數(shù)據(jù)工程師參與的企業(yè)分析的一個關(guān)鍵環(huán)節(jié)

儀表檢測：從登陸開始及之后所有相關(guān)連的操作都會進行分析，數(shù)據(jù)工程師專注于確?？梢詮纳嫌蜗到y(tǒng)捕獲高質(zhì)量數(shù)據(jù)。

會話：提供能及時理解一系列業(yè)務操作的特殊渠道，讓分析師明白用戶行為。

就像軟件工程師一樣，數(shù)據(jù)工程師應該不斷的尋找使他們工作自動化的方式，構(gòu)建能讓他們爬上更復雜階梯的抽象概念。雖然由于環(huán)境不同，可自動化的工作流程性質(zhì)不盡相同，卻都有著自動化的需求。

所需技能

▼

精通SQL：

如果英語是業(yè)務的交流工具，那么SQL就是數(shù)據(jù)的交流工具。一個不會流利的英語的業(yè)務人員能有多大的成就？不管任何技術(shù)時代的產(chǎn)生和更替，SQL一直是數(shù)據(jù)的通用語。數(shù)據(jù)工程師應該有能用SQL表達任何‘相關(guān)子查詢’和窗口函數(shù)復雜度的技術(shù)能力。對數(shù)據(jù)工程師來說初始SQL／DML/DDL簡單到根本沒有難度。即使是沒有接觸過SQL的人，他也能讀懂并明白數(shù)據(jù)庫的執(zhí)行計劃，了解所有步驟，知道程序怎么被調(diào)用，連接算法的不同和執(zhí)行計劃內(nèi)的分布式維度。

數(shù)據(jù)模型技能：

作為一個數(shù)據(jù)工程師，有對實體－關(guān)系模型的認知反射，規(guī)范化的清晰認識，權(quán)衡反規(guī)范化的敏銳直覺。數(shù)據(jù)工程師應該熟悉維度建模及相關(guān)概念與術(shù)語。

ETL設計：

能夠?qū)懗鲇行?、有彈性的、“可發(fā)展”的ETL任務是一個關(guān)鍵。我計劃在下一博客中深入這個話題。

架構(gòu)項目：

就如任何一個領(lǐng)域的專家的專業(yè)技能一樣，數(shù)據(jù)工程師需要一個較高層次的綜括，對大多數(shù)的工具，平臺，庫，和其他供他支配的資源的了解。認識到不同類型的數(shù)據(jù)庫、計算引擎、流處理器、消息隊列、工作流協(xié)調(diào)器、序列化格式及其他相關(guān)技術(shù)的屬性、用例、微妙之處。在設計解決方案的時候，他應該有能力選擇即將要使用的技術(shù)，并有一個構(gòu)想去協(xié)調(diào)怎么使他們一起更好地工作。

總體來說

▼

過去在硅谷Airbnb，臉書和雅虎工作的五年里，跟來自谷歌、Netflix、亞馬遜，優(yōu)步、Lyft等幾十個不同規(guī)模大小，不同類型的公司的數(shù)據(jù)團隊交談過。我觀察到越來越多的人對數(shù)據(jù)工程師的職責范圍是什么達成共識，覺得有必要分享我的感悟。

我希望這篇文章能夠成為類似數(shù)據(jù)工程師的一個宣言，我也希望拋磚引玉，使在這個相關(guān)領(lǐng)域中，從事這類工作的人之間能產(chǎn)生更多的火花。