银行海量交易数据是怎么存储的？海量流水数据如何开放给客户查甚至导出？

【CaesarChan的回答(6票)】:

其实我想说下，仅“流水数据查询”这个功能还用不到“大数据”的概念。

看下百度百科里面“大数据”的概念

大数据技术(big data)，或称巨量资料，指的是所涉及的资料量规模巨大到无法通过目前主流软件工具，在合理时间内达到撷取、管理、处理、并整理成为帮助企业经营决策更积极目的的资讯。在维克托·迈尔-舍恩伯格及肯尼斯·库克耶编写的《大数据时代》中大数据指不用随机分析法（抽样调查）这样的捷径，而采用所有数据进行分析处理。大数据的4V特点：Volume（大量）、Velocity（高速）、Variety（多样）、value（价值）。

“合理时间内达到撷取、管理、处理、并整理成为帮助企业经营决策更积极目的的资讯。”分析和决策这才是银行引入“大数据”处理的关键因素。仅仅对于“海量流水数据提供给客户查询”而言，只是满足了客户的某个功能性需求而已。

一般来说，银行的数据都是结构化的、持久性存储的（非结构化的数据一般指电子影像，如客户办理业务的回单扫描图片等），以数据库以及文件方式存储为主。按照交易数据性质，我们可以分为“原始流水数据”和“加工后数据”两种。

“原始流水数据”一般最开始生成于交易处理的应用程序（这些应用可以理解为前线部队）处理交易的过程，几乎记录了交易的所有内容：交易日期、交易时间、卡号、账号、地区号、网点号、地点、终端编号、柜员编号、交易凭证（如Transaction Certification）、交易渠道等等等等乱七八糟你想得到想不到的字段。曾经见过一张表，多达数百个字段，一条记录长度多达数千字节。这类数据的特点是，信息全面，占用空间大。

“加工后数据”产生于“原始流水数据”，一般情况下，“前线部队”会把“原始流水数据”提供给其他应用程序（可以理解为后勤部队），“后勤部队”会根据自身应用的需求将数据进行裁剪而不是照单全收。简单举个例子，假设用户拿到的信用卡对账单是由一个叫做“客户账单”（Customer Statement，下面简称CS）的应用生成。CS会根据业界的标准从交易流水中获取仅需的数据，比如交易日期，商户名称、卡号、交易币种、交易金额等。其他并不需要的数据就会被舍弃，这样也就保证了数据存储的经济性。

好了，经过上面的理论准备，我们来设计一个“历史数据查询”（Historical Data Inquiry,下面简称HDI）的应用，首先看下它的功能和特点：

1.需要支持对客户历史流水数据的查询；

2.需要很大的存储空间；

3.交易以查询为主；

4.数据插入的时效性不高，没有数据删除操作；

可以看出，HDI应用的设计难点主要在存储空间、查询速度、数据更新方式方面。让我们以银行卡历史流水数据查询交易为例，一个个分析这些难点应该如何解决：

1.存储空间。我们之前举了“原始流水数据”的特点：信息全面，占用空间大。为了解决这个问题，我们首先可以来一次数据的裁剪，HDI本来也是个“后勤部队”，抄起大砍刀一阵猛砍，只留下交易渠道、交易日期，商户名称/网点名称、卡号、交易币种、交易金额几个字段。几千个字节一下减为200个字节。但这样就结束了吗？还没有！积少成多的道理大家都知道，一条记录多50个字节，100条记录就多5000字节！还怎么砍？二八原则，让我们从商户名称来想办法！举个例子（请勿对号入座）：“内蒙古自治区锡林郭勒盟东乌珠穆沁旗满都胡宝拉格镇满都宝拉格苏木小学小卖部”，整整36个字，72个字节，每做一笔交易HDI就要给一份存储的钱啊！咋办？加个设备档案参数表，再多也不过超过百万级的数据，每个商户只存一次，流水表里面只存个10位的端机编号，查询的时候展示出来，存储空间立马就节省出来了。

解决办法：数据裁剪、档案参数表。

2.查询速度。首先需要分析下，这类交易的量大不大？数据变动多不多？查询条件复不复杂？分析一下我们就可以知道，大多数此类业务的场景都是“拿流水办证明”，交易频度并不高；作为历史数据，“What's done is done”,不存在太大对已插入数据变更的概率；查询条件也一般为卡号+时间区间。在大海里面捞针很困难，但在水杯里面找颗茶叶还是很容易的。我们的策略就是：对数据库进行分库、分区、分表，简单的理解：把长袜子和短袜子放在不同的抽屉里面，想找的时候就拉对应的抽屉即可！具体可以把数据库按时间区分，按卡号区间区分，在进行数据查询的时候就事前指定方向，这样跟从大堆数据里面捞东西相比就快了很多了。

解决办法：数据库分库、分区、分表，限定查询的灵活性。

3.数据更新方式。既然说是历史数据查询，那么也就没有实时性的需求，HDI可以通过后台批量的方式将数据慢慢进行裁剪、插入，每天/每周/每月加载都可以，数据量再大都有充足的处理时间。

解决办法：后台批量更新。

总结：单纯就“海量流水数据如何开放给客户查甚至导出”这个功能来说，还用不到“大数据”这样高大上的概念，使用传统的技术加上设计的一些构思就完全能够实现。而对数据的分析和处理，以便获得可供决策的关键数据，这才是“大数据”概念的关键所在。毕竟，无论你查或不查，历史明细就在那里，不增不减；市场才是瞬息万变，大数据分析的准确性、时效性才是赢得市场的关键砝码。

就数据“银行海量交易数据是怎么存储的”这个问题， @du不知道已经答复比较清楚了，这里就不赘述了。

PS:多谢 @detail lee指导，补充下表达下：

1.开放提供给客户查询的数据只是银行海量数据的一小部分，这部分数据是可以通过传统的方式截取、存储手段展现的;

2.大数据的存储、处理，目前银行业多使用数据仓库，TeraData技术来实现,主要作为内部数据分析处理使用；

3.存量“原始流水数据”银行还是主要使用磁带备份方式。

4.银行IT的现状是对新技术的使用还是比较慢比较谨慎，特别是对已有系统的升级改造更是慢，真需要跟业界（特别是金融界的其他IT）取经多学习。

【du不知道的回答(4票)】:

个人了解：

1、就存储来说，一般会按照时间维度划分，时间近的存当前库，时间久的存数据仓库。时间近的就是普通库如主机db，时间远得就数据仓库。目前数据仓库国内采用技术几乎全是td，它可谓数据仓库届的老大，但成本较高。

2、按照政策要求，银行是需要保留15年的数据供审计。数据存储也是按照一年，三年，等时间划分。目前几大行建成数据仓库的不多。

3、客户的查询一般简单，银行数据库端行已经是做到了读写分离，支撑查询没有问题。

4、对于处理加工分析一般是在数据仓库处理，如一些报表等。它一般供业务人员查询，并发用户较少。分析可用sas等建模进行分析。

5、由于银行一般是非实时数据的分析处理，目前也可以采用Hadoop平台进行处理，但处理速度远不如td。

【杨博的回答(2票)】:

不邀自来。题主想单纯了解银行数据存储及查询所涉及到的技术的话，我可能还是能够说点什么的。

银行客户群体庞大且数据细致条目众多，这使得银行每天的交易所产生和涉及到的数据量极为庞大。根据人行和银监会的要求，对每个交易账户，银行需要保存长达15年的数据。但实际上我们只能查询近一年的交易数据。这是因为银行所有的用户数据通常都是静态存储的，而近一年的数据是做了数据持久化的。而且通常这些数据都是分布存储在各省分行的。静态存储就是将数据集中存储在数据库集群中，这部分数据不会经常被查询，因此可以直接存在数据库的物理文件中，直接以文件的形式存在于硬盘上。这种存储方式是查询不友好的，也就是说查询一次耗费的时间和性能是比较高的（尽管这种消耗对于我单次查询是可以忍受的，但由于用户量巨大，可能同一时间会有很多次查询，这就会极度占用系统资源），因为每次查询数据都要直接从硬盘读取数据。对于提供给用户经常查阅的近一年的数据肯定不能仅仅通过这种方式存储。所以出现了另一种方式，就是为能够经常被查阅的数据做数据持久化。数据持久化实际上是一种计算机技术，通过这种技术，系统可以将数据库中的一部分数据动态加载到内存中，提供一个更高速性能更好的数据源供系统查询。这就使得用户可以即时查询自己近期的全部交易记录。除此之外，实际上用户每天的交易数据也不是实时记录到数据库文件中的，这些数据都是以天为单位向数据库体提交的。

以上是关于一年内可查询数据的存储方式。这些数据用户可以通过终端或者网银随时查询。

至于一年以上的用户数据，通常都是直接从静态数据中查阅的，而且也不是任何一个用户都能随时查阅，必然要提交申请获得，有的还需要等待到一个工作日出结果。这就是因为这样大量对静态数据的查询比较耗时，银行会集中查询。

银行应该还没有哪家可以提供用户从开户以来但现在的所有数据，而且也没这个必要。除非是开户不超过15年的。存储数据成本非常大。多一个月的不必要数据都会使成本大增。

各银行，无论大小，所使用的数据库无非oracle db2等等，而且由于用户数据与交易记录通常联系紧密，因此通常都是关系数据库。之前说过，这些数据库是分布式的，就是为了满足各个省分行对本地区账户的访问。但通常总行都有数据中心来存储最终固化的数据。

至于数据的分析，这个由于不需要即时查询，可以集中处理。

说了这么些，纯粹是从技术人员的角度说了银行数据的存储及访问。如果有不明确的或者疏漏的，请后来人补充。

题主还有疑问可以继续追问。

【爻艮兑的回答(1票)】:

一般都是分级分档分别存储的。

比如当月数据存交易系统实时库里，一年内的存在数据仓库里，三年内的存数据仓库历史库里，三年以上的存带库里。

至于你说的交易对账单这样的给客户看的东西一般都是加工好的成品数据，所以可以存很久很久的，那才占多大点空间啊！

银行的科技系统其实比绝大多数的互联网科技企业要复杂而庞大得多。

【邓昳轶的回答(1票)】:

历史数据查询在很长时间内都是国内各大银行的软肋，特别是对客部分。直到大数据技术的出现，那些说大数据炒作的人睁开眼看看，至少大数据技术解决了实际问题不是吗？

据我所知，各大行试水大数据都是从历史数据查询开始的，有些行已经建成了。我们行也在启动了，差不多也是HBASE这一套，现在还不敢说效果，等建好了再来答您。

不过可以预见的是，性能不是问题，数据治理方面才是真正的难点。

【detaillee的回答(0票)】:

是不是都在用hbase技术架构？

【ltye的回答(0票)】:

谢邀，我不负责数据平台和业务系统，了解的不是太多~ 不过我们行的核心系统数据都是结构化、关系型数据库存储的。

【知乎用户的回答(0票)】:

除个别大的银行的历史数据可能较多， 单就某个银行的数据来说，算不上海量。