大数据不仅有着数据量大、类型繁多、需要超快的处理速度、数据价值密度低等特点，更面临着涉及数据结构、数据存储、数据计算等多方面的问题。在各个领域，我们都要求大数据的数据量足够大，要求数据具有真实性、时效性，要求更高的处理速度。尤其在交通运输物流领域，实时性数据处理需求更为明显，而且交通运输物流数据早已不仅仅局限于结构化的数据，大部分数据都是非结构化的或者是半结构化的，传统的关系数据库按照行式存储，建立索引和视图会花费大量的时间和资源，面对查询需求必须大量膨胀才能满足性能要求，可见传统的关系数据库已经远远不能满足大数据的要求了。

我们需要找到满足大数据要求的数据存储模式运用于交通运输物流领域。早期的基于C/S架构的单数据库模式监控规模不大，传感器采集数量有限，所有的数据都存储到一个数据库中，如图3.2所示，显然这种单数据库模式是不可能适用于交通运输物流领域的大数据分析的。

图3.2　早期的单数据库模式

2000年以后，Web技术取代了C/S架构，成为主流架构，逐渐出现了早期网络存储模式。机房监控软件属于行业应用系统，要求实时数据的刷新，所以早期的网络存储模式不仅包括呈现综合信息的Web页面，也包含了呈现实时性要求的交互页面的桌面客户端，如图3.3所示描述了这种早期的网络存储模式。

图3.3　早期的网络存储模式

这种网络存储模式以数据库（Database）为中心，应用服务器（App Server）和桌面应用程序（Desktop App）直接连接数据库；Web服务器和客户端程序（Rich Internet App）不直接连接于数据库，而是直接连接应用服务器。这种模式运行一段时间之后，用户不仅希望获取告警和实时数据，同时也希望能收集所有的历史数据，将历史数据以报表的形式呈现出来，帮助他们做更进一步的分析。显然这种简单的早期网络存储模式慢慢也不能适应越来越多的要求了，人们开始研究网络存储模式的切分来改进早期的网络存储模式。有两种切分方法：垂直切分和水平切分。

垂直切分是考虑历史数据量大，使用单一数据库系统反应速度慢，压力大的问题，将单一数据进行垂直切分，分离出配置库、历史库和交换库，部署到不同的机器上，垂直切分后的网络存储模式如图3.4所示。其中配置库（Config Database）用于存储系统运行环境和实体关联信息；历史库（History Database）用于存储实时数据和历史数据；交换库（Swap Database）即临时库，用于存储复杂计算中间值或用于第三方对接系统数据交换。

随着系统的运行，历史库承载的压力越来越大，慢慢就出现了整个系统响应速度变慢，用户操作体验变差，查询响应时间变长甚至超时的问题。开发人员用水平切分来解决这些问题，水平切分就是对历史数据进行分类，然后对每种类型按月、按年分表，水平切分是在垂直切分的基础上进行的。(www.daowen.com)

伴随着全国各地大数据中心的建设，中小型机房监控系统逐步过渡到了数据中心基础设施管理平台，数据中心对新的平台要求更为严格。7×24 h的不间断实时监控，不仅要求即时对故障做出响应，还需要能根据历史数据，在故障出现之前做出预警，需要平台有高安全性；新的平台规模大，数据中心机柜多，占地面积大，甚至能独占一整栋楼；新的平台业务计算复杂，目的是要实现科学化、智能化管理，流程管理、大数据决策等业务导致计算量呈几何倍数增长。以数据为中心的存储模式已经很难适应平台化管理的需求，必须要引入新一代的存储模式了，大数据混合存储模式架构应运而生。

图3.4　垂直切分后的网络存储模式

Hadoop架构已经成为当前主流的大数据混合存储模式架构，它提供了一种通用的资源管理YARN和分布式文件存储架构HDFS，用户根据需求，实现定制化的数据处理应用，包括MapReduce、Spark、Storm等新一代处理应用。以Hadoop技术为平台的大数据混合存储模式如图3.5所示。

该大数据混合存储模式的最底层是用传统的关系型数据库（RDMS）和Hadoop集群组成，关系型数据库用来存储配置信息，历史数据存储到分布式文件存储系统（HDFS）中，对于上层的数据交互有Hive数据仓储、Hbase数据库、Spark RDD等高级接口可供选择。存储在Hadoop集群上的历史数据由Hadoop应用（如分布式计算Map/Reduce或者实时计算Storm）直接完成，就不需要使用交换库了，新的架构中就不存在交换库。

中间层是计算节点（Compute Node）集群，集群上运行的程序既包括传统应用服务器（App Server）和Web服务器（Web Server），也包括与Hadoop应用协作的分析服务器（Analysis Server）。

顶层用于呈现，呈现内容包括传统的报表和新式的交互体验；承载方式包括Web浏览器、移动设备以及桌面应用等。

图3.5　大数据混合存储模式