海量数据加工的处理方法和系统的制作方法
【专利摘要】本发明公开了一种海量数据加工的处理方法和系统，其中，该处理方法包括以下步骤：步骤S3：加载来自多个源业务系统的海量数据；步骤S5：对所加载的海量数据进行映射；步骤S7：根据报表工具的要求对映射后的海量数据进行处理。本发明的有益效果在于：通过将数据处理逻辑从业务系统中分离出来，生成数据文件由专门的数据处理系统进行统一处理。数据处理由原来的扁平处理方式改为分层的方式进行处理。从而减轻数据处理难度，极大的提高海量数据处理性能，从而提高数据处理的效率，进一步满足数据统计分析要求。
【专利说明】海量数据加工的处理方法和系统
【技术领域】
[0001]本发明涉及银行业中多业务种类、超大数据量、高性能的数据仓库及各类数据分析类信息系统的海量数据加工处理领域，尤其涉及一种海量数据加工的处理方法和系统。
【背景技术】
[0002]现有技术中，大量数据的处理基本上是分散在各自的源业务处理系统中进行的，此时源业务系统既承担着日常业务处理本身的压力，同时还要承担海量数据的加工、查询、分析等大量工作。由于各源业务系统的数据模型都是按3NF、4NF甚至是5NF进行设计的，这种数据模型对于海量数据的处理在性能方面的需求远远不能达到数据分析的时效要求。随着银行业务飞速发展，业务处理愈加复杂，业务流程不断更新，各业务系统间关联越来越紧密，管理层高层领导及部门级管理人员对数据统计分析的需求越来越大，在各源业务系统中进行海量数据加工处理的方法、性能、技术架构已明显不再符合银行对数据统计分析的要求。
【发明内容】
[0003]本发明所要解决的问题是在源业务处理系统中进行海量数据处理不能满足现对数据统计分析的要求，提供一种能够专门对海量数据处理进行处理的方法和系统，从而提高数据处理的效率，满足数据统计分析要求。
[0004]为了解决上述问题，本发明提供一种海量数据加工的处理方法，根据本发明的处理方法包括以下步骤:
[0005]步骤S3:加载来自多个源业务系统的海量数据；
[0006]步骤S5:对所加载的海量数据进行映射；
[0007]步骤S7:根据报表工具的要求对映射后的海量数据进行处理。
[0008]作为优选，步骤S5进一步包括:
[0009]步骤S51:根据源业务系统的业务对所加载的海量数据进行建模；
[0010]步骤S52:对建模之后的海量数据进行范式化。
[0011]作为优选，步骤S7进一步包括:
[0012]步骤S71:对映射后的海量数据进行汇总；
[0013]步骤S72:对汇总后的海量数据进行指标加工。
[0014]作为优选，步骤S7进一步包括:
[0015]按照星型模型设计原则对映射后的海量数据进行处理；星型模型设计原则包括:
[0016]事实聚合表设计原则，其用于计算指标和固定报表；
[0017]事实基础表设计原则，其用于计算事实聚合表；
[0018]指标表设计原则，其用于根据接合前端工具的要求和固定报表的格式来设计指标
O O
[0019]作为优选，在步骤S3之前，根据本发明的方法包括:
[0020]步骤S2:根据预设规则对海量数据进行清洗。
[0021]作为优选，在步骤S2之前，根据本发明的方法还包括:
[0022]步骤S1:对从多个源业务系统中所分离出来的海量数据进行集中；
[0023]则步骤S3进一步包括:对集中后的海量数据进行加载。
[0024]根据本发明的另一个方面，还提供了一种海量数据加工的处理系统，采用如上的海量数据加工的处理方法，该处理系统包括:
[0025]ODS层，其配置为加载来自多个源业务系统的海量数据并存储；
[0026]UDM层，其配置为对所加截的海量数据进行映射并存储；
[0027]应用层，其配置为根据报表工具的要求对映射后的海量数据进行处理，并将处理后的数据体现到业务所需的报表中。
[0028]作为优选，根据本发明的处理系统还包括:
[0029]数据清洗模块，其配置为根据预设规则对海量数据进行清洗。
[0030]作为优选，根据本发明的处理系统还包括:
[0031]数据下传平台，其配置为集中从多个源业务系统中所分离出来的海量数据；
[0032]则ODS层进一步配置为对数据下传平台中集中后的海量数据进行加载。
[0033]作为优选，上述应用层进一步包括:
[0034]汇总模块，其配置为对映射后的海量数据进行汇总；
[0035]加工模块，其配置为对汇总后的海量数据进行指标加工。
[0036]本发明相对于现有技术的有益效果在于:
[0037]1、通过将数据处理逻辑从业务系统中分离出来，生成数据文件由专门的数据处理系统进行统一处理。数据处理由原来的扁平处理方式改为分层的方式进行处理。从而减轻数据处理难度，极大的提高海量数据处理性能，从而提高数据处理的效率，进一步满足数据统计分析要求。
[0038]2、通过UDM层的作用使得更易理解的数据模型、屏蔽了底层异物构数据源；可进行高效的聚合型查询。
[0039]3、通过对数据模型进行范式化可以使得数据更新加快并且节约空间。
【专利附图】
【附图说明】
[0040]图1为根据本发明的海量数据加工方法的流程图；
[0041]图2为根据本发明的海量数据加工方法的一个实施例进行数据集中的装置的示意图；
[0042]图3为根据本发明的海量数据加工方法的一个实施例进行数据分层处理的系统的不意图；
[0043]图4为根据本发明的海量数据处理方法的一个实施例的步骤的示意图。
【具体实施方式】
[0044]以下结合附图对本发明的进行详细描述。
[0045]根据本发明的实施例，提供了一种海量数据的处理方法，包括以下步骤:
[0046]步骤S3:加载来自多个源业务系统的海量数据；
[0047]步骤S5:对所加载的海量数据进行映射，其中，可以进一步包括:步骤S51:根据源业务系统的业务对所加载的海量数据进行建模；步骤S52:对建模之后的海量数据进行范式化；
[0048]步骤S7:根据报表工具的要求对映射后的海量数据进行处理，优选地，可以根据星型模型设计原则对映射后的海量数据进行处理，其中，可以进一步包括:步骤S71:对映射后的海量数据进行汇总；步骤S72:对汇总后的海量数据进行指标加工。
[0049]在另一个实施例中，在步骤S3之前，根据本发明的处理方法还可以包括:
[0050]步骤S2:根据预设规则对海量数据进行清洗。
[0051]在又一个实施例中，在步骤S2之前，根据本发明的处理方法还可以包括:
[0052]步骤S1:对从多个源业务系统中所分离出来的海量数据进行集中；而在步骤SI的基础上，步骤S3可以进一步包括:对集中后的海量数据进行加载。
[0053]根据本发明的实施例，还提供了一种海量数据加工的处理系统，该处理系统包括:
[0054]ODS层，配置为加载来自多个源业务系统的海量数据；
[0055]UDM层，配置为对所加截的海量数据进行映射；
[0056]应用层，配置为对映射后的海量数据进行应用。
[0057]此外，根据本发明的处理系统还包括:
[0058]数据清洗模块，配置为根据预设规则对海量数据进行清洗。
[0059]在优选的实施例中，根据本发明的处理系统还包括:
[0060]数据下传平台，配置为集中从多个源业务系统中所分离出来的海量数据；
[0061]则ODS层进一步配置为对数据下传平台中集中后的海量数据进行加载。
[0062]优选地，上述应用层进一步包括:
[0063]汇总模块，配置为对映射后的海量数据进行汇总；
[0064]加工模块，配置为对汇总后的海量数据进行指标加工。
[0065]在实际应用中，根据本发明的海量数据加工方法可以包括数据集中和数据分层处理两大部分，以下参照图2和图3对该两部分进行描述。
[0066]如图2所示，为执行根据本发明的海量数据加工方法进行数据集中的装置的示意图。该海量数据加工系统包括源业务系统、手工录入系统(i_R印rot)、数据下传平台、数据库服务器。根据本发明进行海量数据加工的主要思想之一即是首先数据集中到数据下传平台，即将各源业务系统(图2中示出为源系统)的数据由业务系统分离出来，然后由统一的入口和出口将数据集中到专门的数据处理系统(图2中示出为数据库服务器)，然后进行后续的采用数据分层的加工处理方式进行处理，这样的设置既减轻了各源业务系统的性能压力，同时也极大的提高了数据汇总的性能要求。
[0067]如图3所示，为执行根据本发明的海量数据加工方法的一个实施例进行数据分层处理的系统的示意图。如图3所示,数据分层具体可分为ODS (Operat1nal Data Store,操作数据存储)层、UDM(Unified Data Manager，统一数据管理平台)层、应用层。ODS层体现了各源业务系统的原始数据视图，ODS层为一种数据结构，其数据间逻辑关系与源业务系统的数据间逻辑关系基本一致，数据可分为增量数据(即继最后一次数据导出后新增的数据)与全量数据(或者部分全量数据)，从而为后续的UDM层提供基础数据；UDM层则是对银行的业务数据进行统一的、科学的、全局的数据规划，该UDM层使用ODS层数据作为原始加工数据，且生成的UDM层数据被后面的应用层数据所引用，因数据被集中处理，因此海量数据的生理性能得到了巨大提高；应用层的数据则真正体现了业务需求对数据的要求，是真正的数据体现，该数据被直接体现到业务所需的报表中。
[0068]以下对图3所示内容进行详细描述，在本实施例中，根据本发明进行数据分层处理的方法主要通过 SHELL+C/PR0C 开发的 Job Control 系统对ETL (Extract-Transform-Load,用于描述将数据从来源端经过萃取(extract)、转置(transform)、加载(load)至目的端的过程)处理过程进行调度和控制，当然，也可以使用本领域技术人员所熟知的其它系统进行ETL处理。如图3所示，首先从数据下传平台(对应于文件层)下传文件，通过SQLLDR C程序进行清洗后加载至ODS (即ODS层)；然后通过proc程序PL/SQL进行转换至UDM (即UDM层)；然后通过proc程序PL/SQL进行加工进入应用(即应用层)；最后通过C程序SHELL程序进行报表加工，从而将数据传输至报表(即报表层)。
[0069]其中，所生成的UDM层的主要优点在于:其为更易理解的数据模型、屏蔽了底层异物构数据源；可进行高效的聚合型查询。
[0070]海量数据因数据量巨大，数据维度复杂，统计需求对数据处理的方式及效率要求极高。如果采用简单的扁平处理方式(即数据不分层次)数据直接关联(或限制条件、统计汇总)那么就会因数据量巨大而导致出现巨大的性能问题，同时也不利于统计分析类系统对业务需求的及时响应。因此海量数据处理方法采用了业界最为流行的数据模型设计，主要面向客户、合约、参考等各主题进行模型设计。
[0071]以下通过图4对各模型层次进行更进一步的详细说明，如图4所示为根据本发明的海量数据处理方法的一个实施例的步骤的示意图。图3是加工流程在逻辑上的分层，图4是流程物理上的分层和各子模块的模块功能，例如图4的Oracle ODS库对应图3的0DS，UDM库对应图3的UDM，汇总库+指标库对应图3的应用层，报表库对应图3的报表层。如图4所示，数据分层处理主要包括三个部分:
[0072]第一、清洗守护程序，通过文件处理模块进行，包括对源数据文进行1、文件注册；
2、数据清洗，其中，2数据清洗包括清洗错误数据文件和清洗正常数据文件，前者包括根据一定的过滤规则将不符合要求的数据进行清洗，再提交用户进行修正，后者包括对数据文件进行转换、映射和加工；
[0073]第二，基础库调度程序，通过基础数据加工模块进行，包括1、加载清洗后的数据至ODS库，包括加载BAD(坏)数据文件、加载DISCARD(丢弃)数据文件和加载LOG(日志)数据文件；2、ODS库存储内的数据文件进行数据映射再存储至UDM库；3、对UDM库内的数据文件进行数据汇总再存储至汇总库；4、对汇总库内的数据文件进行指标加工再存储至指标库；5、对指标库内的数据文件进行数据复制得到备份文件；
[0074]第三、应用调度程序，由应用数据加工模块进行，包括1、导入备份文件数据至指标库(复制)；2、对指标库(复制)内的数据文件进行报表数据加工，然后也可以存储至报表库。
[0075]优选地，图4中所提及的ODS库、UDM库、汇总库、指标库、指标库(复制)和/或报表库均可以采用0racle(甲骨文)公司的产品。进一步地，本实施例中ETL的范围是从数据源模型(即源数据文件)到报表元素模型(即报表数据)，或者在根据本发明的海量数据的处理过程中，根据需求指定需进行ETL的步骤，而不仅限于实施例中所示顺序的ETL步骤，此外，可以根据用户需求对ETL的要求进行不同的设定以实现不同的效果。
[0076]各模型层次说明:
[0077]如图4所示:海量数据采用三层结构存储数据:0DS、UDM、FCT(Fact Table事实表)。ODS存储由源系统传输而来的数据，存储当前的增量和部分全量业务数据，该数据文件在模型设计上和源业务系统的数据文件保持一致，数据每天清除重传，不保留历史，以达到对海量数据高性能处理的要求；UDM是按照业务建模并储存范式化的数据模型，优选地UDM层的逻辑模型设计采用第三范式原则进行(其中，对数据模型进行范式化的优点在于:范式化数据文件的更新速度要快于非范式化数据文件的更新；当数据文件得到很好的范式化之后，就仅存在很少的重复数据或者没有重复数据，因而也只存在很少的数据需要更新；范式化的数据文件通常较小，可以节约存储空间)，存储当前及部分历史的全口径业务数据，逻辑模型设计采用第三范式(3NF)原则，物理模型设计根据具体需要和软硬件环境可以适当地进行非范式化；FCT存放事实及报表指标数据，面向报表应用，按照星型模型(也称为星形连接的模式、数据立方体或多维模式，是最简单的样式数据仓库架构，其由一个或多个事实表中引用任何数量的维表)进行设计。
[0078]UDM是对业务数据包括历史明细的一次重新组织与存储。在ODS模型和FCT模型之间架设一个UDM模型，对ODS模型进行一次封装，可以减少业务源变化对FCT模型的直接冲击，从而很好的降低ODS模型的变化风险。另一方面，把从数据源模型到报表元素模型的ETL分成了两部:0DS到UDM、UDM到FCT。通过对上述数据分层和模型的说明可以看出海量数据在处理上被分隔成各个模块，和从业务源直接到报表元素的ETL相比，降低了海量数据处理的难度，大大降低了 ETL的复杂度。
[0079]以下关于数据加工流程及性能进行分析，下述各数据加工流程及各层数据的设计策略都在很大程度上着重考虑海量数据加工时的性能要求。
[0080]
[0081]UDM层的逻辑模型设计采用第三范式原则进行，其设计策略包括以下几方面:
[0082]第一方面，概念层同类实体在逻辑层的设计策略
[0083]为了描述业务方便，在概念层上将同类实体作为一个实体描述。但是，模型数据来自不同系统，描述不同区域、不同业务的内容(例如客户，有对公客户、也有对私客户)。在逻辑层上，对于这些同一类业务对象，有两种方式记录数据:统一到一个业务实体；或在一个业务实体下继承。举例来说，以客户这个实体来说，很多系统的客户都具有同样的属性，例如客户号、客户名称、创建时间，但也会有各自系统特有的属性，例如财富管理系统，客户有特有的属性VIP等级，贷款审批系统，客户有属性风险等级，那么，当这些源系统的数据统一到UDM层的时候，就面临一个选择，是建一个实体，属性有客户号、客户名称、创建时间、VIP等级、风险等级，还是说建3个实体，实体I属性是客户号、客户名称、创建时间，实体2属性是客户号、VIP等级，实体3属性是客户号、风险等级，实体2、3看起来就像是实体I的扩展属性实体，前者就是统一方式，后者就是继承方式。而两种表达方式的利弊在于:统一表达的方式(即统一到一个业务实体)，其优点是能满足全辖数据、全口径业务的查询统计分析，模型相对简单容易理解；继承的表达方式(即在一个业务实体下继承)，其优点是在单口径查询统计分析时，更具有灵活性与效率，而且容易与源系统对应。综合考虑以上因素并接合查询统计需求，按照以下原则进行设计:
[0084]对于同一业务对象但是不同系统不同区域的数据，如果数据属性、类型、取值基本一致，为了模型简单及方便全辖数据统计查询，将数据统一到一个数据实体中；
[0085]对于不同业务对象，通过继承来记录；
[0086]对于不同业务对象的余额历史，统一到一个数据实体中。
[0087]第二方面，历史数据的存储的设计策略:
[0088]对于本次需求分析中需要历史的金额或状态，建立历史余额表和历史状态表，对于不需要进行历史分析的金额及状态，只保留最新情况。
[0089]历史数据保存方法分为三种:a、明细直接追加b、开始日期一截至日期C、历史日期。方式a是适合流水类数据，是传票、交易明细等业务数据较好的保存办法；方式b存储量小，查询统计效率低，适合不定期大数据量的历史数据分析；方式c存储量大，查询统计效率高，适合定期的小数据量的历史数据分析。
[0090]第三方面，公共码表的设计策略:
[0091]由于源数据来自不同系统，PIF信息有所差异。为了以后分析、统计口径保持一致与统一口径不一致的系统数据，需要在清洗时转换进入本模型。
[0092]第四方面，预联接与冗余的设计策略:
[0093]概念层里用实体表达了“合约与客户”、“合约与内部当事方”、“合约与合约”、“客户与客户”、“客户与客户”、“客户与内部当事方”、“内部当事方与内部当事方”的关系。在逻辑层里，根据统计分析需求，我们直接在客户、合约、OSF等实体里加入“机构号”、“客户号”等冗余字段，避免统计分析时进行表联接处理。在物理层中，将去掉“合约与客户”、“合约与内部当事方”、“合约与合约”、“客户与客户”、“客户与客户”、“客户与内部当事方”、“内部当事方与内部当事方”等实体。
[0094]第五方面，FCT层的设计原则及策略:
[0095]FCT层是数据应用区，针对具体应用，将UDM的数据进行计算、链接、聚合等处理，以达到前端报表工具方便使用的目的。FCT层分为事实表子层和指标表子层:事实表子层是面向主题的、多维描述的业务事实，事实通过UDM的原始数据聚集得到；指标表子层是面向具体分析需求的、指标描述的指标项，指标项通过业务事实或原始UDM数据加工计算得至IJ。FCT层采用星型模型设计。
[0096]原则一、事实聚合表设计原则
[0097]设计事实聚合表之目的在于为计算指标和固定报表。因而，需要以需求分析为依据进行，具体地，将需求指标项分解到各主题的事实，根据对事实的粒度要求进行维度设计；根据对事实的业务范围要求进行事实表UDM源数据范围设计，最终得到事实表，其包括维度、事实及UDM源数据加工范围。
[0098]原则二、事实基础表设计原则
[0099]设计事实基础表之目的在于为计算事实聚合表，避免事实聚合表重复扫描源UDM数据。因此，根据事实聚合表具体情况设计事实基础表。
[0100]原则三、指标表设计原则
[0101]设计指标表之目的在于为前端工具计算固定报表，因而其原则在于根据接合前端工具的要求和固定报表的格式来设计指标表。
[0102]以上实施例仅为本发明的示例性实施例，特别是本文的技术方案进行各种处理时所采用的各种程序，均不用于限制本发明，本发明的保护范围由权利要求书限定。本领域技术人员可以在本发明的实质和保护范围内，对本发明做出各种修改或等同替换，这种修改或等同替换也应视为落在本发明的保护范围内。
【权利要求】
1.一种海量数据加工的处理方法，其特征在于，包括以下步骤: 步骤S3:加载来自多个源业务系统的海量数据； 步骤S5:对所加载的海量数据进行映射； 步骤S7:根据报表工具的要求对映射后的海量数据进行处理。
2.根据权利要求1所述的处理方法，其特征在于，步骤S5进一步包括: 步骤S51:根据所述源业务系统的业务对所加载的海量数据进行建模； 步骤S52:对建模之后的海量数据进行范式化。
3.根据权利要求1所述的处理方法，其特征在于，步骤S7进一步包括: 步骤S71:对映射后的海量数据进行汇总； 步骤S72:对汇总后的海量数据进行指标加工。
4.根据权利要求3所述的处理方法，其特征在于，步骤S7进一步包括:按照星型模型设计原则对映射后的海量数据进行处理；所述星型模型设计原则包括: 事实聚合表设计原则，其用于计算指标和固定报表； 事实基础表设计原则，其用于计算事实聚合表； 指标表设计原则，其用于根据接合前端工具的要求和固定报表的格式来设计指标表。。
5.根据权利要求1所述的处理方法，其特征在于，在步骤S3之前，所述方法包括: 步骤S2:根据预设规则对所述海量数据进行清洗。
6.根据权利要求5所述的处理方法，其特征在于， 在步骤S2之前，所述方法还包括: 步骤S1:对从所述多个源业务系统中所分离出来的所述海量数据进行集中； 则步骤S3进一步包括:对集中后的海量数据进行加载。
7.—种海量数据加工的处理系统，其特征在于，采用如权利要求1中所述海量数据加工的处理方法，所述系统包括: ODS层，其配置为加载来自多个源业务系统的海量数据并存储； UDM层，其配置为对所加截的海量数据进行映射并存储； 应用层，其配置为根据报表工具的要求对映射后的海量数据进行处理，并将处理后的数据体现到业务所需的报表中。
8.根据权利要求7所述的处理系统，其特征在于，还包括: 数据清洗模块，其配置为根据预设规则对所述海量数据进行清洗。
9.根据权利要求8所述的处理系统，其特征在于，还包括: 数据下传平台，其配置为集中从所述多个源业务系统中所分离出来的所述海量数据； 则ODS层进一步配置为对所述数据下传平台中集中后的海量数据进行加载。
10.根据权利要求7所述的处理系统，其特征在于，所述应用层进一步包括: 汇总模块，其配置为对映射后的海量数据进行汇总； 加工模块，其配置为对汇总后的海量数据进行指标加工。
【文档编号】G06F17/30GK104298779SQ201410613964
【公开日】2015年1月21日 申请日期:2014年11月4日 优先权日:2014年11月4日
【发明者】王作为, 杨春明, 闫宏宇, 郭铸 申请人:中国银行股份有限公司