项目背景及目标

大数据已成为当前发展快且受关注的新兴技术之一，大数据对于银行业务发展的重要性和支撑作用已不言而喻。与此同时，随着银行信息技术的不断发展，服务器、存储设备、应用系统等的数量越来越多，网络架构也变得愈加复杂。对各类大量复杂运维数据的及时处理正迫使传统IT运维方法发生改变。为保障良好的客户体验和数据时效性，银行IT运维管理面临一定的挑战。而国内银行业大数据技术的应用大多集中于对业务经营发展的研究与探索，在IT运维方面应用较少。

因此，在当前大数据集中趋势越来越明显的背景下，借助大数据处理技术，打造具备实时采集和海量分析能力的智能化大数据运维体系，增强智能检索、告警关联、辅助预警、问题回溯等运维能力，实现事前及时预警、事后快速溯源，已成为大数据在银行业运维管理工作中新的探索实践方向。

结合数据中心生产运维实际情况和上述需求，江苏农信数据中心发起运维大数据平台项目，实施针对多套重点系统日志智能检索分析、异常检测和辅助预警等功能的建模与开发。

开发完成后，将江苏农信数据中心的所有运维数据完成数据集中（包括数据治理），并且完成基于数据湖数据的分析模型，帮助我们提高运维效率，并有效降低故障发生率。

项目方案

一、 技术方案

1.1 项目实施范围

本项目实施范围根据甲方所发出的邀标文件中的实施范围为基础，另外考虑甲方现有环境中的大数据平台使用状况，设计 一套适合甲方所使用的综合统一大数据平台，并且将现有ECC大屏展示系统的数据与数字化智能运维平台进行对接，完成邀标文件中的业务类分许需求。

1.2 工作项目

1.2.1 大数据平台建设

分析甲方现存数据，根据现有数据体量以及业务需求设计适合甲方信息科技部的大数据平台。建设的大数据平台以开源方案为主体，结合数字化智能运维平台、端到端监控平台、基础运维监控平台、大屏展示平台、主机监控平台等多平台数据需求，提供适合不同业务的数据保存方案，并且合理部署大数据平台的各组件。涉及组件包括但不限于以下：

数据采集Agent：Flume

消息队列：Kafka

大数据ETL工具：Sqoop

流式计算引擎：Spark Streaming／Storm

分布式计算引擎：Spark

数据模型组件：MATLAB／DeepLearning4J

日志处理组件：ElasticSearch

分布式文件系统组件：HDFS

NoSQL数据库：Hive／HBase／Phoenix

内存数据库：Redis

资源调度管理：Yarn／Zookeeper

规则引擎：CEP

1) 设计原则

在大数据平台设计时，我们遵循以下的设计原则：

通用性：基于Hadoop2社区标准以及考虑各组件数据交互使用统一接口规范是平台架构设计的基本要求。各组件之间数据交互尽可能通过Kafka完成，所有组件产生的数据使用统一的接口协议写入Kafka的Topic当中供其他组件进行数据消费。

先进性：使用新的大数据平台技术，紧跟社区发展方向，改善底层平台的数据支持力度，提高平台运算能力，并根据业务场景的挖掘，不断完善平台的模型支持能力。

扩展性：基于Hadoop2的架构原则，实现各功能组件节点的快速水平扩展，并且根据业务需求，合理分配replica数量。

2) 物理架构

大数据平台物理架构示意图如下：

上述架构既可以部署在云环境，也可以部署在物理机集群，但是从使用性能上看，我们更推荐物理机集群部署。

3) 逻辑架构

大数据平台逻辑架构示意图如下：

从上图中我们可以看到整个平台分为了4层：

数据源：数据中心运维过程中产生的所有可收集数据均为对象数据源，包括但不限于：监控系统产生的监控数据，包括系统层／数据库层／中间件层／各类硬件设备／APM管理工具等各种监控数据；系统日志数据，包括诸如syslog／audit log等日志数据；应用日志数据，包括诸如应用debug日志／性能日志等日志数据；

第三方监控脚本数据，包括诸如filemon／数据库访问计划等数据；

数据加载：通过采集Agent将源数据收集到消息队列中供计算引擎消费或者直接通过ETL工具将源数据持久化保存到HDFS上；

计算引擎：根据业务需求消费消息队列中的数据或者直接读取HDFS上的文件数据进行业务计算或者执行数据审计；

UI展示：通过数据可视化的方式，按照不同的业务场景需求，进行有效的数据展示。同时可以按照客户对于页面风格的喜好，对UI展示的皮肤进行特定开发对应，满足客户对于内部使用系统UI一致性的需求。

4) 日志分析架构

应用日志检索架构设计如下：

上图架构设计说明如下：

服务器数量

基于目标90TB数据以及一定的本地空间冗余，建议未来扩展到10台服务器

服务实例数量

单台物理服务器内存较大，建议运行两个JVM Node

每个JVM Node的JVM大小设置为32GB

索引数量

每个业务应用每天的日志为一个单独的索引

索引分片shard

为适应未来集群扩展的需要，建议shard数量初始化为10

未来建议运行二个或多个ES集群

索引副本replica

应用日志来源于NAS，本身已为备份的副本

基于服务器硬件和数据空间成本的考虑，建议设置ES中的索引index的副本参数replica=0

每天新增索引或冷索引可备份到HDFS中

创新点

整个技术方案采用了纯开源架构，并且采取与供应商合作开发的模式，使我们农信自己完全掌握平台开发内容以及开发方式，真正实现了自主可控。同时开发过程采取了同步开发同步上线的方式进行， 在测试环境中，针对每一个上线业务测试完成即上线提供功能使用，从而在后续的开发测试中，可以不断的汲取前期的开发经验，提高整体开发质量。

另一方面，由于整个开发采用开源架构，因此在组件功能完善方面，采用了开源社区的项目管理经验，针对每一个开源代码修改进行管理，并反馈开源社区。

在数据预测方面，引入AI理念，采用新AI研究成果，完成运维数据趋势预测及预警。同时利用大数据技术，通过日志分析，串联各业务关系。

后，整个大数据平台采用了云环境建设，目前状况为：

目前组成运维大数据平台的服务器分区数量达到60台，保障关键组件的高可用的同时提供实时数据处理能力：

CDH – 33台

Elasticsearch – 24台

门户 – 3台

未来考虑为Redis集群申请单独的服务器来运行

在平台建设过程中，根据接入的业务应用的实际数据负载情况，经历过共4次扩容

架构在私用云之上，平台扩容方便、灵活、高效，在平台扩容过程中，采用Rolling Upgrade的升级方式，始终未影响大数据应用的正常运行

技术实现特点

1.大数据平台

1.1 简介

本文用于指导进行多个大数据平台的迁移合并操作。从大的方面看大数据平台迁移合并需要关注的内容包括如下几个方面：

1、 版本确定和统一，这个部分重点关注多个平台版本不统一的情况，讲阐述如何进行版本统一和确定的工作。

2、 用户和权限，确定合并后的系统中用户和权限如何进行划分

3、 组件对齐，确定组件对齐和替代原则

4、 容量规划，确定合并过程中和合并后的容量规划

5、 数据迁移，数据传输和替换等

6、 服务器迁移，服务器在集群间迁移

1.2 版本确定和统一

如何两个集群是相同的发行版本，那么需要在迁移进行确保两个集群升级到相同的版本（包括小版本和补丁）。

如果两个集群的不是相同的发行版本（比如CDH和星环），则需要选择各自的版本让相对应的组件版本相同。考虑到不同的发行版本之间所有组件版本相同难以做到，因此这种情况下重点考察数据存储组件如（hdfs/hive/hbase等），可以不考虑运算组件（spark，storm等）。

如果是不同发行版本的情况，即使双方文档描述的组件版本相同，依然需要在正式迁移前，进行小数据量的迁移测试，以确认可以正常工作。

1.3 用户和权限

首先要对比两个集群除管理员账户外是否有账户重复？如果有重复的情况，需要在迁移进行前先进行用户名或者用户组名称的变更，以便避免在合并后出现异常。

在主集群，提前设置好新迁移过来需要的用户账户等，完成权限设置后，需要进行小数据量测试一遍，验证权限运行正常。

如果可能避免启用数据加密，如果一定有加密，需要针对加密数据进行专门的测试验证。

1.4 组件对齐

这个阶段主要是解决组件不一致问题，因为不同集群安装的组件可能不一致，在迁移前需要在主集群讲其他集群使用到的组件全部安装。

但是有一类情况，如果是不同的发行版本，可能会出现组件在其他发行版本没有。比如Impala一般只有CDH发行版本有提供，对于这种情况需要通过功能相同的组件进行替代，同样的这种情况需要专门进行测试验证。

1.5 容量规划

容量规划阶段要考察各个集群的数据量大小，是否都需要在合并后的集群里面保存。如果主集群可以保存全部的数据那么后继操作就会比较简单，可以一次传输完所有数据，然后再迁移服务器。

如果主集群现有容量无法保存全部数据，那么就需要分步迁移，即从子集群一次迁移少量数据到主集群后，清理子集群存储后，再从子集群退出服务器，然后将服务器迁移到主集群进行扩容。在扩容完成后再进行下一步的数据迁移工作。

如果分步迁移，需要在规划阶段将每步迁移哪些数据，哪些服务器都明确规划好。

1.6 数据迁移

根据不同的组件自身的数据传输接口进行数据迁移，如果系统同时还在工作，需要注意监控不要影响生产任务。

1.7 服务器迁移

服务器迁移首先需要根据网络等设计情况明确是否需要将服务器迁移到不同的路由器等，当子集群的数据迁移走后，需要将要进行服务器首先进行退服操作，然后再作为新服务器加入到主集群中。

2 日志解析

2.1文档说明

2.1.1 需求说明

日志主要指系统、网络、数据库以及中间件等在运行过程中生成的详细信息，通常是查明异常原因和支持更多运维决策的重要信息来源。具体使用场景包括：日志信息接入、日志信息解析、日志关键字检索、高级语法查询、历史日志保存与统计分析。

2.1.2 架构设计

2.1.2.1 总体架构

ElasticSearch是一个基于Lucene的搜索服务器，提供一个分布式多用户能力的全文搜索引擎，基于RESTful web接口，为用户提供实时的、稳定的以及高效的日志搜索能力。

通过垂直和水平扩展的双方式实现ElasticSearch集群的高可用和高性能

在需收集日志信息的系统本地部署Flume前置客户端

通过后置Flume将Kafka中的Event日志信息在解析后插入到ElasticSearch中

为不同类型的日志设置不同的index名称

相同日志类型每天生成一个单独的索引

2.1.2.2 日志检索与分析

根据实际业务类型，对不同类型日志的处理包含如下两个功能：

Event封装: 主要指将存在直接关联关系的上下行封装为一个Event进行后续处理，如Java跨行的Exception信息等

特征字段解析: 不同类型的日志包含不同的特征字段，根据业务提供的日志格式完成对特征字段的提取

在完成日志文件的特征字段解析后，将为日志建立索引并存储在基于Lucene的全文搜索引擎中：

目前日志解析模块支持如下形式的查询服务：

任意字符串的模糊查询

特征字段的完全匹配查询

高级语法的组合

2.1.2.3高级语法查询

query_string是ElasticSearch提供的一种高级查询语法功能，日志解析模块支持query_string方式的用户查询交互，包括：

特征字段匹配，如title:(quick OR brown)，book.\*:(quick brown)，_exists_:title等

正则匹配，如name:/joh?n(ath[oa]n)/等

日期范围条件，如date:[2012-01-01 TO 2012-12-31]等

大小范围条件，如count:[1 TO 5]，count:[10 TO *]等

支持布尔值的定义，通常用“+”符号表示一定存在，用“-”符号表示一定不存在，如查询条件“quick brown +fox –news”

支持AND和OR的条件组合

2.1.2.4SPL语法支持

SPL通过单行输入，在普通查询页面中，用户生成自定义查询结果，同时在图表和报表界面中，借助SPL完成log的数据提取和定义。基于SPL的高级搜索模式，可以方便用户通过直接在搜索框输入命令，实现较为复杂的关联分析、建立新字段、对字段进行数值运算等。

目前SPL支持的函数如下：

fields，支持字段的增加和减少

tail，显示后N个结果

head，显示前面N个结果

top，显示排名前N个结果

stats，提供统计信息，可以选择按字段进行分组

extract，从搜索结果提取字段的值对

timerange，指定时间范 围

eval，计算表达式并将生成的值放入字段中

2.1.2.5 标准日志开箱即用

运用乙方运维经验，针对通用的系统日志、中间件日志、数据库日志等进行了预定义，平台安装部署后即可支持。具体的支持类型如下：

1）解析规则-easlog

 2) 解析规则-system_err

 3) 解析规则-system_out

 4) 解析规则-verbosegc

5) 其他解析规则

日志解析规则 – 分隔符

 日志解析规则 – 键值对

查询页面

选择业务， 显示当前业务下所有日志，类型为多选

支持复杂的查询， 查询结果高亮，查询关键字另存为

6) 高级语法支持功能示例

正常查询输入字段名:值

 messageLevel:INFO OR messageLevel:DEBUG等价messageLevel:(INFO OR DEBUG) 

 AND关键字 组合条件查询 messageLevel:INFO | messageLevel:DEBUG 等价于 messageLevel:INFO AND messageLevel:DEBUG

用 “-something”可以去除结果中的something  等价于 messageLevel:(INFO OR DEBUG)  NOT DEBUG

 列名通配符 messageL\*:DEBUG 需以 / 区分

正则表达式

在表达式前后要加 ”/”

范围查询 TO关键字

2.1.2.6 交易追踪

ElasticSearch中对业务日志的存储有如下特性：

不同的业务系统对应不同的index

每天每个业务系统生成一个新的index

同一业务系统的不同类型的日志存储为不同的type

日志消息的来源包括主机名、文件名、文件所在路径将作为元信息关联在每一个Event中

通过对日志中特征字段的提取，如交易时间、交易码、交易流水等，可以建立不同日志之间的关联，以便在统一的日志分析平台中呈现一个交易的完整生命周期。

用户根据交易流水或其他特征字段查询相应日志中的交易，把此次交易的前后五分钟(或更长)日志全部取出，根据主机名称分组，展现所有和此次交易有关的日志， 并以上下文方式显示。

用户可以根据交易追踪的需要，对查询返回的信息进行组合，包括：

支持对需要查询的主机和日志类型进行自由选择

支持对日志条目所在文件的上下文信息的展现和向前向后翻阅

支持以时间轴的维度，对来自不同主机不同文件的关联信息进行统一展现

2.1.3 部署维护

以每台服务器的内存（128GB）和磁盘（10T）的情况考虑，为充分利用系统资源，在每台服务器上运行两个ElasticSearch实例：

安装目录分别为/opt/elasticsearch_1和/opt/elasticsearch_2

ES_HEAP_SIZE大小为32gb

每个ES实例读写4块磁盘

运行在tss用户下，通过bin/elasticsearch –d方式启动

2.1.3.1 检查 ElasticSearch运行状态

检查进程是否存在

ps –ef | grep elastic

检查集群节点状态

curl –XGET http:// 

检查集群索引状态

curl –XGET http:// 

2.1.4 数据接入

目前大数据平台共有两种类型的日志数据在接入后加载到ElasticSearch中，供用户查询与检索。本期项目我们将会接入的日志预计有如下：

3 Flume客户段安装部署方案

3.1 文档说明

3.1.1文档描述

本文档旨在说明部署Flume的前提条件及其必要性

3.1.2 前提条件

Flume运行要求JRE8或更高

如果是AIX平台，需安装bash运行环境

具备对需采集的日志文件的读权限，包括WebSphere GC日志、DB2 db2diag.log等

3.1.3部署流程

如果是AIX系统，申请root用户对JRE和bash进行部署；如果是Linux系统，使用Flume用户对JRE进行解压式安装即可

创建单独的用户（flumeusr）和用户组（flumegrp）对Flume进程进行启动和停止，以及其他维护操作

创建单独文件系统（/opt/flume）对Flume客户端进行解压式安装，并将该文件系统的属主和属组设置为Flume用户和用户组

正常情况下，操作系统普通用户具备对WebSphere GC日志、DB2 db2diag.log等日志文件的读权限，如果不具备，需将Flume用户添加到WAS和DB2实例的属组中

3.1.4文件系统要求

为了不影响系统运行，建议为Flume客户端提供单独的文件系统，大小2GB，创建在rootvg中：除介质本身的空间外，主要用于日志文件的存放

3.1.5 用户和用户组要求

目前已部署Flume客户端通过root对进程进行启动，因生产环境要求，对Flume客户端的操作维护需提前申请root用户

建议通过普通用户对Flume客户端进行启动和停止，以及其它操作如替换jar包等，方便日常维护

创建操作系统普通用户（flumeusr）及用户组（flumegrp）即可，没有其它特殊要求

项目过程管理

项目整个开发过程主要可以分为如下几个阶段：

1. 大数据平台搭建阶段

在该阶段，完成大数据平台的基础搭建过做，并且以small start理念出发，采用了小的资源完成了平台建设，从而快速推进后续功能开发。

2. 主业务数据分析

选取用户focus的业务场景——AFA日志分析入手，针对AFA的业务特点——流量大/日志文件保存路径杂/同时更新文件数目多/可打开文件句柄有限/日志数据内容不一，存在大量判断逻辑并需要按照需求进行日志合并进行开源组件功能改善及开发。在此阶段完成之后，前端采集Agent可以满足江苏农信所有业务逻辑需求以及性能需求。

3. 业务场景推广

按照客户需求，进行业务场景推广开发，在此阶段完成之后，智能运维大数据平台的基础功能完成，可以正常提供客户一期需求服务目标。

4. 大数据平台性能调优

随着业务场景的推广，进入大数据平台分析的数据也越来越多越来越复杂，因此，需要不断的对大数据平台性能进行调优工作。同时，提供大数据平台各组件的监控功能，保障大数据平台的稳定性。在此阶段完成之后，成熟的数据平台建设完成。

运营情况

目前组成运维大数据平台的服务器集群分区数量达到60台，保障关键组件的高可用的同时提供实时数据处理能力。同时在开发过程中，采用了small start的模式，因此，对于大数据平台的水平扩展能力以及数据balance也积累了经验。

接入包含AFA、ESB、前端等在内近20个业务应用的业务日志供实时查询与检索，有效的缓解了运维人员运维压力，通过新建的大数据日志分析平台，可以快速的查找业务错误点，并且进行相关的运维操作。

为ECC二期、安全态势等提供大数据平台支撑服务，同时后期农信所有的数据都会落到大数据平台，形成大数据湖。

项目成效

大数据运维平台建设后，主要在下面几个方面发挥了运维作用：

随着运维大数据平台的建设与深化，其采集和存储的数据类型不断丰富，改善数据相对独立现状的同时，已实际在为不同部门不同项目的大数据需求提供支撑，一方面显著提升了IT资源的使用效率，另一方面为未来不同运维场景的实现奠定了坚实的基础

业务应用日志集中之后，改变了传统的日志查询方式，应用维护人员可以根据自身问题分析的需要方便灵活地结合检索、过滤、统计等手段快速定位问题；通过实用性和先进性的大数据手段，不断从日志中挖掘更多的业务价值，在提高应用运维效率的同时，促进IT的业务价值提升

增强了IT运维的数据化手段，将如NMON/TWS/ODS等更细粒度的性能和作业分析数据，结合大数据方法与优势，为运维人员提供基础的查询和展现功能，持续丰富日常运维手段的同时，不断提升问题定位与分析的效率

经验教训

1. 运维大数据平台是由多个组件组合在一起工作的，每一个组件的健康运行都会影响到平台的稳定性，而开源的CDH版本没有对每一个组件进行良好的监控。因此，我们需要尽快针对每个组件开发一套监控程序，并且在组件出现Error时，及时告警，并将告警发送到统一事件平台，进行组件的运维工作。

2. 应用日志因各自建设的历史的原因，其日志中包含的内容可能会比较杂乱，在确定不影响业务需求的同时，应尽可能在早期对无效信息进行识别和过滤，减轻平台实时处理压力，提高资源使用效率。

3. 在业务运行过程中，对于资源的使用状况监控不够，从而导致经常发生临时扩容事件。虽然通过云环境可以快速的完成资源扩容，但是对于客户使用体验还是存在影响，并且对于客户的云环境资源的消耗也会产生压力，因此在今后的实施过程中，应该加强前期BA分析，对资源的使用分析更认真仔细，降低临时资源扩容需求。

本文由2018年度农村金融科技创新优秀案例评选组委会授权发表，转载请注明出处和本文链接。