互联网大厂的企业级风控系统项目实战

 

 

 

企业级支付系统从0到1手把手开发实战

03

如果支付时，在调起支付宝时选择的是支付宝余额支付，那么实际就是支付宝内部的一次数据流转，不涉及银行真正的资金流动。商户会在支付宝中开辟一个账户余额，客户也会在支付宝有一个支付余额，此时就是支付宝在内部将客户的余额扣减并累加到商家的余额上去

如果是客户，直接用的商家平台的积分支付或者商家平台的钱包功能，那么支付请求也就不会到达第三方支付机构，只会在商家支付平台内部

04

普通的银行卡支付

如果是同行转账，那么商户就需要在多家银行开多个银行卡账户，此时如果客户使用的是招行卡转账，那么商家就使用他自己的招行卡账户来接收、如果客户使用的是工行卡转账，那么商家就使用他自己的工行卡账户来接收等等，所以这种方式比较非商家的人工，对商家而言不太方便

如果是跨行转账，客户只有招行卡而商户只有工行卡，客户去招行给客户端工行卡直接转账，那么就需要银行们事先将自己打通，银行之间并不是一开始就能直接转账的，如果有100家银行，那么此时每家银行就要和另外100家银行都去打通

 

POS机支付

为了不让客户每次都去银行转账，所以每个银行都推出了自己的pos机，商户需要去到每个银行都办理pos机，用户持有什么银行的银行卡，那么商户就拿出哪个银行的pos机

 

银联支付

多个银行之间跨行支付，银行之间的打通和清算，是非常麻烦的，银联就是用来管理对接各个银行

有了银联之后，一个商户就不用再办多个p不同银行的pos机，只需要办理一台银联的pos机

 

支付机构

不同的支付机构都提供了自己的pos机，可能对应给到商户不同的费率，商户就可以选择费率低的pos机

此时开很多银行卡的动作变成由支付机构来做，支付机构开很多张银行卡，比如此时客户使用招行卡进行支付，那么就会先将用户招行里的钱转到支付机构招行卡中，T+1结算时，钱才从支付机构的工行卡转到商户的工行卡中。支付机构有跑路风险，所以支付机构都要有牌照来进行规范

 

课程亮点

1、企业级风控系统核心业务模块开发

2、风控系统动态规则引擎v1.0架构设计与开发实战

3、基于ClickHouse实现风控系统的核心数据存储与分析

4、风控系统动态规则引擎v2.0架构设计与Flink技术整合开发实战

5、风控系统动态规则引擎v3.0架构设计与Redis引入优化实战

6、风控系统多数据流场景下的双流join关联方案设计与开发实战

7、推荐模块业务模型设计与Flume+Kafka采集架构设计

8、特征工程模块设计与落地开发实战

9、实际业务场景落地实战-物流模块设计与数据仓库开发

10、实时数据仓库设计与落地开发实战

 

 

 

大数据基础知识

大数据技术生态中，Hadoop、Hive、Spark是什么关系？| 通俗易懂科普向_哔哩哔哩_bilibili

因为要分布式的存储数据所以有了HDFS，HDFS提供的API，使得分散存在多台机器上的数据，在API使用者看来，像是在操作单机一样

存了数据后当然就是要计算，计算就有了MapReduce分发计算合并结果，写MapReduce程序有一定的技术门槛，所以就有人想出通过SQL的方式来进行分布式数据计算分析，所以引出了Hive，Hive底层也会被翻译成MapReduce程序，所以写Hive没有直接写MapReduce程序的计算效率高

分布式计算框架Spark，对标的是Hadoop生态圈中的MapReduce，不同的是Spark基于内存的计算，而MapReduce是基于磁盘的，所以一般Spark比MapReduce快2-3倍以上