针对视频云存储技术，业内主流安防厂家可以说已经做得炉火纯青了。安防厂家将云存储的底层技术与安防专用流媒体结合，形成了安防特色云直存产品。无需外部设备拉流，存储可直接接收前端传输过来的数据。但如今，安防行业也发生了翻天覆地的变化，视频流已经完全不能代表安防行业的数据特色了，AI时代即将来临。

　　 

　　目前业内的AI数据内容主要有人脸数据和结构化数据两种，包含机动车、非机动车、行人。数据类型包含了图片、抓拍记录、报警记录、图片属性信息等一系列非结构化数据。这类数据的特点是比较碎片化，与视频流数据类型不同。视频流可以保证持续不断的写入，而且文件打包大小比较均匀。但是碎片化的文件，由于其大小和数量都是未知，零散的写入对CPU和硬盘资源的消耗都是很大的。对CPU来说，需要同时处理很多的线程。对于硬盘来说，磁头需要不断的换道寻址，大大减少了硬盘的寿命。

　　 

　　对于这种比较特别的数据类型，传统的流媒体服务无法进行处理。目前主流安防厂商都为此专门开发了用于拉取此类数据流的软件，安装在通用的存储硬件中就可实现存储功能。由于是新兴市场，目前绝大多数场景中使用单台设备存储就可以满足，但随着AI的普及，数据量也将不断增大，对于一座城市来讲，为了掌握城市中交通状况，需要采集每一条道路、每一个路口的车辆数量信息、拥堵信息以及车流走向等。通过算法后的数据，可以模拟城市交通的运行状况，以此来预测下一秒的动向，及时作出预警方案，实现真正的大数据时代。当数据规模扩大到一定程度的时候，底层的云存储机制将是人们不得不考虑的技术支撑。但这样的话问题就出现了，传统安防云存储只有对视频的接入能力，无法主动获取结构化数据。于是，在未来的短期内，这种AI数据云存储势必成为存储应用层的主流。

　　 

　　虽然通过应用层与底层的对接，可以实现一体化的AI数据云存储，但是当数据类型进一步进化，出现新的数据结构时，云存储将如何应对？一味地做兼容开发势必不是长久之计，还会浪费人力物力。更糟糕的是，如果在一个现场存在多种数据类型，那就需要部署多套云存储来进行不同数据的存储，这对存储空间是一种极大的浪费，占用的资金成本也极高，可行性极低。

　　针对安防行业的业务特性，云存储的以下两大技术方向需要重点突破：

　　一是高效元数据组织和框架构建，解决大规模集群管理和海量文件的问题。

　　整个分布式系统中需要管理的节点数成百上千台，用户的一个真实文件会被分布在多台节点上，由多台节点负责承载真实数据的写入。在读取时需要经过元数据管理服务器请求拿到数据位置信息，从而发起读取。而针对元数据请求的性能是逐级递归还是一次访问就能完成操作，是衡量整个系统性能的关键要素。

　　对于一个单独的大文件，是否能充分发挥读写性能，涉及拆分粒度问题。元数据服务作为核心，需要能在支持上千的节点、上万的客户端请求完成高速并发处理，这在最基础的协议框架和信令交互模型上就需要考虑齐全，通过超高协议序列化和反序列化性能、可扩展的协议设计、网络框架模型、任务处理模型这些底层基础件上一层层向上，在每个环节中都做到高效处理。一个合理元数的组织结构可以采用类型对象存储的分桶方式，让数据hash分布，实现文件的简单高效管理，对于桶内数据不需要采用类似传统目录树形式进行逐级的遍历，仅需一次定位就可以完成操作。

　　对于文件的数据块组织管理，一方面要控制较好的粒度实现IO能充分发挥多节点多磁盘的优势，另一方面需要降低元数据的管理压力，提升管理的集群规模数和文件数量。在存储节点上存在用户的数据块被切分成一段段落在各个磁盘内，系统长期运行或者重启、掉电、字节跳变等，需要能够将节点管理的数据块和元数据中的数据块进行比较，查出差异项完成修正，对于损坏数据提早触发恢复，这就要求元数据在组织合理，能够快速的查找到对应节点的元数据信息，并在比较处理过程中不影响其他的元数据实时访问和新增。

　　二是明确的读写模型对提供业务使用语义，解决视频和图片不同写入和读取要求。

　　常见的读写并非提供一个接口就行，需要有明确的读写语义。比如文件系统提供的是文件操作语义，按open/write/read/close模式，并支持seek和修改、追加的语义；S3接口提供的是putObject/getObject接口，按照一次完成上传，上传后可以见的语义；HDFS提供的是类似文件系统的操作语义，但不支持修改。

　　对视频而言，应该按照文件的语义但又无需支持追加和修改，仅需支持流式的写入，并支持边写边读，避免业务层需要开大缓存或者将视频文件缓存本地才能上传。对于图片写入方式也是同理，也应支持文件流方式写入。虽然看上去图片可以一次写入一张，但是现在的图片高清化可以有1MB或者更大，仅通过设置缓存大小完成应用程序的一张图写入，会出现云存储的客户端内的内存占用过大或者写入不够平滑会存在一顿一顿的效果并引发缓存满出现图片丢失问题。在读取上，对一张图片内数据没写入完成无需可读，但是整张写入完成是要立即可读。

　　再从文件名角度看，由于每张图片对应一条前端的抓拍记录，因此对图片地址可以随结构化记录一起存储，对于用户来说无需关系图片地址生成方式，这意味着图片地址可以由系统返回进行生成。对于视频流存储后形成的录像文件来说，使用方可以无需记录每段录像文件名，通过云存储提供的指定文件名能力，按照自定义的业务逻辑生成文件名，后续按照规则进行查询即可完成录像列表或者指定录像文件的回放。

　　另外，随着AI在安防领域落地，异构云存储将存储的应用层与文件管理层、资源分配层独立开发部署，这样一来，做云存储底层和硬件的厂商可以专心保障存储机制的稳定性，应用厂商可以专心做不同数据类型的兼容。只要底层标准化做好，各大安防与存储厂商就可以形成一个稳定的生态合作。一方提供物理资源，一方提供上层业务，不再局限于软硬一体的产品模式。在此基础上，一些受限于资本投入的厂家甚至可以开发自己的云服务。上层的应用软件甚至可以存储在云端，作为一个公用资源，让终端用户开发属于自己的专业存储服务。