一种数据更新方法与流程

本发明涉及大数据处理技术领域，尤其涉及一种基于elasticsearch的数据更新方法。

背景技术：

elasticsearch是一个开源的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于restfulweb接口。elasticsearch是用java开发的，并作为apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。

elasticsearch是当前非常流行的企业大数据解决方案系统组件，兼具数据存储和搜索引擎的功能。在使用elasticsearch作为数据存储的技术方案中，数据更新是一个常见的数据操作，elasticsearch为数据更新提供了以下的特性：elasticsearch为每一条数据记录记录一个内部版本号(_version)。当记录被第一次创建时，elasticsearch为其设定_version＝1；每一次对此记录执行更新(update)操作时，elasticsearch对比要更新的字段值和原记录字段值是否完全相同，如果完全相同，elasticsearch忽略此次更新，保持原记录不变，如果不完全相同，elasticsearch执行更新操作，并把记录的内部版本号(_version)加一(假设原记录内部版本号为1，变更后内部版本号变为2)。

在大数据处理系统中，数据更新一般通过批量操作来执行，在不做全量数据对比的情况下，无法获知数据更新过程中，数据是否真的发生更新。数据实际更新未知性，导致在数据处理的全流程中，无法进行增量数据处理，导致整个计算系统的资源巨大浪费。

技术实现要素：

本发明针对现有技术的不足，提出一种基于elasticsearch的数据更新方法。

本发明的目的是通过以下技术方案来实现的：一种数据更新方法，该方法包括以下步骤：

步骤一：在数据记录上添加业务数据版本号out_version。

步骤二：同步业务数据版本号out_version和elasticsearch的内部版本号_version。

步骤三：执行实际的业务数据更新操作。

步骤四：在业务数据更新操作完成以后，通过对比业务数据版本号out_version和内部版本号_version的值来判断数据是否实际发生更新。

进一步地，步骤一中，将业务数据版本号out_version初始化为1。

进一步地，步骤二中，同步业务数据版本号out_version和elasticsearch的内部版本号_version的方法具体为：首先获得数据记录的内部版本号_version，假定为n，然后对该数据记录做一次更新操作，更新内容为out_version＝n+1，使得更新后业务数据版本号out_version等于内部版本号_version。

进一步地，步骤四具体为：如果业务数据版本号out_version等于内部版本号_version，则判断业务数据没有发生实际更新；如果业务数据版本号out_version小于内部版本号_version，则判断业务数据发生了实际更新。

进一步地，步骤四中，对判断为实际更新的数据打上一个时间标记，表示该数据在此次数据处理周期中发生了实际更新。

进一步地，在下一个数据处理周期到来时，重复执行步骤二、三和四，即可再次指出此次数据处理周期中实际发生更新的数据记录。

本发明的有益效果是：本发明结合elasticsearch自身的系统特点，提出了一种数据更新方法，在数据处理流程源头即可判断和标识出实际更新的数据，从而减少了数据处理流程下游的数据处理量，大大减少了计算系统的资源浪费。

附图说明

图1为本发明数据更新方法流程图。

具体实施方式

下面结合附图和具体实施例对本发明作进一步详细说明。

如图1所示，本发明提出的一种数据更新方法，该方法结合elasticsearch的数据内部版本号_version和自定义的业务数据版本号的同步，更新，对比来判断数据是否发生实际更新。该方法可以重复实施，并保持有效。该方法具体包括以下步骤：

第一步，添加业务数据版本号字段。为了判定数据是否真实更新，在数据记录上添加一个业务数据版本号字段，假定字段名称为out_version，并对out_version做初始化，例如可以直接设置为1。

第二步，同步业务数据版本号和内部版本号_version。方法为：首先获得数据记录的内部版本号_version，假定为n，然后对该数据记录做一次更新操作，更新内容为out_version＝n+1(因为业务数据版本号更新操作也会导致_version自增1)，使得更新后业务数据版本号out_version＝内部版本号_version。

第三步，执行实际的业务数据更新操作。这一步就是原来实际的业务数据更新过程。

第四步，检查和标记实际数据更新。在业务数据更新操作完成以后，通过对比业务数据版本号out_version和内部版本号_version的值是否相等，来确定数据是否实际发生更新，方法是：如果业务数据版本号out_version等于内部版本号_version，则判断业务数据没有发生实际更新；如果业务数据版本号out_version小于内部版本号_version，则判断业务数据发生了实际更新。此时可以对实际更新的数据打上一个时间标记，一般设置为当前时间，表示该数据在此次数据处理周期中发生了实际更新。

该数据更新方法可重复实施，并保持有效的特性。在下一个数据处理周期到来时，重复执行步骤二、三和四，即可再次指出这个处理周期中实际发生更新的数据记录。

以下为一个更为具体的数据更新实例。

假设已经存在索引(index)名为：test_person，已经写入了一条记录，如下：

可以看到，这条数据当前的内部标记号(_id)为2，内部版本号(_version)为4。

为了追踪这条数据的实际更新情况，第一步，添加业务数据版本号字段。不失一般性，设定业务数据版本号字段名称为out_version，并设置初始值为1。操作如下：

此时，再看这条数据，因为新增了一个字段，内部版本号(_version)更新为5。数据如下：

第二步，同步业务数据版本号和内部版本号。令业务数据版本号out_version＝6，方法如下：

再查看该条数据，现在业务数据版本号out_version已经和内部版本号(_version)相同，均为6。

第三步，执行实际的业务数据更新操作。现在，我们来执行业务更新，我们把这条记录的age字段变更为28，操作如下：

第四步，检查实际数据更新。此时我们查看这条数据，数据如下：

可见内部版本号(_version)等于7，业务数据版本号out_version等于6，依据规则：如果业务数据版本号out_version等于内部版本号(_version)，则判断业务数据没有发生实际更新；如果业务数据版本号out_version小于内部版本号(_version)，则判断业务数据发生了实际更新。判定数据发生了实际更新，这个时候我们可以给数据打上更新时间戳，方法如下：

再看数据：

这样就能给这条记录打上更新的标识，来确定数据真实的更新时间，为下游的数据增量处理打下基础。在任何想对数据执行更新操作的时候，只需要顺序执行上述的步骤。

上述实施例用来解释说明本发明，而不是对本发明进行限制，在本发明的精神和权利要求的保护范围内，对本发明作出的任何修改和改变，都落入本发明的保护范围。