在2016 Hadoop技术峰会的大数据银行业专题论坛上，星环科技资深架构师吕品分享了星环帮助银行客户构建大数据应用的经验。创新的技术架构打破旧有模式，全面提升生产效率。1大数据的挑战
大数据有四个特征可以概括为4个V：数据量大、数据生产的速率快、数据多样化、价值总体密度低但价值总量大。正是这四个特点，对银行业现有技术架构提出了巨大的挑战。
图1. 大数据的挑战首先，数据量大导致原有系统的存储能力不足，有限的计算能力无法处理海量数据。其次，数据产生的速度非常快，数据录入可能成为瓶颈。再者，数据格式变得多样化，除了高价值密度的结构化数据，还有更多的非结构化、半结构化数据，这部分数据价值密度低但总量大，存储和提取价值都是棘手的问题。最后，复杂多样的数据怎样通过关联分析出更多价值，也亟待解决。
2Hadoop的能力及应用
图2. Hadoop数仓的整体逻辑架构图2是一个使用hadoop构建的完整现代数仓，展现了从数据接入、数据处理到数据展示的整体逻辑架构。
左边表示数据的ETL过程：实时数据一般通过Kafka等MQ进入平台；现有系统的存量数据、第三方数据及非/半结构化数据通过文件传输方式进入平台；增量数据通过Sqoop、Kettle等ETL工具T+1进入平台，此外星环开发的TDA组件能够帮助这部分数据做到T+0的准实时同步。所有数据最后汇总到右边的数据仓库。
关于数据仓库内部的数据处理我们有专题分享，这里不再赘述。
数据仓库之上有五种类型的平台分别支撑不同类型的应用。
3自助分析平台
3.1 数据请求逻辑
银行系统一直面临一个问题，随着业务类型增多数据量变大，这个问题愈发突出，就是数据层和系统层的界限模糊不够清晰，导致数据难以管理和获取。图3展示了银行系统当前的数据请求逻辑。
图3. 银行系统当前的数据请求逻辑
1. 业务人员发起数据需求；2. 需要确认是否已经有对应的供数系统；3. 如果没有，则需要跟科技部门协商，通过提数到本地、新建报表、新建系统等方式满足供数需求，几种处理方式所花费的时间从几天到几个月；
4. 如果已经有供数系统，则需要业务部门的领导在系统内进行权限审批，审批通过才能获得数据。
在整个数据请求过程中，业务部门和科技部门权力多有交叉，数据层和系统层界限模糊不清，简单的数据请求却需要复杂的处理逻辑。
3.1.2. 改进后逻辑
图4. 改进后的数据请求逻辑
1. 业务人员发起数据需求；2. 信息管理部门根据相关规则制度，审批权限；
3. 通过则业务人员可以自助查询数据。
整套流程都在统一建设的自助分析平台之上，不再涉及科技部门和系统层面。业务部门只需要提数据需求，权限审批由专门的信息管理部门统一管理。信息管理部门根据平台是否有这份数据、业务人员是否有权限获取这份数据进行审批。如果审批通过了，业务人员就可以自助查询；如果拒绝，则直接结束。
1）时间延迟：这套逻辑非常简单，可能是线上或者线下带纸质备份的审批，时间延迟非常短，减少了流通环节无需科技部门参与；2）数据安全：数据在统一平台上，不涉及数据下发，减少泄露可能；3）一致性：所有的数据统一存放，只有一个副本，保证全局一致；4）分析性能：自助分析平台底层是物理集群，集群的分析能力比单机要强很多，所以能够增强分析能力，减少计算时间。整体上看，通过Hadoop技术，数据都录入到这个平台的存储层，在上面进行一系列的加工，变成一个个的主题模型，最后提供统一的数据接口服务，供上层的应用层访问这些数据。所有操作都在安全管控之下，所有的分析人员只能远程连到跳转机进行访问。数据不会泄露，也不会导致多个副本。下文讨论需要实现以上数据请求逻辑的几点技术需求。
3.2. 权限控制
首先，平台需要4A认证。所谓的4A就是Account、Authentication、Authorization和Audit。
图5.权限控制
3.2.2. RBAC权限控制
如同传统的关系型数据库，Inceptor有基于角色的访问控制（RBAC）。数据库的建表查表权限、数据表的增删改查权限都可以赋权给角色或个人。角色是一类特殊的权限集合，每种权限可以先赋予角色，再将角色赋予个人用户，形成类似分组的权限管控。
通过以上几种权限的综合使用，实际项目中可以形成三级权限控制：1. 库级表级权限：主题级控制；2. 列级权限：敏感字段控制；3. 行级权限：分机构访问控制。
典型的应用场景如下：
平台中有多种类型的数据，有些是客户关系，有些是交易明细。这些表放在不同的库的不同表中，从主题级别将不同的访问权限赋予不同的用户，如CRM信息赋予营销人员、交易数据赋予财务人员。
在大数据场景下，有非常多的宽表，一张表中的信息量非常大，可能有几十甚至上百个字段。如交易信息中，既有客户身份证、手机号等敏感信息，也有交易额、数据源等非敏感信息。数据分析师只允许访问非敏感信息，而管理员允许访问敏感信息。该场景下需要让不同用户访问同一张表的不同字段。在传统的关系型数据库中，往往通过建视图的方式控制列级权限，但是如果权限分类一多，就会生成非常多的视图难以管理。针对该场景，星环开发了列级权限，可以在原表上赋予不同用户不同字段的访问权限，方便管理。
3.3. 资源隔离
3.3.1. 计算资源隔离
如果没有计算资源隔离，一个用户在分析平台上提交了一个SQL任务，把计算资源占光，会影响其他用户的正常使用。
因此需要限定每个用户的计算资源。用户提交任务时可以申请专有的资源池供自己使用。物理集群根据当前是否有空闲的CPU和内存等计算资源、当前用户是否有独享资源的权限决定是否为其分配专有资源。如果没有分配，当前用户只能使用共享资源进行作业，根据作业优先级分配到队列里，进行作业调度。一个虚拟集群里可以有多个队列。
图6. 多任务队列支持计算资源隔离
3.3.2. 存储资源隔离
一个平台的存储空间是有限的，如果用户无限放入文件，平台很快就不堪重负。所以这里涉及到存储资源的隔离。
C用户分配的空间比较小，达到上限了，这时候就不允许上传数据了。
图7. HDFS Quota支持存储资源隔离
3.4. 数据联邦
一般的Hadoop解决方案中，大数据平台只能调用存储于HDFS和HBase之上的数据。然而有一些数据不适合从外部转存到HDFS或HBase中，如频繁改动的维度表，每次关联之前都要从生产库中将维度表完整的抽取过来再做关联。
图8. 数据联邦在访问外部关系型数据库时，在Inceptor中先通过DBLink的语法，将外部数据表映射到Inceptor中，访问该表就像访问Inceptor的一张内表一般。当真正访问该数据表时，数据再从外部数据库传输到Hadoop平台上。这个过程中，过滤条件会下沉到外部数据库，所以每次访问，只会传输参与计算的数据，而不是全表，大大减少传输数据量，提升效率。
4日志处理
日志处理是另一类常见的大数据应用。
4.1. 整体逻辑架构
图9. 日志处理整体逻辑架构图图9是星环常用的日志处理技术的完整逻辑框架。
数据源可以是各种应用系统的日志，或网站的访问信息。
5. 处理完的信息可以直接录入持久化存储层，如Inceptor、Hyperbase、ElasticSearch等。
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. 容量性能预警5T+0 ODS数据同步方面，在关系型数据库中，常用的是Oracle的OGG和IBM的CDC等数据库同步工具，通过抓取主库的日志文件，在从库重演一遍以达到同步效果。
目前，关系型数据库和Hadoop之间一般通过Sqoop增量抽取或数据文件传输等方式同步。但是这种方案有一些问题。首先，调度比较复杂。其次，时间延迟比较大，现在一般只能做到T+1。
星环开发了一个准实时的同步工具TDA（Transwarp Data Alive）：
4. HDFS上有调度监控程序，将日志信息在Inceptor上重演一遍，完成从关系型数据库到Hadoop的同步。
图13. 准实时同步技术实现T+0 ODS
最后附上大神的皂片供大家膜拜~
