Re: [請益] 生涯發展 數據/資料工程師

[pelicanper (派立肯)]

※ 引述《joyste0102 (Joyce)》之銘言：
: 晚安，大家，不好意思有以下生涯發展想請問：
: 朋友商管背景，工作大概3年，想轉職Data analysis/data engineering或是偏backend的工作，請問各位轉職大神有什麼建議呢？
: 目前有幾個想法是這樣：
: 1. 不要去考研究所，成本太高也不太需要。
: 2. 去上線上課程Python跟Database開始測試自己的興趣，然後一路上到data visualization之類的。
: 3. 去Bootcamp。Alpha Camp只有Full stack似乎不太適合？要去App Works?還有其他的嗎？Hahow有什麼好課程推薦嗎？
: 另想詢問各位推薦幾件事情：
: 1. 台灣的線上或是實體課程。英文程度OK，但還是希望以中文先入手，然後有人可以問可以討論最好。目前有在上班，現在是淡季可以晚上上線上，不排斥兩三個月後辭職準備。
: 2. 課程地圖。想請問自己在家上MOOC的話，應該是怎樣的順序然後才去銜接比方說App Works的Boot camp呢？比較不希望一張白紙就去上，上之前的前期工作要準備好。所以我才會開Python基本語法然後DB，但是到Data Visualization的中間，還有哪些東西可以上MOOC的呢？
: 非常感謝大家的協助，謝謝~
: -----
: Sent from JPTT on my Realme RMX2144.

其實看到這篇真的感觸很深,這幾年DS變顯學但是再屌的DS後面都還是傳統的BI

只是現在為了要吸引人來應徵和跟上潮流大家都一定要講Data Science...

我現在剛好就在紐西蘭某一萬五千人的公家機關當DS Manager

但是我的部門其實是一個SAS平台從Data Warehouse到Visualisation和Analytics

不管前面的專案用甚麼資料模型,一大堆PhD(Permanent Head Damage)

都還是要仰賴ETL,然後我們招人頭銜開Data Scientist來丟履歷的都可以包山包海

面試前30分鐘丟考卷裡面大概六大類考題,請他們能做多少做多少

每個都寫會R/Python/SAS,做過Power BI/Tableau,成功的ML專案

然後丟一個輾轉相除法用SAS寫Macro,問為什麼

select * from a inner join b on a.id = b.id 有問題

來個Left Skewed Bar Chart請他們提供更好的視覺化

再來個Confusion Matrix比較outcome

最後問一個怎麼追蹤量測已經上線的ML

結果...全掛@@

尤其在底層的程式語言和資料倉儲現在有能力的越來越難找

所以回到原PO的問題,其實我到覺得Data Backend非常有搞頭

因為傳統ETL越來越跟不上現代快速大量然後一直變化的需求

從老式Dimensional Modelling到後來Data Vault到現在都Realtime data pipeline

要能夠建立維護一個穩定又效率的資料倉儲尤其在像是大企業或是政府機關

真的難度很高,我們有超過1,800個source table

每天大約六十四億筆資料更新,1.1Tb資料在伺服器間往返

然後編制...六個人,而且還不能加班

現在薪水開到約兩百二十萬台幣還真的很難找人 (不好意思我們鄉下地方不能跟美國比)

所以有機會進Data Backend的話其實還蠻推薦的哇哈哈~~~

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 101.100.130.214 (紐西蘭)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1623414606.A.E94.html
推 lairrol: data sourece 量大又要即時 搬到哪個領域都是大問題
推 kokolotl: 一般招DS都是考這類題目嗎
題目是我出的哇哈哈,因為既然每個都包山包海我就甚麼都考...一點
然後專門找上網找不到或是沒有一定答案的
最後一輪前三十分鐘才公布考題,而且題目多到很難全做完
這樣考的人一定會選自己知道得先寫這樣馬上就知道這傢伙大概領域在哪
→ lairrol: 羨慕這個使用量 小弟還沒摸過 Tb 等級的量...
※ 編輯: pelicanper (101.100.130.214 紐西蘭), 06/11/2021 20:40:56
推 kokolotl: 原來如此~ 感謝
推 Apache: 酷欸
推 chocopie: inner join 考題感覺很有趣
推 yoche2000: 受教了 推
推 drajan: 這個inner join我看不出來哪裡有問題，求教
→ drajan: 你問的問題需要一個有幾年經驗的ML/Data工程師才回答的出
推 x246libra: 我也想知道inner join有什麼問題，是否還要知道，ab各
→ x246libra: 別資料才能看出問題？
推 everglows: 真好奇這樣的問題考得出鑑別度嗎
→ everglows: ds面試超難準備 很廣又因應不同的面試者  會有不同問題
→ everglows: 之前onsite 其中一輪的interivwer只問我電腦配備是什麼
→ everglows: 怎麼處理記憶體有效使用的問題  沒錯就這樣而已
→ everglows: 老實說 問個很偏的題目 在否定candidate的實力不是很認
→ everglows: 同  要說實務上會遇到就算了
→ everglows: 要jr role就問觀念基礎 跟測驗程式能力
→ everglows: sr role就直接問實際接觸到的case or case study
→ everglows: 到底是要考倒candidate還是知道測試實力？
→ everglows: 有時候該準備都準備了 題也刷了 被問到很偏的問題答不
→ everglows: 出來 真的內心很幹Orz
推 kokolotl: 是不能接受select * 嗎  ，求解
→ sextitanic: 比較好奇a跟b的id的關係，為何不是 a.id = b.a_id
推 chocopie: 10樓的方向有點接近了
推 Nonsense8: 1 to 1 relationship？
推 wahaha279: 如果用id當外鍵，可以重新審視一下為什麼要分兩個table
→ wahaha279: 。
推 drajan: Star schema吧
沒想到大家對這個inner join的問題這麼有興趣

這個問題有兩個角度...

第一個是效率,select * 意思就是全部,如果兩個表格都超大

那就要問為什麼一定要如此詳細的資料,譬如說回傳>100G的資料產生的問題

不是CPU或是Memory而是網路頻寬,尤其在企業級的平台即使設備再好

常常瞬間爆量的傳輸量都有可能癱瘓系統,我之前在銀行就發生過兩次

有人用select * from a inner join b on a.id = b.id向核心系統發指令

因為回傳量瞬間太大導致核心系統無法回應導致癱瘓網路銀行

第二個角度是從ETL的維護, select * 的問題是如果沒有把欄位寫清楚

如果上游加了刪了或改了一個下游沒有在用的欄位就會讓自動化的流程產生錯誤

現在很多ETL都是用軟體像是Wherescape Red, Talend, Informatica等等

現代的ETL軟體大部分可以解決這個問題,因為都用拖拉的

基本上這個問題會出現在使用custom query在某些特定場合

或是在某些程式語言嵌入的SQL

這個select * from a inner join b on a.id = b.id

是要看來應徵的有沒有大型企業ETL或是在實務上對資料量與環境的影響夠不夠敏感

尤其是SAS,因為SAS很特別所有的程式都跑在伺服器上不是客戶端

加上因為安全考量我們沒有用雲端,這個部分就會是面試中一個值得注意的眉角

另外補充說明一下...

其實影響面試的面相很多,像廣義的DS真的一兩樣沒有答得很好也不一定會影響結果

而且很多東西是經驗的累積用錯誤和血汗才能換來

到最後都是綜合評比和這個人適不適合這個位置而已

我個人也是從銀行傳統BI然後再新創ML+BI,現在進政府機關一年後當個小主管這樣

當初能被看上是因為技能樹很廣,但是我旁邊那個博士DS就是除了ML其他不插手

所以我的功能現在就是把所有的鳥事攬在身上,這樣下面的就可以專注做目前最重要的

一個團隊要各種不同的人所以沒有甚麼一定是怎樣

這個行業就是這樣,永遠都學不完

共勉之
※ 編輯: pelicanper (101.100.130.214 紐西蘭), 06/12/2021 03:31:23
※ 編輯: pelicanper (101.100.130.214 紐西蘭), 06/12/2021 04:04:51
推 expiate: 對我來說你比較需要的是data engineer而不是DS
→ pelicanper: 就這個inner join問題是,但是上面原文就不只這個問題
→ pelicanper: 只能做DS的DS對我們來說只是一種理想哇哈哈
推 Apache: 不然找個會DS的DE好了
→ pelicanper: 來應徵的都說會啊@@還有履歷Web到ML全包的
→ pelicanper: 我就是看了人資給我Short List的履歷才決定這樣考
推 loveu8: 哈 看工作內容就真的很有趣，不過人員編制少
→ loveu8: 真的有時候面臨這麼大資料量要處理時
→ loveu8: 就會很辛苦去處理
→ loveu8: inner join 會面臨許多問題在於大資料量的狀況下
→ loveu8: l.兩個資料的量體是不是太大，大到記憶體都無法放進去
→ loveu8: 2.就算放進去記憶體裡面，還會面臨過於複雜的運算
→ loveu8: 可能會有算不出來的狀況
→ loveu8: 3.若要一定得運算出結果，有時inner join
→ loveu8: 產生資料遺失的部分，該怎麼調整
→ loveu8: 4.inner join 有時會改用 指定colume+sub query
→ loveu8: 減少資料的輸出，加快運算結果
→ loveu8: 5.如果這個join結果是必須常使用，是不是要建立view
→ loveu8: 給需要的單位去查看
→ loveu8: 6.資源很重要，每一筆query都是錢，怎樣花費最少的cost
→ loveu8: 查出想要的結果，正確判斷資料集該用怎麼方式去獲取
→ loveu8: 7.分析join的必要性，有時需求單位給了一項議題
→ loveu8: 很多自然會想要利用join去解決問題
→ loveu8: 但有時資料的乾淨程度與內容很重要
→ loveu8: 才不會白作工
→ loveu8: 以上是偶爾協助資料分析的經驗
→ loveu8: 才會理解這個水很深，不是做完程式就沒事
→ loveu8: 無時無刻需要調整優化，並回饋真實結果，而改善
→ loveu8: 真實世界我們面臨問題，進而改善，是這門技術存在之需求
→ loveu8: 只是想進去的人很多。在裡面的人 說不出裡面的苦
→ loveu8: 等入門後，大家一起跳坑了XD
推 sammythekid: 架構上就有問題了，怎麼能夠在online service query
→ sammythekid: loveu8大大講得太中肯。調整優化回饋結果&改善
→ bowin: 感謝你的精闢分享。可惜若沒有對PhD的偏見就更好了
PhD那個就開玩笑,學士BS=Bull Shit,碩士MS=More Shit啦哇哈哈

推 sammythekid: 總之還是感謝分享。抱歉這樣推文會有誤會。感謝分享
※ 編輯: pelicanper (101.100.130.214 紐西蘭), 06/13/2021 14:56:19
推 endlesswalk: select不能用*取全部欄位是因為有時候會取太多資料回
→ endlesswalk: 來導致DB爆炸嗎？前公司甚至還規定不能用join（前公
→ endlesswalk: 司是國內知名大電商）
推 yiche: confusion matrix 沒特別背這麼多metric 反正要用google都
→ yiche: 有，這心態參加面試是可以的嗎