返回目录：金融新闻
本文首度揭秘了中兴通讯的大数据平台系统DAP在国内Z银行的部署过程。
大数据是一个开放的平台，当前大部分系统是基于互联网公司的开源的产品而生，银行业是不能完全照搬互联网原生技术模式，银行业在安全性、稳定性有其特殊要求，对高可用、安全私密有更高的需求，新的大数据技术平台必须与传统行业的企业级特性相融合。
为了保证稳定性，从硬件到软件都需要考虑高可用问题。
Z银行的大数据业务场景如下：
对用户的数据进行ETL处理，通过MapReduce完成，为离线应用。
将某类数据进行抽取，放入到数据库中，对外提供查询，为在线应用。
当数据越来越多时，可通过增加存储服务器的方式进行线性扩展。
设计思路
综合上述业务场景，同步考虑金融行业的数据高安全性，服务高稳定性，我们进行规划设计。
Z银行需要进行海量数据的存储，则必须要部署HDFS，且该组件是其他组件的基础。同时用户需要对数据进行ETL处理，则MapReduce（YARN）也同样要部署。对外进行在线查询离不开HBase，因为HBase也需要进行部署。
综上，需要部署的组件有Zookeeper、HDFS、HBase和MapReduce（YARN）。
金融业的特殊性要求我们必须考虑到整体服务的高稳定性，所以需要考虑组件的高可用实现。对于各个组件的高可用实现，我们分别采用如下的实现方式：
Zookeeper：选择三台服务器部署，为集群提供协调服务。
NameNode：采用QJMHA方式部署，选择两台服务器部署NameNode，选择三台服务器部署JournalNode。
HBase：配置两台Hmaster，分别为主备，主备倒换借助Zookeeper实现。
ResourceManager：采用HA的方式部署。YARN依赖于HDFS运行，故部署时可选择将ResourceManager与HDFS的 NameNode合设、将NodeMamager与DataNode合设的方式。
业务及管理数据库：采用分布式数据库实现，一般选择三台机器作分布式数据库集群的部署。
HIVE、ZHD-Manager：分别配置两台作为主备。
了解到该银行的业务主要分为普通业务和重点业务，因此我们又必须考虑到数据和业务的安全性，为降低彼此的影响，需要进行物理隔离。我们基于此将整个机群设计为由一个大集群和若干小集群组成，大集群用于进行基础数据的清洗等ETL任务，再将处理后的数据导入到小集群中进行处理，由小集群专享该数据。一般来说一个集群都自带一套管理门户，但这样会造成维护使用上的复杂，所以为了降低部署成本和维护复杂性，就要采用单个门户管理多个集群的方式。
另外，一般来说在实际部署时整套系统环境又要分为生产环境和测试环境。其中生产环境仅仅用于实际运营，承载真实业务数据和业务应用；测试环境用于各种必要的功能验证和性能测试等，包括应用在上线前的功能验证。
如把两个环境合用，将带来很多不确定性，测试环境容易对生产环境造成干扰，影响生产环境正常业务的提供，甚至测试环境中不成熟的应用和业务运行时可能对环境造成破坏性的影响。因此对生产环境和测试环境进行物理隔离，两者独立运行，互不干扰，防止因硬件资源的占用或者抢夺对运行造成不必要的影响。保证系统运行的安全和资源的有效利用，进一步保障银行的安全生产。
解决了生产测试可能造成的互相干扰的问题，接下来我们还要考虑各种不同类型应用的部署和运行。在Z银行的应用场景中，大数据平台上运行的应用分为在线应用和离线应用两大类。作为大数据平台，就必须要对在线应用和离线应用的运行提供基本的运行规划，为应用的部署提供依据，因为不用的应用在同一套物理集群上部署运行时，同样会出现资源竞争的情形。
1）不同应用所用资源的隔离，解决在线类应用和离线类应用在运行时的资源争抢问题。
对于目前的业务场景，MapReduce任务、Hive为离线应用，HBase服务为在线应用，提供实时查询服务。部署方式如下图所示：
在线应用与离线应用资源隔离
集群中的数据都是基于HDFS进行存放的，因此对于属于同一个集群内的应用的数据隔离，可通过设置不同的HDFS目录存放的方式实现。不同应用属于不同的用户，不同的应用使用不同的目录，然后通过对目录进行权限配置的方式进行隔离和共享。
2）不用应用运行时计算资源的隔离考虑，解决运行时内存和CPU的调度问题。主要包括如下两种手段：
YARN自动均衡
通过调度器指定
由于MapReduce任务运行时往往会占用大量的CPU和磁盘资源，为保证自身或者其他任务的正常执行，对MapReduce也要进行隔离。
对于普通MapReduce任务的隔离通过YARN自身的机制完成。在YARN中，资源管理由ResourceManager和NodeManager共同完成，其中ResourceManager中的调度器负责资源的分配，NodeManager负责资源的供给和隔离。ResourceManager将某个NodeManager上资源分配给任务后，NodeManager按照要求为任务提供相应的资源，保证这些资源具有独占性，为任务运行提供基础的保证。
另外MapReduce任务实时性要求不高，可通过为各个MapReduce任务单独规划运行时间段的方式来辅助隔离，避免多个应用同时运行时出现资源抢占的情况。其中对于任务的执行时间，需要通过先在测试环境中运行采集，再通过等比例推算评估的方式获得，防止出现某个MapReduce任务的实际运行时间超出了配置时间。
而对于某些用户认为重要或者特殊（由用户自主决定）的MapReduce任务的隔离可通过设置专用调度器的方式完成。为应用设定调度队列，并为队列指定专属服务器，通过将MapReduce任务指定在某台服务器上运行的方式达到隔离的目的。而其他普通的MapReduce应用则无权使用该专属服务器的资源。
3）对不同功能的在线服务数据进行隔离，保证重点在线应用的正常运行。
需要单独规划HBase集群，且该集群基于一套独立的HDFS运行，从物理上和逻辑上和其他在线集群都进行隔离。该HBase集群的数据来源问题可通过两种方式解决：接口程序或者基于distcp的集群拷贝。
对于少量的数据迁移可通过接口程序实现，对于大量的数据迁移可通过distcp的方式进行。后者需要先在离线应用服务集群内对数据进行处理，生成HFile文件，再通过distcp将文件拷贝到在线应用集群，再在在线应用集群内执行数据导入到HBase的操作。在线应用服务再基于导入的数据对外提供实时查询服务。如下图所示：
另外由于MapReduce任务在运行时对磁盘、CPU等要求较高，当MapReduce的Job和HBase等部署在一台服务器运行时，容易对HBase服务造成影响（响应很慢，长时间等待）。所以在同一套HDFS内，在服务器比较充足的情形下，也建议对MapReduce任务的运行和HBase服务也需要进行隔离。将HBase服务指定在集群中的某些服务器上运行，MapReduce任务指定在集群中的其他服务器上运行。通过部署不同的基础服务在不同的服务器上的方式来实现。
为了节省资源，我们提供了一种基于一套HDFS来实现对多套HBase支撑的实现，不用的HBase共用一套Zookeeper，部署方式见下图：
所有HBase集群基于同一套zookeeper实现，每个集群包含各自的HMaster和Region Server，可对外独立提供在线查询服务。通过调用HBase java api实现HBase客户端访问集群内的HBase集群。由于使用相同的HDFS存储，为了防止相同的表存储空间重叠，不同的HBase集群使用不同的存储路径。同时为了区分Zookeeper中存储的rootdnode路径，也需要修改配置文件。不同的HBase集群对外提供不同类型的数据查询服务。对于同一个HBase服务，可通过对列和表的所属权配置实现对HBase的访问控制。
实际部署
Z银行的实际部署如下图所示：
大数据平台上运行的应用分为在线应用（HBase服务）和离线应用（MapReduce服务）两大类。Z银行大数据平台分为基础集群和在线集群。
基础集群用于接收外部导入的数据，并对数据进行加工处理，主要通过MapReduce任务对数据进行基础加工。
在线集群是为保证重点在线应用的正常运行而单独规划的区域，第一期是由历史数据平台1个HBase集群构成，后期再扩展个人综合对账单系统以及反洗钱风险管理系统。
基础集群和在线集群相互关系说明如下：
每个集群都基于一套独立的HDFS运行，这样从物理上和逻辑上与其他集群都进行隔离。在线集群的数据都来源于基础集群，依靠本地万兆网实现高效的传输。在线应用服务基于导入的数据对外提供实时查询服务。
基础集群以及历史数据平台集群各自基于一套Zookeeper实现，每个集群包含各自的Master和RegionServer。
整个集群中部署一套CBDP-Manager用于实现集群的管理，并且该Manager单独使用一套单机MariaDB实现管理数据、告警数据、性能数据的存储。
交付效果
整套大数据平台在部署后一直平稳运行，效果得到客户的一致称赞，并成为客户的集团内的典型案例。在后续的扩容中，也是非常的方便简洁，在短时间内即完成了扩容升级。
End.