數據工程師是真的沒落了嗎？
作者：Maxime Beauchemin
編譯：阮雪妮，笪潔瓊，Aileen
這個行業的辛酸，也許只有數據工程師們自己能懂。
在這篇文章中我打算揭露使數據工程師寸步難行的挑戰和風險，并列舉這一領域在經歷其“青春期”時所面臨的阻力。The downfall of data engineer.
盡管這篇文章的標題有點標題黨，內容很悲觀，但請牢記，我對數據工程非常有信心——我只是需要一個和我之前的文章對比強烈的標題。理解并揭露這一職位正面臨的逆境是尋找解決方案的第一步。
同時提請讀者注意的是這里陳述的所有觀點都是我個人的，并且是基于我在與很多來自硅谷的數據科學團隊的人們交流時所做的了解。這些觀點并不是我老板的想法，與我現在的職位也沒有之間的聯系。
工作內容無聊 & 項目之間內容切換
編寫和維護數據抽取、轉換和加載(Extract Transform and Load，ETL)真的很無聊。絕大多數ETL工作需要花很長時間來執行，而錯誤和問題更容易在運行時出現，或是運行后才可以認定。由于開發時間對執行時間的比率較低，要做到高效就要同時周旋于多重管線之間，同時，這也就意味著需要進行大量的內容切換。在你的五個正在運行的“大數據項目”的其中之一完成之前，你不得不恢復到數小時前的大腦狀態并設計下一個循環。這些取決于你有多依賴于咖啡因，距離上一個循環已經過了多久，以及你能做有多細致周到，你也許不能成功地在你的短時記憶中恢復全部的上下文語境。這將導致出現愚蠢的系統性錯誤，又要浪費數小時去糾正。
如果迭代周期之間的空閑時間以小時計算時，你會覺得夜以繼日地工作更有效果 ：晚上11點半花上5-10分鐘的額外工作能夠為你明天節約2- 4小時。這就可能會導致工作與生活之間的不平衡，很不健康。
尋求共識
不論你是否認為老派的數據倉庫概念正在消逝，達成一致的維度和指標的追求依舊像以往一樣具有重要意義。我們中的大部分人依舊能時不時地聽到人們說“單一數據源”。數據倉庫需要反映商業，而商業應該明確它認為這些分析怎么樣。沖突的命名方式和不同命名空間或“數據集市Data Mart”中不一致的數據是有問題的。如果你想在決策支持上建立信任，你至少需要一致性以及準確性。在分析過程中的數據生成方包含數百人的現代大組織中，尋求共識在當下不是完全不可能，不過也是具有挑戰性的。
過去人們用貶義詞“數據孤島”來指代與分散在平臺上或引用不兼容的異質性分析相關的問題。數據孤島在項目開始時便自然而然地大量產生，隨著收購的進行，團隊也不可避免地流動。使用如主數據管理(MDM)、數據集成(data integration)和厲害的數據倉庫項目等增強共識的方法來解決這些問題是商業智能(現為數據工程)團隊的職責。現如今，在現代快節奏的公司里，孤島問題瘋狂地不成比例增長。在這里你可以用“暗物質”這個詞來描述正在發生的混亂的擴張后果。隨著大量不那么合格的人們參與進來，管道網將很快變得混亂、不一致，并成為一種浪費。如果數據工程師是“數據倉庫的圖書管理員”，他們可能會覺得他們的工作就像在一個巨大的回收廠里分類出版物。
在儀表盤的生命周期以周計算的世界里，共識成為了幾乎趕不上商業焦點的改變和切換速度的后臺進程。傳統主義者建議創立一個數據管理制和所有制的項目，但在特定的規模和速度下，這些努力只是一種微薄的力量，并不能與正在發生的擴張相匹配。
變革管理
由于有用的數據集被廣泛使用，并且是通過會導致龐大復雜的有向非循環圖(DAGs)的方法獲得的，變化的邏輯或源數據可能會打破下游結構，和/或使其變得無效。下游結點比如派生數據集、報告、儀表盤、服務項目和機器學習模型便可能需要被改變來反映上游的變化。通常來說，數據傳輸線附近的元數據是不完整的或被掩藏在代碼中，只有極少數人有能力耐心閱讀。上游的變化將不可避免地以錯綜復雜的方式打破下游實體或使其無效。取決于你的機構如何權衡穩定性與精確性，這種變化可能是十分可怕的，并可能導致管道堵塞。如果數據工程師的工作目標是穩定性，他們很快就會認識到不打破任何東西的最好方法就是不改變任何東西。
由于管道通常是巨大且昂貴的，適當的單元測試或集成測試應當在某種程度上達到均衡。問題在于：利用抽樣數據和試運行，你能確認的只有這么多。如果你認為一個單一環境的混亂程度已經超出了你能處理的范疇，那么在使用到了不同的復雜代碼和數據的開發和生產環境時，請努力保持理智。憑我個人的經驗，在大數據的世界里，很難找到體面地開發或測試環境。在很多情況下，你能找到的最好的就是一些人們用來支持任何他們認為合適但還未公開的進程的空間“沙盒(Sandbox)”。
數據工程已經錯過了“devops運動”這只大船。devops是一種重視“軟件開發人員(Dev)”和“IT運維技術人員(Ops)”之間溝通合作的文化、運動或慣例。 并且現代工程師很少受益于devops運動帶來的理智和安心。他們沒登上這艘大船不是因為他們沒出現，而是因為船票對于他們的貨物來說太昂貴了。
整個團隊中最不利的角色
現代團隊發展得很快，不管你的機構是工程驅動、項目管理驅動或是設計驅動，也不管它是否把自己想成是數據驅動的，數據工程師并不會起太大的驅動作用。你得把數據工程想成是基礎設施的角色，是一種人們認為理所當然的東西。只有當它壞了或者是沒有達到人們的預期時，它才會受到人們的關注。
如果團隊人員中有數據工程師，他的工作可能是幫助數據科學家和分析師收集他們需要的數據。如果需要的數據不能在數據倉庫的結構化部分得到，分析師可能會查找一些原始數據來做出短期的解決方案。此時數據工程師就需要適當地處理數據并最終把這些數據加入倉庫中。很多情況下答案必須及時給出，因而當新的維度和指標被填充到數據倉庫中時，它們早已是過時的新聞了，所有人都已經忘了這件事兒了。數據分析師會因其洞察力而獲得榮譽，而其他所有人都可能會質疑把這一部分新信息并入數據倉庫這一緩慢的后臺進程是否還有必要。
雖然“沖擊/影響力(impact)”——這暗示著速度與改變——是員工在其業績評估中最希望看到的詞，數據工程卻被譴責為幾乎沒有短期影響的緩慢的后臺進程。數據工程師離那些能產生積極影響的形象還有些距離。
維護蔓延
維護蔓延(Operational Creep)對那些需要維持他們自己搭建的系統的職業來說是一個殘酷的事實。質量監控團隊在很大程度上被“你建立的系統你自己維護”的格言取代了，并且這個領域的大部分人都支持這個觀點。這被認為是一種能夠適當地使工程師意識到累積的技術債務并對其負責的方法。
由于數據工程通常伴隨著相當高的維護負擔，維護蔓延緩慢這現象出現得很快，并且它整垮工程師的速度比你的招募速度還要快。確實，現代工具使人們變得更高效，但這無疑只是指機器幫助管道建造者能在同時使更多的“飛碟”能旋轉起來而已。
此外，維護蔓延蔓延會導致更高的員工流動率，而這最終會導致低質量、不一致且不可維護的混亂。
是否是真正的軟件工程師?
這個領域的人們應該聽到過關于數據工程師是否是“真正的軟件工程師”，或是某種不同類別的工程師的爭論。在某些機構中這一職位是不同的，并且可能有不同(更低)的工資級別。隨機觀測的結果顯示，數據工程師中擁有計算機科學學位的比率顯著低于整個軟件工程領域中擁有計算機科學學位的工程師的比率。
由于本文所述的原因，這一職位的名聲可能在惡性循環的傳播中變壞。
別急——希望還是有的!
別著急退出。各公司一致認為數據是核心競爭優勢，并且他們在數據分析上的投入也比以往更多。“數據成熟度”以一個可預見的曲線形式增長并最終使人們意識到數據工程的極端重要性。在你閱讀這篇的文章的同時，成百上千的公司正在他們的長期數據策略上加倍投入并投資于數據工程。這個職位很有活力，且正在發展，并有著美好前景。
隨著許多公司在他們的數據的投資回報率(ROI)上停滯不前，同時感受到了“數據運算高峰”的挫敗感，創新必然會出現以解決本文所描述的痛點，并最終開創數據工程的新紀元。
也許有人會說未來可能的方向是"去專門化"。如果合適的工具出現，也許簡單的任務可交付給信息工作者。也許和品質監控(Q/A)團隊經歷的一樣，軟件工程職能將是更復雜的工作任務。同時隨著持續輸送技術和方法的不斷出現，工程師們也會被解放出來。
無論如何，適當的工具和方法能夠決定一個職位未來的道路。我有信心它們能夠解決。這是這篇文章所表達的擔憂的大部分根源。
原文：https://medium.com/@maximebeauchemin/the-downfall-of-the-data-engineer-5bfb701e5d6b
【本文是51CTO專欄機構大數據文摘的原創譯文，微信公眾號“大數據文摘（ id: BigDataDigest）”】
