摘要：?2017云棲大會HBase專場，大搜車高級數(shù)據(jù)架構(gòu)師申玉寶帶來HBase在大搜車金融業(yè)務(wù)中的應(yīng)用實踐。本文主要從數(shù)據(jù)大屏開始談起，進而分享了GPS風(fēng)控實踐，包括架構(gòu)、聚集分析等，最后還分享了流式數(shù)據(jù)統(tǒng)計，包括數(shù)據(jù)流、數(shù)據(jù)合流和服務(wù)監(jiān)控等。

2017云棲大會HBase專場，大搜車高級數(shù)據(jù)架構(gòu)師申玉寶帶來HBase在大搜車金融業(yè)務(wù)中的應(yīng)用實踐。本文主要從數(shù)據(jù)大屏開始談起，進而分享了GPS風(fēng)控實踐，包括架構(gòu)、聚集分析等，最后還分享了流式數(shù)據(jù)統(tǒng)計，包括數(shù)據(jù)流、數(shù)據(jù)合流和服務(wù)監(jiān)控等。
以下是精彩內(nèi)容整理：

數(shù)據(jù)大屏實踐

最近幾年二手車業(yè)務(wù)發(fā)展非常迅猛，大搜車一直做B端的業(yè)務(wù)，我們在B端里面4S店的市場占有率已經(jīng)達到90%以上。今年年初我們覺得時機成熟了，我們就做了彈個車，它是比較典型的汽車金融。無論是車商業(yè)務(wù)，還是金融業(yè)務(wù)，都對我們數(shù)據(jù)采集、數(shù)據(jù)整理、數(shù)據(jù)使用提出了非常多的挑戰(zhàn)。而HBase性能比較穩(wěn)定，也可以水平拓展，很好地支撐了我們的業(yè)務(wù)。

圖為我們其中一個數(shù)據(jù)大屏，它是上海地區(qū)彈個車業(yè)務(wù)一個小時以內(nèi)的行駛軌跡，看起來還是比較震撼的。該大屏還有一個配置的頁面，用戶可以選擇時間、城市，業(yè)務(wù)同學(xué)可以自己配備報表，方便他們對外做一些商務(wù)事務(wù)。

我們看一下報表是如何實現(xiàn)的。這個報表的數(shù)據(jù)源來自車載GPS設(shè)備，GPS設(shè)備會定時上報一些數(shù)據(jù)，包括精度、緯度、點火狀態(tài)的數(shù)據(jù)，這些數(shù)據(jù)會先經(jīng)過GPS上報，會做狀態(tài)的管理、里程，之后生成想要的報表，數(shù)據(jù)到達終點。這個數(shù)據(jù)會通過數(shù)據(jù)網(wǎng)關(guān)，數(shù)據(jù)網(wǎng)關(guān)是對外提供產(chǎn)品都要經(jīng)過的地方，并且會進行系統(tǒng)跟蹤等。車載設(shè)備上傳各種的基礎(chǔ)數(shù)據(jù)會存到GPS。針對這個場景，我們根據(jù)時間、城市來查數(shù)據(jù)，所以我們要對報表單獨建立一個索引。因為我們在查數(shù)據(jù)的時候，這個場景只需要精度和緯度，這樣在查數(shù)據(jù)的時候直接在索引中就可以完成所有數(shù)據(jù)查詢，不用再回主表，大大減少了產(chǎn)品的耗時。

我們在報表的應(yīng)用層也做了一些優(yōu)化，大屏里面是該地區(qū)所有車輛軌跡，這個數(shù)據(jù)量是非常巨大的，如果直接瀏覽就會卡死，所以我們首先做了分片。剛開始只查詢一個小時的少量數(shù)據(jù)，這個數(shù)據(jù)拿到以后開始渲染，數(shù)據(jù)請求下一時間段的數(shù)據(jù)，前端渲染是不停的，后端數(shù)據(jù)也一直往上堆積，所以我們在打開頁面的時候可以立即開始整個頁面的展示。另外，因為數(shù)據(jù)傳輸非常頻繁，使用Websocket減少建立 HTTP 請求耗時。

剛才的大屏是離線大屏，而現(xiàn)實中實時業(yè)務(wù)大屏非常常見，這是彈個車實時成交數(shù)據(jù)大屏。大屏數(shù)據(jù)來自我們的業(yè)務(wù)埋點日志，大屏當(dāng)中也會用到基礎(chǔ)的緯度數(shù)據(jù)，我們直接拉到了MySQL，我們內(nèi)部的計算框架會根據(jù)MQ進行數(shù)據(jù)的處理，組裝成我們需要的數(shù)據(jù)，放到終點Phoenix當(dāng)中。

GPS風(fēng)控實踐

?

對汽車金融來說風(fēng)控是生命線，如果風(fēng)控搞不好分分鐘就會破產(chǎn)。我們有一個軌跡監(jiān)控大屏，通過時間和車輛可以察看車輛在一段時間內(nèi)的型式軌跡，它的速度、地理位置，還有后臺可以設(shè)置一些風(fēng)險區(qū)域，比如澳門賭場等正常用戶應(yīng)該不會去的地方，這些地方出沒的會有一些貸款風(fēng)險。還有風(fēng)控模型，GPS里面會把各種數(shù)據(jù)統(tǒng)計為模型特征，再交給模型，最后由風(fēng)控引擎針對這些線上數(shù)據(jù)判定有沒有特征，發(fā)出報警。

業(yè)務(wù)架構(gòu)

?

最早設(shè)備是來自廠商上報的，后來因為對接的廠商比較多，發(fā)現(xiàn)了一些故障。我們上報到網(wǎng)關(guān)，包括設(shè)備注冊、狀態(tài)維護、里程糾偏，設(shè)計運營環(huán)境非常復(fù)雜，有可能這輛車沒有電了，里面存儲的數(shù)據(jù)沒有了，也有可能跑到非常偏遠的地方，沒有辦法上報數(shù)據(jù)，還有一些上報的里程非常奇怪，本來是兩萬多，突然變成一萬，表現(xiàn)在數(shù)據(jù)上可能會是非常詭異的點，。針對這部分，我們做了一些清洗，比如說偏移，我們會根據(jù)前后一些點的關(guān)系做一些數(shù)據(jù)的過濾。還有里程糾偏，我們對時間做了一些分片，每分鐘都會有一個點，我們會統(tǒng)計這分鐘結(jié)束時間減去起始，計算出真正的里程，可以對這塊數(shù)據(jù)作出處理，對一天的影響就非常小。我們在這里花了大量的精力，一大半時間都在清洗數(shù)據(jù)。
接下來數(shù)據(jù)通過MQ到HBase，實時軌跡、電子圍欄、停留點分析、聚焦分析，這些數(shù)據(jù)會和材料驗證一塊提供給我們的貸后運維同學(xué)來判斷風(fēng)險。我們發(fā)現(xiàn)很多騙貸的并不是個人，而是一些機構(gòu)，有些村子都是騙貸的團伙，有些是負責(zé)偽造材料，有些是負責(zé)申請貸款，我們針對這些場景，把每個車的具體情況分析出來，因為正常是面向C端用戶，不應(yīng)該大量車聚焦在一個地方。最后這些數(shù)據(jù)進入到預(yù)警后臺。

聚集分析

?

使用GeoHash先對地球進行二維平面化，把地球分成好多個區(qū)域，對每一個區(qū)域再分成32個區(qū)域，不斷地細分，讓一個區(qū)域不斷地精確。Base32編碼字符串,每個字符由5bit 組成。將每輛車的停留點算出來，再把停留點算出GeoHash值，按照這些區(qū)域聚合好選擇聚合的點，算出每一個點到底有多少輛車，最后形成一個特征，生成模型。
數(shù)據(jù)存儲部分，原始軌跡支持按設(shè)備、時間維度查詢詳細軌跡，查聚集點按區(qū)域、時間維度查詢聚集數(shù)據(jù)。

流式數(shù)據(jù)統(tǒng)計

?

有些車輛列表大家看到的并不是動態(tài)的，會根據(jù)流量數(shù)量、地理位置來決定一個智能點的排序，這就需要很多特征、流式計算的場景。全國實時車交數(shù)據(jù)和報表，產(chǎn)品經(jīng)理都比較人性化，所有數(shù)據(jù)都想立刻在報表里面更新，所以這些也是我們主要的場景。
這些業(yè)務(wù)特點：

• 實時數(shù)據(jù)間隔非常短，我們會要求10秒或者5秒的時間窗口就要更新過來；
• 數(shù)據(jù)量比較大，我們遇到了一些百萬兆、億兆的；
• 這些場景還有并發(fā)要求，畢竟是線上業(yè)務(wù)，我們是一個B端業(yè)務(wù)，所以對內(nèi)部要求還沒有太高，100QPS就可以滿足我們這個階段的要求；
• 業(yè)務(wù)變化非常快，如果一個需求真的做一個月，做完了以后規(guī)則就變了，所以查詢緯度很多、變化很大，針對這些我們會細分一些性能，然后提高開放的速度。
  

?

這是數(shù)據(jù)流，最多的數(shù)據(jù)還是來自RDS，把數(shù)據(jù)庫的各種數(shù)據(jù)變更轉(zhuǎn)化成MQ消息，再加上以前還有很多埋點消息都會統(tǒng)一到MQ。所有數(shù)據(jù)會在我們計算框架里面聚合起來，按照我們的業(yè)務(wù)場景把它放在Phoenix里面，先放到明細數(shù)據(jù)。我們針對每個場景單獨聚合好，可以直接查詢。還有一些場景計算量很大，會有一些統(tǒng)計數(shù)據(jù)，以此來支撐我們的線上業(yè)務(wù)。A、B、C業(yè)務(wù)通過數(shù)據(jù)網(wǎng)關(guān)來訪問數(shù)據(jù)。

數(shù)據(jù)合流是我們現(xiàn)在遇到的比較大的問題，有一個定單表，里面有金額、品牌等等，需要把所有數(shù)據(jù)合并到一起提供服務(wù)，對流式處理來說這個問題非常棘手，因為數(shù)據(jù)是流式到達的，而且到達是無序的。我們也做了一些處理，對每一個處理流里面立一個表為主表，每次數(shù)據(jù)到達的時候會有一個監(jiān)測模塊，看是否符合合流條件，會從庫里面檢查數(shù)據(jù)是否真的到達了，按照業(yè)務(wù)規(guī)則組合數(shù)據(jù)。這里也要做優(yōu)化，并不是直接查，是要經(jīng)過數(shù)據(jù)緩存。

性能測試方面我們找最低配的集群，Master（2C4G）+CORE（4C8G）×2，數(shù)據(jù)量：—100Million，這對我們場景來說已經(jīng)綽綽有余，再加上Phoenix性能的拓展非常方便。這些性能測試其實跟性能條件關(guān)系非常大，這只是我們內(nèi)部的測試，更標(biāo)準的數(shù)據(jù)還要參考官方的數(shù)據(jù)。

服務(wù)監(jiān)控上，流式和離線不太一樣，流式數(shù)據(jù)一天24小時在線，所以它的穩(wěn)定性非常重要，不能跑著跑著就掛了。阿里云后臺本身的監(jiān)控可以看到一些機器的信息。另外，我們內(nèi)部開發(fā)了一套業(yè)務(wù)監(jiān)控系統(tǒng)，我們所有請求都是通過數(shù)據(jù)網(wǎng)關(guān)，數(shù)據(jù)網(wǎng)關(guān)的重要功能就是整個服務(wù)的監(jiān)控，它每次訪問都會記一個日志，日志里面有訪問的數(shù)量、訪問的時間，按表來查，這樣對我們查詢問題幫助非常大。另外，我們業(yè)務(wù)監(jiān)控系統(tǒng)也有移動版，以前出什么問題在公交車上都得拿出電腦，現(xiàn)在直接在移動端里查，比較方便。 轉(zhuǎn)自：https://yq.aliyun.com/articles/346456#

?

---

交流

如果大家對HBase有興趣，致力于使用HBase解決實際的問題，歡迎加入Hbase技術(shù)社區(qū)群交流：

微信HBase技術(shù)社區(qū)群，假如微信群加不了，可以加秘書微信: SH_425?,然后邀請您。

?

?

?

? ?釘釘HBase技術(shù)社區(qū)群

轉(zhuǎn)載于:https://www.cnblogs.com/hbase-community/p/8727740.html

總結(jié)

以上是生活随笔為你收集整理的HBase在大搜车金融业务中的应用实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。