神譯局是36氪旗下編譯團(tuán)隊(duì)，關(guān)注科技、商業(yè)、職場(chǎng)、生活等領(lǐng)域，重點(diǎn)介紹國(guó)外的新技術(shù)、新觀點(diǎn)、新風(fēng)向。

編者按：數(shù)據(jù)工程師是一份好工作還是一份費(fèi)力不討好的工作？數(shù)據(jù)工程師的職責(zé)正在分化得越來越專業(yè)。隨著先進(jìn)工具的發(fā)展，數(shù)據(jù)工程師的工作也在迎來變化。本文來自編譯，希望對(duì)您有所啟發(fā)。

Image courtesy of Tom Stodge on Unsplash.

在數(shù)據(jù)工程領(lǐng)域，馬克西姆·博謝明(Maxime Beauchemin)是一個(gè)人盡皆知的人。

作為Facebook和Airbnb的首批數(shù)據(jù)工程師之一，他編寫并開放了廣受歡迎的Apache Airflow，隨后不久又推出了Apache Superset，這是一款數(shù)據(jù)探索工具，在數(shù)據(jù)領(lǐng)域掀起了一場(chǎng)風(fēng)暴。目前，馬克西姆是Preset的首席執(zhí)行官和聯(lián)合創(chuàng)始人，該公司是一家快速發(fā)展的初創(chuàng)公司，正在為現(xiàn)代企業(yè)的人工智能數(shù)據(jù)可視化鋪平道路。

毫不夸張地說，馬克西姆經(jīng)歷了，甚至是構(gòu)建了過去十年中許多最具影響力的數(shù)據(jù)工程技術(shù)，并通過他在2017年發(fā)表的具有里程碑意義的博客文章《數(shù)據(jù)工程師的崛起》(the Rise of the data Engineer)開創(chuàng)了數(shù)據(jù)工程師這一角色，他在文中記錄了許多他的觀察。簡(jiǎn)而言之，馬克西姆認(rèn)為，為了有效地?cái)U(kuò)展數(shù)據(jù)科學(xué)和分析，團(tuán)隊(duì)需要一個(gè)專門的工程師來管理ETL、構(gòu)建數(shù)據(jù)管道和擴(kuò)展數(shù)據(jù)基礎(chǔ)設(shè)施。這就是數(shù)據(jù)工程師的職責(zé)。

幾個(gè)月后，馬克西姆又對(duì)數(shù)據(jù)工程師面臨的一些最大挑戰(zhàn)進(jìn)行了反思：數(shù)據(jù)工程師的工作很艱難，受到的尊重很少，他們的工作與實(shí)際產(chǎn)生的見解之間的聯(lián)系很明顯，但很少被認(rèn)可。數(shù)據(jù)工程師是一項(xiàng)吃力不討好、但越來越重要的工作，團(tuán)隊(duì)要在構(gòu)建基礎(chǔ)設(shè)施、運(yùn)行作業(yè)和處理來自分析和BI團(tuán)隊(duì)的特別請(qǐng)求之間游走。因此，成為一名數(shù)據(jù)工程師既是一件好事，也是一件壞事。

事實(shí)上，在馬克西姆看來，數(shù)據(jù)工程師是“地位最差的人”。那么，五年過去了，數(shù)據(jù)工程師處在什么位置了呢？

在《影響力：數(shù)據(jù)可觀測(cè)性峰》的主題演講之前，我們與馬克西姆（Maxime）坐下來討論了當(dāng)前的事態(tài)，包括現(xiàn)代數(shù)據(jù)棧的去中心化、數(shù)據(jù)團(tuán)隊(duì)的碎片化、云計(jì)算的興起，以及所有這些因素會(huì)如何永遠(yuǎn)改變數(shù)據(jù)工程師的角色。

1. ETL(Extract Transform and Load，即提取、轉(zhuǎn)換和加載)和分析的速度提高了

馬克西姆回憶說，就在不久以前，數(shù)據(jù)工程師還會(huì)一次運(yùn)行幾個(gè)小時(shí)的Hive作業(yè)，這就需要頻繁地在作業(yè)之間上下文切換（Context Switching），并管理數(shù)據(jù)管道的不同元素。

說白了，這既無聊又累人。

他說：“這種無休止的上下文切換和運(yùn)行數(shù)據(jù)操作所需的時(shí)間太長(zhǎng)，讓人精疲力竭。通常情況下，晚上11:30工作5-10分鐘可以為第二天節(jié)省2-4個(gè)小時(shí)的工作時(shí)間。這并不一定是好事?！?/p>

2021年，得益于BigQuery、Snowflake、Firebolt、Databricks和其他云倉(cāng)儲(chǔ)技術(shù)的計(jì)算能力，數(shù)據(jù)工程師可以很快地完成大型工作。這種從on-prem和開源解決方案向云和托管SaaS的轉(zhuǎn)變釋放了數(shù)據(jù)工程資源，用于與數(shù)據(jù)庫(kù)管理無關(guān)的任務(wù)。

另一方面，成本受到了更多的限制。

馬克西姆說：“以前在on-prem上運(yùn)行相當(dāng)便宜，但在cloud上，你必須注意你的計(jì)算成本。資源是有彈性的，而不是有限的?！?/p>

隨著數(shù)據(jù)工程師不再負(fù)責(zé)管理計(jì)算和存儲(chǔ)，他們的角色正在從基礎(chǔ)設(shè)施開發(fā)轉(zhuǎn)變?yōu)閿?shù)據(jù)堆棧中更基于性能的元素，甚至是專門的角色。

“我們可以從數(shù)據(jù)可靠性工程的興起中看到這種轉(zhuǎn)變，數(shù)據(jù)工程師負(fù)責(zé)管理(而不是構(gòu)建)數(shù)據(jù)基礎(chǔ)設(shè)施，并監(jiān)督基于云的系統(tǒng)的性能?！?/p>

2. 在治理方面更難達(dá)成共識(shí)——不過這沒關(guān)系

在以前的時(shí)代，數(shù)據(jù)團(tuán)隊(duì)結(jié)構(gòu)非常集中化，數(shù)據(jù)工程師和精通技術(shù)的分析師充當(dāng)整個(gè)公司的數(shù)據(jù)“圖書管理員”。數(shù)據(jù)治理是一個(gè)孤立的角色，數(shù)據(jù)工程師實(shí)際上成為了數(shù)據(jù)信任的守門人——不管他們是否愿意。

馬克西姆認(rèn)為，現(xiàn)在人們普遍認(rèn)為治理是分布式的。每個(gè)團(tuán)隊(duì)都有他們自己的分析領(lǐng)域，圍繞“好”數(shù)據(jù)的廣泛標(biāo)準(zhǔn)化定義，強(qiáng)制分散的團(tuán)隊(duì)結(jié)構(gòu)。

他說：“我們承認(rèn)，并非所有領(lǐng)域都需要尋求共識(shí)，但這并沒有讓事情變得更容易。在許多方面，數(shù)據(jù)倉(cāng)儲(chǔ)是組織的鏡像。如果人們對(duì)他們?cè)跀?shù)據(jù)倉(cāng)儲(chǔ)中的東西或指標(biāo)的定義不一致，那么這種缺乏共識(shí)將會(huì)在下游反映出來。但也許這沒關(guān)系?！?/p>

馬克西姆認(rèn)為，也許數(shù)據(jù)團(tuán)隊(duì)不一定要為業(yè)務(wù)尋找共識(shí)，尤其是在數(shù)據(jù)被公司以不同方式使用的情況下。除非團(tuán)隊(duì)仔細(xì)考慮哪些數(shù)據(jù)是私有的(換句話說，只被特定的業(yè)務(wù)領(lǐng)域使用)，哪些需要與更廣泛的組織共享，否則這將不可避免地導(dǎo)致重復(fù)和不一致。

“現(xiàn)在，不同的團(tuán)隊(duì)擁有屬于他們自己的數(shù)據(jù)，這些數(shù)據(jù)是由這個(gè)團(tuán)隊(duì)產(chǎn)生并使用的，而不是讓一個(gè)中心團(tuán)隊(duì)負(fù)責(zé)公司的所有數(shù)據(jù)。當(dāng)數(shù)據(jù)在不同群體之間共享，并在更大范圍內(nèi)開放時(shí)，就需要更嚴(yán)格地為變更管理提供API?！?/p>

這就引出了下一點(diǎn)……

3. 變更管理仍然是一個(gè)問題——但正確的工具有助于解決這個(gè)問題

2017年，馬克西姆寫了他的第一篇文章，“當(dāng)數(shù)據(jù)發(fā)生變化時(shí)，會(huì)影響整個(gè)公司，但卻不會(huì)通知任何人。”缺乏變更管理是由技術(shù)和文化差異造成的。

當(dāng)源代碼或數(shù)據(jù)集被更改或更新時(shí)，下游就會(huì)發(fā)生問題，這些問題將導(dǎo)致儀表板、報(bào)告和其他數(shù)據(jù)產(chǎn)品無效。這種數(shù)據(jù)宕機(jī)(數(shù)據(jù)丟失、不準(zhǔn)確或時(shí)間段錯(cuò)誤)的代價(jià)是昂貴的，它在短時(shí)間內(nèi)密集出現(xiàn)，而且很難解決。通常情況下，宕機(jī)會(huì)悄無聲息地發(fā)生，數(shù)據(jù)團(tuán)隊(duì)會(huì)撓頭，需要想辦法弄清楚哪里出了問題，誰(shuí)受到了影響，以及如何解決問題。

如今，數(shù)據(jù)團(tuán)隊(duì)越來越依賴DevOps和軟件工程最佳實(shí)踐來構(gòu)建更強(qiáng)大的工具和文化，優(yōu)先考慮通信和數(shù)據(jù)可靠性。

馬克西姆說：“數(shù)據(jù)的可觀察性和系統(tǒng)無疑幫助了團(tuán)隊(duì)識(shí)別和解決問題，甚至揭示了什么出現(xiàn)了問題，誰(shuí)受到了影響。不過，變更管理既是技術(shù)上的，也是文化上的。如果去中心化的團(tuán)隊(duì)沒有遵循將下游消費(fèi)者甚至是中心數(shù)據(jù)平臺(tái)團(tuán)隊(duì)留在循環(huán)中的工作流程，那么有效處理變更問題將是一個(gè)挑戰(zhàn)?！?/p>

如果沒有劃分哪些數(shù)據(jù)是私有的(僅由數(shù)據(jù)域所有者使用)，哪些數(shù)據(jù)是公共的(由更廣泛的公司使用)，那么就很難知道誰(shuí)使用了哪些數(shù)據(jù)，如果數(shù)據(jù)泄露了，是什么原因造成的。根因定位可以幫你做到一半。例如，當(dāng)馬克西姆在Airbnb工作時(shí)，Datportal的建立是為了讓數(shù)據(jù)訪問民主化，并讓所有Airbnb員工能夠探索、理解和信任數(shù)據(jù)。盡管Datportal能告訴他們，通過端到端沿襲，誰(shuí)會(huì)受到數(shù)據(jù)更改的影響，但它仍然沒有使管理這些更改變得更容易。

4. 數(shù)據(jù)應(yīng)該是不可變的，否則就會(huì)出現(xiàn)混亂

數(shù)據(jù)工具在很大程度上依賴于軟件工程來獲得靈感——總的來說，這是一件好事。但是有一些數(shù)據(jù)元素使得使用ETL管道與使用代碼庫(kù)有很大的不同。

“如果我想更改一個(gè)列名，這是相當(dāng)困難的，因?yàn)槟惚仨氈匦逻\(yùn)行ETL和更改SQL，”馬克西姆說，“這些新的管道和數(shù)據(jù)結(jié)構(gòu)會(huì)影響你的系統(tǒng)，所以很難做出改變，尤其是當(dāng)某些東西出現(xiàn)問題的時(shí)候。”

例如，如果你有一個(gè)定期將數(shù)據(jù)加載到一個(gè)非常大的表中的增量過程，并且你想要?jiǎng)h除其中的一些數(shù)據(jù)，那么你必須暫停管道，重新配置基礎(chǔ)設(shè)施，然后在刪除新列之后部署新的邏輯。

工具真的幫不上什么忙，尤其是在負(fù)載差異的情況下?；靥钊匀粫?huì)很痛苦，但保留它們還是有一些好處的。

他說：“保存你的數(shù)據(jù)歷史記錄實(shí)際上是有好處的。舊邏輯與新邏輯并存，可以進(jìn)行比較。你不需要打破和改變過去已經(jīng)發(fā)布的東西。”

保留重要的數(shù)據(jù)資產(chǎn)(即使它們沒用了)可以提供有用的上下文。當(dāng)然，目標(biāo)是隨著時(shí)間的推移，所有這些更改都應(yīng)該明確地記錄下來。

5. 數(shù)據(jù)工程師的角色正在分化

就像在軟件工程中一樣，數(shù)據(jù)工程師的角色和職責(zé)正在發(fā)生變化，特別是對(duì)于更成熟的公司來講。隨著數(shù)據(jù)倉(cāng)儲(chǔ)需求向云轉(zhuǎn)移，數(shù)據(jù)庫(kù)工程師正在消失，數(shù)據(jù)工程師越來越多地負(fù)責(zé)管理數(shù)據(jù)性能和可靠性。

根據(jù)馬克西姆的說法，這可能是一件好事。在過去，數(shù)據(jù)工程師是“地位最差的人”?，F(xiàn)在，出現(xiàn)了各種各樣的新職位，讓數(shù)據(jù)工程師的工作變得容易一些。比如說，分析工程師。由local Optimistic的編輯邁克爾·凱米思科（Michael Kaminsky）創(chuàng)造的分析工程師職位是一個(gè)跨數(shù)據(jù)工程和數(shù)據(jù)分析的角色，并使用一種分析的、面向業(yè)務(wù)的方法來處理數(shù)據(jù)。分析工程師負(fù)責(zé)確保數(shù)據(jù)不會(huì)脫離商業(yè)智能和分析。

“數(shù)據(jù)工程師幾乎變成了良好數(shù)據(jù)習(xí)慣的守護(hù)者。例如，如果分析工程師在每次運(yùn)行時(shí)都用dbt重新處理倉(cāng)儲(chǔ)，他們可能會(huì)養(yǎng)成壞習(xí)慣。數(shù)據(jù)工程師是看門人，負(fù)責(zé)向數(shù)據(jù)團(tuán)隊(duì)傳授最佳實(shí)踐，最重要的是關(guān)于效率、數(shù)據(jù)建模和編碼標(biāo)準(zhǔn)，并依賴數(shù)據(jù)可觀察性和DataOps，以確保每個(gè)人都以同樣的勤勉對(duì)待數(shù)據(jù)?！?/p>

6. 操作蠕變并沒有消失，只是被分散了

正如馬克西姆在之前的文章中所討論的，操作蠕變指的是職責(zé)隨著時(shí)間的推移而逐漸增加，不幸的是，對(duì)于數(shù)據(jù)工程師來說，這是非常普遍的現(xiàn)實(shí)。雖然現(xiàn)代工具可以幫助工程師提高效率，但這些工具也并不總是能讓他們的工作更輕松。事實(shí)上，隨著時(shí)間的推移，工具通常會(huì)帶來更多的工作或技術(shù)問題。

然而，即使有了更專業(yè)化的職位和分布式數(shù)據(jù)團(tuán)隊(duì)的出現(xiàn)，操作蠕變并沒有消失。例如，馬克西姆認(rèn)為，分析工程師優(yōu)先考慮的東西不一定是數(shù)據(jù)工程師優(yōu)先考慮的東西。

“分析工程師關(guān)心運(yùn)行管道的成本嗎？他們關(guān)心如何優(yōu)化你的堆棧嗎？”他說，“操作蠕變是一個(gè)行業(yè)問題，因?yàn)閿?shù)據(jù)工程師很有可能仍然需要管理‘不太吸引人的’事情，比如監(jiān)控存儲(chǔ)成本或處理數(shù)據(jù)質(zhì)量?！?/p>

在分析工程師的世界里，操作蠕變也存在。

馬克西姆說：“作為一名分析工程師，如果我要做的只是寫一堆SQL來解決問題，我可能會(huì)使用dbt，但它仍然是一堆模板SQL，這使得編寫任何可重用或可管理的東西都很困難。但在很多情況下，這仍然是我的選擇，因?yàn)樗?jiǎn)單明了?！?/p>

他建議，在理想的情況下，我們希望一些看起來更像現(xiàn)代代碼的東西，因?yàn)槲覀兛梢砸愿勺兊姆绞絼?chuàng)建抽象概念。

7. 那么，數(shù)據(jù)工程師的下一步是什么呢？

我和馬克西姆的談話讓我有很多東西要思考，但總的來說，我傾向于同意他的觀點(diǎn)。當(dāng)數(shù)據(jù)團(tuán)隊(duì)報(bào)告結(jié)構(gòu)和操作層次變得越來越垂直時(shí)，數(shù)據(jù)工程師的范圍變得越來越水平，并關(guān)注性能和可靠性——這最終是一件好事。

專注孕育了創(chuàng)新和速度。數(shù)據(jù)團(tuán)隊(duì)中分化出更多的職位意味著傳統(tǒng)的數(shù)據(jù)工程任務(wù)不需要完全由數(shù)據(jù)工程師承擔(dān)。相反，他們可以專注于重要的事情：確保數(shù)據(jù)在生命周期的每個(gè)點(diǎn)上都是可信的、可訪問的和安全的。

不斷變化的工具環(huán)境反映了向更專注和專門化職位的轉(zhuǎn)變。DataOps使調(diào)度和運(yùn)行作業(yè)變得容易；云數(shù)據(jù)倉(cāng)儲(chǔ)使得在云存儲(chǔ)和處理數(shù)據(jù)變得容易；數(shù)據(jù)湖允許更加微妙和復(fù)雜的處理用例；數(shù)據(jù)可觀察性使許多與數(shù)據(jù)質(zhì)量和可靠性相關(guān)的機(jī)械和重復(fù)任務(wù)自動(dòng)化了，允許整個(gè)數(shù)據(jù)組織平穩(wěn)運(yùn)行。

隨著這些新技術(shù)和工作流程的興起，工程師們也有了一個(gè)極好的機(jī)會(huì)，可以把數(shù)據(jù)當(dāng)作產(chǎn)品來對(duì)待。只有在數(shù)據(jù)本身經(jīng)過不斷發(fā)展的迭代產(chǎn)品后，才能構(gòu)建可操作的、可擴(kuò)展的、可觀察的和彈性的數(shù)據(jù)系統(tǒng)。這里有特定于用例的元數(shù)據(jù)、ML驅(qū)動(dòng)的數(shù)據(jù)發(fā)現(xiàn)和工具，這些工具可以幫助我們更好地理解哪些數(shù)據(jù)是真正重要的。

譯者：Jane