ETL工程師,數據開發and數據倉庫工程師,要如何做職業規劃,求方向,求出路?

目前公司所經常使用的是用GreenPlum搭建的數據倉庫,但之前實習都是使用的大數據Hadoop,Hive所搭建的數倉,請問從現在的職位出發,該如何規劃自己的學習路線?轉大數據Hadoop方向的話,又該如何學習?


我覺得不要把自己局限到某一個大數據組件上,這些組件在一些分散式處理的理念上,都是相通的,要把自己定位在了解各個組件的優缺點,靈活選用的程度。

作為ETL工程師,要提升自己的抽象能力,把一些人工處理的工作,盡量自動化和框架化。不要停留在ETL本身,往前溯,解決數據源的問題,往後溯,建設更好的數據模型,滿足數據分析和挖掘的需求。不要把自己局限到寫腳本跑數據。

對於職業規劃,我覺得一個角度是做好數據流的管理,就是從數據內容建設上,這其實價值很大。另一個角度就是從研發的角度,讓自己有能力勝任模塊組件的研發。都是很好的路。

切忌原地轉圈圈,圍繞數據處理上當前所面臨的問題去思考,問題驅動。成為一名大數據專家,是持續積累的結果,不要急於求成。


謝謝邀請

以前我們組用oracle做數據倉庫的時候,用戶說得最多是 你們怎麼不用大數據,聽說大數據很厲害

後來老系統下線,大數據上線,用戶說得最多的是 你們的大數據做得還不如傳統bi

無意黑大數據,作為一個新人回答這個有點強上的感覺,上面那些還是聽老員工說的。

大數據對我們最大的影響可能就是一群做了5年以上的bi工程師集體去學習使用大數據,然而僅僅只是把oracle那套搬到hive或者spark sql而已,能力有限、底層基礎搭建得不好,所以用戶才會吐槽不如傳統bi,畢竟以前沒做過大數據,邊學邊做還要立馬上線,欠缺的還很多。公司還有一組專門做大數據的,然而營運性的報表分析覺得太low又不肯接,只做挖掘或者應用性不大的搜索。

人才起決定因素不是?懂得越多做的越少,級別越高重複性的工作做得越少,無論如何都有2、8定理的存在,即使在it行業,創造性的工作只需要百分之二十的人造輪子就好了,剩下的都是重複搬磚。

你覺得我沒有回答問題?我的觀點是都不會相互取代,就算大數據取代了bi了如何,大部分人還不是學一套新的東西繼續搬磚,所以你會的不是大數據或者傳統bi,你會的只是搬磚,去哪裡都不缺乏低端搬磚工的位置,只是級別待遇不高而已。如果你是另外那20%的造輪子的人,那麼你根本不用擔心這個問題,這類人多數反應是「哦技術更新了?我再造一套就是了"

我認為不會取代的原因在於,大數據技術在數據量相對較小的情況下其實時效性、速度不如平常資料庫,我們大可認為這兩者是互補的,百萬級別或者千萬級別以上的數據大可用大數據分析,百萬級別一下大可用oracle做分析。

什麼?大數據開源成本低?說得好像那些大數據工程師工資很低的樣子。


與題主差不多的處境吧,我自己規划了幾條路線,給題主做下參考好啦~

一、BI諮詢顧問——&>BI資深顧問

這條路線需要懂的東西會很多很雜。尤其是業務知識,否則諮詢做不起來......

目前做的是銀行數據倉庫項目,所以開始學習一些銀行的業務知識。

①銀行從業資格考試

②銀行會計、銀行相關的規章制度、銀行IT架構等相關的書籍

題主是其他的業務的話,也可以從基礎知識認證考試這兩個方面入手的。

另外一個就是數據建模相關的知識。

目前我正在讀《數據倉庫工具箱-——維度建模權威指南》。

二、大數據方向——數據科學家

和數據倉庫、ETL這些存在較大的差異了,需要學習的東西挺多。

這個方向是現在很熱門的,很多人都選擇跳進去。但是據我看來,大數據數據挖掘的工具已經有了那麼多,新進入的人不大可能是去造輪子的,而是使用輪子的。

但是大數據數據分析數據挖掘其實對數據知識、統計學知識有較高的要求,同時也對業務方面有要求。如果不懂數學統計學,那麼大部分工具用起來也不過是知其然不知其所以然罷了。而如果對業務不熟悉的話,可能挖掘出來的結論就是一文不名的。

目前我在學Python......據說Python在數據處理上還是不錯的。

如果真的要往大數據方向發展的話,可以學學Java,然後是Hadoop、Hive等方面的知識。同時要去理解數據分析數據挖掘的理念和演算法,不只是會用,還能夠知道為什麼要這麼用。

三、數據模型師——數據架構師

精通數據倉庫模型建模總體架構。業務知識上面的要求比BI諮詢顧問還要高。

這個我還是補上一張我自己做的思維導圖吧,也算是自己的一些思考,給大家作參考啦!

有問題不妨私信~


作為開發人員,除了提高基本的技以外更應該注意如何提升自己處理問題解決問題的能力。見過太多的開發人員技術沒問題,但做不好事情,主要是思路問題和思維方式問題。


另外,需要積極突破,增強自己溝通能力,無論對待用戶還是內部的產品、需求團隊,如何高效溝通?如何迅速定位問題解決問題?面對一個工作任務,如何快速的找到主線,分析清楚需求,以至於找到需求實現路線這才是主要的。這才是一個程序員向一個團隊領袖乃至更高層轉變角色的第一步。


技術是無止境的,在技術的路上追尋一輩子也難逃被後來者碾壓的結局。如何拓展自己的領域、視野,以超乎常人的視角帶領團隊進步則是最難得的


祝你成功!


12年DW經驗,謝邀

1.

用GP建設數據倉庫也好,用Hadoop也好,資料庫是什麼,只是工具,GP資料庫的DW,Oracle數據倉庫的DW,Teradata的DW,在同一個系統架構師的手底下,有可能架構都是一樣的,無非是資料庫不同而已,可能牽扯到的周邊工具不用而已.

2.Hadoop平台確實提供了新的DW的解決方案,設計模式跟傳統架資料庫不一樣.會引入新的設計模式,考慮的問題也更多.總體來說,Hadoop平台的成本,靈活性等因素,會逐步替代傳統資料庫作為生產核心,但是這個過程,需要Hadoop平台組建進一步產品化商業化,估計還要3年左右的時間吧

3.對個人來說.如果是純粹技術的學習,Hadoop平台相關技術需要深入的學習,傳統架構的設計理念需要認真的學習掌握.

另外,並不建議把大數據作為單獨條塊跟傳統DW區隔,只不過是技術應用有變化而已


ETL工程師主要是利用工具對不同業務不同結構的數據進行抽取,轉換,載入,局限性比較強,不適合一直干。

數據開發包括數據分析和資料庫開發,兩種職業方向不同,知識結構有重合,數據分析需要用到資料庫工具,資料庫開發包括了很多資料庫工具的開發,適合一直干。

數據倉庫既包括了數據開發,又包括了ETL開發,它需要你的知識面比較廣,同時還需要你有其他知識,所以我覺得數據倉庫開發是比較好的職業,要求也比較高。適合作為職業規劃。


我參與過td gp搭建數倉的過程,現在在嘗試用Hadoop。

其中的邏輯方法實際上都是一樣的,只是用的工具不一樣而已。但是Hadoop本質上不是資料庫,相對資料庫來說有兩個明顯的區別。一是沒有update和delete語句,所以歷史留存的邏輯得另闢蹊徑來實現。二 也是更嚴重的問題,沒有回滾機制,所以一旦出錯,在數據恢復上所需投入的各種成本會大大增加,而且未必能達到資料庫的效果。

我的建議是,在當前的情況下,搭建數倉在可操作性和成本綜合來講,gp是個好選擇。

從學習的角度來說,先理解gp的套路再嘗試用Hadoop去實現它。


我是傳統BI的,現在都大數據了,我自己都沒出路了


推薦閱讀:

資料庫 與 數據倉庫的本質區別是什麼?

TAG:Hadoop | 數據倉庫 | Hive |