神譯局是36氪旗下編譯團隊，關注科技、商業、職場、生活等領域，重點介紹國外的新技術、新觀點、新風向。

編者按：數據工程師是一份好工作還是一份費力不討好的工作？數據工程師的職責正在分化得越來越專業。隨著先進工具的發展，數據工程師的工作也在迎來變化。本文來自編譯，希望對您有所啟發。

Image courtesy of Tom Stodge on Unsplash.

在數據工程領域，馬克西姆·博謝明(Maxime Beauchemin)是一個人盡皆知的人。

作為Facebook和Airbnb的首批數據工程師之一，他編寫并開放了廣受歡迎的Apache Airflow，隨后不久又推出了Apache Superset，這是一款數據探索工具，在數據領域掀起了一場風暴。目前，馬克西姆是Preset的首席執行官和聯合創始人，該公司是一家快速發展的初創公司，正在為現代企業的人工智能數據可視化鋪平道路。

毫不夸張地說，馬克西姆經歷了，甚至是構建了過去十年中許多最具影響力的數據工程技術，并通過他在2017年發表的具有里程碑意義的博客文章《數據工程師的崛起》(the Rise of the data Engineer)開創了數據工程師這一角色，他在文中記錄了許多他的觀察。簡而言之，馬克西姆認為，為了有效地擴展數據科學和分析，團隊需要一個專門的工程師來管理ETL、構建數據管道和擴展數據基礎設施。這就是數據工程師的職責。

幾個月后，馬克西姆又對數據工程師面臨的一些最大挑戰進行了反思：數據工程師的工作很艱難，受到的尊重很少，他們的工作與實際產生的見解之間的聯系很明顯，但很少被認可。數據工程師是一項吃力不討好、但越來越重要的工作，團隊要在構建基礎設施、運行作業和處理來自分析和BI團隊的特別請求之間游走。因此，成為一名數據工程師既是一件好事，也是一件壞事。

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

在《影響力：數據可觀測性峰》的主題演講之前，我們與馬克西姆（Maxime）坐下來討論了當前的事態，包括現代數據棧的去中心化、數據團隊的碎片化、云計算的興起，以及所有這些因素會如何永遠改變數據工程師的角色。

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

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

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

他說：“這種無休止的上下文切換和運行數據操作所需的時間太長，讓人精疲力竭。通常情況下，晚上11:30工作5-10分鐘可以為第二天節省2-4個小時的工作時間。這并不一定是好事。”

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

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

馬克西姆說：“以前在on-prem上運行相當便宜，但在cloud上，你必須注意你的計算成本。資源是有彈性的，而不是有限的。”

隨著數據工程師不再負責管理計算和存儲，他們的角色正在從基礎設施開發轉變為數據堆棧中更基于性能的元素，甚至是專門的角色。

“我們可以從數據可靠性工程的興起中看到這種轉變，數據工程師負責管理(而不是構建)數據基礎設施，并監督基于云的系統的性能?！?/p>

2. 在治理方面更難達成共識——不過這沒關系

在以前的時代，數據團隊結構非常集中化，數據工程師和精通技術的分析師充當整個公司的數據“圖書管理員”。數據治理是一個孤立的角色，數據工程師實際上成為了數據信任的守門人——不管他們是否愿意。

馬克西姆認為，現在人們普遍認為治理是分布式的。每個團隊都有他們自己的分析領域，圍繞“好”數據的廣泛標準化定義，強制分散的團隊結構。

他說：“我們承認，并非所有領域都需要尋求共識，但這并沒有讓事情變得更容易。在許多方面，數據倉儲是組織的鏡像。如果人們對他們在數據倉儲中的東西或指標的定義不一致，那么這種缺乏共識將會在下游反映出來。但也許這沒關系。”

馬克西姆認為，也許數據團隊不一定要為業務尋找共識，尤其是在數據被公司以不同方式使用的情況下。除非團隊仔細考慮哪些數據是私有的(換句話說，只被特定的業務領域使用)，哪些需要與更廣泛的組織共享，否則這將不可避免地導致重復和不一致。

“現在，不同的團隊擁有屬于他們自己的數據，這些數據是由這個團隊產生并使用的，而不是讓一個中心團隊負責公司的所有數據。當數據在不同群體之間共享，并在更大范圍內開放時，就需要更嚴格地為變更管理提供API?！?/p>

這就引出了下一點……

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

2017年，馬克西姆寫了他的第一篇文章，“當數據發生變化時，會影響整個公司，但卻不會通知任何人?！比狈ψ兏芾硎怯杉夹g和文化差異造成的。

當源代碼或數據集被更改或更新時，下游就會發生問題，這些問題將導致儀表板、報告和其他數據產品無效。這種數據宕機(數據丟失、不準確或時間段錯誤)的代價是昂貴的，它在短時間內密集出現，而且很難解決。通常情況下，宕機會悄無聲息地發生，數據團隊會撓頭，需要想辦法弄清楚哪里出了問題，誰受到了影響，以及如何解決問題。

如今，數據團隊越來越依賴DevOps和軟件工程最佳實踐來構建更強大的工具和文化，優先考慮通信和數據可靠性。

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

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

4. 數據應該是不可變的，否則就會出現混亂

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

“如果我想更改一個列名，這是相當困難的，因為你必須重新運行ETL和更改SQL，”馬克西姆說，“這些新的管道和數據結構會影響你的系統，所以很難做出改變，尤其是當某些東西出現問題的時候。”

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

工具真的幫不上什么忙，尤其是在負載差異的情況下?；靥钊匀粫芡纯?，但保留它們還是有一些好處的。

他說：“保存你的數據歷史記錄實際上是有好處的。舊邏輯與新邏輯并存，可以進行比較。你不需要打破和改變過去已經發布的東西?！?/p>

保留重要的數據資產(即使它們沒用了)可以提供有用的上下文。當然，目標是隨著時間的推移，所有這些更改都應該明確地記錄下來。

5. 數據工程師的角色正在分化

就像在軟件工程中一樣，數據工程師的角色和職責正在發生變化，特別是對于更成熟的公司來講。隨著數據倉儲需求向云轉移，數據庫工程師正在消失，數據工程師越來越多地負責管理數據性能和可靠性。

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

“數據工程師幾乎變成了良好數據習慣的守護者。例如，如果分析工程師在每次運行時都用dbt重新處理倉儲，他們可能會養成壞習慣。數據工程師是看門人，負責向數據團隊傳授最佳實踐，最重要的是關于效率、數據建模和編碼標準，并依賴數據可觀察性和DataOps，以確保每個人都以同樣的勤勉對待數據?！?/p>

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

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

然而，即使有了更專業化的職位和分布式數據團隊的出現，操作蠕變并沒有消失。例如，馬克西姆認為，分析工程師優先考慮的東西不一定是數據工程師優先考慮的東西。

“分析工程師關心運行管道的成本嗎？他們關心如何優化你的堆棧嗎？”他說，“操作蠕變是一個行業問題，因為數據工程師很有可能仍然需要管理‘不太吸引人的’事情，比如監控存儲成本或處理數據質量。”

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

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

他建議，在理想的情況下，我們希望一些看起來更像現代代碼的東西，因為我們可以以更可變的方式創建抽象概念。

7. 那么，數據工程師的下一步是什么呢？

我和馬克西姆的談話讓我有很多東西要思考，但總的來說，我傾向于同意他的觀點。當數據團隊報告結構和操作層次變得越來越垂直時，數據工程師的范圍變得越來越水平，并關注性能和可靠性——這最終是一件好事。

專注孕育了創新和速度。數據團隊中分化出更多的職位意味著傳統的數據工程任務不需要完全由數據工程師承擔。相反，他們可以專注于重要的事情：確保數據在生命周期的每個點上都是可信的、可訪問的和安全的。

不斷變化的工具環境反映了向更專注和專門化職位的轉變。DataOps使調度和運行作業變得容易；云數據倉儲使得在云存儲和處理數據變得容易；數據湖允許更加微妙和復雜的處理用例；數據可觀察性使許多與數據質量和可靠性相關的機械和重復任務自動化了，允許整個數據組織平穩運行。

隨著這些新技術和工作流程的興起，工程師們也有了一個極好的機會，可以把數據當作產品來對待。只有在數據本身經過不斷發展的迭代產品后，才能構建可操作的、可擴展的、可觀察的和彈性的數據系統。這里有特定于用例的元數據、ML驅動的數據發現和工具，這些工具可以幫助我們更好地理解哪些數據是真正重要的。

譯者：Jane