请考虑以下“大数据”特性：

●以网页上为主(不属于先前的内部数据传送)

●涉及多个云环境

●与社交媒体应用紧密关联，例如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.对于研发，你可能需要内部且独立的分析数据库，同时要有允许跨云查询的数据联合功能。

那么，现在要如何把它与现有架构相结合呢?通常根据企业的规模，解决途径可划分为下列两大阵营：

1.中小型企业(SMBs)往往没有数据仓库，即使有，功能也不齐全。那样的话，在必要的数据仓库性能开始产生之际，能在云上尽量运行的PaaS架构是一个好选择。

2.大型企业有着大型主机，小型服务器群组，数据仓库，数据集市，以及架构中现有基础设施，因此确实要创建一个PaaS架构。最好采用像IBM公司这样的现行供应商提供的方案，把公共云上的PaaS架构与现有商业智能/分析/数据仓库架构相结合。