企業(yè)大數(shù)據(jù)工作的任務(wù)、工具及挑戰(zhàn)

隨著互聯(lián)網(wǎng)、移動互聯(lián)網(wǎng)和物聯(lián)網(wǎng)的廣泛而深入地應(yīng)用，人類活動的蹤跡加快在網(wǎng)絡(luò)空間的映射，網(wǎng)絡(luò)瀏覽、行車軌跡、物等等均留下數(shù)據(jù)記錄。

目前，全球數(shù)據(jù)呈現(xiàn)爆發(fā)式增長態(tài)勢，人類社會邁入大數(shù)據(jù)時代；

全球每18個月新增數(shù)據(jù)量是人類有史以來全部數(shù)據(jù)量的總和。

大數(shù)據(jù)的核心是數(shù)據(jù)，與大小無關(guān)，數(shù)據(jù)已經(jīng)成為戰(zhàn)略資產(chǎn)。

數(shù)據(jù)是人類活動在網(wǎng)絡(luò)空間的映射，蘊含人類生產(chǎn)、生活的規(guī)律，挖掘數(shù)據(jù)潛在價值，對國家治理、社會管理、企業(yè)決策和個人生活影響深遠(yuǎn)。

世界經(jīng)濟論壇的報告認(rèn)為大數(shù)據(jù)為新財富，價值堪比石油；

商業(yè)版圖由此被重新劃定，通曉如何利用這些數(shù)據(jù)的企業(yè)將成為最強者。

0. 澄清基本概念　　

為了不在后面討論中因概念不清產(chǎn)生誤解，我們首先給出幾個定義：　　

大型IT企業(yè)：指對外提供IT相關(guān)的軟硬件產(chǎn)品及服務(wù)的公司，員工至少在萬人以上?！?

數(shù)據(jù)平臺：指大型IT企業(yè)用來為自身服務(wù)為主，擔(dān)負(fù)數(shù)據(jù)存儲、處理、分析業(yè)務(wù)和軟硬件綜合。

主要針對內(nèi)部服務(wù)，不對外開發(fā)。　　

數(shù)據(jù)分析：此處的數(shù)據(jù)分析師廣義的，包括一切基于數(shù)據(jù)得出的insights的行為，包括統(tǒng)計分析、機器學(xué)習(xí)建模和預(yù)測等?！　?

1. 大型IT企業(yè)開展對內(nèi)數(shù)據(jù)業(yè)務(wù)的驅(qū)動力　　

就目前而言，IT企業(yè)針對自身的數(shù)據(jù)分析業(yè)務(wù)可以分為廣告和非廣告兩類。

對大多數(shù)企業(yè)而言，除了廣告之外的數(shù)據(jù)業(yè)務(wù)，并不能直接帶來可以量化的收入。

但是，無論當(dāng)前數(shù)據(jù)分析的結(jié)果為企業(yè)的現(xiàn)金流做了多少貢獻。

數(shù)據(jù)為王的思想已然占據(jù)了眾多前沿企業(yè)間的頭腦。

數(shù)據(jù)是礦山，insights是金子，有了礦山才能有金子，有了礦山，終究會有金子?！　?

因此，開發(fā)數(shù)據(jù)業(yè)務(wù)最主要的驅(qū)動力，實際是對數(shù)據(jù)業(yè)務(wù)未來前景的積極預(yù)估?！　?

主要應(yīng)用有(除廣告之外)：　　

用戶畫像——越來越多的企業(yè)開始觀眾用戶畫像，畢竟知己知彼百戰(zhàn)不殆，賣東西先得了解買主。　　

客戶保持——預(yù)測哪些現(xiàn)有客戶可能棄用產(chǎn)品或服務(wù)，即使采取措施挽留之?！　?

產(chǎn)品使用分析——DAU，MAU，PV，UV，CTR等等，這些看起來都是些簡單的統(tǒng)計數(shù)字，但卻是反應(yīng)產(chǎn)品被使用情況的重要指標(biāo)?！　?

產(chǎn)品推薦、銷量預(yù)測　　銷售指標(biāo)……等等

具體到某一種應(yīng)用，看似并不復(fù)雜，有些有成熟的方法可以用來訓(xùn)練模型，還有些根本就是統(tǒng)計指標(biāo)。

似乎并不需要什么高深的算法背景。但一旦涉及實際，就不像看起來那么簡單了。

即使是統(tǒng)計指標(biāo)，也不像想象得那樣，隨便run幾個sql query就能得出來?！　?

對于大型分布式系統(tǒng)，不同模塊的訪問log都有可能分布在不同的cluster上，單純收集每日全局log就是一個復(fù)雜工作，更別說之后的合并、去重、聚合等工作?！　?

因此，大型企業(yè)的數(shù)據(jù)分析不是做個excel表，安裝一個免費mysql能夠解決的，而是需要專門的大型數(shù)據(jù)分析平臺?！　?

2. 數(shù)據(jù)分析平臺通用架構(gòu)　　

常見的數(shù)據(jù)分析平臺，至少包括數(shù)據(jù)存儲、處理和分析三個部分。

2.1 數(shù)據(jù)存儲　　

數(shù)據(jù)存儲不必解釋，是一定必要的。

但是如何備份是一個很重要的問題。

假設(shè)：某公司一年產(chǎn)生上千PB的數(shù)據(jù)。

按照單純數(shù)據(jù)的存儲費用1美元/GB年計算，存1TB一年就是1000美元，一PB就是100萬，1000PB就是10億。如果就是簡單的使用hadoop的默認(rèn)配置，每份數(shù)據(jù)都存3份，那么，這個實際產(chǎn)生數(shù)據(jù)x 3的體量將有多大?有將有多大的cost?　　

這是存儲層的挑戰(zhàn)。為了解決這個問題，一方面從硬件層面力圖降低存儲介質(zhì)的價格，比如近年來冷存儲的提出，就是針對運維費用。

另一方面就是尋找備份算法。

例如，yahoo專門研發(fā)了一種圖片存儲算法，邏輯上是11個備份，但是size只有原size的1.x倍。

2.2 數(shù)據(jù)處理　　

數(shù)據(jù)處理傳統(tǒng)上叫ETL、EDW，主要指數(shù)據(jù)的清洗、遷移和格式化。

大數(shù)據(jù)平臺，由于應(yīng)用范疇不同，自然多種多樣，源數(shù)據(jù)包括結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)。

但是如果數(shù)據(jù)真的是“大數(shù)據(jù)”(符合4V特征)的話，即使本身收集上來的數(shù)據(jù)是結(jié)構(gòu)化的，也往往需要二次處理，轉(zhuǎn)換format或schema?！?

數(shù)據(jù)處理層所需技術(shù)相對簡單，然而挑戰(zhàn)在于對于數(shù)據(jù)的理解。

如果不知道這個收集上來的log文件里面要提取出多少字段，每個字段對應(yīng)數(shù)據(jù)源中的哪個部分，則數(shù)據(jù)提取完全不能進行。

這就要求進行數(shù)據(jù)處理的人必須同時具備對業(yè)務(wù)的了解。

2.3 數(shù)據(jù)分析　　

數(shù)據(jù)分析是數(shù)據(jù)中尋找價值的關(guān)鍵步驟。

數(shù)據(jù)分析工作本身還處于初級階段。

除了一些簡單的統(tǒng)計計算，大多數(shù)數(shù)據(jù)還是只能交給分析人員，進行沒有特別針對性的探索，效果難以得到保證。　　

對于這些挑戰(zhàn)，開展數(shù)據(jù)業(yè)務(wù)早的公司，相應(yīng)的平臺和技術(shù)是在針對自身業(yè)務(wù)的過程中慢慢發(fā)展起來，部分公司選擇是將平臺外包或者自己開發(fā)針對自身業(yè)務(wù)的定制功能。

相對于前兩者，數(shù)據(jù)分析師一個業(yè)務(wù)針對性更強的步驟，因此更難采用通用方法或手段解決，更加依賴企業(yè)自身的積累。

3. 數(shù)據(jù)分析平臺開源框架　　

3.1 開源框架　　

目前，就國內(nèi)而言，談到數(shù)據(jù)分析相關(guān)的開源框架，總不能忽略下面三個：　　

hadoop：batch，mapReduce

storm：streaming

spark：batch + streaming

這些開源框架的共同特點是把重點放在并行計算框架上，關(guān)注的是job latency, load balance和fault recovery，對于資源分配、用戶管理和權(quán)限控制幾乎不考慮。

它們基于的假設(shè)是:所有用戶都一樣，平權(quán)，所有用戶都能用所有的機器以最快的可能完成所有工作。　　

3.2 開源框架的局限　　

而在大型企業(yè)內(nèi)部，不同部門，同一部門的不同job，絕對不是平權(quán)的。

不同部門之間，也有很多私密的數(shù)據(jù)，不讓別人訪問。

不同用戶的權(quán)限也是不一樣的。對于計算資源的需求，因為不同job的優(yōu)先級不同，也要求予以區(qū)別。

在這種需求之下，催生了一些第三方，專門提供hadoop等開源框架的資源、權(quán)限管理產(chǎn)品或者服務(wù)。hadoop在升級到2以后，也考慮一些數(shù)據(jù)隔離的問題。

但其力度，恐怕難以滿足大多數(shù)大型企業(yè)的要求。

這也是使用開源框架的無奈。使用開源產(chǎn)品的商業(yè)發(fā)行版，也是一種辦法。不過始終是不如企業(yè)原生系統(tǒng)在這方面的支持。

3.3 企業(yè)原生框架　　

確實也有些企業(yè)獨立開發(fā)了全自主(不基于開源產(chǎn)品)的僅限于內(nèi)部使用的分布式數(shù)據(jù)處理平臺。在用戶管理，數(shù)據(jù)訪問權(quán)限，存儲、運算資源管理等方面很下功夫?！　?

例如：要求每個用戶在提交job前必須先申請token，有多少token，就有多少計算量。不同數(shù)據(jù)存儲路徑之間的權(quán)限完全單獨管理，使用者也要實現(xiàn)申請權(quán)限?！　?

但是開發(fā)這樣的系統(tǒng)意味著企業(yè)必須具備非常強大的研發(fā)能力，并能承擔(dān)得起巨大的人力等資源的消耗。而且相對于開源系統(tǒng)已經(jīng)實現(xiàn)的功能，難免有重復(fù)造輪子之嫌，即使是大型企業(yè)，也很少選取這種方案。　

4. 大型IT企業(yè)數(shù)據(jù)業(yè)務(wù)的挑戰(zhàn)　　

4.1 通用挑戰(zhàn)：意識、技術(shù)和人才　　

4.1.1 意識　　

意識主要是指決策層的思想意識——數(shù)據(jù)對于企業(yè)發(fā)展是否真的必要?

這一點在很多管理者腦子里還是存疑的，他們目前所處狀態(tài)很多是：聽說數(shù)據(jù)這東西有用，人家都在搞，所以我們也要搞，至于是不是真有用，搞出來看看再說。

如果只是采用游戲或者試探態(tài)度，必然影響發(fā)展進程。但這也是沒辦法的事情，所有新事物都必須經(jīng)歷這一過程。

4.1.2 技術(shù)　　

技術(shù)指目前數(shù)據(jù)分析的技術(shù)，基本是采用新框架逆流支持舊接口的策略。

曾經(jīng)有一篇文章，名叫《NoSQL?NO，SQL》，說的就是這個。

包括spark回頭支持SQL，也是如此。明明我們分析的是非結(jié)構(gòu)化數(shù)據(jù)，但是因為高階算法的問題，卻連mapReduce都放棄了，索性回到SQL時代。

為了讓更多人用的舒服，不去開發(fā)針對非結(jié)構(gòu)化數(shù)據(jù)的新方法，而是反過來，向下兼容結(jié)構(gòu)化。

個人認(rèn)為這是一種逆流。這樣做則永遠(yuǎn)無法避免巨大的數(shù)據(jù)處理工作?！　?

4.1.3 人才　　

“數(shù)據(jù)科學(xué)家”這個詞大家肯定都知道。

可是，這個職位其實很模糊，不同公司，甚至同一公司的不同部門之間對這一職位的定義相差甚遠(yuǎn)。

有些數(shù)據(jù)科學(xué)家是學(xué)數(shù)學(xué)的博士，有些是以前做BI的，有些是PM轉(zhuǎn)行的，水平參差不齊。

所以，恐怕在相當(dāng)長的時期里，這會是一個門檻低，要求高的職位。很難短時間內(nèi)批量涌現(xiàn)出優(yōu)秀者。　　

4.2 特有挑戰(zhàn)：產(chǎn)品align　　

產(chǎn)品align是說每個產(chǎn)品的數(shù)據(jù)分析結(jié)果可以互相對比，也就是要求其定義和實現(xiàn)都一致。

對于一個產(chǎn)品眾多的大企業(yè)而言，要求不同產(chǎn)品、流水線的分析報告具有可比性，這是一個很常見的需求。

但是由于現(xiàn)在大多數(shù)企業(yè)中數(shù)據(jù)分析不是由一個部門統(tǒng)一管理，各個產(chǎn)品部門各自為戰(zhàn)，結(jié)果導(dǎo)致在align的過程中互相牽制，進而拉低了所有產(chǎn)品的分析水平。

這樣的挑戰(zhàn)有賴于企業(yè)總體數(shù)據(jù)策略的制定和執(zhí)行。

而整體策略的制定和執(zhí)行又有賴于前面所說的三點通用挑戰(zhàn)，環(huán)環(huán)相扣，顯然不能一蹴而就?！　?

5. 大企業(yè)數(shù)據(jù)工作的發(fā)展趨勢　　

早期的數(shù)據(jù)分析工作，在實踐層面基本采用批處理模式。

隨著業(yè)務(wù)的發(fā)展，對于其實時或者準(zhǔn)實時(NRT)的需求越來越多。

提供latency極短的增量分析和流式服務(wù)是眾多企業(yè)數(shù)據(jù)分析工作的當(dāng)務(wù)之急?！　?

從長遠(yuǎn)考慮，真正擁有數(shù)據(jù)的是大企業(yè)，未來，大企業(yè)在數(shù)據(jù)的分析利用上，也必將全面勝出小企業(yè)。

不過，處于不同成熟階段的大公司突破點各不同。

有些技術(shù)先行，在分析方法和工具上成為領(lǐng)軍。

另一些則傾向數(shù)據(jù)管理和治理，在管理層面上，在策略、條例的制定上為整個社會提供先進經(jīng)驗。