針對視頻云存儲技術(shù)，業(yè)內(nèi)主流安防廠家可以說已經(jīng)做得爐火純青了。安防廠家將云存儲的底層技術(shù)與安防流媒體結(jié)合，形成了安防特色云直存產(chǎn)品。無需外部設(shè)備拉流，存儲可直接接收前端傳輸過來的數(shù)據(jù)。但如今，安防行業(yè)也發(fā)生了翻天覆地的變化，視頻流已經(jīng)*不能代表安防行業(yè)的數(shù)據(jù)特色了，AI時代即將來臨。
目前業(yè)內(nèi)的AI數(shù)據(jù)內(nèi)容主要有人臉數(shù)據(jù)和結(jié)構(gòu)化數(shù)據(jù)兩種，包含機動車、非機動車、行人。數(shù)據(jù)類型包含了圖片、抓拍記錄、報警記錄、圖片屬性信息等一系列非結(jié)構(gòu)化數(shù)據(jù)。這類數(shù)據(jù)的特點是比較碎片化，與視頻流數(shù)據(jù)類型不同。視頻流可以保證持續(xù)不斷的寫入，而且文件打包大小比較均勻。但是碎片化的文件，由于其大小和數(shù)量都是未知，零散的寫入對CPU和硬盤資源的消耗都是很大的。對CPU來說，需要同時處理很多的線程。對于硬盤來說，磁頭需要不斷的換道尋址，大大減少了硬盤的壽命。
對于這種比較特別的數(shù)據(jù)類型，傳統(tǒng)的流媒體服務(wù)無法進行處理。目前主流安防廠商都為此專門開發(fā)了用于拉取此類數(shù)據(jù)流的軟件，安裝在通用的存儲硬件中就可實現(xiàn)存儲功能。由于是新興市場，目前絕大多數(shù)場景中使用單臺設(shè)備存儲就可以滿足，但隨著AI的普及，數(shù)據(jù)量也將不斷增大，對于一座城市來講，為了掌握城市中交通狀況，需要采集每一條道路、每一個路口的車輛數(shù)量信息、擁堵信息以及車流走向等。通過算法后的數(shù)據(jù)，可以模擬城市交通的運行狀況，以此來預(yù)測下一秒的動向，及時作出預(yù)警方案，實現(xiàn)真正的大數(shù)據(jù)時代。當數(shù)據(jù)規(guī)模擴大到一定程度的時候，底層的云存儲機制將是人們不得不考慮的技術(shù)支撐。但這樣的話問題就出現(xiàn)了，傳統(tǒng)安防云存儲只有對視頻的接入能力，無法主動獲取結(jié)構(gòu)化數(shù)據(jù)。于是，在未來的短期內(nèi)，這種AI數(shù)據(jù)云存儲勢必成為存儲應(yīng)用層的主流。
雖然通過應(yīng)用層與底層的對接，可以實現(xiàn)一體化的AI數(shù)據(jù)云存儲，但是當數(shù)據(jù)類型進一步進化，出現(xiàn)新的數(shù)據(jù)結(jié)構(gòu)時，云存儲將如何應(yīng)對？一味地做兼容開發(fā)勢必不是長久之計，還會浪費人力物力。更糟糕的是，如果在一個現(xiàn)場存在多種數(shù)據(jù)類型，那就需要部署多套云存儲來進行不同數(shù)據(jù)的存儲，這對存儲空間是一種極大的浪費，占用的資金成本也*，可行性極低。
針對安防行業(yè)的業(yè)務(wù)特性，云存儲的以下兩大技術(shù)方向需要重點突破：
一是元數(shù)據(jù)組織和框架構(gòu)建，解決大規(guī)模集群管理和海量文件的問題。
整個分布式系統(tǒng)中需要管理的節(jié)點數(shù)成百上千臺，用戶的一個真實文件會被分布在多臺節(jié)點上，由多臺節(jié)點負責承載真實數(shù)據(jù)的寫入。在讀取時需要經(jīng)過元數(shù)據(jù)管理服務(wù)器請求拿到數(shù)據(jù)位置信息，從而發(fā)起讀取。而針對元數(shù)據(jù)請求的性能是逐級遞歸還是一次訪問就能完成操作，是衡量整個系統(tǒng)性能的關(guān)鍵要素。
對于一個單獨的大文件，是否能充分發(fā)揮讀寫性能，涉及拆分粒度問題。元數(shù)據(jù)服務(wù)作為核心，需要能在支持上千的節(jié)點、上萬的客戶端請求完成高速并發(fā)處理，這在基礎(chǔ)的協(xié)議框架和信令交互模型上就需要考慮齊全，通過超高協(xié)議序列化和反序列化性能、可擴展的協(xié)議設(shè)計、網(wǎng)絡(luò)框架模型、任務(wù)處理模型這些底層基礎(chǔ)件上一層層向上，在每個環(huán)節(jié)中都做到處理。一個合理元數(shù)的組織結(jié)構(gòu)可以采用類型對象存儲的分桶方式，讓數(shù)據(jù)hash分布，實現(xiàn)文件的簡單管理，對于桶內(nèi)數(shù)據(jù)不需要采用類似傳統(tǒng)目錄樹形式進行逐級的遍歷，僅需一次定位就可以完成操作。
對于文件的數(shù)據(jù)塊組織管理，一方面要控制較好的粒度實現(xiàn)IO能充分發(fā)揮多節(jié)點多磁盤的優(yōu)勢，另一方面需要降低元數(shù)據(jù)的管理壓力，提升管理的集群規(guī)模數(shù)和文件數(shù)量。在存儲節(jié)點上存在用戶的數(shù)據(jù)塊被切分成一段段落在各個磁盤內(nèi)，系統(tǒng)長期運行或者重啟、掉電、字節(jié)跳變等，需要能夠?qū)⒐?jié)點管理的數(shù)據(jù)塊和元數(shù)據(jù)中的數(shù)據(jù)塊進行比較，查出差異項完成修正，對于損壞數(shù)據(jù)提早觸發(fā)恢復(fù)，這就要求元數(shù)據(jù)在組織合理，能夠快速的查找到對應(yīng)節(jié)點的元數(shù)據(jù)信息，并在比較處理過程中不影響其他的元數(shù)據(jù)實時訪問和新增。
二是明確的讀寫模型對提供業(yè)務(wù)使用語義，解決視頻和圖片不同寫入和讀取要求。
常見的讀寫并非提供一個接口就行，需要有明確的讀寫語義。比如文件系統(tǒng)提供的是文件操作語義，按open/write/read/close模式，并支持seek和修改、追加的語義；S3接口提供的是putObject/getObject接口，按照一次完成上傳，上傳后可以見的語義；HDFS提供的是類似文件系統(tǒng)的操作語義，但不支持修改。
對視頻而言，應(yīng)該按照文件的語義但又無需支持追加和修改，僅需支持流式的寫入，并支持邊寫邊讀，避免業(yè)務(wù)層需要開大緩存或者將視頻文件緩存本地才能上傳。對于圖片寫入方式也是同理，也應(yīng)支持文件流方式寫入。雖然看上去圖片可以一次寫入一張，但是現(xiàn)在的圖片高清化可以有1MB或者更大，僅通過設(shè)置緩存大小完成應(yīng)用程序的一張圖寫入，會出現(xiàn)云存儲的客戶端內(nèi)的內(nèi)存占用過大或者寫入不夠平滑會存在一頓一頓的效果并引發(fā)緩存滿出現(xiàn)圖片丟失問題。在讀取上，對一張圖片內(nèi)數(shù)據(jù)沒寫入完成無需可讀，但是整張寫入完成是要立即可讀。
再從文件名角度看，由于每張圖片對應(yīng)一條前端的抓拍記錄，因此對圖片地址可以隨結(jié)構(gòu)化記錄一起存儲，對于用戶來說無需關(guān)系圖片地址生成方式，這意味著圖片地址可以由系統(tǒng)返回進行生成。對于視頻流存儲后形成的錄像文件來說，使用方可以無需記錄每段錄像文件名，通過云存儲提供的文件名能力，按照自定義的業(yè)務(wù)邏輯生成文件名，后續(xù)按照規(guī)則進行查詢即可完成錄像列表或者錄像文件的回放。
另外，隨著AI在安防領(lǐng)域落地，異構(gòu)云存儲將存儲的應(yīng)用層與文件管理層、資源分配層獨立開發(fā)部署，這樣一來，做云存儲底層和硬件的廠商可以專心保障存儲機制的穩(wěn)定性，應(yīng)用廠商可以專心做不同數(shù)據(jù)類型的兼容。只要底層標準化做好，各大安防與存儲廠商就可以形成一個穩(wěn)定的生態(tài)合作。一方提供物理資源，一方提供上層業(yè)務(wù)，不再局限于軟硬一體的產(chǎn)品模式。在此基礎(chǔ)上，一些受限于資本投入的廠家甚至可以開發(fā)自己的云服務(wù)。上層的應(yīng)用軟件甚至可以存儲在云端，作為一個公用資源，讓終端用戶開發(fā)屬于自己的專業(yè)存儲服務(wù)。
