今天和大家分享的內容主要就是怎么樣從0到N來建一個大數(shù)據(jù)平臺。其實，每一個大數(shù)據(jù)平臺都不是憑空而起的，每個企業(yè)剛剛開始數(shù)據(jù)分析的時候，也不是上來就是一個大數(shù)據(jù)開源平臺Hadoop、Spark這樣一個存儲的。今天分享的內容，其實是根據(jù)企業(yè)發(fā)展的不同階段，針對業(yè)務的需求來選擇不同的大數(shù)據(jù)架構，配置不同規(guī)模的數(shù)據(jù)處理人員，根據(jù)企業(yè)不同的時間點，幫助企業(yè)從0到N，建立高性價比的大數(shù)據(jù)平臺。

從0到N——數(shù)據(jù)大時代的劃分

第一個先說從0到N大數(shù)據(jù)的時代劃分，其實大數(shù)據(jù)時代不是現(xiàn)在才開始的，它早在以前就開始了，只不過那時候不叫大數(shù)據(jù)，在最開始的時候叫數(shù)據(jù)倉庫。十年前，它在做企業(yè)內部的ERP、CRM的相對的一些集成。然后把里面做一些BI的分析報表，做一些數(shù)據(jù)挖掘。那個時候最著名的例子應該是啤酒和尿片的故事，就是關聯(lián)數(shù)據(jù)挖掘能分析出來，周末男人經(jīng)常去買尿片和啤酒故事。到后來互聯(lián)網(wǎng)的出現(xiàn)大數(shù)據(jù)進入了Web2.0時代。在過去大家只是拿到一些用戶結構化的交易信息和用戶的聯(lián)系信息，現(xiàn)在可以獲得每一個人上網(wǎng)的點擊流的信息，根據(jù)你的點擊的情況做一些推薦。包括一些現(xiàn)在的猜你喜歡和搜索引擎排名，這些都是在Web2.0時候基于你在點擊流的大數(shù)據(jù)的檢索和大數(shù)據(jù)的一些處理。第三個階段，現(xiàn)在我們所處的階段，我認為就是IoT O2O時代，現(xiàn)在大家一講到大數(shù)據(jù)，其實不僅僅包括了上網(wǎng)的行為日志，還包括像現(xiàn)在智能Wi-Fi與智能POS(感知在線下，一個在逛商場的時候，你在哪里停留了，停了多久，進了哪家店，吃了什么東西，唱了什么歌，看了什么電影這樣的數(shù)據(jù))把這些東西全部能收上來。還包括像現(xiàn)在的一些可穿戴的設備，去檢測你的健康信息，也包括圖象的識別、錄像的分析，這些都是在現(xiàn)在這個時代大數(shù)據(jù)囊括的內容。

大家能感覺到，隨著大數(shù)據(jù)時代的發(fā)展，從1.0，2.0到現(xiàn)在3.0，它離消費者的距離是越來越近了，過去原來都是高高在上，數(shù)據(jù)結果都是在相關的企業(yè)決策者的眼里，而現(xiàn)在其實我們都可以把它穿戴在身上，從手機上就能看到一些相關的數(shù)據(jù)的分析和相關的結果，整個數(shù)據(jù)對業(yè)務的影響力也是由弱慢慢變強，現(xiàn)在基本上如果一個企業(yè)沒有一個數(shù)據(jù)決策，這個企業(yè)很難去運轉。

從0到N——大數(shù)據(jù)時代企業(yè)劃分

說過大數(shù)據(jù)時代的劃分，下面來給大家介紹下我定義的大數(shù)據(jù)時代的企業(yè)劃分，這里面我做了一個小的比喻，我根據(jù)一個企業(yè)的數(shù)量量，然后根據(jù)它的技術人員的分布，我去把它分成幼兒園、小學、中學、大學、碩士、博士等等。最后單獨拿一個模板給傳統(tǒng)企業(yè)。這里面的提到的PV數(shù)，如果你不是互聯(lián)網(wǎng)的企業(yè)也沒關系，你可以用你的企業(yè)每天日增的數(shù)據(jù)的處理條數(shù)，因為數(shù)據(jù)量其實決定了企業(yè)的技術框架復雜度和你的處理的人員多少。這里分別劃分了幾種：五萬、五十萬、五百萬、五千萬、五十億條，大于五十億條。數(shù)據(jù)技術人員的多少跟每一個企業(yè)發(fā)展階段都是有直接關系的，具體情況參見上圖，不再贅述。單獨把傳統(tǒng)企業(yè)拎出來，因為它稍微特殊，除了數(shù)據(jù)量的量級之外，傳統(tǒng)行業(yè)的技術人員做大數(shù)據(jù)的人一般都比較匱乏，現(xiàn)在像零售、醫(yī)療、銀行等等其實都是這個狀態(tài)，而它的數(shù)據(jù)需求特別多，既需要OLAP，又要做挖掘，還要做個性推薦，對數(shù)據(jù)還有做一些數(shù)據(jù)產(chǎn)品，想法非常多，我們到后面也討論一下，傳統(tǒng)企業(yè)做大數(shù)據(jù)的時候要注意什么。

這個是我對不同數(shù)據(jù)階段的劃分，下面逐步介紹不同階段適合的框架。

大學之前的基本框架

先說說大學之前的框架，就是所有的這些數(shù)據(jù)處理的基本框架，在大學之前其實無外乎分為以下幾個模塊：數(shù)據(jù)處理調度模塊，數(shù)據(jù)展示工具，結構化數(shù)據(jù)存儲(非結構化處理后放入結構化存儲)。非結構化數(shù)據(jù)也可以用第三方的一些免費的分析工具，具體每個階段略有不同。

先說說大學之前的框架，就是所有的這些數(shù)據(jù)處理的基本框架，在大學之前其實無外乎分為以下幾個模塊：數(shù)據(jù)處理調度模塊，數(shù)據(jù)展示工具，結構化數(shù)據(jù)存儲(非結構化處理后放入結構化存儲)。非結構化數(shù)據(jù)也可以用第三方的一些免費的分析工具，具體每個階段略有不同。

先講講幼兒園階段，此時數(shù)據(jù)專職人員幾乎沒有，主要都是結構化的數(shù)據(jù)。結構化數(shù)據(jù)在這個量級的時候每天五萬條，用Mysql即可存儲，數(shù)據(jù)處理調度的時候，不用專門復雜的ETL工具，用Shell+JAVA處理即可(此時企業(yè)也沒有專職數(shù)據(jù)處理人員)。展示工具在這個階段的時候，不用買什么工具，這里我強烈推薦Excel，待會我給大家講講為什么推薦它。對于非結構化數(shù)據(jù)，這個量級有很多第三方的免費工具，如果需要可以挑選一個使用。

幼兒園基本框架

Excel是小數(shù)據(jù)量最好分析工具

• 所見即所得
• 產(chǎn)品使用方便，人員易上手
• 支持各種定制化展示
• 支持簡單的數(shù)據(jù)挖掘
• 業(yè)務部門容易使用 無招勝有招 多少金融模型來自于Excel

為什么推崇Excel?到目前為止，個人一直認為Excel是小數(shù)據(jù)量的最好的分析工具，沒有之一。第一，所見即所得，所有的數(shù)據(jù)處理和數(shù)據(jù)挖掘工具沒有一個就像Excel一樣，簡單拖拖拽拽即可實現(xiàn)，旋轉透視表、關聯(lián)分析挖掘、或者回歸分析完全就在一個界面上就能處理好，沒有一個工具能比得上它。第二點是使用方便，人員易上手，對業(yè)務人員不用做什么培訓，用Excel業(yè)務人員就能做出各種各樣的分析報表，非常高效。第三，支持各種個性化的展示。如右圖，在頁面上面能畫出來比較炫酷的這些圖，Excel基本都支持,包括支持地圖上展示熱區(qū)圖等，具體的方法，大家自行谷歌一下。第四，支持簡單的數(shù)據(jù)挖掘。Excel支持大部分的基本數(shù)據(jù)挖掘算法，比如關聯(lián)分析，決策樹分類等，方法大家自行谷歌。 Excel我認為在數(shù)據(jù)量級不超過十萬條的時候是最好的分析工具。所以用Mysql把這個數(shù)據(jù)做一下匯總，Excel直接展示，這也是在幼兒園階段對你來講最好的一個分析框架了。有些人會說用Excel不是大數(shù)據(jù)，但是到現(xiàn)在為止，很多數(shù)據(jù)分析師還在用Excel，個人認為無招勝有招，不在乎工具是怎么樣，而是在乎你背后分析思路和分析的經(jīng)驗是如何。大家知道現(xiàn)在很多大家都說金融股票分析什么這些都非常高深，用各種量化模型，但是大家知道，很多金融模型都是來自Excel的，對于最基本的分析工具Excel，我向大家強烈推薦一下，無論哪個階段一定要深學活用。

第三方分析——易觀方舟幫助你分析頁面流量

• 支持網(wǎng)頁和APP
• SDK只有66k
• 省去了各種數(shù)據(jù)加工的麻煩
• 基本指標一應俱全
• 目前開放的基本功能，永久免費
• 功能不斷在迭代

對于在這個階段，互聯(lián)網(wǎng)非結構化分析有很多像友盟和方舟這樣的免費分析工具。我在易觀就簡單說易觀的方舟，通過易觀的業(yè)界最小的 SDK(Android只有66K)就可以看到各種基本的分析指標，存儲和處理都不用操心了。基本的這些指標一應俱全，而且永久免費，指標數(shù)據(jù)可以下載回本地，如果需要明細數(shù)據(jù)回傳服務也可以單聊。這個階段，最重要的是把企業(yè)把業(yè)務流程打通，先活下來，這是在幼兒園這個階段。

集美貌與智慧一身的“SQL Server”

為什么是SQL Server?

一個軟件覆蓋了這個階段數(shù)據(jù)處理的所有功能

• 支持各種數(shù)據(jù)源的集成
• 支持ETL調度
• 支持報表展示
• 支持OLAP
• 數(shù)據(jù)量在幾億條之內(每天50萬，一年1.5億)，查詢效率OK，如果擴展cluster，支持更好。
• 小數(shù)據(jù)分析神器Excel，完美結合，擴展了數(shù)據(jù)挖掘，展
• 現(xiàn)等功能
• 缺點：數(shù)據(jù)量大以后，效率跟不上

在小學階段的企業(yè)基本上有一點數(shù)據(jù)了，每天大概有五十萬條這樣的數(shù)據(jù)，有一些數(shù)據(jù)的處理專職人員了，1到2個人。需要有ETL工具和一定數(shù)據(jù)量級的數(shù)據(jù)存儲。這個時候，向小企業(yè)隆重推薦一個繼承解決方案就是SQL Server。提到SQL Server其實也有很多人在鄙視，聽上去一點都不高大上，怎么能叫大數(shù)據(jù)?但其實大家知道嗎?無論是現(xiàn)在已經(jīng)火的京東，還是現(xiàn)在的美團，剛剛起步的時候都曾經(jīng)經(jīng)過SQL Server做數(shù)據(jù)分析的階段。我把SQL Server叫做“集美貌與智慧于一身”，為什么這么說?其實SQL Server其實是它目前唯一一款軟件，覆蓋了這個階段數(shù)據(jù)處理分析的所有功能，支持各種數(shù)據(jù)源的支撐。因為企業(yè)在這個數(shù)據(jù)量級的時候，源數(shù)據(jù)庫有多個異構數(shù)據(jù)庫和異構數(shù)據(jù)來源，需要一個比較強大的ETL工具做集中數(shù)據(jù)存儲。在這個階段，可以利用SQL Server自身集成帶的一個東西叫SSIS，SSIS組件是一個簡化版的ETL處理工具，你購買了SQL Server，你不用再需要購買一個ETL工具。此外，SQL Server還集成SSRS，它是一個網(wǎng)頁報表系統(tǒng)，這個東西本身還支持OLAP引擎，你不需要再單獨買一套報表的展現(xiàn)工具，對于這個階段的企業(yè)來講，大部分需求也足夠使用。第四個是OLAP引擎，就是上鉆下鉆旋轉這些OLAP特性SQL Server全都支持，而且在數(shù)據(jù)量級在幾億條以內，數(shù)據(jù)查詢效率OK。當然，如果企業(yè)比較富裕，你去購買Cognos、Tablau這樣的產(chǎn)品的話，支持會更好一些。最關鍵的，完美結合剛才提到的小數(shù)據(jù)分析神器Excel。Excel直接連上SqlServer，那基本上就如虎添翼，原來Excel只能十萬條，SQL Server擴展到一億條。當然此時第三方的工具還可以繼續(xù)用，你用的像方舟這些繼續(xù)可以使。那方舟里面，但這個階段除了剛才說PV、UV，現(xiàn)在可能就是分析一下這個頁面路徑了，就是這些人通過什么樣的路徑點擊進來，到你那觸達你的最終的購買路線的，這些人究竟它的轉化率怎么樣。包括一些留存分析，就是哪些用戶是老用戶，這些用戶留存情況怎么樣，是什么活動促銷進來的等等。這個問題是在這個階段肯定有的，但是用的工具不一定是易觀的方舟也有其他的工具。

傳統(tǒng)數(shù)據(jù)倉庫+日志分析工具

日增500萬，年度過5億以內，2-4個人，暫時還沒有人力搭建hadoop。

剛才講到了幼兒園小學，現(xiàn)在上中學了。為什此時我還在推薦商業(yè)組件而不是開源組件，是因為在此時，大部分企業(yè)還是以滿足企業(yè)內部需求為主，建立分析平臺的時間和效率往往比建立高大上的平臺有效切實的多，同時建立相關團隊也需要時間，使用商業(yè)組件可以提高整體的效率。在中學的時候，每日日增數(shù)據(jù)量基本上是五百萬量級，一般是小型的這些互聯(lián)網(wǎng)企業(yè)，或者小的傳統(tǒng)企業(yè)，此時，數(shù)據(jù)專職人員就有2到5個人了，這個數(shù)據(jù)量可能像一年下來可能要過十億條了，單機的SQL Server支持可能會有一些吃力。

目前這個階段，我個人的建議還是你不要上Hapdoop這樣大的平臺，建立Hapdoop平臺一定要10人以上的團隊規(guī)模，這個其實是一個坎兒，在這個時間不要著急搭這種復雜的Hapdoop平臺，但是對于您目前的企業(yè)數(shù)據(jù)量來講，你需要一些專業(yè)的數(shù)據(jù)處理工具和展示工具了，就是你的小的企業(yè)可能剛才我說的SqlServer這個解決方案，已經(jīng)不適合你了。那一般現(xiàn)在都有哪些?像數(shù)據(jù)處理調度的時候，因為剛才我提到說，SqlServer它自己集成，但是目前處理到SSIS，肯定是不能夠完全滿足你的要求了，于是就有比較專業(yè)的數(shù)據(jù)處理工具，有兩個比較商業(yè)上過去用的非常有名的，一個叫Informatica，另一個Datastage，這兩個其實都能滿足大部分的企業(yè)的數(shù)據(jù)處理的調度的需求，現(xiàn)在大部分銀行也在用。

當然今天我們追求性價比，所以我給大家介紹常用開源的工具，叫做Kettle，目前大部分中小公司Kettle用的其實還是最多的，因為它的功能比 Informatica、Datastage相比肯定要弱一些，但是比SSIS來講還是要更強一些，而且現(xiàn)在Kettle還支持了Hadoop、 Spark等等任務調度和監(jiān)控，還是擴展性在這個階段挺強的工具。

數(shù)據(jù)存儲在這里也有一個升級，原先的存儲在這個數(shù)據(jù)量級每年在15-20億條，此時需要更大型的數(shù)據(jù)存儲，比如說DB2、Oracle，這兩個都是商業(yè)的，就是現(xiàn)在目前也是過去在商業(yè)數(shù)據(jù)倉庫驗證比較好的。我們追求性價比，也可以用去年開源的Greenplum。GP其實在大數(shù)據(jù)行業(yè)里面還挺有名的，去年年底實現(xiàn)開源免費使用。GP是在上百億數(shù)據(jù)量級里面，唯一一個MPP架構且開源的數(shù)據(jù)存儲平臺，它的處理效率和DB2、Oracle一點不落后。

在展示方面，隨著業(yè)務量的增加，需求越來越多，也需要一些單獨的查詢展示工具。在這個環(huán)境下，數(shù)據(jù)量有一定數(shù)據(jù)量級了，但你的人不多，做自己的一些查詢工具可能還不行，你方式是買一些商用的工具來去做一個過渡，所以我在這里推薦幾個現(xiàn)在比較火的。Qlik Sense/Tablau這兩個我用過都還不錯，屬于新一代的展現(xiàn)工具，當然還有老牌的Cognos和BO等表現(xiàn)都中規(guī)中矩，建議展示工具和業(yè)務需求部門一起評審，選一個合適的即可。選擇合適的展示工具可以節(jié)約建立大數(shù)據(jù)平臺的大量時間。

開源的ELK——簡易日志分析平臺

ELK

• Logstash
• ElasticsSearch
• Kabana

優(yōu)點

• 搭建簡易
• 迅速滿足日志分析需求
• 自身具有多種展示方式

缺點

• 功能單一，只針對日志
• 擴展性不強

在中小學的時候，非結構化數(shù)據(jù)可以通過程序轉換為結構化數(shù)據(jù)再存入傳統(tǒng)結構化數(shù)據(jù)數(shù)據(jù)庫的同時使用第三方免費工具來分析處理。在這個數(shù)據(jù)量級的時候，你會發(fā)現(xiàn)很多臨時性的新需求，第三方免費的這些工具不夠用，這時候ELK就派上用場了，ELK，就是Logstash、 ElasticsSearch、Kabana縮寫。在這個時間點，其實如果你想要自己一些自主的，這種非結構化的日志類的分析，可以使用ELK分析。

在這個時候如果你的公司還沒有使用Python處理數(shù)據(jù)的話，一定要求你的技術人員開始使用Python，前面其實都沒有單獨對數(shù)據(jù)處理的語言對大家做限制，特別人比較少的時候，在這個時間點，一定需要讓你的人員從JAVA轉到Python去。Python有幾個這樣的好處，第一數(shù)據(jù)處理簡潔明快，比Java針對數(shù)據(jù)開發(fā)效率高很多。過去有一個語言叫做Perl，現(xiàn)在Python已經(jīng)取代了Perl的地位，成為一個數(shù)據(jù)處理的一個必會的語言。第二個好處是Python各種數(shù)據(jù)源和各種環(huán)境都支持，它的延展性特別高。第三個是Python支持各種數(shù)據(jù)挖掘的算法庫，基本上各種在Python的這種庫是最多的，甚至比JAVA還多。第四個是支持各種流式計算系統(tǒng)的框架，就是你將來學了Python以后，你可以順利地從中學上大學。所以在這個階段，我建議每一個企業(yè)在這個時候，去把Python腳本用起來。

第三方免費分析——易觀方舟的用戶畫像

• 人口屬性：設備群體特征
• 使用類型：都是使用什么類型的應用
• 使用類型時段：什么時間使用什么類型的APP
• 使用關聯(lián)分析：從哪里來，到哪里去
• 用戶偏好：用戶標簽

當然，在這個階段，第三方的數(shù)據(jù)平臺依然可以幫你做一些事情，比如說方舟的用戶畫像。因為這些功能的背后需要有大量的數(shù)據(jù)和大量的數(shù)據(jù)分析算法，來幫助你的企業(yè)告訴你，你的客戶它的設備群體是什么樣的，他們是在使用什么樣類型的應用，這些應用在什么時間段怎么使用。也能告訴你做一些關聯(lián)分析，就是你這個客戶在使用應用之前，他從哪里來到哪里去，還給你很多的一些用戶標簽。這些其實是你在用ELK，這些統(tǒng)計的東西都是沒有的，目前這個功能也是免費對外開放的，大家歡迎去使一下。

開源平臺的引入與數(shù)據(jù)治理的加強

上完中學以后就要上大學了，包括小銀行、政府機構、大部分傳統(tǒng)機構，這個里面它要求的東西就更多了。上大學以后，系統(tǒng)的結構一下就變復雜了，為什么?除了非結構化數(shù)據(jù)的處理之外，在這個時候有兩個非技術模塊很重要，一個叫做主數(shù)據(jù)管理，一個叫做元數(shù)據(jù)管理，所有在這個階段的企業(yè)都做了類似這樣的項目。主數(shù)據(jù)是什么?在企業(yè)里面，各種各樣的系統(tǒng)里面都有各種各樣的數(shù)據(jù)，對于某些特殊的數(shù)據(jù)的標準數(shù)據(jù)就是主數(shù)據(jù)。舉個例子，客戶信息。你可能有CRM里面有，ERP里面有，可能生產(chǎn)調度系統(tǒng)里面有，可能銷售的APP里面也有，你的網(wǎng)站上面也有。

對于每一個客戶來講，誰作為唯一確定的數(shù)據(jù)做黃金拷貝?這就是主數(shù)據(jù)管理的意義，你一定把主數(shù)據(jù)存儲獨立存儲，業(yè)務流程發(fā)生變更的時候，哪個系統(tǒng)有權限去改主數(shù)據(jù)，是非常重要的，否則最后客戶的電話號碼天天變來變去，你也不知道它哪個是最終有的有效數(shù)據(jù)。所以在這個時間點你一定要做一個主數(shù)據(jù)的管理。第二個元數(shù)據(jù)，元數(shù)據(jù)的管理，到這個階段以后，表、存儲特別多了，這些數(shù)據(jù)怎么能有效的管理。例如，元數(shù)據(jù)當中的血緣分析，就是你這個表它的數(shù)據(jù)從哪里來，到哪里去，這個數(shù)據(jù)怎么最后變成了指標展現(xiàn)出來，指標發(fā)生數(shù)據(jù)問題的時候，哪些數(shù)據(jù)處理過程可能存在一些故障可能，這些東西其實是在這個階段做的。

在這個階段開始要做真的開源平臺的引入了，開源平臺的引入和數(shù)據(jù)治理的加強，導致你的人員迅速地擴張。第一個這里面引入了 Hadoop，Hadoop我目前建議你還是先用Hive先用用，逐步轉為Map Reduce非結構化處理，通過Kafka，接入Storm也可以使用實時地流式計算，通過Storm直接反饋到前端的展現(xiàn)工具。在這個數(shù)據(jù)量級的時候，每天五千萬條左右的結構化數(shù)據(jù)的處理量，可以使用開源的Greenplum或者商業(yè)化的Teradata。Teradata目前還是在MPP架構業(yè)界最快的，但是賣的也是最貴的。展現(xiàn)工具，企業(yè)依然可以去買第三方工具，自己不用去開發(fā)。

此時的企業(yè)，數(shù)據(jù)挖掘的需求越來越多，使用數(shù)據(jù)挖掘工具的時候，原來做的一些簡單的像Excel這樣的工具已經(jīng)無法滿足個性化推薦、協(xié)同過濾這些算法了。挖掘工具可以在R SPSS、SAS、或Mlib庫選一個。Mlib是Spark中的數(shù)據(jù)挖掘庫，功能強大，處理速度快。不過此時我還不建議企業(yè)著急上Spark，因為大部分這些企業(yè)大數(shù)據(jù)投入還是有限的，Spark的使用會給人員帶來新的需求。如果人員有限，那么可以選擇商業(yè)的數(shù)據(jù)挖掘工具，如果人力比較富裕，可以使用開源的R結合python相關挖掘的類庫，能解決企業(yè)大部分的挖掘和推薦需求。這個時間點上有一個特點就是在大部分的這個企業(yè)處理的時候，大部分數(shù)據(jù)還是將非結構化數(shù)據(jù)處理之后，變?yōu)榻Y構化數(shù)據(jù)再做相關處理，哪怕經(jīng)過了MapReduce，經(jīng)過挖掘在線模型，最終的數(shù)據(jù)還會回到這種結構化的數(shù)據(jù)庫里面再去使用。

或者有小部分地流式實時數(shù)據(jù)處理來做展示。絕大部分數(shù)據(jù)存儲還不是放在Hive和Hapdoop里面的，你的大部分的數(shù)據(jù)其實還是在結構化的數(shù)據(jù)里面。因為你的人員在這個階段，其實還是結構化數(shù)據(jù)處理人員比非結構化數(shù)據(jù)處理人員多，你的業(yè)務需求也是結構化數(shù)據(jù)需求最多。

中流砥柱——Kafka/HDFS/Hadoop/Hive

最皮實的組合

• 魯棒性
• 硬件兼容性
• 數(shù)據(jù)處理穩(wěn)定性

每個系統(tǒng)大數(shù)據(jù)存儲，都繞不開

缺點：慢!

分開來講，Kafka/HDFS/Mapreduce/Hive，我把它叫做最皮實的大數(shù)據(jù)組合，原因有幾個：第一就是穩(wěn)定，無論你現(xiàn)在用的是 Cloudera 還是Hortonworks，其實讓你的開發(fā)人員去安裝一套，安裝配置的時候可能中間有一些坑，但是你只要把它安上去轉起來一次以后，那后面基本上它的大部分問題幾乎就沒有了。不會像其他平臺，在運行時有時候會有一些詭異的問題。它的兼容性也比較強，就是無論好硬件差硬件，它都能跑起來。數(shù)據(jù)處理的穩(wěn)定性，數(shù)據(jù)處理是非常穩(wěn)定的，你不用擔心數(shù)據(jù)量徒增會出什么問題。所以現(xiàn)在目前為止，每一個大數(shù)據(jù)的存儲都繞不開這個組合。缺點也很明顯，就是慢。這個東西它是不會內存爆掉，不會死機， 但是它轉起來真的很慢，你想讓它跑快起來，這個事其實挺難的，因為這個整個結構其實就不是那樣的結構，經(jīng)常你查一個SQL下去，你看著它先做map，然后再做reduce可能半個小時過去了。

貴族的開源——Greenplum

• MPP架構，查詢速度很快!
• 大數(shù)據(jù)量SQL查詢，除了Teradata，商業(yè)化使用最多
• 穩(wěn)定性強
• GPDB目前使用最多，HAWQ支持HDFS是未來

缺點：吃硬件，萬兆、多SAS盤、服務器很貴…

剛才我提到了Greenplum， Greenplum這家公司其實也是一家老牌公司了，它其實現(xiàn)在有兩個開源的版本，一個以GPDB為核心，一個以HAWK位核心。GPDB是現(xiàn)在目前使用最多一個查詢的引擎，廣泛應用于銀行、電信等等很多的領域里面，其實都是用了GPDB的SQL的查詢比較多。HAWK是新版的GP存儲引擎，現(xiàn)在支持 HDFS，簡單來講它是底下存儲換為HDFS，它本身的查詢計劃和優(yōu)化還是用的GP的這一套東西，所以它的速度基本上和GPDB是相同的，只不過現(xiàn)在剛剛推出來，還需要一些時間驗證和推廣。但是整個趨勢來看HAWK是未來，因為它支持的HDFS，對于數(shù)據(jù)的導入導出，磁盤的冗余替換都是非常有利的。易觀作為GP開源以后第一個使用開源版本存儲處理大量數(shù)據(jù)的企業(yè)(日處理量在100億條左右)，我們也遇到了一些坑。但是給我們帶來的優(yōu)勢是查詢速度非常快，同樣的結構化數(shù)據(jù)的查詢，不夸張的講Hive需要1小時，GP 1分鐘就可以算出來。目前來講GP其實商業(yè)化用的是最多的，穩(wěn)定性也是非常強，在大數(shù)據(jù)的類SQL這個領域里還是比較好用的。當然，它也有缺點，就是非常吃硬件。普通的開源軟件我叫做屌絲開源，一般對硬件要求不高，而GP我管它叫貴族開源，它對網(wǎng)絡和磁盤的IO要求極為苛刻，一旦你的網(wǎng)絡和你的磁盤IO沒有配置均衡有效的時候，它會經(jīng)常出現(xiàn)一些詭異的問題。所以基本的配置，單光口萬兆是最最基本的，沒有這個硬件投入你就不要想用GP了，一般它推薦的是雙萬兆卡，就是一定要有光交機，兩個萬兆給它，每一個機器的磁盤很多的SAS盤。所以，它要求的硬件，包括整個的服務器，那你服務器本身主板其實這些要求全都規(guī)格都上去了。但是企業(yè)結構化數(shù)據(jù)到一定數(shù)據(jù)量級的時候，還是可以選它的，個人認為它還是比較靠譜的。

易觀方舟的轉化分析與應用評級

看自己產(chǎn)品轉化

• 營銷活動是否高轉化為下單支付?
• 行業(yè)平均轉化率如何?
• 什么渠道用戶分享與傳播多?

看行業(yè)均值、TOP10

• 市場是否已被領頭羊蠶食?
• 長尾幾無生存空間?

看自己評級

• 易觀給你的第三方的評估

當然在這個階段，第三方的平臺依然可以給你一些幫助。例如，幫助你看你企業(yè)從廣告到瀏覽到下單，轉化率是如何的?行業(yè)均值差多遠?這些易觀都一些分行業(yè)的分析模板，只需要你簡單的做一些數(shù)據(jù)嵌入即可。能看看行業(yè)趨勢是怎么樣，你自己看看這個行業(yè)的TOP10是怎么樣。你的市場已經(jīng)被領頭羊吃掉了，或者你自己生存空間怎么樣。再看看你在這個行業(yè)里排行如何?有沒有一些新的缺口?另外易觀給你做一個第三方的評估評級，給你的投資看下你的用戶的價值有多大。這些基本功能都是永久免費的，而將來基于這些基本功能的擴展分析是要收費的。

那剛才講完大學了，現(xiàn)在開始上研究生了，研究生每天的數(shù)據(jù)條數(shù)少于五十億，那現(xiàn)在到了這個量級的時候，基本上專職人員是30到50人了，這個時候關鍵詞就是一個字，開源。為什么?在這個量級的時候，如果你不去用一些開源的一些工具投入已經(jīng)超過了你對于人員雇傭的投入費用。那對于這個階段來講，除了 Hadoop系列，會引入Spark、麒麟、Presto、Druid這樣的數(shù)據(jù)處理和存儲平臺。研發(fā)工具基本上原來的商業(yè)工具肯定是無法滿足需求了，可以引用百度的E-Chart或者D3。他們之間各有千秋，但是我是支持國產(chǎn)的開源的，所以我選了echarts。

數(shù)據(jù)量增加、實時計算的引入導致全面開源化

內存計算的翹楚——Spark

• 目前最火的大數(shù)據(jù)開源項目
• 華人貢獻占52%
• 大數(shù)據(jù)下數(shù)據(jù)挖掘必選項SparkR
• 即使使用磁盤，執(zhí)行效率優(yōu)于Hive幾倍

研究生大數(shù)據(jù)必修課

• 缺點：如果達到很高效，硬件要支持
• 數(shù)據(jù)量比較大，節(jié)點比較多，對Scala要求比較高

先說Spark，目前最火的大數(shù)據(jù)開源項目。它的開源的火爆程度目前超過了Hadoop一倍可能還得多，而且華人在里面貢獻的人名數(shù)超過50%以上。在這個數(shù)據(jù)量級，會有大量的數(shù)據(jù)挖掘模型和處理的需求，而Spark對于迭代式的數(shù)據(jù)挖掘，特別大數(shù)據(jù)量的處理的時候。同時，它的內存計算及相關框架效率是Hadoop運行效率的幾倍，所以在研究生階段，大數(shù)據(jù)必修課就是Spark。但缺點也挺明顯，就是如果你想達到它的高效，因為它就是內存的計算，硬件整體環(huán)境需要支持。就是也許你現(xiàn)在不用萬兆，那你也得用雙網(wǎng)卡或者四網(wǎng)卡捆綁，你的網(wǎng)絡IO得有保證，你的內存和CPU得能上來，這兩個是你在 Spark的時候必用的。另外，大家知道Spark是用scala做的，你對scala的要求就比較高了，因為你結點多的時候，這點或者那點總有點小問題，所以研發(fā)的技術人員必須得對scala比較熟悉，可以簡單調試相關的問題。相對于Hadoop，Spark穩(wěn)定性還在逐步加強，它在流程里會有一些小的bug出來，因為它雖然很火，但是它還會有各種各樣的小問題，需要你去修修補補的。所以這個是你在研究生的時候你再去學。

OLAP的利器——Kylin

• 解決了大數(shù)據(jù)多維度查詢速度慢，多維查詢數(shù)據(jù)返回丌及時的問題
• 開源MOLAP利器
• Apache金牌項目
• 源自Ebay內部大數(shù)據(jù)
• 利用Hbase，加速可以加速Hbase

中國人自己的開源項目!

• 缺點：預計算時間比較長

麒麟源自于e-Bay，現(xiàn)在它單獨從e-Bay獨立出來了，那它是Apache的金牌開源項目。麒麟是開源的MOlap的利器，解決了大數(shù)據(jù)多維查詢速度慢，多維查詢的反饋不及時的問題。目前麒麟底層主要是利用Hbase去做存儲和查詢，所以你要去想加快麒麟的速度的話，可以用增強磁盤和網(wǎng)絡 I/O的方式處理。麒麟目前國內很多大牌的地方也都用過了，包括像騰訊，美團都有使用，現(xiàn)在有很多經(jīng)過實際的一些經(jīng)驗，它是OK的。最重要的一點，它是中國自己開源的項目，中國人自己的，所以大家一定要支持它。但是麒麟也有它的缺點了，就是它的預加載時間比較長，因為它是用空間換時間的。在大數(shù)據(jù)架構里，展示的時候如果想看到數(shù)據(jù)怎么上鉆下鉆，然后做一些查詢，麒麟作為國產(chǎn)的開源的這樣一個軟件，我覺得還是強烈推薦的，這個大家可以去使用。

OLAP的生力軍——Druid

• 解決單表大數(shù)據(jù)查詢問題
• 支持實時增量的聚合
• 不支持查明細

正準POC，不亂評價

開源負責人是華人

• 缺點：未知，正在準備試用

Druid是最近比較火爆的查詢平臺，最近群里也一直在討論，我正在做POC，暫時還不評論。試用以后再給大家做一個反饋。

內部SQL查詢工具——Presto

• Facebook開源內存SQL查詢
• 可以跨mysql，Hadoop， cassandra查詢
• 查詢效率進高于Hive
• SQL支持比較好
• 缺點：內存吃的很厲害，而且大查詢出現(xiàn)詭異的異常

目前易觀用作內部查詢使用

Presto其實Facebook開源的，是一個內存式計算的框架，它比較牛的地方，它是一個能夠跨Mysql跨Hadoop，跨 cassandra的查詢。支持跨庫查詢，可能主數(shù)據(jù)在Mysql，行為明細在Hive，用戶標簽在cassandra，一個語句可以解決所有問題。這件事情還是很牛逼的，但是現(xiàn)在它要支持很多新的數(shù)據(jù)庫的Adapter，但是據(jù)說新的adapter要收費，查詢效率也高于原生的Hive。我們原先也用 presto，美團也在使用。但是Presto的缺點也挺明顯，就是如果你數(shù)量不大的時候，原來我們拿presto串到整個數(shù)據(jù)處理流程也很好。但缺點也很明顯，Presto內存吃的很厲害，如果數(shù)據(jù)量級比較大的的查詢(超過20億左右，根據(jù)集群大小不同)，就會出現(xiàn)很詭異的異常，而且每次異常的點都不一樣。所以在這個情況下，就是我們現(xiàn)在易觀拿它做內部查詢使用，就是你不能把它串到數(shù)據(jù)處理流程里。

對開源平臺的修改、對硬件的定制要求

到博士生了，更多的技術人員集中到算法層面，例如像知識庫或者知識圖譜的建立，或者在線推薦引擎和搜索優(yōu)化這樣。大數(shù)據(jù)平臺方面，其實每個不同的這個地方，其實都不太一樣。這個階段每個公司都是自主的一些存儲了，包括ETL的工具。在這個階段原先免費開源的ETL調度工具都不行了，這個工具需要結合任務去動態(tài)調整資源，像易觀自己做的EAMP，或者我在萬達時候e-horse，除了你調度ETL流程之外，因為你的數(shù)據(jù)量很多了，它得能夠去調動你的 Hadoop的這些資源并處理一些特殊的業(yè)務情況。大數(shù)據(jù)存儲的時候在此時各顯神通，這個時候真的沒有一個統(tǒng)一地說完整的解決方案。這里稍微提一點優(yōu)化，就是需要將大數(shù)據(jù)分段處理了。因為這么大量的數(shù)據(jù)，如果直接扔到后臺集群，集群壓力會超大，性價比也不是最高。所以在這里舉例，在互聯(lián)網(wǎng)數(shù)據(jù)接收的時候，就開始做數(shù)據(jù)處理。例如，利用Lua在openresty去處理臟數(shù)據(jù)，分段優(yōu)化整體的大數(shù)據(jù)處理流程。在這個階段，基本上所有的這些博士生的企業(yè)，都有修改開源平臺的能力，你的團隊得能去修理開源的平臺解決相關的問題。

性價比最高的定制化硬件

大數(shù)據(jù)集群要什么?不同場景不同

批量計算——高性價比的I/O，網(wǎng)絡I/O，磁盤I/O

• 磁盤I/O，SSD?量大了用不起。
• 多磁盤，組Raid
• 網(wǎng)絡I/O，光纖萬兆?性價比丌吅適
• 多網(wǎng)卡捆綁，4塊放一起

實時計算——網(wǎng)絡 I/O，CPU

• 大內存
• 萬兆
• 高CPU
• 磁盤?SSD，必須的

同時，你要對硬件做一些定制，就是如果你真的想做性價比最高，原來成型的這些機器不太好使了，其實有很多東西你得去配置什么要下一些功夫。大數(shù)據(jù)集群需要什么?就是不同場景，不太一樣。批量計算，批量計算像Hadoop或者presto主要是高性價比的IO，指的是網(wǎng)絡的IO，磁盤的IO。如果真的想框架不變，速度提升優(yōu)化50%、70%，你想通過優(yōu)化Hadoop這些優(yōu)化，我覺得基本不太可能，你直接升SSD硬盤才是解決方案。如果性價比比較高的方案，優(yōu)選的就是磁盤特別多的機器，在這個時候你去買更多的盤，比如說你的機器支持16塊盤，把這16塊盤，如果HDFS倍數(shù)是3的話，你組三個 Raid，去處理，比你用8塊盤的機器用羅裸快得多。磁盤IO這件事是我覺得第一個優(yōu)化的。

第二個網(wǎng)絡IO，網(wǎng)絡IO，我們要高性價比，網(wǎng)絡IO萬兆當然是最好了但是性價比其實不合適，其實現(xiàn)在很多的這種多網(wǎng)卡捆綁的方案了，就是你買四塊網(wǎng)卡，費點交換機，你把四塊卡綁一起，其實它這個速度，雖然不是×4，但是基本上×2×3還可以。所以在這個時候也是一個廉價的解決方案，所以你的 Hadoop集群在配的時候，你就用這種多磁盤，多網(wǎng)卡，CPU要不要高?其實我覺得不用。就是大部分的Hadoop出現(xiàn)的問題都不用在CPU上，都是在磁盤和網(wǎng)絡IO上面的，就是你在這兩個IO上面提上去，你的查詢效率會高很多，而且也不用花太多錢。

對于時時計算來講，這個事其實如果你真的想做得比較好，那么主要是網(wǎng)絡IO和CPU，內存一定要大，你的網(wǎng)絡，我覺得像GP、Spark這些你要想把它轉得非常好，速度非?？欤悄氵€是上萬兆吧。如果你要想便宜的話，你就用四塊網(wǎng)卡去捆綁，CPU，因為這個時候其實它是內存之間的交互，CPU如果不夠高，那你最后CPU就有瓶頸，磁盤直接上SSD即可，現(xiàn)在目前其實你要想定制比較性價比高的這些硬件，其實主要還是回到它原來處理平臺的時候，需要 IO，需要CPU還是需要網(wǎng)絡，從這幾個角度來看，不同場景其實還是不太一樣的。

當然，其實剛才講了一堆開源的工具，我們也在做一些有趣的測試，就是拿我們現(xiàn)在易觀處理完的，比如說一天大概五十億條的數(shù)據(jù)，拿這個數(shù)據(jù)做一下評測，在不同場景下，每個查詢效果怎么樣，這個事其實我們現(xiàn)在正在做POC，做完以后，下次分享的時候，也跟大家去聊一聊。

剛才也說了各個不同的，從幼兒園到博士生，其實跨度還是挺大的，講的從一開始的Mysql到最后整個完整的一個大數(shù)據(jù)平臺。傳統(tǒng)企業(yè)比較特殊，就是它大部分數(shù)據(jù)都是結構化數(shù)據(jù)，技術人員基本上不是特別多，要么就是外包，要么是自己內部人員。但大數(shù)據(jù)的這些算法和大數(shù)據(jù)的非結構化的處理比較少。我這里面關鍵詞其實就是建議傳統(tǒng)企業(yè)還是先建一個數(shù)據(jù)倉庫，然后把少量的非結構化的處理放到結構化里面。

傳統(tǒng)企業(yè)模板

大數(shù)據(jù)云化的觀點

大數(shù)據(jù)云化是趨勢

小公司，全面云化，借劣第三方云化解決方案，端到端解決問題

• 核心數(shù)據(jù)選一家大的(阿里、騰訊、Ucloud等)
• 周邊方案丌一定只一家(多選幾家功能觸達為主)

大公司，大數(shù)據(jù)混吅云是當前的最佳實踐

• 大數(shù)據(jù)集群自主
• 相關組件不產(chǎn)品云化

最后說說，大數(shù)據(jù)和云化的問題。各家云都上了各種大數(shù)據(jù)組件，這個東西可不可用?好不好用?該不該用?我的觀點是這樣的，就是大數(shù)據(jù)是云化是未來的趨勢。目前在國內，如果你是小公司，那你就全面云化吧，那借助第三方的云化的解決方案，端到端解決問題，比如阿里、騰訊、Ucloud等等這個就不列了，這個感興趣大家可以看易觀的分析報告。周邊端到端的數(shù)據(jù)分析服務云就不一定選一家，哪家能用它的一個優(yōu)化的方案來解決你用哪家，對于移動互聯(lián)網(wǎng)來講，你可以選易觀，當然你也可以加上其他的友商，在這個階段對于中小公司來講，這就可以了。對于大公司來講，目前現(xiàn)在最佳的方案是混合云，最終落到還是一個混合云的方案。是為什么?就剛才提到，大數(shù)據(jù)集群從性價比來講，從穩(wěn)定性來講，公有云都還有一段路要走。大數(shù)據(jù)集群可以在自己的私有云里面，那么你的相關的這些產(chǎn)品可以放到公共云上。

來源：極客頭條