这是一个很好的问题,不止数据中台,很多涉及历史数据查询的场景都会遇到。数据内容分层和数据组件分级是可以总结出一套明确方法论来指导实践的。笔者在之前的文章中曾经系统的分享过,各位架构师可以查询阅读。这里抛砖引玉,以金融业常见的客户交易明细查询场景为例,说明方法论中需要各位架构师关注的点:
关注点 1 :明确服务对象。直接服务客户、间接服务客户、服务内部管理、服务内外部审计、服务运维异常备查。不同的服务对象,对数据存储组件的综合性能(并发、容量、弹性扩容等)要求不同,这部分可以通过固定的几项指标量化。上述几个服务对象对数据存储组件综合性能的要求基本是逐级递减的。
关注点 2 :量化服务场景。客户交易明细查询场景就要通过关键指标来量化这个场景,需要明确不同时间区间的访问频度、访问峰值,单次查询的时间范围区间,单次查询的返回记录数,数据明细分布曲线。这一组量化的数据将是指导数据内容时间区间划分、数据存储组件选型的重要依据。
关注点 3 :量化组件能力。这里要结合各家机构自身所具备的技术储备,区分自身所具有的数据存储组件能力,像笔者所在机构,就具备关系型数据库、内存数据库、分布式 KV 型数据库、分布式数据等组件可控选型,这里可以从单表容量、性能、是否支持复杂关联等技术指标和响应级别、灾备级别等运维指标上得以量化。
关注点 4 :综合服务对象、量化后的服务场景、量化后的组件能力,制定数据组件的分级服务方案,多种组件取长补短、灵活插拔、组合服务。回到客户交易明细查询场景的例子: T+0 日数据,由产品系统通过实时流同步至内存数据库提供服务; T+1 年数据,由产品系统夜间批量同步至关系型数据库提供服务; T+1 年 ~T+10 年,由关系型数据库定期降级至分布式数据库提供服务。前台封装数据查询逻辑,实现数据查询路由、数据分页游标缓存等基本功能。