整個世界都是KPI:(3) 資料工程師的 KPI 窘境

一 15 6月 2015 by leafwind
242

黑手資料工程師

在講黑手資料工程師之前,先談一下比較理想的情況

純粹的資料科學家(data scientist)或資料分析師(data analysist)

通常需要精通以下其中一種,並同時熟悉兩種以上

  • 統計

  • 電腦科學(Machine Learning, coding)

  • domain knowledge

而台灣很少有人符合這個嚴苛的定義

因為這樣偏研究類型的工作並不能直接增加公司營收或利潤

尤其是小規模的軟體新創公司

就算有所謂 data scientist 的職缺

多數都還是像我這種身兼研究、開發、跨部門協調的打雜工程師

在這樣的環境裡,就不太能像國外一樣

(有些大公司甚至分工細膩到不用負責產品端)

因為事情太雜太多了,就統稱資料黑手...工程師

當然,在不同公司的資料工程師,其中差異可能會很大

但台灣這類型的工作目前還很少,或許每一間公司都可以當做一個 case study 吧

以下這整篇文章要講的就是這類工作

我只將我遇到的、感受到的寫出來,不代表所有類似的職缺都是如此。

what the fxck are we doing?

如上述所說,這類工作的定位其實蠻尷尬的

雖然專長定位在研究,但目標卻是產品導向

人手不夠的時候可能要產品線一條龍通包

就算沒有通包也必須參與規劃整個系統,以至於到後續維運

舉例來說:

資料平台的 infrastructure

雖然不是我建立的,但我們靠裡面的資料吃飯

因為本身是使用者,常常有新功能的需求

譬如 spark 雖然是很好用的平台,但畢竟還很新

很多不穩定的地方或是 bug 可能要自己 patch 或 workaround

或是要發 PR 回饋給整個 open source

如果是一個比較重大的 feature,會需要完善的規劃

(即使這個 cycle 在我們公司已經很很短)

當有緊急的需求時

等不到 UDF 可能要自己先生一個再 push 上去

或者臨時建 cache table 應付 ETL 的需求

另外 AWS 平台雖然已經廣泛被使用

但維運上有非常多眉角

對新創來說首當其衝的考量就是錢

不可能像以前在學校的時候要多少機器就開多少

AWS 也不是神,常有意外發生

要多做很多維護慢慢增加穩定性

這些都是身為使用者的我們

每天每天地使用,不斷地將需求反饋到平台端

才慢慢有越來越舒服的環境能夠使用

(每天都很感謝我們的 spark team,卻又一直發需求給他們)

系統穩定度、scalability、costdown

這些原本就跟演算法有關的層面更要小心

因為我的程式一旦 deploy 就會影響到整個公司

緊急的 case 天天有

當一個功能是為了救火,時間上不允許作完善測試再上線的時候

就要事先想好哪些地方可能風險比較高,一旦出事馬上 rollback

演算法

擁有最高度不確定性的,就是這一項

不管資料是不是大數據,或者是不是用了機器學習的 model

當你的成效到了一個瓶頸,就要花十倍甚至百倍的力氣去改善 model

對資料工程師來說,選擇永遠有太多種

一個好的、有經驗的資料工程師可以將選項、參數

縮減到別人的十分之一、百分之一

但是仍然需要時間去嘗試各種假設與實驗

然而新創公司就像一枚火箭,必須訂立一個不太容易卻又有希望的目標

每個人都有自己所謂的 KPI

身為資料工程師,實在很難說出:

「好,這個禮拜的目標是增加預測準確度 50%」

這種話

就好像牛頓說:這個月的目標就是想出萬有引力定理

或是愛因斯坦說:今年必須想一個打破現有常識的理論

說的少了,你無法做出對公司確實產生影響力的 project

說的多了,只會覺得愚蠢而已


最令人不舒服的是,能達成多少目標

只有經歷過「分析數據、提出假設、實驗、上線」一整串過程才知道

而這過程很可能會是白費的

是要經過嘗試很多次失敗也不一定保證會得到好結果的

不像其他的程式工作,相對較能預期結果產出

有 spec、有類似的 implementation

只要有線性的倍數時間能夠加班 debug,總是有 workaround 可以解決


資料分析是一種研究

你甚至不知道問題在哪裡

可能試了一百種方法都沒有用

只因為你還沒找到問題的關鍵

是 input data 太髒?

(你以為有人幫你清測資?現實中不要摻太多假資料就不錯了)

還是 feature 沒有做好前處理?

(你甚至不知道要怎樣處理才對)

整個核心價值在於「尋找問題」、「定義問題」而非「實作」


研究需要鉅額成本

就像科學總是耗費極大量人力研究,才能突破一點前緣

新創必須同時兼顧短期 KPI 與長期技術影響力

要怎麼在中間取捨,是個大哉問


Comments