文章轉(zhuǎn)載自知乎專欄“撩撩數(shù)據(jù)吧”。原文鏈接：https://zhuanlan.zhihu.com/p/21486408?refer=jiago

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

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

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

正文

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

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

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

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

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

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

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

3.性能問題，公司可以越做越大距误，同樣的數(shù)據(jù)也會(huì)越來越大簸搞”馕唬可能是歷史數(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í)有非常多的方案可供選擇，我懂的少憔涉，肯定是無法一一介紹订框，所以就分成了下面幾類，相信也一定程度上覆蓋了大部分企業(yè)的需求了兜叨。

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

關(guān)于這一方案的優(yōu)缺點(diǎn)被环，不寫沒用的糙及，直接說重點(diǎn)了：

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

方案成熟，關(guān)于數(shù)據(jù)倉庫的架構(gòu)筛欢，不管是Inmon架構(gòu)還是Kimball架構(gòu)浸锨，都有著非常廣泛的應(yīng)用唇聘，而且相信能將這兩種架構(gòu)落地的人也不少。

實(shí)施簡(jiǎn)單揣钦，涉及的技術(shù)層面主要是倉庫的建模以及etl的處理雳灾，很多軟件公司具備數(shù)據(jù)倉庫的實(shí)施能力，實(shí)施難度的大小更多的取決于業(yè)務(wù)邏輯的復(fù)雜程度冯凹，而并非技術(shù)上的實(shí)現(xiàn)谎亩。

靈活性強(qiáng)，說這句話要有對(duì)應(yīng)場(chǎng)景的宇姚，數(shù)據(jù)倉庫的建設(shè)是透明的匈庭，如果需要，可以對(duì)倉庫的模型浑劳、etl邏輯進(jìn)行修改阱持，來滿足變更的需求（當(dāng)然，最好設(shè)計(jì)之初考慮的周全一點(diǎn)）魔熏。同時(shí)對(duì)于上層的分析而言衷咽，通過sql或者mdx對(duì)倉庫數(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ù)庫系統(tǒng)）植兰，這個(gè)量級(jí)的數(shù)據(jù)，而相當(dāng)一部分企業(yè)的數(shù)據(jù)璃吧，還是很難超過這個(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ù)的處理速度驮宴。目前來看，這些產(chǎn)品都達(dá)到了以上的目的呕缭。但它的優(yōu)缺點(diǎn)也比較明顯堵泽。

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

部署簡(jiǎn)單，敏捷開發(fā)恢总，這也是這類產(chǎn)品最大的優(yōu)點(diǎn)迎罗，和數(shù)據(jù)倉庫相比，實(shí)施周期要短的多片仿。實(shí)際上它也沒什么嚴(yán)格的實(shí)施的概念纹安，因?yàn)檫@類產(chǎn)品只是針對(duì)需要分析的數(shù)據(jù)，進(jìn)行局部的關(guān)聯(liá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ǔ)的努隙。但無疑都一定程度上提高了數(shù)據(jù)的處理性能球恤。

缺點(diǎn)：

首先，它是要收費(fèi)的荸镊。

無法處理復(fù)雜的業(yè)務(wù)邏輯咽斧，這只是一個(gè)工具，它無法解決業(yè)務(wù)問題躬存。這類工具中自帶簡(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è)觀念是需要清楚的，不能指望一款工具來解決業(yè)務(wù)問題根悼。這種數(shù)據(jù)產(chǎn)品僅僅是對(duì)當(dāng)前的業(yè)務(wù)數(shù)據(jù)進(jìn)行簡(jiǎn)單的整合凶异，第一，數(shù)據(jù)是局部的挤巡，第二唠帝，時(shí)間是當(dāng)前的（其涵帶的增量更新或者全量更新，是無法應(yīng)對(duì)復(fù)雜的邏輯的玄柏，相信熟悉etl的人都知道這個(gè)過程有多復(fù)雜）襟衰。當(dāng)然，對(duì)于一些公司來說粪摘，可能需求只是對(duì)當(dāng)前業(yè)務(wù)數(shù)據(jù)進(jìn)行整合分析瀑晒，那么這類產(chǎn)品就夠了。（說實(shí)話徘意，很多公司真的是懶得更長(zhǎng)遠(yuǎn)的考慮苔悦，有一天沒一天的，誰說的準(zhǔn)呢）

靈活性低椎咧，這個(gè)也是沒法避免的玖详，越是操作簡(jiǎn)單的工具，他的靈活性肯定受限勤讽，因?yàn)榉庋b住了蟋座，產(chǎn)品是不透明的，常規(guī)的需求用起來非常方便脚牍，但是遇到復(fù)雜的向臀，發(fā)現(xiàn)對(duì)他內(nèi)部不了解，你也沒法修改诸狭，只有蛋疼的份券膀。

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

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

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

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

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

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

海量數(shù)據(jù)的支持，大量成熟的應(yīng)用案例晌坤，所以我想這一點(diǎn)是不用懷疑的逢艘。

擴(kuò)展性，據(jù)說可線性擴(kuò)展到10000個(gè)節(jié)點(diǎn)骤菠，并且每增加一個(gè)節(jié)點(diǎn)它改，查詢、加載性能都成線性增長(zhǎng)娩怎。

易用性搔课，不需要復(fù)雜的調(diào)優(yōu)需求胰柑，并行處理由系統(tǒng)自動(dòng)完成截亦。依然是sql作為交語言，簡(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)：

本身來說称龙，它的定位在olap領(lǐng)域，不擅長(zhǎng)oltp交易系統(tǒng)戳晌。當(dāng)然我們搭建公司的數(shù)據(jù)中心也不會(huì)是用來做交易系統(tǒng)的鲫尊。

成本，兩個(gè)方面的考慮沦偎，一是硬件成本疫向，greenplum有其推薦的硬件規(guī)格，對(duì)內(nèi)存豪嚎、網(wǎng)卡都有要求搔驼。當(dāng)然，在硬件選型上侈询，需要達(dá)到一個(gè)平衡舌涨，要在性能、容量扔字、成本等多方面考慮囊嘉，畢竟不能一味的追求性能，把采購部門嚇到吧革为。另一個(gè)是實(shí)施成本扭粱，這里主要是人了，基本的是greenplum的安裝配置震檩，再到greenplum中數(shù)據(jù)倉庫的構(gòu)建琢蛤，都需要人和時(shí)間蜓堕。（但是必須要說的是，人家軟件都開源了博其，也省下了一筆錢疤撞拧）

技術(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è)所要解決的也不僅是性能問題糠聪，還會(huì)包括時(shí)效問題、更復(fù)雜的分析挖掘功能的實(shí)現(xiàn)等谐鼎。非常典型的實(shí)時(shí)計(jì)算體系也與hadoop這一生態(tài)體系有著緊密的聯(lián)系舰蟆。

近些年來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)來說牵触，hadoop的優(yōu)勢(shì)與劣勢(shì)非常明顯：它的大數(shù)據(jù)的處理能力淮悼、高可靠性、高容錯(cuò)性揽思、開源性以及低成本（為什么說低成本袜腥，要處理同樣規(guī)模的數(shù)據(jù)，換一個(gè)其他方案試試呢）钉汗。缺點(diǎn)也就是他的體系的復(fù)雜羹令，技術(shù)門檻較高（能搞定hadoop的公司規(guī)模一般都不小了）。

關(guān)于hadoop的優(yōu)缺點(diǎn)對(duì)于公司的數(shù)據(jù)平臺(tái)選型來說损痰，影響已經(jīng)不大了福侈。需要上hadoop的時(shí)候，也沒什么其它的方案好選擇（要么太貴卢未，要么不行），沒到達(dá)這個(gè)數(shù)據(jù)量的時(shí)候，也沒人愿意碰這東西垂蜗〖鼗郑總之，不要為了大數(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ù)拉出來后再分析，如果目的真的就這么單純郁惜，還真的沒有必要大動(dòng)干戈了堡距。如果是獨(dú)立系統(tǒng)的話，直接將業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫復(fù)制出來一份就好了兆蕉；如果是多系統(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ú)立出來了劝术，就不再多考慮一點(diǎn)嗎缩多？多個(gè)系統(tǒng)的數(shù)據(jù)，不趁機(jī)梳理整合一下养晋？當(dāng)前只有分析業(yè)務(wù)數(shù)據(jù)的需求衬吆，以后會(huì)不會(huì)考慮到歷史數(shù)據(jù)呢？這種敏捷的方案能夠支撐明年绳泉、后年的需求嗎逊抡？

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

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

3.成本：包括時(shí)間成本和金錢，不必多說榆骚。但是這里有一個(gè)問題想提一下片拍，發(fā)現(xiàn)很多公司，要么不上數(shù)據(jù)平臺(tái)妓肢，一旦有了這樣的計(jì)劃捌省，就恨不得馬上把平臺(tá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)恭金，沒有達(dá)到海量數(shù)據(jù)操禀，不考慮歷史數(shù)據(jù)褂策，不需要依照業(yè)務(wù)邏輯對(duì)數(shù)據(jù)進(jìn)行系統(tǒng)的梳理，這種情況下颓屑，可以考慮敏捷型的bi工具自帶的數(shù)據(jù)底層斤寂。

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

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

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

場(chǎng)景c：公司數(shù)據(jù)爆發(fā)式增長(zhǎng)，原有的數(shù)據(jù)平臺(tái)無法承擔(dān)海量數(shù)據(jù)的處理昔瞧，那么就建議考慮hadoop這種大數(shù)據(jù)平臺(tái)了指蚁。它一定是公司的數(shù)據(jù)中心，這樣一個(gè)角色自晰，倉庫是少不了的凝化，可以將原來的倉庫直接搬到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ù)倉庫深员，但歷史數(shù)據(jù)了堆積過多负蠕，分析性能下降，要怎么辦倦畅？?jī)蓚€(gè)方案可以考慮遮糖，比較長(zhǎng)遠(yuǎn)的，可以將倉庫以及數(shù)據(jù)遷移到greenplum中叠赐，形成一個(gè)新的數(shù)據(jù)平臺(tái)欲账，一個(gè)獨(dú)立的數(shù)據(jù)平臺(tái)，可以產(chǎn)生更多的可能性芭概；比較快速的赛不，是可以將類似finecube那種敏捷型數(shù)據(jù)產(chǎn)品接入原來的倉庫，這樣來提升數(shù)據(jù)的處理性能谈山，滿足分析的要求俄删。

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

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

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

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

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

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

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

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

ps：數(shù)據(jù)平臺(tái)的建設(shè)，是一個(gè)不小的項(xiàng)目馅精，實(shí)施周期過長(zhǎng)严嗜，會(huì)不會(huì)途中夭折？這鍋誰都不想背洲敢，這樣的項(xiàng)目漫玄，怎樣才能迭代起來，逐步實(shí)施逐步投放沦疾？我先把問題放在這称近，呵呵第队。

作者：知乎達(dá)人“jiago王”，知乎專欄“撩撩數(shù)據(jù)吧”刨秆。帆軟數(shù)據(jù)人凳谦，樂于交流的數(shù)據(jù)小兵。