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

獲得這個職稱，并不是因為我被升職或是分配。而是 Facebook 覺得我們的工作已經(jīng)超越了典型的商業(yè)智能。我們?yōu)樽约簞?chuàng)造的這個新角色是個全新的學(xué)科。

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

我們是先頭部隊！我們是數(shù)據(jù)工程師！

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

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

數(shù)據(jù)工程師也像數(shù)據(jù)科學(xué)家一樣要寫代碼。數(shù)據(jù)科學(xué)家有很好的分析能力，并且對數(shù)據(jù)可視化很感興趣。與數(shù)據(jù)科學(xué)家不同，而且受啟發(fā)于我們更顯成熟的父學(xué)科——軟件工程，數(shù)據(jù)工程師要構(gòu)建工具、基礎(chǔ)設(shè)施、框架和服務(wù)。事實上可以證明，相比數(shù)據(jù)科學(xué)，數(shù)據(jù)工程更接近軟件工程。

如果討論與既有職責(zé)的關(guān)系，數(shù)據(jù)工程領(lǐng)域可以認(rèn)為是商業(yè)智能和數(shù)據(jù)倉庫的超集，而且更多的元素是從軟件工程得來的。這個學(xué)科也囊括了所謂的“大數(shù)據(jù)”分布式系統(tǒng)的相關(guān)領(lǐng)域內(nèi)容，以及廣泛的Hadoop生態(tài)圈、流式處理和大規(guī)模計算的相關(guān)概念。

在還沒有正規(guī)化的數(shù)據(jù)基礎(chǔ)架構(gòu)團隊的小公司里，數(shù)據(jù)工程的職責(zé)也會涵蓋搭建和維護組織數(shù)據(jù)基礎(chǔ)架構(gòu)的工作任務(wù)。這包括搭建和維護像 Hadoop/Hive/HBase、Spark 平臺之類的活。

在小一些的環(huán)境里，人們傾向使用 Amazon 或 Databricks之類的托管服務(wù)，或者從 Cloudera 或 Hortonworks 之類的廠商獲取支持，這本質(zhì)上就是將數(shù)據(jù)工程的職責(zé)外包給了其他公司。

在大一些的環(huán)境里，由于對數(shù)據(jù)基礎(chǔ)架構(gòu)團隊的需求越來越高時，組織更傾向于專門指定或者開設(shè)一個正式的角色來處理這些工作。在這些組織中，這個把數(shù)據(jù)工程流程自動化的職責(zé)，同時落到了數(shù)據(jù)工程團隊和數(shù)據(jù)基礎(chǔ)架構(gòu)團隊手中，而且兩個團隊合作解決高級問題也是很常見的。

雖然這個角色在工程方面的范圍在擴大，但其他原本作為商業(yè)工程角色的應(yīng)關(guān)注的方面，卻變得越來越次要。比如像構(gòu)建和維護大量的報表和儀表板，已不是一個數(shù)據(jù)工程師的主要關(guān)注領(lǐng)域。

我們現(xiàn)在有了更好的自服務(wù)工具，可以讓分析師、數(shù)據(jù)科學(xué)家和廣義的“信息工作者”變得更精通數(shù)據(jù)，可以獨自應(yīng)付數(shù)據(jù)的使用。

ETL 在變化

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

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

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

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

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

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

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

這里列舉一些數(shù)據(jù)建模技術(shù)方面的變化：

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

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

動態(tài)模式：由于 MapReduce 的出現(xiàn)，以及文檔存儲越來越流行，和 blobs 在數(shù)據(jù)庫中的支持，不需要執(zhí)行 DML（數(shù)據(jù)操作語言）就改進數(shù)據(jù)庫模式變得更容易。這使得以迭代方式去建數(shù)據(jù)倉庫更加容易，也免得開發(fā)前需要達成完全一致和認(rèn)同。

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

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

角色和任務(wù)

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

“數(shù)據(jù)倉庫是一個專門為查詢和分析而構(gòu)造的事務(wù)數(shù)據(jù)副本。” — Ralph Kimball

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

數(shù)據(jù)倉庫依然像之前一樣重要，數(shù)據(jù)工程師負(fù)責(zé)了很多方面的數(shù)據(jù)倉庫建設(shè)和運維的工作。數(shù)據(jù)工程師的焦點就是數(shù)據(jù)倉庫和相關(guān)工作。

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

數(shù)據(jù)工程團隊通常會擁有數(shù)據(jù)倉庫中幾片有保證的、高質(zhì)量的區(qū)域。比如在 Airbnb，有一組“核心”模式（schema）由數(shù)據(jù)工程團隊管理，這里有清晰定義和度量的服務(wù)等級協(xié)議（SLA，service level agreement），嚴(yán)格遵守命名約定，并且相關(guān)的流水線代碼遵循一套最佳實踐。

為數(shù)據(jù)對象制定標(biāo)準(zhǔn)、最佳實踐和認(rèn)證流程的“卓越中心”，這也成為數(shù)據(jù)工程團隊的職責(zé)之一。團隊可以進而去參與或領(lǐng)導(dǎo)一個項目來分享其核心能力，以幫助其他團隊成為更佳的數(shù)據(jù)倉庫公民。比如，F(xiàn)acebook 有一個“數(shù)據(jù)夏令營”的培訓(xùn)項目，Airbnb 正在開發(fā)一個類似的“數(shù)據(jù)大學(xué)”的項目，數(shù)據(jù)工程師在這里主持會議來教大家如何熟練使用數(shù)據(jù)。

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

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

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

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

建設(shè)可以隨企業(yè)規(guī)模增長的基礎(chǔ)設(shè)施（或在其上建設(shè)），并時刻保持資源意識，無疑是對數(shù)據(jù)工程師有好處的。

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

數(shù)據(jù)集成，是通過數(shù)據(jù)交換來集成業(yè)務(wù)和系統(tǒng)其背后的實際操作，它和以前同樣重要，也和以前同樣充滿挑戰(zhàn)。由于軟件即服務(wù)（SaaS， Software as a Service）逐漸成為企業(yè)運營的新標(biāo)準(zhǔn)方式，跨越這些系統(tǒng)來同步相關(guān)數(shù)據(jù)就成為更加關(guān)鍵的需求了。不僅SaaS服務(wù)本身需要最新的數(shù)據(jù)來運行，我們通常也想把產(chǎn)生在SaaS側(cè)的數(shù)據(jù)拿到數(shù)據(jù)倉庫，來和我們其他數(shù)據(jù)一起進行分析。當(dāng)然SaaS經(jīng)常會提供它們自己的分析，但是沒有系統(tǒng)地支持企業(yè)中其余數(shù)據(jù)所能提供的視角，通常得把這些數(shù)據(jù)拉取回來。

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

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

服務(wù)

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

這里列舉數(shù)據(jù)工程師和數(shù)據(jù)基礎(chǔ)架構(gòu)工程師可能構(gòu)建和維護的一小部分服務(wù)。

數(shù)據(jù)攝取：圍繞“爬取”數(shù)據(jù)庫、載入日志、從外部存儲和API獲取數(shù)據(jù)的服務(wù)和工具

指標(biāo)計算：計算和匯總相關(guān)參與指標(biāo)、增長指標(biāo)或細(xì)分指標(biāo)量的框架

異常檢測：使數(shù)據(jù)處理自動化，以便當(dāng)異常事件發(fā)生或趨勢明顯變化時警示相關(guān)人員

元數(shù)據(jù)管理：可以生成和消費元數(shù)據(jù)，并方便在數(shù)據(jù)倉庫中查找信息的相關(guān)工具。

實驗：A/B測試和實驗框架通常是一個重要的企業(yè)分析，并帶有一個關(guān)鍵的數(shù)據(jù)工程模塊。

檢測儀：從日志時間和相關(guān)屬性到那些事件，數(shù)據(jù)工程師

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

就像軟件工程師一樣，數(shù)據(jù)工程師必須不斷關(guān)注工作自動化、構(gòu)建抽象來使他們能應(yīng)對重重困難。雖然環(huán)境不同，可自動化的工作的性質(zhì)不同，但自動化的需求在各個環(huán)境是普遍存在的。

技能要求

精通SQL：如果說英語是商業(yè)語言，那 SQL 就是數(shù)據(jù)語言。如果英語都說不好的話，作為一個商務(wù)人士又能做的怎么樣呢？雖然一代又一代技術(shù)老去和退出舞臺，但是 SQL 一直作為數(shù)據(jù)的通用語言頑強地活著。數(shù)據(jù)工程師應(yīng)該能夠使用 SQL 表達各種復(fù)雜邏輯，比如使用“關(guān)聯(lián)子查詢”和窗口函數(shù)。

SQL/DML/DDL 原語已經(jīng)足夠簡單，對于數(shù)據(jù)工程師來說應(yīng)該完全掌握了。除了SQL的聲明特性，數(shù)據(jù)工程師還應(yīng)該有能力理解數(shù)據(jù)庫的執(zhí)行計劃，并明白每個步驟是什么，明白索引是如何工作的，明白不同的 join 算法，以及執(zhí)行計劃的分布維度（distributed dimension）。

數(shù)據(jù)建模技術(shù)：對于數(shù)據(jù)工程師來說，應(yīng)該對實體/關(guān)系模型形成一種認(rèn)知反射（cognitive reflex），并且對范式化有清晰的認(rèn)識，同時對權(quán)衡反范式化有敏銳的直覺。數(shù)據(jù)工程師應(yīng)該熟悉維度建模和相關(guān)概念和用語。

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

架構(gòu)規(guī)劃：就像任何專業(yè)領(lǐng)域的專家，數(shù)據(jù)工程師需要對大多數(shù)工具、平臺、庫和其他可以運用的資源有一個較高層級的理解。比如不同種類的數(shù)據(jù)庫、計算引擎、流處理器、消息隊列、工作流編排器、序列化格式和其他相關(guān)技術(shù)背后的屬性、用例和微妙之處。設(shè)計解決方案時，數(shù)據(jù)工程師必須能夠?qū)κ褂媚姆N技術(shù)做出好的選擇，能夠想象到如何使它們協(xié)同工作。

總而言之

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

我希望這篇文章可作為某種意義上的數(shù)據(jù)工程宣言，并且我希望可以在從事相關(guān)領(lǐng)域的社區(qū)中激起回應(yīng)。