创新架构提升生产效率：构建大数据银行业应用

由咪咪 · 发布日期 2016年4月22日 · 已更新 2016年4月26日

从大数据的定义四个特征：

数据量大
数据产生数据快
数据多样化
数据价值密度低总量大

因为这四个特征，对银行业的架构提出很大的挑战，首先数据量大，导致的问题是原来的存储能力不足，数据产生速度快的话，数据录入速度也会可能成为瓶颈，接下来数据多样化，包括结构化和半结构化数据，这部分数据非常难处理，这会带来一个问题就是，我们怎么去关联分析这些数据，导致关联分析能力不足，如下图：

接上CTO孙元浩先生的现代数仓，大家看下图：

这是一个非常完整的现代数据数仓，从左边是数据的录入，包括实时数据走kafka，现有业务数据走ETL，还有一些增量数据也是走ETL，从社会上购买的一些数据走flume，所有数据会汇总到右下角的大数据平台，上面会有五个平台，首先看实时推荐平台：实时推荐、实时风控、实时运维预警；离线批处理平台：用户画像等；两个平台之间会有精准营销，精准营销的一部分业务是离线业务用到批处理，实时营销也会用到流处理，所以会有一个相交的情况，还有自主分析平台、数据探索平台，数据探索平台主要是对客户流失、担保链等这些业务做一些分析，最后还有数据检索平台，主要是对历史业务数据的检索，这块业务数据量比较大，通常会在10亿至100亿级别，在传统的oracle、DB2等这些的数据库中，处理起来困难，比较慢。最后还有一个日志分析平台。

自主分析平台可能是银行迫切需要的一个东西，大家现在都知道数据价值很高，如果没有分析、没有去利用，它的价值就沉睡在哪里，无法利用，那么如果我们有了这些平台，怎么分析呢，还是要人来分析，还是要工程师来分析，不是说我们建了一个系统、一个平台，它就能用起来，所以我们要规划好系统，包括怎么去获取数据，怎么去呈现数据，接下来看下自主分析平台是怎么来做的

这是一个在银行规划的图，现在银行面临的一个问题，就是系统层和数据层建设很模糊，不够清晰，然后业务部门和科技部门在整个业务过程，他们权力有交叉，导致整个获取数据的流程非常长，具体就是，业务部门提的是具体需求，所以他处在业务部门数据层这个象限，然后他提出一些需求，问科技部门是否有这样的系统，如果没有这样的系统，他会申请建新的报表、新的系统或者最直接把数据直接给他，他在本地搭建系统使用，走这条路线的话，时间会非常长，短的话一两个月，长的话，会有一个季度；如果说已经有系统的话，就涉及到权限审批，我一个业务人员是否真的有权限拿到数据呢，这个又不是科技部门说了算，而是业务部门说了算，所以权限审批又在业务部门这个象限。最后如果有权限通过了就会获得数据，如果拒绝了，就直接返回，不能访问数据。他会带来这样几个问题：

1，审批延迟：时间非常长；

2，数据安全：如果总行的数据下方，怎么保证它的安全性；

3，一致性：如果一份数据分成几份的话，怎么保证它的一致性；

4，分析性能：一般数据下发，都导入oracle或者MySQL中，怎么保证它的分析性能；

@现在有了Hadoop平台，我们所有的数据和逻辑都放到这个平台中，业务部门只要提需求，不在需要科技部门，而是由信息管理部门查看这个平台中有没有这个数据，业务人员能不能拿到这个数据，进行审批，如果通过后，那么数据在平台中可以直接查询，如果拒绝，直接结束，这个带来的好处是把刚才的问题都解决掉，一个是时间延迟，非常简单，就是在线上或者线下，通过纸质审批，无须科技部门参与。

@数据安全，所有的数据都在一个平台上，不会涉及数据的下发和转发，就不会造成数据泄露。

@数据一致性，所有的数据都在一个平台上，就是说所有的数据只有一个副本，就会保证数据一致性。

@分析性能，因为我们的自主平台是一个集群，所以它能增强分析能力，缩短计算时间。

传统数据架构如下图：

就是从传统的业务系统，进入数据仓库，然后变成主题集市，接着到资源和数据权限的管理，最后到本地可视化展示。有了Hadoop平台后，就可形成右边的架构图，就是所有的数据都录入到平台存储层，在加工到模型层，最后提供统一的接口，形成的统一的服务，供客户使用。所有的数据都可以在总行的进行权限管控，所有的分析人员都可以连到这个平台，统一使用，就不会形成多个副本，不会导致数据泄露。

数据联邦

如上图，首先看下边的数据源，有DB2、oracle、分布式holodesk等，如果所有的数据库都要大家管理的话，会很不方便，鉴于此，星环开发了一个StarGate工具，连接各个数据库。

当大家需求的大部分数据可以已经进入到自主分析平台中，但有一些维度表可能经常会修改，对于这些数据，它们不会被采集到自主分析平台中，它们主要保存在传统DB2、oracle等数据库中，但是StarGate通过类似DB-link的语法，直接建一个link。当我们需要数据的时候，直接访问这个link就可以了，同时它还有个好处就是如果需要把数据抽取到平台来，往往不会把数据全量抽取，会有一些过滤，可以建设数据的获取量，增加性能。StarGate可以访问HDFS、holodesk、Hyperbase。最终所有这些数据源，都通过StarGate封装，对于所有的数据人员来说，他们访问的是StarGate，所有的数据都可以用SQL来访问，这个就是一个很大的创新，现在的开源有这个那个API，现在全部封装好的话，就可以很好的运维，把整个数据分析平台当成一个数据库即可。

刚才讲到要访问关系型数据库，那不可避免的会有oracle中存储过程，那星环的sql引擎，支持存储过程、函数、控制流、游标、异常处理等，plsql的语法支持98%以上。支持并行sql运行。

怎么管控数据安全？谁能去访问？谁不能去访问？通过计算资源的隔离、存储资源的隔离以及表之间的权限控制。计算资源的隔离，限制你使用哪些CPU，哪些队列，当业务需要计算的时候，是否有空余的CPU等，如果没有的话，使用共享资源或者队列；如果有权限的话，可以使用专有的资源或者队列。如果队列使用完成后，系统就会回收。动态资源的创建和回收。

存储资源：临时计算空间，静态存储空间。举例如下图，

当一个用户提交的job达到上限后，整个job就会kill掉。

行列级权限控制：如下图，

这里只介绍两个组件控制权限，主要介绍RBAC，行级权限：如客户关系表，可以给每一个客户分配如select、update、delete等权限。列级权限：一些大表和宽表，字段会比较多，同一张表中可以让不同的用户访问到不同的列，比如一些敏感字段，不能让所有的人都看到，就可以对这些敏感字段设置权限。管理可以访问所有信息，分析师访问特定信息。在关系型数据库中，一般是通过视图封装来实现，如果用户多，表也比较多，那么去通过创建视图来控制的话，视图就会特别的大，而且也会很复杂。

行级权限：这个数据平台一般是建立在总行，收集各分行的信息表，然后整合，我们希望不同的分析师看到不同的数据，如北京的分析师只能看到北京的数据，天津的分析师只能看到天津的数据。

Holodesk：自助分析平台，可能分析量小，但并发度比较高，不同的分析师可能频繁的访问，那holodesk就会有类似Cube的功能，就说我们在数据入库的时候，对数据进行相应列式存储或者建立cube或者index信息。如下图：

比如表会有很多维度，有不同的产品、不同的城市等，经常访问这个表，统计不同产品的总额、不同的城市总额等类似各个维度的分析，那我们在数据入库的时候，就对各个维度建立cube，最后数据在存储层，是被缓存在内存或SSD中，并且是列式存储，它的块头是有索引信息，这样他在访问的时候，就能提高访问的速度。所以在整个交互式自助分析的时候，提高I/o速度，就能提高整个访问速度。

日志处理架构：传统的日志数据收集已不能满足业务需求，最新的日志处理架构如下图：

数据源来自网站的访问信息、移动设备信息、业务系统，首先用flume，然后用kafka消息队列同步数据，实时预警数据处理，如果业务需要的话，可以在5s内实现实时预警。其它数据可以存储在hyperbase。

日志数据流转：如下图，

日志的采集分为：实时采集和准实时的采集；

日志结构化处理：如果是结构化系统日志数据，直接采集；

有些是应用日志，每个访问都是多个日志拼接在一起的，每次连接可能用有begin….end、input…output等，如果没有update的功能hive中，是不能把分散在两个日志中的信息连接在一起的，比如：前一天的日志信息，当它不断的刷新的时候，过了一天，断开的日志信息就会在另一个文件中，分散在两个文件中，这样的数据肯定是要结构化的。这里可以用mergeinto的语法来实现，开源的hive是没有这个语法的。

系统日志信息动态预警：系统肯定会有闲时或者忙时之分，所以肯定不能用统一的规则来预警，那我们就需要一个动态的告警线，可以解析系统的历史动态日志，来学习其中的规律，把动态的告警线呈现出来，来有价值。如下图：