运营数据监管方法和运营数据监管系统

技术领域

本公开涉及数据交互技术领域，特别涉及一种运营数据监管方法和运营数据监管系统。

背景技术

为方便对一定区域或一定行业的运营数据进行有效管理，运营管理系统应运而生。其中，运营管理系统的核心为运营数据监管系统，运营数据监管系统可对底层平台的相关数据信息(例如，静态资产数据、动态运营数据等)进行监管。其中，底层平台的动态运营数据的数据量巨大且极其重要，因此针对动态运营数据制定合理、高效的监管策略，是构建运营数据监管系统过程中亟需需要解决的问题之一

发明内容

本公开旨在至少解决现有技术中存在的技术问题之一，提出了一种运营数据监管方法和运营数据监管系统。

第一方面，本公开实施例提供了一种运营数据监管方法，其中，包括：

获取目标底层平台上报的目标动态运营信息，所述目标动态运营信息包括：目标动态运营数据、所述目标底层平台所属企业的目标企业ID、所述目标底层平台的目标平台ID和所述目标动态运营数据所对应的目标唯一交互ID；

检测数据库中是否已存储有企业ID为所述目标企业ID、平台ID为所述目标平台ID且唯一交互ID为所述目标唯一交互ID的动态运营信息；

在检测到所述数据库中已存储有企业ID为所述目标企业ID、平台ID为所述目标平台ID且唯一交互ID为所述目标唯一交互ID的动态运营信息时，则向所述目标底层平台反馈用于表征动态运营信息重复上报的第一提示信息，所述第一提示信息中包括有所述目标唯一交互ID；

在检测到所述数据库中未存储有企业ID为所述目标企业ID、平台ID为所述目标平台ID且唯一交互ID为所述目标唯一交互ID的动态运营信息时，则验证所述目标动态运营数据的完整性和有效性，并在所述目标动态运营数据的完整性验证通过以及有效性验证通过时，将所述目标动态运营信息存储至所述数据库中。

在一些实施例中，在获取目标底层平台上报的目标动态运营信息的步骤之后，还包括：

获取缓存中所记录的所述目标底层平台上一次上报的动态运营信息所对应唯一交互ID；

判断所述目标唯一交互ID与所述目标底层平台上一次上报的动态运营信息所对应唯一交互ID是否一致；

若一致，则向所述目标底层平台反馈所述第一提示信息；

若不一致，则将缓存中所记录的所述目标底层平台上一次上报的动态运营信息更新为所述目标唯一交互ID，并执行所述检测数据库中是否已存储有企业ID为所述目标企业ID、平台ID为所述目标平台ID且唯一交互ID为所述目标唯一交互ID的动态运营信息的步骤。

在一些实施例中，在获取目标底层平台上报的目标动态运营信息之后，且在检测数据库中是否已存储有企业ID为所述目标企业ID、平台ID为所述目标平台ID且唯一交互ID为所述目标唯一交互ID的动态运营信息的步骤之前，还包括：

初步判断所述目标动态运营信息的数据结构以及预设关键字段是否存在异常；

若判断出所述目标动态运营信息的数据结构和预设关键字段中至少之一存在异常时，则向所述目标底层平台反馈表征动态运营信息存在数据异常的提示信息；

若判断出所述目标动态运营信息的数据结构和预设关键字段中均正常时，则执行检测数据库中是否已存储有企业ID为所述目标企业ID、平台ID为所述目标平台ID且唯一交互ID为所述目标唯一交互ID的动态运营信息的步骤。

在一些实施例中，在检测到所述数据库中未存储有企业ID为所述目标企业ID、平台ID为所述目标平台ID且唯一交互ID为所述目标唯一交互ID的动态运营信息时，并在验证所述目标动态运营数据的完整性和有效性的步骤之前，还包括：

将所述目标动态运营信息保存至消息系统，并向所述目标底层平台发送用于表征所述目标动态运营信息已被成功接收的第二提示信息，所述第二提示信息中包括有所述目标唯一交互ID；

以及，响应于所述消息系统内位于所述目标动态运营信息之前的信息完成相应处理，从所述消息系统内获取所述目标动态运营信息。

在一些实施例中，验证所述目标动态运营数据的完整性和有效性的步骤包括：

验证所述目标动态运营数据的完整性；

在所述目标动态运营数据的完整性验证失败时，向所述目标底层平台发送用于表征所述目标动态运营数据的完整性验证失败的第三提示信息，所述第三提示信息包括有所述目标唯一交互ID；

在所述目标动态运营数据的完整性验证通过时，进一步验证所述目标动态运营数据的有效性；

在所述目标动态运营数据的有效性验证失败时，向所述目标底层平台发送用于表征所述目标动态运营数据的有效性验证失败的第四提示信息，所述第四提示信息包括有所述目标唯一交互ID。

在一些实施例中，在获取目标底层平台上报的目标动态运营信息的步骤之前，还包括：

获取目标企业账户的平台添加请求，所述平台添加请求中包括待添加的所述目标底层平台的目标平台ID；

对所述平台添加请求的有效性进行审核，并在所述平台添加请求的有效性审核通过后，在联调环境下与所述目标底层平台进行联调测试；

响应于与所述目标底层平台进行联调测试的所有接口交互均正常时，与所述目标底层平台进行生产环境对接。

在一些实施例中，所述平台添加请求中还包括有所述目标底层平台的目标静态资产信息；

所述方法还包括：

响应于与所述目标底层平台进行联调测试的所有接口交互均正常时，在联调环境下审核所述目标静态资产信息的真实性；

在所述目标静态资产信息的真实性审核通过后，将所述目标静态资产信息进行录入存储，以同步到生产环境。

在一些实施例中，还包括：

每隔预设周期向所述目标底层平台发送静态资产更新指令；

接收所述目标底层平台所反馈的更新后的目标静态资产信息；

在联调环境下审核更新后的目标静态资产信息的真实性；

在更新后的目标静态资产信息的真实性审核通过后，根据更新后的目标静态资产信息对已录入存储的所述目标底层平台的目标静态资产信息进行更新，以同步到生产环境。

在一些实施例中，在所述平台添加请求的有效性审核通过后，且在联调环境下与所述目标底层平台进行联调测试的步骤之前，还包括：

生成与所述目标底层平台相对应的两套数据通信密钥，并将所述两套数据通信密钥中的一套数据通信密钥内的第一加密密钥以及另一套数据通信密钥内的第二解密密钥发送给所述目标底层平台。

第二方面，本公开实施例提供了一种运营数据监管系统，用于实现如第一方面中提供的所述运营数据监管方法，所述运营数据监管系统包括：

动态信息获取模块，配置为获取目标底层平台上报的目标动态运营信息，所述目标动态运营信息包括：目标动态运营数据、所述目标底层平台所属企业的目标企业ID、所述目标底层平台的目标平台ID和所述目标动态运营数据所对应的目标唯一交互ID；

动态信息检测模块，配置为检测数据库中是否已存储有企业ID为所述目标企业ID、平台ID为所述目标平台ID且唯一交互ID为所述目标唯一交互ID的动态运营信息；

第一提示模块，配置为在检测到所述数据库中已存储有企业ID为所述目标企业ID、平台ID为所述目标平台ID且唯一交互ID为所述目标唯一交互ID的动态运营信息时，则向所述目标底层平台反馈用于表征动态运营信息重复上报的第一提示信息，所述第一提示信息中包括有所述目标唯一交互ID；

验证及存储模块，配置为在检测到所述数据库中未存储有企业ID为所述目标企业ID、平台ID为所述目标平台ID且唯一交互ID为所述目标唯一交互ID的动态运营信息时，则验证所述目标动态运营数据的完整性和有效性，并在所述目标动态运营数据的完整性验证通过以及有效性验证通过时，将所述目标动态运营信息存储至所述数据库中。

附图说明

图1为本公开所涉及的一种运营管理系统的结构框图；

图2A和图2B分别为本公开实施例提供的两种运营数据监控方法的流程图；

图3为本公开实施例中步骤S4的一种可选实现方法的流程图；

图4A和图4B为本公开实施例提供的另两种运营数据监控方法的流程图；

图5为本公开实施例提供的又一种运营数据监控方法的流程图；

图6为本公开实施例提供的一种运营数据监管系统的结构框图；

图7为本公开实施例的一种电子设备的结构示意图。

具体实施方式

为使本领域技术人员更好地理解本公开的技术方案，下面结合附图和具体实施方式对本公开作进一步详细描述。

除非另外定义，本公开使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本公开中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。同样，“一个”、“一”或者“该”等类似词语也不表示数量限制，而是表示存在至少一个。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系，当被描述目标的绝对位置改变后，则该相对位置关系也可能相应地改变。

在各个附图中，相同的元件采用类似的附图标记来表示。为了清楚起见，附图中的各个部分并没有都按比例绘制。此外，在图中可能未示出某些公知的部分。

在下文中描述了本公开的许多特定的细节，例如部件的结构、材料、尺寸、处理工艺和技术，以便更清楚地理解本公开。但正如本领域的技术人员能够理解的那样，可以不按照这些特定的细节来实现本公开。

图1为本公开所涉及的一种运营管理系统的结构框图。如图1所示，运营管理系统的核心为运营数据监管系统，监管平可用于监管不同企业的底层平台的动态运营数据；其中，每个企业可以具有1个或多个不同的底层平台。

图2A和图2B分别为本公开实施例提供的两种运营数据监控方法的流程图。如图2A所示，该运营数据监控方法应用于运营数据监管系统，该运营数据监管方法包括：

步骤S1、获取目标底层平台上报的目标动态运营信息。

其中，目标动态运营信息包括：目标动态运营数据、目标底层平台所属企业的目标企业ID、目标底层平台的目标平台ID和目标动态运营数据所对应的目标唯一交互ID。

在本公开实施例中，不同企业的企业ID不同，属于同一企业的不同底层平台的平台ID不同，来自于不同底层平台的不同动态运营信息的唯一交互ID不同；属于不同企业的不同底层平台的平台ID可以相同，也可以不同；来自于不同底层平台的不同动态运营信息的唯一交互ID可以相同，也可以不同。

在一些实施例中，目标唯一交互ID包括：基于时间戳的UUID或根据哈希算法等生成的唯一字符串(也称为随机字符串)。

步骤S2、检测数据库中是否已存储有企业ID为目标企业ID、平台ID为目标平台ID且唯一交互ID为目标唯一交互ID的动态运营信息。

在步骤S2中检测到数据库中已存储有企业ID为目标企业ID、平台ID为目标平台ID且唯一交互ID为目标唯一交互ID的动态运营信息时，则表明目标动态运营数据被重复上报，此时执行步骤S3；在步骤S3中检测到数据库中未存储有企业ID为目标企业ID、平台ID为目标平台ID且唯一交互ID为目标唯一交互ID的动态运营信息时，则表明目标动态运营数据未被数据库存储，此时执行步骤S4。

步骤S3、向目标底层平台反馈用于表征动态运营信息重复上报的第一提示信息。

其中，第一提示信息中包括有目标唯一交互ID。

步骤S4、验证目标动态运营数据的完整性和有效性，并在目标动态运营数据的完整性验证通过以及有效性验证通过时，将目标动态运营信息存储至数据库中。

需要说明的是，在本公开实施例中“完整性”验证用于检测数据是否完整有缺失及符合规范，“有效性”验证用于检测相应数据是否满足对应的有效条件(根据实际需要进行预先设计)。

在本公开实施例中，目标底层平台所上报的目标动态运营信息，可利用该目标动态运营信息内的“目标企业ID”“目标平台ID”“目标唯一交互ID”三者的结合(即，目标企业ID+目标平台ID+目标唯一交互ID)，来标记目标动态运营信息的唯一性。如此设计，可以有效区别数据库内不同的动态运营信息。可以有效避免动态运营信息的重复存储，以及在动态运营信息出现缺失时进行缺失重传。

此外，在确定出底层平台重复上报动态运营信息时，将包括有该重复上报动态运营信息所对应的目标唯一交互ID的第一提示信息反馈至对应的底层平台，可供相应底层平台快速定位被重复上报的动态运营信息。

本公开的技术方案可实现运营数据监管系统对动态运营信息高效、合理的监管，保证运营数据监管系统所存储动态运营信息的完整性、有效性和去重性。

参见图2B所示，在一些实施例中，在步骤S1和步骤S2之间，还包括：步骤S1aa。

步骤S1aa、初步判断所述目标动态运营信息的数据结构以及预设关键字段是否存在异常。

若判断出所述目标动态运营信息的数据结构和预设关键字段中至少之一存在异常时，则向所述目标底层平台反馈表征动态运营信息存在数据异常的提示信息；

若判断出所述目标动态运营信息的数据结构和预设关键字段中均正常时，则执行步骤S2。

图3为本公开实施例中步骤S4的一种可选实现方法的流程图。如图3所示，步骤S4包括：

步骤S401、将目标动态运营信息保存至消息系统，并向目标底层平台发送用于表征目标动态运营信息已被成功接收的第二提示信息，第二提示信息中包括有目标唯一交互ID。

步骤S402、响应于消息系统内位于目标动态运营信息之前的信息完成相应处理，从消息系统内获取目标动态运营信息。

在实际应用中，对数据的精处理(例如完整性验证、有效性验证)时间和对数据存储的时间相对较长，若运营数据监管系统直接采用交替进行数据存储和数据处理的过程，则在出现大量动态运营信息上报时，容易导致系统压力过大甚至出现动态运营信息的丢失。

为改善该技术问题，在本公开实施例中，运营数据监管系统先将动态运营信息存储至消息系统(如kafka)，然后再依次对消息系统内的动态运营信息进行处理，可以有效提高系统的数据处理能力，消息系统的存在可以有效保证运营数据监管系统的高并发、高性能、高可用。

步骤S403、验证目标动态运营数据的完整性和有效性。

在一些实施例中，步骤S403包括：

步骤S4031、验证目标动态运营数据的完整性。

在目标动态运营数据的完整性验证失败时，执行步骤S4032；在目标动态运营数据的完整性验证通过时，执行步骤S4033。

步骤S4032、向目标底层平台发送用于表征目标动态运营数据的完整性验证失败的第三提示信息。

其中，第三提示信息包括有目标唯一交互ID。

步骤S4033、验证目标动态运营数据的有效性。

在目标动态运营数据的有效性验证失败时，执行步骤S4034；在目标动态运营数据的有效性验证通过时，执行步骤S404；

步骤S4034、向目标底层平台发送用于表征目标动态运营数据的有效性验证失败的第四提示信息，第四提示信息包括有目标唯一交互ID。

步骤S404、将目标动态运营信息存储至数据库中。

步骤S405、向目标底层平台反馈目标动态运营信息已完成存储的提示信息。

图4A和图4B为本公开实施例提供的另两种运营数据监控方法的流程图。如图4A和图4B所示，图4A和图4B所示技术方案不但包括前面实施例中的步骤S1～步骤S4，且在步骤S1与步骤S2之间还包括步骤S1a和步骤S1b，在步骤S4之后还包括步骤S5。

步骤S1a、获取缓存中所记录的目标底层平台上一次上报的动态运营信息所对应唯一交互ID。

步骤S1b、判断目标唯一交互ID与目标底层平台上一次上报的动态运营信息所对应唯一交互ID是否一致。

其中，若步骤S1b判断出目标唯一交互ID与目标底层平台上一次上报的动态运营信息所对应唯一交互ID一致，则执行步骤S3；若步骤S1b判断出目标唯一交互ID与目标底层平台上一次上报的动态运营信息所对应唯一交互ID不一致，则执行步骤S1c，并在步骤S1c结束后执行执行步骤S2。

步骤S1c、将缓存中所记录的所述目标底层平台上一次上报的动态运营信息更新为所述目标唯一交互ID。

在本公开实施例中，考虑到动态运营信息的重复上报一般是连续发生的，因此通过将目标底层平台最新已上报并完成存储的动态运营信息所对应唯一交互ID进行缓存，并在目标底层平台发送目标动态运营信息时，将目标动态运营信息内的目标唯一交互ID与缓存中所记录的同一目标底层平台上一次上报的动态运营信息所对应唯一交互ID进行比对，可以排除绝大部分的重复。而对于因其他原因产生的重复，可通过步骤S2中基于数据库的查重进行处理。如此设计，可以有效提升去重效率。

图5为本公开实施例提供的又一种运营数据监控方法的流程图。如图5所示，在一些实施例中，在步骤S1之前还包括：

步骤S01、获取目标企业账户的平台添加请求。

在一些实施例中，平台添加请求中包括待添加的目标底层平台的平台ID。

步骤S02、对平台添加请求的有效性进行审核。

作为一个示例，平台添加请求中包括有目标企业的企业ID以及待添加的目标底层平台的平台ID。首先，可以检测平台添加请求中所包括的企业ID是否为已注册企业的企业ID，若平台添加请求中所包括的企业ID不为已注册企业的企业ID，则平台添加请求的有效性审核失败；若平台添加请求中所包括的企业ID为已注册企业的企业ID，则进一步验证检测平台添加请求中待添加的目标底层平台的平台ID是符合对应目标企业预先设计的命名规则，若平台添加请求中待添加的目标底层平台的平台ID符合对应目标企业预先设计的命名规则，则平台添加请求的有效性审核通过；若平台添加请求中待添加的目标底层平台的平台ID不符合对应目标企业预先设计的命名规则，则平台添加请求的有效性审核失败。

当然，本公开中还可以采用其他方式来平台添加请求的有效性进行审核。例如，可以基于预先设定的有效性审核规则来审核平台添加请求的有效性，或者是由人工来进行审核；本公开对此不作限定。

在平台添加请求的有效性审核失败后，目标企业账户反馈添加请求失败的提示信息；在平台添加请求的有效性审核通过后，执行步骤S03。

步骤S03、在联调环境下与目标底层平台进行联调测试。

运营数据监控与目标底层平台的联调测试，主要是测试运营数据监控与目标底层平台之间的各接口交互是否正常。其中，若存在接口交互异常，则联调测试失败，向目标底层平台反馈联调测试失败的提示信息(可以提示哪些接口存在交互异常)；若所有接口交互均正常，则联调测试通过，此后执行步骤S04。

步骤S04、与目标底层平台进行生产环境对接。

在一些实施例中，平台添加请求中还包括有目标底层平台的目标静态资产信息；在步骤S03中确定出联调测试通过之后且在执行步骤S04之前还包括：

步骤S03a、在联调环境下审核目标静态资产信息的真实性。

其中，可基于预先配置的真实性验证规则来审核目标静态资产信息的真实性；或者，由人工来确认目标静态资产信息的真实性。本公开对此不作限制。

若目标静态资产信息的真实性审核失败，则向目标底层平台反馈真实性审核失败的提示信息；若目标静态资产信息的真实性审核成功，则执行步骤S03b。

步骤S03b、将目标静态资产信息进行录入存储，以同步到生产环境。

在一些实施例中，步骤S03b与步骤S04可以同步进行。

在一些实施例中，在步骤S02中平台添加请求的有效性审核通过之后，且在执行步骤S03之前，还包括：

步骤S02a、生成与目标底层平台相对应的两套数据通信密钥，并将两套数据通信密钥中的一套数据通信密钥内的第一加密密钥以及另一套数据通信密钥内的第二解密密钥发送给目标底层平台。

其中，两套数据通信密钥中的一套数据通信密钥包括第一加密密钥和第一解密密钥，另一套数据通信密钥包括第二加密密钥和第二解密密钥；第一加密密钥和第二解密密钥存储在目标底层平台，第一解密密钥和第二加密密钥存储在运营数据监管系统。

目标底层平台根据第一加密密钥对发送至运营数据监管系统的数据进行加密，运营数据监管系统根据第一解密密钥对目标底层平台所发送的加密数据进行解密；运营数据监管系统根据第二加密密钥对发送至目标底层平台的数据进行加密，目标底层平台根据第二解密密钥对运营数据监管系统所发送的加密数据进行解密。

在一些实施例中，运营数据监管方法还包括：

步骤S6、每隔预设周期向目标底层平台发送静态资产更新指令。

步骤S7、接收目标底层平台所反馈的更新后的目标静态资产信息。

步骤S8、在联调环境下审核更新后的目标静态资产信息的真实性。

步骤S9、在更新后的目标静态资产信息的真实性审核通过后，根据更新后的目标静态资产信息对已录入存储的目标底层平台的目标静态资产信息进行更新，以同步到生产环境。

例如，将部分下线的目标静态资产信息进行报废标识，将部分变更的目标静态资产信息进行更新操作(含更新状态标识)，将部分新增的目标静态资产信息进行存储操作。

在一些实施例中，监管系统向目标底层平台提供可供目标底层平台查询某个目标唯一交互ID所对应的目标动态运营数据是否存在的服务接口，以及可供目标底层平台反馈某个目标唯一交互ID所对应的目标动态运营信息需删除重传的服务接口。

目标底层平台可通过相应服务接口查询运营数据监管系统的数据库内是否存在某个目标唯一交互ID所对应的目标动态运营信息是否存在，若存在，则运营数据监管系统向目标底层平台反馈相应目标唯一交互ID所对应的目标动态运营信息已存在的提示信息，若不存在，则运营数据监管系统向目标底层平台反馈相应目标唯一交互ID所对应的目标动态运营信息不存在以及询问目标底层平台是否需上报的提示信息。

目标底层平台可通过相应服务接口向运营数据监管系统发送删除某个目标唯一交互ID所对应的目标动态运营信息的请求，待运营数据监管系统完成相应删除操作后，向目标底层平台反馈目标唯一交互ID所对应的目标动态运营信息已删除的提示信息。

基于同一发明构思，本公开实施例还提供了一种运营数据监管系统。图1为本公开所涉及的一种运营管理系统的结构框图。图2为本公开实施例提供的一种运营数据监控方法的流程图。图3为本公开实施例中步骤S4的一种可选实现方法的流程图。图4为本公开实施例提供的另一种运营数据监控方法的流程图。图5为本公开实施例提供的又一种运营数据监控方法的流程图。图6为本公开实施例提供的一种运营数据监管系统的结构框图。如图6所示，该运营数据监管系统可用于实现前面实施例提供的运营数据监管方法，该运营数据监管系统包括：

动态信息获取模块，配置为获取目标底层平台上报的目标动态运营信息，目标动态运营信息包括：目标动态运营数据、目标底层平台所属企业的目标企业ID、目标底层平台的目标平台ID和目标动态运营数据所对应的目标唯一交互ID。

动态信息检测模块，配置为检测数据库中是否已存储有企业ID为目标企业ID、平台ID为目标平台ID且唯一交互ID为目标唯一交互ID的动态运营信息。

第一提示模块，配置为在检测到数据库中已存储有企业ID为目标企业ID、平台ID为目标平台ID且唯一交互ID为目标唯一交互ID的动态运营信息时，则向目标底层平台反馈用于表征动态运营信息重复上报的第一提示信息，第一提示信息中包括有目标唯一交互ID。

验证及存储模块，配置为在检测到数据库中未存储有企业ID为目标企业ID、平台ID为目标平台ID且唯一交互ID为目标唯一交互ID的动态运营信息时，则验证目标动态运营数据的完整性和有效性，并在目标动态运营数据的完整性验证通过以及有效性验证通过时，将目标动态运营信息存储至数据库中。

对于各种模块的具体描述，可参见前面实施例中的内容，此处不在赘述。

在本公开实施例中，运营数据监管系统可由多台服务器基于负载均衡原理来实现，可以保证服务的高并发和高可用能力。

运营数据监管系统与底层平台之间的数据总体流向过程如下：1)底层平台获取运营数据监管系统token令牌；2)底层平台数据加密上报至运营数据监管系统；3)运营数据监管系统对动态运营信息进行初步处理数据(解密、粗过滤等，发现异常会反馈并终止；4)运营数据监管系统将动态运营信息保存到消息系统(如kafka等)，并给底层平台返回接收成功；5)运营数据监管系统消费数据(精处理，例如完整性、有效性验证)并存储到数据库；6)运营数据监管系统反馈数据最终处理结果给底层平台，运营数据监管系统还会统计底层平台各接口数据上报情况及数据有效性情况。

运营数据监管系统的数据库设计如下：

运营数据监管系统所监管底层平台的平台信息：由两张表维护，一张企业基本信息(包括企业ID等信息)，一张的底层平台交互信息(底层平台的平台ID、所属企业的企业ID、服务地址、加密解密密钥等)，两张表由企业ID关联起来。

静态资产信息：视资产的层级关系由多张关联表组成，每张表需要有企业ID、资产ID(及上级资产id)、资产名称、地址(及经纬度)、资产类型、建成投运时间、创建时间(即接入时间)、更新时间、资产状态(建设中、使用中、故障、已报废等)等。

动态运营信息：重要字段包括企业ID、资产ID、唯一交互ID、创建时间及业务数据等。动态运营信息的量比较大，采用时间维度(便于统计)的分库分表设计。另外，为了减轻数据压力和及时了解运营情况，每日每周每月会有一定形式的数据合并、清理及统计等定时任务。

运营数据监管系统信息：一张表，字段包括运营数据监管系统的系统ID、联调服务地址、生产服务地址等。

运营数据监管系统中还存在日志服务，用于对于各底层平台之间的数据交互(原始参数、加密参数、返回原始结果、解密结果等)、数据库操作语句等内容进行记录。

底层平台接入运营数据监管系统的接入流程如下：

联调环境联调：企业在运营数据监管系统注册唯一账号(得到企业ID)，运营数据监管系统审核企业基本信息，通过后底层平台按运营数据监管系统接入规范开发接口服务；企业在联调管理界面添加底层平台的联调和生产信息(主要包括底层平台的ID信息和服务地址信息)，运营数据监管系统审核通过后自动生成和分配给底层平台和运营数据监管系统互通的两套一定复杂度的数据通信秘钥。底层平台发起联调，双方在运营数据监管系统联调环境测试所有接口交互是否正常，审核静态资产的真实性，保证静态资产的真实性正确性、保证所有接口数据的正常交互；该联调环境还可再现及排查问题等。

生产环境接入：联调通过后，切换到生产环境对接。根据统计底层平台各接口数据上报情况及数据有效性情况，对接入符合性作反馈，底层平台存在上报异常的限期整改，完全符合后将接入状态置为完成，以此保证企业经营数据正确完整及时同步到运营数据监管系统。

监管网站展示：方便监管部门查看、掌握运营情况。底层平台完成接入后，企业可查看自身上报数据的情况，其他信息如公告等的展示。

静态资产维护流程：新增和修改先在联调环境完成核实，后同步到生产环境。上次和本次查询静态资产，出现上次有多的部分时要沟通核实来进行资产状态变更。

本公开的技术方案具有如下优势：

底层平台上报的每条动态运营信息均用企业ID、平台ID以及一个唯一交互ID来标记数据的唯一性，动态运营信息存储到数据库时会保存这组唯一键，从而一个专门的查询接口以此保证数据接收的完整性、有效性。

运营数据监管系统将接收到的动态运营信息保存到消息系统，数据处理程序从消息系统消费数据，处理并存储到数据库。消息系统的存在进一步保证了服务的高并发、高性能、高可用。

企业在运营数据监管系统注册唯一账号，当增加上报底层平台时，只需添加一条底层平台信息即可，避免了传统设计考虑不全面，一个底层平台要一个账号，一个运营主体注册多个ID的不利情况。

基于同一发明构思，本公开实施例还提供了一种电子设备。图7为本公开实施例的一种电子设备的结构示意图。如图7所示，本公开实施例提供一种电子设备包括：一个或多个处理器101、存储器102、一个或多个I/O接口103。存储器102上存储有一个或多个程序，当该一个或多个程序被该一个或多个处理器执行，使得该一个或多个处理器实现如上述实施例中任一的运营数据监管方法；一个或多个I/O接口103连接在处理器与存储器之间，配置为实现处理器与存储器的信息交互。

其中，处理器101为具有数据处理能力的器件，包括但不限于中央处理器(CPU)等；存储器102为具有数据存储能力的器件，包括但不限于随机存取存储器(RAM，更具体如SDRAM、DDR等)、只读存储器(ROM)、带电可擦可编程只读存储器(EEPROM)、闪存(FLASH)；I/O接口(读写接口)103连接在处理器101与存储器102间，能实现处理器101与存储器102的信息交互，包括但不限于数据总线(Bus)等。

在一些实施例中，处理器101、存储器102和I/O接口103通过总线104相互连接，进而与计算设备的其它组件连接。

在一些实施例中，该一个或多个处理器101包括现场可编程门阵列。

根据本公开的实施例，还提供一种计算机可读介质。该计算机可读介质上存储有计算机程序，其中，该程序被处理器执行时实现如上述实施例中任一运营数据监管方法中的步骤。

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

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

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

描述于本公开实施例中所涉及到的电路或子电路可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的电路或子电路也可以设置在处理器中，例如，可以描述为：一种处理器，包括：接收电路和处理电路，该处理模块包括写入子电路和读取子电路。其中，这些电路或子电路的名称在某种情况下并不构成对该电路或子电路本身的限定，例如，接收电路还可以被描述为“接收视频信号”。

可以理解的是，以上实施方式仅仅是为了说明本公开的原理而采用的示例性实施方式，然而本公开并不局限于此。对于本领域内的普通技术人员而言，在不脱离本公开的精神和实质的情况下，可以做出各种变型和改进，这些变型和改进也视为本公开的保护范围。