到目前為止，你的大數據分析和商業智能項目還在順暢地自行運轉。但從長遠來看，通過對現有架構進行簡單擴展來保持順暢的數據訪問可能不是最好的解決辦法。
請考慮以下“大數據”特性：
·以網頁上為主（不屬于先前的內部數據傳送）
·涉及多個云環境
·與社交媒體應用緊密關聯，例如Facebook, Twitter和Linkedin
·規模空前
·數據有時 “不潔凈”，甚至不可用
·數據大部分是非結構化
·至少要引入幾種新工具，例如Apache的Hadoop和Hive，以及graph/triple存儲
分開來看，每種特性都可能構成現有數據倉庫設置的一種變體。組合起來，這些特性代表了一種與眾不同的操作環境，在規劃時必須深入到每項特性，分別對待。也就是說，首先你要了解，基于未來可能的需求，哪種架構最適合大數據分析。然后了解，如何能夠把它與現有的數據中心架構（也可能是數據倉庫型架構）結合起來。
那么未來有哪些可能性需求呢？有跡象表明，每個機構都會想要在下列特性中尋求一個獨特的組合：
1.為了維護客戶忠誠度和出于營銷目的，對中型客戶的社交媒體數據進行有目標訪問--無需實時數據；
2.同樣，對于預期銷售而言也是需要的，但實時數據將會帶來更大價值；
3.出于安全考慮，當網頁瀏覽者試圖訪問公司數據時，有必要對該訪問者的社交媒體數據進行少量實時訪問；
4.實時訪問“戰略威脅”數據，例如，對公司的負面宣傳信息或是給公司造成不良影響的災難信息，通常來講造成的影響較小，但有時波及范圍也很廣。
5.為了進行市場分析對大量大數據進行訪問--無需實時數據；
6.為了開展具體行業或具體機構新產品研發， 對大量和超大量社交媒體數據進行訪問。這里，同樣不需要實時數據，但是訪問速度越快效果越好。
上述組合要求決定了通常的數據需求量和交付速度，以及在“數據潔凈度”和“數據及時性”方面的折衷取舍。
我們現在來看看，針對這些個案的最優架構：
1.訪問目標客戶的數據，你可能需要在每朵云上安裝查詢工具，滿足內部數據存儲需要，在不至于向競爭對手披露信息前提下對數據進行分析。
2.對于目標預期和銷售過程數據，你可能需要在每朵云上添加本地數據庫，方便針對特定目標信息進行快速交付。
3.針對安全掃描，你可能需要在Hadoop旁邊部署能實現告警和單用戶查詢的軟件，并能把結果信息直接反饋給內部管理員。
4.對于“戰略威脅”數據，你可能需要在每朵云上建立高效，高容量的本地數據庫，并且數據庫相互間能跨云聯合進行協作，可執行預分析。如果可能的話，在威脅抵達數據中心或單位其它部門前，該消息將直接反饋到系統，系統對此自動做出回應。
5.對于市場分析，你可能需要云-本地“緩存”的高性能數據庫，能幫助過濾數據。這樣的話，可以把數據壓縮到數據倉庫要求的大小，而且可能的話，還能對數據進行預清潔。而現有的像extract, transform, load (ETL)這些工具還無法適應新型數據的這些要求。
6.對于研發，你可能需要內部且獨立的分析數據庫，同時要有允許跨云查詢的數據聯合功能。
假設你需要所有這六項內容？那么你要考慮：
·數據聯合和跨數據庫查詢軟件，諸如Composite Software公司和Denodo公司的產品
·高性能和大容量數據庫技術，例如內存和柱體技術，來自于EMC Greenplum公司，或者Sybase IQ公司的解決方案。
·低成本，靈活性的，云適應型查詢/分析工具，例如Birst,或者Tableau.
·用于研發的內部網狀架構
那么，現在要如何把它與現有架構相結合呢？通常根據企業的規模，解決途徑可劃分為下列兩大陣營：
1.中小型企業（SMBs）往往沒有數據倉庫，即使有，功能也不齊全。那樣的話，在必要的數據倉庫性能開始產生之際，能在云上盡量運行的PaaS架構是一個好選擇。
2.大型企業有著大型主機，小型服務器群組，數據倉庫，數據集市，以及架構中現有基礎設施，因此確實要創建一個PaaS架構。最好采用像IBM公司這樣的現行供應商提供的方案，把公共云上的PaaS架構與現有商業智能/分析/數據倉庫架構相結合。
綜上所述，不要認為，把大量大數據從一個云直接吸納到數據倉庫是最理想的解決方案。因為當你這么做時，你的競爭對手將會利用他們的IT資源對其顧客進行有針對性的，更深層的靈活分析，并推動他們的品牌深入你的市場。在內部分析和云分析功能之間設置防火墻是一回事，不做任何公共駐云分析又是另一回事。簡言之：
·要接受：部分分析需在企業外部進行
·要承認：大型而且“不潔凈”數據需要分別處理
要同意：為獲得最佳效果，大型數據和傳統數據需要有獨立而又互相協作的架構。
京公網安備 11010502049343號