用于合并数据的系统和方法与流程

本公开涉及数据处理领域。具体地，本公开涉及用于合并数据的系统和方法。

背景技术：

本公开提出了用于通过实时流计算融合大量计算以支持网络相册(Flickr)的神奇视图(Magic View)的新型架构。Magic View被设计为一种愉快的体验，仅基于图像内容，它提供了基于用户自己的照片流的示图的对象和主题。为了实现该目的，本公开中的系统使用针对实时计算和批量计算的单一表格，并推进读取的一致性。为了处理关于传统架构(称为Lambda架构)的复杂度的问题之一，所公开的系统能够显著地简化实现方式而仍旧能够实现一种快速响应的实时数据库，该数据库可操作的规模为300亿个记录，其中5000万个记录每天被递增式增加和更新。

该系统允许以极低延迟，非常广泛并深入地服务来自Lambda架构的数据。该系统具有非常适度的硬件和软件足迹(footprint)(这是一种概念模式)。该系统的设计还促进精确的(surgical)实时更新和整体数据集的更新二者，同时维持高度的一致性和正确性。

我们面临的挑战是将数据从大的周期性静态记录集(回填)投射到服务系统的长周转时间。该问题由于大数据集通常是以千万亿字节大小为规模而尤其严重。Map-reduce(映射化简)已经可以很好地用于较快地创建和存储回填。挑战已成为如何在同样合理的时间帧(若干小时或天，而非若干天或周)内将这些回填投射到我们现有的服务栈(关键值存储、RDBMS、和搜索引擎)。

此外，我们从不同的系统生成额外的、日益增长的主数据记录集，并且数据以高速率改变(大约1亿次记录更新/天)，当该数据与回填合并时可形成超过200亿的记录集。我们需要以低延迟经由我们的API，采取统一的方式向数以千万的用户同时服务该数据，并维持高度的一致性和正确性。

最终，我们的数据中的一些数据由稳定发展和改进下的前沿算法生成。平均每6-8周，存在遍历整个记录集重新计算该数据的显著用户利益。这可能需要对我们的数据进行完全的更新，同时继续以低延迟和高规模服务新的更新。

HBase是开源的分布式数据库，HBase作为灵活的大规模关键值数据存储已经很成熟，其可以促进非常快速的批量加载(大于每秒400k条记录)，同时从实时更新写入同一HBase基础设施(区域服务器、表格等)。随后所造成的问题是如何实际地合并这些“实时”源和“回填”源的数据。

我们实时地使用预测性活动队列来执行这一点，“缓存引(cache primer)”或“Warmr”(我们对其的称呼)观察和扫描HBase以将实体投射到一个低延迟服务层(在我们的情况下为Redis)。

首先在下文介绍合并实时数据和回填数据的概念。有两种类别的数据单元，分别为“属值(Values)”和“王牌(Trumps)”。“属值”为将被投射到服务层的实体的属性(例如：拍摄照片的日期)。“王牌”表示从缓存中删除实体的信号。所有的单元通过实时表示和回填表示之间的“同属(sibling)”双重引用来建模。该算法为：“王牌”始终胜过“属值”(故有此名称)且实时始终胜过回填。

我们所取得的作为Warmr中一部分的一项创新是最小化HBase扫描IO出同时保持上部分(above-the-fold)冷缓存(cold-cache)的低延迟(我们已在第95百分位实现了300ms)。为了达到这一点，我们将HBase扫描结果的最大时间戳快照到缓存层。这允许我们在稳态时只需为最近的数据变化(即，其时间戳在来自前次扫描的快照时间戳之后的单元)对HBase进行高频扫描。这增加了实时/回填优先级分级/合并算法的复杂性。

由于“王牌”单元始终取得高于“属值”单元的优先级，且“实时”单元始终胜过它们“回填”的同属，我们有时需要在HBase上针对同一行运行多次取值。所以例如，如果我们在某个时间范围内扫描并只找到了回填数据，则我们必须针对任意可能的实时数据进行及时(back-in-time)回查。通过把这部分“Warmar”封装为一个HBase协同处理器，这种额外的HBase IO可以得到缓解。

有关这种“实时胜过回填”算法的问题在于，实时“路径(lane)”可能阻碍被写入回填的新的更新。我们通过统筹“清除”阶段来解决该问题，在该“清除”阶段中，仔细挑选的实时数据集被周期性地移动到回填单元。通过与在映射化简(map-reduce)中处理的起作用的批量数据的低水印数据时间戳仔细地协调，这一点被完成。实践中，我们的实时系统比我们的批量系统更容易出错，所以以每天或每周的频率运行该过程具有校正数据的额外优点，该数据可能在实时处理期间已经丢失。

回填清除检查我们标准的存储在磁盘上的、用来标识最大时间段的数据集，我们已知该数据集是正确的，即不会仍然通过实时或数据处理流写入该数据集。该标准数据集的块包括可能从实时数据流丢失的数据(该情况定期发生)，所以我们将该数据加载至数据库的批量部分。对于数据库中相同标识的时间段，我们随后标识任意实时更新，该实时更新可能“胜过”刚加载的标准批量数据并将该数据“公布”于批量列，以及将实时列中现在过期的数据消除。时序图在图6中示出。

该系统主要益处是实现、扩大和调试比较简单。该系统从数据库架构强(strongly)解耦，所以它还提供了操作简易性。数据库可以被“现场”更新，同时Warmr正在运行并且Warmr将提供最终一致的结果；该系统额外的优点是其允许大规模的经解耦回填。

最后，该系统的规模是轻量级的；其实际的实现方式不需要很多用于将数十亿的记录存储至大内存缓存的硬件和存储器。

该系统允许以极低延迟，非常广泛并深入地服务来自Lambda架构的数据。该系统具有非常适度的硬件和软件足迹(这是一种概念模式)。该系统的设计还同时促进精确的(surgical)实时更新和整体数据集的更新，同时维持高度的一致性和正确性。

网络相册曾试图将我们的计算机视觉技术以一种愉快的方式呈现给用户。神奇视图(Magic View)基于自动标签以分类学的方式将用户的照片进行聚合和分组，并提供无缝的、“快速导航”视图，例如，将用户照片中所有的“猫”分为一组。

技术实现要素：

本发明提供了一种用于合并数据的方法。该方法包括：获得第一属性值，其中第一属性值表示数据项的方面；获得述第一属性有关的第二属性值，其中第二属性值表示数据项的方面；选择将用来确定表示数据项的第三属性值的方案；以及根据所选的方案以及第一属性值和第二属性值来确定所述第三属性值。

附图说明

图1示出了根据本教导的实施例的照片的神奇视图(magic view)。

图2示出了根据本教导的实施例的将照片添加到magic view类别。

图3示出了根据本教导的实施例的典型Lambda架构的示例。。

图4示出了根据本教导的实施例的系统的概览和(相比于图3中经典的实现方式的)增强型Lambda架构。

图5示出了根据本教导的实施例的系统的概览和(相比于图3中经典的实现方式的)另一增强型Lambda架构。

图6示出了根据本教导的实施例的用于合并数据的方法的时序图。

图7示出了根据本教导的实施例的用户认知的时间的图表。

图8描绘了可以用来实现专门实现本教导的系统的移动设备架构；以及

图9描绘了可以用来实现专门实现本教导的系统的计算设备架构。

具体实施方式

图1示出了根据本教导的实施例的照片的神奇视图(magic view)。通过应用我们前沿的计算机视觉技术，网络相册的神奇视图基于照片的内容自动地将用户的照片流中的照片进行分类并且将其以无缝的视图呈现，从而解决整理用户自己照片时的麻烦。这都是实时发生的。只要照片被上传，该照片就被分类并被置于神奇视图中。图2示出了根据本教导的实施例将照片添加到神奇视图分类。

最初的考虑是将这些聚合作为每日的、批量计算任务来计算。实验表明它没有实时地达到实现工作的预期。另外的考虑包括使其整体地被流计算驱动，在空中建立聚合，但这没有达到全面向用户供应历史数据的预期。

当照片被上传时，我们的计算机视觉流水线处理该照片，从而生成一组自动标签(autotag)，该自动标签是图像内容的文本描述。当我们具有对上传照片中的自动标签执行流计算的现有架构时，神奇视图需要数据存储，该数据存储计算它们的每个用户的聚合。另外，将必须维持这些聚合。如果照片被添加、移除、或更新，则该聚合将需要被精确地更新来反应这一点。我们还将需要利用系统中全部120亿张照片的自动标签对系统进行初始化，并针对流计算丢失图像的情况运行定期回填。

我们需要系统，该系统针对网络相册上的超过120亿张图像创建每一用户的神奇视图分类，以及当实时数据流入时，利用从实时数据产生的数千万个标签来更新这些分类。理想地，该系统必须允许我们有效但是单独地管理批量数据和实时数据，该系统仅在被请求时计算最终状态。我们转向Yahoo的Hadhoo堆栈，来找出以我们所需的超大规模来建立这一点的方式。

由Apache HBase支持，我们开发了一种新方案来融合来自批量和实时聚合的结果。使用HBase中的单一表格，我们能够独立地更新并管理系统的批量数据和实时数据，同时始终能够提供一致的、正确的结果。

Pig和Oozie用于快速地计算和加载大规模、线下的批量计算。这些鲁棒工具对于快速初始化系统以及定期回填任意丢失数据是很好的。Storm用于支持将数据实时提取到系统，并被Java层调解，该Java层将写入分散到HBase。当用户请求查看他们的数据时，最终的Java过程负责将批量数据和实时数据合并到其最终状态。

该解决方案是对有时被称为Lambda架构的创新改进。我们通过简化基本的Lambda架构的一些复杂度，使得维护和开发更为容易，改进了该基本的Lambda架构。

传统的数据库查询是在其存储的所有数据上进行操作以获取结果的函数。其可以被抽象为：

结果＝查询(数据)

在2011年，公布了“如何打败CAP定理(How to Beat the CAP Theorem)”的重要文章，其中公开了“Lambda架构”。Lambda架构的核心利用实时数据库和批量数据库替代了传统数据库，并且将查询函数的框架修改为：

结果＝合并(查询(实时数据)+查询(批量数据))

图3示出了典型的Lambda架构的示例。该典型的Lambda架构由它的记录系统的“只附加”队列所支持，该记录由事件的实时流所提供。周期性地，队列中的所有数据被提供至批量计算，该批量计算预处理数据以针对查询对其进行优化，并且将这些聚合存储到批量计算数据库。实时事件流驱动流计算机，该流计算机将进入事件处理至实时聚合中。随后查询经由查询合并器进行，该查询合并器查询批量数据库和实时数据库二者，计算二者的合并并且存储结果。

同时，较新的Lambda架构很受欢迎，并且已经建立了若干具体实现方式。两个重要的实例是分布式分析平台druid和Twitter的Summingbird。两种实现方式提取查询合并器后面的数据库。

这种类型的架构经由最终一致性享有稳定性和容错性。如果数据块在实时计算中被略过，则保证该数据块将最终出现在批量计算数据库中。

对Lambda架构的批判集中于合并器的复杂度。合并器在多个方面存在弱点：来自需要维持两个(通常是非常不同的)数据库的开发者和系统的成本、查询两侧的不同延迟以及随后合并结果的复杂度。

虽然Lambda架构好像自然地适合于我们的问题，但是我们反对单独的数据库所带来的成本和复杂度。替代的，我们使用HBase(BigTable类型的非关联性数据库)来实现单个数据库系统，该HBase将查询函数简化为：

结果＝合并器(查询(数据))

通过利用单个数据库支持该系统，这解决了Lambda架构的主要顾虑，显著地简化了复杂度和代码路径。这是如何实现的呢？针对HBase中的单行数据，我们具有实时列和批量列的概念。这两种列的集合分别由实时子系统和批量子系统单独管理。在查询时间，我们执行单独的取值，并且合并器将从批量数据和实时数据组合最终的结果。

我们的具体实现方式是集中于使用HBase，作为多值存储的关键。这通过Pig Latin中的批量计算来初始化，通过Storm实时更新，并且通过基于批量计算的回填过程来保证正确性。合并器可以是使用新型方案的Java过程，以最小化或甚至隐藏来自用户的读取延迟。

下文将公开该系统的具体实现方式的细节，仔细检查关于延迟和可用性的结果并讨论一些未来趋势。

图4示出了系统的概览和(相比于图3中经典的实现方式)我们的增强型Lambda架构。出于本讨论的目的，便捷的概述是考虑在HBase中表示给定照片的当前状态的每一行。我们通过对每一行给出两个列的集合(实时和批量)来实现我们的经简化Lambda架构，这两个列的集合由实时子系统(storm)和批量计算子系统(Pig Latin和Oozie)单独地管理。合并器阶段被抽象为在其自身硬件(Warmr)上运行的单个Java过程，该Java过程计算HBase中的数据，并将该数据发送至由站点的服务层使用的Redis缓存。

当照片被上传时，我们的计算机视觉流水线处理该照片，从而生成一组自动标签，该自动标签是图像内容的文本描述。当我们具有对上传照片中的自动标签执行流计算的现有架构时，神奇视图需要数据存储，该数据存储计算它们的每个用户的聚合。另外，将必须维持这些聚合。如果照片被添加、移除、或更新，则该聚合将需要被精确地更新来反应这一点。我们还将需要利用系统中全部120亿张照片的自动标签对系统进行初始化，并针对流计算丢失图像的情况运行定期回填。

神奇视图中的HBase

在下文中，在系统中我们主要的表格的设置和生命周期，所有者-照片-自动标签(owner_photo_autotags)被描述。在该表格中，我们具有每一行：行键，采用所有者标识(owner_id)的md5总和以及对给定照片附加照片标识(photo_id)和自动标签，例如，md5(ownerId)_photoId_autotag；以及针对每个行键的列的集合，这些列可能被填充或者可能未被填充-实时-[得分、隐藏、删除]以及批量-[得分、隐藏、删除]。

典型的照片将具有一个或多个自动标签。那么，照片的完整描述将是行的集合，该集合的行键(例如，在HBase中彼此相邻)可以是md5(ownerId)_photoId_ski、md5(ownerId)_photoId_snow、md5(ownerId)_photoId_mountain。便利地，HBase提供扫描过滤器运算符，该扫描过滤器运算符允许我们使用简单的表达式(regex)(例如，md5(ownerId)_photoId_*)，很容易地选择针对给定照片的所有数据。遵循该逻辑，利用甚至更宽泛但是简单的表达式(例如，md5(ownerId)_*)使用扫描过滤器，可以实现对给定用户选择所有数据。

在HBase中读取的一致性-Warmr

我们具有与HBase中的每一行相应的列的两个集合-批量属性和实时属性。针对这些集合中的每一个集合，我们维持若干个属性。在一些实施例中，三个属性可以作为列来表示：

得分-我们在针对这一照片的自动标签中具有的计算机视觉置信度。我们用该得分来进行分类。每当计算机流水线被升级时该数值将被更新。

隐藏-用户具有隐藏给定照片的自动标签的选项。如果他们选择了该选项，则这会被设定为这里的一种标志，并且该特定自动标签的照片在神奇视图中将不再示出。

删除-如果照片已经被删除，则设置该标志。这是很重要的，这使得如果用户已经删除照片，则我们尽快地将该照片从在神奇视图中移除。所以该标志可以作为需要移除的信令。

在该实施例中，合并器(我们称之为Warmr)合并这六列中的所有数据。例如，为了确定每个属性的最终值：在存在实时数据而不存在批量数据(或反之亦然)的情形下，则仅有一个值用来选择；在二者均存在的情形下，我们始终选择实时值。

在确定经决定的值或最终值之后，系统可能未在长期存储中存储该经决定的值，但是可以将每个经决定的值转换到服务缓存上的“添加”或“删除”。此外，该系统可以采用来自在扫描中返回的单元的最大时间戳，这样在随后的扫描中仅将返回新的数据。这维持了容易管理的持久状态，并且使状态机的复杂度最小化以维持批量系统和实时系统的简化。

在另一实施例中，系统在长期存储中(例如，在上述描述的表格中设置的附加列)存储经决定的值。

定期地运行回填任务将定期扫过Hbase中行的集合(通常通过时间相关联)。由于该数据已经“稳定”，因此该任务将数据从实时列移动到批量列，这使得读取正确数据的挑选任务更为简单。

流计算-增量更新

针对神奇视图，我们具有驱动系统的三个流事件集合：

照片上传，生成新的照片标识(photoId)和与之相应的自动标签的集合。

自动标签隐藏，对给定的自动标签，这是将照片从神奇视图聚合移除的信号。

照片删除，这是将照片从所有神奇视图聚合移除的信号。

照片替换，利用新的集合替换给定照片的自动标签的一个集合。这些事件被馈送到Storm出口(spout)集合，其转而将这些事件发送到我们的数据访问对象(Data Access Object)。

数据访问对象(Data Access Object，DAO)

数据访问对象是Java类，我们建立该Java类，用来交互和管理给定照片或自动标签对象的实时列中的数据。数据访问对象将高等级事件(照片上传、照片删除和替换、和自动标签隐藏)映射到HBase的获取和放置操作的最小集合。在DAO中，我们还“扩充(enrich)”自动标签，作为给定图像变化的自动标签集合。这将支持神奇视图中的分类树，并且作为示例，它通常包括，在呈现出“滑雪”、“下雪”、和“山”的自动标签时，添加经扩充的“运动”标签。

在理想世界中，这些高等级操作将映射到原子事务。然而，实践中，我们发现因为我们跨多个表格获取和放置数据，所以锁定会导致极差的性能，并且实践中，我们没有看到针对事务的任何实际需求。

批量计算

系统初始化

我们考虑首先通过重演通过DAO的事件流的完整历史，来对HBase中的表格进行初始化。虽然这产生正确的结果，但是花费了太长的时间。为了加载10年值的数据，我们计划28天的加载时间。这主要归结于，如事务讨论中所提到的，需要对每个事件的多个表格进行写入和读取。

替代地，我们尝试预计算每个表格的数据并直接加载该数据，该加载时间为7个小时。我们认识到可以通过将批量数据和实时数据分离到不同的列来避免批量和实时的冲突，并且这导致本文的中心创新点。

回填

在网络相册，我们具有在每天或每周的基础上被转储到网格的SQL表格的若干静态副本。我们参考作为网络相册ALL Raw或FLAR的元数据的集合。我们还建立用于将我们在网络相册上的每个单独图像的小版本复制到网格并且将其存储到顺序文件中的系统，即我们的照片像素数据源。我们能够在线下、详尽的计算机视觉驱动流水线中合并来自这些源(FLAR和照片像素)的数据，从而完整地描述(直到给定的时间点)留在神奇视图中的所有数据和聚合。

合并器和清除器

通过选择FLAR中的时间戳并与照片像素结合，我们可以选择时刻计算还是持续较短时间段计算神奇视图的数据。该时间段可以被用来生成回填任务较小数据集合；通过调整该时间段(例如，每天运行)，我们可以执行快速运行加载，对照片出现在神奇视图中所需的时间设置合理的上限，以免实时处理丢失该照片。当从HBase读取单个行时，我们需要合并来自实时列和批量列的数据。如果仅存在批量数据或实时数据，则选择该数据是显而易见的。如果同时存在批量数据和实时数据，则我们始终选择实时数据。这看似合理，但是引起了细微的问题。

假设照片计算机视觉标签经由实时计算被添加，即，不存在批量数据。稍后，我们使用计算机视觉标签的新版本重新计算所有可用的照片，并且经由批量加载来加载该数据(包括该照片)。即使在批量列中存在较新的数据，我们也无法得到该数据，因为合并器将只读取实时列。在进行批量加载后，我们通过对HBase中的所有数据运行清除器过程来解决该问题。

清除器仅访问每一行并查看针对实时数据的HBase时间戳是否比批量加载的时间更早。如果是，则我们删除该行的实时数据，因为该数据已经在批量列中被获取。以这种方式，批量计算的结果不会被“公布”直到清除器已运行。

结果

生产吞吐量

在规模上，我们的架构已经能够充裕地跟上生产负载。

为了通过批量计算初始化系统，我们能够经由映射化简，在25小时内针对120亿张照片(翻译为230亿个自动标签行)的自动标签信息运行节流式加载(11个映射)。我们可以同时对HBase运行回填，并在不影响缓存SLA内的延迟的情况下同时服务用户信息。

我们的驱动神奇视图的HBase实例被配置有跨23个区域服务器和1200区域的3个表格。在读取侧，我们的DAO充裕地促进每秒2150次HBase读取(包括Storm读取)和每秒400000次写入。我们的合并器(Warmr)驱动大部分的写入；Warmr本身驱动每秒1250次读取，用于将用户数据加载至服务缓存。

针对系统是如何工作的最重要的测量方式是用户是怎样认知的。该系统最慢的部分是将来自HBase的数据寻呼(paging)至服务缓存；如图7中所示，用户认知到“已完成”的中值时间是大约10ms。针对第99个百分位，该时间会突然达到半秒或甚至是一秒；这主要是由具有少见的超大集合的照片(数以万计)的“超级(whale)”用户造成的。

在本公开中，我们提出了用于融合批量计算和实时计算的、新型简化的Lambda架构。通过采用实时表格和批量表格并在Hbase中水平地将二者合并，我们能够显著地简化和巩固查询架构，减少移动块的数量并使故障点的数量最小化。此外，我们能够在实践中并且成规模地演示该系统，其中我们能够在产品预期内很好地实现对数据的查询。

上述描述的本教导可以根据各个实施例来实现。首先，虽然以上公开描述了从属于分辨率的三种类型的示例性值，但是其他值(例如，描述图像的对象或区域的特征值)也可以从属于所公开的发明方案。例如，在关联的图像中标识的颜色二进制对象(blob)可以具有实时值和批量值。类似地，每个这样的颜色二进制对象的纹理特征也可以描述图像并且具有实时值和批量值。这样的实时特征值和批量特征值可以被存储在与对应的实时列和批量列的每一行中相同的配置中。取决于这些值的性质，用来合并的算法可以不同。

合并器可以基于根据不同的空中条件可被动态选择的方案来合并或调解与属性相关联的实时值和批量值。下文中，描述了用于基于实时数据和批量数据来确定属性的最终值或经决定值的一般方案。问题本身可以被形式化为以下公式：

经决定值＝f(S_R，S_B)；

其中，S_R表示来自实时数据的值的集合；S_B表示来自批量数据的值的集合；以及f()表示具有参数S_R和S_B的函数。通过该公式，属性K的经决定值可以基于属性K的实时值或S_R^K以及属性K的批量值或S_B^K来实现。计算属性K的经决定值的不同的实施例在下文被形式化。

在一个实施例中，系统可以使用以下方案来确定每个属性的最终值或经决定值：在存在实时数据的数据而不存在批量数据的数据(或反之亦然)的情况中，系统选择一个可用的值作为经决定值；在存在实时数据和批量数据二者的情况中，系统选择实时数据作为经决定值。该方案可以通过以下的一般公式来描述：

可以理解的是根据另一实施例，当存在实时值和批量值二者时，该系统可以选择实时值或批量值作为经决定值。在这种情况下对经决定值的选择可以被预定(例如，仅选择实时值)或根据其他条件(例如，将要决定的属性的具体类型)。例如，针对与精确度相关联的属性，该系统在实时值和批量值二者都存在但数值上不一致时可以选择胜过实时值的批量值。

在不同的实施例中，当实时值和批量值二者是数值时，该系统还可以基于使用实时值和批量值二者的计算来确定经决定值。例如，实时值和批量值的加权和可以被用来计算经决定值。该方法可以通过以下公式来描述：

属性K的经决定值＝f(S_R^K，S_B^K)＝aS_R^K+bS_B^K

可以理解的是，系数a和b的选择可以基于应用需求、特征的性质或基于机器学习。

根据另一实施例，被用来确定属性的经决定值的值可以不是在其自身的实时版本和批量版本中的相应值。例如，当不存在S_R^K和S_B^K时，该系统可以分配S_R^J或S_B^J作为经决定值，其中S_R^J是S_R^K的近似版本，S_B^J是S_B^K的近似版本。例如，属性K表示照片中某一区域的颜色，同时属性J表示该照片相同区域的灰度等级。因此，S_R^J/S_B^J可以是S_R^K/S_B^K的粗略版本。

在其他实施例中，照片或其中区域的特征可以是分等级的。例如，照片中的二进制对象可以具有多个特征，包括纹理、色调、颜色、亮度等。在该情况中，该二进制对象(可以被表示为边界)是等级比与二进制对象相关联的特征更高的特征。当存在这种体制时，在某个情况中，较高等级的特征值可以用于计算较低等级特征的经决定值。形式上，这可以被描述为如下：

或

其中表示在特征等级中，特征J比特征K的等级高。以上公式提供了当较高等级的特征值将要用于确定较低等级特征的经决定值时，关于是如何决定的不同可能性。可以理解的是，根据一些实施例，系统可以具有确定使用S_R^J和S_B^J还是将两个值合并为经决定值的函数的算法。

在另一实施例中，与多个特征相对应的实时值和批量值可以被用来计算特定特征的经决定值。例如，可以基于多个特征的实时值和批量值来计算特征A的经决定值，该多个特征中可以包括特征A或者可以不包括特征A。

在一些实施例中，该系统还可以基于时间序列数据计算经决定值。例如，该系统可以存储之前在不同的时间实例处导出的值，例如，S_R^K(t-1)、S_R^K(t-2)、…S_R^K(t-M)。在时间t处，为了计算经决定值，该系统可以选择使用时间t处的S_R^K(如果它存在)或者依赖于时间序列S_R^K(t-1)、S_R^K(t-2)、…S_R^K(t-M)来导出经决定值。在该情境中，该系统可以基于时间序列数据预测S_R^K(t)(或S_B^K(t))：

S_B^K(t)＝g[S_B^K(t-1)，…S_B^K(t-N)]；

S_R^K(t)＝h[S_R^K(t-1)，…S_R^K(t-M)]；

假设该系统存储M个之前实例处的S_R^K以及N个之前实例处的S_B^K。这里的h和g表示基于时间序列数据预测当前值的两个函数。例如，预测函数可以是基于线性外插函数的。在以上的公式中，基于单个时间序列来执行基于时间序列的预测。

在一些实施例中，当预测经决定值时，可以基于时间上与实时值和批量值二者相对应的时间序列数据来执行预测。在该情况中，该系统可以基于在时间上相等的S_R^K(t)和S_B^K(t)二者来预测经决定值，其中S_R^K(t)是基于实时值的时间序列来预测的，S_B^K(t)基于批量值的时间序列来预测的。S_R^K(t)和S_B^K(t)相等，这表示两种预测是经由外插法相交的。

合并实时数据和批量数据以导出经决定值的其他实现方式也是可能的，并且都在本教导的范围内。

图8描绘了可以用来实现实施本教导的专用系统的移动设备架构。在该示例中，在其上查询被发送至系统的用户设备是移动设备800，包括但不限于智能手机、平板计算机、音乐播放器、手持游戏机、全球定位系统(GPS)接收器、和可穿戴计算设备(例如，眼镜、手表等)或是采用任何其它形式的代理。该示例中的移动设备800包括一个或多个中央处理单元(CPU)840、一个或多个图形处理单元(GPU)830、显示器820、存储器860、通信平台810(例如，无线通信模块)、存储装置890以及一个或多个输入/输出(I/O)设备850。任意其他合适的组件(例如但不限于系统总线或控制器(未示出))也可以被包括在移动设备800中。如图8所示，可以将移动操作系统870(例如，IOS、安卓(Android)、微软视窗手机操作系统(Windows Phone))等，并且一个或多个应用880可以从存储装置890加载到存储器860中从而由CPU 840来运行。应用880可以包括浏览器或用于在移动设备800上接收查询结果的任意其他合适的移动应用。与查询结果或其他内容项的交互可以经由I/O设备850实现并且被提供至系统。

为实现本公开中描述的各种模块、单元、和它们的功能，计算机硬件平台可以被用作本文所描述的一个或多个元件的(一个或多个)硬件平台。这样的计算机的硬件元件、操作系统和编程语言实际上是常规的，并且假设本领域技术人员对于其十分熟悉，以改编这些技术来实现如本文描述的合并数据。具有用户接口元件的计算机可以被用来实现个人计算机(PC)或其他类型的工作站或终端设备，但计算机如果被适当程控则还可以作为服务器。相信本领域技术人员对于这样的计算机设备的结构、设计以及一般操作十分熟悉，因此附图应当是不言自明的。

图9描绘了可以用来实现实施本教导的专用系统的计算设备架构。这种结合本教导的专用系统具有示出了包括用户接口元件的硬件平台的功能框图。该计算机可以是通用计算机或专用计算机。二者都可被用来实施本教导的专用系统。该计算机900可以被用来实施本文所描述的合并数据技术的任何组件。例如，系统(如图4和图5中所示)可以经由其硬件、软件程序、固件或它们的组合在计算机(例如，计算机900)上实现。尽管出于方便只示出了一个这样的计算机，但与在此所描述的数据合并有关的计算机功能可以以分布式方式被实施在多个类似的平台上，以便分布处理负荷。

例如，计算机900包括COM端口950，这些COM端口950被连接至去往和来自与其连接以促进数据通信的网络。计算机900还包括以一个或多个处理器的形式的中央处理单元(CPU)920，以用来运行程序指令。示例性计算机平台包括内部通信总线910、不同形式的程序存储装置和数据存储装置(例如，磁盘2970、只读存储器(ROM)930、或随机存取存储器(RAM)940)，以用于各种数据文件由计算机处理和/或传输，以及可能地由CPU运行的程序指令。计算机900还包括I/O部件960，支持计算机和其中的其他部件(例如，用户接口元件980)之间的输入/输出流。计算机900还可以经由网络通信来接收程序和数据。

因此，如上面所概括的，数据合并的方法的各方面可以以编程的方式来实施。该技术的程序方面通常可以被看作是可执行代码和/或相关联的数据的形式的“产品”或“制品”，该可执行代码和/或相关联的数据被承载于或实施于一种类型的机器可读介质中。有形非暂态“存储”类型介质包括可以在任意时间为软件程序提供存储的计算机、处理器等的任意或所有存储器或其他存储设备或与其相关联的模块例如，各种半导体存储器、磁带驱动器、磁盘驱动器等。

所有或部分软件有时可以通过网络(例如，互联网或各种其他电信网络)进行通信。举例来说，这样的通信可以实现将软件从一个计算机或处理器加载到另一计算机或处理器中_，例如，从管理服务器或主机计算机加载到计算环境的(一个或多个)硬件平台或实现计算环境或与数据合并有关的类似功能的其他系统。因此，可以承载软件元素的另一种类型的介质包括例如通过本地设备之间的物理接口、通过有线和光陆地网络以及通过各种空中链路来使用的光波、电波、电磁波。运载这样的波的物理元件(例如，有线链路或无线链路、光链路等)也可以被看作是承载软件的介质。如本文所使用的，除非限制为有形的“存储”介质，否则诸如计算机或机器“可读介质”之类的术语指代参与向处理器提供指令以供运行的任意介质。

因此，机器可读介质可以采取许多形式，包括但不限于有形存储介质、载波介质或物理传输介质。举例来说，非易失性存储介质包括可以被用来实现附图中所示的系统或其任意部件的光盘或磁盘(例如，任意(一个或多个)计算机中的任意存储设备等)。易失性存储介质包括动态存储器(例如，这样的计算机平台的主存储器)。有形传输介质包括同轴电缆、铜线和光纤(包括形成计算机系统内的总线的线)。载波传输介质可以采取电信号或电磁信号、或者声波或光波(例如，在射频(RF)和红外(IR)数据通信期间生成的那些)的形式。因此，计算机可读介质的常见形式包括例如：软盘、柔性盘、硬盘、磁带、任意其他磁介质、CD-ROM、DVD或DVD-ROM、任意其他光介质、穿孔卡片纸带、具有孔图案的任意其他物理存储介质、RAM、PROM和EPROM、FLASH-EPROM、任意其他存储器芯片或卡盘、传输数据或指令的载波、传输这样的载波的电缆或链路、或计算机可以从其读取程序代码和/或数据的任意其他介质。这些形式的计算机可读介质中的许多介质可以在将一个或多个指令的一个或多个序列运载到处理器以供运行时被涉及。

本领域技术人员将认识到，本教导可服从于各种修改和/或改进。例如，尽管上面所描述的各个组件的实现方式可以被实施于硬件设备中，但其也可以被实现为仅为软件的方案(例如，现有服务器上的安装程序)。此外，本文所公开的主机和客户端节点的单元可以被实现为固件、固件/软件组合、固件/硬件组合或硬件/固件/软件组合。

尽管前面已经对被认为构成本教导和/或其他示例的部分进行了描述，但应当理解可以对其做出各种修改，本文所公开的主题可以以各种形式和示例来实现，并且这些教导可以被应用在大量的应用中，而本文只公开了其中的一些应用。所附权利要求旨在保护落入本教导的真实范围内的任何和全部应用、修改和变化。

本教导涉及用于数据处理的方法、系统、和程序。特别地，本教导针对用于调解或合并实时数据与批量数据的方法、系统、和程序。在一个示例中，公开了在具有处理器、存储装置、和能够连接到网络的通信平台的机器上实现的、用于合并数据的方法。第一属性值被获得。第一属性值表示数据项的方面。与第一属性有关的第二属性值被获得。第二属性值表示数据项的方面。选择将用来确定表示数据项的第三属性值的方案。第三属性值根据所选的方案以及第一和第二属性值被确定。