到目前为止，你的大数据分析和商业智能项目还在顺畅地自行运转。但从长远来看，通过对现有架构进行简单扩展来保持顺畅的数据访问可能不是最好的解决办法。
请考虑以下“大数据”特性：
·以网页上为主(不属于先前的内部数据传送)
·涉及多个云环境
·与社交媒体应用紧密关联，例如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资源对其顾客进行有针对性的，更深层的灵活分析，并推动他们的品牌深入你的市场。在内部分析和云分析功能之间设置防火墙是一回事，不做任何公共驻云分析又是另一回事。简言之：
·要接受：部分分析需在企业外部进行
·要承认：大型而且“不洁净”数据需要分别处理
要同意：为获得最佳效果，大型数据和传统数据需要有独立而又互相协作的架构。
