CN112817971A

CN112817971A - 一种基于二维映射表的数据处理方法及系统

Info

Publication number: CN112817971A
Application number: CN202110084460.7A
Authority: CN
Inventors: 于克干
Original assignee: Individual
Current assignee: Individual
Priority date: 2021-01-21
Filing date: 2021-01-21
Publication date: 2021-05-18

Abstract

本发明提出了一种基于二维映射表的数据处理方法及系统，涉及互联网技术领域。一种基于二维映射表的数据处理方法包括：获取来源数据采集范围和数据采集方式；根据数据采集方式以及数据库产品选择对应的模型；根据确定的模型建立数据的访问方式；采用数据处理任务调度引擎、任务执行引擎、数据映射规则模型建立数据处理机制；确定ETL处理脚本的实现工具并选定预设脚本工具实现数据处理。通过将数据开发从线下搬到了线上，系统运营的每个环节都能在线上实现，为企业IT整体数字化转型提供了有力的基础支撑。此外本发明还提出了一种基于二维映射表的数据处理系统，包括：获取模块、选择模块、设计模块、建立机制模块以及输出模块。

Description

一种基于二维映射表的数据处理方法及系统

技术领域

本发明涉及互联网技术领域，具体而言，涉及一种基于二维映射表的数据处理方法及系统。

背景技术

随着移动互联网和数字化信息产业的快速发展，大数据应用市场不断扩大，在推动我国经济数字化转型升级过程中发挥着关键作用。“作为新时代的石油”，数据，已经渗透到当今每一个行业和业务职能领域，成为了企业最宝贵的资产，并得到了各行各业的高度重视。其中如何高效、快速、准确的利用好数据，挖掘其中的价值，为企业运营的每一个环节服务，成为当下各企业面临的共同难题。

传统企业级数据平台的开发和使用，因数据本身存在的历史原因以及数据开发的技术原因，通常会面临五大困难：

系统孤立数据隔离：传统零散的应用需求促使企业搭建了许多只满足某个应用场景的相对孤立的应用数据平台，也就是我们常说的数据孤岛，孤岛之间数据共享不畅，应用之间无法产生协同效应。

数据使用灵活性差：很多时候业务人员需要的指标数据，当前系统无法提供，需要向科技部门提出数据开发需求。科技人员通常需要经过分析、设计、开发、测试、上线等流程，最后才能满足业务人员的数据需求。这个过程通常需要经历一个相当长的时间(通常几天或者几个月)，而很多时候业务人员的数据需求都是临时性的，时效性要求较高，需求生命周期较短，类似冗长的数据处理机制很难满足业务发展的实际需求。

平台操作便携度低：很多时候处理数据，由于各种规定和风险控制，我们需要回到公司打开电脑或者在其他地方通过VPN访问数据平台执行系统的各种操作。

数据开发门槛较高：传统的方案中搭建数据平台通常需要ETL或者大数据开发人员利用某脚本语言开发数据处理脚本，将数据按照业务规则处理成需要的模型数据(通常是维度模型)。其中，数据需求的变更，新需求的响应通常都由专业科技开发人员通过线下修改代码、测试代码、线上部署代码完成。

数据视图透明度低：传统的数据平台中，数据的处理逻辑都散落在脚本中，业务人员很难知道企业的业务数据都去哪了，也很难知道系统中使用的指标数据是怎么来的。部分企业为此搭建了元数据管理平台，但是由于元数据采集困难，系统很难及时准确的反应当前最新的数据处理逻辑，而且，元数据管理平台的搭建也增加了系统建设和维护成本。以上问题亟需解决。

发明内容

本发明的目的在于提供一种基于二维映射表的数据处理方法，其能够快速配置需要的数据集，通过前端配置助手，可以快速完成数据处理开发需求，为前端BI数据分析提供了强大、便捷的数据处理支撑平台，通过将数据开发从线下搬到了线上，系统运营的每个环节都能在线上实现，为企业IT整体数字化转型提供了有力的基础支撑。

本发明的另一目的在于提供一种基于二维映射表的数据处理系统，其能够运行一种基于二维映射表的数据处理方法。

本发明的实施例是这样实现的：

第一方面，本申请实施例提供一种基于二维映射表的数据处理方法，其包括获取来源数据采集范围和数据采集方式；根据数据采集方式以及数据库产品选择对应的模型；根据确定的模型建立数据的访问方式；采用数据处理任务调度引擎、任务执行引擎、数据映射规则模型建立数据处理机制；确定ETL处理脚本的实现工具并选定预设脚本工具实现数据处理。

在本发明的一些实施例中，上述获取来源数据采集范围和数据采集方式包括：根据需求梳理平台涉及的数据源以及数据源的数据采集方式。

在本发明的一些实施例中，上述根据数据采集方式以及数据库产品选择对应的模型包括：数据库产品选择对应大数据平台的HIVE、ORACLE、SQL SERVER、MYSQL模型。

在本发明的一些实施例中，上述根据确定的模型建立数据的访问方式包括：业务人员或者系统运维人员通过PC端或者移动端访问设计。

在本发明的一些实施例中，上述数据映射规则包括：建立create映射子表、delete映射子表、insert映射子表、update映射子表以及映射总表。

在本发明的一些实施例中，还包括ETL执行引擎在任务处理映射总表获取每个任务的处理步骤。

在本发明的一些实施例中，还包括根据处理步骤生成数据库能够识别的SQL语句集。

在本发明的一些实施例中，还包括数据实验室环境和生产环境保持一致，并且与生产环境尽量物理隔离，计算存储资源相互独立，未经测试过的数据源配置通过数据实验室成功试验后投产运行。

第二方面，本申请实施例提供一种基于二维映射表的数据处理系统，其包括获取模块，用于获取来源数据采集范围和数据采集方式；

选择模块，用于根据数据采集方式以及数据库产品选择对应的模型；

设计模块，用于根据确定的模型建立数据的访问方式；

建立机制模块，用于采用数据处理任务调度引擎、任务执行引擎、数据映射规则模型建立数据处理机制；

输出模块，用于确定ETL处理脚本的实现工具并选定预设脚本工具实现数据处理。

在本发明的一些实施例中，上述包括：用于存储计算机指令的至少一个存储器；与上述存储器通讯的至少一个处理器，其中当上述至少一个处理器执行上述计算机指令时，上述至少一个处理器使上述系统执行：获取模块、选择模块、设计模块、建立机制模块以及输出模块。

相对于现有技术，本发明的实施例至少具有如下优点或有益效果：

其能够快速配置需要的数据集，通过前端配置助手，可以快速完成数据处理开发需求，为前端BI数据分析提供了强大、便捷的数据处理支撑平台，通过将数据开发从线下搬到了线上，系统运营的每个环节都能在线上实现，为企业IT整体数字化转型提供了有力的基础支撑。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本发明实施例提供的一种基于二维映射表的数据处理方法步骤示意图；

图2为本发明实施例提供的一种基于二维映射表的数据处理方法详细步骤示意图；

图3为本发明实施例提供的一种基于二维映射表的数据处理系统模块示意图。

图标：10-获取模块；20-选择模块；30-设计模块；40-建立机制模块；50-输出模块。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

下面结合附图，对本申请的一些实施方式作详细说明。在不冲突的情况下，下述的各个实施例及实施例中的各个特征可以相互组合。

实施例1

请参阅图1，图1为本发明实施例提供的一种基于二维映射表的数据处理方法步骤示意图，其如下所示：

步骤S100，获取来源数据采集范围和数据采集方式；

步骤S110，根据数据采集方式以及数据库产品确定模型；

具体的，选择对应的数据库，因为数据库不同，处理语法不同。

步骤S120，根据确定的模型建立数据的访问方式；

具体的，选择不同的端口进入，进入的是同一个模块，即数据应用服务和数据管控服务。

步骤S130，采用数据处理任务调度引擎、任务执行引擎、数据映射规则模型建立数据处理机制；

具体的，数据处理任务调度引擎用于梳理脚本处理顺序；任务执行引擎用于读规则，是一个执行者；数据映射规则模型是执行引擎可以去任务处理映射总表获取每个任务的处理步骤，根据处理步骤生成数据库能够识别的SQL语句集，且映射总表不循环，到update子表无论结果是否，都结束，这就是映射规则。例如，在代码部分中，数据源部分，存在一个条件语句，例如，当遇到了F_CUST_ACCT_INFO之类的表后，进行不同的执行动作。

在一些实施方式中，概念模型设计通常包括临时缓存层模型、ODS历史层模型、标准化数据层模型、应用集市层数据模型等等，上述的多个模型用于数据的分类存储，为现有技术，这里不再赘述。

步骤S140，确定ETL处理脚本的实现工具并选定预设脚本工具实现数据处理。

具体的，对应的模型为大数据平台的HIVE、ORACLE、SQL SERVER、MYSQL等模型；

预设脚本工具为perl，python，shell，dos等。

在一些实施方式中，包括三部分，第一部分为搭建基础数据平台，该基础平台为业务人员提供基础数据支撑，包括基础物理表和视图，以及搭建云视图库，平台数据处理系统。该平台通常由科技人员独立维护，保证业务应用的数据基础来源稳定可靠。

第二部分为搭建应用数据平台，业务人员在该平台之上可以实现数据的线上各种灵活加工处理。

第三部分为搭建数据处理管理和使用门户，科技人员利用管理门户管理平台的日常运营，普通用户通过平台实现数据的各种自动加工处理。

根据以上描述，低代码数据平台的实施和传统的数据平台实施方式类似通常由实施团队驻场根据客户需求客户化实施，其中会引入产品的部分或者全部功能帮助快速落地，当然部分产品功能可能会根据客户需求做客户化改造具体实施详情如下：

首先是需求阶段，需要对客户做业务应用调研和基本信息调研。业务应用调研主要是了解项目建设的业务背景，是为了某些业务场景例如精准营销，还是单纯的数据平台，是作为企业的数据服务中心还是有其他的原因。信息调研过程主要是梳理平台所涉及的数据源，以及数据源的数据采集方式。当然很多时候信息调研的范围由业务应用范围决定，企业为了尽快出成效，要求实施人员先将涉及应用需求的数据先采集到系统。还有一些其它的调研例如客户的产品选型意向、IT建设规范、系统上下游环境、内部相关规章制度等等。

调研之后就是系统设计针对客户的现有情况，参考产品设计理念，拟定系统建设方案。建设方案包括：来源数据采集范围和数据采集方式。系统数据库产品选型(例如大数据平台HIVE、ORACLE、SQL SERVER、MYSQL等等)。上线初，数据应用需求的满足，系统性能需求的满足。数据的访问方式设计，包括PC端、移动端等访问设计。数据的处理机制，这通常会采用已经开发好的部分产品功能例如数据处理任务调度引擎、任务执行引擎、数据映射规则模型等等。整个平台的概念模型设计，通常包括临时缓存层模型、ODS历史层模型、标准化数据层模型、应用集市层数据模型等等。确定ETL处理脚本的实现工具。系统不能保证所有的数据处理都是无代码的，需要选定用什么样的脚本工具实现数据处理，例如数据库存储过程，perl，python,shell,dos等等。整个平台物理软硬件环境设计通常包括硬件选型，软件数据库选型系统配置等等。平台管理端原型设计。平台应用端原型设计，流程设计。需要明确客户的功能需求中哪些可以使用现有产品、哪些需要对产品进行客户化改造、哪些需要现场开发。

设计完成之后进入系统开发阶段。开发阶段先要完成开发环境的搭建包括应用环境、数据库环境等等，然后是前端应用开发、后端应用开发、后台数据开发等等。

开发完成之后进入测试阶段，包括系统测试、集成联调测试、性能测试，最后是用户测试。上线前的演练和上线准备工作，系统上线，上线后的系统运维。

实施例2

请参阅图2，图2为本发明实施例提供的一种基于二维映射表的数据处理方法详细步骤示意图，其如下所示：

步骤S200，根据需求梳理平台涉及的数据源以及数据源的数据采集方式。

步骤S210，数据库产品选择对应大数据平台的HIVE、ORACLE、SQL SERVER、MYSQL模型。

步骤S220，业务人员或者系统运维人员通过PC端或者移动端访问设计。

步骤S230，建立create映射子表、delete映射子表、insert映射子表、update映射子表以及映射总表。

步骤S240，ETL执行引擎在任务处理映射总表获取每个任务的处理步骤。

步骤S250，根据处理步骤生成数据库能够识别的SQL语句集。

步骤S260，数据实验室环境和生产环境保持一致，并且与生产环境尽量物理隔离，计算存储资源相互独立，未经测试过的数据源配置通过数据实验室成功试验后投产运行。

在一些实施方式中，低代码平台基本上不在使用ETL脚本做数据处理，而是将ETL脚本中所包含数据处理信息存在事先设计好的二维映射表里，这种映射表通常称为MAPPING。当需要新增数据处理需求时只要配置好MAPPING就行。系统配有ETL执行引擎，会根据配置好的MAPPING,动态生成数据处理的SQL语句，然后提交给数据库去执行，并跟踪执行结果。

新的数据需求不再需要做线下代码开发，而是先通过线上数据模型配置(即MAPPING，数据处理映射表)，然后再由线上数据实验室测试，通过后自动部署投产，最终完成线上数据需求处理。其中，经过测试后的数据模型可以被其他用户调用(这是问题的关键后面会描述数据模型是如何共享的)。

代码数据平台主要技术核心是如何实现低代码的数据处理。一个数据任务处理通常(称为ETL过程)由多个DDL和DML过程组成。DDL通常用来创建表或者视图，DML主要是做数据处理，通常过程比较复杂，主要有insert、select、update、delete、merge等逻辑处理单元。在数据平台中ETL脚本大多是由多个DDL和DML语句组成，脚本之间的区别只是涵盖的DDL和DML信息不同，例如基于SQL SERVER数据库有如下两个脚本：

脚本1：

--DML-delete语句

delete from

dwdb.F_CUST_INFO where update_date＝’20201219’；

--DDL-create语句建临时表#F_CUST_INFO,#号表示临时表

select cust_no,cust_name,create_date,update_date into#F_CUST_INFO

from odsdb.L_CUST_INFO

where create_date＝’20201219’；

--DML-insert语句

Insert into dwdb.F_CUST_INFO(cust_no,cust_name,create_date,update_date)

select cust_no,cust_name,create_date,update_date FROM#F_CUST_INFO；

--DML-update语句,更新本次任务状态

Update dwdb.F_SYS_JOB_INFO

Set task_stat＝’success’

where task_name＝@task_name；

脚本2：

--DML-delete语句删除数据

delete from

dwdb.F_CUST_ACCT_INFO where update_date＝’20201219’；

--DDL-create语句建临时表#F_CUST_ACCT_INFO,#号表示临时表

select cust_no,acct_no,acct_name,create_date into#F_CUST_ACCT_INFO

from odsdb.L_CUST_ACCT_INFO

where create_date＝’20201219’；

--DML-insert语句

Insert into dwdb.F_CUST_ACCT_INFO(cust_no,acct_no,acct_name,create_date)

SELECT cust_no,acct_no,acct_name,create_date FROM#F_CUST_ACCT_INFO

WHERE create_date＝’20201219’；

--DML-update语句,更新本次任务状态

Update dwdb.F_SYS_JOB_INFO

Set task_stat＝’success’

Where task_name＝@task_name；

脚本1和脚本2都是由create、delete、insert和update语句构成，区别只是语句中操作的数据库对象不一样。假如现在将这些常用的DDL和DML语句中涵盖的数据库对象通过二维表(我们称它们为映射表)存起来，然后由一个执行引擎动态的根据二维表信息生成要执行的DDL和DML语句，然后提交给数据库执行它们，那样我们就去掉了原先静态的脚本代码。

以上脚本的相关二维映射表实例如下：

delete映射子表：

create映射子表：

insert映射子表：

update映射子表：

映射总表：

有了映射表之后，系统ETL执行引擎可以去任务处理映射总表获取每个任务的处理步骤，根据处理步骤生成数据库能够识别的SQL语句集。

脚本1和脚本2的具体执行流程为：执行器开始，任务总表获取任务执行步骤并判定是否成功执行，若否则结束，若是则去delete映射子表获取delete信息组成DML语句并执行，判定是否成功执行，若否则结束，若是则去create映射子表获取create信息组成DDL语句并执行，判定会否成功，若否则结束，若是则去insert映射子表获取insert信息组成DML语句并执行，判定是否成功执行，若否则结束，若是则去update映射子表获取update信息组成DML语句并执行，判定是否成功执行，若否则结束，若是则结束。

为数据平台增加了数据实验室，数据实验室环境和生产尽量完全一致，并且与生产环境尽量物理隔离，至少做到计算存储资源相互独立，任何未经测试过的数据源配置必须通过数据实验室成功试验后才能投产运行。当然选用平台内现存的独立物理表，做数据源时无需再进入实验室测试。

映射配置表中填的信息较多，其中主要是CREATE映射子表和insert映射子表的信息。为此我们提出数据云视图的概念，即任何能够被平台数据库识别并且能够执行产生结果的数据集描述都可以归为云视图。在系统中云视图包含如下来源：系统中存在的物理表(包括临时表)，系统中存在的，被使用过的视图，有过正确实验报告的数据集描述。在实际配置过程中系统会为配置人员自动提供存量的云视图，以及提供视图中涉及到的信息项去选择，以帮助快速配置好映射表。同时系统也会记住经过实验室正确试验过的所有数据集，来不断扩大系统云视图库。

当云视图涉及到物理表和字段发生变更时，系统也会将受之影响云视图从云视图库删除，以保证云视图的有效性和准确性。

由于系统的记忆功能，云视图库在使用的过程中会被逐步扩大和完善，为此，需要有一个合理的管理机制来管理它们，而且为了方便用户的使用，需要给每一个云视图制定一个关联物理表，具体存储模型如下：

客户可以通过上表中的关键字字段或者关联物理表字段查询相关的云视图。在系统使用初期，系统建设人员会为用户搭建常用的基础视图库。

通过观察上表中的数据源我们发现有些视图之间差异较小，例如序号1和2两个视图之间具有相同的关联表和相同的关联的条件，只是过滤条件不同。当视图1运行成功时，视图2的运行风险较小，可以认为视图2是视图1的扩展云视图。系统可以设置基础云视图的扩展视图无需经过实验室测试，而直接使用。

这样一来无需经过实验室试验的云视图包括：物理表；正在使用的数据库视图；经过实验室试验过的数据集描述；以上云视图的扩展。

随着用户的使用，系统记录的云视图越来越多，可以被扩展的云视图就更多，业务人员要配置的数据源基本上都能够在云视图库中找到。基于现有的云视图，系统会为用户自动生成一个云视图全量表，自动填在用户配置的映射子表中。

实施例3

请参阅图3，图3为本发明实施例提供的一种基于二维映射表的数据处理系统模块示意图，其如下所示：

获取模块10，用于获取来源数据采集范围和数据采集方式；

选择模块20，用于根据数据采集方式以及数据库产品选择对应的模型；

设计模块30，用于根据确定的模型建立数据的访问方式；

建立机制模块40，用于采用数据处理任务调度引擎、任务执行引擎、数据映射规则模型建立数据处理机制；

输出模块50，用于确定ETL处理脚本的实现工具并选定预设脚本工具实现数据处理。

还包括存储器、处理器和通信接口，该存储器、处理器和通信接口相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。存储器可用于存储软件程序及模块，处理器通过执行存储在存储器内的软件程序及模块，从而执行各种功能应用以及数据处理。该通信接口可用于与其他节点设备进行信令或数据的通信。

其中，存储器可以是但不限于，随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read-OnlyMemory，PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，EEPROM)等。

处理器可以是一种集成电路芯片，具有信号处理能力。该处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

可以理解，图3所示的结构仅为示意还可包括比图3中所示更多或者更少的组件，或者具有与图3所示不同的配置。图3中所示的各组件可以采用硬件、软件或其组合实现。

在本申请所提供的实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

综上所述，本申请实施例提供的一种基于二维映射表的数据处理方法及系统，其能够快速配置需要的数据集，通过前端配置助手，可以快速完成数据处理开发需求，为前端BI数据分析提供了强大、便捷的数据处理支撑平台，通过将数据开发从线下搬到了线上，系统运营的每个环节都能在线上实现，为企业IT整体数字化转型提供了有力的基础支撑。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其它的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

Claims

1.一种基于二维映射表的数据处理方法，其特征在于，包括：

获取来源数据采集范围和数据采集方式；

根据数据采集方式以及数据库产品确定模型；

根据确定的模型建立数据的访问方式；

采用数据处理任务调度引擎、任务执行引擎、数据映射规则模型建立数据处理机制；

确定ETL处理脚本的实现工具并选定预设脚本工具实现数据处理。

2.如权利要求1所述的一种基于二维映射表的数据处理方法，其特征在于，所述获取来源数据采集范围和数据采集方式包括：

根据需求梳理平台涉及的数据源以及数据源的数据采集方式。

3.如权利要求1所述的一种基于二维映射表的数据处理方法，其特征在于，所述数据库产品选择对应的模型包括：

数据库产品选择对应大数据平台的HIVE、ORACLE、SQL SERVER、MYSQL模型。

4.如权利要求1所述的一种基于二维映射表的数据处理方法，其特征在于，所述根据确定的模型建立数据的访问方式包括：

业务人员或者系统运维人员通过PC端或者移动端访问设计。

5.如权利要求1所述的一种基于二维映射表的数据处理方法，其特征在于，所述数据映射规则包括：

建立create映射子表、delete映射子表、insert映射子表、update映射子表以及映射总表。

6.如权利要求5所述的一种基于二维映射表的数据处理方法，其特征在于，还包括：

ETL执行引擎在任务处理映射总表获取每个任务的处理步骤。

7.如权利要求6所述的一种基于二维映射表的数据处理方法，其特征在于，还包括：

根据处理步骤生成数据库能够识别的SQL语句集。

8.如权利要求1所述的一种基于二维映射表的数据处理方法，其特征在于，还包括：

数据实验室环境和生产环境保持一致，并且与生产环境物理隔离，计算存储资源相互独立，未经测试过的数据源配置通过数据实验室成功试验后投产运行。

9.一种基于二维映射表的数据处理系统，其特征在于，包括：

获取模块，用于获取来源数据采集范围和数据采集方式；

设计模块，用于根据确定的模型建立数据的访问方式；

10.如权利要求9所述的一种基于二维映射表的数据处理系统，其特征在于，包括：

用于存储计算机指令的至少一个存储器；

与所述存储器通讯的至少一个处理器，其中当所述至少一个处理器执行所述计算机指令时，所述至少一个处理器使所述系统执行：获取模块、选择模块、设计模块、建立机制模块以及输出模块。