協同過濾可擴展性

『壹』 建設了幾個系統平台 哪些數據

(1)操作系統的選擇操作系統一般使用開源版的RedHat、Centos或者Debian作為底層的構建平台，要根據大數據平台所要搭建的數據分析工具可以支持的系統，正確的選擇操作系統的版本。

(2)搭建Hadoop集群Hadoop作為一個開發和運行處理大規模數據的軟體平台，實現了在大量的廉價計算機組成的集群中對海量數據進行分布式計算。Hadoop框架中最核心的設計是HDFS和MapRece，HDFS是一個高度容錯性的系統，適合部署在廉價的機器上，能夠提供高吞吐量的數據訪問，適用於那些有著超大數據集的應用程序;MapRece是一套可以從海量的數據中提取數據最後返回結果集的編程模型。在生產實踐應用中，Hadoop非常適合應用於大數據存儲和大數據的分析應用，適合服務於幾千台到幾萬台大的伺服器的集群運行，支持PB級別的存儲容量。Hadoop家族還包含各種開源組件，比如Yarn，Zookeeper，Hbase，Hive，Sqoop，Impala，Spark等。使用開源組件的優勢顯而易見，活躍的社區會不斷的迭代更新組件版本，使用的人也會很多，遇到問題會比較容易解決，同時代碼開源，高水平的數據開發工程師可結合自身項目的需求對代碼進行修改，以更好的為項目提供服務。

(3)選擇數據接入和預處理工具面對各種來源的數據，數據接入就是將這些零散的數據整合在一起，綜合起來進行分析。數據接入主要包括文件日誌的接入、資料庫日誌的接入、關系型資料庫的接入和應用程序等的接入，數據接入常用的工具有Flume，Logstash，NDC(網易數據運河系統)，sqoop等。對於實時性要求比較高的業務場景，比如對存在於社交網站、新聞等的數據信息流需要進行快速的處理反饋，那麼數據的接入可以使用開源的Strom，Sparkstreaming等。當需要使用上游模塊的數據進行計算、統計和分析的時候，就需要用到分布式的消息系統，比如基於發布/訂閱的消息系統kafka。還可以使用分布式應用程序協調服務Zookeeper來提供數據同步服務，更好的保證數據的可靠和一致性。數據預處理是在海量的數據中提取出可用特徵，建立寬表，創建數據倉庫，會使用到HiveSQL，SparkSQL和Impala等工具。隨著業務量的增多，需要進行訓練和清洗的數據也會變得越來越復雜，可以使用azkaban或者oozie作為工作流調度引擎，用來解決有多個hadoop或者spark等計算任務之間的依賴關系問題。

(4)數據存儲除了Hadoop中已廣泛應用於數據存儲的HDFS，常用的還有分布式、面向列的開源資料庫Hbase，HBase是一種key/value系統，部署在HDFS上，與Hadoop一樣，HBase的目標主要是依賴橫向擴展，通過不斷的增加廉價的商用伺服器，增加計算和存儲能力。同時hadoop的資源管理器Yarn，可以為上層應用提供統一的資源管理和調度，為集群在利用率、資源統一等方面帶來巨大的好處。Ku是一個圍繞Hadoop生態圈建立的存儲引擎，Ku擁有和Hadoop生態圈共同的設計理念，可以運行在普通的伺服器上，作為一個開源的存儲引擎，可以同時提供低延遲的隨機讀寫和高效的數據分析能力。Redis是一種速度非常快的非關系型資料庫，可以將存儲在內存中的鍵值對數據持久化到硬碟中，可以存儲鍵與5種不同類型的值之間的映射。

(5)選擇數據挖掘工具Hive可以將結構化的數據映射為一張資料庫表，並提供HQL的查詢功能，它是建立在Hadoop之上的數據倉庫基礎架構，是為了減少MapRece編寫工作的批處理系統，它的出現可以讓那些精通SQL技能、但是不熟悉MapRece、編程能力較弱和不擅長Java的用戶能夠在HDFS大規模數據集上很好的利用SQL語言查詢、匯總、分析數據。Impala是對Hive的一個補充，可以實現高效的SQL查詢，但是Impala將整個查詢過程分成了一個執行計劃樹，而不是一連串的MapRece任務，相比Hive有更好的並發性和避免了不必要的中間sort和shuffle。Spark可以將Job中間輸出結果保存在內存中，不需要讀取HDFS，Spark啟用了內存分布數據集，除了能夠提供互動式查詢外，它還可以優化迭代工作負載。Solr是一個運行在Servlet容器的獨立的企業級搜索應用的全文搜索伺服器，用戶可以通過http請求，向搜索引擎伺服器提交一定格式的XML，生成索引，或者通過HTTPGET操作提出查找請求，並得到XML格式的返回結果。還可以對數據進行建模分析，會用到機器學習相關的知識，常用的機器學習演算法，比如貝葉斯、邏輯回歸、決策樹、神經網路、協同過濾等。

(6)數據的可視化以及輸出API對於處理得到的數據可以對接主流的BI系統，比如國外的Tableau、Qlikview、PowrerBI等，國內的SmallBI和新興的網易有數(可免費試用)等，將結果進行可視化，用於決策分析;或者迴流到線上，支持線上業務的發展。成熟的搭建一套大數據分析平台不是一件簡單的事情，本身就是一項復雜的工作，在這過程中需要考慮的因素有很多，比如：穩定性，可以通過多台機器做數據和程序運行的備份，但伺服器的質量和預算成本相應的會限制平台的穩定性;可擴展性：大數據平台部署在多台機器上，如何在其基礎上擴充新的機器是實際應用中經常會遇到的問題;安全性：保障數據安全是大數據平台不可忽視的問題，在海量數據的處理過程中，如何防止數據的丟失和泄漏一直是大數據安全領域的研究熱點。

『貳』 協同過濾中的可擴展性問題是什麼

協同過濾演算法能夠容易地為幾千名用戶提供較好的推薦，但是對於電子商務網站，往往需要給成百上千萬的用戶提供推薦，這就一方面需要提高響應時間的要求，能夠為用戶實時地進行推薦;另一方面還應考慮到存儲空間的要求，盡量減少推薦系統運行的負擔。

1．3 可擴展性問題

在協同過濾推薦演算法中，全局數值演算法能及時利用最新的信息為用戶產生相對准確的用戶興趣度預測或進行推薦，但是面對日益增多的用戶，數據量的急劇增加，演算法的擴展性問題(即適應系統規模不斷擴大的問題)成為制約推薦系統實施的重要因素。雖然與基於模型的演算法相比，全局數值演算法節約了為建立模型而花費的訓練時間，但是用於識別「最近鄰居」演算法的計算量隨著用戶和項的增加而大大增加，對於上百萬的數目，通常的演算法會遇到嚴重的擴展性瓶頸問題。該問題解決不好，直接影響著基於協同過濾技術的推薦系統實時向用戶提供推薦問題的解決，而推薦系統的實時性越好，精確度越高，該系統才會被用戶所接受。

基於模型的演算法雖然可以在一定程度上解決演算法的可擴展性問題，但是該類演算法往往比較適於用戶的興趣愛好比較穩定的情況，因為它要考慮用戶模型的學習過程以及模型的更新過程，對於最新信息的利用比全局數值演算法要差些。

分析以上協同過濾在推薦系統實現中面臨的兩個問題，它們的共同點是均考慮到了最近鄰居的形成問題(包括用戶信息獲得的充分性、計算耗費等)。但是應該看到協同過濾在推薦系統的實現中，要獲得最近鄰居用戶，必須通過一定的計算獲得用戶之間的相似度，然後確定最佳的鄰居個數，形成鄰居用戶集。而在這一過程中，如果對全部數據集進行相似性計算，雖然直接，但是運算量和時間花費都極大，無法適應真實的商務系統。如果通過對訓練集數據(整個數據集的某一子集)進行實驗獲得，雖然不必對整個數據集進行計算，但是必須通過將多次實驗結果統計出來才可能得到，這無疑也增加了推薦結果獲得的代價和誤差。並且如果考慮到數據集的動態變化，這一形成最近鄰居用戶集技術的實際應用價值越來越小。因此，考慮使用更為有效的最近鄰居用戶形成辦法，對於協同過濾的應用非常必要。

『叄』 矩陣分解在協同過濾推薦演算法中的應用

矩陣分解在協同過濾推薦演算法中的應用
推薦系統是當下越來越熱的一個研究問題，無論在學術界還是在工業界都有很多優秀的人才參與其中。近幾年舉辦的推薦系統比賽更是一次又一次地把推薦系統的研究推向了高潮，比如幾年前的Neflix百萬大獎賽，KDD CUP 2011的音樂推薦比賽，去年的網路電影推薦競賽，還有最近的阿里巴巴大數據競賽。這些比賽對推薦系統的發展都起到了很大的推動作用，使我們有機會接觸到真實的工業界數據。我們利用這些數據可以更好地學習掌握推薦系統，這些數據網上很多，大家可以到網上下載。
推薦系統在工業領域中取得了巨大的成功，尤其是在電子商務中。很多電子商務網站利用推薦系統來提高銷售收入，推薦系統為Amazon網站每年帶來30%的銷售收入。推薦系統在不同網站上應用的方式不同，這個不是本文的重點，如果感興趣可以閱讀《推薦系統實踐》（人民郵電出版社，項亮）第一章內容。下面進入主題。
為了方便介紹，假設推薦系統中有用戶集合有6個用戶，即U={u1,u2,u3,u4,u5,u6}，項目（物品）集合有7個項目，即V={v1,v2,v3,v4,v5,v6,v7}，用戶對項目的評分結合為R，用戶對項目的評分范圍是[0, 5]。R具體表示如下：

推薦系統的目標就是預測出符號「？」對應位置的分值。推薦系統基於這樣一個假設：用戶對項目的打分越高，表明用戶越喜歡。因此，預測出用戶對未評分項目的評分後，根據分值大小排序，把分值高的項目推薦給用戶。怎麼預測這些評分呢，方法大體上可以分為基於內容的推薦、協同過濾推薦和混合推薦三類，協同過濾演算法進一步劃分又可分為基於基於內存的推薦（memory-based）和基於模型的推薦（model-based），本文介紹的矩陣分解演算法屬於基於模型的推薦。
矩陣分解演算法的數學理論基礎是矩陣的行列變換。在《線性代數》中，我們知道矩陣A進行行變換相當於A左乘一個矩陣，矩陣A進行列變換等價於矩陣A右乘一個矩陣，因此矩陣A可以表示為A=PEQ=PQ（E是標准陣）。
矩陣分解目標就是把用戶-項目評分矩陣R分解成用戶因子矩陣和項目因子矩陣乘的形式，即R=UV，這里R是n×m， n =6， m =7，U是n×k，V是k×m。直觀地表示如下：

高維的用戶-項目評分矩陣分解成為兩個低維的用戶因子矩陣和項目因子矩陣，因此矩陣分解和PCA不同，不是為了降維。用戶i對項目j的評分r_ij =innerproct(u_i, v_j)，更一般的情況是r_ij =f(U_i, V_j)，這里為了介紹方便就是用u_i和v_j內積的形式。下面介紹評估低維矩陣乘積擬合評分矩陣的方法。
首先假設，用戶對項目的真實評分和預測評分之間的差服從高斯分布，基於這一假設，可推導出目標函數如下：

最後得到矩陣分解的目標函數如下：

從最終得到得目標函數可以直觀地理解，預測的分值就是盡量逼近真實的已知評分值。有了目標函數之後，下面就開始談優化方法了，通常的優化方法分為兩種：交叉最小二乘法（alternative least squares）和隨機梯度下降法（stochastic gradient descent）。
首先介紹交叉最小二乘法，之所以交叉最小二乘法能夠應用到這個目標函數主要是因為L對U和V都是凸函數。首先分別對用戶因子向量和項目因子向量求偏導，令偏導等於0求駐點，具體解法如下：

上面就是用戶因子向量和項目因子向量的更新公式，迭代更新公式即可找到可接受的局部最優解。迭代終止的條件下面會講到。
接下來講解隨機梯度下降法，這個方法應用的最多。大致思想是讓變數沿著目標函數負梯度的方向移動，直到移動到極小值點。直觀的表示如下：

其實負梯度的負方向，當函數是凸函數時是函數值減小的方向走；當函數是凹函數時是往函數值增大的方向移動。而矩陣分解的目標函數L是凸函數，因此，通過梯度下降法我們能夠得到目標函數L的極小值（理想情況是最小值）。
言歸正傳，通過上面的講解，我們可以獲取梯度下降演算法的因子矩陣更新公式，具體如下：

（3）和（4）中的γ指的是步長，也即是學習速率，它是一個超參數，需要調參確定。對於梯度見（1）和（2）。
下面說下迭代終止的條件。迭代終止的條件有很多種，就目前我了解的主要有
1） 設置一個閾值，當L函數值小於閾值時就停止迭代，不常用
2） 設置一個閾值，當前後兩次函數值變化絕對值小於閾值時，停止迭代
3） 設置固定迭代次數
另外還有一個問題，當用戶-項目評分矩陣R非常稀疏時，就會出現過擬合（overfitting）的問題，過擬合問題的解決方法就是正則化（regularization）。正則化其實就是在目標函數中加上用戶因子向量和項目因子向量的二范數，當然也可以加上一范數。至於加上一范數還是二范數要看具體情況，一范數會使很多因子為0，從而減小模型大小，而二范數則不會它只能使因子接近於0，而不能使其為0，關於這個的介紹可參考論文Regression Shrinkage and Selection via the Lasso。引入正則化項後目標函數變為：

（5）中λ_1和λ_2是指正則項的權重，這兩個值可以取一樣，具體取值也需要根據數據集調參得到。優化方法和前面一樣，只是梯度公式需要更新一下。
矩陣分解演算法目前在推薦系統中應用非常廣泛，對於使用RMSE作為評價指標的系統尤為明顯，因為矩陣分解的目標就是使RMSE取值最小。但矩陣分解有其弱點，就是解釋性差，不能很好為推薦結果做出解釋。
後面會繼續介紹矩陣分解演算法的擴展性問題，就是如何加入隱反饋信息，加入時間信息等。

『肆』 個性化推薦演算法——協同過濾

有三種：協同過濾
用戶歷史行為
物品相似矩陣

『伍』 推薦演算法的主要推薦方法的對比

各種推薦方法都有其各自的優點和缺點，見表1。 表1 主要推薦回方法對比 推薦方法優點缺點答基於內容推薦推薦結果直觀，容易解釋；不需要領域知識 新用戶問題；復雜屬性不好處理；
要有足夠數據構造分類器 協同過濾推薦新異興趣發現、不需要領域知識；隨著時間推移性能提高；
推薦個性化、自動化程度高；
能處理復雜的非結構化對象 稀疏問題；可擴展性問題；
新用戶問題；
質量取決於歷史數據集；
系統開始時推薦質量差； 基於規則推薦能發現新興趣點；不要領域知識 規則抽取難、耗時；產品名同義性問題；
個性化程度低； 基於效用推薦無冷開始和稀疏問題；對用戶偏好變化敏感；
能考慮非產品特性 用戶必須輸入效用函數；推薦是靜態的，靈活性差；
屬性重疊問題； 基於知識推薦能把用戶需求映射到產品上；能考慮非產品屬性 知識難獲得；推薦是靜態的

『陸』 電子商務推薦系統現在有什麼問題

電子商務推薦系統定義為：利用電子商務網站向用戶提供商品信息和建議，幫助客戶決定應該購買什麼產品，模擬銷售人員幫助客戶完成購買過程。它是一個基於客戶網上購物的以商品為推薦對象的個性化推薦系統，為客戶推薦符合其興趣愛好的商品。分析客戶的消費偏向，向每個客戶具有針對性地推薦的產品，幫助客戶從龐大的商品目錄中挑選真正適合自己需要的商品。電子商務推薦系統在幫助了客戶的同時也提高了客戶對商務活動的滿意度,從而換來對電子商務站點的進一步支持。
電子商務推薦系統主要起到了三個方面的作用：首先，極大地增加了客戶，可以把網站的瀏覽者轉變為購買者，提高主動性；其次，可以提高網站相關系列產品的連帶銷售能力；最後，可以提高、維持客戶對網站的滿意度和信任度。
電子商務推薦系統具有良好的發展和應用前景。在日趨激烈的競爭環境下，電子商務推薦系統能有效保留客戶，提高電子商務網站系統能大大提高企業的銷售額。成功的電子商務推薦系統將會產生巨大的經濟效益和社會效應。
電子商務推薦技術
目前,電子商務推薦系統中使用的主要推薦技術有基於內容推薦,協同過濾推薦,基於知識推薦,基於效用推薦，基於關聯規則推薦,混合推薦等等。
1.基於內容的推薦。它是信息過濾技術的延續與發展，項目或對象通過相關特徵的屬性來定義，系統基於商品信息, 包括商品的屬性及商品之間的相關性和客戶的喜好來向其推薦。基於商品屬性主要是基於產品的屬性特徵模型推薦。
內容推薦技術分析商品的屬性及其相關性可以離線進行，因而推薦響應時間快。缺點是難以區分商品信息的品質和風格，而且不能為用戶發現新的感興趣的商品，只能發現和用戶已有興趣相似的商品。
2.協同過濾推薦。協同過濾推薦是目前研究最多、應用最廣的電子商務推薦技術。它基於鄰居客戶的資料得到目標客戶的推薦,推薦的個性化程度高。利用客戶的訪問信息,通過客戶群的相似性進行內容推薦,不依賴於內容僅依賴於用戶之間的相互推薦,避免了內容過濾的不足,保證信息推薦的質量。協同過濾推薦優點有:能為用戶發現新的感興趣的商品;不需要考慮商品的特徵,任何形式的商品都可以推薦。缺點是:稀疏性問題,用戶對商品的評價矩陣非常稀疏;可擴展性問題,隨著系統用戶和商品的增多,系統的性能會越來越低;冷啟動問題,如果從來沒有用戶對某一商品加以評價,則這個商品就不可能被推薦。
3.基於知識的推薦。在某種程度上可以看成是一種推理技術，各個方法因所用的知識不同而有明顯區別。基於知識的推薦提出了功能知識的概念。簡單的說，功能知識是關於某個項目如何滿足某個特定客戶的知識，它能解釋需要和推薦之間的關系。在基於知識的推薦看來，客戶資料可以是任何能支持推理的知識結構，並非一定是用戶的需要和偏好。
4.基於效用的推薦。它是根據對客戶使用項目的效用進行計算的，核心問題是如何為每個客戶創建效用函數，並考慮非產品屬性，如提供商的可靠性和產品的可用性等。它的優點是能在效用函數中考慮非產品因素。效用函數通過交互讓用戶指定影響因素及其權重對於大多數用戶而言是極其繁瑣的事情，因而限制了該技術的應用。
5.基於關聯規則的推薦系統往往利用實際交易數據作為數據源，它符合數據源的通用性要求。以關聯規則為基礎，把已購商品作為規則頭,推薦對象作為規則體,其中關聯規則的發現最關鍵且最耗時,但可以離線進行。其特點是實現起來比較簡潔,推薦效果良好,並能動態地把客戶興趣變化反映到推薦結果中。
6.混合推薦技術。混合推薦系統整合兩種或更多推薦技術以取得更好的實際效果。最常見的做法是將協同過濾推薦技術與其它某一種推薦技術相結合。例如,結合基於協同過濾和基於內容推薦這兩種推薦技術,盡量利用它們的優點而避免其缺點,提高推薦系統的性能和推薦質量。比如,為了克服協同過濾的稀疏性問題,可以利用用戶瀏覽過的商品預期用戶對其他商品的評價,這樣可以增加商品評價的密度,利用這些評價再進行協同過濾,從而提高協同過濾的性能。
電子商務推薦系統，一方面有助於電子商務網站內容和結構自適應性的實現，另一方面在幫助客戶快速定位感興趣的商品的同時也為企業實現了增值。電子商務推薦系統作為有利的分析工具和促銷手段，已成為電子商務網站的競爭工具，必將獲得廣泛的應用和發展。本文對電子商務推薦系統進行了介紹，並對推薦技術進行了概述。目前國內的電子商務網站在這方面的實踐處在快速發展的階段，因此還需要繼續研究出更智能、更優化的電子商務推薦技術。

『柒』 微服務容器平檯面對大數據存儲是怎麼做的

整體而言，大數據平台從平台部署和數據分析過程可分為如下幾步：
1、linux系統安裝
一般使用開源版的Redhat系統--CentOS作為底層平台。為了提供穩定的硬體基礎，在給硬碟做RAID和掛載數據存儲節點的時，需要按情況配置。例如，可以選擇給HDFS的namenode做RAID2以提高其穩定性，將數據存儲與操作系統分別放置在不同硬碟上，以確保操作系統的正常運行。

2、分布式計算平台/組件安裝
目前國內外的分布式系統的大多使用的是Hadoop系列開源系統。Hadoop的核心是HDFS，一個分布式的文件系統。在其基礎上常用的組件有Yarn、Zookeeper、Hive、Hbase、Sqoop、Impala、ElasticSearch、Spark等。
先說下使用開源組件的優點：1）使用者眾多，很多bug可以在網上找的答案（這往往是開發中最耗時的地方）。2）開源組件一般免費，學習和維護相對方便。3）開源組件一般會持續更新，提供必要的更新服務『當然還需要手動做更新操作』。4）因為代碼開源，若出bug可自由對源碼作修改維護。
再簡略講講各組件的功能。分布式集群的資源管理器一般用Yarn，『全名是Yet Another Resource Negotiator』。常用的分布式數據數據『倉』庫有Hive、Hbase。Hive可以用SQL查詢『但效率略低』，Hbase可以快速『近實時』讀取行。外部資料庫導入導出需要用到Sqoop。Sqoop將數據從Oracle、MySQL等傳統資料庫導入Hive或Hbase。Zookeeper是提供數據同步服務，Yarn和Hbase需要它的支持。Impala是對hive的一個補充，可以實現高效的SQL查詢。ElasticSearch是一個分布式的搜索引擎。針對分析，目前最火的是Spark『此處忽略其他，如基礎的MapRece 和 Flink』。Spark在core上面有ML lib，Spark Streaming、Spark QL和GraphX等庫，可以滿足幾乎所有常見數據分析需求。
值得一提的是，上面提到的組件，如何將其有機結合起來，完成某個任務，不是一個簡單的工作，可能會非常耗時。

3、數據導入
前面提到，數據導入的工具是Sqoop。用它可以將數據從文件或者傳統資料庫導入到分布式平台『一般主要導入到Hive，也可將數據導入到Hbase』。

4、數據分析
數據分析一般包括兩個階段：數據預處理和數據建模分析。
數據預處理是為後面的建模分析做准備，主要工作時從海量數據中提取可用特徵，建立大寬表。這個過程可能會用到Hive SQL，Spark QL和Impala。
數據建模分析是針對預處理提取的特徵/數據建模，得到想要的結果。如前面所提到的，這一塊最好用的是Spark。常用的機器學習演算法，如樸素貝葉斯、邏輯回歸、決策樹、神經網路、TFIDF、協同過濾等，都已經在ML lib裡面，調用比較方便。

5、結果可視化及輸出API
可視化一般式對結果或部分原始數據做展示。一般有兩種情況，行熟悉展示，和列查找展示。在這里，要基於大數據平台做展示，會需要用到ElasticSearch和Hbase。Hbase提供快速『ms級別』的行查找。 ElasticSearch可以實現列索引，提供快速列查找。

平台搭建主要問題：
1、穩定性 Stability
理論上來說，穩定性是分布式系統最大的優勢，因為它可以通過多台機器做數據及程序運行備份以確保系統穩定。但也由於大數據平台部署於多台機器上，配置不合適，也可能成為最大的問題。 曾經遇到的一個問題是Hbase經常掛掉，主要原因是采購的硬碟質量較差。硬碟損壞有時會到導致Hbase同步出現問題，因而導致Hbase服務停止。由於硬碟質量較差，隔三差五會出現服務停止現象，耗費大量時間。結論：大數據平台相對於超算確實廉價，但是配置還是必須高於家用電腦的。

2、可擴展性 Scalability
如何快速擴展已有大數據平台，在其基礎上擴充新的機器是雲計算等領域應用的關鍵問題。在實際2B的應用中，有時需要增減機器來滿足新的需求。如何在保留原有功能的情況下，快速擴充平台是實際應用中的常見問題。

上述是自己項目實踐的總結。整個平台搭建過程耗時耗力，非一兩個人可以完成。一個小團隊要真正做到這些也需要耗費很長時間。

目前國內和國際上已有多家公司提供大數據平台搭建服務，國外有名的公司有Cloudera，Hortonworks，MapR等，國內也有華為、明略數據、星環等。另外有些公司如明略數據等還提供一體化的解決方案，尋求這些公司合作對 於入門級的大數據企業或沒有大數據分析能力的企業來說是最好的解決途徑。

對於一些本身體量較小或者目前數據量積累較少的公司，個人認為沒有必要搭建這一套系統，暫時先租用AWS和阿里雲就夠了。對於數據量大，但數據分析需求較簡單的公司，可以直接買Tableau，Splunk，HP Vertica，或者IBM DB2等軟體或服務即可。
-