【技术】Hadoop技术在银行业的创新应用

记得前天小编给大家share的那篇软文吗？

《在这个浮躁的年代，让我们一起完成一件不那么简单的事情。》

今天小编又挖到了他的一篇技术稿

《Hadoop技术在银行业的创新应用》

在2016 Hadoop技术峰会的大数据银行业专题论坛上，星环科技资深架构师吕品分享了星环帮助银行客户构建大数据应用的经验。创新的技术架构打破旧有模式，全面提升生产效率。

1

大数据的挑战

大数据有四个特征可以概括为4个V：数据量大、数据生产的速率快、数据多样化、价值总体密度低但价值总量大。正是这四个特点，对银行业现有技术架构提出了巨大的挑战。

图1. 大数据的挑战

首先，数据量大导致原有系统的存储能力不足，有限的计算能力无法处理海量数据。其次，数据产生的速度非常快，数据录入可能成为瓶颈。再者，数据格式变得多样化，除了高价值密度的结构化数据，还有更多的非结构化、半结构化数据，这部分数据价值密度低但总量大，存储和提取价值都是棘手的问题。最后，复杂多样的数据怎样通过关联分析出更多价值，也亟待解决。

2

Hadoop的能力及应用

图2. Hadoop数仓的整体逻辑架构

图2是一个使用hadoop构建的完整现代数仓，展现了从数据接入、数据处理到数据展示的整体逻辑架构。

左边表示数据的ETL过程：实时数据一般通过Kafka等MQ进入平台；现有系统的存量数据、第三方数据及非/半结构化数据通过文件传输方式进入平台；增量数据通过Sqoop、Kettle等ETL工具T+1进入平台，此外星环开发的TDA组件能够帮助这部分数据做到T+0的准实时同步。所有数据最后汇总到右边的数据仓库。

关于数据仓库内部的数据处理我们有专题分享，这里不再赘述。

数据仓库之上有五种类型的平台分别支撑不同类型的应用。

1.      实时决策平台：现在落地较多的案例有实时推荐、实时风控、实时运维预警等；

2.      离线批处理平台：主要处理一些数据量巨大的固定报表业务，如审计业务等；

3.      自助分析平台：提供交互式自助分析服务，包含传统数仓的数据集市部分；

4.      数据探索平台：提供模型实验室，帮助分析师迭代式快速建模，实现客户流失预测、担保链分析等业务场景；

5.      检索业务平台：提供对数据的检索服务，包括精确查询和模糊查询等；

6.      其中有些应用场景综合使用多种技术，如实时推荐。客户画像的工作在离线批处理平台完成，而实时推荐部分在实时决策平台完成。

大数据平台处理的数据量非常大，典型客户的单表数据量在百亿以上，这样的数据量在传统的Oracle或者DB2方案中处理起来非常困难。而应用Hadoop技术的整体解决方案，能够处理上文提出的各项挑战。

下面简单介绍银行业需求比较迫切的几个应用。

3

自助分析平台

3.1 数据请求逻辑

3.1.1.   现有逻辑

银行系统一直面临一个问题，随着业务类型增多数据量变大，这个问题愈发突出，就是数据层和系统层的界限模糊不够清晰，导致数据难以管理和获取。

图3展示了银行系统当前的数据请求逻辑。

图3. 银行系统当前的数据请求逻辑

1.      业务人员发起数据需求；

2.      需要确认是否已经有对应的供数系统；

3.      如果没有，则需要跟科技部门协商，通过提数到本地、新建报表、新建系统等方式满足供数需求，几种处理方式所花费的时间从几天到几个月；

4.      如果已经有供数系统，则需要业务部门的领导在系统内进行权限审批，审批通过才能获得数据。

在整个数据请求过程中，业务部门和科技部门权力多有交叉，数据层和系统层界限模糊不清，简单的数据请求却需要复杂的处理逻辑。

这种处理逻辑还带来其他问题：

1）时间延迟：如上所述，简单的数据请求需要几天到几个月的延迟；

2）数据安全：通过提数，数据下发到业务人员，难以管理，极易泄露；

3）一致性：多人提数，则一份数据有多份副本，一方面带来一致性问题，另一方面是对存储资源的浪费；

4. 分析性能：把数据提到本地，用本地的Oracle或者DB2，实际是单机在处理整个数据集，分析性能得不到保证。

3.1.2.   改进后逻辑

使用Hadoop技术，对整个业务流程改进，得到如图4的处理逻辑。

图4. 改进后的数据请求逻辑

1.      业务人员发起数据需求；

2.      信息管理部门根据相关规则制度，审批权限；

3.      通过则业务人员可以自助查询数据。

整套流程都在统一建设的自助分析平台之上，不再涉及科技部门和系统层面。业务部门只需要提数据需求，权限审批由专门的信息管理部门统一管理。信息管理部门根据平台是否有这份数据、业务人员是否有权限获取这份数据进行审批。如果审批通过了，业务人员就可以自助查询；如果拒绝，则直接结束。

这种处理逻辑解决了上文提的四个问题。

1）时间延迟：这套逻辑非常简单，可能是线上或者线下带纸质备份的审批，时间延迟非常短，减少了流通环节无需科技部门参与；

2）数据安全：数据在统一平台上，不涉及数据下发，减少泄露可能；

3）一致性：所有的数据统一存放，只有一个副本，保证全局一致；

4）分析性能：自助分析平台底层是物理集群，集群的分析能力比单机要强很多，所以能够增强分析能力，减少计算时间。

整体上看，通过Hadoop技术，数据都录入到这个平台的存储层，在上面进行一系列的加工，变成一个个的主题模型，最后提供统一的数据接口服务，供上层的应用层访问这些数据。所有操作都在安全管控之下，所有的分析人员只能远程连到跳转机进行访问。数据不会泄露，也不会导致多个副本。

下文讨论需要实现以上数据请求逻辑的几点技术需求。

3.2.       权限控制

3.2.1.   4A统一安全管理

首先，平台需要4A认证。所谓的4A就是Account、Authentication、Authorization和Audit。

1.      Account（账户管理）：为平台提供统一集中的账户管理，能够实现账号的创建、删除及同步等账号管理生命周期所包含的功能。

2.      Authentication（用户认证）：认证部分提供了对用户身份的认证，通常采用输入用户名和密码来进行审核。TDH使用Kerberos进行认证，可以采用密码和keytab两种方式，Kerberos支持HA。

3.      Authorization（权限管理）：通过认证后的用户可以使用Inceptor等服务，但用户能访问哪些数据、能够使用哪些资源、能够对表进行怎样的操作还需要进一步的权限管控。RBAC（Role based access control，基于角色的访问控制）在3.2.2中详细介绍，资源隔离在3.3中详细介绍。

4.      Audit（审计）：用户对各个组件的操作日志集中记录管理和分析，不仅可以对用户行为进行监控，还可以对审计数据进行挖掘，进行一系列预警。

图5.权限控制

3.2.2.   RBAC权限控制

如同传统的关系型数据库，Inceptor有基于角色的访问控制（RBAC）。数据库的建表查表权限、数据表的增删改查权限都可以赋权给角色或个人。角色是一类特殊的权限集合，每种权限可以先赋予角色，再将角色赋予个人用户，形成类似分组的权限管控。

除了库级表级权限，针对大数据场景，Inceptor还开发了行级权限和列级权限。行级权限指的是同一张表中，不同的行可以控制不同的用户访问。列级权限指的是同一张表中，不同的字段可以控制不同的用户访问。

通过以上几种权限的综合使用，实际项目中可以形成三级权限控制：

1.      库级表级权限：主题级控制；

2.      列级权限：敏感字段控制；

3.      行级权限：分机构访问控制。

典型的应用场景如下：

平台中有多种类型的数据，有些是客户关系，有些是交易明细。这些表放在不同的库的不同表中，从主题级别将不同的访问权限赋予不同的用户，如CRM信息赋予营销人员、交易数据赋予财务人员。

在大数据场景下，有非常多的宽表，一张表中的信息量非常大，可能有几十甚至上百个字段。如交易信息中，既有客户身份证、手机号等敏感信息，也有交易额、数据源等非敏感信息。数据分析师只允许访问非敏感信息，而管理员允许访问敏感信息。该场景下需要让不同用户访问同一张表的不同字段。在传统的关系型数据库中，往往通过建视图的方式控制列级权限，但是如果权限分类一多，就会生成非常多的视图难以管理。针对该场景，星环开发了列级权限，可以在原表上赋予不同用户不同字段的访问权限，方便管理。

最后是行级权限。银行的大数据平台一般建立在总行，会把数据从下面的分支行抽上来统一存储。因此一张关于交易的大表可能糅合了北京、上海、天津的数据。不同地方的分析师需要访问不同的数据，传统的做法是建立多张数据表，从应用层面进行管理。星环开发的行级权限，能够让不同的用户访问同一张表，但是只能读到用户允许访问的数据。

3.3.       资源隔离

除了权限管控，还需要计算和存储资源隔离。

3.3.1.   计算资源隔离

如果没有计算资源隔离，一个用户在分析平台上提交了一个SQL任务，把计算资源占光，会影响其他用户的正常使用。

因此需要限定每个用户的计算资源。用户提交任务时可以申请专有的资源池供自己使用。物理集群根据当前是否有空闲的CPU和内存等计算资源、当前用户是否有独享资源的权限决定是否为其分配专有资源。如果没有分配，当前用户只能使用共享资源进行作业，根据作业优先级分配到队列里，进行作业调度。一个虚拟集群里可以有多个队列。

如果当前用户申请到专有资源，集群可以为其创建单独的虚拟集群，如图6里的Inceptor2-InceptorN。分析完成或超时以后，该虚拟集群被动态销毁，资源被回收。这个需要依靠星环的容器技术TOS完成。

图6. 多任务队列支持计算资源隔离

3.3.2.   存储资源隔离

一个平台的存储空间是有限的，如果用户无限放入文件，平台很快就不堪重负。所以这里涉及到存储资源的隔离。

假如有A、B、C三个用户：

A用户没有限制平台的使用空间，可以无限上传数据；

B用户被限制了存储空间，但还没有达到上限，可以继续上传数据；

C用户分配的空间比较小，达到上限了，这时候就不允许上传数据了。

平台有些文件是静态的，还有一些文件是在计算过程中动态生成的。平台通过限制用户的临时计算空间，来限制用户提交的job的大小。当用户提交的job非常大时，会生成非常多的中间数据，达到上限，整个job会被kill掉。通过这种手段可以限制用户提交的任务大小。如果用户没有限制就可以提交非常大的任务，直到整个集群的资源被用完为止。

图7. HDFS Quota支持存储资源隔离

3.4.       数据联邦

一般的Hadoop解决方案中，大数据平台只能调用存储于HDFS和HBase之上的数据。然而有一些数据不适合从外部转存到HDFS或HBase中，如频繁改动的维度表，每次关联之前都要从生产库中将维度表完整的抽取过来再做关联。

为了统一访问平台内外的多种数据源，星环开发了StarGate组件。StarGate就像星际之门，将各种数据源通过各自的Driver汇聚在一起，供Inceptor统一访问。数据源既可以是Text、ORC、Parquet等各种存储格式的HDFS文件；也可以是Hyperbase；或是星环开发的高速列式存储Holodesk；还可以是外部的关系型数据库Oracle、DB2。不管是何种数据源，Inceptor用户都可以用统一的SQL语句访问这些数据。

图8. 数据联邦

在访问外部关系型数据库时，在Inceptor中先通过DBLink的语法，将外部数据表映射到Inceptor中，访问该表就像访问Inceptor的一张内表一般。当真正访问该数据表时，数据再从外部数据库传输到Hadoop平台上。这个过程中，过滤条件会下沉到外部数据库，所以每次访问，只会传输参与计算的数据，而不是全表，大大减少传输数据量，提升效率。

4

日志处理

日志处理是另一类常见的大数据应用。

4.1.       整体逻辑架构

图9. 日志处理整体逻辑架构图

图9是星环常用的日志处理技术的完整逻辑框架。

数据源可以是各种应用系统的日志，或网站的访问信息。

1.      首先，通过Flume agent从各个数据源采集数据；

2.      然后发送到消息队列Kafka，根据主题进入不同的topic；

3.      接着实时流处理引擎Transwarp Stream从Kafka把不同job的数据拉过来实时处理；

4.      各种实时机器学习、预警、仪表盘等应用可以通过SQL的方式写进Stream引擎，进行实时处理；

5.      处理完的信息可以直接录入持久化存储层，如Inceptor、Hyperbase、ElasticSearch等。

以往，客户处理预警信息都是T+1，当发现一些不正常状态时，机器可能已经出现故障了。现在可以做到实时预警，基本上一秒内就能定位问题设备，快速停机检修。

4.2.       日志结构化处理

日志数据往往是非结构化或半结构化的，半结构化会比较多。如何结构化日志数据？这里涉及到两类数据：一类是系统日志，每条之间没有依赖关系，我们把它称为孤立的系统日志。这种日志可以直接采集。还有一些应用日志，每一次访问都会生成多条记录，比如建立一次连接会有一个begin、一定的input和output，最后是end。但这几条信息可能散落在多个文件中，因为从begin到end可以持续较长时间。

图10. 孤立日志和关联日志的区别

在以前没有update功能的Hadoop系统中，把分散在多个文件的应用日志收集在一起是非常困难的。如果有了merge into语法，情况就会截然不同。比如第一个文件中有begin和input信息，第二个文件中有output和end信息。那么在处理第一个文件时，先把begin和input的信息写入结构化表中；处理第二个文件时，再把output和end信息update进该行的后2个字段。通过这种方式，可以快速处理应用日志。

4.3.       动态阈值告警

在传统的预警方案中，某个系统的预警线一般是一条水平线，但实际上机器的性能是会波动的，有忙时性能和闲时性能的区别。如果以固定的阈值作为监控指标缺少指导意义，因为忙时指标总是偏高，闲时指标总是偏低，无法判断出性能异常。

因此，有效的监控告警需要基于机器性能数据，根据变化规律进行动态调整。通过学习周期性性能数据，挖掘出性能变化曲线，动态阈值警告能够有效发现异常情况，提升告警有效性。

图11. 动态阈值告警

4.4.       容量性能预警

硬件规划是另一类日志分析的应用场景。对于传统的应用，硬件大多是需要时增加即可，早一点晚一点成本区别不大。但是在大数据场景下，数据快速增长，硬件规模也很大，早采购可能导致硬件限制成本上升，晚采购可能导致存储空间不足数据溢出，或是计算性能不足无法及时处理数据。

因此，通过分析日志信息，可以学习网络设备、线路、端口等历史性能指标，估算增长趋势，预测指标瓶颈，提前提示生产风险。这样在实际线碰触预警线之前，提前画出预测线，做好扩容准备。

图12. 容量性能预警

5

T+0 ODS

数据同步方面，在关系型数据库中，常用的是Oracle的OGG和IBM的CDC等数据库同步工具，通过抓取主库的日志文件，在从库重演一遍以达到同步效果。

目前，关系型数据库和Hadoop之间一般通过Sqoop增量抽取或数据文件传输等方式同步。但是这种方案有一些问题。首先，调度比较复杂。其次，时间延迟比较大，现在一般只能做到T+1。

星环开发了一个准实时的同步工具TDA（Transwarp Data Alive）：

1.      通过CDC获取关系型数据库的日志信息；

2.      将日志信息放在临时层；或者通过命令将需要快速同步的日志直接拖到批次层；或者每天任务结束时，临时层的日志会最终进入落地层；

3.      不同的同步频率作用于临时层、批次层、落地层，将同步信息传输到HDFS；

4.      HDFS上有调度监控程序，将日志信息在Inceptor上重演一遍，完成从关系型数据库到Hadoop的同步。

这个方案的好处是不同的规则作用于不同的调度层：临时层暂时不会同步，批次层会立马同步，落地层则是每天晚上同步一次。TDA可以做到不同延迟程度的同步策略，并且传输的数据量非常小，传输的只是日志文件而不是完整的数据文件，所以整个传输过程对关系型数据库的压力非常小，不影响生产库的正常业务。

图13. 准实时同步技术实现T+0 ODS

最后附上大神的皂片供大家膜拜~