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