在数据中台中的数据查询功能如何设计?

一方面前端或渠道对于明细数据的查询需求各异,另一方面很多系统积累的数据成指数级增长,自身运维压力较大,就将历史数据迁移到了数仓或大数据平台保存,并对自身的数据做了清理。这就造成了一份数据,按照数据产生时间的不同存在两个系统里。前端系统的很多数据查询需求,要求的时...显示全部

一方面前端或渠道对于明细数据的查询需求各异,另一方面很多系统积累的数据成指数级增长,自身运维压力较大,就将历史数据迁移到了数仓或大数据平台保存,并对自身的数据做了清理。
这就造成了一份数据,按照数据产生时间的不同存在两个系统里。
前端系统的很多数据查询需求,要求的时间段比较长,例如最近3-5年。在这样的大背景下,如何为前端系统提供无缝的数据查询服务

收起
参与10

查看其它 2 个回答木讷大叔爱运维的回答

木讷大叔爱运维木讷大叔爱运维运维老兵互联网+金融

这是一个很好的问题,不止数据中台,很多涉及历史数据查询的场景都会遇到。数据内容分层和数据组件分级是可以总结出一套明确方法论来指导实践的。笔者在之前的文章中曾经系统的分享过,各位架构师可以查询阅读。这里抛砖引玉,以金融业常见的客户交易明细查询场景为例,说明方法论中需要各位架构师关注的点:

关注点 1 :明确服务对象。直接服务客户、间接服务客户、服务内部管理、服务内外部审计、服务运维异常备查。不同的服务对象,对数据存储组件的综合性能(并发、容量、弹性扩容等)要求不同,这部分可以通过固定的几项指标量化。上述几个服务对象对数据存储组件综合性能的要求基本是逐级递减的。

关注点 2 :量化服务场景。客户交易明细查询场景就要通过关键指标来量化这个场景,需要明确不同时间区间的访问频度、访问峰值,单次查询的时间范围区间,单次查询的返回记录数,数据明细分布曲线。这一组量化的数据将是指导数据内容时间区间划分、数据存储组件选型的重要依据。

关注点 3 :量化组件能力。这里要结合各家机构自身所具备的技术储备,区分自身所具有的数据存储组件能力,像笔者所在机构,就具备关系型数据库、内存数据库、分布式 KV 型数据库、分布式数据等组件可控选型,这里可以从单表容量、性能、是否支持复杂关联等技术指标和响应级别、灾备级别等运维指标上得以量化。

关注点 4 :综合服务对象、量化后的服务场景、量化后的组件能力,制定数据组件的分级服务方案,多种组件取长补短、灵活插拔、组合服务。回到客户交易明细查询场景的例子: T+0 日数据,由产品系统通过实时流同步至内存数据库提供服务; T+1 年数据,由产品系统夜间批量同步至关系型数据库提供服务; T+1 年 ~T+10 年,由关系型数据库定期降级至分布式数据库提供服务。前台封装数据查询逻辑,实现数据查询路由、数据分页游标缓存等基本功能。

金融其它 · 2020-06-04
浏览2789

回答者

木讷大叔爱运维
运维老兵互联网+金融

木讷大叔爱运维 最近回答过的问题

回答状态

  • 发布时间:2020-06-04
  • 关注会员:4 人
  • 回答浏览:2789
  • X社区推广