654
數據工程師的沒落
本文講的是數據工程師的沒落，本文是幾個月前大數據文摘推送的一篇文章《數據工程師的崛起》的後續 。那是最近一篇嚐試定義數據工程和描述數據工程師這一新職位與數據科學領域以往和現在的職位之間的聯係的文章。如果對數據工程師這個職位不了解的讀者，可以參考這篇文章《數據科學行業的8個關鍵角色：職責與技能》了解數據科學行業職責分類。
在這篇文章中我打算揭露使數據工程師寸步難行的挑戰和風險，並列舉這一領域在經曆其“青春期”時所麵臨的阻力。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)團隊經曆的一樣，軟件工程職能將是更複雜的工作任務。同時隨著持續輸送技術和方法的不斷出現，工程師們也會被解放出來。
無論如何，適當的工具和方法能夠決定一個職位未來的道路。我有信心它們能夠解決。這是這篇文章所表達的擔憂的大部分根源。
本文作者正在構思下一篇名為“下一代，數據感知ETL”的博文。在這篇文章中他將提出一個以可達性和可維護性為核心的新框架的構思。這個尚未建造的框架有一係列很強的限製條件，但反過來它也會為達成最好的實現提供很強的保障。敬請期待！
原文發布時間為：2017-09-20
作者：Maxime Beauchemin
編譯：阮雪妮，笪潔瓊，Aileen
本文來自雲棲社區合作夥伴“大數據文摘”，了解相關信息可以關注“大數據文摘”微信公眾號
最後更新：2017-09-21 16:03:13