自2012年以來，公安部交通管理局在全國範圍內推廣了機動車緝查布控系統（簡稱卡口系統），通過整合共享各地車輛智能監測記錄等信息資源，建立了橫向聯網、縱向貫通的全國機動車緝查布控系統，實現了大範圍車輛緝查布控和預警攔截、車輛軌跡、交通流量分析研判、重點車輛布控、交通違法行爲甄別查處及偵破涉車案件等應用。在偵破肇事逃逸案件、查處涉車違法行爲、治安防控以及反恐維穩等方面發揮着重要作用。
隨着聯網單位和接入卡口的不斷增加，各省市區部署的機動車緝查布控系統積聚了海量的過車數據。截至目前，全國32個省（區、市）已完成緝查布控系統聯網工作，接入卡口超過50000個，匯聚機動車通行數據總條數超過2000億條。以一箇中等規模省市爲例，每地市每日採集過車信息300萬條，每年採集過車信息10億條，全省每年將匯聚超過200億條過車信息。如何將如此海量的數據管好、用好成爲各省市所面臨的巨大挑戰。
隨着車輛網以及汽車卡口應用的不斷擴大，車輛數據的不斷積累。對於原始數據的存儲、處理、查詢是一個很大的考驗，爲此我們需要一個能實時處理、多維度查詢的分佈式計算的平臺。
一、 關鍵需求分解
1. 車輛軌跡查詢
能夠根據輸入的車牌號，或通過車牌號模糊查詢對車輛進行狀態查詢、訂單軌跡追蹤。過車記錄查詢，過車軌跡查詢，落腳點分析，進行軌跡回放。
2. 地理位置檢索
能夠根據經緯度座標快速的進行經緯度的過濾，如指定一個座標，快速圈定周邊10公里內的車輛。
3. 多維碰撞, 多維度查詢
要求可以有5個條件的維度查詢，最常用的是時間，終端號，類型。
可以根據多個維度進行任意條件的組合過濾，進行數據碰撞。
也可以根據多個地理座標進行車輛碰撞分析。
4. 車輛出行規律分析，
可以按照一輛車，或一批車輛進行統計分析，瞭解車輛的出行規律，出行時間，頻繁出入地點。
5. 出行規律異常車輛分析
選定某一區域的，周邊陌生人/車的識別。出行規律異常的人/車識別。
6. 伴隨分析
人車軌跡擬合，判斷是否有代駕行爲，有尾隨，盯梢識別。
7. 數據碰撞分析
能夠根據根據多個地理位置以及時間進行數據碰撞，連環時間進行數據碰撞分析。
8. 重點車輛分析
根據統計一定區域範圍內的客運、危險品運輸、特殊車輛等重點車輛通行數量，研判發現通行規律。對在路段內行駛時間異常的車輛、首次在本路段行駛的重點車輛、2到5點仍在道路上行駛的客運車輛等進行預警提示。
9. 車輛出入統計分析
挖掘統計一段時間內在某一個區域內（可設定中心城區、地市區域、省市區域、高速公路等區域）、進出區域、主要幹道的經常行駛車輛、“候鳥”車輛、過路車輛的數量以及按車輛類型、車輛發證地的分類統計。
二、 關鍵技術能力要求
1. 數據規模-數據節點數
能夠承載日均數百億條增量，數據要可以長久保留
也要支撐未來三到五年，每天百億，甚至數千億條數據增量。
每個數據節點每天能處理20億的數據量。
2. 查詢與統計功能靈活性
根據不同的廠商，車型，往往在邏輯上有較大的區別，他們業務的不同查詢邏輯也會有較大的區別，故一個查詢系統要求非常靈活，可以處理複雜的業務邏輯，算法，而不是一些常規的簡單的統計。
能支持複雜SQL
當業務滿足不了需求的時候可以拓展SQL，自定義開發新的邏輯,udf,udaf,udtf。
要能支持模糊檢索
對於郵箱、手機號、車牌號碼、網址、IP地址、程序類名、含有字母與數字的組合之類的數據會匹配不完整，導致數據查不全，因分詞導致漏查以及缺失數據，對於模糊檢索有精確匹配要求的場景下，業務存在較大的風險
多維分析多維碰撞
要求可以有5個條件的維度查詢，最常用的是時間，終端號，類型。
3. 檢索與併發性能
每次查詢在返回100條以內的數據時能在1秒內返回，併發數不少於200（6個節點以內）。對於併發數要做到隨着節點數的增加可以按比例增加。
4. 數據導入與時效性
對數據時效性要求較高，要求某一車輛在經過產生數據後，可達到分鐘級別內系統可查可分析。對檢索性能要求很高，以上典型需求均要求能夠在秒級內返回結果及明細。
採用SQL方式的批量導入，也要支持kafka的流式導入
5. 穩定性-與單點故障
易於部署，易於擴容，易於數據遷移；
多數據副本保護，硬件不怕硬件損壞；
服務異常能自動檢測及恢復，減輕運維人員經常需要半夜起牀的痛苦；
系統不能存在任何單點故障，當某個服務器存在問題時不能影響線上業務。
數據過百億後，不能頻繁的OOM，也不能出現節點調片的情況。
系統出現異常後，可以自動偵探服務異常，並自動重啓恢復服務，不能每次調片都要運維 人員半夜去機房重啓。需要服務有自動遷移與恢復的特性，大幅減少運維人員駐場的工作量。
提供了導入與查詢的限流控制，也提供了過載保護控制，甚至在極端場景提供了有損查詢與有損服務
6. 要有較高的排序性能
排序可以說是很多日誌系統的硬指標（如按照時間逆序排序），如果一個大數據系統不能進行排序，基本上是這個系統屬於不可用狀態，排序算得上是大數據系統的一個“剛需”,無論大數據採用的是hadoop,還是spark，還是impala,hive，總之排序是必不可少的，排序的性能測試也是必不可少的。
7. 用戶接口
儘量是SQL接口。如果是程序接口學習成本與接入成本均較高。
8. 方便與周邊系統的導入導出
能與現有的常見系統如hadoop，hive ，傳統數據庫,kafka等集成，方便數據導入導出。
支持原始數據的任意維度導出
可以全表，也可以通過過濾篩選局部導出
支持數據經過各種組合計算過濾後的導出
可以將Y多個表與其他系統的多個表，進行組合篩選過濾計算後在導出
可以將多個數據從一張表導入到、另外一張表
可以將數據導出到別的系統裏面（如hive，hbase，數據庫等）
也可以將其他系統的數據導入到當前系統裏面。
可以導出成文件，也可以從文件導入。
可以從kafka流式導入，也可以寫插件，導出到kafka。
9. 數據存儲與恢復
數據不能存儲在本地磁盤，遷移難，恢復也難。
1）.磁盤讀寫沒有很好的控速機制，導入數據沒有良好的流量控制機制，無法控制流量，而生產系統，磁盤控速與流量控速是必須的，不能因爲業務高峯對系統造成較大的衝擊，導致磁盤都hang住或掛掉。
2）.本地硬盤局部壞點，造成局部數據損壞對於系統來說可能無法識別，但是對於索引來說哪怕是僅僅一個byte數據的讀異常，就會造成索引指針的錯亂，導致檢索結果數據丟失，甚至整個索引廢掉，但是本地磁盤不能及時的發現並修正這些錯誤。
3）.數據存儲在本地磁盤，一旦本地將近20T的存儲盤損壞，需要從副本恢復後才能繼續服務，恢復時間太長。
要將數據存儲在HDFS之上
1).基於HDFS做了磁盤與網絡做了讀寫控速邏輯。
2).磁盤局部壞點hdfs配有crc32校驗，有壞點會立即發現，並不影響服務，會自動切換到沒有壞點的數據繼續讀取。
3).本地磁盤損壞，HDFS自動恢復數據，不會中斷讀寫，不會有服務中斷。
10. 數據遷移
不能採取這樣的方案：
誇機房搬遷機器，不能讓運維人員細心的進行索引1對1複製，這種搬遷方案往往要數星期，且非常容易出錯。
遷移過程中爲了保證數據的一致性，需要中斷服務或者中斷數據的實時導入，讓數據靜態化落地後不允許在變化後，才能進行遷移，這種方案業務中斷時間太久。
要採取這樣的遷移方案
1.hdfs通過balance自動遷移數據。
2.可以控制遷移過程中的帶寬流量。
2.遷移過程中不中斷服務，hdfs擴容與移除機器也對服務沒影響。
11. 增加主備kafka
採用的是KAFKA主備設置，當主個KAFKA出現問題時會自動切換到備KAFKA，不影響線上業務。
12. 可擴展性-預警與在線擴容
當系統存儲出現瓶頸時能及時報警，可容易的對存儲進行擴容和數據均衡。在擴容時可以在線擴容。
13. 系統監控
有成熟的系統存儲監控平臺，可以對平臺的運行狀態進行實時監控，一旦出現問題可以及時告知監控人員.
一、 業界現有方案—優缺點分析
1. 開源大數據系統解決方案（Hadoop、Spark、Hive、Impala）
| 數據規模-數據節點數 | √ | 基於HDFS之上，數據可無限拓展，存儲PB級的數據很輕鬆。 |
| 查詢與統計功能靈活性 | √ | 1.SQL支持較爲齊全。
2.與周邊系統的集成非常方便，數據導入導出靈活。 3.支持JDBC方式，可以與常見的報表系統無縫集成 |
| 檢索與併發性能 | × | 該類系統並非爲即席查詢而設計，比較適合離線分析，通常來說一個HiveSQL運行時間從幾分鐘到幾小時不等，如果是百億規模的數據分析時間可能會達到數個小時，如果以現有XX部門的預算來看，可能需要數天的時間，究其根本原因是該類系統是採用暴力掃描的方式，即如果是100億條數據，也是採用從頭遍歷到末尾的方式掃描，性能可想而知，
基本無併發性可言。單併發就需要數小時。 |
| 數據導入與時效性 | × | HDFS的特性導致數據延遲較大，常規應用均是T+1數據，即延遲一天。 |
| 穩定性-與單點故障 | √ | 無單點故障，比較完善 |
| 排序性能 | × | 採用暴力排序方式，業界第一騰訊採用512臺機器，也是90多秒響應 |
| 用戶接口 | √ | 採用hive jdbc接口，目前hive爲大數據SQL的即席標準 |
| 方便與周邊系統
的導入導出 |
√ | 由於採用了hive接口，生態圈均基於該生態圈開發，與周圍生態系統集成非常方便，有一系列的生態工具可用，可用與常見的系統集成 |
| 數據存儲與恢復 | √ | hadoop的長項，硬件損壞，機器宕機後可自動遷移任務，不需要人工干預，中間不影響服務。
1.從一開始設計之初，Hadoop即假設所有的硬件均不可靠，一旦硬件損壞，數據不會丟失，有多份副本可以自動恢復數據。 2.數據遷移以及機器擴容有比較完備的方案，中間不停服務，動態擴容。 |
| 數據遷移 | √ | |
| 增加主備kafka | × | hive不能對接kafka |
| 預警與在線擴容 | √ | 業界有完完備的方案 |
| 系統監控 | √ | hdp有完完備的方案 |
2. 流計算系統（Storm、Spark Streaming）
| 數據規模-數據節點數 | √ | 數據規模可隨節點拓展 |
| 查詢與統計功能靈活性 | × | 無法查看明細數據，只能看特定粒度的彙總結果，而過車記錄是無法先計算出來的，即無法預知那個車有可能會犯罪，那個車會出事故，故無法預計算。 |
| 檢索與併發性能 | √ | 1.預先將需要查詢的數據計算好，查詢的時候直接訪問預計算好的結果，性能非常好。
2.預計算完畢的結果集存儲在HBase或傳統數據庫裏，因數據規模並不大故併發性比較好。 |
| 數據導入與時效性 | √ | 時效性非常好，一般與Kafka採用消息隊列的方式導入，時效性可達幾秒可見。 |
| 穩定性-與單點故障 | √ | 無單點故障，比較完善 |
| 排序性能 | √ | 預計算的方式，排序結果預先算好，性能比較好 |
| 用戶接口 | × | java接口，有獨立的API，需要寫類似mapreduce的程序 |
| 方便與周邊系統
的導入導出 |
× | 比較難，需要單獨獨立開發對接程序 |
| 數據存儲與恢復 | √ | 損壞的機器會自動摘除，進行會自動遷移，服務不中斷。
|
| 數據遷移 | √ | 數據遷移，擴容，容災均有完善的方案，Storm的擴容需要簡單的Rebanlance即可。 |
| 增加主備kafka | √ | 可以支持 |
| 預警與在線擴容 | √ | 有完完備的方案 |
| 系統監控 | √ | 有完完備的方案 |
3. 全文檢索系統（Solr、ElasticSearch）
| 數據規模-數據節點數 | × | 1.典型使用場景在千萬級別，如果給予較大內存，數據量可上億。
2.本身系統內存的限定，百億以上將會是巨大的挑戰-除非是512G內存的機器，弄個20~30臺左右，且是數據總量百億，而不是每天百億。 |
| 查詢與統計功能靈活性 | × | 1.爲搜索引擎的場景而生，分析功能較弱。只有最簡單的統計功能，無法滿足過車記錄複雜的統計分析需求，無法支撐複雜SQL，多表關聯，嵌套SQL甚至自定義函數等功能。
2.與周邊系統的集成麻煩，數據導入導出太麻煩，甚至不可行，第三方有SQL引擎插件，但均是簡單SQL，且由於Merger server是單節點的問題，很多SQL的查詢性能很低，不具備通用性。 3.無法與常見的支持jdbc標準的報表系統集成，定製開發代價較大。 4. 對於郵箱、手機號、車牌號碼、網址、IP地址、程序類名、含有字母與數字的組合之類的數據會匹配不完整，導致數據查不全，因分詞導致漏查以及缺失數據，對於模糊檢索有精確匹配要求的場景下，業務存在較大的風險。 5. 基於lucene的分詞來實現，但並不考慮單詞的匹配順序，也不保證匹配詞語的連續性，中間可以穿插其他單詞。 6.solr與es中不支持多列的group by與統計（原因爲無法交叉），所謂的實現是通過單列group by後 進行的笛卡爾及，按照每個單元格重新進行的查詢。 |
| 檢索與併發性能 | √ | 1.採用倒排索引，直接根據索引定位到相關記錄，而不需要採用全表暴力掃描的方式，檢索查詢性能特別高。
2.在千萬級別以下，並且給予較多內存的情況下，併發情況很好。 |
| 數據導入與時效性 | × | 1.支持實時導入，在千萬數據規模下導入性能較好。
2.數據過億後，生產系統實時導入經常會出現OOM，以及CPU負載太高的問題，故過億數據無法實時導入數據，一般過百億的系統均採用離線創建索引的方式，即數據時效性延遲一天。 3.沒有良好的合併控制策略，系統會發生階段性（幾分鐘）的負載極高的情況（索引合併），此時系統資源佔用特別高，前臺查詢響應速度極慢。 |
| 穩定性-與單點故障 | × | 1.數據規模一旦過百億，就會頻繁的出現OOM，節點調片的情況。
2.一旦調片後無法自動恢復服務，需要運維人員去重啓相關服務。 3.系統無過載保護，經常是一個人員做了一個複雜的查詢，導致集羣整體宕機，系統崩潰。 lucene在索引合併過程中，每進行一次commit都要進行一次全範圍的ord關係的重新映射，數據規模小的時候整個索引文件的映射還沒什麼，但是當數據量達到億級別，甚至百億級別後，這種映射關係會佔用超多的CPU、內存、硬盤資源，所以當數據量過億後，solr與Es在數據比較大的情況下，實時索引幾乎是不可能的，頻繁的ord關係映射，會讓整個系統不可用。 |
| 排序性能 | × | 採用暴力全表遍歷的方式排序，性能較差，經常因爲排序導致整個系統癱瘓。
採用lucene的Sort接口實現，本質是藉助docvalues的暴力掃描，如果數據量很大排序過程耗費非常多的內存與IO，並且排序耗時很高。 |
| 用戶接口 | × | 採用java API的方式，用戶學習成本高。
因不是通用的通訊協議，與其他大數據系統集成對接麻煩。 |
| 方便與周邊系統
的導入導出 |
× | 比較難，需要單獨獨立開發對接程序，
數據如若想導出到其他系統很難，超過百萬級別的導出基本是不可行的,沒有成型的高可用的導出方案。 全量數據導出基本是不可能的，更別談經過多表複雜運算後的導出了
|
| 數據存儲與恢復 | × | 索引存儲在本地硬盤，恢復難
1.磁盤讀寫沒有很好的控速機制，導入數據沒有良好的流量控制機制，無法控制流量，而生產系統，磁盤控速與流量控速是必須的，不能因爲業務高峯對系統造成較大的衝擊，導致磁盤都hang住或掛掉。 2.本地硬盤局部壞點，造成局部數據損壞對於lucene來說無法識別，但是對於索引來說哪怕是僅僅一個byte數據的讀異常，就會造成索引指針的錯亂，導致檢索結果數據丟失，甚至整個索引廢掉，但是solr與es不能及時的發現並修正這些錯誤。 3.數據存儲在本地磁盤，一旦本地將近20T的存儲盤損壞，需要從副本恢復後才能繼續服務，恢復時間太長。 |
| 數據遷移 | × | 1.如若誇機房搬遷機器，需要運維人員細心的進行索引1對1複製，搬遷方案往往要數星期，且非常容易出錯。
2.遷移過程中爲了保證數據的一致性，需要中斷服務或者中斷數據的實時導入，讓數據靜態化落地後不允許在變化後，才能進行遷移。 |
| 增加字段 | √ | 支持 |
| 增加主備kafka | × | 不支持，需要業務單獨開發導入api |
| 預警與在線擴容 | × | 分片數不可以隨意更改，如果要擴分片數，需要重建全部的歷史索引，也就是傳說的reindex，另外出現問題後無法自動恢復服務，需要運維人員去現場恢復服務 |
| 系統監控 | √ | es本身有收費版的監控系統 |
二、 最終方案-延雲YDB混合方案集成多個系統的優勢
針對上述典型場景，我們最終將多個系統整合，發揮系統的各自優勢，揚長避短，深度集成。延雲YDB作爲機動車緝查布控即席分析引擎，已經在10個以上城市的成功部署或測試，取得非常好的效果，有的甚至超過了客戶的預期。
YDB是一個基於Hadoop分佈式架構下的實時的、多維的、交互式的查詢、統計、分析引擎，具有萬億數據規模下的萬級維度秒級統計分析能力，並具備企業級的穩定可靠表現。
YDB是一個細粒度的索引，精確粒度的索引。數據即時導入，索引即時生成，通過索引高效定位到相關數據。YDB與Spark深度集成，Spark直接對YDB檢索結果集分析計算，同樣場景讓Spark性能加快百倍。
延雲推薦配置
延雲YDB高性能配置 (毫秒響應)
1.機器內存：128G
2.磁盤：企業級SSD，600~800G *12個磁盤
3.CPU：32線程（2顆,16核,32線程）
4.萬兆網卡
延雲YDB常規配置 （秒級響應）
1.機器內存：128G
2.磁盤：2T*12的磁盤
3.CPU：24線程（2顆,12核,24線程）
4.千兆網卡
指標比對
| 數據規模-數據節點數 | √ | 1.在騰訊我們做到了53臺機器 處理每天1800億的日增量，總量達幾萬億的數據規模（每條數據1kb左右）
2.在延雲推薦的普通機器 以給的示例數據預估，每個節點每天實時處理30~50億的數據比較適合。 處理的數據規模以及查詢響應速度，根據節點數線性增長。 |
| 查詢與統計功能靈活性 | √ | 1.支持hive SQL表達，支持所有的hive內置函數，可以嵌套SQL，可以多表關聯，也可以自定義UDF,UDAF
2. 內置的分詞類型會確保查詢準確度，不會出現漏查，內置的分詞類型，很好的解決了lucene默認分詞導致的查詢數據缺失的問題。另外YDB可以自定義拓展任意的luene分詞類型。如詞庫分詞，語義分詞，拼音分詞等。 3.能支持任意維度的多維查詢，多維統計，與分析。 |
| 檢索與併發性能 | √ | 常規情況下支持200~300的併發查詢，持續性壓測20天以上。
但是目前我的真實生產系統，確實沒有很大的併發，最大的併發系統也就是每5分鐘由系統觸發的100併發的檢索查詢，但是查詢完畢後會有5分鐘的休息時間。 |
| 數據導入與時效性 | √ | 數據從產生約1~2分鐘，系統內可查
每天千億增量，總量可達萬億 |
| 穩定性-與單點故障 | √ | 1.採用Spark Yarn的方式，系統宕機，硬件損壞，服務會自動遷移，數據不丟失。
2.有守護進程，一旦發現服務異常，自動重啓服務，不需要運維人員親自去機房重啓機器。 3.延雲YDB只需要部署在一臺機器上，由Yarn自動分發，不需要維護一堆機器的配置,改參數很方便。易於部署，易於擴容，易於數據遷移； 4.多數據副本保護，硬件不怕硬件損壞； 5.服務異常能自動檢測及恢復，減輕運維人員經常需要半夜起牀的痛苦； 系統不能存在任何單點故障，當某個服務器存在問題時不能影響線上業務。 數據過百億後，不能頻繁的OOM，也不能出現節點調片的情況。 系統出現異常後，可以自動偵探服務異常，並自動重啓恢復服務，不能每次調片都要運維 人員半夜去機房重啓。需要服務有自動遷移與恢復的特性，大幅減少運維人員駐場的工作量。 6.提供了導入與查詢的限流控制，也提供了過載保護控制，甚至在極端場景提供了有損查詢與有損服務 7.我們修正了大量的spark的bug，讓系統比開源系統更穩定。 http://blog.csdn.net/qq_33160722/article/details/60583286 |
| 排序性能 | √ | 採用延雲獨有的BLOCK SORT 技術，百億數據秒級排序。
技術原理請參考 http://blog.csdn.net/muyannian/article/details/60755273 |
| 用戶接口 | √ | 採用SQL的方式，用戶學習陳本低。
支持HIVE的JDBC接入（編程），可以命令行接入（定時任務），http方式接入。 Hive的JDBC協議，已經是大數據的事實標準。 與常規大數據系統可無縫對接（如hive,spark,kafka等），也提供了拓展接口。 海量數據導入導出靈活方便，也可與常見的支持jdbc的報表工具、SQL可視化工具集成。 |
| 方便與周邊系統
的導入導出 |
√ | 導出
支持原始數據的任意維度導出 可以全表，也可以通過過濾篩選局部導出 支持數據經過各種組合計算過濾後的導出 可以將YDB中的多個表與其他系統的多個表，進行組合篩選過濾計算後在導出 可以將多個數據從ydb的一張表導入到YDB的另外一張表 可以將YDB裏面的數據導出到別的系統裏面（如hive，hbase，數據庫等） 也可以將其他系統的數據導入到YDB裏面。 可以導出成文件，也可以從文件導入。
導入 採用SQL方式的批量導入，也支持kafka的流式導入 1.索引的設計實現，不會想solr與es那樣將數據全部加載到內種內存中進行映射，這無論是在導入還是在查詢過程中均大幅的減少了OOM的風險。 2.在內存與磁盤多個區域不同合併策略，在結合控速邏輯，讓導入佔用的性能控制在一定範圍之內，讓系統更平穩，儘量減少索引合併瞬間產生的幾分鐘佔據了大量的資源的情況，分散資源的佔用，讓前臺用戶的查詢更平穩。 3.結合了storm流式處理的優點，採用對接消息隊列（如kafka）的方式，數據導入kafka後大約1~2分鐘即可在ydb中查到。
|
| 數據存儲與恢復 | √ | 將數據存儲在HDFS之上
1.YDB基於HDFS做了磁盤與網絡做了讀寫控速邏輯。 2.磁盤局部壞點hdfs配有crc32校驗，有壞點會立即發現，並不影響服務，會自動切換到沒有壞點的數據繼續讀取。 3.本地磁盤損壞，HDFS自動恢復數據，不會中斷讀寫，不會有服務中斷。 |
| 數據遷移 | √ | 1.hdfs通過balance自動遷移數據。
2.可以控制遷移過程中的帶寬流量。 2.遷移過程中不中斷服務，hdfs擴容與移除機器也對服務沒影響。 |
| 增加主備kafka | √ | 支持，切換過程不中斷服務 |
| 定時聚集 | √ | 兼容了hive本身的特性，適合大量數據後臺定時計算。
內置支持直接將ydb的計算結果導出到oracle,不需要在單獨寫etl程序。 |
| 實時聚集 | √ | 兼容了本身索引的特性，適合掃描小範圍的數據。
聚焦性能跟命中的記錄條數以及機器磁盤數有很大關係。如果是100量車從3000億條原始數據數據中篩選1.5億條記錄進行統計彙總，6臺集羣sata盤的磁盤的iops達不到這個性能，需要ssd磁盤纔行。 |
| 預警與在線擴容 | √ | 1.數據存儲在HDFS之上，不存儲在本地硬盤，擴容，遷移，容災與Hadoop一樣，穩定可靠。
2.對於kafka消費延遲，節點宕掉，均有預警機制，可以在moniter頁面看到。 |
| 系統監控 | √ | 1.有完備的指標監控系統，可以實時YDB監控集羣的運行狀態。
2.基於有存儲的預警系統，出現問題後會發出通知報警。 3.如果機器異常頁面也會顯示出warning報警 4.可以自定義報警邏輯 |
常見SQL 寫法示例
5.行車軌跡查詢/重點車輛分析
| 描述 | 一般根據一個車牌號，去搜尋特定車輛的行車軌跡。在XX部門的系統裏用於追蹤嫌犯的犯罪過程，或者對重點車輛進行分析。 |
| SQL | /*ydb.pushdown(‘->’)*/
select hphm,kkbh,jgsj,jgsk,quyu from ydb_jiaotong where hphm=”雲NEW336″ order by jgsj desc limit 10 /*(‘<-‘)pushdown.ydb*/ |
6.同行車輛分析
| 描述 | 可以根據目標車輛過車的前後時間，經過的地點，找到目標車輛的同行車輛。該功能一般用於查詢“盯梢”，“跟蹤”車輛。如果遇到綁架等案件，可以根據被綁架人的車輛的過車記錄，查詢出“盯梢”車輛，從而爲案件的偵破提供更多的線索。 |
| SQL | select tmp.hphm,count(*) as rows,size(collect_set(tmp.kkbh)) as dist_kkbh,concat_ws(‘#’, sort_array(collect_set(concat_ws(‘,’,tmp.jgsj,tmp.kkbh)))) as detail
from ( /*ydb.pushdown(‘->’)*/ select hphm,jgsj,kkbh from ydb_oribit where ydbpartion = ‘20160619’ and ( (jgsj like ‘([201604290000 to 201604290200] )’ and kkbh=’10000000′) or ( jgsj like ‘([201604290001 to 201604290301] )’ and kkbh=’10000001′) or (jgsj like ‘([201604290002 to 201604290202] )’ and kkbh=’10000002′) ) /*(‘<-‘)pushdown.ydb*/ ) tmp group by tmp.hphm order by dist_kkbh desc |
7.區域碰撞分析
| 描述 | 根據不同時間段的不同卡口（路段），找出在這些卡口上同時出現的車輛。該功能一般用於破獲連環作案的案件，追蹤逃犯，如部分城市最近經常在出現搶劫的行爲，就可以根據多個搶劫的時間與地點，進行碰撞分析，如果多個搶劫的地點周圍均出現該車輛，那麼該車爲嫌疑車輛的可能性就非常大，從而更有助於連環案件的偵破。 |
| SQL | select
tmp.hphm, count(*) as rows, size(collect_set(tmp.quyu)) as dist_quyu, concat_ws(‘#’, sort_array(collect_set(concat_ws(‘,’,tmp.jgsj,tmp.quyu)))) as detail from ( /*ydb.pushdown(‘->’)*/ select hphm,jgsj,quyu from ydb_jiaotong where ( (jgsj like ‘([201604111454 TO 201604131554] )’ and quyu=’安義路閣馨’) or (jgsj like ‘([201609041043 TO 201609041050] )’ and quyu=’恆仁路太陽星城’) or (jgsj like ‘([201609040909 TO 201609040914] )’ and quyu=’環江路大有恬園’ /*(‘<-‘)pushdown.ydb*/ ) tmp group by tmp.hphm order by dist_quyu desc limit 10 |
8.陌生車輛分析
| 描述 | 用於搜尋某一地區，在案發期間出現過，並且在這之前沒有出現或出現次數較少的車輛。陌生車輛對於小區盜竊，搶劫等案件的偵破可以提供較多的偵破線索。
給出一個時間範圍【A TO B】,搜尋出一個區域內的所有車輛. 如果在這個時間範圍出現過，並且在之前的 C天內出現次數少於N次的車輛
|
| SQL | select * from (
select tmp.hphm, count(*) as rows, max(tmp.jgsk) as max_jgsj, size(collect_set(tmp.jgsk)) as dist_jgsj, size(collect_set(case when ((tmp.jgsk>=’20161201153315′ and tmp.jgsk<=’20161202153315′) or (tmp.jgsk>=’20161203153315′ and tmp.jgsk<=’20161204153315′)) then 0 else tmp.jgsk end )) as dist_before, concat_ws(‘#’, sort_array(collect_set(concat_ws(‘,’,tmp.jgsk,tmp.kkbh)))) as detail from ( /*ydb.pushdown(‘->’)*/ select hphm,jgsk,kkbh from t_kk_clxx where jgsk like ‘([20161201153315 TO 20161204153315] )’ and kkbh IN(‘320600170000089780′,’320600170000000239′,’320600170000000016′,’320600170000000018′,’320600170000002278′,’320600170000092977′,’320600170000092097′,’320600170000092117’) /*(‘<-‘)pushdown.ydb*/ ) tmp group by tmp.hphm ) tmp2 where tmp2.dist_before<=’1’ order by tmp2.dist_jgsj asc limit 10
|
9.晝伏夜出、落腳點分析
| 描述 | 可以針對某一車輛，查詢其出行規律，分析其日常在每個時段的出行次數，經常出路的地點。通過分析車輛的出行規律，從而可以識別某一量車是否出現異常的出行行爲，有助於對案件事發地點出現的車輛進行一起集體掃描，如果有車輛的該次出行行爲與平日的出行行爲不一致，那麼該車極有可能就是嫌疑車輛。 |
| SQL | select
tmp.jgsk, count(*) as rows, size(collect_set(tmp.quyu)) as dist_quyu, concat_ws(‘#’, sort_array(collect_set(concat_ws(‘,’,tmp.jgsj,tmp.quyu)))) as detail from ( /*ydb.pushdown(‘->’)*/ select jgsk,jgsj,quyu from ydb_jiaotong where hphm=’黑NET458′ /*(‘<-‘)pushdown.ydb*/ ) tmp group by tmp.jgsk order by dist_quyu desc limit 10 |
10.嫌疑車牌模糊搜索與定位
| 描述 | 因攝像頭因夜晚或者天氣等原因拍攝到的車牌識別不清，或者交通孽事車輛逃逸，目擊證人只記住了車牌號的一部分，但知道車的顏色，是什麼車等信息。但是事發路段可能會有多個其他交通探頭能識別出該車牌。故可以根據車牌號碼模糊檢索，在結合車輛顏色，時間，車的型號等綜合匹配出最有可能的車牌。從而定位到嫌疑車輛。
注意下面的hphm_search爲charlike類型，可以進行號牌號碼的模糊檢索 |
| SQL | select tmp.hphm,count(*) as rows,size(collect_set(tmp.kkbh)) as dist_kkbh from (
/*ydb.pushdown(‘->’)*/ select hphm,kkbh from ydb_jiaotong where hphm_search=’NEW33′ /*(‘<-‘)pushdown.ydb*/ ) tmp group by tmp.hphm order by dist_kkbh desc limit 10 |