數(shù)據(jù)平臺(tái)的建設(shè)

數(shù)據(jù)平臺(tái)的建設(shè)方案數(shù)據(jù)平臺(tái)的建設(shè)方案公司要做數(shù)據(jù)分析和報(bào)表系統(tǒng)，首先要考慮數(shù)據(jù)的準(zhǔn)備，也就是數(shù)據(jù)平臺(tái)的建設(shè)，最近接觸了幾個(gè)客戶都處于這一環(huán)節(jié)，而且其中在方案選型過(guò)程中，也是充滿了糾結(jié)，而我也并沒(méi)有在開(kāi)始階段給出合理全面的建議。一、為何而搭建數(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.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è)有哪些方案可以選擇如果一句話回答的話，那就是：太多了，但確實(shí)有非常多的方案可供選擇，我懂的少，肯定是無(wú)法一一介紹，所以就分成了下面幾類，相信也一定程度上覆蓋了部分企業(yè)的需求了。1.常規(guī)數(shù)據(jù)倉(cāng)庫(kù)：概念不說(shuō)了，既然是做數(shù)據(jù)這一行的，相信大家都比較清楚，不清楚的可以百度。它的重點(diǎn)在于數(shù)據(jù)整合，同時(shí)也是對(duì)業(yè)務(wù)邏輯的一個(gè)梳理。雖然它也可以打包成ssas（多維數(shù)據(jù)集）那種cube（多維數(shù)據(jù)庫(kù)）一類的東西來(lái)提升數(shù)據(jù)的讀取性能，但是數(shù)據(jù)倉(cāng)庫(kù)的作用，更多的是為了解決公司的業(yè)務(wù)問(wèn)題，而不僅僅是性能問(wèn)題。這一點(diǎn)后面會(huì)詳細(xì)介紹。優(yōu)點(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)滿足變更的需求。同時(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)單，敏捷開(kāi)發(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)品就夠了。靈活性低，這個(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)生的。greenplumgreenplum的數(shù)據(jù)庫(kù)引擎是基于postgresql的，并且通過(guò)Interconnnect連接實(shí)現(xiàn)了對(duì)同一個(gè)集群中多個(gè)postgresql實(shí)例的高效協(xié)同和并行計(jì)算。同時(shí)，基于同時(shí)，基于greenplum的數(shù)據(jù)平臺(tái)建設(shè)，可以實(shí)現(xiàn)兩個(gè)層面的處理，顯而易見(jiàn)的一個(gè)是對(duì)數(shù)據(jù)處理性能的處理，greenplum數(shù)據(jù)庫(kù)宣稱支持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)證的。缺點(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)部門(mén)嚇到吧。另一個(gè)是實(shí)施成本，這里主要是人了，基本的是greenplum的安裝配置，再到greenplum中數(shù)據(jù)倉(cāng)庫(kù)的構(gòu)建，都需要人和時(shí)間。技術(shù)門(mén)檻，這里是相對(duì)于上一個(gè)敏捷型數(shù)據(jù)集市的，greenplum的門(mén)檻肯定是要高一點(diǎn)了。4.hadoop分布式系統(tǒng)架構(gòu)關(guān)于hadoop，已經(jīng)火的要爆炸了，greenplum的開(kāi)源跟它也是脫不了關(guān)系的。有著高可靠性、高擴(kuò)展性、高效性、高容錯(cuò)性的口碑。在互聯(lián)網(wǎng)領(lǐng)域有非常廣泛的運(yùn)用，雅虎、facebook、百度、淘寶、京東等。hadoop生態(tài)體系非常龐大，各公司基于hadoop所實(shí)現(xiàn)的也不僅限于數(shù)據(jù)平臺(tái)，也包括數(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ō)，對(duì)于企業(yè)構(gòu)建數(shù)據(jù)平臺(tái)來(lái)說(shuō)，hadoop的優(yōu)勢(shì)與劣勢(shì)非常明顯：它的大數(shù)據(jù)的處理能力、高可靠性、高容錯(cuò)性、開(kāi)源性以及低成本（為什么說(shuō)低成本，要處理同樣規(guī)模的數(shù)據(jù)，換一個(gè)其他方案試試）。缺點(diǎn)也就是他的體系的復(fù)雜，技術(shù)門(mén)檻較高（能搞定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.目的：什么樣的目的？就是文中開(kāi)始部分的三種情況吧，或者是其中幾個(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)，選型敏捷型的商業(yè)數(shù)據(jù)產(chǎn)品也夠了，快速建模，直接用工具進(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)，任何公司要搭建數(shù)據(jù)平臺(tái)，都不是一件小事，多花一兩個(gè)月實(shí)施你可能覺(jué)得累，多花一周兩周的時(shí)間，認(rèn)真的思考一下總可以的吧。雷軍不是說(shuō)過(guò)這樣一句話：不能以戰(zhàn)術(shù)上的勤奮，掩蓋戰(zhàn)略上的懶惰。些地方，些地方，是hadoop缺少的能力，集算器在hadoop里定位為計(jì)算引擎，能接不同的組件，提供高性能的計(jì)算。四、關(guān)于方案選型時(shí)可能會(huì)出現(xiàn)的誤區(qū)忽略業(yè)務(wù)的復(fù)雜性，要用工具來(lái)解決或者是繞開(kā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ú)法處理。雖然敏捷開(kāi)發(fā)非常誘人，如果業(yè)務(wù)系統(tǒng)簡(jiǎn)單，或者只需要分析當(dāng)前