Differences

This shows you the differences between two versions of the page.

--- architect:fin-data-system [2022/09/09 23:15] – [不该存在的需求] morgan0329
+++ architect:fin-data-system [2022/09/11 12:49] (current) – [处理OLTP&OLAP] morgan0329
@@ Line 1: / Line 1: @@
+====== 金融数据型系统的思考 ======
+===== 处理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>
+数据的不断流入，总的数量会越来越大（还是小于ToC互联网系统的数据量级）
+数据的展示以及可视化（就是查询几条数据给用户看，或者通过一定的图表显示）
+数据的分析（无论是计算各种模型，还是调用第三方算模型，或者本系统内做各类统计）
+数据的搜索
+数据的合规与安全（包括出入境管理，跨境同步等等）
+系统的合规（为满足合规要求的灾备体系，高级环境和低级环境的完全隔离；用户信息的保存与维护）
+系统的安全（监控所有API的调用；不能被大量爬取还一无所知；不能无授权地获取到不该碰触的数据）
+至于预警功能，应该算在OLAP范畴，根据用户动态定制化的在线数据分析。
+</code>
+===== 短期内不存在的需求：高并发 =====
+一般的金融数据系统，更多的是ToB,当然现有的启信宝，爱企查，企查查，都是ToC的。
+只是毕竟金融数据的查询和分析的需求，还是局限在少部分人手上。
+不像日常聊天，购物，信息分享，刷视频，点外卖如此频繁而广泛。
+<code>
+普通的系统，每个接口调用都是免费的，至少绝大部分都是免费的，而且还是给所有ToC用户，会出现高并发情况。
+分析mysql性能的时候，都是几百，几千个用户同时做查询操作，每秒总共的查询次数是上万次。
+下面的图片才变得有意义
+</code>
+{{:architect:mysql-并发.jpg?direct&800|}}
+正因为ToB，且很多接口虽然是程序调用，但是可能都会按照接口的次数来收费的。
+所以并发量上不去，大量地调用意味着用户大量的费用支出。那种对表的每秒几千次查询，都不在mysql要做性能调优的考虑范围内。
+若全是统计查询时，就算每秒一两次都会有问题。
+===== 最核心需求的解决方案 =====
+<code>
+数据的不断流入: 专门的一套系统只做数据验证和流入，可以从任何不同渠道流入，
+比如sqlsever, oss,excel, ftp, 第三方api,mysql
+数据的展示以及可视化： 专门的一套前端系统和后端查询系统
+数据的分析：专门的一套系统做各类数据分析
+数据的搜索：看情况如果直接mysql索引就能支持可以直接用，实在不行专门让ES处理
+数据的合规与安全：
+系统的合规：
+系统的安全：
+</code>
+===== 值得关注的问题：慢，体验差 =====
+因为金融数据，有些数据本系统不能存，只能实时从第三方获取，接口本身就可能慢，
+常常会出现一些接口超过十几秒，几十秒都没返回，因为太慢，严重影响用户体验。