數(shù)據(jù)工程師的沒落

在這篇文章中我打算揭露使數(shù)據(jù)工程師寸步難行的挑戰(zhàn)和風(fēng)險，并列舉這一領(lǐng)域在經(jīng)歷其“青春期”時所面臨的阻力。The downfall of data engineer.

盡管這篇文章的標(biāo)題有點標(biāo)題黨，內(nèi)容很悲觀，但請牢記，我對數(shù)據(jù)工程非常有信心——我只是需要一個和我之前的文章對比強烈的標(biāo)題。理解并揭露這一職位正面臨的逆境是尋找解決方案的第一步。

同時提請讀者注意的是這里陳述的所有觀點都是我個人的，并且是基于我在與很多來自硅谷的數(shù)據(jù)科學(xué)團(tuán)隊的人們交流時所做的了解。這些觀點并不是我老板的想法，與我現(xiàn)在的職位也沒有之間的聯(lián)系。

工作內(nèi)容無聊 & 項目之間內(nèi)容切換

編寫和維護(hù)數(shù)據(jù)抽取、轉(zhuǎn)換和加載(Extract Transform and Load，ETL)真的很無聊。絕大多數(shù)ETL工作需要花很長時間來執(zhí)行，而錯誤和問題更容易在運行時出現(xiàn)，或是運行后才可以認(rèn)定。由于開發(fā)時間對執(zhí)行時間的比率較低，要做到高效就要同時周旋于多重管線之間，同時，這也就意味著需要進(jìn)行大量的內(nèi)容切換。在你的五個正在運行的“大數(shù)據(jù)項目”的其中之一完成之前，你不得不恢復(fù)到數(shù)小時前的大腦狀態(tài)并設(shè)計下一個循環(huán)。這些取決于你有多依賴于咖啡因，距離上一個循環(huán)已經(jīng)過了多久，以及你能做有多細(xì)致周到，你也許不能成功地在你的短時記憶中恢復(fù)全部的上下文語境。這將導(dǎo)致出現(xiàn)愚蠢的系統(tǒng)性錯誤，又要浪費數(shù)小時去糾正。

如果迭代周期之間的空閑時間以小時計算時，你會覺得夜以繼日地工作更有效果 ：晚上11點半花上5-10分鐘的額外工作能夠為你明天節(jié)約2- 4小時。這就可能會導(dǎo)致工作與生活之間的不平衡，很不健康。

尋求共識

不論你是否認(rèn)為老派的數(shù)據(jù)倉庫概念正在消逝，達(dá)成一致的維度和指標(biāo)的追求依舊像以往一樣具有重要意義。我們中的大部分人依舊能時不時地聽到人們說“單一數(shù)據(jù)源”。數(shù)據(jù)倉庫需要反映商業(yè)，而商業(yè)應(yīng)該明確它認(rèn)為這些分析怎么樣。沖突的命名方式和不同命名空間或“數(shù)據(jù)集市Data Mart”中不一致的數(shù)據(jù)是有問題的。如果你想在決策支持上建立信任，你至少需要一致性以及準(zhǔn)確性。在分析過程中的數(shù)據(jù)生成方包含數(shù)百人的現(xiàn)代大組織中，尋求共識在當(dāng)下不是完全不可能，不過也是具有挑戰(zhàn)性的。

過去人們用貶義詞“數(shù)據(jù)孤島”來指代與分散在平臺上或引用不兼容的異質(zhì)性分析相關(guān)的問題。數(shù)據(jù)孤島在項目開始時便自然而然地大量產(chǎn)生，隨著收購的進(jìn)行，團(tuán)隊也不可避免地流動。使用如主數(shù)據(jù)管理(MDM)、數(shù)據(jù)集成(data integration)和厲害的數(shù)據(jù)倉庫項目等增強共識的方法來解決這些問題是商業(yè)智能(現(xiàn)為數(shù)據(jù)工程)團(tuán)隊的職責(zé)?，F(xiàn)如今，在現(xiàn)代快節(jié)奏的公司里，孤島問題瘋狂地不成比例增長。在這里你可以用“暗物質(zhì)”這個詞來描述正在發(fā)生的混亂的擴張后果。隨著大量不那么合格的人們參與進(jìn)來，管道網(wǎng)將很快變得混亂、不一致，并成為一種浪費。如果數(shù)據(jù)工程師是“數(shù)據(jù)倉庫的圖書管理員”，他們可能會覺得他們的工作就像在一個巨大的回收廠里分類出版物。

在儀表盤的生命周期以周計算的世界里，共識成為了幾乎趕不上商業(yè)焦點的改變和切換速度的后臺進(jìn)程。傳統(tǒng)主義者建議創(chuàng)立一個數(shù)據(jù)管理制和所有制的項目，但在特定的規(guī)模和速度下，這些努力只是一種微薄的力量，并不能與正在發(fā)生的擴張相匹配。

變革管理

由于有用的數(shù)據(jù)集被廣泛使用，并且是通過會導(dǎo)致龐大復(fù)雜的有向非循環(huán)圖(DAGs)的方法獲得的，變化的邏輯或源數(shù)據(jù)可能會打破下游結(jié)構(gòu)，和/或使其變得無效。下游結(jié)點比如派生數(shù)據(jù)集、報告、儀表盤、服務(wù)項目和機器學(xué)習(xí)模型便可能需要被改變來反映上游的變化。通常來說，數(shù)據(jù)傳輸線附近的元數(shù)據(jù)是不完整的或被掩藏在代碼中，只有極少數(shù)人有能力耐心閱讀。上游的變化將不可避免地以錯綜復(fù)雜的方式打破下游實體或使其無效。取決于你的機構(gòu)如何權(quán)衡穩(wěn)定性與精確性，這種變化可能是十分可怕的，并可能導(dǎo)致管道堵塞。如果數(shù)據(jù)工程師的工作目標(biāo)是穩(wěn)定性，他們很快就會認(rèn)識到不打破任何東西的最好方法就是不改變?nèi)魏螙|西。

由于管道通常是巨大且昂貴的，適當(dāng)?shù)膯卧獪y試或集成測試應(yīng)當(dāng)在某種程度上達(dá)到均衡。問題在于：利用抽樣數(shù)據(jù)和試運行，你能確認(rèn)的只有這么多。如果你認(rèn)為一個單一環(huán)境的混亂程度已經(jīng)超出了你能處理的范疇，那么在使用到了不同的復(fù)雜代碼和數(shù)據(jù)的開發(fā)和生產(chǎn)環(huán)境時，請努力保持理智。憑我個人的經(jīng)驗，在大數(shù)據(jù)的世界里，很難找到體面地開發(fā)或測試環(huán)境。在很多情況下，你能找到的最好的就是一些人們用來支持任何他們認(rèn)為合適但還未公開的進(jìn)程的空間“沙盒(Sandbox)”。

數(shù)據(jù)工程已經(jīng)錯過了“devops運動”這只大船。devops是一種重視“軟件開發(fā)人員(Dev)”和“IT運維技術(shù)人員(Ops)”之間溝通合作的文化、運動或慣例。 并且現(xiàn)代工程師很少受益于devops運動帶來的理智和安心。他們沒登上這艘大船不是因為他們沒出現(xiàn)，而是因為船票對于他們的貨物來說太昂貴了。

整個團(tuán)隊中最不利的角色

現(xiàn)代團(tuán)隊發(fā)展得很快，不管你的機構(gòu)是工程驅(qū)動、項目管理驅(qū)動或是設(shè)計驅(qū)動，也不管它是否把自己想成是數(shù)據(jù)驅(qū)動的，數(shù)據(jù)工程師并不會起太大的驅(qū)動作用。你得把數(shù)據(jù)工程想成是基礎(chǔ)設(shè)施的角色，是一種人們認(rèn)為理所當(dāng)然的東西。只有當(dāng)它壞了或者是沒有達(dá)到人們的預(yù)期時，它才會受到人們的關(guān)注。

如果團(tuán)隊人員中有數(shù)據(jù)工程師，他的工作可能是幫助數(shù)據(jù)科學(xué)家和分析師收集他們需要的數(shù)據(jù)。如果需要的數(shù)據(jù)不能在數(shù)據(jù)倉庫的結(jié)構(gòu)化部分得到，分析師可能會查找一些原始數(shù)據(jù)來做出短期的解決方案。此時數(shù)據(jù)工程師就需要適當(dāng)?shù)靥幚頂?shù)據(jù)并最終把這些數(shù)據(jù)加入倉庫中。很多情況下答案必須及時給出，因而當(dāng)新的維度和指標(biāo)被填充到數(shù)據(jù)倉庫中時，它們早已是過時的新聞了，所有人都已經(jīng)忘了這件事兒了。數(shù)據(jù)分析師會因其洞察力而獲得榮譽，而其他所有人都可能會質(zhì)疑把這一部分新信息并入數(shù)據(jù)倉庫這一緩慢的后臺進(jìn)程是否還有必要。

雖然“沖擊/影響力(impact)”——這暗示著速度與改變——是員工在其業(yè)績評估中最希望看到的詞，數(shù)據(jù)工程卻被譴責(zé)為幾乎沒有短期影響的緩慢的后臺進(jìn)程。數(shù)據(jù)工程師離那些能產(chǎn)生積極影響的形象還有些距離。

維護(hù)蔓延

維護(hù)蔓延(Operational Creep)對那些需要維持他們自己搭建的系統(tǒng)的職業(yè)來說是一個殘酷的事實。質(zhì)量監(jiān)控團(tuán)隊在很大程度上被“你建立的系統(tǒng)你自己維護(hù)”的格言取代了，并且這個領(lǐng)域的大部分人都支持這個觀點。這被認(rèn)為是一種能夠適當(dāng)?shù)厥构こ處熞庾R到累積的技術(shù)債務(wù)并對其負(fù)責(zé)的方法。

由于數(shù)據(jù)工程通常伴隨著相當(dāng)高的維護(hù)負(fù)擔(dān)，維護(hù)蔓延緩慢這現(xiàn)象出現(xiàn)得很快，并且它整垮工程師的速度比你的招募速度還要快。確實，現(xiàn)代工具使人們變得更高效，但這無疑只是指機器幫助管道建造者能在同時使更多的“飛碟”能旋轉(zhuǎn)起來而已。

此外，維護(hù)蔓延蔓延會導(dǎo)致更高的員工流動率，而這最終會導(dǎo)致低質(zhì)量、不一致且不可維護(hù)的混亂。

是否是真正的軟件工程師?

這個領(lǐng)域的人們應(yīng)該聽到過關(guān)于數(shù)據(jù)工程師是否是“真正的軟件工程師”，或是某種不同類別的工程師的爭論。在某些機構(gòu)中這一職位是不同的，并且可能有不同(更低)的工資級別。隨機觀測的結(jié)果顯示，數(shù)據(jù)工程師中擁有計算機科學(xué)學(xué)位的比率顯著低于整個軟件工程領(lǐng)域中擁有計算機科學(xué)學(xué)位的工程師的比率。

由于本文所述的原因，這一職位的名聲可能在惡性循環(huán)的傳播中變壞。

別急——希望還是有的!

別著急退出。各公司一致認(rèn)為數(shù)據(jù)是核心競爭優(yōu)勢，并且他們在數(shù)據(jù)分析上的投入也比以往更多。“數(shù)據(jù)成熟度”以一個可預(yù)見的曲線形式增長并最終使人們意識到數(shù)據(jù)工程的極端重要性。在你閱讀這篇的文章的同時，成百上千的公司正在他們的長期數(shù)據(jù)策略上加倍投入并投資于數(shù)據(jù)工程。這個職位很有活力，且正在發(fā)展，并有著美好前景。

隨著許多公司在他們的數(shù)據(jù)的投資回報率(ROI)上停滯不前，同時感受到了“數(shù)據(jù)運算高峰”的挫敗感，創(chuàng)新必然會出現(xiàn)以解決本文所描述的痛點，并最終開創(chuàng)數(shù)據(jù)工程的新紀(jì)元。

也許有人會說未來可能的方向是"去專門化"。如果合適的工具出現(xiàn)，也許簡單的任務(wù)可交付給信息工作者。也許和品質(zhì)監(jiān)控(Q/A)團(tuán)隊經(jīng)歷的一樣，軟件工程職能將是更復(fù)雜的工作任務(wù)。同時隨著持續(xù)輸送技術(shù)和方法的不斷出現(xiàn)，工程師們也會被解放出來。

無論如何，適當(dāng)?shù)墓ぞ吆头椒軌驔Q定一個職位未來的道路。我有信心它們能夠解決。這是這篇文章所表達(dá)的擔(dān)憂的大部分根源。