数据中台最终的价值是通过用户层对数据的使用而体现出来的。数据中台的用户从部门划分来说，分为业务用户、外部用户、管理用户三大部分。业务用户是内部数据中台的最直接的数据用户，外部用户是指外部的数据中数据使用者。管理用户是指数据中台的管理员及开发用户。

n分类管理

用户分类管理的原则，数据中台的用户种类很多，对数据的访问权限、数据的质量要求、时效性要求、响应速度要求都是不一样的，因此需要对用户层的用户进行分类管理。

n访问控制

用户层是数据中台对外提供服务的唯一数据出口，也是证券公司的重要运营数据的访问接口，因此需要严格控制用户访问权限，并且定期的进行权限检查，收回过期权限。

l业务用户

n公司领导：

公司领导作为公司的决策者。数据中台系统为管理决策人员分配专门的系统资源，建立最为直观和方便的存取界面。数据中台系统将决策人员最为关心的信息主动发布到决策人员的访问界面上，简化信息访问的方式，使得决策人员在第一时间获得经营管理的各种重要信息和指标。

n部门/营业部领导

部门/营业部领导作为公司的中层决策者，需要更多的商业智能数据进行决策支持，通过对指定的主题、指标进行自定义的灵活分析和比较，包括自定义查询、自定义报表、多维旋转和穿透钻取等等。

n总部/营业部员工

主要指证券公司各业务部门、业务用户等，该类人员直接使用模块化的应用界面访问数据中台系统，生成或预览预定义报表，进行相对固定的查询以及多维分析。

通过应用层访问数据仓库的用户，此类用户对数据中台的数据服务层很熟悉，能够熟练使用SQL语句进行数据访问。此类用户也可能是上述三种用户，也可能是其他用户。

l管理用户

n平台管理员

平台管理员负责管理数据库，维护物理数据模型，维护备份与恢复过程，承担性能调整和负载管理工作以及容量的规范。

nETL管理员

ETL管理员负责监控ETL的运行状态、服务器资源，及时发现并处理错误，保证日常加载的正常运行。

n元数据、数据质量管理员

元数据管理员负责监控元数据的一致性、准确性，以及用户访问情况，根据业务用户的需求定制元数据。

数据质量管理员负责在生产环境监控已经配置的数据质量任务，及时发现数据质量的警告和报错信息，并发送给数据质量组进行质量分析。

n运维管理员

运维管理员主要负责监控数据库、ETL过程等出现的各种告警、出错信息，并通过相应管理办法及时解决问题。

n平台开发人员

平台开发人员主是模型设计、ETL开发、数据服务开发、报表开发等人员，需要对各层数据进行访问操作的权限。

数据中台中数据具有较高的商业性和保密性，系统整体安全是数据中台体系架构设计中重要的环节之一。数据仓库系统实际上是一个集网络、硬软件基础环境、数据库系统以及应用系统的综合体，面向最终业务用户的使用。整体的安全策略是设计多层次的安全机制来保护信息的私密性和安全性：

n对于恶意数据，采取机器网段隔离，从物理上杜绝，保证用户有控制的访问数据仓库的数据，防范数据仓库的数据被不正当的使用，以保证数据仓库数据的安全。

n对网络侵害及病毒侵入，使用监控工具，对网络的连接状况和利用情况进行实时的监控，及时发现网络是否遭受侵害及网络病毒的侵入。

n对非授权访问和越权操作，设立严密的系统安全认证与用户权限管理体系，并具备登录、审核以及资源访问的审计与跟踪。包括使用数据库登录时提供用户标识和口令建立会话；网络传输加密；使用NTLM、AD、LDAP等外部认证；利用数据库视图避免访问基表等措施。

n对操作系统出现异常，使用数据中台监控工具，对数据仓库的主机集群以及各应用服务器的操作系统运行状况和资源的使用情况进行实时的监控，及时捕获各平台操作系统的异常。

n为保证数据对外安全，数据恢复，数据库进行数据交换，并使用系统级、数据库级、备份与恢复等手段保证数据的安全。

n通过存取日志可记录使用者在数据库中的所有活动，对敏感数据的存取加以记录，以供系统管理员查看此信息。

考虑到数据中台系统每日都有几乎全部的证券公司生产数据在网络上传输，因此需要对数据转移涉及到的每个环节详细描述，以保证没有未加密的文本文件在企业内部网传输。

ETL数据传输安全

在数据中台系统中ETL主要包括：抽取、保存、加载、转换、导出四个部分，每个部分实现的工具不同，因此对安全的要求也不相同。

n抽取

对源系统的抽取工作主要由三种方式：

1、通过ODBC

2、通过专用工具

3、通过接口文件

不论是ODBC还是专用工具，都无法直接设置加密，可以在数据下载在ETL服务器上设置数据文件的访问安全机制。

接口文件的安全性由上游系统、以及前置机的安全策略保证。

n保存

在数据中台中，下载的数据会临时性的保存在ETL服务器上，ETL服务器设置访问安全机制、目录访问安全等手段来保证数据在ETL服务器的不被非法获取。ETL服务器上的数据不进行长时间保存，数据加载完成后即保存到备份设备上。

n加载

加载通过数据库专门的加载工具执行，加入数据湖。由于此过程数据以二进制传输，因此不需要加密。

n转换

由于采用ELT的加载策略，转换完全在数据中台内进行，不存在数据在网络上的传输，因此不需要加密。

n导出

按照导出目标的不同对安全的要求也不相同，导出数据使用专门的导出工具或ODBC完成，数据以二进制流的方式传输到目标服务器，因此不需要加密。

敏感数据

生产环境包含客户敏感数据，随着日后数据中台分析型应用越来越多，BI部门的成立，灵活查询用户的增多，客户的信息也可能会被各级业务部门检索到，因此在提供给灵活查询的用户的访问视图中，客户的姓名、联系方式、身份证号码等需要做特殊的安全处理，只有特殊级别的业务人员才能访问。

除了在生产环境数据迁移的安全性需要考虑，还有数据从生产环境迁移到开发、测试等环境，考虑到生产环境有些数据非常敏感（如：客户姓名、联系方式等），因此，需要对这部分数据进行安全处理，在不影响应用开发、测试的情况下通过变形或加密等操作来保护数据。

数据库提供一系列的数据保护机制保证数据在意外事件中数据能够得到保护和提供恢复能力。数据库对数据仓库的数据保护和高可靠性，进行了多个层级、全方位的考虑和设计，包括以下几个方面：

n系统级数据保护

w磁盘阵列的冗余保护

wClique技术

w同城异地机房灾备

n数据库级数据保护

w副本策略

wFallback技术

w数据库加锁技术

wJournal技术

w其它数据保护技术

w备份与恢复

即对数据的存取控制。存取安全性在数据库数据仓库中包括以下几方面：

n数据库的存取安全

n物理系统存取安全

n租户管理

n系统审计

n安全制度

数据库是C2安全级的关系数据库管理系统，从以下几个方面提供安全机制保证数据不被非法使用：

n物理安全：从空间上限制非法用户接触数据仓库系统。

n用户登录控制：从主机和数据库系统两个层面设置注册管理机制，针对用户/用户组设置是否允许登录，以及允许从哪些客户机（IP地址）登录；可以设置口令格式、口令过期规则、口令重复使用规则、允许口令错误次数等。

n数据存取控制：对所有的数据库对象（包括数据库、表、字段、视图、宏、存储过程、触发器等）可以设置相应的权限。同时也可以利用视图、宏、存取过程限制用户对数据的访问。对安全性要求高数据进行加密存储，增强数据保护策略。

通过这些安全措施的建立和设置，建立完善的权限管理，用户只能访问到允许访问的数据，从而保证数据不被非法使用。

数据库用户权限设置一般是由DBA来完成的。

对于数据的存取应以“需要知道”为基础。如果没有限制，可能会造成数据不当使用；但是如果限制太严格与繁琐，就会使信息难以利用，最终业务用户和IT用户在实际使用中感到过分繁琐，安全效果不好。因此需要DBA进行权衡，掌握一个度。

要建立一定的安全机制措施来确保数据存取的过程是在一定的安全规则下执行，而且系统能够记录哪些用户、哪些时间在访问哪些数据。在此同时，程序应尽可能有效率，不要对DBA造成管理负荷。因此对用户进行分级的权限管理十分必要。通常设置如下等级的数据库用户：

nDBA

在数据库中有特殊的权利，有建立和删除数据、视图和宏的能力。DBA可以创建新的数据库，调整数据库空间大小；备份和恢复数据；创建和删除用户，赋予和收回用户权限

n最终用户

这些用户包含所有业务用户的用户ID，即所有非IT技术人员的用户，他们只对VIEW有Select的权限，没有其它权限。

nETL数据加载用户

这些用户包含所有对所有能够执行数据转换、备份工作的用户。只有这些用户才对系统数据（如SDATA、PDATA及VIEW）有更新的存取权。

受权体系

对于应用访问的安全，其主要设计体现在用户安全认证与权限分配管理。

前端用户管理包括两个部分，用户(User)和用户组(Group)信息管理。

用户(User)管理

用户(User)管理包括用户信息的维护、用户组的分配以及用户特殊功能的权限分配等。

在对用户进行权限分配时，采用基于角色控制（RACB）设计引入角色(Role)的概念，所谓角色，就是一个权限集合的定义，一个用户可以赋予多个角色，每个角色都与之对应的用户类，用于定义对应用和数据的访问权限。

用户组(Group)管理

用户组管理包括用户组创建、用户组修改、用户组权限分配等。

用户组是一组具有使用相同角色的用户群。

用户和用户组的关系是一个用户组可以包括多个用户，一个用户只可以属于一个用户组。

用户组权限管理可以对用户组进行角色分配，而用户组内的各用户可继承该组的角色分配；此外，各用户也可单独定义超出该组角色之外的个性化角色。

对于证券公司各业务用户的安全设定与权限划分，将采用多组分层的策略，即首先按照行政组织结构分组。在同一部门的分组下，将按照管理决策层、业务层、信息分析层等职能结构进行分层；同时也可根据自定义的模式对同一部门的业务用户进行分组。这样，就可以灵活地对不同部门或同一部门的不同类用户进行分组和权限的划分。

系统用户在进行密码的设置中，而且密码需要定期更新，以下类型的密码系统认为是非法的，包括：

n长度过小，小于六位的密码。

n和用户名相同的密码。

n密码不包含大小写、数字、特殊字符

n使用重复字符作为密码等。

这种手段保证了用户设定密码的一定的复杂度，增加了黑客破解密码的难度。保证了系统的安全性。

最后，对前端的用户访问还可进行访问上的审计。即通过前端应用服务器对用户的前端应用的访问操作进行记录，包括用户登录的终端IP地址，用户访问的时间，用户访问的功能应用，用户使用的查询条件，用户查询返回的结果情况等，这些信息用来完成对前端用户访问的审计，从而可以及时发现非法的访问操作，屏蔽不合法的用户对系统进行的访问。

数据中台系统以数据中台建设为核心，与通常的源业务系统相比，它所处理的数据量很大，涉及到数据的抽取、加载、集成、清洗等工作较复杂，主要支持对数据的计算、汇总、统计等分析型工作。数据中台的网络、主机、系统的部署和运行结构都较复杂；在正常的业务操作时间，必须保证系统不间断运转。因此，数据仓库运维管理的目标是保证系统的正常运行，及时发现和修复运行错误，不断调整和完善系统配置，预防故障和灾难的发生。运维架构提供了支持整体数据库数据仓库架构的服务，以保证所有的数据都正确和及时地移动，同时保证系统可以从不同规模的服务中断中恢复。

运维管理职责包含了如下环节：

1.环境准备：根据实际情况合理规划设计数据中台资源配备要求，证券公司运维管理部门根据对数据中台运行环境的要求，准备物理地点条件和运行准备条件。

2.系统安装部署：数据中台系统的软硬件安装及配置。

3.系统运行/业务操作：系统正常作业，业务部门在运维管理部门的配合下进行业务操作和系统使用。

4.系统维护：运维管理部门对数据中台系统进行日常维护，包括网络/系统监控、服务管理、配置管理、备份管理等。

5.运行故障：在系统运行和维护过程中，随时对系统运行状态进行监控，识别运行故障。

6.故障排除：发现故障时，通过故障切换管理、恢复管理等措施，进行故障的排除。

7.版本变更：在系统运行和维护过程中，会进行系统的新版本投产、BUG修复、硬件/系统软件升级、应用系统升级等操作。发生版本变更时，应返回流程的开始阶段，从运营环境准备的步骤开始考虑，实现该变更。

8.运行报告：周期性对数据中台进行全面检查汇总，提前感知、预估系统问题和下阶段工作重点。

系统运维流程

数据中台的运维目标是：保证数据中台生产环境系统的安全、稳定、高效、高质量的运行，通过自动化的手段及流程化的管理机制，实现数据中台的设计目标。

在数据中台的运维管理的设计中，必须全面考虑到业务范围、功能、性能等各方面内容，同时与现有的IT标准相一致。主要设计原则应包括如下要点：

n规范性：

运维架构的设计应符合规范性，包括与成熟的相关工业标准相符合，以及与证券公司现有运维环境的标准相符合。

n重用性：

数据仓库项目的运维架构必须考虑与证券公司现有运维环境的一致，最大程度的重用现有的运维的功能和组件，保护现有投资。

n集成性：

运维架构的设计应当是集成的，而不是孤立的功能单元，避免功能的重叠和冗余。未来数据仓库的运维架构还应提供与证券公司IT运维环境进行集成的接口。

n高效性：

运维环境的设计目的是保证系统正常、高性能的运行。运行架构本身提供了设计方法和原则，应用这些方法和原则的设计时，应具备高效性，而不是增加系统运行的压力。

数据中台的数据库用户与权限，主要分为两部分：

一部分是在开发阶段设计并规划好的，并且伴随版本部署到生产环境，这部分用户和权限是固定的，此用户基本上是系统批量执行程序所使用的用户，因此基本上不会经常变化。

另一部分是业务人员和分析人员的用户，这部分用户经常做灵活查询，因此权限会经常变化，同时可能会出现多个部门或者业务人员使用一个用户的情况，因此需要进行专门管理。

数据库的用户和数据库概念类似，用户与数据库的唯一区别是：用户具有一个帐号，可以通过此帐号来登录系统。因此，用户有一个口令，而数据库是没有口令的。创建和删除用户的方法与数据库的操作类似，其他日常操作包括调整用户口令、优先级、SpoolSpace空间等（一般不给用户分配Perm空间）。以上操作需要使用DBA或同等权限的用户完成。

数据库主要用户的介绍：

nDBA用户：系统管理员用户，记录数据库中各种对象（数据库，用户、表，视图等）的元数据信息。DBA中的信息至关重要，当系统发生故障时，需要首先恢复DBA；

nDBCMANAGER用户：系统监控用户；

nSYS_CALENDAR数据库：此用户用来保存系统日历表和视图；

nSYSADMIN用户:SYSADMIN是具有最小表存储空间的系统用户；

生产主要用户说明：

nHYSECEDW用户：管理员用户，权限类似DBC用户；

nDWADMINUSR用户：仓库管理员用户，拥有仓库内所有库的权限（除DBC系统权限）

nDWQUERY用户：查询用户，对各个库拥有查询权限；

nDWARC用户：备份恢复用户，对所有数据库拥有备份恢复权限；

nDWJOB用户：日常加载用户，主要是源数据加载；

nDWARCUSR用户：基础层、源数据层历史数据归档操作用户；

nDWXXXUSR用户：各集市对应用户，对应各集市库有操作权限；

nDWMETAADM用户：元数据系统管理员用户

nDWMETAUSR用户：元数据系统查询用户

nDWUDFADM用户：SYSLIB目录UDF管理员用户，具有UDF的增删改权限

nDWMONITOR用户：数据系统监控用户

nDWETLADM用户：ETL系统库管理员

nDWETLUSR用户：ETL系统库查询用户

nDWDQADM用户：DQ系统相关数据库的管理员用户

nDWDQUSR用户：DQ系统相关数据库的查询用户

nDWBarUsr用户：数据库备份恢复用户

l数据仓库容量估算方法

数据仓库系统容量规划在整个数据仓库的生命周期内会多次进行。首次容量规划常常由于系统设计未完成、输入参数不准确而导致误差较大，因此系统设计完成和上线运行后，需定期对系统进行回顾和检查，并根据系统的运行状况、用户服务标准SLA(ServiceLevelAgreement)、数据量与并发用户数的增长趋势等，定期对系统进行更为精确的容量规划。依据项目发展的阶段不同，容量规划可以采用不同方法：

n源数据估算法

根据数据调研的表筛选结果统计源系统数据量，以源系统数据量为输入，估算数据湖、基础数据区和汇总数据区容量。由于估算以数据库为单位进行，粒度较粗，误差大。此方法仅在总体架构设计阶段使用。

nLDM（逻辑数据模型）估算法

统计LDM主要实体的记录数、增长率和变动率，以LDM实体为单位进行估算。由于模型物理化后，PDM与LDM并不一致，采用这种方法也存在误差。此方法适用于LDM设计完成、PDM未完成的阶段。

nPDM（物理数据模型）估算法

统计PDM主要表的记录数、增长率和变动率，以物理表为单位进行估算，准确度高。此方法适用于PDM设计完成后，可以准确统计出客户、帐户、交易记录数和增长率、变动率的阶段（如：适应性测试期间）。

目前证券公司数据仓库处于总体设计阶段，因此容量估算采用源数据估算法进行。在PDM设计完成后，将使用PDM估算法，并依据数据保留策略，进行准确度更高的容量估算，以确定系统稳定期的容量。

现阶段采用的源数据估算法主要包括如下四个步骤：

1.估算原始数据量

依据数据调研的结果估算源系统初始和增量规模，由于采用源数据估算法，需要直接统计源系统数据容量而不是记录数。

2.计算磁盘空间需求

根据数据文件压缩比计算源系统数据文件存储区对ETL服务器的磁盘空间要求。

根据最小磁盘空间计算公式支持计算上述数据量需要的数据仓库磁盘空间。

3.计算所需的服务器存储空间

根据2650MPP海量并行处理系统配置确定所需服务器的存储空间。

4.目前容量现状及其对策

评估目前容量现状，给出解决方案。

l计算磁盘空间需求

nETL服务器

ETL服务器存储初始和日常加载的源系统数据文件，由压缩文件大小和解压缩后文件大小两个因素确定存储需求。

n数据仓库服务器

对于数据仓库服务器，在基于原始数据量估算最小磁盘空间需求时，需分别考虑以下因素：

1.RAID因子：当使用RAID1时，RAID因子为2；当使用RAID5时，RAID因子与具体使用多少磁盘组成一个逻辑卷有关，在数据库中，一般使用4个磁盘组成一个逻辑盘，故此时的RAID因子为1.33。一般建议使用RAID1，故此RAID因子为2。

2.磁盘格式化因子：当存储磁盘进行格式化后，会造成磁盘一定的浪费。所以，磁盘实际的使用率大概是91.5%，磁盘格式化因子1.093。

3.数据库缓冲空间因子：数据库的索引、额外的物理存储（保存数据记录所需要的额外空间如记录头、尾）空间和工作所需要的缓冲空间，一般的经验值为1.3~1.65。工作负载比较单一，任务简单时，此因子可以选择较小的值，工作负载很重，任务比较复杂时，可以选择较高的值。考虑到证券公司数据仓库系统源系统较多、ETL任务复杂，这里取1.65。

4.数据库压缩因子：数据库提供多值压缩技术，可对用户数据中的重复值进行压缩，从而减少所需的物理存储空间，同时可以减少数据库工作时的I/O次数，进一步提高性能。此压缩因子的经验值为0.7～0.9。在此取0.8。

5.数据库Fallback因子：FALLBACK是数据库为加强整个数据仓库系统的数据安全性而提供的项。当采用FALLBACK时，数据库将自动为每条数据记录在不同集群(Cluster)的存取模块处理器（AMP）所负责的物理磁盘上保持一份拷贝，这样，当原磁盘或其对应的存取模块处理器（AMP）发生故障时，系统仍能通过相互备援的存取模块处理器（AMP）对外提供正常的服务。现在RAID技术越来越先进，通过RAID技术来提供的数据安全性也越来越高，因而采用FALLBACK选项的场合已不多。在此取1。

数据库磁盘空间需求=原始数据量*RAID因子*此盘格式化因子*数据库工作空间因子*数据库压缩因子*Fallback因子

=RawData×2×1.093×1.65×0.8×1

=RawData×2.89

对于系统的性能与负载管理，首先应建立一套服务协议，包含以下内容：

数据的时效性，具体表现为数据从源系统转换到数据仓库中的时间。一般如果要求是T+1（即转天早上9:00能够看到应用），至少是6-7个小时；

需要强调的是，为了满足服务协议的要求，可能牵涉到人工、监控、修正以及系统资源等方面的成本。

服务协议应该从业务方面进行判断，例如，对某个级别响应时间的要求，其业务价值为多少。服务协议的设置和维护必须从业务的角度出发来考虑。确定好服务协议后，必须建立一套规章制度来监控，并报告各种意外情况。

为了确保服务协议中所要求的性能，对本系统的负载要进行管理和监控，以确保具有更高级别的工作任务/用户具有较高的优先级。

对数据中台系统来说，第一期的业务用户不多，灵活查询的要求也不多，可能还不容易出现性能问题。但是日后随着用户越来越多，应用也越来越多，因此负载管理将是非常必要的。数据库针对企业级数据仓库有专门的混合负载管理工具，可以设置不同用户在不同时段对硬件设备资源如CPU的使用百分比，但是目前证券公司购买的数据库2650节点以及数据库13.10版本的数据库，尚不能支持混合负载管理，因此，从管理上来控制性能与查询是数据中台性能管理的主要手段。

本系统中包含一个覆盖整个数据仓库系统的实时直观的系统监控平台，能够完成以下功能需求：

n网络管理

n系统管理（数据库服务器设备）

n数据库系统（数据库）管理

n数据仓库相关应用及工具管理

w中间服务层管理（OLAP与BI工具）

w元数据管理

w数据质量管理

w数据加载服务管理（ETL）

n存储管理

数据库使用Viewpoint集中管理所有的数据库系统。

优点：

n简单直观的WEB方式访问管理数据库系统

可以从任意地点通过WEB访问数据库系统。

n为业务人员提供自助服务功能

减少业务人员对DBA的依赖，提高工作效率。

n系统状态监控和管理

集中管理多个数据库系统。

检测长期和周期性趋势。

通过“倒带”查看历史运行情况，进行系统分析和调试功能。

下图是数据库viewpoint逻辑架构图。其中Viewpoint服务器安装在数据库机柜中。如果客户没有足够的空间，可以将viewpoint服务器放置到非数据库机柜中，但是这可能会对系统性能有影响。

n报警

当系统处于不可用状态时，DBA可以及时做出反应。可以针对CPU、I/O、结点状态、空间、会话数定义监控规则，出现异常后以电子邮件、寻呼、SNMP包、报警日志等方式通知管理员。

n管理

DBA以简单、易用的图形化界面维护用户、数据库、表；授权；进行空间管理；工作负载管理。

n历史趋势报告

根据DBA设定的条件生成资源利用率、工作负载分析报告，使管理员了解系统一段时间以来的资源利用情况，以便制订相应的容量计划。

n性能监控

帮助DBA全面、及时地了解系统。以数字化仪表盘形式实时反应系统状态；监控系统会话；终止会话；动态改变会话优先级。

数字化仪表盘提供一个当前系统状态单一的视图，视图中包括各种资源的实时数据和趋势曲线。在视图的上部有状态灯显示AMP、PE、NODE和ByNet的状态，绿灯表示对象正常运行，红灯表示对象停止运行。

n配置信息

nNode、Disk、IO、PE、AMP、ByNet汇总信息

在Summary面板中显示了系统监控的基本信息（Node、Disk、IO、PE、AMP、ByNet）。包括各个性能的均值，最高值，最低值。其中，绿色表示正常；黄色表示高利用率；红色表示异常警告信息。“Chart”按钮提供了以图表的形式显示监控的情况。

nAMP或Node的详细信息

在Resource窗口可以监控每一个AMP或Node的详细信息。

n当前会话信息

会话窗口是DBA最常使用的Pmon功能，通过此窗口可以观察到当前所有会话（可以按节点、AMP、PE分类）信息，会话涉及的锁情况，杀掉指定会话，每个会话当前执行的SQL语句甚至是每个SQL语句执行的步骤。

数据加载系统提供抽取/转换/加载服务，从而实现数据仓库的载入。在数据中台系统采用数据库DWAutomation实现整个ETL流程，管理员可以通过ETLAdmin、ETLMonitor两个Java程序监控下列信息：

n监控ETL服务，主要监控的信息如下：

数据抽取状态

数据加载状态

数据转换任务状态

数据卸载状态

ETL服务运行状态

各阶段运行汇总

n监控ETL重要日志

n作业监控：作业状态存放在数据库数据库的ETL知识库中，可以通过ETLAdmin工具实现对JOB日志的监控。日志信息主要来自两个表：

表一：ETL_job_Status，主要监控信息如下：

字段名

说明

ETL_system

ETL系统

ETL_job

ETL作业名

JobSessionID

作业Session号

TXDate

数据日期

StartTime

作业开始执行时间

time

作业结束执行时间

jobStatus

作业状态

作业状态有：READYPENDINGRUNNINGDONEFAILED五种状态。

表二：ETL_Job_Log，主要监控信息如下：

字段名

说明

ETL_System

ETL系统

ETL_Job

ETL作业名

JobSessionID

作业Session号

ScriptFile

脚本名

TX_Date

数据日期

ReturnCode

返回码

StartTime

开始时间

Time

结束时间

除了通过JAVA客户端程序监控ETLAutomation的运行情况，数据中台项目还将在Portal部署ETL流程调度及ETL服务的监控。

数据仓库提供上游业务系统各类数据，了解各业务系统运行情况有利于更好的维护运营数据中台，提前发现各业务系统瓶颈及问题，使业务运行更加顺畅。业务系统主要监控内容包含：

n运行环境：

基础资源

实例运行状态

访问记录

n数据仓库请求

各业务系统请求统计

请求响应时间

数据仓库的特点是数据量很大，因此数据备份是数据仓库的重要的安全管理和运行维护工作。目前证券公司没有购买专业的备份工具，因此备份工具主要采用ABU软件和ARCMAIN工具结合使用。体系架构图如下：

图表3‑1备份恢复体系逻辑架构

由上面的备份/恢复架构图可知，整个备份/恢复操作纳入ETL流程调度控制下，实现统一的监控和管理。

EDW各数据对象的备份策略，以及备份数据量及其时间窗口的估算如下表所示：

备份对象

备份方式

备份频率

保留周期

全量

日增量(GB)

时间窗口(小时)

源系统数据文件

增量

日

数据湖

增量

日

基础数据区

全量

周

集成数据区

全量

周

历史数据区

全量

周

中间汇总区

全量

周

应用集市区

全量

周

数据质量检查库

全量

日

2月

10G

基本不变

ETL库

全量

日

2月

元数据管理库

全量

日

2月

数据库数据字典

全量

日

2月

1G

基本不变

ETL日志

全量

月

2月

7G

基本不变

ETL等程序

全量

月或发生变更时

2月

周期性备份数据和HA基本保证数据备份一致性和故障转移，为能在极端情况下也能够快速应对故障场景，需要灾备恢复演练机制保证出现故障时启用应急方案。

系统名称

灾备预演时间

恢复用时

优化建议

CDH

20210831

1天

xxx

xxx

xxx

xxx

xxx

数据仓库的容量是有限的，而数据是无限的，如何用有限的容量保存无限的数据，这就需要考虑仓库内的数据的生命周期问题。衡量数据生命周期管理质量的标准就是：对数据历史的的访问率尽可能的高，数据恢复的几率尽可能的低。要达到上述标准就需要遵循一定的策略以实现之。

数据生命周期管理的主要对象就是数据仓库的数据服务层中的数据，尤其是特指基础数据区和历史数据区这样的包含历史信息的数据区域。数据仓库的数据服务层的数据备份策略，以及数据从基础数据区向历史数据区迁移的策略，必须完全基于数据生命周期的指导来完成，因此证券公司需要制订数据仓库的数据生命周期管理的整体策略。

数据生命周期管理的主要有以下三大类需求驱动：

1.满足各部门业务分析的需要

2.满足监管法规遵从、审计与投资者情况披露的需要

3.满足基于历史数据为客户提供服务的需要

n数据需求第一原则：数据生命周期管理必须基于三大主要需求，即：监管、业务分析、客户需要。不能出现寻找所需数据的时候发现数据已经销毁的情况。

n分类细化的原则：由于不同的需求对数据的生命周期策略是不一样的，因此就算是对仓库基础数据区中的同一张表，可能会应用不同的数据保留策略。

n容量、性能的最佳配置原则：虽然有数据的保存周期需求，但是要综合考虑系统的容量和性能的最优管理原则。访问频率比较高的保存在基础数据区中，访问频率中等的数据可以保存在历史数据区中，访问频率比较低的数据可以保存在磁带中。

n数据文件

数据文件特指从上游源系统抽取过来的数据文件。数据文件的保留期限一般是7年，保存在磁带中。

n数据湖

数据湖的数据在线保留6天，最多不超过1个月。归档保留7年。

n基础数据区

基础数据区总体策略是在线保留2年，近线管理数据移植到历史数据区中，归档保留7年。但是在线保留策略可以按照主题、业务分类再进行细分。

n集成数据区

集成数据区的数据在线保留是当天，没有近线和归档的管理。

n历史数据区

历史数据区的数据在线保留是7年，历史数据区在线和近线是统一的；归档保留策略是7年。

n中间数据区

中间数据区的数据保留策略基本上是当天，如果有历史的话，根据具体的汇总表设计和业务需求具体制订。

n应用集市区

应用集市区的数据保留策略基本上是当天，如果有历史的话，根据具体的集市区设计和业务需求具体制订。

l在线管理

在线数据是指可以被快速访问的数据。通常是放在数据库中，查询级别较高的数据，也是最经常访问的数据。

在线管理是管理在线数据的查询需求，并负责定期把数据进行向近线和归档迁移的管理过程。

l近线管理

在线数据是指可以被访问的数据，但是响应速度不如在线管理，性能通常会被限制。通常是放在数据库中温度较低的区域或者另外的低性能大容量的数据库中，是查询级别较低的数据，也是不经常访问的数据。

近线管理是管理近线数据的查询需求，并负责定期把数据进行归档迁移的管理过程。

l归档管理

归档数据是指不能直接被访问的数据，如果有查询需求需要进行数据恢复到库中再进行查询。响应速度最慢，性能通常会被限制。通常是放在磁带中或者光盘中，是查询级别最低的数据。也是最不经常访问的数据。

归档管理是管理归档数据，如有查询需求进行归档恢复操作，并负责定期把数据进行销毁的管理过程。

l销毁管理

销毁数据是指已经不会被访问的数据。

销毁管理是销毁归档数据中已经不被使用的数据，并回收存储介质的过程。

按照数据库数据仓库的建设方法论，数据仓库应该提供开发(Development)、集成测试(SIT)、用户接收测试(UAT)、准生产环境（PPT）、生产运行(Production)五套环境。除此之外，在数据库项目经验中，还会保留一套准生产环境。目前证券公司的数据库采购了2650服务器用作生产和准生产环境，开发、测试环境使用虚拟机。其中生产环境有独立的数据库服务器和ETL服务器、应用服务器；开发、测试环境都采用虚拟机环境。

系统环境配置的目标是：通过为各阶段设置不同的环境，规范数据中台的开发、测试、生产流程，达到提高生产环境的数据仓库的数据质量、程序质量以及数据安全性，提高数据仓库的可用性与可信度，以及保障证券公司的信息安全的目标。

开发、测试、生产之间的系统环境的配置原则是：

n流程第一原则

环境之间的管理，数据同步、程序同步等操作，都必须严格按照数据仓库开发、测试、生产的流程进行。杜绝弱化流程、简化流程、临时流程等不规范的操作出现。

n环境隔离原则

每个环境由专门的团队负责，开发团队负责开发环境，测试团队负责测试环境，运维团队负责生产环境。环境之间的程序交换必须通过版本发布流程，通过版本控制工具进行。环境之间的数据交换必须通过数据迁移流程，生产环境的DBA负责进行。

n程序单向流动原则

数据仓库的程序（含程序代码、控制文件等），只能从开发到测试再到生产这样的流程，不能反过来，也不能跳过其中某个环境。

如果因为某个生产事故、紧急bug等造成必须在生产环境修改程序，那么修改完毕后，代码版本发布流程也还必须再走一次，直到覆盖生产环境。

环境之间的程序提交，必须通过版本控制工具SVN进行，不能人员私下进行交换。

n数据单向流动原则

由于证券公司没有专门的测试部门负责生成模拟测试数据，因此数据中台在开发和测试阶段会需要生产数据进行模拟测试，因此，每个版本投产后，需要从生产环境提取样本数据供其他俩个环境使用。抽取数据过程中注意两点：1：敏感信息需要脱敏处理，隐去客户姓名、联系方式等信息，2：考虑到其他环境的空间比生产要小，因此不需要拿到全部数据，可以取一个分支机构即可。模拟测试用样本数据的抽取和分发由生产环境的DBA负责。

开发环境是提供EDW及相关应用开发人员进行程序开发、单元测试的环境。也是版本最多的环境，除了当前正在开发的版本，还应该建有与生产环境、测试环境一致的版本，用来测试和发布补丁程序。每投产一次，开发环境中的生产版本要与生产进行数据同步和程序同步。

准生产环境是集成测试环境，测试团队用来进行集成测试，一般集成测试环境有两个版本，一个是当前正在测试的版本；一个是与生产环境一致的版本，用来测试补丁。每次生产环境投产，测试环境中的生产版本要与生产进行数据和程序同步。

生产环境是EDW的业务运行环境，是各个环境中安全、稳定性、容量、性能要求最高的环境，有且只有一个版本。生产环境版本的发布必须严格按照版本发布流程来进行。系统运维人员对生产环境有一切权限，业务人员根据各自不同级别对生产环境有读权限，除此之外其他人没有生产环境访问权限。严禁开发、测试人员在生产环境进行开发与测试。生产环境每做一次版本投产，可以抽取样本数据与程序由生产环境管理员分发给其他环境使用。样本数据需要进行敏感信息处理。