現(xiàn)在一個(gè)企業(yè)或個(gè)人搞個(gè)hadoop集群不是難事，除非你想搞上千個(gè)節(jié)點(diǎn)，難得是如何才能用好這個(gè)平臺(tái)，因此，我們提出要建設(shè)一個(gè)PaaS平臺(tái)，讓操控?cái)?shù)據(jù)的門檻足夠低，也只有大家都會(huì)用了，才有利于形成企業(yè)大數(shù)據(jù)應(yīng)用的生態(tài)，從而更大程度的發(fā)揮出大數(shù)據(jù)的價(jià)值。

那么，何謂大數(shù)據(jù)PaaS？

運(yùn)營(yíng)商在進(jìn)行全網(wǎng)BI系統(tǒng)規(guī)劃時(shí)，會(huì)頻繁遇到一個(gè)問題，各個(gè)省公司、各個(gè)部門都希望自己搭建大數(shù)據(jù)平臺(tái)，到處都缺少人才，甚至都在爭(zhēng)搶集成商的支持。隨著大數(shù)據(jù)技術(shù)的蓬勃發(fā)展，這個(gè)問題變得非常嚴(yán)重，關(guān)鍵在于沒有規(guī)模效益。公司能培養(yǎng)一百名大數(shù)據(jù)專家已經(jīng)非常不容易了，但是如果分散在多個(gè)省，又分散在各個(gè)IT部門(如業(yè)務(wù)支撐、網(wǎng)管支撐和管理信息支撐系統(tǒng))，那么每個(gè)部門只能分到一個(gè)人。

所以很自然的想到“能否實(shí)現(xiàn)平臺(tái)和應(yīng)用分離?”，可否統(tǒng)一搭建一個(gè)大數(shù)據(jù)平臺(tái)，然后各個(gè)單位在平臺(tái)上做分析模式、搭建自己的應(yīng)用? 這種集中化的規(guī)劃，可能是業(yè)界第一次提出大數(shù)據(jù)能力開放平臺(tái)(PaaS)的概念。

大數(shù)據(jù)PaaS最重要的就是數(shù)據(jù)資源的管理，把它與大數(shù)據(jù)能力一樣看待，通通抽象成服務(wù)，即一切皆服務(wù)，從采集、存儲(chǔ)、計(jì)算、展現(xiàn)再到管理，下面一張圖道盡了一切，這里的DaaS是否可以算作PaaS呢?仁者見仁智者見智了，但如果從目的出發(fā)，筆者覺得可以算。

成就大數(shù)據(jù)PaaS的典范是阿里吧，你看他們的中臺(tái)，覆蓋了PaaS的方方面面，幾乎承載了所有數(shù)據(jù)平臺(tái)人員的夢(mèng)想，以下來自《阿里巴巴大數(shù)據(jù)實(shí)踐之大數(shù)據(jù)之路》一書的描述。

數(shù)據(jù)采集層：

Aplus.JS+UserTrack雙劍合璧實(shí)現(xiàn)了Web和APP端的采集，TT實(shí)現(xiàn)了消息的傳輸，DataX實(shí)現(xiàn)了數(shù)據(jù)庫的同步。

數(shù)據(jù)計(jì)算層：

MaxConpute離線和StreamCompute實(shí)時(shí)是存儲(chǔ)和云計(jì)算平臺(tái)，讓其擁有了海量數(shù)據(jù)處理的底蘊(yùn)。

數(shù)據(jù)整合和開發(fā)管理：

主要包括OneData和數(shù)據(jù)開發(fā)平臺(tái)，OneData就是數(shù)據(jù)倉庫建模，數(shù)據(jù)開發(fā)平臺(tái)就是提供各種開發(fā)測(cè)試工具，其中的D2(在云端)管開發(fā)及調(diào)度，SQLSCAN管SQL代碼質(zhì)量，DQC管數(shù)據(jù)質(zhì)量，在彼岸管測(cè)試，比如數(shù)據(jù)交換后的表、字段和分布一致性比對(duì)等等。

數(shù)據(jù)開放層：

使應(yīng)用對(duì)底層數(shù)據(jù)存儲(chǔ)透明，將海量數(shù)據(jù)方便高效地對(duì)外開放，阿里叫OneService，主要提供數(shù)據(jù)查詢和實(shí)時(shí)數(shù)據(jù)推送服務(wù)。

當(dāng)然，其實(shí)PaaS還包括了資源申請(qǐng)，數(shù)據(jù)賦權(quán)等功能，廣義來講就是以上的所有。

理解了大數(shù)據(jù)PaaS的價(jià)值，大家一定對(duì)PaaS非常神往，那么，對(duì)于一般企業(yè)如何打造這類企業(yè)級(jí)的PaaS平臺(tái)呢?

第一，自研，但大多時(shí)候是找死，當(dāng)然簡(jiǎn)單的搞個(gè)小工具也就無所謂PaaS了，筆者強(qiáng)調(diào)的是企業(yè)級(jí)，不是部門集市。

第二，全套外包，比如入駐阿里云，享受其提供的大數(shù)據(jù)PaaS服務(wù)，但將失去靈活性，數(shù)據(jù)安全隱患也成為很多企業(yè)不能承受之重。

第三，采購不同的PaaS組件，搭建符合企業(yè)自身特點(diǎn)的定制化大數(shù)據(jù)PaaS，這成為當(dāng)前很多大型企業(yè)的選擇。

筆者重點(diǎn)談的是第三條道路，今天就從管理的視角來談?wù)勥@種模式的一些挑戰(zhàn)，很多問題的根源其實(shí)不是技術(shù)問題，而是建設(shè)模式問題，你一旦選擇了模式三，就得有足夠的思想準(zhǔn)備。

1、很難有合作伙伴能夠提供全套大數(shù)據(jù)PaaS組件，這意味著巨大的集成成本

這讓我想起了印度的LCA自研飛機(jī)，其外形參考法國幻影2000的，而其引擎系統(tǒng)則選用了美國通用提供的F404-GE-F2J3 發(fā)動(dòng)機(jī)，另外還有俄羅斯負(fù)責(zé)參與測(cè)試的“卡韋里”渦輪風(fēng)扇發(fā)動(dòng)機(jī)，計(jì)算機(jī)系統(tǒng)也采用美國的產(chǎn)品，“阿瓊”坦克也是如此，其發(fā)展時(shí)間長(zhǎng)達(dá)40多年，零配件基本都是進(jìn)口，印度只是負(fù)責(zé)組裝，即使這樣，“阿瓊”的造價(jià)仍然高達(dá)接近1000萬美元，而且到目前為止，“阿瓊”仍然是一種發(fā)展中的坦克產(chǎn)品，它們是否能夠正常使用仍是未知數(shù)。

大數(shù)據(jù)PaaS也面臨同樣困境，其涉及的組件太多了，幾乎沒有任何合作伙伴能夠全套提供，比如數(shù)據(jù)計(jì)算用的是A產(chǎn)品，數(shù)據(jù)采集用的是B產(chǎn)品，數(shù)據(jù)開發(fā)用的是C產(chǎn)品，數(shù)據(jù)可視化用的是D產(chǎn)品，每一個(gè)產(chǎn)品單獨(dú)來看都挺不錯(cuò)，但一旦湊一起要形成合力就充滿挑戰(zhàn)，別說1+1>2，能等于2已經(jīng)挺不錯(cuò)了，企業(yè)在獲得靈活性的同時(shí)，后續(xù)的運(yùn)營(yíng)成本很大，這里舉二個(gè)典型的挑戰(zhàn)：

(1)大數(shù)據(jù)統(tǒng)一的數(shù)據(jù)管理需要三方產(chǎn)品能按標(biāo)準(zhǔn)吐出元數(shù)據(jù)，由于各個(gè)產(chǎn)品開放程度不同，因此如果你希望能給予運(yùn)維人員一致的使用體驗(yàn)，能做端到端的影響或溯源分析，估計(jì)就很難了，協(xié)調(diào)的成本太高。

(2)建設(shè)大數(shù)據(jù)PaaS并不是一棍子買賣，后續(xù)各個(gè)組件都涉及到版本升級(jí)，這個(gè)時(shí)候往往牽一發(fā)而動(dòng)全身，A產(chǎn)品要升級(jí)，B產(chǎn)品能否配合測(cè)試，C產(chǎn)品能否同步改造，全都是協(xié)調(diào)工作，而且產(chǎn)生了木桶效應(yīng)，比如由于XX原因SPARK的版本長(zhǎng)期停留在1.5版本，導(dǎo)致很多新功能不能用。

雖然該模式有很大的集成難度，但考慮到能集百家之長(zhǎng)，因此成為了很多企業(yè)的首選，從大數(shù)據(jù)PaaS生態(tài)的角度看這是好事，但不建議合作伙伴搞什么全套大數(shù)據(jù)PaaS解決方案，這幾乎是不現(xiàn)實(shí)的，規(guī)劃與PPT可以寫得很好，但市場(chǎng)會(huì)給出答案。

大家說要向BAT看齊啊，它有的我也要有，但要知道阿里是有個(gè)阿里云托底的，PaaS組件也是基于阿里云生成，這樣PaaS產(chǎn)品的實(shí)施難度會(huì)直線下降，因此，阿里提OneService是相對(duì)容易的。

而大多合作伙伴的產(chǎn)品面對(duì)的是開放的生態(tài)，你底層要對(duì)接的是各種MPP，Hadoop,流處理組件等等，而且要跟著外面的生態(tài)與時(shí)俱進(jìn)，因此開始的時(shí)候產(chǎn)品其實(shí)做不了那么精細(xì)，做透一個(gè)就相當(dāng)不易。

比如阿里僅一個(gè)開發(fā)管理平臺(tái)就搞出了這么多輔助功能，什么DQC,SQLSCAN等等，我們到現(xiàn)在為止還沒實(shí)現(xiàn)呢，為什么?因?yàn)橐龅氖虑樘嗔恕?/p>

2、很難有合作伙伴能夠提供技術(shù)+體驗(yàn)俱佳的大數(shù)據(jù)PaaS，而客戶這個(gè)“白老鼠”間接鑄就了他們的成功

為什么合作伙伴一開始很難提供技術(shù)+體驗(yàn)俱佳的大數(shù)據(jù)PaaS？筆者認(rèn)為根子在于以下兩點(diǎn)：

(1)合作伙伴縱然有強(qiáng)大的技術(shù)能力，但如果沒有足夠的數(shù)據(jù)，他們嘔心瀝血研發(fā)的杰作幾乎可以肯定是個(gè)半殘品，BAT在大數(shù)據(jù)方面的強(qiáng)大是因?yàn)樗麄兊漠a(chǎn)品是基于自己的大數(shù)據(jù)慢慢孵化出來的，而大多數(shù)合作伙伴沒有這個(gè)機(jī)會(huì)，他們的PaaS是規(guī)劃出來的，模擬的海量數(shù)據(jù)場(chǎng)景跟真實(shí)的數(shù)據(jù)使用場(chǎng)景有很大的區(qū)別，他們的產(chǎn)品一開始非常不成熟。

比如A公司數(shù)據(jù)采集工具在剛交付客戶時(shí)，竟然沒有基本的統(tǒng)計(jì)功能，導(dǎo)致運(yùn)維甚至無法評(píng)估到底有多少比例的接口在第一次上線時(shí)抽取失敗了，得一個(gè)個(gè)靠人去看，而這個(gè)客戶的接口有幾千個(gè)!

比如B公司在某個(gè)小省的客戶處順利升級(jí)了產(chǎn)品，但換到某個(gè)大省，就爆發(fā)了大規(guī)模的故障，原因就是大省的日志太多了，List不動(dòng)了，然后各種超時(shí)。

比如C公司由于沒考慮到某個(gè)客戶數(shù)據(jù)庫中的字段中竟然會(huì)有文本逗號(hào)，這導(dǎo)致了異構(gòu)數(shù)據(jù)庫間交換的失敗，極大影響了生產(chǎn)。

比如阿里的SQLSCAN估計(jì)是檢測(cè)SQL代碼質(zhì)量的，這個(gè)功能很重要，可以避免SQL笛卡爾積啥的，但D公司的產(chǎn)品就是提供不了這個(gè)功能。

你看，合作伙伴縱有天才的程序員，總有想不到的數(shù)據(jù)問題和使用場(chǎng)景，而BAT依托于大數(shù)據(jù)的優(yōu)勢(shì)讓其打造的產(chǎn)品生態(tài)具備天然的優(yōu)勢(shì)，因此大家得抱團(tuán)取暖，有數(shù)據(jù)差技術(shù)的，有技術(shù)沒數(shù)據(jù)的，來個(gè)優(yōu)勢(shì)互補(bǔ)。

(2)呆在實(shí)驗(yàn)室的那幫家伙幾乎不可能有機(jī)會(huì)接觸到客戶的一線維護(hù)人員的真實(shí)訴求，他們偏重開發(fā)更多的功能(意味著更多的收入)，提供更強(qiáng)的性能(意味著碾壓競(jìng)爭(zhēng)對(duì)手)，但當(dāng)我們欣喜的祝賀大數(shù)據(jù)PaaS平臺(tái)上線的時(shí)候，卻發(fā)現(xiàn)自己的一線維護(hù)人員要多花1小時(shí)去配置一個(gè)接口，這到底是怎樣一種體驗(yàn)?

一般來講，B端的產(chǎn)品相對(duì)C端不是太強(qiáng)調(diào)體驗(yàn)，但筆者覺得還是要具體問題具體分析，講不講體驗(yàn)跟B端產(chǎn)品的性質(zhì)和使用環(huán)境有關(guān)，具體可參考另一篇文章《為什么就做不好數(shù)據(jù)產(chǎn)品的體驗(yàn)?》，大數(shù)據(jù)時(shí)代講究個(gè)機(jī)器換人，但突然發(fā)現(xiàn)需要更多的人去運(yùn)作這臺(tái)機(jī)器的時(shí)候就感覺有點(diǎn)荒唐了，運(yùn)營(yíng)運(yùn)維這種隱性成本其實(shí)很高。

A公司，B公司，C公司，D公司都非常拼命，現(xiàn)在的產(chǎn)品越來越好，這對(duì)整個(gè)大數(shù)據(jù)產(chǎn)業(yè)其實(shí)是好事，但也得感謝下那些第一個(gè)吃螃蟹的客戶，他們給予了海量數(shù)據(jù)的測(cè)試機(jī)會(huì)，抓出的BUG可謂汗牛充棟，讓這些公司的產(chǎn)品得以迭代演化。

如果你的企業(yè)需要建設(shè)大數(shù)據(jù)PaaS，但又不想吃螃蟹，那就不要太關(guān)注合作伙伴的PPT，應(yīng)該直接問，在多少企業(yè)用過?多大的數(shù)據(jù)規(guī)模?現(xiàn)在有多少人在用?

3、很難有合作伙伴能夠兼顧到產(chǎn)品的短期和長(zhǎng)期，新時(shí)期要在組織架構(gòu)上進(jìn)行變革

產(chǎn)品研發(fā)的集中化、標(biāo)準(zhǔn)化才能確保合作伙伴用最低的成本獲得最高的效益，合作伙伴對(duì)于大數(shù)據(jù)PaaS往往有自己的既定演進(jìn)路徑，而客戶的需求往往在變，特別是大數(shù)據(jù)這種正處于從概念向?qū)嵱玫霓D(zhuǎn)變中的業(yè)務(wù)，兩者之間的矛盾非常突出。

主要體現(xiàn)在以下三點(diǎn)：

(1)客戶提出的需求要進(jìn)入合作伙伴的研發(fā)列表決策流程很長(zhǎng)，動(dòng)輒半年，很多合作伙伴提出要讓自己的專家聽得見一線的炮聲，但也是雷聲大雨點(diǎn)小。

(2)B端產(chǎn)品的商務(wù)決策流程很長(zhǎng)，從客戶一線提出需求，到項(xiàng)目經(jīng)理匯總，再到規(guī)劃部門，采購部門，信息耗損非常大，再加上合作伙伴的決策流程，到最后，一線的需求往往變了樣，一線作為使用人員在整個(gè)決策流程中其實(shí)是個(gè)弱勢(shì)群體。

(3)合作伙伴規(guī)劃的大數(shù)據(jù)PaaS產(chǎn)品功能跟具體的某個(gè)客戶的需求有出入，客戶并不愿意為自己不需要的功能買單，現(xiàn)在功能捆綁銷售的問題不少，合作伙伴該如何權(quán)衡?哪些該做，哪些不該做。

很多客戶受不了，只能另起爐灶，好一點(diǎn)的做法就是搞外掛，要求開放接口，自己搞小應(yīng)用，不少合作伙伴拒絕開放接口，但這是下策，另一種就是選擇其他的替代品，有機(jī)會(huì)就顛覆你，由于B端產(chǎn)品問題的潛伏期比較長(zhǎng)，很多合作伙伴往往渾然不知。

那么，有什么解決辦法呢？

筆者近期也在跟大數(shù)據(jù)PaaS合作伙伴探討解決方案，有兩個(gè)建議：

一是必須提升本地PSO的地位，一方面要承擔(dān)起一線需求對(duì)接的職責(zé)，并且擁有較強(qiáng)的開發(fā)能力，在研發(fā)短線支撐不了的時(shí)候，進(jìn)行補(bǔ)位，甚至能承擔(dān)部分研發(fā)的職責(zé)，比如率先實(shí)現(xiàn)某些功能，另一方面也能傳遞真實(shí)的需求到研發(fā)，驅(qū)動(dòng)大數(shù)據(jù)PaaS產(chǎn)品的成熟，成為感知客戶的”晴雨表”和雙方關(guān)系的”緩沖器”。

二是研發(fā)要走大中臺(tái)的路徑，主要做能力沉淀、前后端解耦及開放，為PSO賦能，讓其去滿足前端應(yīng)用開發(fā)的要求，比如A公司的數(shù)據(jù)采集平臺(tái)雖然功能較多，但由于必須前臺(tái)配置，導(dǎo)致某些輕量級(jí)的抽取場(chǎng)景沒法用，A又不愿意開放能力，逼得客戶只能走外掛。

從這里我們似乎看到了阿里“大中臺(tái)，小前臺(tái)”的影子，是的，合作伙伴也可以借鑒這個(gè)理念，但不要僅僅局限在技術(shù)層面，阿里在實(shí)施這個(gè)戰(zhàn)略的時(shí)候，首先調(diào)整的是組織架構(gòu)，如下圖：

這是一個(gè)很有藝術(shù)的組織架構(gòu)，但顯然當(dāng)前大多公司的研發(fā)和PSO不是這種中臺(tái)和前臺(tái)的關(guān)系，研發(fā)只是單純的滿足需求，沒有中臺(tái)，無法開放能力，更無從談起敏捷響應(yīng)，PSO更多是個(gè)配合角色，缺乏話語權(quán)。

布萊夫曼2016年出了本書《海星與蜘蛛》，說得就是去中心化的組織架構(gòu)，集中的組織必須要放權(quán)，讓聽得見炮聲的基層組織進(jìn)行指揮和戰(zhàn)斗，別老想著控制，這種手段越來越不好用了。