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

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

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

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

2、很難有合作伙伴能夠提供技術(shù)+體驗(yàn)俱佳的大數(shù)據(jù)PaaS，而客戶這個(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ǔ)。

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

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

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

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

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

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

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

大數(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)營成本很大，這里舉二個(gè)典型的挑戰(zhàn)：

所以很自然的想到“能否實(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ù)計(jì)算層：

一是必須提升本地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)系的”緩沖器”。

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

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

（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)的成本太高。

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

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

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

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

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

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

主要包括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ù)PaaS的價(jià)值，大家一定對(duì)PaaS非常神往，那么，對(duì)于一般企業(yè)如何打造這類企業(yè)級(jí)的PaaS平臺(tái)呢？

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

（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)？

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

（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)品一開始非常不成熟。

現(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ù)整合和開發(fā)管理：

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

運(yùn)營商在進(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è)人。