（3）数据类型多。交通数据由于产生的来源广泛，处理的方法多样，其数据类型繁多，包括文本、图片、视频、二维图表等多种类型。
（4）价值复杂。这表现在价值密度降低，但是价值提高。由于数据产生量大，产生频率高，使得数据本身的价值密度降低。以交通监控视频为例，连续24小时的监控视频，可能仅有2秒钟有用，但是这2秒钟的数据产生的作用非常大，比如协助抓获了犯罪分子。
面对具有这些特点的数据，普通的单个服务器无法满足数据的存储和管理要求，同时也无法在短时间内完成计算任务，必须借助海量计算能力来完成。用传统技术处理交通数据时会面临以下挑战。
首先是，数据存储方面的挑战。PB级交通数据是传统的单机版文件系统所不能够胜任的，需要能够存储海量数据的分布式文件系统。但是购置分布式文件系统与硬件又需要花费不小的费用，在摩尔定律作用下，低端服务器是最佳选择。但是，与专业的高性能和高可靠小型机、大型机等高端服务器相比，低端服务器较容易发生硬件故障，服务器硬件出错是正常而非异常的。由大量廉价、易损的硬件组成的系统，必须保持文件系统整体的可靠性。因此，在一堆廉价但不可靠的硬件上构建可靠的分布式文件系统是当前分布式文件系统面临的重要挑战。
其次是，数据管理方面的挑战。传统的数据库技术在管理多类型的交通数据方面，显得力不从心。主要有以下几个方面的原因。
（1）数据可靠性的挑战。海量的数据增长和快速的变化，需要不断增加和调整服务器和存储设备。这就要求海量数据的数据库管理系统在保障可靠性方面充分考虑到底层硬件的不可靠性，即使服务器节点出现宕机的情况，也不会造成数据的丢失，数据的恢复也不能对当前的管理系统正常运行造成任何影响。
（2）对多类型的数据进行管理的挑战。前面说过，城市交通系统针对结构化和非结构化的数据，其模式通常是不固定的。而传统关系型数据库表结构固定，不擅长处理模式不确定的数据，需要一种新型结构的分布式数据库管理系统来管理模式不固定的数据。
（3）可扩展性的挑战。对传统关系数据库来说，数据范式是一种帮助人们又快又好地设计数据库的手段，严格按范式设计的数据库能为用户提供正确、丰富、灵活的查询选项。但模式分解导致数据表多，使得其只有在同一个服务器节点上进行扩展时才比较方便，并不适合在分布式环境下进行扩展。以协同布控应用场景为例，按照传统关系型数据库设计的部分表结构（图中对涉及用户隐私的具体信息使用“x”符号代替），关于车主的信息散落在车牌识别数据库表、基本信息数据库表、通话记录数据库表等多个数据库表中，如图1．3所示。由于车牌识别数据和通话记录数据量很大，在分布式环境下，当一台服务器容量不够时，需要将数据划分后扩展到新的节点上。若按照该表结构设计进行扩展，很容易造成一个车主的不同信息散落于不同的节点上，在查询车主的所有相关信息时，不得不涉及不同服务器上数据库表的关联操作。
……
展开
