应对“大数据”分析

到目前为止，你的大数据分析和商业智能项目还在顺畅地自行运转。但从长远来看，通过对现有架构进行简单扩展来保持顺畅的数据访问可能不是最好的解决办法。

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

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

●涉及多个云环境

●与社交媒体应用紧密关联，例如Facebook, Twitter和Linkedin

●规模空前

●数据有时 “不洁净”，甚至不可用

●数据大部分是非结构化

●至少要引入几种新工具，例如Apache的Hadoop和Hive，以及graph/triple存储

分开来看，每种特性都可能构成现有数据仓库设置的一种变体。组合起来，这些特性代表了一种与众不同的操作环境，在规划时必须深入到每项特性，分别对待。也就是说，首先你要了解，基于未来可能的需求，哪种架构最适合大数据分析。然后了解，如何能够把它与现有的数据中心架构(也可能是数据仓库型架构)结合起来。

那么未来有哪些可能性需求呢?有迹象表明，每个机构都会想要在下列特性中寻求一个独特的组合：

1.为了维护客户忠诚度和出于营销目的，对中型客户的社交媒体数据进行有目标访问--无需实时数据;

2.同样，对于预期销售而言也是需要的，但实时数据将会带来更大价值;

3.出于安全考虑，当网页浏览者试图访问公司数据时，有必要对该访问者的社交媒体数据进行少量实时访问;

4.实时访问“战略威胁”数据，例如，对公司的负面宣传信息或是给公司造成不良影响的灾难信息，通常来讲造成的影响较小，但有时波及范围也很广。

5.为了进行市场分析对大量大数据进行访问--无需实时数据;

6.为了开展具体行业或具体机构新产品研发， 对大量和超大量社交媒体数据进行访问。这里，同样不需要实时数据，但是访问速度越快效果越好。

上述组合要求决定了通常的数据需求量和交付速度，以及在“数据洁净度”和“数据及时性”方面的折衷取舍。

我们现在来看看，针对这些个案的最优架构：

1.访问目标客户的数据，你可能需要在每朵云上安装查询工具，满足内部数据存储需要，在不至于向竞争对手披露信息前提下对数据进行分析。

2.对于目标预期和销售过程数据，你可能需要在每朵云上添加本地数据库，方便针对特定目标信息进行快速交付。

3.针对安全扫描，你可能需要在Hadoop旁边部署能实现告警和单用户查询的软件，并能把结果信息直接反馈给内部管理员。