M Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 金融数据型系统的思考 ======

===== 处理OLTP&OLAP =====
既然是数据型，就意味着不断的流入数据，会有大量的数据做计算与分析。

这就引出了个概念：在线事务（On-Line Transaction Processing）和在线分析（On-line Analytical Processing）。
<code>
像应用程序，不断地读取或写入数据，算作OLTP。
像不断地预先把一些数据分析处理好的场景，如果这个换成在线实时地进行，就算作OLAP。
一旦数据量大了以后，这两件事情无法做到在同一组数据库里完成，OLAP会消耗大量性能从而影响OLTP，进一步影响用户体验。
传统的做法就是分成两个副本，不断把OLAP分析好的结果，同步到OLTP的副本上。

（不太复杂的系统不要去尝试追新）
现在业界有一种新思路的实践（源于1994）：Hybrid Transaction Analytical Processing 混合事务分析，
希望做到同一组数据库，既完成OLTP又完成OLAP。
同时能保证足够好的性能，不至于影响在线用户体验。

给人感觉，就是用分布式体系，把数据库也做成分布式的相当于一套数据库有几个副本，
然后某一个副本在做OLAP时不影响其他副本给应用程序提供OLTP服务。
</code>

===== 最核心需求 =====
<code>
1 数据的不断流入，总的数量会越来越大（还是小于ToC互联网系统的数据量级）
2 数据的展示以及可视化（就是查询几条数据给用户看，或者通过一定的图表显示）
3 数据的分析（无论是计算各种模型，还是调用第三方算模型，或者本系统内做各类统计）
4 数据的搜索
5 数据的合规与安全（包括出入境管理，跨境同步等等）


6 系统的合规（为满足合规要求的灾备体系，高级环境和低级环境的完全隔离；用户信息的保存与维护）
7 系统的安全（监控所有API的调用；不能被大量爬取还一无所知；不能无授权地获取到不该碰触的数据）


至于预警功能，应该算在OLAP范畴，根据用户动态定制化的在线数据分析。
</code>


===== 短期内不存在的需求：高并发 =====
一般的金融数据系统，更多的是ToB,当然现有的启信宝，爱企查，企查查，都是ToC的。
只是毕竟金融数据的查询和分析的需求，还是局限在少部分人手上。
不像日常聊天，购物，信息分享，刷视频，点外卖如此频繁而广泛。

<code>
普通的系统，每个接口调用都是免费的，至少绝大部分都是免费的，而且还是给所有ToC用户，会出现高并发情况。
分析mysql性能的时候，都是几百，几千个用户同时做查询操作，每秒总共的查询次数是上万次。
下面的图片才变得有意义
</code>
{{:architect:mysql-并发.jpg?direct&800|}}

正因为ToB，且很多接口虽然是程序调用，但是可能都会按照接口的次数来收费的。

所以并发量上不去，大量地调用意味着用户大量的费用支出。那种对表的每秒几千次查询，都不在mysql要做性能调优的考虑范围内。

若全是统计查询时，就算每秒一两次都会有问题。

===== 最核心需求的解决方案 =====

<code>
1 数据的不断流入: 专门的一套系统只做数据验证和流入，可以从任何不同渠道流入，
比如sqlsever, oss,excel, ftp, 第三方api,mysql
2 数据的展示以及可视化： 专门的一套前端系统和后端查询系统
3 数据的分析：专门的一套系统做各类数据分析
4 数据的搜索：看情况如果直接mysql索引就能支持可以直接用，实在不行专门让ES处理
5 数据的合规与安全：


6 系统的合规：
7 系统的安全：
</code>

===== 值得关注的问题：慢，体验差 =====
因为金融数据，有些数据本系统不能存，只能实时从第三方获取，接口本身就可能慢，

常常会出现一些接口超过十几秒，几十秒都没返回，因为太慢，严重影响用户体验。