大數(shù)據(jù)開發(fā)工程師、BI工程師、數(shù)據(jù)倉庫工程師、ETL工程師、有什么區(qū)別?
今天我們來看一位大神如何解釋。
BI,商務(wù)智能。BI工程師即為從事商務(wù)智能行業(yè)的工程師。從需求分析師到數(shù)據(jù)倉庫架構(gòu)師、到etl工程師、數(shù)據(jù)分析,報表開發(fā)工程師、數(shù)據(jù)挖掘工程師、etc.,都可以稱之為BI工程師。
etl工程師:是從事系統(tǒng)編程、數(shù)據(jù)庫編程與設(shè)計,要掌握各種常用的編程語言的專業(yè)技術(shù)人員。也叫數(shù)據(jù)庫工程師。
1
一味的解釋數(shù)據(jù)倉庫概念可能沒意思,我們從不同角色出發(fā)吧
老板 :我是一家手機公司的老板,今天要向去董事局匯報,我要準(zhǔn)備一份介紹過去三年的用戶增長、用戶留存、用戶活躍度、手機里面每個APP使用率等情況的報表,假如下面沒我下面沒有BI,那我肯定就蒙逼了。。
BI : 我是一名非技術(shù)BI,我天天看競品的分析報告,看雙十一銷量,看各種評論,知道自己的產(chǎn)品有哪些短板有哪些長處,我分析南北地域差異,國內(nèi)外客戶喜好,總之我在手機領(lǐng)域有著很強的行業(yè)解讀能力和數(shù)據(jù)解讀能力,我可以畫出非常漂亮的圖表和PPT。今天老板讓我出一份報表,我還要去刷臉找ETL工程師幫我跑出這次報告的數(shù)據(jù),基于這份數(shù)據(jù)我要給出一定的解讀,為啥這個月手機賣得不如上個月,為啥用戶流失越來越嚴(yán)重等等都是我要去做的。
ETL工程師 : 我是食物鏈最底層的苦逼ETL工程師,我會寫shell、我會搭hadoop/hive/hbase、會寫超復(fù)雜邏輯的sql,今天那個不會自己計算數(shù)據(jù)的BI又讓我跑幾個數(shù)據(jù),我本想讓她提需求流程的,但她說這是老板要的(運營慣用的殺手锏!?。。?,要加急處理,我只能放下手頭的活兒給她跑數(shù)據(jù)了,花了半個小時把數(shù)據(jù)跑好給她,希望能就這么交差吧。
大數(shù)據(jù)工程師,就是我們所知的大數(shù)據(jù)開發(fā)工程師,主要從事大數(shù)據(jù)平臺的搭建,對個人技術(shù)要求偏高,需要從業(yè)者具備java基礎(chǔ),還得具備以下技術(shù)能力,hadoop、hive、hase、flume、storm、kafka、spark等,是一個非常龐大的技術(shù)集群。
如果你以為我每天就做這點事那你就錯了,我平時的工作可不僅僅就是完成上面交給我的任務(wù)哦,我還負責(zé)數(shù)據(jù)ETL過程、數(shù)據(jù)建模、定時任務(wù)的分配、甚至有時Hadoop集群的維護等等都得我去做,每件事單獨拿出來都可以拿出來寫本書。
就拿ETL過程來說吧,你要把原始數(shù)據(jù)從各種數(shù)據(jù)庫、各種服務(wù)器的不同業(yè)務(wù)日志歸一化到同一類格式,要約定好分隔符,然后導(dǎo)入到分布式文件系統(tǒng)HDFS,甚至你還要和業(yè)務(wù)系統(tǒng)定義數(shù)據(jù)格式出規(guī)范,數(shù)據(jù)收集完,你還得出中間表,數(shù)據(jù)過濾,格式統(tǒng)一,ID統(tǒng)一,維度統(tǒng)一,通過不同的數(shù)據(jù)現(xiàn)象進行數(shù)據(jù),完了,你就得出一些日報周報之類的數(shù)據(jù)了,這時候你要按照需求把數(shù)據(jù)組織成一定的格式然后導(dǎo)Mysql、或者HBASE等等。
總之你就是需要把數(shù)據(jù)各種收集、各種處理、然后各種導(dǎo)入導(dǎo)出,是不是很有意思?
2
不過這些數(shù)據(jù)倉庫都非常初級,其中ETL工程師可發(fā)揮的空間太多了
1、正常情況下,老板 —》 BI —》 ETL 出一份報告,這中間能否BI直接去計算數(shù)據(jù)?sql太復(fù)雜,那么可不可以一切數(shù)據(jù)標(biāo)簽化,BI甚至老板要什么就選什么?
2、ETL工程師可以把數(shù)據(jù)收集自動化、可以規(guī)范業(yè)務(wù)日志格式、可以將一切都配置化,但是這些都是基于N+1的,也就是說今天的發(fā)生了什么一定要到明天才能看到,那么有沒有一個系統(tǒng)能把數(shù)據(jù)分析做到實時或者準(zhǔn)實時?參考雙十一大屏,馬總要是到12號才能知道成交了多少筆不劈了那幫做數(shù)據(jù)的才怪。
3、目前絕大部分分析系統(tǒng)都基于離線計算(HADOOP/ODPS),那這里有個問題了,運營或BI想看個數(shù)據(jù)還得你離線慢騰騰跑完才能看到,那么有沒有一個系統(tǒng)可以支持你再大的數(shù)據(jù)量,再復(fù)雜的邏輯,毫秒出數(shù)據(jù)?
我沒有提到的還有算法工程師、大數(shù)據(jù)運維工程師等等。
3
數(shù)據(jù)倉庫的概念很廣很大,但在大數(shù)據(jù)應(yīng)用面前也不值一提。
如果把數(shù)據(jù)價值分層,這里分層的辦法很多,我只列舉一種方法,有人分過5層
第一層: 為老板提供決策支持,例如傳統(tǒng)的財務(wù)報表
第二層: 為運營提供決策支持,例如數(shù)據(jù)化非常徹底的淘寶運營們
第三層: 為產(chǎn)品提供支持,例如有產(chǎn)品經(jīng)理們會拿著報表天天看研究自己的某一個按鈕擺放位置對不對
第四層:數(shù)據(jù)用于生產(chǎn),比如直接對接廣告系統(tǒng)產(chǎn)生收益,比如直接對接推薦系統(tǒng)為用戶推薦商品,實現(xiàn)千人千面,再比如利用手機APP直接為不同用戶push消息
第五層:大數(shù)據(jù)交換,數(shù)據(jù)產(chǎn)生直接受益
大部分公司能做到前兩個層次就已經(jīng)很不錯了,如果能做到第三層,就已經(jīng)很牛逼,做到第四第五層次,國內(nèi)互聯(lián)網(wǎng)公司不超過2家,大數(shù)據(jù)應(yīng)用太大了,不知從何說起,以后聊吧。
4
針對評論中的一些問題做些統(tǒng)一的解釋
問:數(shù)據(jù)交換的理念
有人提到數(shù)據(jù)交換,數(shù)據(jù)交換不是簡單的我給你一點,你給我一點;也不是我給你錢,你給我點數(shù)據(jù)。
原因是這些模式基本走不通
1、數(shù)據(jù)很難定價,無法簡單的將數(shù)據(jù)定義為商品,數(shù)據(jù)供給方也無法去衡量一份數(shù)據(jù)能產(chǎn)生多大的價值,只有在具體的應(yīng)用場景中才能大概估計它的價值,因此幾乎沒有一種簡單公平的機制去為交易雙反指定交易規(guī)則。
2、數(shù)據(jù)拷貝成本幾乎沒有
如果是一部iPhone,如果想要造出一模一樣的一部iPhone成本奇高,所以蘋果公司可以放心大膽的把手機賣給你而不怕你仿制,但是數(shù)據(jù)不行,因為數(shù)據(jù)幾乎沒有拷貝成本。
那么帶來一個問題,如果我把這份數(shù)據(jù)一百萬賣給你,我?guī)缀醭恕耗愕恼\信』之外沒有任何方法去限制你不把數(shù)據(jù)折價買個其它更多第三方,那這份數(shù)據(jù)的市場價值很快蕩然無存。
3、隱私
商業(yè)有很多隱私規(guī)則,用戶也有很多隱私,這些都是不能簡單的通過拷貝的去交換的,如果給對方一份數(shù)據(jù),例如:用戶的在某APP的瀏覽行為,那么如果被第三方運用在電話騷擾,廣告彈窗之類的場景中,肯定是不行的。
所以數(shù)據(jù)的交易一定不是通過價格衡量,也不能簡單的數(shù)據(jù)拷貝
數(shù)據(jù)交換 最理想的方式應(yīng)該是,雙方共同拿出一些東西,然后服務(wù)于某個場景,而數(shù)據(jù)導(dǎo)出等行為都是被禁止的,雙方不能看到對方的數(shù)據(jù)也不能導(dǎo)出對方的數(shù)據(jù),可被導(dǎo)出的結(jié)果一定是無害、不侵犯隱私的、不對原數(shù)據(jù)價值產(chǎn)生影響的東西。
而這樣一種數(shù)據(jù)交換的方式卻需要非常大的體系建設(shè),平臺建設(shè),制度建設(shè)。
這樣的體系和平臺,需要長時間的摸索和市場培育,數(shù)據(jù)人任重而道遠。
-
工程師
+關(guān)注
關(guān)注
59文章
1571瀏覽量
68556
發(fā)布評論請先 登錄
相關(guān)推薦
評論