本申请涉及通信技术领域，尤其涉及一种海量数据的处理方法和装置。
背景技术：
随着互联网技术的快速发展，越来越多的业务可以通过网络实现。当大量业务集中爆发时，比如：“双十一”、“双十二”等，服务提供商的部署的各种设备就会面临巨大的处理压力，如何应对这种瞬时或短期内数据量的暴涨已成为亟待解决的问题。
技术实现要素：
有鉴于此，本申请提供一种海量数据的处理方法和装置。
具体地，本申请是通过如下技术方案实现的：
一种海量数据的处理方法，所述方法包括：
当数据的流入速度大于数据的处理速度时，确定超出所述处理速度的待处理数据的优先级；
将所述待处理数据的关键数据保存至与所述优先级对应的泄洪文件中，所述关键数据包括对所述待处理数据进行处理所需要的数据；
当触发恢复操作时，从恢复操作指定的优先级对应的泄洪文件中获取保存的关键数据；
对所述关键数据进行处理，以实现对对应待处理数据的处理。
一种海量数据的处理装置，所述装置包括：
确定单元，当数据的流入速度大于数据的处理速度时，确定超出所述处理速度的待处理数据的优先级；
保存单元，将所述待处理数据的关键数据保存至与所述优先级对应的泄洪文件中，所述关键数据包括对所述待处理数据进行处理所需要的数据；
获取单元，当触发恢复操作时，从恢复操作指定的优先级对应的泄洪文件中获取保存的关键数据；
处理单元，对所述关键数据进行处理，以实现对对应待处理数据的处理。
由以上描述可以看出，本申请设备可以在数据量暴涨时，可将设备无法及时处理的待处理数据的关键数据保存到与其优先级对应的泄洪文件中，以缓解设备的处理压力，避免设备崩溃。当数据量正常时，可以有选择性的触发面向不同优先级泄洪文件的恢复操作，最终确保数据的一致性，且成本低廉。
附图说明
图1是本申请一示例性实施例示出的一种海量数据的处理方法的流程示意图。
图2是本申请一示例性实施例示出的一种用于海量数据处理的系统架构图。
图3是本申请一示例性实施例示出的一种用于海量数据的处理装置的一结构示意图。
图4是本申请一示例性实施例示出的一种海量数据的处理装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
相关技术中，当数据量暴涨时，为避免系统阻塞或者崩溃，通常采用以下解决方案：
方案一，当数据量暴涨时，设备不再从上游数据源处获取数据，等到设备中待处理的数据处理完毕后，再从上游数据源处获取数据并进行处理。然而，采用这样的处理方案，设备会基于接收顺序对待处理的数据进行处理，这就会导致后续重要的数据迟迟得不到处理，并且设备有崩溃的风险。
方案二，当数据量暴涨时，将单位时间内入队列中无法处理的后接收到的数据丢弃，从而确保设备满负荷正常运行。在这样的处理方案中，虽然可以确保设备稳定运行，但丢弃的数据无法找回，无法确保数据的一致性。
方案三，硬件扩容，从而提升设备的处理性能。然而，扩容成本较大，当出现问题时进行扩容，耗时又较长。
方案四，当数据量暴涨时，设备处于停止运行状态，待高峰期过去后，设备再重启运行并跳过这段时间的数据，由另一个辅助应用来处理停运期间的数据，从而补全。然而，在这样的实现方式中，停运期间的设备完全不可用，这往往是不能接受的。
针对上述问题，本申请提供一种海量数据的处理方案，以解决短期内数据量暴涨所带来的问题。
图1是本申请一示例性实施例示出的一种海量数据的处理方法的流程示意图。
请参考图1，所述海量数据的处理方法可以应用在服务提供商后台部署的各种设备中，比如：计算设备、解析设备等，本申请对此不作特殊限制。所述海量数据的处理方法可以包括以下步骤：
步骤101，当数据的流入速度大于数据的处理速度时，确定超出所述处理速度的待处理数据的优先级。
在一个例子中，所述数据的处理速度可以由管理员预先进行设置，比如：管理员可以根据设备的处理性能设置所述处理速度。举例来说，假设设备出厂时厂商公布的处理性能为10万数据/秒，则管理员可以将所述数据的处理速度设置为8万数据/秒。
在另一个例子中，所述数据的处理速度也可以是设备实际的处理速度，比如：设备可以每秒钟检测一下数据的真实处理速度，然后将该真实处理速度作为下一秒的所述处理速度以进行后续判断。
在本实施例中，可以以秒为单位进行流入速度与处理速度的对比，也可以以其他时长为单位进行对比，本申请对此不作特殊限制。假设，所述数据的处理速度由管理员预设，为8万数据/秒，则设备可以检测数据的流入速度是否大于8万数据/秒，即可以每隔1秒检测这1秒钟内流入的数据是否大于8万，如果大于8万，则可以确定当前数据的流入速度大于数据的处理速度。有假设这1秒内流入的数据为10万，则后流入的2万数据为超出所述处理速度的待处理数据。
在本实施例中，当检测到数据的流入速度大于数据的处理速度时，可以确定超出所述处理速度的待处理数据的优先级。可选的，针对每个超出所述处理速度的待处理数据，可以先识别该待处理数据的业务类型，然后将根据所述业务类型的优先级确定为所述待处理数据的优先级。具体地，各业务类型的优先级可以由管理员预先设置，比如：可以将交易类数据的优先级设置为最高优先级，将监控类数据的优先级设置为最低优先级等。针对每个超出所述处理速度的待处理数据，可以先从所述待处理数据中解析出业务标识以确定其业务类型，然后查询该业务类型的优先级以确定所述待处理数据的优先级。当然，在实际应用中，也可以采用其他方式确定所述待处理数据的优先级，比如：根据所述待处理数据的源ip地址确定其优先级等。
步骤102，将所述待处理数据的关键数据保存至与所述优先级对应的泄洪文件中，所述关键数据包括对所述待处理数据进行处理所需要的数据。
在本实施例中，所述关键数据可以就是所述待处理数据，所述关键数据也可以是对所述待处理数据进行整理之后的数据，所述关键数据中包括对所述待处理数据进行处理所需要的数据即可，本申请对此不作特殊限制。
在本实施例中，所述泄洪文件可以位于在本设备中，所述泄洪文件也可以位于在其他的设备中。所述泄洪文件有多个，分别与不同的优先级对应。举例来说，假设超出处理速度的待处理数据的优先级有三级，分别为优先级1、优先级2以及优先级3，则所述泄洪文件也可以有三个，优先级分别为：优先级1、优先级2以及优先级3。在本步骤中，可以将待处理数据的关键数据保存至其优先级对应的泄洪文件中，比如：将优先级为1的待处理数据的关键数据保存到优先级为1的泄洪文件1中，将优先级为2的待处理数据的关键数据保存到优先级为2的泄洪文件2中，依次类推。
基于前述步骤101和102，设备可以在数据量暴涨时，可将超出设备处理速度的待处理数据的关键数据保存到泄洪文件中，即将设备无法及时处理的待处理数据的关键数据保存到泄洪文件中，以缓解设备的处理压力，避免设备崩溃。
步骤103，当触发恢复操作时，从恢复操作指定的优先级对应的泄洪文件中获取保存的关键数据。
步骤104，对所述关键数据进行处理，以实现对对应待处理数据的处理。
在本实施例中，当设备的数据量恢复正常时，可以触发恢复操作，以对数据量暴涨期间设备无法及时处理的待处理数据进行处理。其中，所述恢复操作可以自动触发，也可以人工触发，所述恢复操作通常会指定泄洪文件的优先级。
在一个例子中，设备可以在数据入队列的饱和度小于预设的阈值时自动触发恢复操作，所述恢复操作指定的泄洪文件的优先级默认为最高优先级。所述阈值可以由管理员进行设置，比如：70％或80％等。举例来说，仍假设泄洪文件可以有三个，分别对应优先级1、优先级2以及优先级3，当数据入队列的饱和度小于70％时，可以触发面向优先级为3的泄洪文件的恢复操作。具体地，设备可以从优先级为3的泄洪文件中获取保存的关键数据，然后对所述关键数据进行处理，以实现对对应待处理数据的处理。当然，当优先级为3的泄洪文件中的关键数据全部被处理完毕后，如果数据入队列的饱和度依然小于70％，可自动触发面向优先级为2的泄洪文件的恢复操作，依次类推。
在另一个例子中，由于在数据量暴涨期间的情况非常复杂，也可以由管理员根据实际情况进行恢复操作的触发。具体地，设备在对待处理数据进行处理的同时还会输出监控日志到日志系统，所述监控日志可以包括：单位时间内写入各优先级泄洪文件中关键数据的数量等信息，日志系统可以基于预设的规则对所述监控日志进行分析，并在分析结果满足预设条件时向管理员告警，以便管理员知晓当前设备的运行状况。其中，所述分析方法和预设条件均可以由管理员预先进行设置，本申请对此不作特殊限制。在接收到告警之后，管理员可以对设备的运行状态进行监控，当数据量恢复正常后，管理员可以根据实际情况触发恢复操作，该恢复操作指定的泄洪文件的优先级由管理员确定，举例来说，管理员可以先触发针对高优先级泄洪文件的恢复操作，而对于低优先级泄洪文件，管理员可以根据需要后续触发恢复操作，也可以不触发恢复操作，灵活度较高。
在本实施例中，当触发恢复操作后，设备还会继续监控数据的流入速度是否大于数据的处理速度，如果数据的流入速度再次大于数据的处理速度，则可以停止恢复操作，并再次执行前述步骤101和102。
由以上描述可以看出，本申请设备可以在数据量暴涨时，可将设备无法及时处理的待处理数据的关键数据保存到与其优先级对应的泄洪文件中，以缓解设备的处理压力，避免设备崩溃。当数据量正常时，可以有选择性的触发面向不同优先级泄洪文件的恢复操作，最终确保数据的一致性，且成本低廉。
图2是本申请一示例性实施例示出的一种用于海量数据处理的系统架构图。
请参考图2，所述消息中间件通常为服务提供商部署的用于数据转发、文件存储、日志存储的服务器或服务器集群，所述实时计算系统为服务提供商部署的对待处理数据进行处理的服务器或者服务器集群，所述监控系统为服务提供商部署的用于对实时计算系统以及其他系统进行监控的服务器或者服务器集群。本申请提供的海量数据的处理方法可以应用在所述实时计算系统中，包括有以下步骤：
步骤201，实时计算系统接收待处理数据。
在本实施例中，所述实时计算系统可以从不同的数据源中接收待处理数据进行处理，比如：可以从antq消息组件、msgbroker消息组件等数据源中接收待处理数据。这部分的处理与实现可以参照相关技术，本申请在此不再一一赘述。
步骤202，实时计算系统判定数据的流入速度是否大于数据的处理速度。
基于前述步骤201，实时计算系统在接收到待处理数据后通常会将待处理数据存储到数据入队列中，并判断数据的流入速度是否大于数据的处理速度，具体判断方式可以参照图1所示实施例中的步骤101。当数据的流入速度大于处理速度时，可以确定超出处理速度的待处理数据的优先级，并继续执行步骤203。当数据的流入速度小于等于所述处理速度时，可以正常进行处理。
步骤203，将超出处理速度的待处理数据的关键数据保存至与其优先级对应的泄洪文件中。
在本实施例中，在超出处理速度的待处理数据中，当某待处理数据的优先级为1时，可以将其关键数据存储到消息中间件中优先级为1的泄洪文件中，当某待处理数据的优先级为2时，可以将其关键数据存储到消息中间件中优先级为2的泄洪文件中，依次类推。
在本实施例中，所述待处理数据包括：业务数据和数据来源。其中，所述数据来源可以包括该数据的原系统信息、以及原系统中的原文件信息等，所述数据来源可以用来确定对所述业务数据进行处理的处理规则。在本步骤中，实时计算系统可以根据所述数据来源确定所述待处理数据的处理规则，然后将所述待处理数据中的业务数据和所述处理规则标识作为所述关键数据保存至与所述优先级对应的泄洪文件中。当然，在另一个例子中，还可以在所述关键数据中添加保存至泄洪文件的时间，以便后续基于保存时间的先后顺序依次进行恢复操作。当然，在其他例子中，还可以直接将所述待处理数据作为关键数据保存至其优先级对应的泄洪文件中，本申请对此不作特殊限制。
步骤204，实时计算系统生成监控日志存储到消息中间件中。
在本步骤中，所述监控日志的格式以及其携带的信息都可以有管理员进行设置，比如：实时计算系统可以将每分钟写入各优先级泄洪文件中的关键数据的数据量作为监控日志存储到消息中间件中。
在本实施例中，消息中间件可以将所述监控日志发送给监控系统，以供监控系统进行监控。监控系统也可以定期从消息中间件中获取所述监控日志进行监控，本申请对此不作特殊限制。
步骤205，监控系统根据管理员配置的告警规则进行告警。
在本实施例中，管理员可以在监控系统中配置告警规则，监控系统在接收到消息中间件发送的监控日志后，可以解析监控日志并判断是否满足所述告警规则，并在满足所述告警规则时向管理员进行告警。
步骤206，管理员通过监控数据大盘进行决策，可以在不同的时机触发面向不同优先级泄洪文件的恢复操作。
步骤207，实时计算系统在接收到管理员触发的恢复操作时，从恢复操作指定的优先级对应的泄洪文件中获取保存的关键数据，并对所述关键数据进行处理，以实现对对应待处理数据的处理。
在本步骤中，假设管理员触发面向优先级为3的泄洪文件的恢复操作，实时计算系统可以从消息中间件中优先级为3的泄洪文件中获取关键数据，在获取到所述关键数据后，可以根据所述关键数据中的处理规则标识确定所述关键数据中业务数据的处理规则，然后根据确定的处理规则对所述业务数据进行处理，以实现对对应待处理数据的处理，从而确保数据的一致性。
与前述海量数据的处理方法的实施例相对应，本申请还提供了海量数据的处理装置的实施例。
本申请海量数据的处理装置的实施例可以应用在服务提供商后台部署的设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图3所示，为本申请海量数据的处理装置所在设备的一种硬件结构图，除了图3所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的设备通常根据该设备的实际功能，还可以包括其他硬件，对此不再赘述。
图4是本申请一示例性实施例示出的一种海量数据的处理装置的框图。
请参考图4，所述海量数据的处理装置300可以包括：确定单元301、保存单元302、获取单元303、处理单元304、生成单元305以及停止单元306。
其中，确定单元301，当数据的流入速度大于数据的处理速度时，确定超出所述处理速度的待处理数据的优先级；
保存单元302，将所述待处理数据的关键数据保存至与所述优先级对应的泄洪文件中，所述关键数据包括对所述待处理数据进行处理所需要的数据；
获取单元303，当触发恢复操作时，从恢复操作指定的优先级对应的泄洪文件中获取保存的关键数据；
处理单元304，对所述关键数据进行处理，以实现对对应待处理数据的处理。
可选的，所述确定单元301，具体识别所述待处理数据的业务类型，并将所述业务类型的优先级确定为所述待处理数据的优先级。
可选的，所述获取单元303，在数据入队列的饱和度小于预设的阈值时，确定触发面向优先级最高的泄洪文件的恢复操作。
生成单元305，根据预设的规则生成监控日志，所述监控日志用于向管理员告警数据的流入速度大于数据的处理速度；
所述确定单元301，在接收到管理员发送的恢复指令时，确定触发恢复操作，所述恢复指令中携带有指定的优先级。
可选的，所述待处理数据包括：业务数据和数据来源；
所述保存单元302，具体根据所述数据来源确定所述待处理数据的处理规则标识，将所述待处理数据的业务数据和所述处理规则标识作为所述关键数据保存至与所述优先级对应的泄洪文件中。
停止单元306，当触发恢复操作后，如果再次确认数据的流入速度大于数据的处理速度，则停止恢复操作。
上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。
对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。