CN113238993A - 一种数据处理方法和装置 - Google Patents

Abstract

本发明公开了一种数据处理方法和装置，涉及计算机技术领域。该方法的一具体实施方式包括：接收机构传输的文件，获取机构的实际机构编码，查询与实际机构编码对应的虚拟机构编码；判断是否存在与虚拟机构编码相应的表路径，若存在，则将文件上传至所述表路径下；或若不存在，则基于预设路径字段和虚拟机构编码，构建表路径，将文件上传至表路径下。该实施方式以数据规模为划分标准，为各机构分配虚拟机构编码，将同数据规模的机构的文件落入同一虚拟池内，从源头上极大可能预防了数据倾斜问题，且将工程数量与机构数量脱钩，大幅缩减了所需建立的工程数量，以此提高系统运行时效。

Description

一种数据处理方法和装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种数据处理方法和装置。

背景技术

随着大数据技术的发展，各行业原本跨域、跨机构的孤岛数据都进行着或已完成了融合打通，以便全局的监管分析、统计、趋势判断等。无论是哪个领域，传输端主体(或称为传输机构)的数量通常远大于接收端主体的数量，如金融监管领域，多个合规端对应一个监管端，这种局面为各种数据报送方案的涌现提供了肥沃的土壤，甚至出现了非常成熟的商业化数据报送服务商。

然而站在接收端主体角度，其数据处理还未形成通用的解决方案，而各自领域在在海量、多源、大波动性三个维度上，有不同的现实情况，所以跨领域时往往不具备通用性。且并未对大型机构和小微机构进行区别对待，存在资源浪费情况。再者，机构的数据规模随时可能会发生变化，进而发生数据倾斜，面对这样的变动，目前也缺乏弹性措施来应对。

发明内容

有鉴于此，本发明实施例提供一种数据处理方法和装置，至少能够解决现有数据处理方式不具备通用性、未区分大小型机构和不具备措施处理数据倾斜情况的现象。

为实现上述目的，根据本发明实施例的一个方面，提供了一种数据处理方法，包括：接收机构传输的文件，获取所述机构的实际机构编码，查询与所述实际机构编码对应的虚拟机构编码；判断是否存在与所述虚拟机构编码相应的表路径，若存在，则将所述文件上传至所述表路径下；或若不存在，则基于预设路径字段和所述虚拟机构编码，构建表路径，将所述文件上传至所述表路径下。

可选的，在所述接收机构传输的文件之前，还包括：接收所述机构的接入请求，获取所述接入请求中的数据规模，确定所述数据规模所处的量级梯度范围，进而根据所述量级梯度范围确定分配给所述机构的虚拟机构编码。

可选的，所述根据所述量级梯度范围确定分配给所述机构的虚拟机构编码，包括：判断所述量级梯度范围是否为最大量级梯度范围；若判断结果为是，则将所述机构的实际机构编码作为虚拟机构编码，否则将与所述量级梯度范围对应的虚拟机构编码分配给所述机构。

可选的，对于将实际机构编码作为虚拟机构编码的机构，设置机构类型为独立，否则为虚拟。

可选的，表路径位于虚拟池内，虚拟池与虚拟机构编号对应；所述方法还包括：接收所述机构传输的新数据规模，判断所述新数据规模是否处于所述量级梯度范围内，若处于，则不作处理；若不处于，则触发机构融合拆分操作，以基于所述新数据规模重新确定新虚拟机构编码，并将所述虚拟池内与所述实际机构编码对应的历史数据，迁移到与所述新虚拟机构编码对应的新虚拟池内。

可选的，所述文件的文件名包括上传日期；所述将所述文件上传至所述表路径下，还包括：确定所述表路径下与所述上传日期对应的分区，将所述文件上传至所述分区内；所述将所述虚拟池内与所述实际机构编码对应的历史数据，迁移到与所述新虚拟机构编码对应的新虚拟池内，包括：在所述虚拟池的不同分区内，确定与所述实际机构编码对应的历史数据，将各历史数据迁移到所述新虚拟池中相同上传日期的分区内。

可选的，所述文件的文件名包括关键字段；所述判断是否存在与所述虚拟机构编码相应的表路径，包括：根据所述虚拟机构编码和所述关键字段，判断是否存在相应表路径；所述基于预设路径字段和所述虚拟机构编码，构建表路径，包括：基于所述预设路径字段、所述虚拟机构编码和所述关键字段，构建表路径。

可选的，所述文件名还包括所述实际机构编码。

可选的，还包括：以所述虚拟机构编码为粒度创建跑批工程，确定与所述虚拟机构编码对应的虚拟池，获取所述虚拟池内的多个表路径，进而利用所述跑批工程对多个表路径下的文件进行跑批处理。

可选的，在所述利用所述跑批工程对所述多个表路径下的文件进行跑批处理之后，还包括：接收所述机构对跑批结果的查询请求；其中，查询请求包括业务字段；查询与所述实际机构编码对应的虚拟机构编码，确定与所述虚拟机构编码对应的虚拟池，获取所述虚拟池内的多个表路径；从多个表路径中，查询与所述实际机构编码和所述业务字段对应的跑批结果。

可选的，还包括：在机构融合拆分操作和跑批工程之间加互斥锁。

为实现上述目的，根据本发明实施例的另一方面，提供了一种数据处理装置，包括：文件接收模块，用于接收机构传输的文件，获取所述机构的实际机构编码，查询与所述实际机构编码对应的虚拟机构编码；文件落库模块，用于判断是否存在与所述虚拟机构编码相应的表路径，若存在，则将所述文件上传至所述表路径下；或若不存在，则基于预设路径字段和所述虚拟机构编码，构建表路径，将所述文件上传至所述表路径下。

可选的，还包括机构打标模块，用于：接收所述机构的接入请求，获取所述接入请求中的数据规模，确定所述数据规模所处的量级梯度范围，进而根据所述量级梯度范围确定分配给所述机构的虚拟机构编码。

可选的，所述机构打标模块，用于：判断所述量级梯度范围是否为最大量级梯度范围；若判断结果为是，则将所述机构的实际机构编码作为虚拟机构编码，否则将与所述量级梯度范围对应的虚拟机构编码分配给所述机构。

可选的，对于将实际机构编码作为虚拟机构编码的机构，设置机构类型为独立，否则为虚拟。

可选的，表路径位于虚拟池内，虚拟池与虚拟机构编号对应；所述机构打标模块，还用于：接收所述机构传输的新数据规模，判断所述新数据规模是否处于所述量级梯度范围内，若处于，则不作处理；

所述装置还包括融合拆分模块，用于：若不处于，则触发机构融合拆分操作，以基于所述新数据规模重新确定新虚拟机构编码，并将所述虚拟池内与所述实际机构编码对应的历史数据，迁移到与所述新虚拟机构编码对应的新虚拟池内。

可选的，所述文件的文件名包括上传日期；所述文件落库模块，还用于：确定所述表路径下与所述上传日期对应的分区，将所述文件上传至所述分区内；所述融合拆分模块，用于：在所述虚拟池的不同分区内，确定与所述实际机构编码对应的历史数据，将各历史数据迁移到所述新虚拟池中相同上传日期的分区内。

可选的，所述文件的文件名包括关键字段；所述文件落库模块，用于：根据所述虚拟机构编码和所述关键字段，判断是否存在相应表路径；以及基于所述预设路径字段、所述虚拟机构编码和所述关键字段，构建表路径。

可选的，所述文件名还包括所述实际机构编码。

可选的，还包括工程调度模块，用于：以所述虚拟机构编码为粒度创建跑批工程，确定与所述虚拟机构编码对应的虚拟池，获取所述虚拟池内的多个表路径，进而利用所述跑批工程对多个表路径下的文件进行跑批处理。

可选的，还包括表路由查询模块，用于：接收所述机构对跑批结果的查询请求；其中，查询请求包括业务字段；查询与所述实际机构编码对应的虚拟机构编码，确定与所述虚拟机构编码对应的虚拟池，获取所述虚拟池内的多个表路径；从多个表路径中，查询与所述实际机构编码和所述业务字段对应的跑批结果。

可选的，还包括：在机构融合拆分操作和跑批工程之间加互斥锁。

可选的，包括：从系统架构中抽象出一个虚拟层，以在所述虚拟层内对机构进行数据处理操作。

为实现上述目的，根据本发明实施例的再一方面，提供了一种数据处理电子设备。

本发明实施例的电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述任一所述的数据处理方法。

为实现上述目的，根据本发明实施例的再一方面，提供了一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现上述任一所述的数据处理方法。

根据本发明所述提供的方案，上述发明中的一个实施例具有如下优点或有益效果：以数据规模为划分标准，为各机构分配虚拟机构编码，将同数据规模的机构的文件落入同一虚拟池内，从源头上极大可能预防了数据倾斜问题，且将工程数量与机构数量脱钩，大幅缩减了所需建立的工程数量，以此提高系统运行时效；即使发生数据倾斜，也能够采用弹性调整空间机制，重新确定新虚拟机构编码并迁移数据，保证机构数据查询可得。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是现有机构—工程模式数据流示意图；

图2根据本发明实施例的一种数据处理方法的主要流程示意图；

图3是不同机构同表名表结构的文件会落入到同一个表路径示意图；

图4是根据本发明实施例的一种可选的数据处理方法的流程示意图；

图5是根据本发明实施例的另一种可选的数据处理方法的流程示意图；

图6(a)是融合前，工程数量等于机构数量的示意图；

图6(b)是融合后，工程数量可自主规划的示意图；

图7是根据本发明实施例的又一种可选的数据处理方法的流程示意图；

图8是本发明实施例的数据处理模块结构框图；

图9是根据本发明实施例的一种数据处理装置的主要模块示意图；

图10是本发明实施例可以应用于其中的示例性系统架构图；

图11是适于用来实现本发明实施例的移动设备或服务器的计算机系统的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

对于本方案涉及的词语做解释如下：

stg层：用于存放从异构的源系统集成的表。

HDFS(Hadoop Distributed File System)：一种大数据领域广泛使用的分布式文件系统，传输的原始文件以及其后经过模型处理的结果表数据，都将存储在HDFS上。

hive：一种数据仓库工具，能将存在于HDFS上的结构化数据映射为一张数据库表，并提供SQL查询功能。

azkaban：一种开源的批量工作流调度器，主要以工程(project)组织，一个工程内可以有多个flows(工作流)，每个工作流可以包含多个job(作业)，作业可以是shell脚本或命令，多个作业可以按照特定的顺序执行。

此处对现有技术进行详细描述：

对于不满足海量高频特征的数据，通常会直接落入关系数据库，此处不做赘述。对于海量高频数据的传统处理方法：基于HDFS存储数据并映射到hive库表，然后跑批作业通过azkaban来调度，一般会经过如下流程：文件落库(HDFS)——自动建表及分区映射(hive)——创建机构专属project(azkaban)——执行project工作流(azkaban)——生成结果数据(hive)。

各机构传输的数据首先会落入各自指定的HDFS路径下，该路径的名称本身包含了机构的专属编码(即实际机构编码)，数据落地后触发自动建hive表的程序，由于hive表名本身与HDFS路径名也具备映射关系，所以最终每家机构都有其专属的一套表，即机构-路径-表，三者呈一一对应关系。待数据报送完毕，再为其创建并启动该机构专属的project工作流，系统内部产生的project数量完全取决于外部数据源(机构)的数量，整体来说，处于一种不可控状态。

以一家机构报送五张表数据为例，其数据处理结果参见图1所示。这种模式主要适用于数据来源较少的领域，如电信行业，假设有34个省级运营商，最终处理得到34个project，即34个完整图1流程，夜间跑批完全可以满足时效性要求。然而该模式难以应对具有多源特征的领域，例如金融征信，其上报机构数量众多且仍在不断增加，属于多源情况，但不属于高频海量情况，反之亦然。以支付监管场景为例：

假设全国有5000家银行及第三方支付机构，即表示每天需完成5000个project排队任务，得到5000张完整图1流程，在有限计算资源情况下，一定时长内(如一晚上)完成的难度较大。其次，该模式并没有对大型机构和小微机构进行区别对待，而hive本身比较适合批处理海量数据，不擅长一个个处理碎片数据，当动用与处理大型机构同样的跑批工程处理小微机构时，存在资源浪费情况。再者，机构的数据规模随时可能会发生变化，例如某个支付牌照被从A公司交易到B后，交易规模会发生巨变，进而发生数据倾斜，面对这样的变动，系统也缺乏弹性措施来应对。以上这些都不是图1所示上述机构—工程模式数据流所能解决的。

参见图2，示出的是本发明实施例提供的一种数据处理方法的主要流程图，包括如下步骤：

S201：接收机构传输的文件，获取所述机构的实际机构编码，查询与所述实际机构编码对应的虚拟机构编码；

S202：判断是否存在与所述虚拟机构编码相应的表路径，若存在，则将所述文件上传至所述表路径下；或

S203：若不存在，则基于预设路径字段和所述虚拟机构编码，构建表路径，将所述文件上传至所述表路径下。

上述实施方式中，对于步骤S201～S203，目前数据传输处理已涉及多个领域，如金融领域各金融机构上报征信数据、电信领域各省运营商给总部上报用户行为数据、教育机构各学校上报学生体质健康数据等。各领域的数据维度在日趋丰富，数据粒度在日趋细化，这意味着将来的数据逐渐可以同时具备海量、多源、大波动性特征。

以监管为例，过去仅分析各机构报送的经过高度汇总的统计数据，如各类日报、月报、季报、年报等，粒度较粗，数据规模较小，数据处理简单。而目前的监管，已将探针布局到每条具体交易粒度，导致数据规模暴增，即在以前多源基础上又增加了海量的特征，而这样的趋势变化，不会仅发生在监管领域。因而本方案提供的数据处理方法，不仅仅面向个例场景，更是面向未来趋势。

机构传输文件给SFTP(SSH File Transfer Protocol，安全文件传送协议)服务器，系统在SFTP服务器接收到文件后，并非现有技术中直接读取文件名并创建同名路径，而是首先读取org_rel表，根据该机构的实际机构编码real_orgcode，查询相应虚拟机构编码virtual_orgcode。

不同机构所传输文件的文件名，通常仅为实际机构编码的不同，例如实际机构编码_base，base即为关键字段。对虚拟机构编码、关键字段，结合预设路径字段，以拼接字符串的方式，在HDFS上创建hive表的stg层路径，若该表路径已存在则无需创建，否则继续创建。亦或者，直接基于虚拟机构编码查询是否存在相应表路径，若存在，则直接进行文件路由落库，否则创建表路径，之后再进行文件路由落库，本方案优选先查询后创建实施方式。进一步的，基于虚拟机构编码和关键字段查询是否存在相应表路径。

例如，机构C00001向系统传输文件，根据其real_orgcode，在org_rel表中查询到相应的virtual_orgcode为VIR001，为其在HDFS上创建表路径/user/hive/warehouse/stg.db/STG_VIR001_XXX_XXX_X表名(表命名规则由接收方统一设定)。后期当新增机构传输文件时，例如C00002，由于其与C00001共享同一个虚拟机构编码VIR001，而此时VIR001的表路径已创建，则直接将C00002传输的文件落入该表路径下即可。

需要说明的是，不同机构同关键字段表结构的文件会落入到同一个表路径下，如图3所示，机构C00001、C00002和C00003的虚拟机构编码均为VIR001，且均设有一张基础表A和一张流水表B，则文件C00001_A.TXT、C00002_A.TXT、C00003_A.TXT均落入STG_VIR001_AAA_XXX_X表内，文件C00001_B.TXT和C00002_B.TXT、C00003_B.TXT均落入STG_VIR001_BBB_XXX_X表内，以保证同一张表内数据结构的一致性，便于后续批量执行计算。

进一步的，为便于区分不同日期上传的文件，文件名中还可以包含上传日期。若查询/创建的表路径下已存在与该上传日期对应的分区，则无需创建，直接将文件路由落库至该分区，否则需创建，例如/user/hive/warehouse/stg.db/STG_VIR001_XXX_XXX_X/20210430。

上述实施例所提供的方法，创建表路径的依据，由机构的实际机构编码变为虚拟机构编码，使得原来需针对每个机构产生的表路径数量从不可控的机构数量，变为了可控的虚拟机构编码数量，在有限资源下保证了数据处理的时效。

参见图4，示出了根据本发明实施例的一种可选的数据处理方法流程示意图，包括如下步骤：

S401：接收机构的接入请求，获取所述接入请求中的数据规模，确定所述数据规模所处的量级梯度范围；

S402：判断所述量级梯度范围是否为最大量级梯度范围；

S403：若判断结果为是，则将所述机构的实际机构编码作为虚拟机构编码；

S404：否则将与所述量级梯度范围对应的虚拟机构编码分配给所述机构。

上述实施方式中，对于步骤S401～S404，实际情况下，每家机构每天都会向HDFS传输多张不同的表，为简化叙述，实施例默认每家机构每天传输一张表，但基本原理不变。

预先根据一个行业内各个机构的实际数据量级分布情况，划分量级梯度，划分的梯度数量将决定最终的虚拟池数量，一个虚拟池对应一个虚拟机构编码。本方案以支付监管为例(此处的数据规模为交易规模，交易规模越大所需上传的数据量越大)，全国共设有5000家机构，单日交易规模梯度假设划分为5个：0～1000000、1000001～10000000、10000001～1亿、1亿零1～2亿、2亿+。

其中，交易规模在2亿以上的机构虽数量较少，但一起打包处理的压力也较大，此类机构优选独立处理，为其创建独立的project，其他所有机构则依自身规模分别归属到4个梯度内，融合为4个虚拟池，每个虚拟池内各机构量级都处于同一水平。即2亿以下交易规模的机构共享一个虚拟机构编码，2亿以上交易规模的机构则独享一个编码，也即其实际机构编码。

假设5000家机构中超过2亿交易规模的机构共有3家，根据上述量级分布分析，逻辑上机构总数为7家，即虚拟机构*4+独立机构*3，后续仅创建7个project即可，而非5000。参见下表1所示，org_level_map为按照机构日交易规模进行划分以及在该划分方式下对应的虚拟机构编码体系，该对应关系表是后续图7机构融合拆分的基础依据。

表1 org_level_map

以机构交易规模作为划分标准，假设机构1～3为相似规模的3家机构，为其分配一个共同的virtual_orgcode:VIR001，机构4～6同理，为其分配另一个共同的virtual_orgcode:VIR002。但机构7由于交易规模大于2亿，属于独立机构，则其real_orgcode与virtual_orgcode一致，且org_type＝2，参见表2所示：

表2 org_rel

每个机构在首次接入系统时，都需要执行上述步骤，机构提供其数据规模，系统以此为依据并结合表1org_level_map，判定该机构为大型独立机构还是小微结构，最终在数据库mySQL中形成并维护一张org_rel表。

上述实施例所提供的方法，对于首次接入的机构按照其数据规模进行梯度划分，分配相应虚拟机构编码，以此通过虚拟池集中管理多个机构，实现可控规划，提升系统运行时效。

参见图5，示出了根据本发明实施例的另一种可选的数据处理方法流程示意图，包括如下步骤：

S501：接收机构传输的文件，获取所述机构的实际机构编码，查询与所述实际机构编码对应的虚拟机构编码；

S502：判断是否存在与所述虚拟机构编码相应的表路径，若存在，则将所述文件上传至所述表路径下；

S503：若不存在，则基于预设路径字段和所述虚拟机构编码，构建表路径，将所述文件上传至所述表路径下；

S504：以所述虚拟机构编码为粒度创建跑批工程，确定与所述虚拟机构编码对应的虚拟池；

S505：获取所述虚拟池内的多个表路径，进而利用所述跑批工程对多个表路径下的文件进行跑批处理；

S506：接收所述机构对跑批结果的查询请求；其中，查询请求包括业务字段；

S507：查询与所述实际机构编码对应的虚拟机构编码，确定与所述虚拟机构编码对应的虚拟池，获取所述虚拟池内的多个表路径；

S508：从多个表路径中，查询与所述实际机构编码和所述业务字段对应的跑批结果。

上述实施方式中，对于步骤S501～S503可参见图2所示描述，在此不再赘述。

上述实施方式中，对于步骤S504～S505，在将文件上传至相应表路径后，进入创建工程及调度跑批流程，该流程为常规的azkaban上创建project，并无特殊处理要求。需要说明的是，此处的project以virtual_orgcode为粒度创建，而非real_orgcode。

接图4所示举例，通过仅建立与虚拟机构编码对应的project，使得现有本该处理的5000个零散prject，变为了7个打包的整块project，以将现实中的碎片数据转换成整块的海量数据，并交给hive进行跑批处理。该种操作能够将工程数量与机构数量规模脱钩，以大幅度缩减所需建立的工程数量，具体参见图6(a)和图6(b)的对比。

例如，位于VIR001虚拟池内的文件，均由PRO001工程处理。由于同一虚拟池内各机构的文件，都是经过规模梯度划分后才上传至虚拟池的，因此在跑批计算过程中，发生数据倾斜的概率较低。只有当某家机构数据暴增或骤减时，才会对其所在虚拟池造成数据倾斜问题，具体处理过程参见后续图7所示描述。

对于步骤S506～S508，在跑批处理完毕后，产出的业务需要的各类结果表依然是virtual_orgcode粒度，即表名携带有virtual_orgcode信息。但各类机构并不知道有虚拟机构的存在，因而系统在对外提供查询接口以供机构查询数据时，需再次借助org_rel表，利用机构提供的real_orgcode，找到对应的virtual_orgcode，从与virtual_orgcode对应的虚拟池中查找与该real_orgcode对应的跑批结果。

实际操作中，机构发起的查询请求中包含有业务字段，如业务查询范围、查询时间等，有些情况下也会包含其real_orgcode。在虚拟池中查找跑批结果，即在虚拟池内的多个表路径下，查找与机构的real_orgcode和业务字段对应的跑批结果。

进一步的，查询过程中可以将virtual_orgcode、real_orgcode和业务查询字段，拼接并封装为固定的SQL查询语句，以该SQL查询语句在虚拟池中查询即可。

上述实施例所提供的方法，利用虚拟机构编码对多个机构进行融合处理，以将不同量级机构的数据文件，落入虚拟层中不同的虚拟池内，能够大幅度降低所需建立的跑批工程数量，并有效预防数据倾斜情况，实现了各机构的独立查询。

参见图7，示出了根据本发明实施例的又一种可选的数据处理方法流程示意图，包括如下步骤：

S701：接收机构的接入请求，获取所述接入请求中的数据规模，确定所述数据规模所处的量级梯度范围，进而根据所述量级梯度范围确定分配给所述机构的虚拟机构编码；

S702：接收所述机构传输的文件，获取所述机构的实际机构编码，查询与所述实际机构编码对应的虚拟机构编码；

S703：判断是否存在与所述虚拟机构编码相应的表路径，若存在，则将所述文件上传至所述表路径下；

S704：若不存在，则基于预设路径字段和所述虚拟机构编码，构建表路径，将所述文件上传至所述表路径下；其中，表路径位于虚拟池内，虚拟池与虚拟机构编号对应；

S705：接收所述机构传输的新数据规模，判断所述新数据规模是否处于所述量级梯度范围内，若处于，则不作处理；

S706：若不处于，则触发机构融合拆分操作，以基于所述新数据规模重新确定新虚拟机构编码；

S707：将所述虚拟池内与所述实际机构编码对应的历史数据，迁移到与所述新虚拟机构编码对应的新虚拟池内。

上述实施方式中，对于步骤S701可参见图4所示描述，步骤S702～S704可参见图2所示描述，在此不再赘述。

上述实施方式中，对于步骤S705～S707，前述描述已提到，机构在接入系统时需提供其数据规模等基本信息，系统依据该数据规模为其分配虚拟机构编码。然而此种规避数据倾斜的方法并不能一劳永逸，当某家机构本身业务量暴增或骤减，其所在的虚拟池整体在跑批处理时易发生数据倾斜。

例如，机构C00001的数据规模一直在百万以下，归属VIR001虚拟池，但当其被收购并全量引流后，日交易规模平稳维持在1亿+，此时若机构C00001的数据仍继续上传至VIR001虚拟池并由PRO001跑批工程处理，必然会对VIR001造成严重的数据倾斜问题。

针对该问题，本方案设置有“机构融合拆分模块”来重新恢复数据平衡，该模块以azkaban上的一个project形式存在，但不会将其加入定时调度，仅在需要时点击/触发执行即可。该project是多个shell脚本的集合，这些shell主要完成以下两个工作：

1、修改org_rel表，重新确定新的虚拟机构编码，以便后续该机构报送文件时，可据此将文件分流到适配的新虚拟池内。

上述举例中的C00001，在交易规模暴增到1亿+以后，与原先量级梯度范围0～1000000不匹配，其virtual_orgcode需由VIR001修改为VIR004。若交易规模超过2亿，属于独立机构，则将virtual_orgcode修改为实际机构编码，即C00001，此时org_type也需修改为2。

2、进行数据迁移工作，保证数据的连续性及查询可得

根据图2描述可知，为区分不同日期上传的文件，表路径下根据上传日期进行分区设置。因而在原虚拟池的各分区内，可能均包含有该机构的历史数据(可以是文件形式、数据形式或其他形式)，而该机构在更新虚拟机构编码后，新数据均落库至新虚拟池，造成该机构的一部分数据仍位于原虚拟池，另一部分落入新虚拟池。且由于org_rel表中该机构虚拟机构编码(和org_type)的修改，用户只能查询到新虚拟池内该机构的新数据，所以需将原虚拟池内该机构的历史数据，逐层、逐表、逐分区地迁移到新虚拟池内相同日期的分区内。后续用户查询时，即可得到所需所有数据，且对迁移本身无感知。

上述机构融合拆分所需shell脚本开发难度较低，整体封装在一个project时，需要注意的是：

1、设置参数入口，运维人员只需传入待融合/拆分的实际机构编码和目标虚拟池编码两个参数即可；

2、与正常跑批工程之间加互斥锁：机构融合拆分工程包含数据迁移功能，执行该功能时，若有其他工程处于跑批状态，会产生数据混乱问题。

上述实施例所提供的方法，应对数据倾斜及波动性问题，传统解决倾斜问题仅从技术角度出发调参，很容易遇到瓶颈，而本方案从业务角度入手，将机构的历史数据迁移至适配当前数据规模的新虚拟池或将其独立出虚拟池，通过灵活的弹性调整空间以达到新的平衡态。

本发明实施例所提供的方法，相比现有技术，至少存在如下有益效果：

1、抽象出一个虚拟层进行机构数据处理操作，从传统的对每个机构独立处理变为将数个机构打包处理，即从传统的每次一个包裹运输n次，到n个包裹一起运输，以将外部数据的多源不可控问题转为内部可控，实现大数据中对海量多源数据的高效处理目的；

2、接入机构数据时并未直接落库，而是首先按照机构数据规模进行分类，将同数据规模的机构的文件落入同一虚拟池内，从源头上最大可能的预防了数据倾斜问题；且将工程数量与机构数量脱钩，大幅降低建立的工程数量，以此提升系统运行时效；

3、在业务发生变化导致数据倾斜时，不再单纯依靠hive调参或在SQL层面增加随机数等传统办法，而是直接从业务角度切入，迁移机构的历史数据到合适规模的虚拟池内，从导致数据倾斜的根因上保障了优化效果。另外，调参和修改SQL需要一定的开发基础和工作量，并且优化空间很有限，但迁移机构历史数据经过简单说明即可上手。

参见图8，示出了本发明实施例的数据处理模块结构框图，包括机构打标模块、文件接收/落库模块、虚拟层模块、工程调度模块、表路由查询模块以及融合拆分模块。

整体流程：

第一步，在机构打标模块，将首次接入系统的机构按照数据规模进行分类，分配相应虚拟机构编码；

第二步，通过文件接收/落库模块，将不同量级机构报送的文件，落入虚拟层中不同的虚拟池内；同一量级机构报送的文件，落入同一虚拟池内；

第三步：在工程调度模块，以虚拟机构编码为单位创建跑批工程，打包处理同一虚拟池内各家机构的数据，运行业务需求的各类规则模型进行跑批处理，生成跑批结果；

第四步：查询跑批结果时，通过表路由模块，再次借助org_rel表，由具体机构定位到相应虚拟表并查出具体机构数据。

第五步，在日常数据处理过程中，一旦个别机构由于数据规模巨变导致数据倾斜时，可通过融合拆分模块，将该机构的历史数据从原虚拟池迁移到适配当前数据规模的虚拟池或将其独立出虚拟池，以达到新的平衡态。

参见图9，示出了本发明实施例提供的一种数据处理装置900的主要模块示意图，包括：

文件接收模块901，用于接收机构传输的文件，获取所述机构的实际机构编码，查询与所述实际机构编码对应的虚拟机构编码；

文件落库模块902，用于判断是否存在与所述虚拟机构编码相应的表路径，若存在，则将所述文件上传至所述表路径下；或若不存在，则基于预设路径字段和所述虚拟机构编码，构建表路径，将所述文件上传至所述表路径下。

本发明实施装置还包括机构打标模块，用于：

接收所述机构的接入请求，获取所述接入请求中的数据规模，确定所述数据规模所处的量级梯度范围，进而根据所述量级梯度范围确定分配给所述机构的虚拟机构编码。

本发明实施装置中，所述机构打标模块，用于：

判断所述量级梯度范围是否为最大量级梯度范围；

若判断结果为是，则将所述机构的实际机构编码作为虚拟机构编码，否则将与所述量级梯度范围对应的虚拟机构编码分配给所述机构。

本发明实施装置还包括：对于将实际机构编码作为虚拟机构编码的机构，设置机构类型为独立，否则为虚拟。

本发明实施装置中，表路径位于虚拟池内，虚拟池与虚拟机构编号对应；

所述机构打标模块，还用于：接收所述机构传输的新数据规模，判断所述新数据规模是否处于所述量级梯度范围内，若处于，则不作处理；

所述装置还包括融合拆分模块，用于：若不处于，则触发机构融合拆分操作，以基于所述新数据规模重新确定新虚拟机构编码，并将所述虚拟池内与所述实际机构编码对应的历史数据，迁移到与所述新虚拟机构编码对应的新虚拟池内。

本发明实施装置中，所述文件的文件名包括上传日期；

所述文件落库模块902，还用于：确定所述表路径下与所述上传日期对应的分区，将所述文件上传至所述分区内；

所述融合拆分模块，用于：在所述虚拟池的不同分区内，确定与所述实际机构编码对应的历史数据，将各历史数据迁移到所述新虚拟池中相同上传日期的分区内。

本发明实施装置中，所述文件的文件名包括关键字段；

所述文件落库模块902，用于：根据所述虚拟机构编码和所述关键字段，判断是否存在相应表路径；以及

基于所述预设路径字段、所述虚拟机构编码和所述关键字段，构建表路径。

本发明实施装置中，所述文件名还包括所述实际机构编码。

本发明实施装置还包括工程调度模块，用于：

以所述虚拟机构编码为粒度创建跑批工程，确定与所述虚拟机构编码对应的虚拟池，获取所述虚拟池内的多个表路径，进而利用所述跑批工程对多个表路径下的文件进行跑批处理。

本发明实施装置还包括表路由查询模块，用于：

接收所述机构对跑批结果的查询请求；其中，查询请求包括业务字段；

查询与所述实际机构编码对应的虚拟机构编码，确定与所述虚拟机构编码对应的虚拟池，获取所述虚拟池内的多个表路径；

从多个表路径中，查询与所述实际机构编码和所述业务字段对应的跑批结果。

本发明实施装置还包括：在机构融合拆分操作和跑批工程之间加互斥锁。

本发明实施装置包括：从系统架构中抽象出一个虚拟层，以在所述虚拟层内对机构进行数据处理操作。

另外，在本发明实施例中所述装置的具体实施内容，在上面所述方法中已经详细说明了，故在此重复内容不再说明。

图10示出了可以应用本发明实施例的示例性系统架构1000，包括终端设备1001、1002、1003，网络1004和服务器1005(仅仅是示例)。

终端设备1001、1002、1003可以是具有显示屏并且支持网页浏览的各种电子设备，安装有各种通讯客户端应用，用户可以使用终端设备1001、1002、1003通过网络1004与服务器1005交互，以接收或发送消息等。

网络1004用以在终端设备1001、1002、1003和服务器1005之间提供通信链路的介质。网络1004可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

服务器1005可以是提供各种服务的服务器，用于执行为机构划分虚拟机构编码、为结构文件落库、跑批处理和查询跑批结果、倾斜时结构融合拆分操作。

需要说明的是，本发明实施例所提供的方法一般由服务器1005执行，相应地，装置一般设置于服务器1005中。

应该理解，图10中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

下面参考图11，其示出了适于用来实现本发明实施例的终端设备的计算机系统1100的结构示意图。图11示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图11所示，计算机系统1100包括中央处理单元(CPU)1101，其可以根据存储在只读存储器(ROM)1102中的程序或者从存储部分1108加载到随机访问存储器(RAM)1103中的程序而执行各种适当的动作和处理。在RAM 1103中，还存储有系统1100操作所需的各种程序和数据。CPU 1101、ROM 1102以及RAM 1103通过总线1104彼此相连。输入/输出(I/O)接口1105也连接至总线1104。

以下部件连接至I/O接口1105：包括键盘、鼠标等的输入部分1106；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1107；包括硬盘等的存储部分1108；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1109。通信部分1109经由诸如因特网的网络执行通信处理。驱动器1110也根据需要连接至I/O接口1105。可拆卸介质1111，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1110上，以便于从其上读出的计算机程序根据需要被安装入存储部分1108。

特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1109从网络上被下载和安装，和/或从可拆卸介质1111被安装。在该计算机程序被中央处理单元(CPU)1101执行时，执行本发明的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括文件接收模块、文件落库模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，文件落库模块还可以被描述为“文件落库表路径模块”。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：

接收机构传输的文件，获取所述机构的实际机构编码，查询与所述实际机构编码对应的虚拟机构编码；

判断是否存在与所述虚拟机构编码相应的表路径，若存在，则将所述文件上传至所述表路径下；或若不存在，则基于预设路径字段和所述虚拟机构编码，构建表路径，将所述文件上传至所述表路径下。

根据本发明实施例的技术方案，至少存在如下有益效果：

1、抽象出一个虚拟层进行机构数据处理操作，从传统的对每个机构独立处理变为将数个机构打包处理，即从传统的每次一个包裹运输n次，到n个包裹一起运输，以将外部数据的多源不可控问题转为内部可控，实现大数据中对海量多源数据的高效处理目的；

2、接入机构数据时并未直接落库，而是首先按照机构数据规模进行分类，将同数据规模的机构的文件落入同一虚拟池内，从源头上最大可能的预防了数据倾斜问题；且将工程数量与机构数量脱钩，大幅降低建立的工程数量，以此提升系统运行时效；

3、在业务发生变化导致数据倾斜时，不再单纯依靠hive调参或在SQL层面增加随机数等传统办法，而是直接从业务角度切入，迁移机构的历史数据到合适规模的虚拟池内，从导致数据倾斜的根因上保障了优化效果。另外，调参和修改SQL需要一定的开发基础和工作量，并且优化空间很有限，但迁移机构历史数据经过简单说明即可上手。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (26)

1.一种数据处理方法，其特征在于，包括：

接收机构传输的文件，获取所述机构的实际机构编码，查询与所述实际机构编码对应的虚拟机构编码；

判断是否存在与所述虚拟机构编码相应的表路径，若存在，则将所述文件上传至所述表路径下；或

若不存在，则基于预设路径字段和所述虚拟机构编码，构建表路径，将所述文件上传至所述表路径下。

2.根据权利要求1所述的方法，其特征在于，在所述接收机构传输的文件之前，还包括：

接收所述机构的接入请求，获取所述接入请求中的数据规模，确定所述数据规模所处的量级梯度范围，进而根据所述量级梯度范围确定分配给所述机构的虚拟机构编码。

3.根据权利要求2所述的方法，其特征在于，所述根据所述量级梯度范围确定分配给所述机构的虚拟机构编码，包括：

判断所述量级梯度范围是否为最大量级梯度范围；

若判断结果为是，则将所述机构的实际机构编码作为虚拟机构编码，否则将与所述量级梯度范围对应的虚拟机构编码分配给所述机构。

4.根据权利要求3所述的方法，其特征在于，还包括：对于将实际机构编码作为虚拟机构编码的机构，设置机构类型为独立，否则为虚拟。

5.根据权利要求2所述的方法，其特征在于，表路径位于虚拟池内，虚拟池与虚拟机构编号对应；

所述方法还包括：

接收所述机构传输的新数据规模，判断所述新数据规模是否处于所述量级梯度范围内，若处于，则不作处理；

若不处于，则触发机构融合拆分操作，以基于所述新数据规模重新确定新虚拟机构编码，并将所述虚拟池内与所述实际机构编码对应的历史数据，迁移到与所述新虚拟机构编码对应的新虚拟池内。

6.根据权利要求5所述的方法，其特征在于，所述文件的文件名包括上传日期；

所述将所述文件上传至所述表路径下，还包括：确定所述表路径下与所述上传日期对应的分区，将所述文件上传至所述分区内；

所述将所述虚拟池内与所述实际机构编码对应的历史数据，迁移到与所述新虚拟机构编码对应的新虚拟池内，包括：在所述虚拟池的不同分区内，确定与所述实际机构编码对应的历史数据，将各历史数据迁移到所述新虚拟池中相同上传日期的分区内。

7.根据权利要求1所述的方法，其特征在于，所述文件的文件名包括关键字段；

所述判断是否存在与所述虚拟机构编码相应的表路径，包括：根据所述虚拟机构编码和所述关键字段，判断是否存在相应表路径；

所述基于预设路径字段和所述虚拟机构编码，构建表路径，包括：基于所述预设路径字段、所述虚拟机构编码和所述关键字段，构建表路径。

8.根据权利要求6或7所述的方法，其特征在于，所述文件名还包括所述实际机构编码。

9.根据权利要求1所述的方法，其特征在于，还包括：

以所述虚拟机构编码为粒度创建跑批工程，确定与所述虚拟机构编码对应的虚拟池，获取所述虚拟池内的多个表路径，进而利用所述跑批工程对多个表路径下的文件进行跑批处理。

10.根据权利要求9所述的方法，其特征在于，在所述利用所述跑批工程对所述多个表路径下的文件进行跑批处理之后，还包括：

接收所述机构对跑批结果的查询请求；其中，查询请求包括业务字段；

查询与所述实际机构编码对应的虚拟机构编码，确定与所述虚拟机构编码对应的虚拟池，获取所述虚拟池内的多个表路径；

从多个表路径中，查询与所述实际机构编码和所述业务字段对应的跑批结果。

11.根据权利要求5或9所述的方法，其特征在于，还包括：在机构融合拆分操作和跑批工程之间加互斥锁。

12.根据权利要求1所述的方法，其特征在于，包括：从系统架构中抽象出一个虚拟层，以在所述虚拟层内对机构进行数据处理操作。

13.一种数据处理装置，其特征在于，包括：

文件接收模块，用于接收机构传输的文件，获取所述机构的实际机构编码，查询与所述实际机构编码对应的虚拟机构编码；

文件落库模块，用于判断是否存在与所述虚拟机构编码相应的表路径，若存在，则将所述文件上传至所述表路径下；或若不存在，则基于预设路径字段和所述虚拟机构编码，构建表路径，将所述文件上传至所述表路径下。

14.根据权利要求13所述的装置，其特征在于，还包括机构打标模块，用于：

接收所述机构的接入请求，获取所述接入请求中的数据规模，确定所述数据规模所处的量级梯度范围，进而根据所述量级梯度范围确定分配给所述机构的虚拟机构编码。

15.根据权利要求14所述的装置，其特征在于，所述机构打标模块，用于：

判断所述量级梯度范围是否为最大量级梯度范围；

若判断结果为是，则将所述机构的实际机构编码作为虚拟机构编码，否则将与所述量级梯度范围对应的虚拟机构编码分配给所述机构。

16.根据权利要求15所述的装置，其特征在于，还包括：对于将实际机构编码作为虚拟机构编码的机构，设置机构类型为独立，否则为虚拟。

17.根据权利要求14所述的装置，其特征在于，表路径位于虚拟池内，虚拟池与虚拟机构编号对应；

所述机构打标模块，还用于：接收所述机构传输的新数据规模，判断所述新数据规模是否处于所述量级梯度范围内，若处于，则不作处理；

所述装置还包括融合拆分模块，用于：若不处于，则触发机构融合拆分操作，以基于所述新数据规模重新确定新虚拟机构编码，并将所述虚拟池内与所述实际机构编码对应的历史数据，迁移到与所述新虚拟机构编码对应的新虚拟池内。

18.根据权利要求17所述的装置，其特征在于，所述文件的文件名包括上传日期；

所述文件落库模块，还用于：确定所述表路径下与所述上传日期对应的分区，将所述文件上传至所述分区内；

所述融合拆分模块，用于：在所述虚拟池的不同分区内，确定与所述实际机构编码对应的历史数据，将各历史数据迁移到所述新虚拟池中相同上传日期的分区内。

19.根据权利要求13所述的装置，其特征在于，所述文件的文件名包括关键字段；

所述文件落库模块，用于：根据所述虚拟机构编码和所述关键字段，判断是否存在相应表路径；以及

基于所述预设路径字段、所述虚拟机构编码和所述关键字段，构建表路径。

20.根据权利要求18或19所述的装置，其特征在于，所述文件名还包括所述实际机构编码。

21.根据权利要求13所述的装置，其特征在于，还包括工程调度模块，用于：

以所述虚拟机构编码为粒度创建跑批工程，确定与所述虚拟机构编码对应的虚拟池，获取所述虚拟池内的多个表路径，进而利用所述跑批工程对多个表路径下的文件进行跑批处理。

22.根据权利要求21所述的装置，其特征在于，还包括表路由查询模块，用于：

接收所述机构对跑批结果的查询请求；其中，查询请求包括业务字段；

查询与所述实际机构编码对应的虚拟机构编码，确定与所述虚拟机构编码对应的虚拟池，获取所述虚拟池内的多个表路径；

从多个表路径中，查询与所述实际机构编码和所述业务字段对应的跑批结果。

23.根据权利要求15或21所述的装置，其特征在于，还包括：在机构融合拆分操作和跑批工程之间加互斥锁。

24.根据权利要求13所述的装置，其特征在于，包括：从系统架构中抽象出一个虚拟层，以在所述虚拟层内对机构进行数据处理操作。

25.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-12中任一所述的方法。

26.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1-12中任一所述的方法。

Images