数据自助使用探索和实践

数据自助使用探索和实践

1

大数据时代，随着银行的业务快速发展与信息化建设的成熟，数据积累越来越多，监管机构、银行单位自身对数据重视程度也越来越高，对数据分析的需求越来越多，同时也针对准确性、时效性、灵活性提出了更高要求。

我行业务传统的获取业务分析的途径主要靠报表系统提供的报表来满足，这种方式能够确保数据的准确性，但是由于其受制于开发测试流程的要求，从需求提出到数据正式能够使用需要经过1-2个月的时间，同时对于上线报表有任何变动，仍需要经过这一过程，所以其时效性较低。

因此为了补足时效性要求高的需求实现的缺陷，设计出了数据提取这一流程，这一流程省去了报表开发流程中大量的分析和测试工作，因此大大提升了一些数据需求的时效性。

该流程设计之初是作为报表的一个补充，但是由于近年来，业务快速的发展以及各级部门和监管机构的对数据的重视，数据提取的需求量越来越多，该流程设计时最重要的功能：时效性已经随着需求的增多开始降低。

下面是我行2017年到2019年3年的数据提取需求情况。可以看出需求的业务人员增长平缓，但是需求的增长幅度很大。

基于上述背景，为了更好的满足业务数据时效性要求，必须对数据提取的处理方式作出改变。

首先，我们先看下数据提取的处置流程。

影响数据提取时效的地方主要集中在以下几个方面：一是IT流程；二是IT人员明确业务的需求；三是IT人员处置需求，将业务需求转成程序；四是IT处理人员有限、时间有限。

所以，要提升数据的时效性，就需要对这4方面进行优化。所以设想是否能够让业务人员自助进行数据处理。这样的做的话，流程就变成下面这样。

这样的话，减少了IT人员参与，大大降低了沟通的时间消耗，同时业务人员也不再需要争夺有限的IT资源。

但是与此同时，这样执行的换，也带来了一个核心问题：业务人员怎么去使用数据。

业务人员直接使用后台数据主要存在以下方面的难点：

1、 合规要求不允许业务人员直接面对业务系统的数据库

2、 业务人员的IT属性基本没有，没有手段来处置底层数据

3、 业务数据分散在各个业务系统的各个表中，业务人员无法处置

4、 底层数据有各类码值，业务人员对各码值的意思一无所知

所以解决以上4个难点成为让业务人员自助数据的前提。也就说必须将数据进行整合、清洗和封装，同时能够将这些结果数据，提供给业务人员自助处理（不带IT属性的操作）。

经过调研分析，发现我行已有的数据仓库和帆软BI工具对处理上述的4个难点很契合。

数据仓库是我行数据中转平台，接入了我行各业务系统的业务相关数据，所以可以在该平台上完成数据的整合、清洗和封装。

帆软BI工具自带ETL数据处理，灵活的数据分析模式，可视化的数据呈现，以及spider大数据引擎，这些都足以让业务人员拖拖拽拽即可生成数据。

所以选用这他们作为业务数据自助处理的实践平台。

1、 落地模型

1.1 数据模型

通过对近三年的数据提取的需求以及和相关业务人员的交流反馈进行分析，发现数据主要集中在：存款、贷款、电子渠道、贷记卡4个业务条线，涉及客户、账户、交易等方面的信息。依据此，设计了数据层的加工模型。

依据数据属性分为客户数据和非客户数据。其中客户模块中又根据资料数据属性分为基本资料和业务资料。基本资料就是客户自身的属性信息，业务资料是客户在我行产生的业务信息，目前设计了存款、贷款、贷记卡、交易4个模块。

1.2 应用模型

针对数据如何通过帆软BI工具提供给业务自助使用，考虑到用户体验以及我行实际情况，采用以用户体验为核心的，业务通用场景为主，自助处理场景为辅的的方式。

业务通用场景的建设以科技人员为主，业务人员为辅。科技人员主动对业务的各项数据需求或者预见性的业务发展的需求进行分析整合，建设并维护通用的数据应用场景，以满足业务人员对数据实时需求。同时也提供给有主动介入意向业务人员维护的入口和权限。

自助处理场景的建设以业务人员为主，科技人员为辅。业务人员针对通用场景外的一些简单的临时需求自己进行数据组合处理，科技人员提供技术支持。一些复杂的需求，科技人员可以协助业务进行场景开发。

依据上述思路，设计了帆软BI的数据应用层。

应用层分为三部分：

第一层为BI自助数据的元数据层，都是各类一维数据组件。

第二层为BI数据处理中台。进行元数据的组合、加工以及应用模块的建设。

第三层为BI数据应用层。将数据中台处理的数据面向业务直接使用。这一层有上面提到的业务通用应用场景和自助处理应用场景组成。通用应用场景为主，自助处理应用场景为辅

1.3 调度模型

数据每日都进行批量加工处理，选用的是我行已有的MOIA调度工具批量处理。主要原因：

（1） 保证一致性：数据治理平台数据统一都是用moia工具进行调度。此次集市建设平台也是数据治理平台，也是属于管理类系统的一部分。

（2） 依赖配置便捷：此次集市建设使用的源数据为数据治理平台的基础层数据和汇总层数据，所以本集市跑批需依赖上述2个数据层加工完成，moia调度平台可配置内置依赖。

（3） 重跑功能灵活：Moia工具支持单个作业或者整个流程的任意参数的重跑。

调度流程的设计按模块来分。

上述主要三个模型设计完成后，整个实践的落地模型也就完成了。

2、 落地情况

针对于通用场景的建设，目前已经设了65个：

运行部14个、网金部10个、财务部7个、个金部6个、信贷部10个、卡部10个、公司部2个、国际部5个、三农部1个

针对于自助场景，实现了业务人员拖拉拽就能进行数据处理的操作。

目前已经在运管部、网金部、个金部、卡部4个业务部门推广使用。这4个业务部门的数据提取需求的，40%左右都能够通过BI通用场景以及自助处理场景实现。

从业务人员使用反馈来看，业务人员对该数据处理方式已经逐渐接受。

业务数据自助处理分析这一目标的实现，从来就不是简单的工具成功，而是跟整个单位的发展阶段、机制流程、人员素质、数据基础、平台能力分不开的。

但是无论如何，其在未来，会是数据分析的常态、主流。