贷款、天使投资(风控助手)业务数据库设计 - 阿里云RDS PostgreSQL, HybridDB for PostgreSQL最佳实践

本文涉及的产品
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
简介:

标签

PostgreSQL , HybridDB for PostgreSQL , 小微贷款 , 金融风控 , 企业图谱 , 图式搜索 , 舆情分析 , 自动贷款 , 贷款审查 , 审查神器


背景

贷款是银行的主营业务之一,但是并不是只有银行能提供贷款,实际上资金雄厚的公司都有能力提供贷款(比如保险行业、资源垄断型企业等)。

pic

除了放贷,我们常说的天使投资、A轮B轮啥的,也是类似的场景,凭什么投你,背后如何决策也需要决策系统的支撑。

pic

与贷款相反的是吸金类业务,比如我们现在发现越来越多的理财产品、股市、甚至是游戏充值,只要是让你存钱,把你的钱留住,而且你还不舍得吧钱取出来的业务,都是吸金类业务。

所以,一些本来就资金雄厚,或者是靠吸金类业务起来的公司,只要吸到足够的金之后,就有放贷款的能力。

放贷本身是一件体力活,来申请贷款的人或企业鱼龙混杂。什么样的人,什么样的企业能获得贷款,需要经过层层审查。审查需谨慎,否则就容易成为放贷公司的烂账。

本文涉及的项目和放贷、审查、风控、舆情系统有关。

一、需求分析

展示企业的图谱信息,例如股权结构、舆情事件、管理层、知识产权,经营状况等。方便审查员查看。

pic

数据的来源,例如爬虫得到的信息、来自合作伙伴(例如招聘网站、税务)的信息等,组成了企业相关的信息网络。

类比社交业务

这类数据和互联网的社交类业务的数据非常类似,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

pic

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亿级。

二、数据库架构设计

pic

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,指表在独立订阅通道时)。逻辑订阅还可以通过规则或触发器支持订阅表中的部分数据,甚至实现格式转换等工作。逻辑订阅的备库支持可读可写。(逻辑订阅的大事务延迟比物理复制高)

物理流式复制,支持全库复制,物理复制的好处是延迟低,备库支持只读。

pic

用户建立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毫秒

pic

pic

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等众多挖掘模型。

pic

http://madlib.incubator.apache.org/product.html

madlib手册

5、线上线下一体化,通过RDS PostgreSQL提供的流复制、逻辑订阅接口,用户可以将数据复制到远端或多个RDS,与业务灵活的组合,实现较灵活的架构(包括多MASTER的支持)。

《使用PostgreSQL逻辑订阅实现multi-master》

《PostgreSQL 10 流式物理、逻辑主从 最佳实践》

6、阿里云云端产品组合拳

使用云端的OSS,HybridDB for PostgreSQL, RDS PostgreSQL,可以支持用户从 流计算、在线业务、数据分析的业务数据闭环。

《打造云端流计算、在线业务、数据分析的业务数据闭环 - 阿里云RDS、HybridDB for PostgreSQL最佳实践》

《ApsaraDB的左右互搏(PgSQL+HybridDB+OSS) - 解决OLTP+OLAP混合需求》

阿里云 RDS PostgreSQL

阿里云 HybridDB for PostgreSQL

五、技术点回顾

本方案用到了哪些技术点:

1、MADlib,支持多种机器学习算法,通过SQL接口调用,实现了数据库的机器学习功能。

2、逻辑订阅,通过逻辑订阅,用户可以复制出多个数据库(可以按表级、行级进行复制),复制出来的SLAVE节点支持读写。

3、物理流式复制,通过物理流式复制,用户可以复制出多个备库,支持只读。

用户建立RDS备库的需求的起因:

有些企业因为SOX审计的需求,必须要在自己的机房放一个备节点。

有些企业可能期望通过这种方法建立日常开发或测试环境。

有些架构的需求,例如云端存储所有数据,线下存储部分关心的加速数据。或者云端所有数据拆分成了多个库,分析场景需要将数据合并起来进行分析,那么就有多对一的复制需求,使用PostgreSQL逻辑订阅可以支持。

4、数组类型,数组类型用于存储一对多的关系,PostgreSQL支持数组的索引检索,效率非常高。

5、SQL 流计算,通过SQL流计算,可以实时的进行数据预警,聚合,转换等操作。在三体高可用PCC大赛中见证了它的卓越效果。

六、云端产品回顾

阿里云 RDS PostgreSQL

阿里云 HybridDB for PostgreSQL

阿里云 OSS

七、类似场景、案例

1、社交类场景业务。

《三体高可用PCC大赛 - facebook\微博 like场景 - 数据库设计与性能压测》

《facebook linkbench 测试PostgreSQL社交关系图谱场景性能》

2、图式搜索相关的金融风控、公安刑侦、社会关系、人脉分析等需求分析类业务。

《金融风控、公安刑侦、社会关系、人脉分析等需求分析与数据库实现 - PostgreSQL图数据库场景应用》

八、小结

贷款这项业务已经不是银行的专利业务,越来越多的企业都开通了类似(贷款、投资)业务。

放贷本身是一件体力活,来申请贷款的人或企业鱼龙混杂。什么样的人可以获得贷款,什么样的企业值得投资,需要经过层层审查。审查需谨慎,否则就容易成为放贷公司的烂账。

通过爬虫、合作伙伴渠道可以获得个人、企业的信息、舆情信息等,通过这些信息的有效组织,可以帮助放贷人、投资人快速的做出决策,选择是否需要放贷或投资。

业务方使用阿里云的RDS PostgreSQL, HybridDB for PostgreSQL, OSS等组合产品,减轻了业务方的数据库维护、HA、容灾、扩容、缩容等负担。业务方可以专注于应用开发,提高效率。

性能方面,远远超出业务预期(如果每秒几十万笔查询还不够,你的贷款业务得多红火呀 ^_^)。

九、参考

《三体高可用PCC大赛 - facebook\微博 like场景 - 数据库设计与性能压测》

《facebook linkbench 测试PostgreSQL社交关系图谱场景性能》

《金融风控、公安刑侦、社会关系、人脉分析等需求分析与数据库实现 - PostgreSQL图数据库场景应用》

《机票业务性能优化案例 - 阿里云RDS PostgreSQL最佳实践》

《分析加速引擎黑科技 - LLVM、列存、多核并行、算子复用 大联姻 - 一起来开启PostgreSQL的百宝箱》

《TPC-H测试 - PostgreSQL 10 vs Deepgreen(Greenplum)》

《使用PostgreSQL逻辑订阅实现multi-master》

《PostgreSQL 10 流式物理、逻辑主从 最佳实践》

《打造云端流计算、在线业务、数据分析的业务数据闭环 - 阿里云RDS、HybridDB for PostgreSQL最佳实践》

《ApsaraDB的左右互搏(PgSQL+HybridDB+OSS) - 解决OLTP+OLAP混合需求》

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
2月前
|
存储 关系型数据库 MySQL
一个项目用5款数据库?MySQL、PostgreSQL、ClickHouse、MongoDB区别,适用场景
一个项目用5款数据库?MySQL、PostgreSQL、ClickHouse、MongoDB——特点、性能、扩展性、安全性、适用场景比较
|
3月前
|
NoSQL 关系型数据库 MySQL
微服务架构下的数据库选择:MySQL、PostgreSQL 还是 NoSQL?
在微服务架构中,数据库的选择至关重要。不同类型的数据库适用于不同的需求和场景。在本文章中,我们将深入探讨传统的关系型数据库(如 MySQL 和 PostgreSQL)与现代 NoSQL 数据库的优劣势,并分析在微服务架构下的最佳实践。
|
7天前
|
运维 关系型数据库 MySQL
自建数据库迁移到云数据库RDS
本次课程由阿里云数据库团队的凡珂分享,主题为自建数据库迁移至云数据库RDS MySQL版。课程分为四部分:1) 传统数据库部署方案及痛点;2) 选择云数据库RDS MySQL的原因;3) 数据库迁移方案和产品选型;4) 线上活动与权益。通过对比自建数据库的局限性,介绍了RDS MySQL在可靠性、安全性、性价比等方面的优势,并详细讲解了使用DTS(数据传输服务)进行平滑迁移的步骤。此外,还提供了多种优惠活动信息,帮助用户降低成本并享受云数据库带来的便利。
|
4月前
|
关系型数据库 MySQL 数据库
RDS MySQL灾备服务协同解决方案构建问题之数据库备份数据的云上云下迁移如何解决
RDS MySQL灾备服务协同解决方案构建问题之数据库备份数据的云上云下迁移如何解决
|
23天前
|
安全 关系型数据库 MySQL
体验自建数据库迁移到云数据库RDS,领取桌面置物架!
「技术解决方案【Cloud Up 挑战赛】」正式开启!本方案旨在帮助用户将自建数据库平滑迁移至阿里云RDS MySQL,享受稳定、高效、安全的数据库服务,助力业务快速发展。完成指定任务即可赢取桌面置物架等奖励,限量供应,先到先得。活动时间:2024年12月3日至12月31日16点。
|
3月前
|
Oracle NoSQL 关系型数据库
主流数据库对比:MySQL、PostgreSQL、Oracle和Redis的优缺点分析
主流数据库对比:MySQL、PostgreSQL、Oracle和Redis的优缺点分析
661 2
|
2月前
|
存储 关系型数据库 MySQL
四种数据库对比MySQL、PostgreSQL、ClickHouse、MongoDB——特点、性能、扩展性、安全性、适用场景
四种数据库对比 MySQL、PostgreSQL、ClickHouse、MongoDB——特点、性能、扩展性、安全性、适用场景
|
4月前
|
存储 C# 关系型数据库
“云端融合:WPF应用无缝对接Azure与AWS——从Blob存储到RDS数据库,全面解析跨平台云服务集成的最佳实践”
【8月更文挑战第31天】本文探讨了如何将Windows Presentation Foundation(WPF)应用与Microsoft Azure和Amazon Web Services(AWS)两大主流云平台无缝集成。通过具体示例代码展示了如何利用Azure Blob Storage存储非结构化数据、Azure Cosmos DB进行分布式数据库操作;同时介绍了如何借助Amazon S3实现大规模数据存储及通过Amazon RDS简化数据库管理。这不仅提升了WPF应用的可扩展性和可用性,还降低了基础设施成本。
98 0
|
4天前
|
存储 Oracle 关系型数据库
数据库传奇:MySQL创世之父的两千金My、Maria
《数据库传奇:MySQL创世之父的两千金My、Maria》介绍了MySQL的发展历程及其分支MariaDB。MySQL由Michael Widenius等人于1994年创建,现归Oracle所有,广泛应用于阿里巴巴、腾讯等企业。2009年,Widenius因担心Oracle收购影响MySQL的开源性,创建了MariaDB,提供额外功能和改进。维基百科、Google等已逐步替换为MariaDB,以确保更好的性能和社区支持。掌握MariaDB作为备用方案,对未来发展至关重要。
17 3
|
4天前
|
安全 关系型数据库 MySQL
MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!
《MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!》介绍了MySQL中的三种关键日志:二进制日志(Binary Log)、重做日志(Redo Log)和撤销日志(Undo Log)。这些日志确保了数据库的ACID特性,即原子性、一致性、隔离性和持久性。Redo Log记录数据页的物理修改,保证事务持久性;Undo Log记录事务的逆操作,支持回滚和多版本并发控制(MVCC)。文章还详细对比了InnoDB和MyISAM存储引擎在事务支持、锁定机制、并发性等方面的差异,强调了InnoDB在高并发和事务处理中的优势。通过这些机制,MySQL能够在事务执行、崩溃和恢复过程中保持
21 3

相关产品

  • 云数据库 RDS
  • 云数据库 RDS PostgreSQL 版
  • 云数据库 RDS MySQL 版