近年来，随着金融科技的迅猛发展和数字化转型的持续深化，银行业既迎来重大机遇，也面临严峻挑战。在数字经济时代，数据作为关键生产要素，已成为银行的核心战略资产和竞争优势所在。然而，当前众多银行在数据管理和应用领域仍存在显著短板。例如：

       与此同时监管也高度重视银行业数据治理工作，陆续出台了一系列政策文件，对银行数据治理提出了明确要求:

       《银行业金融机构数据治理指引》（银保监发〔2018〕22号）： 明确了数据治理的定义、目标、原则、框架和主要内容，要求银行业金融机构建立健全数据治理体系，提升数据管理和应用水平。

       《关于银行业保险业数字化转型的指导意见》（银保监发〔2022〕2号）：提出要加快数据治理体系建设，提升数据质量，加强数据共享和融合，深化数据应用，为数字化转型提供数据支撑。

       《商业银行数据安全管理办法（征求意见稿）》：对商业银行数据安全管理提出了具体要求，包括数据分类分级、数据安全保护、数据安全事件处置等方面。

       《金融业数据能力建设指引》（银发〔2021〕310号）：明确了金融业数据能力建设的总体要求、主要任务和保障措施，为金融机构提升数据能力提供了指导。

       《数据管理能力成熟度评估模型》（GB/T 36073-2018）：提供了数据管理能力成熟度评估的框架和方法，帮助金融机构评估自身数据管理能力，识别差距，制定改进计划。

       数据治理和数据仓库建设是数字化转型的必经之路，对于提升银行数据管理和应用水平、增强核心竞争力具有重要意义。本项目将帮助金融机构构建完善的数据治理体系，打造统一的数据仓库平台，提升数据分析应用能力，为金融机构高质量发展提供强有力的数据支撑。

       数据仓库架构规划参考架构设计规划方法论，如下图所示：

       按照此方法论体系，可以指定出数据仓库数据架构规划的基本工作内容，如下图所示：

       各部分内容以下进行简要说明：

1、调研分析

       访谈：如领导访谈、业务部门访谈。提供访谈大纲，通过问答方式了解总体业务战略、具体的业务问题、对未来数据仓库数据架构建设的要求。

       访谈的内容一般是一些开放性的问题，如：

       企业的业务发展总体战略，IT架构如何满足并推动业务战略的实现？

       IT架构，特别是数据架构层面，最迫切的问题是什么？

       进行数据仓库建设，主要的驱动力是什么？

       调查问卷：通过提供调研问卷，对数据架构的详细信息进行深入的了解。相关的IT人员填写调研问卷，咨询顾问对调研问卷的反馈信息质量进行及时的跟踪。

       调研问卷是基于业务顾问在大量实践过程中总结的经验而设计，示例如下：

       最终得到一个数据的评估结构和相关的报告，示例如下：

2、目标架构设计

       首先要定义数据仓库的架构设计原则，一般基本的原则包括：

       不同的架构原则如何确定优先级，可以在规划的开始过程中进行调整。原则一旦确定，就应该以此原则来指导后续的架构设计。

3、数据仓库数据架构规划建议

       数据仓库的架构一般都是借鉴目前较为成熟的数据分层架构，我们提出如下“数据仓库数据架构”如下图所示。

       数据仓库采用得到业界普遍认可的6层架构：

       贴源缓冲层是为了数据加载和转换的需要而设计的，不提供对外服务，源系统下载数据通过源系统或数据交换平台加载到缓冲层。

       贴源全量层基本按照源系统的结构来保存数据，用于方便快速地支持需要按源系统数据结构提供历史数据的分析型应用或时效性比较高的应用。

       数据标准层是对贴源层的数据进行名称、码值、单位上的标准化，同时支持数据去重和数据剔除，基本数据结构和贴源层保持一致。

       数据模型层模型采用面向主题的设计方法，有效组织来源多样的业务数据，使用统一的逻辑语言描述银行业务，是数据管理的分析工具和交流的有力手段；保证数据的一致性，是银行实现业务智能的重要基础。

       共性加工层是数据的预加工、预汇总和预关联，是对应用的共性化提炼，而不是面向某个特定的应用。共性加工层包括汇总数据和指标体系的坚守，在共性加工层建立后，数据仓库对外提供了多层次的数据访问支持。对于数据仓库的访问建议优先考虑共性加工层，对于共性加工层能够满足的需求，从共性加工层支持；对共性加工层不能满足的需求，再从基础层来支持。

       数据集市层直接面向各类型的应用，利用数据仓库内的数据，直接加工各类型的应用结果数据。数据集市可以是面向部门的，也可以面向特定类型的应用。

       数据仓库的数据是下游“分析性应用”和“业务应用系统”的唯一数据来源。

4、数据仓库平台技术架构规划

       数据仓库平台的技术架构规划是基于数据仓库数据架构规划而进行的，包括以下的几个部分：

数据仓库容量规划

       数据仓库内可以划分为6个数据层：贴源缓冲层、贴源全量层、标准层、模型层、共性加工层和数据集市层。不同的层存放不同形态和不同周期的数据，需要根据不同的情况，计算出不同层所需的数据容量，并依此为基础计算出整个数据仓库当前的数据量和3-5年的中长期数据量，便于确定数据仓库硬件平台的配置。

数据仓库性能规划

       数据仓库的性能主要包括三个方面的性能：

数据备份容灾策略

       数据仓库数据的备份是数据仓库技术架构规划的一个重要内容。数据仓库的数据备份包括以下两个主要方面：

       数据仓库的容灾策略。数据仓库一般都是采用数据容灾方式，而不采用应用容灾方式，在同城或者异地，采用数据复制的方式，进行相关的数据容灾，可以结合企业整体的“两地三中心”策略进行数据仓库的容灾策略。

数据仓库物理部署架构规划

        数据仓库物理架构规划主要是确定主机、存储、网络的拓扑结构和各个逻辑子系统的部署情况。

        对于数据仓库系统，除了数据仓库服务器之外，一般还包含以下的硬件平台。

        需要定义不同类型服务器的主要性能/容量指标，不同服务器的推荐配置，各个服务器的物理拓扑关系等。

数据安全策略规划

        数据安全是数据仓库技术平台的一个重要方面，主要的内容包括以下几个部分：

5、数据仓库的运营管理规划

        数据平台管理包含组织体系、制度与流程体系和技术支撑体系。其中，组织体系作为数据管理平台的基础，制度与流程体系是数据管理平台的保障，技术体系是数据管理平台的物理载体。

6、企业级数据模型规划

统一数据模型的建设

        在数据平台（仓库）中，模型层是数据平台（仓库）的核心所在，优秀的稳定的模型层有利于整个平台（仓库）体系的稳定发展。公司有金融行业成熟数据模型，结合金融机构业务需求和发展规划，设计符合行方实际的数据模型，实现业务数据的抽象和整合，按业务主题分类保存。

企业级数据模型设计规范与原则

• 模型设计规范

        数据模型是数据管理的分析工具和交流的有力手段，同时还能够很好地保证数据的一致性，是BI的重要基础。因此建立、管理一个企业级的数据模型，应该遵循标准的模型设计规范。基础模型层、共性加工层、应用集市层模型设计都将遵循以下标准规范。

• 模型层设计原则

模型层也称之为数据整合层:

        数据模型采用面向主题的设计方法，有效组织来源多样的业务数据，使用统一的逻辑语言描述银行业务，是数据管理的分析工具和交流的有力手段；保证数据的一致性，是银行实现业务智能的重要基础。

        数据平台（仓库）将同时面对多个部门的分析需求，因此相应的逻辑数据模型不能针对某一个特定部门或领域的特定需求而开发，一个普遍的、灵活的数据模型应该在一定的抽象水平上提供对数据事实本身的一个中性视图。例如，一个人的基本信息（姓名、性别、出生日期等），不会因为他是普通客户或员工，也不会因为是哪个部门要分析这些数据信息而有所变化。

        因此数据模型作为一个行方构建基础数据平台（仓库）的重要基础，在此基础上可以进行多种不同应用的开发设计，满足不同部门的业务需求和不同的数据访问方式，真正实现数据一次导入，多次使用，它所遵循的设计原则主要包括：

• 共性加工层模型设计原则

        在逻辑上，共性加工层是EDW的一部分，它介于模型层和应用集市层的中间，因为基础数据基本按照第三范式的原则进行组织的，而特定的应用集市的数据要求都需要对基础数据进行一定程度的汇总才能便于应用访问数据，而且某一程度的汇总数据会支持多数应用所需要，因此，为了满足应用访问效率和数据资源的共享性，需要在EDW中构建共性加工层。

        共性加工层是从业务的视角出发，提炼出对数据仓库具有共性的数据访问、统计需求，从而构建出的一个面向支持应用的、提供共享的数据访问服务的公共数据。它所遵循的设计原则主要包括：

• 应用集市层模型设计原则

数据架构规划建议

        未来数据仓库系统需要支撑全行绝大部分分析型应用和数据分析工作，从全面支撑应用和数据分析的角度，数据仓库的数据架构应当包含以下几个层次：

贴源缓冲层

        技术缓冲层是为了数据加载和转换的需要而设计的，不提供对外服务，源系统下载数据通过源系统或数据交换平台加载到技术缓冲层。

        数据仓库在数据处理中可能会出现加载错误或采集的源数据本身的错误，解决问题往往需要对源数据进行重新加载或查询，为方便和快速地发现错误、解决问题，可以在技术缓存层保留数天的数据。

贴源全量层

        基本按照源系统的结构来保存数据，用于方便快速地支持需要按源系统数据结构提供历史数据的分析型应用或时效性比较高的应用。

        物理数据尽量保持源系统数据的原貎，不做变形，对于代码标准化等适合在贴源模型层进行的操作，可以通过两套视图对外提供数据服务：

        原始数据视图：基于源系统原貌的数据服务；

        标准数据视图：进行了代码标准化映射的数据服务；

        贴源模型层只保留当前数据或者短期历史，历史数据以两种方式保存；

        时间戳方式：适用于事件类表，例如交易表；

        时间拉链方式：在源系统表结构上加上开始日期和结束日期，适用于其他需要保留历史信息的表，例如账户表。

标准层

        标准层是在贴源全量层的基础上，通过对表名和字段进行统一的命名标准化，确保数据结构和命名规则的一致性，同时进行码值对标和转换，使不同来源的数据能够在统一的维度下进行整合和分析。此外，标准层还会对空值字段进行剔除或填充处理，避免数据缺失对分析结果的影响，并剔除冗余字段以简化数据结构，提升数据处理效率。在数据重复处理方面，标准层通过去重和合并操作，确保数据的唯一性和准确性，从而显著提高数据的整体质量。

模型层

        模型层是基于标准化的数据，进行进一步的主题划分、转换和数据标准化，生成符合逻辑模型的主题数据。主题是对银行业务的抽象。它着眼于银行经济活动中的要素：客户、帐户、交易、产品、组织等以及这些要素间的关系；它屏蔽了不同系统变化繁多的交易处理过程，使用户的注意力始终关注在关键信息上。可以说，模型层的模型将是数据平台系统的核心和建设成败的关键。

        具体来说，模型层特点如下：

共性加工（指标）层

        共性加工层是从业务的视角出发，提炼出对数据仓库具有共性的数据访问、统计需求，从而构建出的一个面向支持应用的、提供共享的数据访问服务的公共数据。

        共性加工层的构建从技术层面来看，主要目的在于：

        同时服务于多个不同应用，实现数据和指标的共享，减少相同的业务统计所带来的数据重复计算与存储，避免数据在多次加工后出现的不一致。

        提高查询效率。由于经常被访问到的基础数据和业务指标经过整合计算以后存储在共性加工层，减少了重新关联表进行计算所带来的性能问题，加快了查询的响应时间。

        降低应用开发和数据查询的复杂程度。由于共性加工层从业务分析的视角组织数据，屏蔽了数据仓库的复杂性，便于前端应用的开发。

        共性加工层的构建从业务层面来看，主要目的如下：

        建立多层次的数据访问服务体系，有力提升EDW的价值。基于共性加工层和FDM，我们可以提供面向特定分析的专题数据集市、面向业务人员的即席数据查询、以及面向应用开发者的应用访问接口，因此建立起一套多层次的数据访问体系，以满足不同类型应用的需要。

        共性加工层的建设是一个循环往复的过程，不可能一步到位。随着应用的增加和对应用理解的深入，共性加工层会不断的丰富和发展，提升其业务价值。因此本期共性加工层建设的目标是搭建共性加工层的基本架构，形成共性加工层建设的基本指导原则和工作模式，重点实现协议主题和部分其他主题的具体设计。

应用集市层

        数据集市层保存各管理信息应用系统所对应的数据集市。数据集市建设面向具体的业务应用，数据集市的数据是在基础模型层数据的基础上按需生成，允许一定的数据冗余，以提高管理信息系统的数据访问效率。

        数据集市的数据模型通常根据管理信息系统的业务需求建立。数据集市中的数据主要是管理信息应用系统专用的数据，数据集市层的数据集市可以从简到繁，根据业务发展的需要逐步进行扩充。

7、统一数据模型

模型层数据模型

        FDM主题模型是以银丰睿哲的数据模型为蓝本，结合行方操作型业务系统的业务特性，采用面向主题的方法，按照第三范式规则进行设计。将来源于行方诸多业务系统的数据有效地组织起来，为行方提供了中性数据平台和单一信息视图，能够全面体现各种业务规则，支持将来的分析型应用。

        伴随着行方数据仓库系统建设得不断推进，今后我们还将逐步融入其它源业务系统，实现数据模型的不断增强完善，最终完成行方模型层的设计。

• 客户主题

        客户主题主要组织和存放与银行客户有关的信息。包括基本信息、地址信息、信用信息、财务信息等。

客户主题包括：

        个人客户信息：主要存放来自个人客户的信息，包括基本信息、地址信息、评级信息、财务信息等。

        企业客户信息：主要存放企业客户的信息，包括基本信息、联系信息、地址信息、信用评级信息、财务信息、企业客户人之间的关系等。

• 存款主题

        存款主题组织和存储企业和个人客户的在银行的存款业务相关信息，主要包括帐户信息、事件信息及事故信息。根据业务应用分类，在模型设计中按个人活期、个人定期、企业活期、企业定期四个子主题进行逻辑设计。

存款主题包括：

        个人活期：包括个人活期存款帐户、个人活期存取款等事件、个人活期帐户变动等信息。

        个人定期：包括个人定期存款帐户、个人定期存取款等事件、个人定期帐户变动等信息。

        企业活期：包括企业活期存款帐户、企业活期协定协议、企业活期存取款等事件、企业活期帐户变动等。

• 贷款主题

        贷款主题组织和存储企业和个人客户的在银行的贷款业务相关信息，主要包括申请信息、合同信息、账户信息、流水信息、还款计划、押品信息、风险分类等。

        企业定期：包括企业定期存款帐户、企业定期存取款等事件、企业定期帐户变动等信息。

贷款主题包括：

        个人贷款：个人贷款申请信息、个人贷款合同信息、个人贷款帐户信息、个人贷款交易流水、个人贷款发放流水、个人贷款还款信息、个人贷款还款计划、个人贷款担保信息、抵质押物信息、个人贷款十级分类信息等。

        企业贷款：企业贷款申请信息、企业贷款合同信息、企业贷款帐户信息、企业贷款交易流水、企业贷款发放流水、企业贷款还款信息、企业贷款还款计划、企业贷款担保信息、抵质押物信息、银行承兑汇票信息、贴现信息、保函信息、企业贷款十级分类信息等。

• 银行卡主题

        银行卡主题组织和存储客户银行卡的基本信息、账户关系和交易信息等。银行卡主题包括：

借记卡：主要存储借记卡基本信息、借记卡相关流水。

贷记卡：存储与贷记卡系统有关的所有信息，如贷记卡主档、贷记账户、贷记卡申请信息、贷记卡帐单信息、贷记卡额度信息、贷记卡流水信息、贷记卡分期还款信息等。

• 中间业务主题

        中间业务主题主要整合银行除存、贷款业务以外的业务，即非利息收入以外的所有业务。

        中间业务主题逻辑划分按中间业务种类进行划分，如票据、汇款、国际结算、证券业务、代收代付、代理等业务相关信息。

中间业务主题包括：

票据：主要存储银行票据信息，包括汇票、本票、支票等。

汇款：主要存储来自银行结算方面数据，包括大额、小额、同城等。

国际结算：主要存储来自国际结算系统的新一代贸易融资方面的业务信息，包括进出口信用证、外汇汇入汇出、国际保理等。

代收代付：主要存储代收付信息，包括代付工资、代缴水电费、代缴电信费等。

代理：主要存储代理业务信息，包括保理保险等。

• 渠道主题

        渠道主题主要存储来自源系统的数据，包括渠道信息、签约帐户信息、渠道帐户信息以及交易流水信息。

渠道主题包括：

网银：包括企业网银和个人网银签约信息、流水信息等。

手机银行：包括手机银行签约等。

短信通：包括短信签约、短信流水等。

电话银行：包括Call Center相关信息。

自助设备：包括ATM,VTM,POS,自助终端等。

• 总账主题

        总帐主题用于组织和存储银行当前会计核算总帐和历史总账明细以及内部帐有关的信息。

总账主题包括：

        总账、内部帐、内部帐明细帐等。

• 公用主题

        公用主题用于存储各种业务主题公用的一些信息。主要包括内部机构、人员、公共代码等相关信息。

公用主题

内部组织：主要存储机构、部门、操作员以及之间的关系方面的数据。

业务参数：主要存放系统参数及业务参数。

共性汇总模型

共性汇总的作用：

共性汇总设计方法：

        比如存款账户日汇总，业务维度是存款，粒度维度是账户级，时间维度是日；网点存款月汇总，业务维度是存款，粒度维度是机构和存款属性，时间维度是月汇总。

        汇总层分为六类，存贷款类汇总、银行卡类汇总、中间业务类汇总、渠道类汇总、总账指标类汇总、公用汇总，主要内容包括：

• 存贷款类汇总

        该主题对存贷款款有关的数据，从账户、机构产品维度；从日、月维度进行统计汇总。可以根据这些维度的不同组合生成不同的数据集合。如：

        个人活期存款帐户日汇总、个人活期存款帐户月汇总、个人定期存款帐户日汇总、个人定期存款帐户月汇总、企业活期存款帐户日汇总、企业活期存款帐户月汇总、企业定期存款帐户日汇总、企业定期存款帐户月汇总、网点存款日汇总、网点存款月汇总、贷款账户日汇总、贷款账户月汇总、网点贷款日汇总、网点贷款月汇总

• 银行卡类汇总

        该主题主要对借记卡、贷记卡有关的内容进行汇总统计，按卡、按机构、日期维度进行统计，卡交易量、卡信息统计、开销卡等。如：

        借记卡交易日汇总、借记卡交易月汇总‘借记卡信息日汇总、借记卡信息月汇总、借记卡卡数日汇总、借记卡卡数月汇总、贷记卡交易日汇总、贷记卡交易月汇总、贷记卡信息日汇总、贷记卡信息月汇总、贷记卡卡数日汇总、贷记卡卡数月汇总

• 中间业务类汇总

        该主题主要对中间业务内容进行汇总统计，主要包括公积金、国债、基金、国业结算量、代发工资、理财、中间业务量等，按账户、机构、日期维度进行统计。如：

        个人公积金账户日汇总、个人公积金账户月汇总、国债账户日汇总、国债账户月汇总、网点国债日汇总、网点国债月汇总、基金账户交易月汇总、基金客户资产月汇总、国业结算量汇总日表、国业结算量汇总月表、企业代发工资汇总日表、企业代发工资汇总月表、理财账户交易月汇总、理财客户资产月汇总、网点中间业务月汇总

• 渠道类汇总

        该主题主要对中间业务内容进行汇总统计，主要包括公积金、国债、基金、国业结算量、代发工资、理财、中间业务量等，按账户、机构、日期维度进行统计。如：

        该主题主要对渠道相关的数据进行汇总统计。主要包括自助设备、商户、网银、柜面等渠道，按渠道、机构、日期维度汇总，包括渠道签约情况、渠道交易情况等。如：

        自助设备交易日汇总、自助设备交易月汇总、自助设备信息日汇总、自助设备信息月汇总、商户交易日汇总、商户交易月汇总、商户信息日汇总、商户信息月汇总、个人网银交易日汇总、个人网银交易月汇总、个人网银信息日汇总、个人网银信息月汇总、企业网银交易日汇总、企业网银交易月汇总、企业网银信息日汇总、企业网银信息月汇总、网银交易日汇总、网银交易月汇总、柜面交易日汇总、柜面交易月汇总

• 总账指标类汇总

        该主题主要对内部帐、总账数据、常用指标进行汇总统计。分成总账和指标的汇总，内部帐的汇总。

总账指标

A、模型

B、指标设计原则

关联性：全行业务经营核心指标为基础的相互依存的体系。

均衡性：核心指标以业务规模，收益，风险为基础的业务经营指标，辅助客户指标，再以市场规模指标作为参考的整体均衡指标框架。

稳定性：业务条线组织指标体系的扩展，以避免部门指标组织方式的不稳定性。

重用性：以权限的方式设定不同部门的KPI指标群集，确保业务经营指标统一口径下的全行共享。

实用性：参照业务部门日常关注的分析重点内容，梳理和整理指标。

C、指标设计原则

内部帐汇总

包括： 内部帐账户日汇总、内部帐账户月汇总

• 公共类汇总

        维度信息，比如机构维度、科目维度、币种维度、汇率参数、时间维度、年龄层次、存贷款金额层次等：

        客户业务汇总，包括个人客户业务汇总、企业客户业务汇总等：

8、性能设计

容量估算

*注：此为容量估算方法示例，行内实际需要容量需要调研后确认

• 3年规划预算步骤

        流水信息保留13个月，13月以前的流水信息应该进入历史数据区或者采用近线或离线存储的方式保留。

       基础数据层重要客户信息，账户信息按3年规划（建议保留7年），流水信息保留13个月（根据业界DW核心信息保留策略）。汇总数据保留3年。

       基础数据层FDM：如上表计算，核心数据量为4.1TB。 取50%的扩展系数，则核心数据量为4.1TB * （1+50%）= 6TB。

       共性加工层ADM: 按每月的核心数据量汇总为162G,2倍扩展系数，3年保留进行计算，得到其他数据的总数据量为：162×2 x 12 x 3 = 11T。

       FDM+ADM: 总数据量为：核心数据容量+ 扩展数据容量 = 8TB +11TB ≈19 TB （用户数据总量，不考虑存储底层的镜像等因素）。

       MDM：管理驾驶舱,统一报表平台，智能分析平台的初始化用户数据容量根据我行实施的多个项目经验来看用户数据容量为：2T。

性能设计要求

       系统整体备份能力：数据增量按每月500GB计，不压缩情况下月增量备份完成时间要求不大于1小时，20T全备份时间不超过12小时；

       并发情况下，文本导入和导出速度都不低于300M/秒；

       注册用户不少于5000，连接用户数不少于1500，其中并发操作用户数不少于200，至少满足200个并发任务下，服务器性能不会有显著降低；

       具备HA、负载均衡功能，当设备扩容时性能指标随容量增加而线性增长，系统能够满足7×24小时稳定运行；

后       台日常批处理时间要求最长不超过3小时，特殊时点（如月初、月底、结息和年终决算等）的批处理时间要求不超过4个小时，并且在后台批处理时不影响前台应用系统对本系统的访问；

       交易用户的简单查询访问的响应时间要求不超过2秒，复杂查询访问的响应时间不超过10秒。

大数据表分区策略

       当表中的数据量不断增大，查询数据的速度就会变慢，应用程序的性能就会下降，这时就应该考虑对表进行分区。表进行分区后，逻辑上表仍然是一张完整的表，只是将表中的数据在物理上存放到多个表空间(物理文件上)，这样查询数据时，不至于每次都扫描整张表。在数据仓库实施中一般采用日期分区模式。

       分区表的设计可以帮助我们解决一些大表的使用效率低下的问题，针对流水表的设计，建议采用按日期分区存放，每一个分区就好像独立的物理表，在使用某一个段时间的数据时，再也不用进行全表扫描，只需查询时间段所在分区的数据，大大的提高了数据的查询效率，同时降低了表的IO次数。

大数据表分区策略

       银行数据仓库的备份恢复策略主要包括数据库备份内容设计和数据库备份方式设计，备份频率设计。

• 数据仓库备份内容

银行数据仓库备份内容主要包括：

1、数据字典及数据库日志；

2、用户数据

（1）贴源层

（2）模型层

（3）共性加工层

（4）应用集市层

3、各管理系统和应用系统的资料库信息；

4、其他应用程序、ETL脚本和程序代码。

• 备份的方式及频率

针对不同的数据采用不同的数据备份策略：

1、每周做数据库全备份(包括数据库数据和归档日志)；

2、业务数据每天采用增量备份的方式进行；

3、源系统传过来的数据文件采用日备份，备份成功后从数据交换服务器删除；

4、各管理系统和应用系统的资料库信息每天备份；

5、其他应用程序及配置文件采用不定期备份，在应用程序或配置更改后备份。

• 备份的方式及频率

       数据仓库备份恢复根据需要进行，找到相应日期的备份，执行相应的恢复操作，恢复操作的粒度包括单表恢复、单库恢复和全库恢复。主要功能包括：

1.完全备份

       每天对自己的系统进行完全备份。例如，星期一用一盘磁盘对整个系统进行备份，星期二再用另一盘磁盘对整个系统进行备份，依此类推。这种备份策略的好处是：当发生数据丢失的灾难时，只要用一盘磁盘（即灾难发生前一天的备份磁盘），就可以恢复丢失的数据。然而它亦有不足之处，首先，由于每天都对整个系统进行完全备份，造成备份的数据大量重复。这些重复的数据占用了大量的磁盘空间，这对用户来说就意味着增加成本。其次，由于需要备份的数据量较大，因此备份所需的时间也就较长。对于那些业务繁忙、备份时间有限的单位来说，选择这种备份策略是不明智的。

2.增量备份

       星期天进行一次完全备份，然后在接下来的六天里只对当天新的或被修改过的数据进行备份。这种备份策略的优点是节省了磁盘空间，缩短了备份时间。但它的缺点在于，当灾难发生时，数据的恢复比较麻烦。例如，系统在星期三的早晨发生故障，丢失了大量的数据，那么现在就要将系统恢复到星期二晚上时的状态。这时系统管理员就要首先找出星期天的那盘完全备份磁盘进行系统恢复，然后再找出星期一的磁盘来恢复星期一的数据，然后找出星期二的磁盘来恢复星期二的数据。很明显，这种方式很繁琐。另外，这种备份的可靠性也很差。在这种备份方式下，各盘磁盘间的关系就象链子一样，一环套一环，其中任何一盘磁盘出了问题都会导致整条链子脱节。比如在上例中，若星期二的磁盘出了故障，那么管理员最多只能将系统恢复到星期一晚上时的状态。

3.差分备份

       管理员先在星期天进行一次系统完全备份，然后在接下来的几天里，管理员再将当天所有与星期天不同的数据（新的或修改过的）备份到磁盘上。差分备份策略在避免了以上两种策略的缺陷的同时，又具有了它们的所有优点。首先，它无需每天都对系统做完全备份，因此备份所需时间短，并节省了磁盘空间，其次，它的灾难恢复也很方便。系统管理员只需两盘磁盘，即星期一磁盘与灾难发生前一天的磁盘，就可以将系统恢复。

4.单表恢复

        如果发现只是单个表需要恢复，使用单表恢复，该功能针对具体的数据表执行数据恢复，使用数据库系统功能，简单、易用。

5.单库恢复

        如果发现单个数据库需要恢复，使用单库恢复，该功能针对具体的数据库执行数据恢复，使用数据库系统功能，简单、易用。

6.全库恢复

        如果发现整个数据库需要恢复，使用全库恢复，该功能可以针对具体的多个数据库执行数据恢复，使用数据库自身功能，简单、易用。

响应时间

调度设计

查询设计

1.在单表查询的时候，选择的过滤条件尽量使用分布键或有索引的字段上。

2.在表与表关联时，作为连接条件尽量使用分布键或有索引的字段上。

3.针对特别复杂的查询，关联的表比较多，计算也相对比较复杂，而有经常查询可以进行一些预处理工作，例如通过物化视图先将表关联好。

4.SQL语句编写的时候，选择我们所需要的字段，尽量不用SELECT *。

5.尽量使数据均匀分布在磁盘上，充分的利用系统的并发能力来提高查询效率。

6.针对分组求和的计算，可以使用分析函数的尽量采用系统自带的分析函数来处理查询。

7.针对不同的业务场景和语句进行充分的测试，保证查询的稳定性。