怎樣選擇數(shù)據(jù)平臺(tái)的建設(shè)方案

時(shí)間：2022-08-03 20:03:02 | 來(lái)源：網(wǎng)站運(yùn)營(yíng)

時(shí)間：2022-08-03 20:03:02 來(lái)源：網(wǎng)站運(yùn)營(yíng)

公司要做數(shù)據(jù)分析，首先要考慮數(shù)據(jù)的準(zhǔn)備，也就是數(shù)據(jù)平臺(tái)的建設(shè)，最近接觸了幾個(gè)客戶都處于這一環(huán)節(jié)，而且其中一個(gè)在方案選型過(guò)程中，也是充滿了糾結(jié)，而我也并沒(méi)有在開始階段給出合理全面的建議。

所以根據(jù)自己的認(rèn)知整理了這篇文章，一是對(duì)自己的整理，二是希望通過(guò)分享，給大家一些參考的價(jià)值。

如我前面每篇文章中所說(shuō)的，文中內(nèi)容局限于自己的認(rèn)知和見(jiàn)識(shí)，有錯(cuò)誤或者不足之處，歡迎大家與“jiago王”交流，對(duì)其中的錯(cuò)誤給予指正。

（ps：文章很長(zhǎng)，心情不好的、比較浮躁的，可以走了，改天再看）


一：為何而搭建數(shù)據(jù)平臺(tái)

業(yè)務(wù)跑的好好的，各系統(tǒng)穩(wěn)定運(yùn)行，為何還要搭建企業(yè)的數(shù)據(jù)平臺(tái)？

這樣的問(wèn)題，心里想想就可以了，不要大聲問(wèn)出來(lái)。我來(lái)直接回答一下，公司一般在什么情況下需要搭建數(shù)據(jù)平臺(tái)，對(duì)各種數(shù)據(jù)進(jìn)行重新架構(gòu)。

從業(yè)務(wù)上的視角來(lái)看：

1.業(yè)務(wù)系統(tǒng)過(guò)多，彼此的數(shù)據(jù)沒(méi)有打通。這種情況下，涉及到數(shù)據(jù)分析就麻煩了，可能需要分析人員從多個(gè)系統(tǒng)中提取數(shù)據(jù)，再進(jìn)行數(shù)據(jù)整合，之后才能分析。一次兩次可以忍，天天干這個(gè)能忍嗎？人為整合出錯(cuò)率高怎么控制？分析不及時(shí)效率低要不要處理？

從系統(tǒng)的視角來(lái)看：

2.業(yè)務(wù)系統(tǒng)壓力大，而不巧，數(shù)據(jù)分析又是一項(xiàng)比較費(fèi)資源的任務(wù)。那么自然會(huì)想到的，通過(guò)將數(shù)據(jù)抽取出來(lái)，獨(dú)立服務(wù)器來(lái)處理數(shù)據(jù)查詢、分析任務(wù)，來(lái)釋放業(yè)務(wù)系統(tǒng)的壓力。

3.性能問(wèn)題，公司可以越做越大，同樣的數(shù)據(jù)也會(huì)越來(lái)越大?？赡苁菤v史數(shù)據(jù)的積累，也可能是新數(shù)據(jù)內(nèi)容的加入，當(dāng)原始數(shù)據(jù)平臺(tái)不能承受更大數(shù)據(jù)量的處理時(shí)，或者是效率已經(jīng)十分低下時(shí)，重新構(gòu)建一個(gè)大數(shù)據(jù)處理平臺(tái)就是必須的了。

上面我列出了三種情況，但他們并非獨(dú)立的，往往是其中兩種甚至三種情況同時(shí)出現(xiàn)。一個(gè)數(shù)據(jù)平臺(tái)的出現(xiàn)，不僅可以承擔(dān)數(shù)據(jù)分析的壓力，同樣可以對(duì)業(yè)務(wù)數(shù)據(jù)進(jìn)行整合，也會(huì)不同程度的提高數(shù)據(jù)處理的性能，基于數(shù)據(jù)平臺(tái)實(shí)現(xiàn)更豐富的功能需求。


二：數(shù)據(jù)平臺(tái)的建設(shè)有哪些方案可以選擇（下文中的優(yōu)缺點(diǎn)僅從企業(yè)選型的角度，并非方案本身的技術(shù)角度）

如果一句話回答的話，那就是：太多了（這是一句廢話，我承認(rèn)），但確實(shí)有非常多的方案可供選擇，我懂的少，肯定是無(wú)法一一介紹，所以就分成了下面幾類，相信也一定程度上覆蓋了大部分企業(yè)的需求了。

1.常規(guī)數(shù)據(jù)倉(cāng)庫(kù)：概念不說(shuō)了，既然是做數(shù)據(jù)這一行的，相信你比我還要清楚，不清楚的可以百度。它的重點(diǎn)在于數(shù)據(jù)整合，同時(shí)也是對(duì)業(yè)務(wù)邏輯的一個(gè)梳理。雖然它也可以打包成ssas那種cube一類的東西來(lái)提升數(shù)據(jù)的讀取性能，但是數(shù)據(jù)倉(cāng)庫(kù)的作用，更多的是為了解決公司的業(yè)務(wù)問(wèn)題，而不僅僅是性能問(wèn)題。這一點(diǎn)后面會(huì)詳細(xì)介紹。

關(guān)于這一方案的優(yōu)缺點(diǎn)，不寫沒(méi)用的，直接說(shuō)重點(diǎn)了：

優(yōu)點(diǎn)：

• 方案成熟，關(guān)于數(shù)據(jù)倉(cāng)庫(kù)的架構(gòu)，不管是Inmon架構(gòu)還是Kimball架構(gòu)，都有著非常廣泛的應(yīng)用，而且相信能將這兩種架構(gòu)落地的人也不少。
  
• 實(shí)施簡(jiǎn)單，涉及的技術(shù)層面主要是倉(cāng)庫(kù)的建模以及etl的處理，很多軟件公司具備數(shù)據(jù)倉(cāng)庫(kù)的實(shí)施能力，實(shí)施難度的大小更多的取決于業(yè)務(wù)邏輯的復(fù)雜程度，而并非技術(shù)上的實(shí)現(xiàn)。
  
• 靈活性強(qiáng)，說(shuō)這句話要有對(duì)應(yīng)場(chǎng)景的，數(shù)據(jù)倉(cāng)庫(kù)的建設(shè)是透明的，如果需要，可以對(duì)倉(cāng)庫(kù)的模型、etl邏輯進(jìn)行修改，來(lái)滿足變更的需求（當(dāng)然，最好設(shè)計(jì)之初考慮的周全一點(diǎn)）。同時(shí)對(duì)于上層的分析而言，通過(guò)sql或者mdx對(duì)倉(cāng)庫(kù)數(shù)據(jù)的分析處理具備極強(qiáng)的靈活性。
  

缺點(diǎn)：

• “實(shí)施周期長(zhǎng)”，注意，我加了引號(hào)，對(duì)應(yīng)下面的敏捷型數(shù)據(jù)集市，而且這點(diǎn)是相對(duì)的，實(shí)施周期的長(zhǎng)與短要取決于業(yè)務(wù)邏輯的復(fù)雜性，時(shí)間是花在了業(yè)務(wù)邏輯的梳理，并非技術(shù)上的瓶頸。關(guān)于這點(diǎn)，后面會(huì)詳細(xì)介紹。
  
• 數(shù)據(jù)的處理能力有限，這個(gè)有限，也是相對(duì)的，海量數(shù)據(jù)的處理它肯定不行，非關(guān)系型數(shù)據(jù)的處理它也不行，但是TB以下級(jí)別的數(shù)據(jù)，還是搞得定的（也取決于所采用的數(shù)據(jù)庫(kù)系統(tǒng)），這個(gè)量級(jí)的數(shù)據(jù)，而相當(dāng)一部分企業(yè)的數(shù)據(jù)，還是很難超過(guò)這個(gè)級(jí)別的。
  

2.商業(yè)敏捷型數(shù)據(jù)集市：

底層的數(shù)據(jù)產(chǎn)品與分析層綁定，使得應(yīng)用層可以直接對(duì)底層數(shù)據(jù)產(chǎn)品中的數(shù)據(jù)進(jìn)行拖拽式分析。這一類產(chǎn)品的出現(xiàn)，其初衷是為了對(duì)業(yè)務(wù)數(shù)據(jù)進(jìn)行簡(jiǎn)單的、快速的整合，實(shí)現(xiàn)敏捷建模，并且大幅提升數(shù)據(jù)的處理速度。目前來(lái)看，這些產(chǎn)品都達(dá)到了以上的目的。但它的優(yōu)缺點(diǎn)也比較明顯。

優(yōu)點(diǎn)：

• 部署簡(jiǎn)單，敏捷開發(fā)，這也是這類產(chǎn)品最大的優(yōu)點(diǎn)，和數(shù)據(jù)倉(cāng)庫(kù)相比，實(shí)施周期要短的多。實(shí)際上它也沒(méi)什么嚴(yán)格的實(shí)施的概念，因?yàn)檫@類產(chǎn)品只是針對(duì)需要分析的數(shù)據(jù)，進(jìn)行局部的關(guān)聯(lián)，只考慮眼前要解決的問(wèn)題就夠了，迭代的能力更強(qiáng)些。
  
• 與上層的分析工具結(jié)合較好，上層的分析工具接入這類數(shù)據(jù)產(chǎn)品后，可直接實(shí)現(xiàn)數(shù)據(jù)的圖形化展示和olap分析。
  
• 對(duì)數(shù)據(jù)處理性能的提高，這類產(chǎn)品都對(duì)數(shù)據(jù)的分析性能做了處理，雖然方式不盡相同，有內(nèi)存映射文件存儲(chǔ)的，也有分布式架構(gòu)、列數(shù)據(jù)存儲(chǔ)的。但無(wú)疑都一定程度上提高了數(shù)據(jù)的處理性能。
  

缺點(diǎn)：

• 首先，它是要收費(fèi)的。
  
• 無(wú)法處理復(fù)雜的業(yè)務(wù)邏輯，這只是一個(gè)工具，它無(wú)法解決業(yè)務(wù)問(wèn)題。這類工具中自帶簡(jiǎn)單的etl功能，實(shí)現(xiàn)簡(jiǎn)單的數(shù)據(jù)處理和整合，而如果考慮到歷史數(shù)據(jù)，考慮到整體的數(shù)據(jù)之間的邏輯和關(guān)系，它一定是解決不了的。一個(gè)簡(jiǎn)單的例子，當(dāng)某個(gè)表中，有兩個(gè)字段，一個(gè)要保留歷史數(shù)據(jù)，一個(gè)要更新歷史數(shù)據(jù)，要怎樣實(shí)現(xiàn)自動(dòng)處理。有一個(gè)觀念是需要清楚的，不能指望一款工具來(lái)解決業(yè)務(wù)問(wèn)題。這種數(shù)據(jù)產(chǎn)品僅僅是對(duì)當(dāng)前的業(yè)務(wù)數(shù)據(jù)進(jìn)行簡(jiǎn)單的整合，第一，數(shù)據(jù)是局部的，第二，時(shí)間是當(dāng)前的（其涵帶的增量更新或者全量更新，是無(wú)法應(yīng)對(duì)復(fù)雜的邏輯的，相信熟悉etl的人都知道這個(gè)過(guò)程有多復(fù)雜）。當(dāng)然，對(duì)于一些公司來(lái)說(shuō)，可能需求只是對(duì)當(dāng)前業(yè)務(wù)數(shù)據(jù)進(jìn)行整合分析，那么這類產(chǎn)品就夠了。（說(shuō)實(shí)話，很多公司真的是懶得更長(zhǎng)遠(yuǎn)的考慮，有一天沒(méi)一天的，誰(shuí)說(shuō)的準(zhǔn)呢）
  
• 靈活性低，這個(gè)也是沒(méi)法避免的，越是操作簡(jiǎn)單的工具，他的靈活性肯定受限，因?yàn)榉庋b住了，產(chǎn)品是不透明的，常規(guī)的需求用起來(lái)非常方便，但是遇到復(fù)雜的，發(fā)現(xiàn)對(duì)他內(nèi)部不了解，你也沒(méi)法修改，只有蛋疼的份。
  

從我的角度看，它是很難成為公司的數(shù)據(jù)中心的。

3.MPP(大規(guī)模并行處理)架構(gòu)的數(shù)據(jù)產(chǎn)品，以最近開源的greenplum為例。

傳統(tǒng)的主機(jī)計(jì)算模式在海量數(shù)據(jù)面前，顯得弱雞。造價(jià)非常昂貴，同時(shí)技術(shù)上也無(wú)法滿足高性能的計(jì)算，smp架構(gòu)難于擴(kuò)展，在獨(dú)立主機(jī)的cpu計(jì)算和io吞吐上，都沒(méi)辦法滿足海量數(shù)據(jù)計(jì)算的需求。分布式存儲(chǔ)和分布式計(jì)算正是解決這一問(wèn)題的關(guān)鍵，不管是后面的MapReduce計(jì)算框架還是MPP計(jì)算框架，都是在這一背景下產(chǎn)生的。

greenplum的數(shù)據(jù)庫(kù)引擎是基于postgresql的，并且通過(guò)Interconnnect神器實(shí)現(xiàn)了對(duì)同一個(gè)集群中多個(gè)Postgresql實(shí)例的高效協(xié)同和并行計(jì)算。

同時(shí)，基于greenplum的數(shù)據(jù)平臺(tái)建設(shè)，可以實(shí)現(xiàn)兩個(gè)層面的處理，顯而易見(jiàn)的一個(gè)是對(duì)數(shù)據(jù)處理性能的處理，greenplum的百科中宣稱支持50PB級(jí)海量數(shù)據(jù)的處理，考慮它有吹牛的成分，對(duì)目前greenplum實(shí)際應(yīng)用情況的了解，100tb級(jí)左右的數(shù)據(jù)，是非常輕松的。另一個(gè)是數(shù)據(jù)倉(cāng)庫(kù)可以搭建在greenplum中，這一層面上也是對(duì)業(yè)務(wù)邏輯的梳理，對(duì)公司業(yè)務(wù)數(shù)據(jù)的整合。

優(yōu)點(diǎn)：

• 海量數(shù)據(jù)的支持，大量成熟的應(yīng)用案例，所以我想這一點(diǎn)是不用懷疑的。
  
• 擴(kuò)展性，據(jù)說(shuō)可線性擴(kuò)展到10000個(gè)節(jié)點(diǎn)，并且每增加一個(gè)節(jié)點(diǎn)，查詢、加載性能都成線性增長(zhǎng)。
  
• 易用性，不需要復(fù)雜的調(diào)優(yōu)需求，并行處理由系統(tǒng)自動(dòng)完成。依然是sql作為交語(yǔ)言，簡(jiǎn)單、靈活、強(qiáng)大。
  
• 高級(jí)功能，greenplum還研發(fā)了很多高級(jí)數(shù)據(jù)分析管理功能，例如人氣很高的外部表，還有Primary/Mirror鏡像保護(hù)機(jī)制，行／列混合存儲(chǔ)等。
  
• 穩(wěn)定性，greenplum原本作為一個(gè)純商業(yè)數(shù)據(jù)產(chǎn)品，具有很長(zhǎng)的歷史，其穩(wěn)定性相比于其他產(chǎn)品以及敏捷性數(shù)據(jù)集市是更加有保障的。greenplum有非常多的應(yīng)用案例，納斯達(dá)克、紐約證券交易所、平安銀行、建設(shè)銀行、華為等都建立了基于greenplum的數(shù)據(jù)分析平臺(tái)。其穩(wěn)定性是可以從側(cè)面驗(yàn)證的，在15年9月份開源后，各大互聯(lián)網(wǎng)公司也是一片歡騰，現(xiàn)在也接觸了幾家在使用greenplum的客戶，對(duì)其評(píng)價(jià)都很高。

缺點(diǎn)：

• 本身來(lái)說(shuō)，它的定位在olap領(lǐng)域，不擅長(zhǎng)oltp交易系統(tǒng)。當(dāng)然我們搭建公司的數(shù)據(jù)中心也不會(huì)是用來(lái)做交易系統(tǒng)的。
  
• 成本，兩個(gè)方面的考慮，一是硬件成本，greenplum有其推薦的硬件規(guī)格，對(duì)內(nèi)存、網(wǎng)卡都有要求。當(dāng)然，在硬件選型上，需要達(dá)到一個(gè)平衡，要在性能、容量、成本等多方面考慮，畢竟不能一味的追求性能，把采購(gòu)部門嚇到吧。另一個(gè)是實(shí)施成本，這里主要是人了，基本的是greenplum的安裝配置，再到greenplum中數(shù)據(jù)倉(cāng)庫(kù)的構(gòu)建，都需要人和時(shí)間。（但是必須要說(shuō)的是，人家軟件都開源了，也省下了一筆錢?。?br>
• 技術(shù)門檻，這里是相對(duì)于上一個(gè)敏捷型數(shù)據(jù)集市的，greenplum的門檻肯定是要高一點(diǎn)了。
  

4.hadoop分布式系統(tǒng)架構(gòu)

關(guān)于hadoop，已經(jīng)火的要爆炸了，greenplum的開源跟它也是脫不了關(guān)系的。有著高可靠性、高擴(kuò)展性、高效性、高容錯(cuò)性的口碑。在互聯(lián)網(wǎng)領(lǐng)域有非常廣泛的運(yùn)用，雅虎、facebook、百度、淘寶等等等等。hadoop生態(tài)體系非常龐大，各公司基于hadoop所實(shí)現(xiàn)的也不僅限于數(shù)據(jù)分析，也包括機(jī)器學(xué)習(xí)、數(shù)據(jù)挖掘、實(shí)時(shí)系統(tǒng)等。

當(dāng)企業(yè)數(shù)據(jù)規(guī)模達(dá)到一定的量級(jí)，我想hadoop是各大企業(yè)的首選方案，到達(dá)這樣一個(gè)層次的時(shí)候，我想企業(yè)所要解決的也不僅是性能問(wèn)題，還會(huì)包括時(shí)效問(wèn)題、更復(fù)雜的分析挖掘功能的實(shí)現(xiàn)等。非常典型的實(shí)時(shí)計(jì)算體系也與hadoop這一生態(tài)體系有著緊密的聯(lián)系。

近些年來(lái)hadoop的易用性也有了很大的提升，sql-on-hadoop技術(shù)大量涌現(xiàn)，包括hive、impala、spark-sql等。盡管其處理方式不同，但普遍相比于原始基于文件的Mapreduce，不管是性能還是易用性，都是有所提高的。也因此對(duì)mpp產(chǎn)品的市場(chǎng)產(chǎn)生了壓力。

對(duì)于企業(yè)構(gòu)建數(shù)據(jù)平臺(tái)來(lái)說(shuō)，hadoop的優(yōu)勢(shì)與劣勢(shì)非常明顯：它的大數(shù)據(jù)的處理能力、高可靠性、高容錯(cuò)性、開源性以及低成本（為什么說(shuō)低成本，要處理同樣規(guī)模的數(shù)據(jù)，換一個(gè)其他方案試試呢）。缺點(diǎn)也就是他的體系的復(fù)雜，技術(shù)門檻較高（能搞定hadoop的公司規(guī)模一般都不小了）。

關(guān)于hadoop的優(yōu)缺點(diǎn)對(duì)于公司的數(shù)據(jù)平臺(tái)選型來(lái)說(shuō)，影響已經(jīng)不大了。需要上hadoop的時(shí)候，也沒(méi)什么其它的方案好選擇（要么太貴，要么不行），沒(méi)到達(dá)這個(gè)數(shù)據(jù)量的時(shí)候，也沒(méi)人愿意碰這東西。總之，不要為了大數(shù)據(jù)而大數(shù)據(jù)。


三、方案很多，企業(yè)要怎樣選擇呢

環(huán)境太復(fù)雜，但是我想至少要從下面這幾個(gè)方面去考慮吧。

1.目的：什么樣的目的？就是文中開始部分的三種情況呀（不好意思，自大了，肯定有其它情況，歡迎向“jiago王”補(bǔ)充），或者是其中幾個(gè)的組合。

做事方法都一樣，哪怕是中午出去吃飯，也是要在心里有個(gè)目的，這頓飯是為了吃飽，還是吃爽，或者為了拍別人的馬屁，然后才好選擇去吃什么。

當(dāng)然，要明確數(shù)據(jù)平臺(tái)的建設(shè)目的，哪里是那么容易的，初衷與討論后確認(rèn)的目標(biāo)或許是不一致的。

公司要搭建一個(gè)數(shù)據(jù)平臺(tái)的初衷可能很簡(jiǎn)單，只是為了減輕業(yè)務(wù)系統(tǒng)的壓力，將數(shù)據(jù)拉出來(lái)后再分析，如果目的真的就這么單純，還真的沒(méi)有必要大動(dòng)干戈了。如果是獨(dú)立系統(tǒng)的話，直接將業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫(kù)復(fù)制出來(lái)一份就好了；如果是多系統(tǒng)，選類似finecube那種型敏捷型的商業(yè)數(shù)據(jù)產(chǎn)品也夠了，快速建模，直接用finebi或者finereport接入進(jìn)去就能實(shí)現(xiàn)數(shù)據(jù)的可視化與olap分析。

但是，既然已經(jīng)決定要將數(shù)據(jù)平臺(tái)獨(dú)立出來(lái)了，就不再多考慮一點(diǎn)嗎？多個(gè)系統(tǒng)的數(shù)據(jù)，不趁機(jī)梳理整合一下？當(dāng)前只有分析業(yè)務(wù)數(shù)據(jù)的需求，以后會(huì)不會(huì)考慮到歷史數(shù)據(jù)呢？這種敏捷的方案能夠支撐明年、后年的需求嗎？

任何公司要搭建數(shù)據(jù)平臺(tái)，都不是一件小事，多花一兩個(gè)月實(shí)施你可能覺(jué)得累，多花一周兩周的時(shí)間，認(rèn)真的思考一下總可以的吧。雷軍不是說(shuō)過(guò)這樣一句話：不能以戰(zhàn)術(shù)上的勤奮，掩蓋戰(zhàn)略上的懶惰。


2.數(shù)據(jù)量：根據(jù)公司的數(shù)據(jù)規(guī)模選擇合適的方案，這里說(shuō)多了都是廢話。

3.成本：包括時(shí)間成本和金錢，不必多說(shuō)。但是這里有一個(gè)問(wèn)題想提一下，發(fā)現(xiàn)很多公司，要么不上數(shù)據(jù)平臺(tái)，一旦有了這樣的計(jì)劃，就恨不得馬上把平臺(tái)搭出來(lái)用起來(lái)，時(shí)間成本不肯花，這樣的情況很容易考慮欠缺，也容易被數(shù)據(jù)實(shí)施方忽悠。


關(guān)于方案選擇的建議，舉以下3+1個(gè)場(chǎng)景

場(chǎng)景a：要實(shí)現(xiàn)對(duì)業(yè)務(wù)數(shù)據(jù)的快速提取和分析，多個(gè)業(yè)務(wù)系統(tǒng)，沒(méi)有達(dá)到海量數(shù)據(jù)，不考慮歷史數(shù)據(jù)，不需要依照業(yè)務(wù)邏輯對(duì)數(shù)據(jù)進(jìn)行系統(tǒng)的梳理，這種情況下，可以考慮敏捷型的bi工具自帶的數(shù)據(jù)底層。

簡(jiǎn)單來(lái)講，這種場(chǎng)景僅僅是在技術(shù)層面上，完成對(duì)數(shù)據(jù)的整合與提速，并沒(méi)有從業(yè)務(wù)層面上對(duì)數(shù)據(jù)進(jìn)行建模。他可以滿足一定的分析需求，但是不能成為公司的數(shù)據(jù)中心。

場(chǎng)景b：要搭建公司級(jí)的數(shù)據(jù)中心，打通各系統(tǒng)之間的數(shù)據(jù)。非常明顯的，需要搭建一個(gè)數(shù)據(jù)倉(cāng)庫(kù)。這時(shí)就需要進(jìn)一步考慮公司數(shù)據(jù)的量級(jí)了，如果是小數(shù)據(jù)量，TB級(jí)以下，那么在傳統(tǒng)數(shù)據(jù)庫(kù)中建這樣一個(gè)數(shù)據(jù)倉(cāng)庫(kù)就可以了，如果數(shù)據(jù)量達(dá)到幾十上百TB，或者可見(jiàn)的在未來(lái)幾年內(nèi)數(shù)據(jù)會(huì)達(dá)到這樣一個(gè)規(guī)模，可以將倉(cāng)庫(kù)搭在greenplum中。

這種場(chǎng)景應(yīng)該是適用于大部分公司，對(duì)于大部分企業(yè)來(lái)說(shuō)，數(shù)據(jù)量都不會(huì)PB級(jí)別，更多的是在TB級(jí)以下。


場(chǎng)景c：公司數(shù)據(jù)爆發(fā)式增長(zhǎng)，原有的數(shù)據(jù)平臺(tái)無(wú)法承擔(dān)海量數(shù)據(jù)的處理，那么就建議考慮hadoop這種大數(shù)據(jù)平臺(tái)了。它一定是公司的數(shù)據(jù)中心，這樣一個(gè)角色，倉(cāng)庫(kù)是少不了的，可以將原來(lái)的倉(cāng)庫(kù)直接搬到hive中去。這種數(shù)據(jù)量比較大的情況要怎樣呈現(xiàn)，因?yàn)閔ive的性能較差，它的即席查詢可以接impala，也可以接greenplum，因?yàn)閕mpala的并發(fā)量不是那么高，而greenplum正好有它的外部表（也就是greenplum創(chuàng)建一張表，表的特性叫做外部表，讀取的內(nèi)容是hadoop的hive里的），正好和hadoop完美的融合（當(dāng)然也可以不用外部表）。

場(chǎng)景d：這個(gè)是后面補(bǔ)充的，當(dāng)公司原本有一個(gè)數(shù)據(jù)倉(cāng)庫(kù)，但歷史數(shù)據(jù)了堆積過(guò)多，分析性能下降，要怎么辦？?jī)蓚€(gè)方案可以考慮，比較長(zhǎng)遠(yuǎn)的，可以將倉(cāng)庫(kù)以及數(shù)據(jù)遷移到greenplum中，形成一個(gè)新的數(shù)據(jù)平臺(tái)，一個(gè)獨(dú)立的數(shù)據(jù)平臺(tái)，可以產(chǎn)生更多的可能性；比較快速的，是可以將類似finecube那種敏捷型數(shù)據(jù)產(chǎn)品接入原來(lái)的倉(cāng)庫(kù)，這樣來(lái)提升數(shù)據(jù)的處理性能，滿足分析的要求。


四、關(guān)于方案選型時(shí)可能會(huì)出現(xiàn)的誤區(qū)

忽略業(yè)務(wù)的復(fù)雜性，要用工具來(lái)解決或者是繞開業(yè)務(wù)的邏輯。

這個(gè)是我最近遇到過(guò)的，客戶要做報(bào)表平臺(tái)，有三個(gè)業(yè)務(wù)系統(tǒng)的數(shù)據(jù)需要整合。但是急于變現(xiàn)，不想搭建傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)，所以從敏捷型的bi工具中選型。工具廠商對(duì)自己數(shù)據(jù)產(chǎn)品的描述，一般著重于他的快速實(shí)施、性能的優(yōu)化、以及自帶的基本etl功能。這樣容易給客戶造成誤區(qū)，就是通過(guò)這一產(chǎn)品可快速搭建出一個(gè)公司級(jí)別的數(shù)據(jù)中心，滿足于頂層對(duì)數(shù)據(jù)的需求。

然而在后期突然意識(shí)到，工具所解決的，僅僅是在技術(shù)層面上簡(jiǎn)化了工具的使用的復(fù)雜性，把etl和數(shù)據(jù)集市封裝在一起，并且提高了數(shù)據(jù)的性能，但是并沒(méi)有從業(yè)務(wù)層面上實(shí)現(xiàn)數(shù)據(jù)的建模，很多細(xì)節(jié)問(wèn)題無(wú)法處理。

雖然敏捷開發(fā)非常誘人，如果業(yè)務(wù)系統(tǒng)簡(jiǎn)單，或者只需要分析當(dāng)前狀態(tài)的業(yè)務(wù)數(shù)據(jù)，不需要公司級(jí)的數(shù)據(jù)中心，那么確實(shí)是一個(gè)非常好的方案。然而這些問(wèn)題還沒(méi)有考慮清楚，對(duì)敏捷產(chǎn)品有了過(guò)高的期望，后面是會(huì)遇到些麻煩的。

除此之外，可能還會(huì)有為了大數(shù)據(jù)而大數(shù)據(jù)的，但是這些我在實(shí)際的工作中還沒(méi)有遇到。


最后總結(jié)一下，企業(yè)選擇數(shù)據(jù)平臺(tái)的方案，有著不同的原因，要合理的選型，既要充分的考慮搭建數(shù)據(jù)平臺(tái)的目的，也要對(duì)各種方案有著充分的認(rèn)識(shí)。

僅從個(gè)人的角度，對(duì)于數(shù)據(jù)層面來(lái)說(shuō)，還是傾向于一些靈活性很強(qiáng)的方案的，因?yàn)閿?shù)據(jù)中心對(duì)于公司來(lái)說(shuō)太重要了，我更希望它是透明的，是可以被自己完全掌控的，這樣才有能力實(shí)現(xiàn)對(duì)數(shù)據(jù)中心更加充分的利用。因?yàn)椋?b>我不知道未來(lái)需要它去承擔(dān)一個(gè)什么樣的角色。


ps：數(shù)據(jù)平臺(tái)的建設(shè)，是一個(gè)不小的項(xiàng)目，實(shí)施周期過(guò)長(zhǎng)，會(huì)不會(huì)途中夭折？這鍋誰(shuí)都不想背，這樣的項(xiàng)目，怎樣才能迭代起來(lái)，逐步實(shí)施逐步投放？我先把問(wèn)題放在這，呵呵。


原創(chuàng)文章，轉(zhuǎn)載請(qǐng)私信作者