摘要：?2017云棲大會HBase專場，大搜車高級數據架構師申玉寶帶來HBase在大搜車金融業務中的應用實踐。本文主要從數據大屏開始談起，進而分享了GPS風控實踐，包括架構、聚集分析等，最后還分享了流式數據統計，包括數據流、數據合流和服務監控等。

2017云棲大會HBase專場，大搜車高級數據架構師申玉寶帶來HBase在大搜車金融業務中的應用實踐。本文主要從數據大屏開始談起，進而分享了GPS風控實踐，包括架構、聚集分析等，最后還分享了流式數據統計，包括數據流、數據合流和服務監控等。
以下是精彩內容整理：

數據大屏實踐

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

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

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

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

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

GPS風控實踐

?

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

業務架構

?

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

聚集分析

?

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

流式數據統計

?

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

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

?

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

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

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

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

?

---

交流

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

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

?

?

?

? ?釘釘HBase技術社區群

轉載于:https://www.cnblogs.com/hbase-community/p/8727740.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。