近年來，伴隨著全國各地公安機關信息化的迅猛發展，數據共享和深化應用的需求空前高漲。但是，隨著數據的匯聚和數據量的爆炸式增長，傳統的數據庫和數據倉庫技術出現了諸多瓶頸問題，特別是對于 PB 級的非結構化數據處理以及多維度關聯分析、數據挖掘、情報研判等需求，傳統的數據存儲和處理方式都面臨著效率低、成本高、可靠性差、擴展能力不足等不可逾越的障礙。以搭建“大數據”處理和分析平臺為突破口，尋求公安信息化應用新的效益增長點，已經成為公安機關信息化應用的熱點問題。本文以兩個案例的形式，分析了公安機關在“大數據”方面開展的一些新的實戰應用和新的思維方法，以期供廣大同行借鑒和參考。
案例一：電子警察疑似套牌車自動識別系統
（1）實例目標
這個實例目標是在近 12 億“電子警察”(卡口視頻抓拍系統) 抓拍車牌數據中查找出套牌車輛，可稱為“疑似套牌車模型”。和通用的數據挖掘方法一樣，對于大數據的處理原則也是“以業務規則為核心，以數據資源為基礎，以運算能力為支撐”。這個實例是在 2011 年初啟動的，大約經過了半年多的研發和應用探討，取得了一定的應用實效。
(2) 操作流程
第一步，業務規則制定。這個實例的業務排查規則是: 在一個較短的時間段內，同一車牌不可能被不同路口“電子警察”抓拍設備抓拍到。這其中涉及到三個變量，一個是時間，第二個是車牌，第三個是“電子警察”的地理位置。在與交警部門進行了業務規則研究后，最終確定的數量是:在 5 分鐘之內，如果在距離大于 10 公里的“電子警察”同時抓拍到同一個車牌，這個車牌可能就是套牌，因為車速一般不能超過 120 公里/小時。另外，以“電子警察”位置經緯度測算其直線距離，比一般道路實際距離要短。
第二步，數據準備。如果面對的是千萬級的數據，常規 SQL 查詢語句就可以解決這個問題。數據量如果再大，采用分區表的形式一般也可以解決這個問題。但是，此實例中，遇到的第一個數據是車輛抓拍數據。數據量是 3 年“電子警察”抓拍的數據總和，目前南通的抓拍量大約是一天 800 萬左右，最后 3 年的數據匯聚到 12 億左右。因此，這個實例的總體技術框架可以用“HADOOP + OＲACLE”來描述億級以上的數據。這里指的是數據條數，因為針對的都是結構化的數據，筆者認為，先把結構化數據的海量數據處理到位，然后再開始啟動半結構化、非結構化的大數據研究。億級以上的數據用分布式的 HADOOP 來直接處理，或者稱為預處理，可處理至千萬級或者百萬級數據，然后再依托傳統的 OＲACLE 來處理。第二個數據是“電子警察”的地理位置數據，可以從 PGIS 取得支撐，取得全市“電子警察”的經緯度信息。將本市所有“電子警察”卡口的坐標位置建立輔助表，如表 1 所示。記錄每個卡口的經緯度，為計算不同卡口之間的距離準備。最后，還有一個重要的數據———時間。全市“電子警察”抓拍設備必須進行統一授時，否則這個億級以上的數據模型就失去了意義。
第三步，利用 HADOOP 計算。這是最關鍵的一步，將 12 億“電子警察”抓拍車牌數據，利用分塊的模式，分別存儲到 10 臺普通 PC 服務器集群的 HADOOP 分布式存儲環境中。每個塊存儲 300 萬數據，分 380 個塊存儲在 9 臺數據節點中，共占用存儲空間 103 G。在數據傳輸交換上，使用分布式索引創建工具，經過 3 小時 10 分鐘將數據從不同的oralce 數據庫存儲到 HDFS 分布式存儲環境中，見圖1 所示。
而后，采用 HADOOP 的 MAP －ＲEDUCE 模型，對分塊數據分別進行運算，首先使用 MAP 對每個車在卡口的時間進行分組，MAP 執行結束后，使用ＲEDUCE 對各個塊的數據按照車牌號進行匯總，再使用 MAP 對每個車在卡口出現的時間與不同卡口之間的距離進行運算，對于在小于 5 分鐘內，在距離大于 10 公里的卡口同時出現的車輛，認定為疑似套牌車。最后使用 ＲEDUCE 將統計結果匯總。其具體執行過程見圖 2 所示。
第四步，結果。這個運算模型在 10 臺 PC 服務器組成的 HADOOP 集群中，以 40 個初始 MAP 進行分布式執行，經過約 50 分鐘執行完畢，共排查出394 輛疑似套牌車牌。這個效率已經基本能夠滿足應用要求
( 3) 結果應用。
(人工輔助)技術部門和交警部門共同研究分析了上述結果，發現在這 394 輛車里，有約三分之二( 也就是 250 輛左右) 是因為自動識別系統的誤判造成的錯誤信息( 如 B 和 8、D 和 0 容易出現誤判) ，這說明公安機關抓拍設備的識別率還要提升。在余下的約 150 輛車中，已經在控的約有 60 輛，其他 90 余輛車通過人工辨別、研判，確認為新發現的套牌車，現已全部納入了套牌車布控查緝系統開展后續工作。
案例二：違法犯罪人員入住賓館規律
實例目標：分析 10 年以來在押的違法犯罪人員曾入住旅館的規律，為治安防控核查工作提供指導。
通過多方努力，我們匯聚到 10 年的旅館數據約5 億余條，10 年內本地在押的人員數據約 65 萬條。利用計算機集群，首先建立了比對模型，根據 HADOOP開展比對來組織數據，將 65 萬條人員數據放到 5 億條住宿數據中去找相同項。以“1O + 1”的模式，即10 臺服務器作數據節點，1 臺作為控制節點，“跑”一遍的時間是 50 分鐘左右。最后得到 10 年間在押的人員曾經入住旅館數據約72. 1 萬條。
( 1) 全部在押人員各時段入住旅館情況的占比分析，具體情況見圖 3。
這是一種比較常規的分析方式。面對 70 萬的小數據，從 10 年全部在押人員自身入住情況對比，可稱為“自占比”分析。從上圖 3 可以看出，在押人員入住“自占比”的第一峰值在 22 時左右，第二峰值在 13 時左右，谷值在 6 時左右。這說明，按照 10年來積累的數據看，我們關注嫌疑對象入住旅館的重點時段應該是夜間 10 時左右和下午 1時左右。
( 2) 針對全部入住旅館人員各時段占比分析，具體情況見圖4
根據 10 年來全部數據量的規模，傳統的關系型數據庫處理這些數據效率會很低。用 HADOOP 的MAP －ＲEDUCE 計算框架，15 分鐘左右全部完成計算工作，得出圖 4 中的結果，可與第一項在押人員入住規律作比較。通過對比可以明顯看出，在押人員入住“自占比”趨勢與全部人員入住占比的趨勢基本一致。這說明在 21 時和下午 1 時左右，本身也是正常人員入住旅館的高峰時間。因此，這項分析雖有意義，但是針對實戰的指導性分析還需要進一步研究。
( 3) 各時段在押入住旅館人員與該時段全部正常入住人員的占比分析。
如果把上面的比較分析方式稱為關注對象的“自占比”，那還有另一種比較方式，即關注對象與全部對象之間的比較，我們可稱為“全占比”。各時段在押人員入住旅館的“全占比”情況見圖 所示。
進一步思考通過上述兩個案例分析，我們不難發現，基于’大數據#統計分析相關規律的業務建模，可能會逐步超越目前的行業經驗，發現事物本質的新的聯系，顛覆一些傳統的行業規則$因此，迎接’大數據#時代的到來最需要的是一種全新的思維方法。
大數據思維是一個不斷演進的過程
兩個實例代表了對’大數據#處理與應用的一個演進過程。在起步階段，我們受到’小數據”思維的慣性控制，增加計算能力的直接目的就是為了提高精確性，總希望直接找到違法犯罪分子。但因為數據量龐大，傳統的技術效率低，不能完成海量數據處理任務了，因此想到了分布式計算，并取得了一些應用成效。
在第二個案例中，我們進一步發現，大數據分析中的精確查詢之外，還有更廣泛應用的更重要的趨勢分析和宏觀研判。大數據處理更能體現的是一種群體行為，通過海量的數據去發現一個隱藏在數據背后的客觀事實，公安大數據要更加重視通過各種工具與方法，通過海量數據的分析發現大數據中隱含的知識和關系。這種’大數據#的思路決定了我們今后的出路! 規律分析是未來一個時期公安’大數據#應用的重點從上述實例中可以看出，引用的數據并不是非常龐大，分析方式是比較簡單的比對方法，展示方式也是用較直接和較單一的折線圖，僅此就能挖掘出服務實戰的結果，這是傳統的數據處理方式無法實現的$這就是’大數據#思維產生的作用。
在’小數據#時代，由于掌握的數據量不夠多，范圍不夠全，因此我們的決策更依賴直覺和經驗，對事物規律性的把握往往需要一個很漫長的積累過程，而且也容易遺漏。但是，隨著’大數據#時代的來臨，豐富的多維度數據應用使得公安傳統的業務思路得到了極大的豐富，大數據破題的真正關鍵，在于領會貫通大數據的思維方式。
京公網安備 11010502049343號