378 阿裏雲技術社區[雲棲]

貸款、天使投資(風控助手)業務數據庫設計 - 阿裏雲RDS PostgreSQL, HybridDB for PostgreSQL最佳實踐

標簽

PostgreSQL , HybridDB for PostgreSQL , 小微貸款 , 金融風控 , 企業圖譜 , 圖式搜索 , 輿情分析 , 自動貸款 , 貸款審查 , 審查神器

背景

貸款是銀行的主營業務之一，但是並不是隻有銀行能提供貸款，實際上資金雄厚的公司都有能力提供貸款（比如保險行業、資源壟斷型企業等）。

除了放貸，我們常說的天使投資、A輪B輪啥的，也是類似的場景，憑什麼投你，背後如何決策也需要決策係統的支撐。

與貸款相反的是吸金類業務，比如我們現在發現越來越多的理財產品、股市、甚至是遊戲充值，隻要是讓你存錢，把你的錢留住，而且你還不舍得吧錢取出來的業務，都是吸金類業務。

所以，一些本來就資金雄厚，或者是靠吸金類業務起來的公司，隻要吸到足夠的金之後，就有放貸款的能力。

放貸本身是一件體力活，來申請貸款的人或企業魚龍混雜。什麼樣的人，什麼樣的企業能獲得貸款，需要經過層層審查。審查需謹慎，否則就容易成為放貸公司的爛賬。

本文涉及的項目和放貸、審查、風控、輿情係統有關。

一、需求分析

展示企業的圖譜信息，例如股權結構、輿情事件、管理層、知識產權，經營狀況等。方便審查員查看。

數據的來源，例如爬蟲得到的信息、來自合作夥伴（例如招聘網站、稅務）的信息等，組成了企業相關的信息網絡。

類比社交業務

這類數據和互聯網的社交類業務的數據非常類似，A企業投資了B企業（類似微博的LIKE），A企業發布了財報（類似發微博），A企業獲得了某個專利。。。。

相關的性能指標：

1、用戶數量級1億（相當於1億企業名錄），好友數量級1~1萬（相當於平均每個企業與之相關聯的企業1到1萬家），單個對象的Like數量1-100萬（相當於單個事件被關注的平均次數1到100萬次）。

1.1. 關注微博（文章）

17.7萬/s，預計可以優化到30萬。

1.2. 查詢文章被誰like？

101.6萬/s

1.3. 查詢文章被like了多少次？

104.1萬/s

1.4. 查詢LIKE某文章的用戶中，哪些是我的好友？

64.8萬/s

1.5. 機器:

（10W左右價位的X86，12*8TB SATA盤，1塊SSD作為BCACHE）

案例詳見：

《三體高可用PCC大賽 - facebook\微博 like場景 - 數據庫設計與性能壓測》

《facebook linkbench 測試PostgreSQL社交關係圖譜場景性能》

類比圖式搜索業務

企業圖譜係統與互聯網社交類業務截然不同的地方：

企業數據相對來說是比較靜態的數據，所以我們更關注的是查詢的性能，按一個企業順藤摸瓜找出相關企業的數據的性能。與之對應的是下麵這個案例，圖式搜索的應用。

案例詳見：

《金融風控、公安刑偵、社會關係、人脈分析等需求分析與數據庫實現 - PostgreSQL圖數據庫場景應用》

相關的性能指標：

1、1億企業名錄，每5萬作為一個有牽連的企業群體，每個企業牽連1000個其他企業，形成1000億的超大規模關係網。

以某個企業為中心，檢索3層關係的企業網絡：響應時間15毫秒。

數據量預估

企業：百萬。

每個企業相關的關係、輿情事件、財報等，平均預計1000條。

平均每個企業的直接相關企業有50家。

個人（法人、股東、監理、。。。）：百萬。

每個人有若幹家相關企業。

總數據量約10億級。

二、數據庫架構設計

1、相對靜態的數據(例如人、企業基本信息、主要成員、股東。。。)

量級：百萬。

有些一對多的數據，可以使用數組類型（例如企業主要成員ID、股東ID，存為數組）來存儲，從而提升查詢效率。

create table corp_info (...);       --  企業相對靜態信息  
  
create table people_info (...);     --  個人相對靜態信息

建議將這類靜態數據設計為多張表，使用PK關聯起來，減少查詢少量字段時的數據掃描量（因為PG是行存儲格式，查詢少量字段時，可以提高命中率減少IO放大）。

2、輿情、流水數據

量級：十億。

create table corp_feed (corp_id pk, typ int, event);

3、關係數據

量級：千萬 ~ 億級別。

這個量級基本上不需要考慮存儲冗餘的正向關係，反向關係，（方便sharding(FDW, hybriddb)）。

create table corp_rel (...);

4、線上線下一體化

阿裏雲線上的數據，通過邏輯訂閱、物理流式複製，可以將數據複製到線下數據庫中。

其中邏輯訂閱支持表級訂閱（每張表的訂閱速度約3萬行/s，指表在獨立訂閱通道時）。邏輯訂閱還可以通過規則或觸發器支持訂閱表中的部分數據，甚至實現格式轉換等工作。邏輯訂閱的備庫支持可讀可寫。（邏輯訂閱的大事務延遲比物理複製高）

物理流式複製，支持全庫複製，物理複製的好處是延遲低，備庫支持隻讀。

用戶建立RDS備庫的需求的起因

有些企業因為SOX審計的需求，必須要在自己的機房放一個備節點。

有些企業可能期望通過這種方法建立日常開發或測試環境。

有些架構的需求，例如雲端存儲所有數據，線下存儲部分關心的加速數據。或者雲端所有數據拆分成了多個庫，分析場景需要將數據合並起來進行分析，那麼就有多對一的複製需求，使用PostgreSQL邏輯訂閱可以支持。

5、sharding

雖然本文涉及的場景和數據量並不需要sharding(根據後麵的測試，實際上RDS PostgreSQL單庫支持1000億數據量，在穩定性、性能各方麵應該是沒有問題的。)，但是考慮到案例的通用性，還是提一下。

可以根據被查詢的ID進行切分，如有正反向關係的，可以采用冗餘存儲的方式達到切片的目的。

PostgreSQL sharding的案例很多：

1、內核層麵支持的sharding

《PostgreSQL 9.6 sharding based on FDW & pg_pathman》

2、通過plproxy代理支持的sharding

《PostgreSQL 最佳實踐 - 水平分庫(基於plproxy)》

3、通過citus插件支持的sharding和mpp

https://github.com/citusdata/citus

4、通過客戶端代理支持的sharding

https://github.com/dangdangdotcom/sharding-jdbc

https://github.com/go-pg/sharding/

三、DEMO性能

建表

create table corp_info (  -- 企業信息  
  id int primary key,  -- 企業ID，主鍵   
  info text,           -- 企業信息  
  core_team int[]      -- 核心團隊成員ID  
  -- 忽略其他字段  
);  
  
create table people_info (  -- 人信息  
  id int primary key,  -- 人ID，主鍵   
  info text,           -- 信息  
  rel_corp int[],      -- 和哪些公司相關  
  rel_type int[]       -- 分別是什麼關係(法人、建立、董事長，。。。。)  
  -- 忽略其他字段  
);  
  
create table corp_rel1 (  -- 企業正向關係  
  corp_id1 int,  -- 企業ID  
  corp_id2 int,  -- 企業ID  
  reltypid int   -- 關係類型  
);  
create index idx_corp_rel1 on corp_rel1 (corp_id1);  
  
create table corp_rel2 (  -- 企業反向關係  
  corp_id1 int,  -- 企業ID  
  corp_id2 int,  -- 企業ID  
  reltypid int   -- 關係類型  
);  
create index idx_corp_rel2 on corp_rel2 (corp_id1);  
  
create table corp_event ( -- 企業輿情  
  corp_id int,  -- 企業ID  
  event text,   -- 事件內容  
  crt_time timestamp  -- 時間  
  -- 其他字段略  
);  
create index idx_corp_event_1 on corp_event(corp_id, crt_time desc);

生成測試數據

生成10.42億測試數據，數據組成和生成方法如下：

-- 100萬 企業數據  
insert into corp_info select generate_series(1,1000000), 'test', array(select (random()*1000000)::int from generate_series(1,20));  
  
-- 100萬 人數據  
insert into people_info select generate_series(1,1000000), 'test', array(select (random()*1000000)::int from generate_series(1,20)), array(select (random()*50)::int from generate_series(1,20));  
  
-- 2000萬 企業正向關係  
insert into corp_rel1 select random()*1000000, random()*1000000, random()*100 from generate_series(1,20000000);  
  
-- 2000萬 企業反向關係  
insert into corp_rel2 select random()*1000000, random()*1000000, random()*100 from generate_series(1,20000000);  
  
-- 10億 企業輿情  
insert into corp_event select random()*1000000, 'test', now()+(id||' second')::interval from generate_series(1,1000000000) t(id);

由於數據相對靜止，所以我們可以對數據進行cluster話，提高查詢效率。（不這麼做，實際上也是毫秒級的響應時間，這麼做之後可以降低到0.0X 毫秒）

相關案例：

《機票業務性能優化案例 - 阿裏雲RDS PostgreSQL最佳實踐》

cluster corp_rel1 using idx_corp_rel1;  
cluster corp_rel2 using idx_corp_rel2;  
cluster corp_event using idx_corp_event_1;

壓測

1、企業靜態數據查詢

vi test.sql  
  
\set id random(1,1000000)  
select * from corp_info where id=:id;  
select * from people_info where id = any (array(select core_team from corp_info where id=:id));

pgbench -M prepared -n -r -P 1 -f ./test.sql -c 64 -j 64 -T 120  
  
transaction type: ./test.sql
scaling factor: 1
query mode: prepared
number of clients: 64
number of threads: 64
duration: 120 s
number of transactions actually processed: 15175162
latency average = 0.506 ms
latency stddev = 0.080 ms
tps = 126454.038435 (including connections establishing)
tps = 126468.912494 (excluding connections establishing)
script statistics:
 - statement latencies in milliseconds:
         0.001  \set id random(1,1000000)
         0.068  select * from corp_info where id=:id;
         0.444  select * from people_info where id = any (array(select core_team from corp_info where id=:id));

2、企業關係數據查詢，查詢正向和反向關係。

vi test1.sql  
  
\set id random(1,1000000)  
select * from corp_rel1 where corp_id1=:id;  
select * from corp_rel2 where corp_id1=:id;

pgbench -M prepared -n -r -P 1 -f ./test1.sql -c 64 -j 64 -T 120  
  
transaction type: ./test1.sql
scaling factor: 1
query mode: prepared
number of clients: 64
number of threads: 64
duration: 120 s
number of transactions actually processed: 49723004
latency average = 0.154 ms
latency stddev = 0.032 ms
tps = 414351.413094 (including connections establishing)
tps = 414396.709915 (excluding connections establishing)
script statistics:
 - statement latencies in milliseconds:
         0.001  \set id random(1,1000000)
         0.077  select * from corp_rel1 where corp_id1=:id;
         0.077  select * from corp_rel2 where corp_id1=:id;

3、企業最近10條輿情數據查詢

vi test2.sql  
  
\set id random(1,1000000)  
select * from corp_event where corp_id=:id order by crt_time desc limit 10;

pgbench -M prepared -n -r -P 1 -f ./test2.sql -c 64 -j 64 -T 120  
  
transaction type: ./test2.sql
scaling factor: 1
query mode: prepared
number of clients: 64
number of threads: 64
duration: 120 s
number of transactions actually processed: 94303135
latency average = 0.081 ms
latency stddev = 0.020 ms
tps = 785845.099057 (including connections establishing)
tps = 785941.120081 (excluding connections establishing)
script statistics:
 - statement latencies in milliseconds:
         0.001  \set id random(1,1000000)
         0.081  select * from corp_event where corp_id=:id order by crt_time desc limit 10;

四、達到的效果

1、性能

1.1、企業靜態數據查詢。

TPS：12.6萬

平均響應時間：0.5毫秒

1.2、企業關係數據查詢，輸出正向和反向關係。

TPS：41.4萬

平均響應時間：0.15毫秒

1.3、企業最近10條輿情數據查詢。

TPS：78.5萬

平均響應時間：0.08毫秒

2、使用阿裏雲RDS PostgreSQL，用戶不需要關心數據庫的運維，容災，備份恢複，擴容，縮容，HA等基本問題，可以更加專注於業務。

3、分析需求，使用PostgreSQL 10提供的多核並行、JIT、算子複用等特性，處理10億級的數據分析完全不在話下。

《分析加速引擎黑科技 - LLVM、列存、多核並行、算子複用大聯姻 - 一起來開啟PostgreSQL的百寶箱》

《TPC-H測試 - PostgreSQL 10 vs Deepgreen(Greenplum)》

4、機器學習需求

阿裏雲RDS PostgreSQL提供了機器學習插件MADlib，支持Classification, Regression, Clustering, Topic Modeling, Association Rule Mining, Descriptive Statistics, Validation等眾多挖掘模型。