CN110232000B - 数据存储管理方法及装置 - Google Patents

Abstract

本发明的实施例提供了一种数据存储管理方法及装置。所述数据存储管理方法应用于数据生产系统，所述数据生产系统用于实时产生海量的更新的数据，该数据存储管理方法包括：针对所述更新的数据进行本地存储，生成第一类型文件；当所述第一类型文件中存储的数据数量达到阈值时，将所述第一类型文件存储为第二类型文件；对所述第二类型文件进行合并处理，存储至第三类型文件；删除已进行合并处理的所述第二类型文件。本发明实施例的技术方案通过本地存储的方式能够实现数据实时备份，同时降低IO及网络消耗；并通过数据合并处理的方式降低了本地存储的数据量。

Description

数据存储管理方法及装置

技术领域

本申请涉及计算机技术领域，具体而言，涉及一种数据存储管理方法、装置、计算机可读介质及电子设备。

背景技术

在系统执行过程中，由于各种原因，比如内存使用、硬件问题、程序缺陷(bug)和数据问题等，会导致系统异常退出，如果不加容错处理，系统就需要从头重新开始，这会耗费大量的时间资源和硬件资源。

因此，需要一种新的数据存储管理方法、装置、计算机可读介质及电子设备。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本发明的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本发明实施例的目的在于提供一种数据存储管理方法、装置、计算机可读介质及电子设备，进而至少在一定程度上克服相关技术中存在的系统异常退出导致的数据资源丢失的问题。

本发明的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本发明的实践而习得。

根据本发明实施例的一方面，提供了一种数据存储管理方法，所述数据存储管理方法应用于数据生产系统，所述数据生产系统用于实时产生海量的更新的数据，所述数据存储管理方法包括：针对所述更新的数据进行本地存储，生成第一类型文件；当所述第一类型文件中存储的数据数量达到阈值时，将所述第一类型文件存储为第二类型文件；对所述第二类型文件进行合并处理，存储至第三类型文件；删除已进行合并处理的所述第二类型文件。

根据本发明实施例的一方面，提供了一种数据存储管理装置，所述数据存储管理方法应用于数据生产系统，所述数据生产系统用于实时产生海量的更新的数据，所述数据存储管理装置包括：第一存储模块，配置为针对所述更新的数据进行本地存储，生成第一类型文件；第二存储模块，配置为当所述第一类型文件中存储的数据数量达到阈值时，将所述第一类型文件存储为第二类型文件；第三存储模块，配置为对所述第二类型文件进行合并处理，存储至第三类型文件；文件删除模块，配置为删除已进行合并处理的所述第二类型文件。

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

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

在本发明的一些实施例所提供的技术方案中，通过本地存储的方式能够实现数据实时备份，一方面，由于数据备份存储于本地，从而可以减少IO和网络资源的消耗；另一方面，由于存储的是更新的增量数据而非全量数据，可以减少存储空间。再一方面，本方案还通过将存储有增量数据的第二类型文件进行合并处理，可以进一步降低存储空间。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示出了可以应用本发明实施例的数据存储管理方法或数据存储管理装置的示例性系统架构的示意图；

图2示出了适于用来实现本发明实施例的电子设备的计算机系统的结构示意图；

图3示意性示出了根据本发明的一实施例的数据存储管理方法的流程图；

图4示出了图3中所示的步骤S330在一实施例中的处理过程示意图；

图5示意性示出了根据本发明的另一实施例的数据存储管理方法的流程图；

图6示出了图5中所示的步骤S550在一实施例中的处理过程示意图；

图7示出了图6中所示的步骤S556在一实施例中的处理过程示意图；

图8示意性示出了根据本发明的一实施例的模型训练过程的示意图；

图9示意性示出了根据本发明的一实施例的模型存储的示意图；

图10示意性示出了根据本发明的一实施例的实时增量模型文件结构的示意图；

图11示意性示出了根据本发明的一实施例的参数合并的示意图；

图12示意性示出了根据本发明的一实施例的训练数据的数据格式的示意图；

图13示出了图12中所示的模型参数样例的示意图；

图14示出了图13中所示的参数合并样例的示意图；

图15示出了图14中所示的参数合并过程的示意图；

图16示意性示出了将本发明实施例所述方法应用于视频推荐的界面示意图；

图17示意性示出了根据本发明的一实施例的模型恢复的示意图；

图18示意性示出了根据本发明的一实施例的数据存储管理装置的框图；

图19示意性示出了根据本发明的另一实施例的数据存储管理装置的框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本发明将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本发明的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本发明的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本发明的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

图1示出了可以应用本发明实施例的数据存储管理方法或数据存储管理装置的示例性系统架构的示意图。

如图1所示，该系统架构可以包括：服务器110以及可实现服务器110中访问的用户终端130。

应该理解，图1中的用户终端和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的用户终端和服务器。比如服务器110可以是多个服务器组成的服务器集群等。

用户可以使用用户终端130通过网络与服务器110交互，以接收或发送消息等。用户终端130可以是具有显示屏的各种电子设备，包括但不限于智能手机、平板电脑、便携式计算机和台式计算机等等。

服务器110可以是提供各种服务的服务器。例如用户通过用户终端130安装视频播放平台，利用用户终端130向服务器110上传了用户名和密码，登录该视频播放平台，服务器110可以根据获取的用户名和密码进行登录验证，当验证通过后，用户登录用户终端130的视频播放平台，用户通过用户终端130向服务器110发送视频播放请求，服务器110根据该视频播放请求返回相应的搜索结果，用户在该搜索结果中点击相应的视频节目，服务器110可以记录什么用户在什么时间、什么地点、什么环境点击了什么视频节目，还可以记录用户的观看时长等信息。服务器110可以基于获取的历史数据(用户信息例如性别、年龄、爱好等，视频中的描述内容等，用户地理位置信息和观看时间信息等)训练模型，服务器110可以采用训练好的模型预测当前用户可能感兴趣的视频内容，向当前用户推荐相关视频内容，服务器110将推荐结果反馈给用户终端130，进而用户可以基于用户终端130上显示的推荐结果，选择自己喜欢的视频节目点击观看。

又如用户利用用户终端130向服务器110上传了多个数据统计请求，服务器110根据接收到的多个数据统计请求进行数据统计计算，当统计计算完成后，服务器110可以将统计结果反馈至用户终端130，从而用户可以基于用户终端130显示的内容获知当前的数据统计结果。

图2示出了适于用来实现本发明实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图2示出的电子设备的计算机系统200仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

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

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

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

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

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

描述于本发明实施例中所涉及到的模块和/或单元和/或子单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的模块和/或单元和/或子单元也可以设置在处理器中。其中，这些模块和/或单元和/或子单元的名称在某种情况下并不构成对该模块和/或单元和/或子单元本身的限定。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现如下述实施例中所述的数据存储管理方法。例如，所述的电子设备可以实现如图3或图4或图5或图6所示的各个步骤。

图3示意性示出了根据本发明的一实施例的数据存储管理方法的流程图。所述数据存储管理方法可以应用于数据生产系统，所述数据生产系统能够用于实时产生海量的更新的数据。

本公开实施例中，“海量(Big)”泛指所述数据生产系统在正常运行时，会实时的不断产生大量的数据，例如，数百个TB(Terabyte，太字节，或百万兆字节＝1024GB)的数据。但这里的海量数据并非总是说有数百个TB才算得上，根据实际使用情况，有时候数百个GB的数据也可称为海量数据，这主要要看它的处理速度。

需要说明的是，本公开实施例中的所述数据生产系统可以根据具体的应用场景，解释成任意的能够产生更新的数据的程序、进程或者线程等中的任意一种或者多种的组合。

如图3所示，本实施例提供的数据存储管理方法可以包括以下步骤。

在步骤S310中，针对所述更新的数据进行本地存储，生成第一类型文件。

本公开实施例中，所述第一类型文件是用于实时写入所述更新的数据的文件。

在示例性实施例中，所述更新的数据可以包括模型训练过程中更新的模型参数。

本公开实施例中，所述方法还可以包括：读取训练数据子集获取当前梯度；根据历史梯度、历史模型参数和所述当前梯度获取所述更新的模型参数。

其中，模型训练过程中，可以将训练数据分成多个批次即各个训练数据子集来处理，前一批次的训练数据子集处理获得的梯度和模型参数分别称之为历史梯度和历史模型参数，当前批次的训练数据子集处理获得的梯度和模型参数分别称之为当前梯度和所述更新的模型参数。

在示例性实施例中，所述更新的模型参数可以包括新增的模型参数和/或模型参数的新参数值，还可以包括根据所述训练数据子集训练后确定的那部分模型参数的旧参数值。

当本公开实施例的用于数据生产系统的存储管理方法应用于模型训练过程时的具体内容可以参照下图8-17的内容。

在步骤S320中，当所述第一类型文件中存储的数据数量达到阈值时，将所述第一类型文件存储为第二类型文件。

本公开实施例中，由于文件的存储容量是有上限的，即不能无限制的一直写入，当写入所述第一类型文件中的所述更新的数据达到所述阈值(可以根据具体应用场景自主设置)时，将当前第一类型文件存储为所述第二类型文件，例如可以根据预先设置的命名规则将当前第一类型文件的文件名更改为第二类型文件的文件名，同时，创建新的第一类型文件继续用于后续更新的数据的实时写入。在系统没有发生异常退出时，这个过程在循环持续进行，可以生成一个或者多个第二类型文件。

在步骤S330中，对所述第二类型文件进行合并处理，存储至第三类型文件。

本公开实施例中，由于用于存储所述更新的数据的所述第一类型文件和所述第二类型文件均是本地存储，为了减少本地存储的存储空间，可以对第二类型文件中存储的数据进行合并处理，将多个第二类型文件中存储的数据合并存储于所述第三类型文件。类似的，也可以通过所述命名规则来命名所述第三类型文件的文件名，以将所述第二类型文件和所述第三类型文件区别开来。具体的合并处理过程可以参照下图4的内容。

在步骤S340中，删除已进行合并处理的所述第二类型文件。

本公开实施例中，已写入所述第三类型文件的第二类型文件可以从本地存储中删除，从而可以进一步降低占据的本地存储空间。

本公开实施方式提供的用于数据生产系统的存储管理方法，通过本地存储的方式能够实现数据实时备份，一方面，由于数据备份存储于本地，从而可以减少IO和网络资源的消耗；另一方面，由于存储的是更新的增量数据而非全量数据，可以减少存储空间。再一方面，本方法还通过将存储有增量数据的第二类型文件进行合并处理，可以进一步降低存储空间。

图4示出了图3中所示的步骤S330在一实施例中的处理过程示意图。

如图4所示，上述步骤S330可以进一步包括以下步骤。

在步骤S331中，将所述第二类型文件按照创建时间先后顺序排序。

在示例性实施例中，所述第二类型文件的文件名可以相关于所述第二类型文件的创建时间。

一些实施例中，可以用自然数字的编号指示第二类型文件的创建时间先后顺序，例如，最先创建的第二类型文件的文件名后缀(或者前缀，或者文件名的指定位置，本公开对此不作限定)为0，随后创建的第二类型文件的文件名后缀可以依次为1，2，…直至n(n为大于等于0的整数)。

另一些实施例中，也可以在第二类型文件的文件名中增加创建时间字符串，例如增加以创建时间字符串结尾的文件名。

在示例性实施例中，可以将所述第二类型文件按照创建时间先后顺序进行降序排列。例如，可以按照文件名后缀从0，1，…直至n的顺序将n+1个第二类型文件排序。

当然，在其他实施例中，也可以将所述第二类型文件按照创建时间先后顺序进行升序排列。只要能够保证读入时是按照创建时间先后顺序读入的即可。

在步骤S332中，将所述第三类型文件写入至内存。

本公开实施例中，系统初始化时或者当首次检测到生成有一个或者多个第二类型文件时，可以生成一个空的第三类型文件。

在其他实施例中，系统初始化时，并不存在所述第三类型文件，之后可以在首次检测到第二类型文件时，创建一个第三类型文件，并将该首次检测到的第二类型文件写入至该第三类型文件。或者，也可以直接将该首次检测到的第二类型文件作为第三类型文件，将之后检测到的第二类型文件再依次写入该第三类型文件中。

需要说明的是，在第一次将多个第二类型文件进行合并处理时，如果实现没有创建一个空的第三类型文件，此时，是不存在第三类型文件的，这时，可以没有上述步骤S332，直接执行步骤S333将当前要合并处理的第二类型文件按排列顺序写入内容，之后再将内存中的数据写回至本地磁盘，生成初始的第三类型文件。

在步骤S333中，将所述第二类型文件按照排列顺序依次写入所述内存，用所述更新的数据的新参数值覆盖旧参数值。

例如，可以先读入文件名后缀为0的第二类型文件至内存，再读入文件名后缀为1的第二类型文件至所述内存，…直至读入文件名后缀为n的第二类型文件至所述内存，每次读入新的第二类型文件时，就用所述更新的数据的新参数值覆盖旧参数值，如果是所述更新的数据中新增的数据，则直接写入至所述内存即可。

在步骤S334中，将所述内存中的数据存储至所述第三类型文件。

本公开实施例中，当系统执行过程中，检测到生成有第二类型文件时，不管是一个还是多个，均可以将第二类型文件按照创建时间先后顺序依次写入至内存中，在写入的过程中，不断用新的参数值覆盖旧的参数值，如果更新的数据中有新增的数据，则直接添加至内存中，待本次合并完成后再将内存中的数据存储至磁盘的所述第三类型文件，同样的，本次合并后的新的参数值覆盖前一次合并后的所述第三类型文件中的旧的参数值，更新了所述第三类型文件中存储的数据。

需要说明的是，上述图3实施例中更新的数据实时写入第一类型文件、当第一类型文件存储的数据达到阈值时将所述第一类型文件存储为第二类型文件可以由第一线程执行，本实施例中将第二类型文件中的数据按照创建时间先后顺序依次写入第三类型文件可以由第二线程执行，其中，该第一线程和该第二线程可以是两个异步线程，彼此并发执行，这样，一方面，第二类型文件的数据合并处理并不会影响到更新的数据实时存储，另一方面，可以及时的将第二类型文件的数据进行合并，删除已经合并的第二类型文件，释放本地存储空间。

图5示意性示出了根据本发明的另一实施例的用于数据生产系统的存储管理方法的流程图。

如图5所示，本实施例提供的用于数据生产系统的存储管理方法可以包括以下步骤。

在步骤S510中，针对所述更新的数据进行本地存储，生成第一类型文件。

在步骤S520中，当所述第一类型文件中存储的数据数量达到阈值时，将所述第一类型文件存储为第二类型文件。

在步骤S530中，对所述第二类型文件进行合并处理，存储至第三类型文件。

在步骤S540中，删除已进行合并处理的所述第二类型文件。

本实施例中的上述步骤S510-540可以参照上述图3所示实施例中的步骤S310-340，在此不再详述。

在步骤S550中，当所述数据生产系统异常退出时，根据异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件进行数据恢复。

本公开实施例中，所述数据生产系统发生异常退出，例如程序缺陷导致进程异常退出，或者软件系统发生故障导致系统崩溃，此时，由于上述步骤S510-540在所述数据生产系统正常工作时，一直在循环持续进行，本地存储了数据生产系统发生异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件，可以在当前服务器上或者另一台服务器上开启一新系统，该新系统可以根据数据生产系统异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件对数据进行恢复。具体的数据恢复过程可以参照下图6和7的内容。

图6示出了图5中所示的步骤S550在一实施例中的处理过程示意图。

如图6所示，上述步骤S550可以进一步包括以下步骤。

在步骤S551中，判断数据生产系统是否异常退出；当所述数据生产系统异常退出时，进入步骤S552；反之，回到步骤S551继续判断所述数据生产系统是否异常退出。

在步骤S552中，启动新系统。

在步骤S553中，判断所述数据生产系统和所述新系统是否在同一个节点上；当所述数据生产系统和所述新系统在同一个节点上时，进入步骤S554；当所述数据生产系统和所述新系统不在同一个节点上时，进入步骤S555。

本公开实施例中，所述节点可以是一台服务器。当所述数据生产系统和所述新系统是在同一台服务器上时，则可以认为所述数据生产系统和所述新系统在同一个节点上。当所述数据生产系统和所述新系统分别在两台不同的服务器上时，则可以认为所述数据生产系统和所述新系统不在同一个节点上。具体的，例如可以通过服务器的IP(InternetProtocol，网络之间互连的协议)地址、MAC(Media Access Control或者Medium AccessControl，媒体访问控制)地址等信息来判断所述数据生产系统和所述新系统是否处于同一服务器上。

在步骤S554中，读取本地存储的所述数据生产系统异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件。

本公开实施例中，当所述数据生产系统和所述新系统处于同一节点上时，可以进行数据本地恢复，直接读取本地存储的所述数据生产系统异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件。

在步骤S555中，将所述数据生产系统异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件传输至所述新系统所在的节点。

本公开实施例中，当所述数据生产系统和所述新系统不处于同一节点上时，可以进行数据异地恢复，先将所述数据生产系统异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件传输至所述新系统所在的节点。

在步骤S556中，根据所述数据生产系统异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件进行数据恢复。

具体的数据恢复过程可以参照下图7实施例的内容。

图7示出了图6中所示的步骤S556在一实施例中的处理过程示意图。

如图7所示，上述步骤S556可以进一步包括以下步骤。

在步骤S5561中，读入所述数据生产系统异常退出时的所述第三类型文件至内存。

在步骤S5562中，将所述数据生产系统异常退出时的所述第二类型文件按照创建时间先后顺序依次读入至所述内存。

在步骤S5563中，读入所述数据生产系统异常退出时的所述第一类型文件至所述内存。

本公开实施例中，当所述数据生产系统发生异常退出时，所述第一类型文件中由于存储的是实时写入的更新的数据，因此，所述第一类型文件中存储的是最新的数据；所述第二类型文件中存储的是次新的数据；所述第三类型文件中存储的数据相对所述第一类型文件和所述第二类型文件是最早存储的数据，因此，先读入所述第三类型文件，再读入所述第二类型文件，最后读入所述第一类型文件，可以保证新的数据正确的覆盖旧的数据，新系统中恢复的是最新的数据，可以实现数据的无损恢复。

以下通过图8-17的模型训练过程为例说明上述数据存储管理方法。本实施例中，应用该数据存储管理方法的数据生产系统是指用于进行模型训练的系统。

在模型训练过程中，由于各种原因，比如内存使用、硬件问题、程序bug和数据问题等导致server(服务)进程异常退出，如果不加容错处理，那就需要重新开始训练，耗费大量时间资源和硬件资源。针对这种情况可以在模型训练过程中将模型参数备份存储，如果server出现异常就重新启动server，待server恢复了之前的模型参数，则继续模型训练过程。

现有技术中，由于模型训练过程中会实时的产生海量数据，所以需要采用HDFS(Hadoop Distributed File System，Hadoop分布式文件系统)这种能够存储海量数据的系统进行模型参数备份，而且现有技术中是使用循环的方式全量将模型参数写入HDFS分布式存储系统中。

这种方案的缺点是：一方面，由于模型训练过程中模型参数是实时产生的，即备份时写入HDFS的是流式文件，而HDFS针对流式文件的写入速度较慢，从而导致进行模型训练产生更新的模型参数的数据生产系统需要等待HDFS的模型参数备份写入，会降低数据生产系统的效率；另一方面，由于HDFS的写入速度较慢，会导致模型参数备份不够及时，如果server出错需要进行模型参数恢复，那么可能丢掉几个甚至几十个minibatch的参数，这样即使恢复了模型参数，模型的精度损失也比较大。再一方面，HDFS写文件耗费比较多的IO和网络资源。

图8示意性示出了根据本发明的一实施例的模型训练过程的示意图。

本公开实施例中，参数服务(parameter server)的系统包括：scheduler(计划表)，worker(工作组)和server(服务进程)。

需要说明的是，本公开实施例中所述模型可以包括线性模型和非线性模型。

一些实施例中，所述模型可以为Word2Vec模型，训练数据中可以包括多个语句，worker划分得到的训练数据子集中包括至少一个语句，对至少一个语句进行分词可以得到多个词组，该多个词组可以作为样本，对Word2Vec模型的模型参数进行训练。

另一些实施例中，所述模型可以为神经网络模型，该神经网络模型可以包括输入层、隐层和输出层，其中输出层包括由多个树节点构成的二叉树，那么，该神经网络模型的模型参数中包括二叉树中任意两个树节点之间的路径参数，每次更新时对任意两个树节点之间的路径参数进行更新。

本发明实施例中，所述模型中可以包括多个模型参数，且不同类型的模型中模型参数的类型也不同，本发明实施例中对该模型和该模型中的模型参数均不作限定。

本公开实施例中，可以采用SGD(Stochastic Gradient Descent，随机梯度下降)算法进行训练，得到更新的模型参数，当然也可以采用其他算法进行训练，本发明实施例对此不作限定。例如，还可以采用FTRL(Follow-the-regularized-Leader)，FM(Factorization Machine)等算法训练模型。

需要说明的是，本实施例中的参数服务不是指参数服务器，而是服务中的进程，包括本公开实施例中的server，都是指的server进程，因为每台服务器中都可能既包含server也包含worker。

其中，scheduler负责调度，交付任务给worker；worker负责按照设定的minibatch读取训练数据子集和计算梯度，并提交计算好的梯度给server；server负责根据历史梯度、历史模型参数等信息和新的梯度计算获取更新后的模型参数。

本公开实施例中，minibatch是指用少量几个训练样本(通常是100-1000个，这里的少是相对训练数据大小而言的)一起计算梯度，更新模型参数。

server本质上是分布式Key-value存储系统，它将一个非常大的模型，通过一致性Hash切成多片，在多个server上分担压力，进行模型分片。server保存了w，w可看作一套模型的向量w。每个模型副本只计算一部分的数据，相当于有并行的k(k为大于等于1的正整数)个worker。worker是将训练数据的不同行加载到不同的worker上，实现数据分片，同时通过计算接口完成梯度计算。worker和server通过pull(拉取)和push(推送)两个接口进行通信，完成模型的迭代更新。push主要是将worker上的梯度(例如，g₁，…g_q，q为大于等于1的正整数)推到server上；server更新(update)w之后，worker通过pull动作从server上拉取相应的w到本地。

训练过程开始后，worker 1直至worker k从server更新当前参数，然后利用当前参数以及本worker上的训练数据，计算得到当前的梯度，通过贪婪式方法，训练到不能再训练位置，然后将参数的更新量提交给server，再获取新的参数进行更新。

图9示意性示出了根据本发明的一实施例的模型存储的示意图。

参数服务中的server可以用于存储模型的模型参数的最终值，还包括用于模型计算，根据梯度和模型参数的初始值对模型参数进行更新。其中，server进程更新模型参数可以包括以下步骤：worker根据server中的模型参数和训练数据子集计算梯度；server根据梯度计算模型参数，在未发生异常退出情况下，这是一个循环的过程。

为了保证模型参数备份的及时性，本实施例采用了本地存储的方式，同时减少数据读写的IO消耗。本公开实施例中，本地存储是相对集群中的例如HDFS来说的，即直接将模型参数备份存放在设定的本地磁盘的某个路径下。

本公开实施例中，server在上述存储模型的模型参数的最终值和模型计算的基础上，还包括用于实时模型存储，及时存储新的模型参数，实现模型参数的增量存储。

需要说明的是，本公开实施例中所述新的模型参数是指由worker根据minibatch即一个训练数据子集确定了的那部分模型参数，可以包括新增加的模型参数，也可以包括原始模型参数的新参数值，还可以包括在当前worker的本批训练数据子集训练完后参数值未发生变化的模型参数。

图9所示，线程1可以用于负责模型计算，在计算好模型之后将增量模型存入缓存队列，其中所述增量模型是指worker根据minibatch确定了的那部分模型参数。

线程2可以用于负责实时模型存储。当线程2在缓存队列中检测到新的模型参数(即新存入的增量模型)之后，会及时的将该新的模型参数存入本地磁盘的第一类型模型文件(例如，图10中的Model_ing模型文件，表示正在写的文件，参数合并进程不对该文件进行读写)中。

存入本地磁盘的第一类型模型文件中的模型参数数量有限制，当超过阈值时，线程2启动新的模型文件作为第一类型模型文件，用作正在写入新的模型参数的模型文件，并将旧的第一类型模型文件即已经写满的第一类型模型文件更改文件名，作为第二类型模型文件存储。

其中，图9中所示的切分模型文件即指的是上述模型参数备份过程中，不是一直往一个模型文件中写入新的模型参数，而是有一个数量限制，如果当前第一类型模型文件中写入的新的模型参数达到所述阈值，就会重新创建一个第一类型模型文件继续存储。

需要说明的是，所述阈值可以根据具体情况设定，该阈值设置太大时，会导致第二类型模型文件太大，不利于后续的参数合并；该阈值设置太小时，会导致第二类型模型文件太多，本实施例中可以设置该阈值为500万。

可以在第二类型模型文件的文件名后缀添加数字编号，代表第二类型模型文件的创建时间先后顺序，例如该编号可以从0开始依次增大，但本公开并不限定于此，任意能够标识第二类型模型文件创建时间先后顺序的方式均属于本公开的保护范围。

需要说明的是，模型在服务器的内存称之为参数，存储至磁盘中就称之为模型。

图10示意性示出了根据本发明的一实施例的实时增量模型文件结构的示意图。

如图10所示，本实施例中的实时增量模型文件结构可以包括：第一类型模型文件：Model_ing；第二类型模型文件：Model_0，Model_1，Model_...，Model_n(n为大于等于0的整数)；第三类型模型文件：Model_m。其中，这些模型文件均存储在本地磁盘中。

图10的实施例中，第一至第三类型模型文件都有一个共同的前缀名字，该名字可以根据预先设定的命名规则创建，这里假设为Model，后缀可以有三种类型：第一类型模型文件的文件名后缀为下划线“_”加上“ing”，即Model_ing是正在写入的模型文件，当该第一类型模型文件中写入的模型参数数量达到阈值时就将该第一类型模型文件更改文件名为model_n(n为大于等于0的整数)的第二类型模型文件，重新建立Model_ing文件进行更新后的模型参数的实时写入；第二类型模型文件的文件名后缀为下划线“_”加上一个顺序编号的数字组成；第三类型模型文件的文件名后缀是下划线“_”加上“m”(这里的m代表英文“merge”，即合并的意思，而非指代数字编号)，这是由图10的参数合并进程创建的模型文件，用来合并以数字为文件名后缀的第二类型模型文件。

需要说明的是，上述第二类型模型文件的文件名后缀的n指的是当前第二类型模型文件中编号最大的那个第二类型模型文件。

本公开实施例中，所述文件名的命名规则可以为：一个时间字符串和一个随机码组成所述第一至第三类型模型文件的文件名，例如，201801241134_32413234，但本公开并不限定于此，任意能够防止与其他任务的备份文件发生冲突的文件名的命名规则均属于本公开的保护范围。

本公开实施例可以通过图10所示的实时增量模型文件结构实现模型参数的实时增量备份。其中，所述实时增量备份可以通过以下方式实现：在server每次更新模型参数后，直接将新的模型参数写入本地磁盘进行备份，一方面，可以实现模型参数备份的实时性，每一个minibatch更新一次；另一方面，可以实现模型参数的增量备份，即只需要更新最新的那部分(minibatch确定了的那部分参数)，占用磁盘的空间小，提高了模型参数备份的效率。

图11示意性示出了根据本发明的一实施例的参数合并的示意图。

由于本地备份需要较大的存储资源，而且一旦模型参数新的参数值(value)产生，旧的value就会作废，所以需要在存储中不断将旧的模型参数删除掉，替换为新的模型参数或者原始模型参数的新参数值。本公开实施例中，通过参数合并过程，用新的模型参数替换旧的模型参数，即将第二类型模型文件写入第三类型模型文件，同时，将已写入第三类型模型文件的第二类型模型文件直接删除掉，这个过程就叫参数合并(或者也可以称之为模型合并)。

如图11所示，所述参数合并可以表示为：Model_m+(Model_0，Model_1，Model_...，Model_n)＝Model_m(新)。

本公开实施例中，参数合并开始的条件可以是只要本地磁盘设定的存储路径中的当前文件夹下面有带数字编号的文件名后缀的第二类型模型文件生成，即可开始执行所述参数合并过程，这样可以保证参数合并的实时性，尽可能的减小本地磁盘的存储空间。但本公开并不限定于此，在其他实施例中，也可以设置一个触发阈值，例如当检测到带数字编号的文件名后缀的第二类型模型文件的数量达到所述触发阈值时，开始执行所述参数合并过程。

由于图10所示的实时增量模型文件结构中的模型文件中包含了大量的重复参数，并且会占用较大的磁盘空间，同时，随着模型训练过程的进行，新的模型参数产生后，旧的模型参数就没有用了，因此，需要把旧的模型参数用新的模型参数替换掉。

其中，参数合并的过程可以包括以下步骤：

第一步，将以数字为文件名后缀的第二类型模型文件以结尾数字从小到大排序。

例如，Model_0，Model_1，Model_...，Model_n。

需要说明的是，因为合并过程是不断进行的，第一次合并是第二类型模型文件可以是从文件名后缀为0的第二类型模型文件开始，但是后续的合并就不是从0开始了，而是从上一次合并后的下一个第二类型模型文件开始，例如，假设第一次合并了Model_0，Model_1，Model_...，Model_n，则第二次合并就是从Model_(n+1)开始。

本公开实施例中，当第一个第二类型模型文件被合并至第三类型模型文件以后，即使删除了第一个第二类型模型文件，之后的模型训练过程也不会立即生成文件名后缀从0开始的第二类型模型文件，而是在之前的编号基础上继续依次递增，即参数备份(即更新的模型参数写入第一类型模型文件以及将写满的第一类型模型文件存储为第二类型模型文件)和参数合并(即将第二类型文件写入第三类型文件，并删除已写入的第二类型文件)是两个异步的独立操作，而且可以同时并发执行，并不会参数合并完后重新从0开始。除非第二类型模型文件的文件名后缀增大至超过一个设定的整数范围，例如达到10亿的时候就又重新从0开始编号。

第二步，当存在以m为文件名后缀的第三类型模型文件Model_m时，读入所述第三类型模型文件至内存，再按照第一步的排序顺序读入第二类型模型文件。

第三步，将内存中的第二类型模型文件按照读入顺序依次写入以m为文件名后缀的第三类型模型文件Model_m，如果第三类型模型文件Model_m中前一第二类型模型文件例如Model_0写入的模型参数存在，就直接用后一第二类型模型文件例如Model_1写入的新的模型参数覆盖掉。

本公开实施例中，这里的覆盖指的是第三类型模型文件即m文件的覆盖，不包含数字文件名后缀的第二类型模型文件。

第四步，删除上述第三步已经被合并的以数字为文件名后缀的第二类型模型文件。

上述第一步至第四步的参数合并过程是重复进行的，Model_m是上一次的合并结果，Model_m(新)是本次的合并结果。

本公开实施例中，由于第二类型模型文件的文件名后缀的数字编号实际上代表了模型参数更新的顺序，所以合并的时候是以数字编号从小到大的顺序读取的，新的模型参数就能覆盖旧的模型参数，合并完毕后就是每个模型参数的最新值写入到了以m结尾的第三类型模型文件中。由于合并参数的第三类型模型文件中的模型参数都是无重复的，所以占据本地磁盘的存储空间并不大。

需要说明的是，上述参数合并的过程均是以文件名后缀为数字编号从小到大的第二类型模型文件为例进行举例说明的，但实际上，只要是根据第二类型模型文件的创建时间先后顺序进行模型参数的合并处理，均属于本公开的保护范围之内。

下面以一个具体的实例对本公开实施例的方法进行说明，这里假设所述方法应用于新闻或者视频推荐的模型训练过程中。

这里以视频推荐为例，首先获取训练数据：包含了用户特征、视频特征和环境特征，还有标签。其中，用户特征可以包括用户的性别、年龄、兴趣、爱好等，视频特征就是视频中描述的内容，环境特征就是观看位置、时间等，标签就是视频是否被观看。采用所述训练数据训练出来的模型就是各个特征的权重，越能区分出来视频是否被观看的特征权重越高，越是无法区分的特征权重越低。预测数据与训练数据的区分就是预测数据没有标签。预测数据和模型的组合的计算结果就是该视频被用户观看的概率有多大。

假设训练数据样例如下：

文件名为：

part-00000

part-00001

part-00002

……

其中数据格式如图12所示，该数据格式中，第一列是标签，广义上代表“是”和“否”，本实施例中代表用户是否点击了新闻或者视频；其中-4656675737798830455，5856910927885318503这些很大的数字代表了用户的特征或者视频的特征，特征后面的1.0代表特征的值。

模型参数样例如如图13所示。该模型参数样例中，第一列是特征，后面三列甚至更多列表示与特征相关的参数。

参数合并样例如下：

假设第一类型模型文件为：

app_20180113220107_350048873_back_part_15_backmodel_ing

app_20180113220107_350048873_back_part_18_backmodel_ing

第二类型模型文件为：

app_20180113220107_350048873_back_part_15_backmodel_1

app_20180113220107_350048873_back_part_15_backmodel_2

…

app_20180113220107_350048873_back_part_18_backmodel_1

app_20180113220107_350048873_back_part_18_backmodel_2

…

第三类型模型文件为：

app_20180113220107_350048873_back_part_15_backmodel_merge

app_20180113220107_350048873_back_part_18_backmodel_merge

其中，20180113220107_350048873这样的字符串代表任务的标识，中间的15，18代表模型分片的标志，末尾的”_ing”代表第一类型模型文件，”_1”以数字结尾的代表第二类型模型文件，_merge结尾的是第三类型模型文件。

其中，以5856910927885318503这个特征为例，app_20180113220107_350048873_back_part_15_backmodel_ing文件(第一类型模型文件)及其对应的第二类型模型文件和第三类型模型文件中是如图14所示。则参数合并过程如如图15所示。

其中，app_20180113220107_350048873_back_part_15_backmodel_ing文件不参与合并，也就是说第一类型模型文件是不参与合并的；只有第二类型模型文件和第三类型模型文件参与合并处理；但是下文中数据恢复的过程中第一类型模型文件参与，而且是最后一个读入的。

图16示意性示出了将本发明实施例所述方法应用于视频推荐的界面示意图。

如图16所示，假设用户甲在其终端设备上打开某视频网站或者视频APP(Application，应用程序)，后台接收到该用户甲的用户信息(例如登录用户名、密码、手机号码、终端设备的硬件信息等中的任意一种或者多种)时，可以根据训练好的视频推荐模型向该用户甲推荐其可能喜欢的视频节目，例如图6“爱看”条目下显示的视频节目。

这里假设同时采用100台服务器来训练该视频推荐模型，通过采集预设时间间隔(例如一小时)内的该视频网站或视频APP的历史数据(例如用户点击信息、用户播放时长信息、播放地点信息等等)作为一批次处理的训练数据子集，将当前批次的训练数据子集分配至该100台服务器上并行的进行训练，其中每台服务器训练获得该视频推荐模型的部分模型参数。

本实施例中，在该视频推荐模型的训练过程中，会实时的产生模型参数，该实时模型参数具有以下特点：

一方面，生成速度快。经过线上运行的数据显示和实验模拟，一个server生成的实时模型参数的速度为160M/S(160兆每秒)，正常情况下每个节点可以运行5个左右的server，峰值情况下可达10个，生成的实时模型参数为160*10＝1600M/S的数据，也就是96G/分钟。1T的磁盘不用10分钟就能够写满。从这里能够看出现有技术中，训练过程中节点之间需要传输大规模的实时参数，系统的瓶颈仍然在网络这块。因此，这样规模的数据如果存储到备份服务器(例如HDFS)，而出问题(系统异常退出)后再进行切换的方式来解决的话，很容易导致网卡阻塞，而延迟正式训练的过程，所以本实施例所提供的方法将更新的模型参数存储到本地磁盘，一方面，可以缓解模型训练过程中网络流量大的压力，另一方面，在系统出现异常情况时，可以较快速的实现数据无损恢复。

另一方面，在模型训练过程中，会产生大量的临时性中间数据。这些数据属于模型训练中的中间数据，不需要长期保留，只要训练结束，这些数据马上就可以删除，只保留最终的模型参数即可，而备份服务器一般是存储需要长期保留的数据。而本实施例所述方法为了减少存储的压力，训练中不断的删除旧模型参数，也就是一边生成新的模型参数，一边删除旧的模型参数，即通过参数合并的处理减少本地存储空间。还是以上述100台服务器为例，在该视频推荐模型训练完成后，最终的模型参数大约为500-600GB，平均分配到该100台服务器上，大约每台服务器上存储5-6GB的模型参数，因此，完全可以实现本地存储参数备份的目的。

本发明实施方式提供的用于数据生产系统的存储管理方法，通过本地存储的方式存储模型训练过程中更新的模型参数，一方面，由于模型参数备份存储于本地，从而可以减少IO(Input/Output，输入/输出)和网络资源的消耗；另一方面，由于存储的是更新的模型参数部分，即增量存储而非全量存储，可以减少存储空间。同时，该方法还通过将存储有模型参数的第二类型模型文件进行合并处理，在参数备份的同时还通过另一个异步的进程做模型参数的合并，且被合并的第二类型模型文件被删除掉了，可以进一步降低存储空间。

图17示意性示出了根据本发明的一实施例的模型恢复的示意图。

如图17所示，本公开实施例中的server还可以用于恢复模型参数。

本实施例中的恢复模型参数可以包括两种不同的情形：本地恢复和异地恢复。

其中，异地恢复是指，YARN(Yet Another Resource Negotiator，另一种资源协调者)在server发生异常退出的情况下，在另一台服务器(或者机器)上启动新的server替代旧的server，此时需要把发生异常退出(进程无法服务，或者进行的非正常退出，服务器故障一般情况下是指出现硬件故障，或者服务器上软件出现系统故障)的旧的server的模型参数拷贝到新的服务器上，进行参数恢复。而本地恢复是指旧的server发生异常情况时，在同一台服务器上启动新的server替代旧的server，此时直接从本地磁盘中读取旧的server的模型参数，进行参数恢复。

具体的参数恢复过程如下：

第一步，判断发生异常情况的server与新启动的server是否在同一个节点上，如果不在同一个节点上，先把旧的server的第一类型模型文件Model_ing、第二类型模型文件(Model_0，Model_1，Model_...，Model_n，...)和第三类型模型文件Model_m，从节点A传输至节点B，这里假设旧的server位于节点A上，新的server位于节点B上。

本实施例中，可以通过有线或者无线网络将旧的server的第一类型模型文件Model_ing、第二类型模型文件(Model_0，Model_1，Model_...，Model_n，...)和第三类型模型文件Model_m拷贝至新节点上的新的server上。

这里的节点可以指的是服务器，可以用IP地址进行标识，如果新的server和旧的server在同一个节点上就不做机器之间的传输，直接从本地备份的目录恢复参数。

第二步，先读入第三类型模型文件例如以m结尾的Model_m模型文件。

第三步，如果第二类型模型文件存在，就先把文件名以数字结尾的第二类型模型文件排序(可以按照从小到大的顺序，例如Model_0，Model_1，Model_...，Model_n，...)，再依次读入。

第四步，最后读入文件名以ing结尾的第一类型模型文件Model_ing。

需要说明的是，本实施例采用的参数恢复原则是以模型参数的新旧为基础，对于某个特定的模型参数，旧的先更新，新的最后更新，以保证恢复完毕后，存储中的模型参数是最新的模型参数。以m结尾的第三类型模型文件是以数字结尾的第二类型模型文件合并的结果，所以文件名以m结尾的第三类型模型文件中的模型参数是最旧的，文件名以数字结尾的第二类型模型文件次之，而且结尾数字越大，第二类型模型文件中的参数越新，以ing结尾的第一类型模型文件中的参数是最新的，所以最后更新。

需要说明的是，虽然上述实施例中均以模型训练过程为例来说明数据存储和数据恢复的过程，但实际上，本公开实施例提出的用于数据生产系统的存储管理方法可以应用于各种场合，例如，服务器接收的数据统计请求，根据该方法在服务器处理数据统计请求的过程中，可以同时将处理的中间数据结果进行备份存储，以用于系统发出异常情况下，根据备份的中间数据结果进行数据恢复。

通过上述方法训练好的模型，可以广泛应用于个性化推荐、搜索个性化等场景。

本公开实施方式提供的用于数据生产系统的存储管理方法，当当前节点的server进程异常退出时，可以通过启动另一节点的server进程，将备份的模型参数拷贝至该另一节点，从而可以实现模型参数的异地恢复，继续模型的训练过程，这样，即使当前节点的server进程出现异常，也不需要从头开始重新模型的训练，节省了时间资源和硬件资源。

以下介绍本发明的装置实施例，可以用于执行本发明上述的用于数据生产系统的存储管理方法。对于本发明装置实施例中未披露的细节，请参照本发明上述的用于数据生产系统的存储管理方法的实施例。

图18示意性示出了根据本发明的一个实施例的用于数据生产系统的存储管理装置的框图。

参照图18所示，根据本发明的一个实施例的用于数据生产系统的存储管理装置1800，包括：第一存储模块1810、第二存储模块1820、第三存储模块1830以及文件删除模块1840。

其中，第一存储模块1810可以配置为针对所述更新的数据进行本地存储，生成第一类型文件。

第二存储模块1820可以配置为当所述第一类型文件中存储的数据数量达到阈值时，将所述第一类型文件存储为第二类型文件。

第三存储模块1830可以配置为对所述第二类型文件进行合并处理，存储至第三类型文件。

文件删除模块1840可以配置为删除已进行合并处理的所述第二类型文件。

在示例性实施例中，第三存储模块1830可以包括第三存储单元。其中所述第三存储单元可以配置为根据创建时间先后顺序依次将所述第二类型文件写入所述第三类型文件。

在示例性实施例中，所述第三存储单元可以包括文件排序子单元、第一文件写入子单元以及数据写回子单元。其中，所述文件排序子单元可以配置为将所述第二类型文件按照创建时间先后顺序排序。所述第一文件写入子单元可以配置为将所述第二类型文件按照排列顺序依次写入内存，用所述更新的数据的新参数值覆盖旧参数值。所述数据写回子单元可以配置为将所述内存中的数据存储至所述第三类型文件。

在示例性实施例中，所述第三存储单元还可以包括第二文件写入子单元。其中，所述第二文件写入子单元可以配置为将所述第三类型文件写入所述内存。

在示例性实施例中，所述第二类型文件的文件名相关于所述第二类型文件的创建时间。

在示例性实施例中，所述更新的数据可以包括模型训练过程中更新的模型参数。

在示例性实施例中，用于数据生产系统的存储管理装置1800还可以包括梯度计算模块和模型计算模块。其中，所述梯度计算模块可以配置为读取训练数据子集获取当前梯度。所述模型计算模块可以配置为根据历史梯度、历史模型参数向量和所述当前梯度获取所述更新的模型参数。

图19示意性示出了根据本发明的一个实施例的用于数据生产系统的存储管理装置的框图。

参照图19所示，根据本发明的一个实施例的用于数据生产系统的存储管理装置1900，包括：第一存储模块1810、第二存储模块1820、第三存储模块1830、文件删除模块1840以及数据恢复模块1910。

本实施例中的第一存储模块1810、第二存储模块1820、第三存储模块1830、文件删除模块1840可以分别参照上述图19所示的实施例，在此不再详述。

在示例性实施例中，数据恢复模块1910可以配置为当所述数据生产系统异常退出时，根据异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件进行数据恢复。

在示例性实施例中，数据恢复模块1910可以包括系统启动单元、数据传输单元以及数据恢复单元。其中，所述系统启动单元可以配置为当所述数据生产系统异常退出时，启动新系统。所述数据传输单元可以配置为当所述数据生产系统和所述新系统不在同一个节点上时，将所述数据生产系统异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件传输至所述新系统所在的节点。所述数据恢复单元可以配置为根据所述数据生产系统异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件进行数据恢复。

在示例性实施例中，数据恢复模块1910还可以包括本地文件读取单元。其中，所述本地文件读取单元可以配置为当所述数据生产系统和所述新系统在同一个节点上时，读取本地存储的所述数据生产系统异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件。

在示例性实施例中，所述数据恢复单元包括第一读入子单元、第二读入子单元以及第三读入子单元。其中，所述第一读入子单元可以配置为读入所述数据生产系统异常退出时的所述第三类型文件至内存。所述第二读入子单元可以配置为将所述数据生产系统异常退出时的所述第二类型文件按照创建时间先后顺序依次读入至所述内存。所述第三读入子单元可以配置为读入所述数据生产系统异常退出时的所述第一类型文件至所述内存。

应当注意，尽管在上文详细描述中提及了用于动作执行的装置的若干模块或者单元或者子单元，但是这种划分并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多模块或者单元或者子单元的特征和功能可以在一个模块或者单元或者子单元中具体化。反之，上文描述的一个模块或者单元或者子单元的特征和功能可以进一步划分为由多个模块或者单元或者子单元来具体化。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本发明实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本发明实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。

Claims (14)

1.一种数据存储管理方法，其特征在于，所述数据存储管理方法应用于数据生产系统，所述数据生产系统用于实时产生海量的更新的数据，所述数据存储管理方法包括：

针对所述更新的数据进行本地存储，生成第一类型文件，所述第一类型文件是用于实时写入所述更新的数据的文件；

当所述第一类型文件中存储的数据数量达到阈值时，将所述第一类型文件本地存储为第二类型文件，创建新的第一类型文件继续用于后续更新的数据的实时写入，所述第二类型文件的文件名相关于所述第二类型文件的创建时间；

对多个所述第二类型文件中存储的数据进行合并处理，本地存储至第三类型文件，通过命名规则来命名所述第三类型文件的文件名，以将所述第二类型文件和所述第三类型文件区别开来；

删除已进行合并处理的所述第二类型文件；

其中，对多个所述第二类型文件中存储的数据进行合并处理，本地存储至第三类型文件，包括：

将所述第二类型文件按照创建时间先后顺序排序；

将所述第二类型文件按照排列顺序依次写入内存，每次读入新的第二类型文件时，用所述更新的数据的新参数值覆盖旧参数值，如果是所述更新的数据中新增的数据，则直接写入所述内存；

将所述内存中的数据存储至所述第三类型文件；

将所述第三类型文件写入所述内存，本次合并后的新的参数值覆盖前一次合并后的所述第三类型文件中的旧的参数值，更新所述第三类型文件中存储的数据。

2.根据权利要求1所述的数据存储管理方法，其特征在于，还包括：

当所述数据生产系统异常退出时，根据异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件进行数据恢复。

3.根据权利要求2所述的数据存储管理方法，其特征在于，当所述数据生产系统异常退出时，根据异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件进行数据恢复，包括：

当所述数据生产系统异常退出时，启动新系统；

当所述数据生产系统和所述新系统不在同一个节点上时，将所述数据生产系统异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件传输至所述新系统所在的节点；

根据所述数据生产系统异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件进行数据恢复。

4.根据权利要求3所述的数据存储管理方法，其特征在于，当所述数据生产系统异常退出时，根据异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件进行数据恢复，还包括：

当所述数据生产系统和所述新系统在同一个节点上时，读取本地存储的所述数据生产系统异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件。

5.根据权利要求3或4所述的数据存储管理方法，其特征在于，根据所述数据生产系统异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件进行数据恢复，包括：

读入所述数据生产系统异常退出时的所述第三类型文件至内存；

将所述数据生产系统异常退出时的所述第二类型文件按照创建时间先后顺序依次读入至所述内存；

读入所述数据生产系统异常退出时的所述第一类型文件至所述内存。

6.根据权利要求1所述的数据存储管理方法，其特征在于，所述更新的数据包括模型训练过程中更新的模型参数，所述方法还包括：

读取训练数据子集获取当前梯度；

根据历史梯度、历史模型参数和所述当前梯度获取所述更新的模型参数。

7.一种数据存储管理装置，其特征在于，所述数据存储管理装置应用于数据生产系统，所述数据生产系统用于实时产生海量的更新的数据，所述存储管理装置包括：

第一存储模块，配置为针对所述更新的数据进行本地存储，生成第一类型文件，所述第一类型文件是用于实时写入所述更新的数据的文件；

第二存储模块，配置为当所述第一类型文件中存储的数据数量达到阈值时，将所述第一类型文件本地存储为第二类型文件，创建新的第一类型文件继续用于后续更新的数据的实时写入，所述第二类型文件的文件名相关于所述第二类型文件的创建时间；

第三存储模块，配置为对多个所述第二类型文件中存储的数据进行合并处理，本地存储至第三类型文件，通过命名规则来命名所述第三类型文件的文件名，以将所述第二类型文件和所述第三类型文件区别开来；

文件删除模块，配置为删除已进行合并处理的所述第二类型文件；

其中，所述第三存储模块包括第三存储单元，所述第三存储单元包括：

文件排序子单元，配置为将所述第二类型文件按照创建时间先后顺序排序；

第一文件写入子单元，配置为将所述第二类型文件按照排列顺序依次写入内存，每次读入新的第二类型文件时，用所述更新的数据的新参数值覆盖旧参数值，如果是所述更新的数据中新增的数据，则直接写入所述内存；

数据写回子单元，配置为将所述内存中的数据存储至所述第三类型文件；

第二文件写入子单元，配置为将所述第三类型文件写入所述内存，本次合并后的新的参数值覆盖前一次合并后的所述第三类型文件中的旧的参数值，更新所述第三类型文件中存储的数据。

8.根据权利要求7所述的数据存储管理装置，其特征在于，还包括：

数据恢复模块，配置为当所述数据生产系统异常退出时，根据异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件进行数据恢复。

9.根据权利要求8所述的数据存储管理装置，其特征在于，所述数据恢复模块包括：

系统启动单元，配置为当所述数据生产系统异常退出时，启动新系统；

数据传输单元，配置为当所述数据生产系统和所述新系统不在同一个节点上时，将所述数据生产系统异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件传输至所述新系统所在的节点；

数据恢复单元，配置为根据所述数据生产系统异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件进行数据恢复。

10.根据权利要求9所述的数据存储管理装置，其特征在于，所述数据恢复模块还包括：

本地文件读取单元，配置为当所述数据生产系统和所述新系统在同一个节点上时，读取本地存储的所述数据生产系统异常退出时的所述第一类型文件、所述第二类型文件和所述第三类型文件。

11.根据权利要求9或10所述的数据存储管理装置，其特征在于，所述数据恢复单元包括：

第一读入子单元，配置为读入所述数据生产系统异常退出时的所述第三类型文件至内存；

第二读入子单元，配置为将所述数据生产系统异常退出时的所述第二类型文件按照创建时间先后顺序依次读入至所述内存；

第三读入子单元，配置为读入所述数据生产系统异常退出时的所述第一类型文件至所述内存。

12.根据权利要求7所述的数据存储管理装置，其特征在于，所述更新的数据包括模型训练过程中更新的模型参数；其中，所述装置还包括：

梯度计算模块，配置为读取训练数据子集获取当前梯度；

模型计算模块，配置为根据历史梯度、历史模型参数向量和所述当前梯度获取所述更新的模型参数。

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

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

一个或多个处理器；

存储装置，配置为存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1至6中任一项所述的方法。

Images