中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導(dǎo)語：公司各個業(yè)務(wù)部門之間都會存在一定的數(shù)據(jù)交互行為，此時，大量不同類型的數(shù)據(jù)可能留存，如何更好地做好數(shù)據(jù)存儲、數(shù)據(jù)交互，便成為重中之重。本篇文章里，作者就跨部門間的數(shù)據(jù)交互體系搭建做了總結(jié)，一起來看一下。

數(shù)據(jù)的存儲形式，在各個部門的系統(tǒng)留存邏輯都是不完全一致的，甚至留存的口徑都存在問題。

以整個互聯(lián)網(wǎng)消費金融的系統(tǒng)為例，前端訂單系統(tǒng)和業(yè)務(wù)風控系統(tǒng)記錄的是用戶申請貸款到實際發(fā)放貸款為止，用戶的所有還款行為、催收員的跟進行為對用戶產(chǎn)生的影響放在貸后跟進系統(tǒng)，最后經(jīng)歷了一整個資產(chǎn)回收周期到末端的逾期資產(chǎn)處置的系統(tǒng)上面去對用戶進行更進一步的操作。這部分所有的數(shù)據(jù)，在一定程度上可以構(gòu)成用戶在互聯(lián)網(wǎng)消費金融方面的整個用戶流程行為。

用戶在消金公司的行為線可以簡單歸納為：

在用戶的實際行為下，會有大量不同類型的數(shù)據(jù)以各種類型留下來在各個系統(tǒng)中，不同類型的數(shù)據(jù)和用戶行為都會被留存下來，這一部數(shù)據(jù)需要以統(tǒng)一的方式和邏輯被留存在系統(tǒng)中。

這就涉及了公司各個業(yè)務(wù)部門之間數(shù)據(jù)中臺的建設(shè)，如果沒有放大到所謂數(shù)據(jù)中臺的建設(shè)上，也仍然涉及了大量跨部門之間業(yè)務(wù)數(shù)據(jù)流轉(zhuǎn)交互的過程。

一、數(shù)據(jù)交互口徑

對大部分公司來說，主要是業(yè)務(wù)部門產(chǎn)生數(shù)據(jù)，由數(shù)倉、BI、大數(shù)據(jù)等等部門去做數(shù)據(jù)留存、交互，除了在業(yè)務(wù)銜接上會各個相關(guān)部門會有接觸外，還有同類型的業(yè)務(wù)部門會產(chǎn)生數(shù)據(jù)上的交集。

像信貸商城部門、風控部門有大量業(yè)務(wù)銜接節(jié)點，同樣作為逾期資產(chǎn)處理的催收部門和用更有利手段的進行訴訟催回欠款的法訴部門互相之間都會有大量業(yè)務(wù)交互的部分，這都需要各個系統(tǒng)在交互邏輯上是保持一致的。

以互聯(lián)網(wǎng)金融風控系統(tǒng)為例，因為“互聯(lián)網(wǎng)”和“消費金融”這兩者的特殊性，導(dǎo)致了用戶實際在線上操作申請貸款的流程需要盡可能快速，但是交易的金額量又較高，前端業(yè)務(wù)風控系統(tǒng)的計算邏輯就需要盡可能減少多的握手次數(shù)，也需要風控引擎讀取的相關(guān)字段盡可能簡單，業(yè)務(wù)邏輯更清晰。

但這樣快速響應(yīng)的系統(tǒng)在某種程度上就在本地服務(wù)器上留存大量數(shù)據(jù)，進行較為復(fù)雜的查詢工作，碰上免息、折扣的活動，大量用戶參與前端風控評測的時候更容易產(chǎn)生風控系統(tǒng)崩潰的情況（這也就是為什么大量企業(yè)在自己的頁面前端加入驗證碼防止前端頁面被刷）。

傳統(tǒng)金融業(yè)的訂單數(shù)少，訂單金額高，借貸期限長，客群資質(zhì)好，風控預(yù)算高；而科技金融公司實施的互聯(lián)網(wǎng)金融業(yè)務(wù)所面臨的業(yè)務(wù)場景則是訂單數(shù)多，訂單金額低，借貸期限短，客群資質(zhì)差，風控預(yù)算低。

這就是為什么所有的互聯(lián)網(wǎng)金融消費公司都需要將風控系統(tǒng)和公司其他所有系統(tǒng)的數(shù)據(jù)交互口徑調(diào)整一致。

數(shù)據(jù)口徑的統(tǒng)一是什樣的？舉個簡單的例子，以互聯(lián)網(wǎng)消金公司的兩套系統(tǒng)為例，訂單系統(tǒng)、貸后催收跟進系統(tǒng)兩套系統(tǒng)中，用戶這個個體的所有行為，都需要統(tǒng)一：

1. A用戶在訂單系統(tǒng)中的按訂單的維度記錄數(shù)據(jù)：A用戶于XX年XX月XX日XX時XX分XX秒借款了3000.00元，訂單到期日為XX年XX月XX日XX時XX分XX秒；
2. A用戶在貸后催收跟進系統(tǒng)按催收處置流程的維度跟進收集的記錄：A用戶于XX年XX月XX日XX分XX秒開始逾期，欠款本金2000.00元，欠款罰息100.00元，逾期天數(shù)XX天，催收人員于XX年XX月XX日接入催收，用戶于XX年XX月XX日還款。

從上面的事實記錄模式看，兩者時間實際只有時間記錄顆粒度的差距，線上訂單系統(tǒng)的記錄能正常精準到秒，但實際以線下行為（且行為的記錄主體是催收員，和線上的行為記錄主體用戶完全是兩套不同的記錄角度），這種顆粒度差距看起來差距不大，但是在實際快速響應(yīng)的風控系統(tǒng)中，會產(chǎn)生很大的影響。

簡單來說，用戶在經(jīng)過催收員溝通之后在一點時間內(nèi)回款，這個時間差從日期來看是天數(shù)的差距，而不是小時、分鐘的差距，這個回款天數(shù)差能夠用于實際評估用戶的還款能力。

舉個例子，用戶在接到催收電話后馬上還款，那可以根據(jù)模型估計用戶的還款行為是代表其有較強的還款能力的，這種有借款行為且有高還款能力的用戶在風控上就可以相對提高用戶的額度。

同樣的，用戶如果都在催收員跟進當天內(nèi)進行還款，又可能代表了不同行為特征的用戶。如果均按“0天”進行計算，就需要從別的維度補充這部分數(shù)據(jù)，可能是催收員進行跟進的文本維度，這就需要NLP介入進行判斷。

某種程度上來說，更復(fù)雜的模型讓各個系統(tǒng)之間的握手次數(shù)和交互流程更為復(fù)雜，這和實際業(yè)務(wù)上的追求就相悖了。

所以，在各個系統(tǒng)的交互上，更需要將所有的交互結(jié)構(gòu)、尤其是數(shù)據(jù)顆粒度，數(shù)據(jù)產(chǎn)生的邏輯進行統(tǒng)一。

這就需要從公司層面上進行業(yè)務(wù)線梳理，明確哪一條是核心業(yè)務(wù)線，根據(jù)核心業(yè)務(wù)線的用戶流程去進行各個系統(tǒng)之間的改造。不然就像我剛剛說的，不同的系統(tǒng)之間有不同的服務(wù)目標，這是好事，但過多的服務(wù)目標會導(dǎo)致底層數(shù)據(jù)的存儲邏輯不同意，在高并發(fā)的核心業(yè)務(wù)部門會導(dǎo)致大量數(shù)據(jù)被無效拉取計算，這就不利于核心業(yè)務(wù)線的增長。

二、數(shù)據(jù)交互時效

除了數(shù)據(jù)交互口徑可能會產(chǎn)生不一致沖突的情況，數(shù)據(jù)交互時效也會對不同業(yè)務(wù)系統(tǒng)產(chǎn)生差異。

幾乎大部分涉及線上業(yè)務(wù)的公司都會有數(shù)倉和大數(shù)據(jù)這兩個部門。從公司業(yè)務(wù)反饋來說，一般數(shù)倉是歷史數(shù)據(jù)的留存處置，大數(shù)據(jù)用于線上實時業(yè)務(wù)數(shù)據(jù)的更新計算。

從某種意義上，傳統(tǒng)數(shù)倉的模式也更容易按統(tǒng)一的業(yè)務(wù)規(guī)范，按數(shù)據(jù)倉庫工具箱：維度建模（第二版）中Kimball說：“我們花了二十年的時間往數(shù)據(jù)庫中加入數(shù)據(jù)，現(xiàn)在該是拿出來使用的時候了?！睌?shù)倉對公司整體業(yè)務(wù)的發(fā)展實際上是起到底層數(shù)據(jù)夯實奠基的作用。

大數(shù)據(jù)部門的作用則更多體現(xiàn)在實時數(shù)據(jù)的生產(chǎn)，由于傳統(tǒng)數(shù)倉本身依托于大數(shù)據(jù)量級的關(guān)系型數(shù)據(jù)庫建立，很難大量、同時提取數(shù)倉的數(shù)據(jù)去做到即時性的分析，而從用戶的維度則更希望看到實時的結(jié)果（這種需求在涉及供需、金額變化的業(yè)務(wù)場景會更為突出，像12306的實時車票計算系統(tǒng)），突出的特點就是“及時性”、“快”，高速響應(yīng)用戶的所有定制化需求，用戶的這種需求在互聯(lián)網(wǎng)消金公司顯得尤為關(guān)鍵。

尤其是當用戶收到我方催收作業(yè)下還款的場景下，會更希望在APP前端展示的欠款產(chǎn)生變化，這種及時性的需求就會要求系統(tǒng)能直接調(diào)用大數(shù)據(jù)的接口完成實時賬單的計算。

這時候就需要考慮如何將這部分數(shù)按統(tǒng)一的規(guī)則落庫到數(shù)倉中，去記錄用戶各個事件節(jié)點收到影響的行為變化，就需要數(shù)倉留存的數(shù)據(jù)是按業(yè)務(wù)流轉(zhuǎn)節(jié)點去進行記錄的，這些互相之間數(shù)據(jù)的交換。

如果在事件隨時發(fā)生就隨時交換，會極大影響系統(tǒng)的性能（這種大量判斷的邏輯會極大影響交互邏輯，如果發(fā)起交互超時了未報錯，會導(dǎo)致實際收集的數(shù)據(jù)不全等情況），這種情況并不只發(fā)生在某個系統(tǒng)中，而會出現(xiàn)在每個系統(tǒng)和數(shù)倉、大數(shù)據(jù)的交互中，而一個系統(tǒng)尚且會碰上數(shù)據(jù)交互時間、事件維度不統(tǒng)一的情況，多個系統(tǒng)想要完成兩者邏輯的匯總，更是難上加難。

而每個系統(tǒng)所能拉取數(shù)據(jù)的時間點也不盡相同，這是困擾所有發(fā)展中公司，尤其是線上線下業(yè)務(wù)同時發(fā)展的公司，這種不同業(yè)務(wù)系統(tǒng)上的數(shù)據(jù)交互時間，也是需要按最核心的業(yè)務(wù)線進行判定，通過核心業(yè)務(wù)線的業(yè)務(wù)邏輯，完成各個系統(tǒng)數(shù)據(jù)交互時間邏輯的改造。

三、最后

以上兩點在互聯(lián)網(wǎng)消金公司中都會發(fā)生，怎么做到兩者的統(tǒng)一，還是需要從整體業(yè)務(wù)架構(gòu)的改善中去調(diào)配。

雖然核心業(yè)務(wù)線是居最高位置的，但它不一定是最能代表公司營收的業(yè)務(wù)線，就像在大部分消金公司中，還是以風控能力、用戶評分卡作為核心業(yè)務(wù)能力，但根據(jù)每個消金公司的業(yè)務(wù)形態(tài)不一樣，業(yè)務(wù)發(fā)展周期不一樣，公司的核心業(yè)務(wù)線就行發(fā)生改變，這就需要更加穩(wěn)固的集中化數(shù)據(jù)服務(wù)平臺對整體業(yè)務(wù)發(fā)展進行評估，確定核心業(yè)務(wù)的發(fā)展和所有業(yè)務(wù)線的粘合方式。

當然，作為一個偏業(yè)務(wù)后端的從業(yè)人員，也是希望后端的數(shù)據(jù)能被更多人關(guān)注，之后看時間談一談互聯(lián)網(wǎng)消金后端風控的逾期資產(chǎn)處置對前端業(yè)務(wù)的作用吧。

作者：Logan_RRRC，公眾號： Logan的運營學(xué)習(xí)日記

本文由 @Logan_RRRC 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于 CC0 協(xié)議