北京华夏银行卡中心之行-历史数据查询平台介绍
现在已经快到19年的5月，离北京华夏银行交流已经半年。现在再回顾，之前的交流内容的脉络更清晰了。
这次北京之行是奔着华夏银行信用卡中心关于建设大数据平台的需求而去的。其中一个重要部分是基于大数据平台构建历史数据查询平台。
这里分享历史数据查询平台建设的背景以及历史数据查询平台的优势。
痛点分析
银行在构建历史数据之前，在线事务产生的交易数据往往会存储在交易的业务系统和核心系统中，并把久远的历史交易数据迁移存储在传统数仓里。一些技术体系不完善的小行甚至只存储在业务系统。随着时间的推移和数据量大不断增大，历史数据的查询会成为巨大的痛点。业务系统因为要应对频繁的历史数据查询，无法专注于交易本身的优化和提升。
- 可查询的历史交易数据的范围小。
客户往往只能查到自己最近一年到2年的数据，3年前的数据需要到柜面递交查询申请，查询结果要等待的时间漫长，不能做到实时出结果。原因在于把历史数据迁移到传统数仓后，业务系统仅仅有近一两年的数据可查。数仓不提供实时查询功能，则3年前的数据都需要数仓的运维人员写查询的sql。这就直接导致体验极差。
- 查询耗时长，等待过程让用户体验极差，最后甚至报错。
如果业务系统中积累的历史数据很大，在没有进行架构升级前，使用的都是关系型数据库，直接导致查询效率低下。据调查，15年以前部分银行的网银系统中历史数据查询需要20秒以上。
- 无法快速生成年度账单报告、无法提供年度账单报告服务。
业务系统专注于业务交易的处理和优化。因为没有数据加工和对客户打标签的能力，无法从客户维度统计和分析客户过去一年的消费习惯、行为习惯，也无法提供未来的消费情况的预测。
- 查询的维度简单。
只能通过客户号、时间范围来查。无法按照交易类型、消费用途、交易金额等来筛选。
全新架构带来的优势
先看看业务上的数据流，如下
第一个keypoint是数据采集过程，可以是离线批量，也可以是实时单笔的采集。这个过程就使得业务数据将会迅速转移到了大数据平台中。大数据平台是有分层的，参考了传统数仓的架构，有贴源层、数据加工层、数据应用层。在这些层之间，数据被一步步的处理。在作业调度系统的协调和帮助下，数据指标和标签被计算出来。
这就是第二个关键点，可以基于多个维度进行指标的加工，包括客户维度、渠道维度、账户维度、商户维度来观察这些指标。并生成年度账单报告的相关数据。
第三个key point在于使用了高效的mpp数据库。以ES为例，历史明细数据和年度账单数据被同步到ES后，可以提供实时的毫秒级查询。历史数据查询平台不仅具备高并发性和扩展性，还能提供丰富多彩的数据展现形式，通过饼图、线图、柱状图、指标和标签等对客户进行汇报。
基于大数据的历险加工能力来构建历史数据查询平台，优势的真对上述所有痛点的。
- 以客户为中心，实现从以账户为中心到以客户为中心的转变，收支明细不再按单一账户呈现，而是为客户直观展现名下收支全视图。
- 收支分类覆盖全面，涵盖转账、现金存入、工资福利等19种收入类别，和转账、消费、取现、信用卡还款、生活缴费、交通出行、教育、医疗、餐饮等23种支出类别。
- 时间追溯长，可按周、月、年三个时间维度对收入支出进行分析，至少可追溯五年时间的收支明细，明细查询时间同业最长。
- 查询维度丰富，可设置收支类别、交易金额、交易时间、交易币种四个维度条件进行灵活查询，根据客户个性化查询需求快速定位所需的明细记录。
- 检索方式灵活，率先支持关键词检索，客户可个性化定制关键词并以关键词为索引进行明细查询，明细检索更加快捷。
- 提供智能贴心的提醒，通过金融日历，定期生成周度/月度报告，提醒客户及时查看当周或当月的收支情况。
- 展现形式直观，通过折线图、饼形图等多种形式，图形化展现客户收支趋势和分类占比，让客户更直观的掌握个人金融收支状况。
案例-广发行和交通银行
广发行历史查询平台
交通银行531历史库-系统效益
后记
这次北京之行给了我们一些溜达的时间。在华夏银行交流完成后，我和张勇总还在长安街闲逛。感受天安门的肃穆，分享游客的轻松（某种程度上，我们也是游客之一啊）。
但这个愉快的溜达过程居然遇到了潜规则，这你受不受得鸟。一个小哥也没说什么话直接递过来两个小红旗，我们误以为是派送的，接了。他就问要10块钱，并且说接了就不能退的。