CN114187061A - 用于数据处理的动态调度的系统和方法 - Google Patents

Abstract

用于数据处理的动态调度的系统和方法。公开了用于动态调度数据处理的方法和系统。一种示例方法包括：标识要构建的数据模型，该数据模型与定义要在构建该数据模型中使用的输入数据的数据模型定义相关联；确定输入数据的尺寸；获得用于数据模型的预期访问时间；基于输入数据的尺寸和数据模型的定义来估计对于构建数据模型所需的总时间；基于用于数据模型的预期访问时间和构建数据模型所需的估计总时间来确定开始构建数据模型的时间；和调度数据模型的构建以在确定的时间开始。

Description

用于数据处理的动态调度的系统和方法

技术领域

本公开涉及调度数据处理作业。更具体地，本公开涉及使用历史数据来动态调度数据处理作业。

背景技术

对于需要在周期性基础上（例如，每天）处理原始数据的任何系统，系统通常调度处理以在例如每天2 AM的静态时间开始，该静态时间可以由用户预定义或根据系统设置进行设置。静态时间通常在当预期计算资源具有更大可用性时以及当预期尚不需要数据模型时的时段期间。

在一些情况下，数据处理的调度可能是全局的，这可能包括多个数据模型构建过程或作业。当存在多个数据模型构建作业要处理时，处理可以是批量调度，而不是在每个作业基础上进行调度。

发明内容

本公开描述了用于基于所需数据模型的预期访问时间和构建数据模型的估计时间来动态设置用于构建数据模型的开始时间的各种示例。预期访问时间可以基于用户输入或系统设置进行预定义。用于构建数据模型的估计时间可以基于历史数据生成。在一些情况下，预期访问时间也可以基于历史数据进行估计。

本文描述的示例可以在电子商务平台的环境中实现，或者可以使本文描述的示例对于电子商务平台的外部使用可用。

在一些示例中，本公开描述了用于动态调度数据处理的方法和系统。一种示例方法包括：标识要构建的数据模型，该数据模型与定义要在构建该数据模型中使用的输入数据的数据模型定义相关联；确定输入数据的尺寸；获得数据模型的预期访问时间；基于输入数据的尺寸和数据模型的定义来估计对于构建数据模型所需的总时间；基于用于数据模型的预期访问时间和构建数据模型所需的估计总时间来确定开始构建数据模型的时间；以及调度数据模型的构建以在确定的时间开始。

提出的解决方案的益处在于，它旨在尽可能晚地调度数据处理，以便在数据处理中捕获最新的原始数据。开始时间可以被认为是用于构建数据模型的“动态”开始时间（与常规的静态开始时间相反）。

在一些示例中，本公开描述了一种系统，该系统包括与存储装置通信的处理设备。所述处理设备可以被配置为执行指令以使得所述系统：标识要构建的数据模型，该数据模型与定义要在构建该数据模型中使用的输入数据的数据模型定义相关联；确定输入数据的尺寸；获得数据模型的预期访问时间；基于输入数据的尺寸和数据模型的定义来估计对于构建数据模型所需的总时间；基于用于数据模型的预期访问时间和构建数据模型所需的估计总时间来确定开始构建数据模型的时间；以及调度数据模型的构建以在确定的时间开始。

在一些示例中，本公开描述了其上存储有计算机可执行指令的计算机可读介质。所述指令当由系统的处理设备执行时，使得系统：标识要构建的数据模型，该数据模型与定义要在构建该数据模型中使用的输入数据的数据模型定义相关联；确定输入数据的尺寸；获得数据模型的预期访问时间；基于输入数据的尺寸和数据模型的定义来估计对于构建数据模型所需的总时间；基于用于数据模型的预期访问时间和构建数据模型所需的估计总时间来确定开始构建数据模型的时间；以及调度数据模型的构建以在确定的时间开始。

在以上示例中的任一个中，该方法可以包括，或者该处理设备可以进一步被配置为执行指令以使得该系统执行：在开始构建数据模型的确定的时间之前，确定输入数据的尺寸已经增加；基于输入数据的增加的尺寸和数据模型的定义，估计对于构建数据模型所需的修订的总时间，修订的总时间大于对于构建数据模型的先前估计的总时间；基于用于数据模型的预期访问时间和构建数据模型所需的修订的总时间，确定开始构建数据模型的更新时间，更新时间早于开始构建数据模型的先前确定的时间；以及重新调度数据模型的构建以在较早的更新时间开始。

在以上示例中的任一个中，该方法可以包括，或者该处理设备可以进一步被配置为执行指令以使得该系统执行：在开始构建数据模型的确定的时间之前，确定输入数据的尺寸已经减小；基于输入数据的减小的尺寸和数据模型的定义，估计对于构建数据模型所需的修订的总时间，修订的总时间小于对于构建数据模型的先前估计的总时间；基于用于数据模型的预期访问时间和对于构建数据模型所需的修订的总时间，确定开始构建数据模型的更新时间，更新时间晚于开始构建数据模型的先前确定的时间；以及重新调度数据模型的构建以在较晚的更新时间开始。

在以上示例中的任一个中，该方法可以包括，或者该处理设备可以进一步被配置为执行指令以使得该系统执行：在开始构建数据模型的确定的时间之前，获得用于数据模型的更新的预期访问时间；基于用于数据模型的更新的预期访问时间和对于构建数据模型所需的估计总时间，确定开始构建数据模型的更新时间；以及重新调度数据模型的构建以在更新的时间开始。

在以上示例中的任一个中，输入数据的尺寸可以基于用于数据模型的预期访问时间来确定。

在以上示例中的任一个中，预期访问时间可以在数据模型定义中预定义。

在以上示例中的任一个中，可以基于历史记录来确定预期访问时间。

在以上示例中的任一个中，可以基于历史记录来估计对于构建数据模型所需的总时间，所述历史记录包括：表示构建数据模型所花费的历史时间的数据、表示构建在结构上可能与数据模型相似的不同数据模型所花费的历史时间的数据，或当构建数据模型时的服务器容量。

在以上示例中的任一个中，数据模型的构建可以依赖于第二数据模型，并且估计对于构建数据模型所需的总时间可以包括估计构建第二数据模型所需的总时间。

在以上示例中的任一个中，确定输入数据的尺寸可以包括：确定输入数据的当前尺寸；以及估计在当前时间和未来时间之间要生成的输入数据的预期尺寸，其中输入数据的尺寸可以基于输入数据的当前尺寸和要生成的输入数据的估计尺寸之和来确定。

在以上示例中的任一个中，可以基于先前每单位时间生成的输入数据的平均尺寸来确定要生成的输入数据的预期尺寸。

在以上示例中的任一个中，该方法可以包括，或者该处理设备可以进一步被配置为执行指令以使得该系统执行：确定可用于构建数据模型的计算资源的量，其中对于构建数据模型所需的总时间的估计可以进一步基于可用于构建数据模型的计算资源的量。

在以上示例中的任一个中，确定可用计算资源的量可以包括基于历史记录估计在多个未来时间的每一个处可用的计算资源的相应量。

在以上示例中的任一个中，该方法可以包括，或者该处理设备可以进一步被配置为执行指令以使得该系统执行：基于历史记录，估计在多个未来时间的每一个处开始构建数据模型所需的相应总时间；以及基于在多个未来时间的每一个处开始构建数据模型所需的估计的相应总时间来确定开始构建数据模型的时间。

因此，提供了一种如以下权利要求中详述的方法。还提供了一种系统。

附图说明

现在将通过示例的方式对示出本申请的示例实施例的附图进行参考，并且其中：

图1是示例电子商务平台的框图，其中可以实现本文描述的示例；

图2是可以经由图1的电子商务平台访问的管理器的示例主页；

图3是示出与应用开发相关的一些细节的图1电子商务平台的另一个框图；

图4示出了当使用图1的电子商务平台进行购买时可能发生的示例数据流；

图5是图示图1的电子商务平台的示例实现的框图；

图6是示出与数据处理引擎相关的一些细节的图1电子商务平台的另一个框图；和

图7是图示用于动态调度数据模型构建作业的示例过程的流程图。

在不同的图中可能已经使用了相似的参考标号来标示相似的组件。

示例实施例的描述

将在电子商务平台的环境中描述本公开，如下讨论。然而，应当理解的是，该讨论仅仅是为了说明的目的，并且不旨在进行限制。此外，应当理解，本公开可以在其他环境中实现，并且不一定限于在电子商务平台中的实现。

参考图1，描绘了用于向顾客提供商家产品和服务的实施例电子商务平台100。虽然本公开始终考虑使用所公开的装置、系统和过程来购买产品和服务，但是为了简单起见，本文中的描述将适用于产品或供应。贯穿本公开的对产品或供应的所有引用也应当被理解为是对产品和/或服务的引用，包括实体产品、数字内容、票、订阅、待提供的服务等。

虽然本公开通篇考虑“商家”和“顾客”可以不止是个人，但是为了简单起见，本文中的描述一般可以照此指代商家和顾客。贯穿本公开对商家和顾客的所有引用也应当被理解为对个人、公司、企业、计算实体等的群组的引用，并且可以表示为了盈利或不为了盈利的产品交换。此外，虽然本公开通篇涉及“商家”和“顾客”，并且照此描述了它们的角色，但是应当理解电子商务平台100的方面可以更一般地可用于支持电子商务环境中的用户，并且贯穿本公开对商家和顾客的所有引用也应当被理解为对用户的引用，诸如其中用户是商家-用户（例如，产品的销售者、零售商、批发商或提供商）、营销-用户（例如，营销代理、外部营销服务提供商或自我营销商家）、顾客-用户（例如，产品的买方、购买代理或用户）、预期用户（例如，浏览并且尚未承诺购买的用户、针对在营销和销售产品中的潜在使用来评估电子商务平台100的用户等等）、服务提供商用户（例如，装运提供商112、金融提供商等）、公司或企业用户（例如，代表购买、销售或使用产品的公司；企业用户；顾客关系或顾客管理代理等）、信息技术用户、计算实体用户（例如，用于产品的购买、销售或使用的计算机器人）等。此外，应当理解，在电子商务环境中，任何个体或个体群组可以扮演多于一个角色，并且可以配合多于一个标签。例如，商家可能是营销人员，或者公司用户也可能是顾客。

电子商务平台100可以提供用于向商家提供用于管理其业务的在线资源的集中式系统。商家可以诸如通过以下各项来利用电子商务平台100管理与顾客的商务：经由在线商店138、经由渠道110、经由物理位置（例如，实体店面或其他位置，诸如经由售货亭、终端、读取器、打印机、3D打印机等）中的销售终端（POS）设备152实现与顾客的电子商务体验，经由电子商务平台100管理其业务，经由电子商务平台100的通信设施129与顾客交互，或其任何组合。

在线商店138可以表示包括多个虚拟店面139的多租户设施。在各种实施例中，商家可以诸如经由商家设备102（例如，计算机、膝上型计算机、移动计算设备等）来管理在线商店138中的一个或多个店面139，并且经由多个不同的渠道110（例如，在线商店138；经由POS设备152的实体店面；电子市场；经由整合到诸如社交网络、社交媒体页面、社交媒体消息传送系统上的网站或社交媒体渠道中的电子购买按钮；等）来向顾客提供产品。商家可以跨渠道110销售，并且然后通过电子商务平台100管理其销售。商家可以在其实体零售店中、在弹出窗口处、通过批发、通过电话等进行销售，并且然后通过电子商务平台100管理其销售。例如，商家可以采用这些的全部或任何组合，诸如通过利用POS设备152的实体店面来维护业务、通过在线商店138来维护虚拟店面139、以及利用通信设施129来利用顾客交互和分析132以改进销售的概率。

在各种实施例中，顾客可以通过如下各项进行交互：顾客设备150（例如，计算机、膝上型计算机、移动计算设备等）、POS设备152（例如，零售设备、售货亭、自动结账系统等）或本领域已知的任何其他商务接口设备。电子商务平台100可以使商家能够通过在线商店138、通过物理位置（例如，商家的店面或其他地方）中的POS设备152联系上顾客，以通过经由电子通信的对话等来促进与顾客的商务，从而提供用于联系上顾客并且针对可用于联系上消费者并与消费者交互的现实或虚拟路径而便于商家服务的系统。

在各种实施例中，并且如本文进一步描述的，电子商务平台100可以通过包括处理设备和存储器的处理设施来实现，处理设施存储指令集，该指令集当被执行时使得电子商务平台100执行如本文描述的电子商务和支持功能。处理设施可以是服务器、客户端、网络基础设施、移动计算平台、云计算平台、固定计算平台或其他计算平台的部分，并且提供在电子商务平台100、商家设备102、支付网关106、应用开发108、渠道110、运输提供商112、消费者设备150、POS设备152等等的电子组件之间以及它们的电子组件当中的电子连接性和通信。电子商务平台100可以诸如在软件和交付模型中被实现为云计算服务、软件即服务（SaaS）、基础设施即服务（IaaS）、平台即服务（PaaS）、桌面即服务（DaaS）、管理软件即服务（MSaaS）、移动后端即服务（MBaaS）、信息技术管理即服务（ITMaaS）等，诸如在软件和交付模型中，软件在订阅的基础上被许可并且被集中托管（例如，由用户使用瘦客户端经由web浏览器访问、通过由POS设备访问等）。在各种实施例中，电子商务平台100的元素可以被实现为在各种平台和操作系统上操作，该各种平台和操作系统诸如是iOS、安卓、通过互联网等。

在各种实施例中，店面139可以由电子商务平台100向顾客提供服务（例如，经由顾客设备150），其中，顾客可以浏览和购买各种可获得的产品（例如，将它们添加到购物车、通过购买按钮立即购买等）。店面139可以以透明的方式提供给顾客，而顾客不必意识到它是通过电子商务平台100提供的（而不是直接从商家提供的）。商家可以使用商家可配置域名、可定制HTML主题等来定制其店面139。商家可以通过主题系统定制他们网站的外观和感觉，诸如其中商家可以通过改变他们的主题同时具有在店面的产品层次内示出的相同的基础产品和商务数据来选择和改变他们的店面139的外观和感觉。主题可以通过主题编辑器进一步定制，该主题编辑器是使得用户能够在具有灵活性的情况下定制其网站的设计的设计界面。主题还可以使用改变诸如特定颜色、字体和预先构建的布局方案之类的方面的主题特定设置来定制。在线商店可以实现用于网站内容的基本内容管理系统。商家可以创作博客帖子或静态页面，并诸如通过博客、文章等将它们发布到其店面139和/或网站104，以及配置导航菜单。商家可以将图像（例如，用于产品的图像）、视频、内容、数据等上传到电子商务平台100，诸如供系统存储。在各种实施例中，电子商务平台100可以提供用于对图像重新定尺寸、将图像与产品相关联、添加文本并将文本与图像相关联、添加用于新产品变体的图像、保护图像等的功能。

如本文所描述的，电子商务平台100可以通过包括在线商店138的多个不同的渠道110、通过电话以及通过物理POS设备152（如本文描述）来向商家提供用于产品的交易设施。电子商务平台100可以提供与运行在线业务相关联的业务支持服务116、管理器组件114等，从而诸如提供与其在线商店相关联的域服务118、用于促进与顾客的交易的支付服务120、用于提供所购买产品的顾客装运选项的装运服务122、与产品保护和责任相关联的风险和保险服务124、给商家开账单服务146等。服务116可以经由电子商务平台100或与外部设施相关联地提供，诸如通过用于支付处理的支付网关106、用于加速产品装运的装运提供商112等来提供。

在各种实施例中，电子商务平台100可以提供整合的装运服务122（例如，通过电子商务平台装运设施或通过第三方装运承运商），从而诸如向商家提供实时更新、跟踪、自动费率计算、大宗订单准备、标签打印等。

图2描绘了用于管理器114的主页170的非限制性实施例，其可以示出关于日常任务、商店的新近活动、以及商家为构建其业务可以采取的接下来步骤的信息。在各种实施例中，商家可以诸如从浏览器或移动设备登录到管理器114，并且管理其店面的各方面，从而诸如查看店面的新近活动、更新店面的目录、管理订单、新近访问活动、总订单活动等。在各种实施例中，商家可以能够通过使用边注栏（sidebar）172来访问管理器114的不同区段，诸如在图2上所示的。管理器的区段可以包括商家的业务的核心方面，包括订单、产品和顾客；销售渠道，包括在线商店、POS和购买按钮；安装在商家账户上的应用程序；应用于商家的店面139和账户的设置。商家可以使用搜索栏174来查找产品、页面或其他信息。取决于商家正在使用的设备，可以通过管理器114使得它们能够用于不同的功能。例如，如果商家从浏览器登录到管理器114，则他们可以能够管理他们的店面139的所有方面。如果商家从其移动设备登录，则他们可以能够查看其店面139的所有方面或其子集，诸如查看店面的新近活动、更新店面的目录、管理订单等。

可以通过获取报告或度量来查看关于商家的店面139的商务和访问者的更详细的信息，该报告或度量诸如显示商家的总体业务的销售概要、有效销售渠道的具体销售和参与数据等。报告可以包括获取报告、行为报告、顾客报告、财务报告、营销报告、销售报告、定制报告等。商家可以能够诸如通过使用下拉菜单176查看来自不同时间段（例如，天、周、月等）的不同渠道110的销售数据。可以为想要更详细地查看商店的销售和参与数据的商家提供概况仪表板。可以提供主页度量区段中的活动提要以说明商家账户上的活动的概况。例如，通过点击“查看所有新近活动”仪表板按钮，商家可以能够看到其账户上新近活动的较长提要。主页可以诸如基于账户状态、增长、新近顾客活动等示出关于商家的店面139的通知。可以提供通知以辅助商家导航通过诸如捕获支付、将订单标记为已履行、将完成的订单存档等之类的过程。

参考回到图1。电子商务平台可以提供通信设施129和相关联的商家接口，其用于提供电子通信和营销，诸如利用电子消息传送聚合设施（未示出）来收集和分析商家、顾客、商家设备102、顾客设备150、POS设备152等之间的通信交互，以聚合和分析通信，诸如用于增加提供产品销售的潜力等。例如，顾客可能具有与产品相关的问题，该问题可以在顾客和商家（或表示商家的基于自动化处理器的代理）之间产生对话，其中，通信设施129对该交互进行分析，并且向商家提供关于如何改进销售的概率的分析。

电子商务平台100可以提供金融设施130，其用于诸如通过安全卡服务器环境148来与顾客进行安全金融交易。电子商务平台100可以将信用卡信息存储在诸如支付卡行业数据（PCI）环境（例如，卡服务器）中，以便核对财务、向商家开账单、在电子商务平台100金融机构账户和商家的后台账之间执行自动化票据交换所（ACH）转账（例如，当使用资金时）等。这些系统可以具有Sarbanes-Oxley Act（SOX）合规以及在它们的开发和操作中所需的高水平的勤勉。金融设施130还可以诸如通过资金的借贷（例如，借贷资金、现金预付等）和保险的提供来向商家提供金融支持。另外，电子商务平台100可以营销和合作方服务的集合，并且控制电子商务平台100和合作方之间的关系。它们还可以将新的商家与电子商务平台100连接并搭载（onboard）起来。这些服务可以通过使商家更容易地跨电子商务平台100工作来实现商家增长。通过这些服务，可以经由电子商务平台100向商家提供帮助设施。

在各种实施例中，在线商店138可以支持大量独立管理的店面139，并且每天针对各种产品处理大体量交易数据。交易数据可以包括顾客联系信息、账单信息、装运信息、关于所购买的产品的信息、关于所呈递的服务的信息、以及与通过电子商务平台100的业务相关联的任何其他信息。在各种实施例中，电子商务平台100可以将该数据存储在数据设施134中。交易数据可以被处理以产生分析132，该分析132进而可以被提供给商家或第三方商务实体，从而诸如提供顾客趋势、营销和销售洞察力、用于改进销售的推荐、对顾客行为的评估、营销和销售建模、欺诈趋势等，其与在线商务有关，并且通过仪表板接口、通过报告等来被提供。电子商务平台100可以存储关于业务和商家交易的信息，并且数据设施134可以具有增强、贡献、细化和提取数据的许多方式，其中随着时间的推移，所收集的数据可以使得能够实现对电子商务平台100的各方面的改进。

在各种实施例中，电子商务平台100可以被配置有用于内容管理和任务自动化的核心商务设施136，以使得能够实现对多个店面139（例如，与产品、库存、顾客、订单、合作、供应商、报告、财务、风险和欺诈等相关）进行支持和服务，但是可通过应用142扩展，这些应用142使得能够实现适应日益增长的各种商家店面139、POS设备152、产品和服务所需的更大灵活性和定制过程。例如，核心商务设施136可以通过诸如顾客标识符、订单标识符、店面标识符等经由划分（例如，分片）功能和数据来为了灵活性和可扩展性进行配置。核心商务设施136可以容纳商店特定的业务逻辑和网络管理器。在线商店138可以表示被嵌入在核心商务设施136内的渠道，提供支持商家使用的支持和调试工具集合，等等。核心商务设施136可以为店面139提供关键数据的集中式管理。

核心商务设施136包括电子商务平台100的基本或“核心”功能，并且照此，如本文所述，并非支持店面139的所有功能都可以适于包括在内。例如，用于包括在核心商务设施136中的功能可能需要超过核心功能阈值，通过该核心功能阈值可以确定的是：功能是商务体验的核心（例如，对于大多数店面活动是共同的，诸如跨渠道、管理器接口、商家位置、行业、产品类型等）是跨店面可重复使用的（例如，可以跨核心功能重复使用/修改的功能），限于一次单个店面的上下文（例如，实现店面“隔离原则”，其中，代码不应当能够一次与多个店面交互，从而确保店面不能访问彼此的数据），提供交易工作负载等。维持对实现什么功能的控制可以使得核心商务设施136能够保持响应，因为许多所需特征要么由核心商务设施136直接提供，要么由其到应用142的扩展/应用编程接口（API）140连接来使能实现。如果没有对限制核心商务设施136中的功能给予关注，则响应性可能诸如通过以下各项而受到损害：经由慢速数据库或非关键后端故障所致的基础设施降级、诸如在数据中心离线情况下的灾难性的基础设施故障、花费比预期更久来执行的部署的新代码等。为了防止或减轻这些情形，核心商务设施136可以被配置为诸如通过利用超时、排队、反向压力来防止降级等的配置来维持响应性。

尽管隔离店面数据对于维护店面139与商家之间的数据隐私是重要的，但诸如例如对于订单风险评估系统或平台支付设施的情况下可能存在收集和使用跨商店数据的原因，这两者都需要来自大多数店面139的信息才得以良好地执行。在各种实施例中，不是违反隔离原则，而可以优选的是将这些组件移出核心商务设施136并移入电子商务平台100内其自己的基础设施中。例如，数据设施134和分析132可以位于核心商务设施136外部。

在各种实施例中，电子商务平台100可以提供平台支付设施149，其是利用来自核心商务设施138的数据但是可以位于外部以便不违反隔离原则的组件的另一示例。平台支付设施149可以允许与店面139交互的顾客使其支付信息由核心商务设施136安全地存储，使得他们仅必须输入支付信息一次。当顾客访问不同的店面139时，即使他们以前从未去过那里，平台支付设施149也可以调用他们的信息以使能实现更快速和正确的结帐。这可以提供跨平台网络效果，其中电子商务平台100随着更多商家加入而变得对其商家更有用，诸如因为存在更多顾客，这些顾客由于相对于顾客购买的使用容易而更频繁地结账。为了最大化该网络的效果，给定顾客的支付信息可以从店面的结帐处可检索，从而允许信息跨店面139全局可用。对于每个店面139来说，能够连接到任何其他店面139以直接检索存储在那里的支付信息将是困难的并且容易出错。结果，平台支付设施149可以在核心商务设施136的外部实现。

对于未包括在核心商务设施138内的那些功能，应用142提供了向电子商务平台100添加特征的方式。应用142可以能够访问和修改关于商家的店面139的数据，通过管理器114执行任务，通过（例如，通过扩展/API 140被表面显示的）用户接口为商家创建新流量等等。可以使得商家能够通过应用搜索208和应用推荐210（参见图3）来发现和安装应用142。在各种实施例中，核心产品、核心扩展点、应用和管理器114可以被开发成一起工作。例如，应用扩展点可以构建在管理器114内部，使得核心特征可以借助于应用142而被扩展，该应用142可以通过扩展/API 140将功能交付给商家。

在各种实施例中，应用142可以通过扩展/API 140向商家交付功能，诸如在应用142能够向商家表面显示交易数据的情况下（例如，App：“使用嵌入式app SDK在移动和web管理器中表面显示我的app）、和/或在核心商务设施136能够要求应用按需求执行工作的情况下（核心：“App，给我用于该结帐的本地税务计算”）。

应用142可以支持店面139和渠道110，提供商家支持，与其他服务整合等。在核心商务设施136可以向店面139提供服务基础的情况下，应用142可以为商家提供用以满足特定的并且有时是唯一的需要的方式。不同的商家将具有不同的需要，并且因此可以受益于不同的应用142。应用142可以更好地通过电子商务平台100被发现，这是通过开发应用分类法（类别），所述应用分类（类别）使得应用能够根据它为商家执行的功能类型被标记；通过支持搜索、评级和推荐模型的应用数据服务；通过应用发现接口，诸如应用商店、主页信息卡、应用设置页面；等等。

应用142可以通过扩展/API层140连接到核心商务设施136，诸如利用API来向应用的功能展示通过核心商务设施136和在其内可用的功能和数据（例如，通过REST、GraphQL等）。例如，电子商务平台100可以向面向商家和面向合作方的产品和服务提供API接口，该面向商家和合作方的产品和服务诸如包括应用扩展、过程流服务、面向开发者的资源等。随着顾客更频繁地使用移动设备来购物，与移动使用相关的应用142可以受益于对API的更广泛的使用，以支持相关不断增长的商务业务量。通过使用应用和API（例如，如为应用开发所提供的）而提供的灵活性使得电子商务平台100能够更好地适应商家（以及通过内部API的内部开发者）的新的和唯一的需要，而不需要对核心商务设施136的持续改变，因而在商家需要他们所需要的东西时向他们提供它。例如，可以通过装运或承运商服务API将装运服务122与核心商务设施136整合，因而使得电子商务平台100能够提供装运服务功能，而不直接影响在核心商务设施136中运行的代码。

许多商家问题可以通过让合作方通过应用开发来改进和扩展商家工作流来解决，诸如与后台操作（面向商家的应用）相关联的、以及店面（面向顾客的应用）中的问题。作为进行业务的一部分，许多商家将每天使用移动和web相关的应用来进行后台任务（例如，推销、库存、折扣、履行等）和店面任务（例如，与其在线商店相关的应用，用于快闪销售、新产品供应等），其中，应用142通过扩展/API 140帮助使产品在快速增长的市场中易于查看和购买。在各种实施例中，合作方、应用开发者、内部应用设施等可以被提供有软件开发工具包（SDK），诸如通过在管理器114内创建将应用接口沙盒化的框架。在各种实施例中，管理器114可能不具有对框架内发生了什么的控制也意识不到框架内发生了什么。SDK可以与用户接口工具包结合使用，以产生模仿电子商务平台100的外观和感觉的接口，例如充当核心商务设施136的扩展。

利用API的应用142可以按需求拉取数据，但是它们通常还需要在发生更新时推送数据。更新事件可以按订阅模型来实现，诸如例如顾客创建、产品改变或订单取消。更新事件可以向商家提供关于核心商务设施136的改变状态的所需更新，诸如用于同步本地数据库、通知外部整合合作方等。诸如通过更新事件订阅，更新事件可以使得能够实现此功能，而不必一直轮询核心商务设施136来针对更新进行检查。在各种实施例中，当发生与更新事件订阅相关的改变时，核心商务设施136可以诸如针对预定义的回调URL发布请求。该请求的主体可以包含对象的新状态和动作或事件的描述。可以在管理器设施114中手动创建或者自动创建（例如，经由API）更新事件订阅。在各种实施例中，更新事件可以排队并且与触发它们的状态改变异步地处理，这可以产生未被实时分发的更新事件通知。

对图3进行参考，其是电子商务平台100的另一个描绘。图3省略了已经参考图1描述的一些细节，并且示出了下面讨论的另外细节。在各种实施例中，电子商务平台100可提供应用开发支持128。应用搜索开发支持128可以包括：用以帮助应用开发的开发者产品和工具202；应用仪表板204（例如，用以向开发者提供开发接口、向管理器提供应用的管理、向商家提供应用的定制等）；用于安装和提供关于提供对应用142的访问的许可206的设施（例如，对于公共访问而言，诸如在安装之前必须满足准则的情况下，或者用于商家的私人使用）；应用搜索208，用以使得商家易于搜索满足针对他们的店面139的需要的应用142；应用推荐210，用以向商家提供关于他们如何能够通过他们的店面139来改进用户体验的建议；对核心商务设施136内的核心应用能力214的描述；等等。这些支持设施可以由任何实体执行的应用开发108所利用，所述任何实体包括开发其自己的应用142的商家、开发应用142（例如，由商家签订合同、凭他们自己开发以提供给公众、签订合同以供与电子商务平台100相关联地使用等）的第三方开发者、或者由与电子商务平台100相关联的内部个人资源开发的应用。在各种实施例中，应用142可以被分配应用标识符（ID），诸如用于链接到应用（例如，通过API）、针对应用进行搜索、进行应用推荐等。

核心商务设施136可以包括电子商务平台100的基本功能，并且通过API将这些功能展示给应用142。API可以使能实现通过应用开发108构建的不同类型的应用。应用142可以能够满足商家的各种需要，但是可以粗略地分为三类：面向顾客的应用216、面向商家的应用218、整合应用220。面向顾客的应用216可以包括店面139或作为商家可以列出产品并让它们购买的地方的渠道110（例如，在线商店、用于快闪销售的应用（例如，商家产品或来自第三方源的机会性销售机会）、移动商店应用、社交媒体渠道、用于提供批发购买的应用等）。面向商家的应用218可以包括以下应用，这些应用允许商家管理其店面139（例如，通过与web或网站相关、或与移动设备相关的应用）、运行其业务（例如，通过与POS设备152相关的应用）、增长其业务（例如，通过与装运（例如，投递装运）相关的应用、使用自动化代理、使用过程流开发和改进）等。整合应用220可以包括提供参与业务运行的有用整合的应用，诸如装运提供商112和支付网关。

在各种实施例中，应用开发者可以使用应用代理来从外部位置获取数据并将其显示于在线店面139的页面上。这些代理页面上的内容可以是动态的、能够被更新等等。应用代理对于显示图像图库、统计、定制表单和其他种类的动态内容可以是有用的。电子商务平台100的核心应用结构可以允许在应用142中构建数量日益增长的商家体验，使得核心商务设施136可以保持关注于更普遍利用的商务业务逻辑。

电子商务平台100通过精编的系统架构来提供在线购物体验，该精编的架构使得商家能够以灵活且透明的方式与顾客连接。典型的顾客体验可以通过示例性示例购买工作流来更好地理解，其中，顾客在渠道110上浏览商家的产品，将他们意图购买的东西添加到他们的购物车中，继续进行结账，并为他们的购物车的内容付费，从而导致针对商家的订单创建。然后，商家可以查看并履行（或取消）订单。然后将产品交付给顾客。如果顾客不满意，则他们可以将产品退货给商家。

在示例实施例中，顾客可以在渠道110上浏览商家的产品。渠道110是其中顾客可以查看和购买产品的地方。在各种实施例中，渠道110可以被建模为应用142（可能的例外是在线商店138，其被整合在核心商务设施136内）。推销组件可以允许商家描述他们想要销售什么以及他们在哪里销售它。产品和渠道之间的关联可以被建模为产品发布并且诸如经由产品列表API而被渠道应用访问。产品可以具有许多选项，如尺寸和颜色，以及将可用选项扩展到所有选项的特定组合的许多变体，如超小且绿色的变体或尺寸大且蓝色的变体。产品可以具有至少一个变体（例如，为没有任何选项的产品创建“默认变体”）。为了便于浏览和管理，可以将产品分组到集合中、为产品提供产品标识符（例如，库存单位（SKU））等。产品集合可以通过以下各项来构建：将产品手动分类为一类（例如，定制集合）、构建用于自动分类的规则集（例如，智能集合）等。可以通过虚拟或增强现实界面等等，作为2D图像、3D图像、旋转视图图像来查看产品。

在各种实施例中，顾客可以将他们意图购买的东西添加到他们的购物车（在替代实施例中，可以诸如通过如本文所述的购买按钮直接购买产品）。顾客可以将产品变体添加到他们的购物车。购物车模型可以是渠道特定的。在线商店138购物车可以由多个购物车排列项（line item）组成，其中，每个购物车排列项跟踪产品变体的数量。商家可以使用购物车脚本来基于其购物车中的内容向顾客提供特别的促销。由于向购物车添加产品并不意味着来自顾客或商家的任何承诺，并且购物车的预期寿命可以是大约几分钟（而不是几天），因此购物车可以被持久保存到短暂的数据储存区中。

然后，顾客继续进行结账。结账组件可以将web结账实现为面向顾客的订单创建过程。结账API可被提供为由某些渠道应用使用的面向计算机的订单创建过程，以代表顾客创建订单（例如，针对销售点）。收款台可以针对购物车而创建，并且记录顾客的信息，例如电子邮件地址、账单和装运细节。在收款台，商家承诺定价。如果顾客输入其联系信息但不继续进行支付，则电子商务平台100可以提供重新接入（re-engage）顾客的机会（例如，以放弃结账特征）。由于这些原因，收款台可以具有比购物车长得多的寿命（数小时或者甚至数天），并且因此持续。收款台可以基于顾客的装运地址来计算税款和装运成本。收款台可以将税款计算委托给税款组件，并将装运成本计算委托给交付组件。定价组件可以使商家能够创建折扣代码（例如，当在收款台输入时将新价格应用于收款台中的项目的“秘密”字符串）。折扣可以由商家用来吸引顾客并评估营销活动的表现。折扣和其他定制价格系统可以在同一平台片段顶上诸如通过价格规则（例如，先决条件集，其当被满足时意味着权利集）来实现。例如，先决条件可以是诸如“订单小计大于$100”或“装运成本低于$10”的项目，并且权利可以是诸如“整个订单的20%折扣”或“产品X、Y和Z减$10”之类的项目。

然后，顾客为他们的购物车的内容付费，从而导致针对商家的订单创建。渠道110可以使用核心商务设施136来向顾客和商家转移金钱、货币或价值存储（例如美元或加密货币）。与各种支付提供商（例如，在线支付系统、移动支付系统、数字钱包、信用卡网关等）的通信可以在支付处理组件内实现。与支付网关106的实际交互可以通过卡服务器环境148来提供。在各种实施例中，支付网关106可以诸如通过与领先的国际信用卡处理器整合来接受国际支付。卡服务器环境148可以包括卡服务器应用、卡槽（sink）、托管字段等。该环境可以充当敏感信用卡信息的安全关守。

图4存在于非限制性的示例中，示出了在web结账上的信用卡、预付费卡、礼品卡或其他卡的支付处理期间，核心商务设施136和卡服务器环境148之间的交互的简化序列图解。

在各种实施例中，大多数过程可以由支付处理作业来编排。核心商务设施136可以支持许多其他支付方法，诸如通过非现场支付网关106（例如，在那里顾客被重定向到另一网站）、手动（例如，现金）、在线支付方法（例如，在线支付系统、移动支付系统、数字钱包、信用卡网关等）、礼品卡等。在结账过程结束时，创建订单。订单是商家和顾客之间的销售合同，其中，商家同意提供订单上列出的商品和服务（例如，订货排列项、发货排列项等），并且顾客同意提供支付（包括税款）。可以在销售组件中对该过程进行建模。不依赖于核心商务设施结帐的渠道110可以使用订单API来创建订单。一旦创建了订单，就可以将订单确认通知发送给顾客，并且经由通知组件将下订单通知发送给商家。当支付处理作业开始时可以预留库存以避免过度销售（例如，商家可以根据每个变体的库存策略来控制该行为）。库存预留可以具有短的时间跨度（分钟），并且可能需要非常快速和可缩放以支持快闪销售（例如，诸如以冲动购买为目标的短时间内提供的折扣或促销）。如果支付失败，则释放该预留。当支付成功并创建订单时，该预留被转换成分配给特定位置的长期库存承诺。库存组件可以记录变体库存的位置，并且跟踪启用了库存跟踪的变体的数量。它可以将产品变体（表示产品列表的模板的面向顾客的概念）与库存项目（表示其数量和位置被管理的项目的面向商家的概念）解耦。库存水平组件可以保持跟踪可用于销售、承诺给订单或从库存转移组件（例如，从供应商）传入的数量。然后，商家可以查看并履行（或取消）订单。

订单评估组件可以实现业务过程，商家使用该业务过程以确保订单在实际履行之前适合于履行。订单可能是欺诈性的，需要验证（例如，ID检查），具有需要商家等待以确保他们将收到他们的资金的支付方法等等。风险和建议可以被持久存储在订单风险模型中。订单风险可以从欺诈检测工具生成、由第三方通过订单风险API提交等。在继续进行履行之前，商家可能需要捕获支付信息（例如，信用卡信息）或等待接收它（例如，经由银行转帐、支票等）并将订单标记为已支付。商家现在可以准备用于交付的产品。在各种实施例中，该业务过程可以由履行组件来实现。履行组件可以基于库存位置和履行服务将订单的排列项分组到工作的逻辑履行单元中。商家可以评估订单、调整工作单元，并且触发相关的履行服务，购买装运标签和输入它的跟踪号，或仅仅把物品标记为已履行，该相关的履行服务诸如是通过当商家挑选产品并将其包装在盒子中时使用的人工履行服务（例如，在商家管理的位置处）。定制履行服务可以发送电子邮件（例如，不提供API连接的位置）。API履行服务可以触发第三方，其中，第三方应用创建了履行记录。遗留履行服务可以触发从核心商务设施136到第三方的定制API调用（例如，由Amazon的履行）。礼品卡履行服务可以提供（例如，生成号码）并激活礼品卡。商家可以使用订单打印机应用来打印包裹单。当项目被包装在盒子中并且准备好装运、被装运、跟踪、交付、验证为被顾客接收到时等，可以执行履行过程。

如果顾客不满意，则他们可以能够将（一个或多个）产品退货给商家。业务过程商家可以经历“取消销售”项目，其可以由退货组件实现。退货可以由各种不同的动作组成，该各种不同的行为诸如是：回货，其中，被售出的产品实际上回到业务中并且可再次销售；退款，其中，曾从顾客处收取的钱被部分或全部退回；记下退款多少钱的会计调整（例如，包括是否存在任何回货费用、或未退款并仍留在顾客手中的货物）；等等。退货可以表示对销售合同（例如，订单）的改变，并且其中，电子商务平台100可以使商家意识到关于法律义务（例如，关于税款）的合规问题。在各种实施例中，电子商务平台100可以使商家能够跟踪对销售合同随时间推移的改变，诸如通过销售模型组件（例如，记录项目所发生的与销售相关的事件的仅附加基于日期的分类账）来实现。

图5是电子商务平台100的示例硬件配置的框图。应当注意，电子商务平台100的不同组件（例如，数据设施134、分析设施132、核心商务设施136和应用142）可以在单独的硬件或软件组件中、在公共硬件组件或服务器上实现，或者被配置为电子商务平台100中的公共（集成）服务或引擎。在图5的示例中，电子商务平台100包括核心服务器510、数据服务器520和应用服务器530，它们各自与彼此通信（例如，经由有线连接和/或经由无线内联网连接）。服务器510、520、530中的每一个包括相应的处理设备512、522、532（其中每一个可以是例如微处理器、图形处理单元、数字信号处理器或其他计算元件）、相应的存储器514、524、534（其中每一个可以是例如随机存取存储器（RAM）、只读存储器（ROM）、硬盘、光盘、订户身份模块（SIM）卡、记忆棒、安全数字（SD）存储卡等，并且可以包括有形的或无形的存储器）和相应的通信接口516、526、536（其中每一个可以包括用于有线和/或无线通信的发射机、接收机和/或收发机）。核心服务器510可以存储指令并执行与电子商务平台的核心能力相关的操作，所述操作除了其他之外尤其诸如提供管理器114、分析132、核心商务设施136、服务116和/或金融设施130。数据服务器520可以除了其他之外尤其用于实现数据设施134。应用服务器530可以存储指令并执行与应用142相关的操作，所述操作诸如为应用142和实现应用开发支持128存储指令和数据。

使用相应设备102、150、152的商家和顾客可以经由一个或多个网络540（例如，有线和/或无线网络，包括虚拟专用网络（VPN）、因特网等）访问电子商务平台100。

尽管图5图示了电子商务平台100的示例硬件实现，应当理解，其他实现也可以是可能的。例如，可以存在更大或更少数量的服务器，电子商务平台100可以以分布式方式实现，或者除了其他可能的修改之外，存储器514、524、534中的至少一些尤其可以用外部存储装置或基于云的存储装置来替换。

如较早前陈述的，设置开始构建数据模型的静态时间可能导致某些问题。例如，在数据模型构建期间，正在处理的数据量的突然尖峰可能导致比预期长的处理时间，其进而可能使数据模型的可用性不可预测。如果存在被调度在相同时间（或前后）构建的大量数据模型，则该问题可能是复合的。

此外，当数据模型被调度在静态开始时间构建时，通常存在截止时间来收集用于构建数据模型的未处理数据。这可能导致无法捕获在截止时间之后可能接收到的最新近未处理数据，但这些数据仍然可能有助于包括在更新的数据模型中。

图6图示了与数据处理引擎350相关的电子商务平台100的一些细节，数据处理引擎350被配置为动态调度用于构建数据模型的作业，这可以帮助解析以上提及的一些问题。

尽管引擎350在图6中被图示为电子商务平台100的不同组件，这仅是示例。引擎也可以或取而代之地由驻留在电子商务平台100内部或外部的另一组件提供。在一些实施例中，应用142中的任一个或两个提供实现本文描述的功能的引擎，以使其对顾客和/或商家可用。此外，在一些实施例中，核心商务设施136提供该引擎。电子商务平台100可以包括由一方或多方提供的多个引擎。多个引擎可以以相同的方式、相似的方式和/或不同的方式实现。此外，引擎的至少一部分可以在商家设备102中和/或顾客设备150中实现。例如，顾客设备150可以本地存储和运行引擎作为软件应用。

如下面进一步详细讨论的，引擎350可以实现本文描述的至少一些功能。尽管下面描述的实施例可以与电子商务平台相关联地实现，诸如（但不限于）电子商务平台100，但是下面描述的实施例不限于电子商务平台。通常，引擎350可以被实现为独立的服务或系统，其被配置为动态调度用于为任何应用构建数据模型的作业，而不仅仅是为电子商务或在线商店。

在图6的示例中，数据处理引擎350包括作业调度器352、输入数据模块354、数据模型模块356和容量估计器358。作业调度器352、输入数据模块354、数据模型模块356和容量估计器358中的每一个可以被实现为数据处理引擎350的子模块，或者可以被实现为数据处理引擎350的一般功能的部分。数据处理引擎350连接到数据设施134，数据设施134包括输入数据1341、历史记录1343和数据模型定义1345。作业调度器352、输入数据模块354、数据模型模块356和容量估计器358被配置为当需要时访问输入数据1341、历史记录1343或数据模型定义1345，以便确定相应的开始时间T_C来构建在预期访问时间T_A所需的每个数据模型。在接下来的几个段落中，首先描述输入数据1341、历史记录1343和数据模型定义1345，随后是数据处理引擎350的实施例的详细描述。

数据设施134实时或批量接收和存储在电子商务平台100的操作期间生成的不同类型的输入数据1341。不同类型的输入数据1341可以包括例如匿名化的用户简档数据、交易数据、店面数据等。交易数据可以包括例如顾客联系信息、账单信息、装运信息、关于购买的产品的信息、关于呈现的服务的信息以及通过电子商务平台100与商务相关联的任何其他信息。

尽管图6示出了数据处理引擎350连接到核心商务设施136，但是在一些实施例中，数据处理引擎350可以不直接与核心商务设施136交互。例如，出于与系统容量或数据完整性相关的原因，数据处理引擎350可以取而代之连接到数据货栈系统（未示出）或核心商务设施136的插入式高速缓存副本，以便处理数据模型。对于数据处理引擎350而言不必为了处理在核心商务设施136的操作期间生成的数据而连接到核心商务设施136。

例如，核心商务设施136的数据货栈系统可以被实现并用于报告和数据分析。数据货栈系统可以存储当前和历史数据，并且可以包括数据设施134或数据设施134的副本。存储在货栈中的数据可以从核心商务设施136或数据设施134上传。数据处理引擎350可以连接到数据货栈系统，以便处理在核心商务设施136的操作期间生成的数据。

电子商务平台100的每个用户可以具有用户账户；用户帐户可以具有用户标识符（ID）。匿名化的用户简档数据可以包括例如对于给定的用户账户ID：浏览历史、购买历史、愿望列表、购物车内容、地理区域、语言偏好、未标识的会员信息等等。当数据处理引擎350（其可以是作业调度器352、输入数据模块354、数据模型模块356或容量估计器358）基于用户账户的用户ID查询数据设施134时，数据处理引擎350可以能够访问和检索匿名化的用户简档数据。

在各种实施例中，店面数据可以包括基于商家标识的关于一个或多个特定在线商店138的信息。例如，商家可以具有带有用户标识符（ID）的用户帐户。商家可以具有一个或多个在线商店138，并且一个或多个在线商店138中的每一个可以独立地与用户ID相关联。每个在线商店138可以具有商店ID，并且在商店ID下具有存储在数据设施134中的各种信息。在线商店138可以支持一个或多个独立管理的店面139，其中店面139可以由URL表示；也就是说，具有商店ID的在线商店138可以具有一个或多个URL，其中每个URL被配置用于不同的店面139。在相同商店ID下的所有URL可以存储在数据设施134中。在线商店138需要在店面139中列出一个或多个产品供应，并且每个列出的产品供应需要具有其相关联的库存计数。包括产品供应列表和对于每个产品供应的单独库存计数的店面数据可以在特定商店ID下存储在数据设施134中，并进而链接到特定用户ID。在线商店138还可以具有设置在适当位置的交付配置，用于向顾客装运和交付订购的产品供应。交付配置可以至少包括默认的装运方法（例如，FedEx^®）以及相关联的装运费用。交付配置可以在特定商店ID下存储在数据设施134中，并进而链接到特定用户ID。当数据处理引擎350基于商家的用户账户的用户ID查询数据设施134时，数据处理引擎350可以能够访问关于链接到用户ID的特定商家的一个或多个在线商店138的多个输入数据1341，包括一个或多个在线商店138的一个或多个URL、一个或多个支付轨道、一个或多个银行存款信息、一个或多个产品列表及其相关联的库存计数以及用于每个在线商店138的一个或多个交付配置。

其他类型的输入数据1341可以存储在数据设施134中。在各种实施例中，可以使用关系数据库来存储输入数据1341，并且可以使用SQL（结构化查询语言）来查询和维护数据库。一些输入数据1341可以是根本未被处理的原始数据；一些输入数据1341可以被预处理，例如，一些数据在被存储为输入数据1341之前可能已经被清理或标准化。

历史记录1343包括迄今为止已经被处理的过去数据的记录。在一些实施例中，历史记录1343可以与输入数据1341——诸如已经由数据处理引擎350处理的输入数据1341——重叠。历史数据1343可以包括例如：过去的交易数据或具有比预定义阈值（例如，24小时）更早的时间戳的匿名化用户简档数据，或关于过去事件和数据模型的元数据，诸如对于数据模型的预期访问时间、数据模型的类型、数据模型的尺寸或关于构建数据模型花费的总时间。历史记录1343可以包括在过去一天、一周、一月或一年的任何给定时间可用的计算资源的类型和量。例如，历史记录1343可以包括：在2020年1月23日3PM可用于数据处理的计算资源包括：20个服务器，每个服务器具有X量的RAM和Y量的CPU。历史记录1343可以进一步包括过去的数据模型，该过去的数据模型可以基于过去的输入数据1341来构建。

保存在历史记录1343中的表格的示例快照可以包含下面所示的信息：

数据模型号	001	002	003
				输入数据的尺寸	100亿行	100亿行	200亿行
输入数据的类型	交易数据	交易数据	店面数据
				平均历史处理时间	30分钟	15分钟	50分钟
平均开始时间	3：00 AM	3：00 AM	2：00 AM
				平均结束时间	3：30 AM	3：15 AM	2：50 AM
数据模型构建期间服务器的平均数量	100	100	80

输入数据的尺寸可以按照如上表中所示的行来表示，或者按照其他方式来表示，诸如例如按照诸如比特、字节、千字节（KB）、兆字节（MB）、千兆字节（GB）、兆兆字节（TB）之类的标准数据尺寸单位等。出于本公开的目的，短语“输入数据的尺寸”和短语“输入数据的行”可以是可互换的，并且它们都可以指代可以以行、比特、字节或用于表示存储在存储器存储设备上的电子数据尺寸的任何其他合适的单位来测量的输入数据的尺寸。

可供在处理数据中使用的服务器的平均数量（例如，服务器容量）以及用于处理数据的服务器的平均数量可以存储在历史记录1343中。历史上可用或使用的计算资源的其他记录统计数据可以包括例如CPU处理器的平均数量、RAM的平均量、平均磁盘I/O速度等。

数据模型定义1345可以包括数据模型定义的表格或列表，每个数据模型定义与唯一标识符相关联，并且包括诸如逻辑数据模型结构和/或物理数据模型结构的信息。数据模型的示例是用于未解决（未履行）订单的数据模型，并且用于该数据模型的相关联逻辑数据模型结构可以包括一个或多个数据实体，所述一个或多个数据实体例如来自：订单号、订单中售出的项目总数、商家ID和店面ID。逻辑数据模型结构还可以包括一个或多个数据模型，所述一个或多个数据模型包括例如订单中售出的每个产品供应的项目数据模型、顾客（购买者）数据模型、支付数据模型和装运数据模型。例如，对于订单中的每个产品供应，项目数据模型可以包括：产品供应ID、SKU编号、货栈位置和项目价格。顾客数据模型可以包括例如顾客ID、会员ID（如果适用）、顾客的装运地址和顾客的账单地址。支付数据模型可以包括例如如从金融机构130发送的支付确认号、支付类型和总支付额。装运数据模型可以包括例如装运地址、快递员、估计装运日期和与装运地址相关联的电话号码。

对于逻辑数据模型结构中的每个数据实体，对应的物理数据模型结构可以包括例如数据实体名称（例如，订单_ID）、对应类型的数据实体（例如，字符或字符串）、数据实体的对应最大尺寸（例如，2字节）、可以用于在输入数据1341中查找数据实体的数据实体的链接，以及如果适用的话，用于获得数据实体值的查询（例如，SQL查询）。逻辑或物理数据模型结构中的每个数据实体值可以使用来自输入数据1341的查询来获得。

数据实体的相应最大尺寸可以与数据实体的类型相关联。例如，实数或十进制数通常存储在比整数（int）或bigint更多的字节中，字符（char）小于字符串或varchar，blob是最大且组织最少的数据类型，并且保存变量，通常大量数据存储在非结构化的字节转储中（例如，对于图像的数据），并且时间戳通常大于日期戳，因为时间戳允许指定至毫秒。

另一个示例数据模型可以是用于产品供应的每日销售的数据模型，并且相关联的逻辑数据模型结构可以包括一个或多个数据实体，所述一个或多个数据实体例如来自：产品供应ID、SKU号码、库存计数的总数、在过去24小时内的销售总数、商家ID和店面ID。在一些示例中，相关联的逻辑数据模型结构可以是面向对象的数据模型，并且基于诸如电子商务平台100的系统的一个或多个操作或业务规则来生成。对于逻辑数据模型结构中的每个数据实体，对应的物理数据模型结构可以包括例如数据实体名称（例如，产品_ID或SKU号）、对应类型的数据实体（例如，整数或字符）、数据实体的对应最大尺寸（例如，5个字符）、可以用于在输入数据1341中查找数据实体的数据实体的链接、以及可选地可以用于获得输入数据1341中的数据实体值的查询。

在一些实施例中，对于给定的数据模型，数据模型定义1345可以包括用于该数据模型的定义的用户群组。定义的用户群组可以包括需要访问数据模型的用户帐户（例如，数据模型的目标受众）。例如，履行中心员工可能需要访问未履行的订单数据模型，并且因此可能作为用户帐户包括在定义的用户群组中。

在一些实施例中，逻辑数据模型结构和物理数据模型结构二者可以存储在文本文件、XML文件、SQL文件中或以任何其他合适的格式。

数据处理引擎350可以被配置为调度开始时间T_C以处理输入数据并构建数据模型。可以基于数据模型的预期访问时间T_A和构建数据模型所需的总时间T_R来确定开始时间T_C。

在图6中所示的实施例中，数据处理引擎350包括作业调度器352。在各种实施例中，作业调度器352可以被配置为基于数据模型的预期访问时间T_A来确定或更新构建数据模型的调度开始时间T_C。作业调度器352可以访问所需数据模型的现有列表，每个所需数据模型都具有默认的预期访问时间T_A。所需数据模型的列表可以存储在数据处理引擎350或数据设施134中。作业调度器352可以监视所需数据模型的列表，并基于该数据模型的预期访问时间T_A来确定开始构建给定数据模型的调度开始时间T_C，如本公开中详细描述的。

一旦已经确定并存储了用于构建数据模型的开始时间T_C，如果数据处理引擎350接收到指示可能影响调度开始时间T_C的若干条件之一的改变的信息，则作业调度器352可以更新该开始时间T_C。例如，如果存在收集的输入数据中突然且未预见的尖峰、可用计算资源的突然且未预见的减少和/或数据模型的访问时间T_A的意外改变，则作业调度器352可以更新用于基于（一个或多个）改变的条件来构建数据模型的开始时间T_C。作业调度器352可以被配置为监视电子商务平台100，以便检测如以上提及的任何改变，和/或当输入数据、计算资源（例如，服务器容量）、调度数据模型的访问时间或任何其他适当的条件改变时，电子商务平台100可以向该作业调度器352通知。

给定数据模型的预期访问时间T_A可以在电子商务平台100中预定义；例如，它可以作为每个数据模型的部分存储在数据模型定义1345中。例如，一个或多个数据模型的预期访问时间T_A1可以由系统管理器预定义为从周一至周五每天8：00 AM，而一些其他数据模型的预期访问时间T_A2可以预定义为每天9：00 AM。

在一些实施例中，作业调度器352可以被配置为通过基于历史记录1343细化预定义访问时间来估计预期访问时间T_A。例如，可以通过基于指示在一段时间（例如，N天）内的实际访问时间的记录数据调整预定义访问时间来估计预期访问时间T_A。记录的数据可以是历史记录1343的部分。如果预定义的访问时间是8：00 AM，并且来自历史记录1343的数据指示实际访问时间在过去五天的8：10 AM到8：20 AM之间变化，则作业调度器352可以基于那些值来估计预期访问时间T_A。例如，基于在过去五天期间的预定义访问时间8：00 AM和最早的实际访问时间8：10 AM之间的平均值的计算，预期访问时间TA可以被估计为8：05 AM。

在其他实施例中，当预期访问时间的预定义值可能为空（null）（例如，其尚未被定义）时，作业调度器352可以被配置为基于指示在过去时间段（例如，N天）内的实际访问时间的历史数据来估计预期访问时间T_A。估计的访问时间T_A可以是过去时段中最早的实际访问时间，或者可以是基于在过去时段中的多个实际访问时间计算的平均值。

在另一个示例中，估计的访问时间T_A可以基于在历史记录1343基础上的相似数据模型的实际访问时间，或者基于由相似用户群组正在使用的数据模型的实际访问时间。在又一示例中，作业调度器352可以获得对一个或多个用户日历的访问，以便提取指示何时可以访问数据模型的信息。

在一些实施例中，基于机器学习的算法可以在作业调度器352内实现，或者作为单独的子模块来实现，以估计数据模型的最可能访问时间T_A。由机器学习模型提供的预测可以基于历史记录1343，历史记录1343指示数据模型一旦构建后的数据模型的实际访问时间。例如，如果在过去的N天（例如，一周）中每天在8：25 AM到8：30 AM之间一致地访问数据模型，则基于机器学习的算法可以估计预期访问时间T_A为8：25 AM。在给定某些信息（例如，数据模型的输入数据类型、数据模型的ID、数据模型的用户群组等等）的情况下，监督式学习方法可以用于训练机器学习模型来学习用于推断数据模型的估计访问时间T_A的函数。训练机器学习模型可以使用历史记录1343作为训练数据，该历史记录1343指示数据模型和/或类似数据模型和/或相同用户群组使用的另一数据模型的实际访问时间。

除了数据模型的预期访问时间T_A之外，作业调度器352可以被配置为确定对构建数据模型所需的总时间T_R。总时间T_R可以以多种方式或基于多种因素来计算。例如，总时间T_R可以基于多个因素来计算，所述多个因素包括例如以下各项中的一个或多个：输入数据的总尺寸、如从数据模型定义1345学习的数据模型的定义、指示构建数据模型的过去处理时间的历史记录和/或可用的计算资源或容量。

作业调度器352可以查询输入数据模块354，以基于数据模型的预期访问时间T_A来预测给定数据模型的输入数据的总尺寸S_F。输入数据模块354可以基于现有输入数据的尺寸S_X和在当前时间T_P和未来时间（诸如预期访问时间T_A）之间接收的输入数据的估计尺寸S_Y来预测输入数据的总尺寸S_F。

在一些实施例中，输入数据模块354可以查询数据模型模块346以获得关于数据模型的信息。数据模型模块346可以基于给定的数据模型ID或任何唯一的标识符，在数据模型定义1345中查找数据模型，以获得用于数据模型的逻辑数据模型结构和对应的物理数据模型结构。物理数据模型结构可以包括在数据模型中包含的每个数据实体的链接。数据模型模块356可以将每个数据实体的链接返回到输入数据模块354，该输入数据模块354进而可以使用每个数据实体的链接来查询输入数据1341，以获得在当前时间T_P与数据模型中的每个数据实体相关联的输入数据的尺寸。输入数据模型模块354然后可以基于与包含在数据模型中的每个数据实体相关联的输入数据的相应尺寸，获得数据模型在时间T_P的现有输入数据的尺寸S_X。例如，总尺寸S_X可以按照数据行来表示，或者可以用比特、字节、KB、MB、GB或TB来表示。

输入数据模块354可以使用历史记录1343来预测在当前时间T_P和未来时间（诸如预期访问时间T_A）之间接收的数据模型的输入数据的估计尺寸S_Y。历史记录1343可以保存在过去时间段中的各个时间点处接收的数据模型的输入数据尺寸的记录，和/或在一个或多个时间段期间为数据模型累积的输入数据的增量尺寸的记录。例如，历史记录1343可以具有指示给定数据模型的输入数据累积的信息：在9：01 PM到10：00 PM之间1 GB；在10：01 PM到11PM之间1.2 GB；在11：01 PM到午夜0：00之间2 GB；等等。在每个时段期间累积的输入数据的尺寸可以是从最新近的时间段（例如，前一天）记录的输入的实际尺寸，或者可以是基于在对于过去多个所选（例如连续）天数的相同时段（例如，9：01 PM到10：00 PM）期间记录的输入数据的实际尺寸计算的平均值。输入数据模块354可以使用以上信息来确定在9：01PM到午夜之间，数据模型接收到大约4.2 GB（S_Y = 4.2 GB）的输入数据。输入数据模块354然后可以基于历史记录1343预测，在当前时间T_P=9：01 PM和午夜之间将累积大约4.2 GB的输入数据。通过使用历史记录1343来估计每个时间段中累积的输入数据的尺寸S_Y，输入数据模块354可以计及数据收集中的不规则性或突发。例如，当电子商务平台100在全球操作并且每个地理区域中的服务器在当地时间2 AM将收集的数据从一个或多个生产数据库上传到数据设施134时，当各个时区中的服务器在当地时间2 AM上传它们相应对输入数据的贡献时，输入数据可以到达突发。

可选地，输入数据模块354可以被配置为，为了计及数据收集中的潜在错误或未预料到的激增，在估计当前时间T_P和未来时间之间接收的输入数据的尺寸S_Y中添加应用调整因子。例如，输入数据模块354可以将如基于历史记录1343确定的输入数据的尺寸（4.2 GB）增加10%，这意味着，使用以上相同的示例，在当前时间T_P 9：01 PM和午夜之间将累积大约S_Y= 4.62 GB的输入数据。调整因子可以在系统中预定义。

因此，输入数据模块354可以预测或估计在当前时间T_P和未来时间之间接收的数据模型的输入数据的尺寸S_Y。在一些实施例中，未来时间可以是预期访问时间T_A。输入数据模块354然后可以将在当前时间T_P的现有输入数据的尺寸S_X添加到在当前时间T_P和预期访问时间T_A之间接收的输入数据的估计尺寸S_Y，以便估计将被收集来构建数据模型的输入数据的总尺寸S_F。调整因子（例如，5%或10%）可能被添加到S_F的估计中，以计及在当前时间和未来时间之间数据收集中的任何未预见的尖峰。

输入数据模块354把将被收集以在未来时间（例如，预期访问时间T_A）构建数据模型的输入数据的总尺寸S_F发送到作业调度器352，该作业调度器352然后可以基于输入数据的总尺寸S_F和如存储在数据模型定义1345中的数据模型的定义来确定对构建数据模型所需的总时间T_R。具体地，作业调度器352可以向数据模型模块356发送查询，以从数据模型定义1345检索用于数据模型的数据模型定义。用于数据模型的检索到的数据模型定义可以包括逻辑数据模型结构，该逻辑数据模型结构可以指示数据模型是否依赖于任何其他数据模型。例如，如较早前所述，未解决（未履行）订单的数据模型可以包括（即，依赖于）其他数据模型，所述其他数据模型包括但不限于例如售出的每个产品供应的项目数据模型、顾客数据模型、支付数据模型和装运数据模型。

在数据模型依赖于其他数据模型的复杂过程中，作业调度器352可以被配置为基于构建依赖于其他数据模型的给定数据模型的复合总时间的计算来编排多个数据模型的构建过程，该复合总时间考虑了构建数据模型的时间和构建任何先决条件数据模型的时间二者。（值得注意的是，在一些情况下，这可能涉及考虑数据模型之间的此类多层依赖关系）。此外，作业调度器352可以计算构建多个数据模型中的每一个的最佳开始时间，以确保所有数据模型在预期访问时间之前可用。例如，当用于给定数据模型D1的检索到的数据模型定义包括另一数据模型D2时，作业调度器352可以被配置为在估计对构建数据模型D1所需的总时间T_{R_D1}之前，首先确定对构建数据模型D2所需的总时间T_{R_D2}。在一些实施例中，当用于给定数据模型D1的检索到的数据模型定义包括多个数据模型D2、D3…DM时，作业调度器352可以被配置为在估计对构建数据模型D1所需的总时间T_{R_D1}之前，首先确定对构建数据模型D2、D3…DM中的每一个所需的总时间T_{R_D2}、T_{R_D3}…T_{R_DM}，该数据模型D1依赖于数据模型D2、D3…DM中的每一个。

典型地，数据模型之间的循环依赖关系（例如，数据模型D1包括D2，D2又包括D1）是罕见的。然而，如果当要构建的一个或多个数据模型中存在循环依赖关系时，作业调度器352可以被配置为通过如下式依赖关系链断裂：使用来自先前时段的这样的依赖关系循环（例如，D1）中涉及的一个或多个数据模型的过去版本，作为以数据新鲜度为代价的依赖关系中涉及的至其他数据模型（例如，D2）生成的输入。

作业调度器352可以至少基于如存储在历史记录1343中的每个数据模型的历史信息来估计T_R。在各种实施例中，给定数据模型D1，作业调度器352可以访问历史记录1343以获得指示用于构建数据模型D1的平均处理时间的信息。存储在历史记录1343中的数据模型记录的示例快照如下：

数据模型号	001	002	003
				输入数据的尺寸S<sub>H</sub>	1.3 GB	0.8 GB	5 GB
平均历史处理时间T<sub>H</sub>	30分钟	15分钟	50分钟
				平均开始时间	3：00 AM	3：00 AM	2：00 AM
平均结束时间	3：30 AM	3：15 AM	2：50 AM
				数据模型构建期间的平均容量C<sub>H</sub>	100个服务器	100个服务器	100个服务器

在一些实施例中，作业调度器352可以被配置为仅检索基于最新近事件（例如，基于最新近3天或5天计算的平均历史处理时间T_H）被存储或计算的信息，以便确保仅考虑最新近的历史数据。基于历史值集合计算的并存储在历史记录1343中的平均值也可以被周期性地（例如，在每个早上的2 AM）刷新，以便提供关于数据模型的最新统计数据。

在一些实施例中，在检索数据模型中的数据实体的值中使用的查询可以影响对构建数据模型所需的历史（或预测）处理时间。例如，需要搜索文本来找到匹配（例如，列_1 =“商店内收取”）的查询可能比仅需要搜索号码的查询花费更久。作为另一个示例，使用模糊匹配的查询（例如，列_1 =“%收取%”，它将匹配“商店内收取”、“路边收取”和“收取在商店内”）可能比没有模糊匹配的简单文本查询花费更久。作为又一个示例，查询没有索引的表格可能倾向于比查询具有索引的表格花费更久。此外，需要多个表格联合以合并跨多个源的数据的查询可能比仅查询一个表格或一个源花费更久，例如，如需要被创建来存储临时数据（例如，以实现联合）的临时表，并且诸如如果来自不同表格的多行被表示在临时表格的每一行中，则这样的临时表可能增长至在尺寸上很大。

在一些实施例中，用在构建数据模型中的数据模型算法也可以影响对构建数据模型所需的历史（或预测）处理时间。例如，一些数据模型可以需要使用可能比在生成或更新其他数据模型中采用的算法更耗时或更处理器密集的算法。例如，第一数据模型可以需要检索商店的所有顾客姓名，将所有姓名存储在临时表格中，并且然后对于每个姓名，单独地在第二表格中查找顾客的支付信息。第二数据模型可以仅需要执行JOIN查询，该JOIN查询通过将两个表格（例如，顾客_名称表格和顾客_支付表格）联合在一起来在一次查询中检索每个顾客的姓名以及他或她的支付信息，其仅是待运行的单个查询。第一数据模型构建起来可能比第二数据模型将花费久得多。

在一些实施例中，用于处理查询本身的查询引擎可以进一步影响对构建数据模型所需的历史（或预测）处理时间。例如，可以并行处理多个作业的查询引擎可能比一次仅可以处理单个作业（即，按顺序）的查询引擎更快。作为另一个示例，可以跨不同服务器之上分布多个作业的查询引擎可能比在一个服务器上处理所有作业更快。

通过使用历史记录1343中的平均历史处理时间T_H作为起始点来估计对构建数据模型所需的总时间T_R，作业调度器352基于如下假设进行操作：一旦在数据模型定义1345中定义了数据模型，在数据模型定义中为数据模型指定的查询和算法就不经常改变，或者不随机改变。作为运行不同查询或算法的结果，诸如当查询引擎在数据模型构建过程期间优化一个或多个查询时，对构建数据模型所需时间的任何变化都可以通过使用在一段时间（例如，过去五天）内的历史平均值来适应。

在一些实施例中，当作业调度器352在历史记录1343中不能找到特定数据模型D1时，作业调度器352可以被调度来检索在结构上与数据模型D1相似的不同数据模型D2的历史信息，并且使用数据模型D2的历史信息作为起始点来估计对构建数据模型D1所需的总时间T_R。例如，可以基于如从数据模型定义1345获得的相应逻辑数据模型结构或相应物理数据模型结构的比较来确定结构上的相似性。例如，用于商家的第一商店的数据模型的逻辑数据模型结构（或对应的物理数据模型结构）可以类似于用于同一商家的第二商店的数据模型的逻辑数据模型结构（或对应的物理数据模型结构）。作为另一个示例，用于未履行订单的数据模型在结构上可以类似于用于已履行订单的数据模型，其中在逻辑数据模型结构上的仅有差异是指示订单已经履行或装运的数据实体。

参考回到以上历史记录1343中的示例表格，对构建数据模型所需的总时间T_R可以与输入数据的总尺寸S_F和可用计算资源量（例如，在数据模型构建过程期间可用的服务器总数）相关联并且受其影响。在各种实施例中，在给定从历史记录1343检索到的数据模型的历史平均处理时间T_H的情况下，作业调度器352可以被配置为基于如由输入数据模块354估计的与数据模型的输入数据的总尺寸S_F相关联的第一因子F₁和/或基于与可用计算资源量相关联的第二因子F₂来更新T_H，其可以由容量估计器358估计。例如，T_R可以基于公式

来确定。

在一些实施例中，第一因子F₁可以是数据模型的输入数据的总尺寸S_F和来自历史记录1343的数据模型的输入数据的历史尺寸S_H之间的比率，即，

。

在一些实施例中，第二因子F₂可以是可以由容量估计器358估计的来自历史记录1343的可用于数据模型的计算资源的历史量C_H和可用计算资源的估计量C_F之间的比率，即，

。

在一些实施例中，为了估计可用于数据模型的计算资源的量C_F，容量估计器358可以被配置为访问历史记录1343，以获得指示在过去时段期间的不同时间点处可用的计算资源的相应量的一个或多个记录。计算资源量可以以多种方式来表述，诸如例如按照可用服务器的总数、按照可用CPU核心的总数和/或按照可用存储器（例如，RAM）的总量来表述。作为示例，历史记录1343可以指示，历史上存在9：00 PM可用的100个服务器、在10：00 PM可用的98个服务器以及在11：00 PM可用的90个服务器，等等。在每个时段期间可用服务器的数量可以是例如在特定时间点（例如，昨天9：00 PM）可用的服务器的实际数量，或者可以是基于在过去多个连续天数内每一天某个时间点处的可用服务器的实际总数来计算的平均值。在调度中作出的假设可以是，在正常情况下，可用服务器的数量或者通常对于电子商务平台100可用的计算资源是循环的，并且倾向于在每天基础上展现相同的模式。

基于从历史记录1343获得的在不同时间点处的可用服务器的历史数量，容量估计器358可以以类似的方式估计从当前时间T_P到未来时间的不同时间点处的可用服务器的数量。使用上面段落中的示例，在当前时间T_P是8：30 PM时，容量估计器358可以估计100个服务器可能在9：00 PM可用，98个服务器可能在10：00 PM可用，并且90个服务器在11：00 PM可用。

在一些实施例中，代替或除了使用历史记录1343来估计可用计算资源量之外，容量估计器358可以被配置为查询数据设施134，以在可用的情况下或者当可用时获得表示有多少将在当前时间T_P和未来时间之间可用于数据模型构建的计算资源（例如，服务器的总数）的信息。例如，数据设施134可以具有在一天的任何一小时或半小时分配给数据模型构建的计算资源的调度。该调度可以由电子商务平台100或系统管理器取决于用于整个电子商务平台100的总体计算资源分配方案来实时或接近实时地更新。

在一些实施例中，如果并且当任何附加的计算资源（例如，服务器）变得可用，这没有被历史记录1343或任何现有的计算资源分配所计及，则附加的计算资源可以被容量估计器358检测到，并被添加到当前时间T_P和未来时间之间可用的计算资源的当前估计上。

作业调度器352可以从容量估计器358获得可用计算资源的估计量C_F，其可以包括估计量C_F1、C_F2、C_F3…C_FN的可用计算资源的列表，每个对应于当前时间T_P和未来时间（例如，11M）之间的特定时间点（例如，9 PM、10 PM、11 PM）。对于每个列出的量

的可用计算资源，作业调度器352可以计算对应的第二因子F₂作为数据模型的输入数据的历史尺寸C_H与由容量估计器358估计的可用计算资源的相应量C_F之间的比率，即，

。

在一些实施例中，对于构建数据模型所需的相应总时间T_R可以在当前时间（例如，8：30 PM）和未来时间（例如，11 PM）之间的多个未来时间（例如，9 PM、10 PM、11 PM）的每一个开始估计，其稍后可以用来计算用于开始数据模型的构建过程的对应开始时间T_C。作业调度器352可以计算在当前时间T_P和预期访问时间T_A之间的各种时间点（例如，9 PM、10PM…）处构建给定的数据模型所需的相应总时间T_R（例如，在t= 9 PM处的T_{R_9P}、在t= 10 PM处的T_{R_10P} …）。可以使用公式

基于在对应时间点（例如，9 PM、10 PM…）处可用的计算资源的相应估计量C_F来计算每个相应的总时间T_R。在一些实施例中，可以使用调整因子来调整T_R，以更好地确保数据模型将在预期访问时间T_A之前完成，例如，

，其中1.1是示例调整因子，并且可以由数据处理引擎350或系统管理器预定义。

接下来，作业调度器352可以针对在当前时间T_P和预期访问时间T_A之间的时间点T_L（例如，T_L = 9 PM、10 PM…）处构建数据模型所需的每个总时间T_R来计算，可以基于相应的总时间T_R来计算用于开始构建数据模型的对应开始时间T_C。例如，如果预期的访问时间T_A是11：59：00 PM，并且在T_L = 9 PM的T_R是50分钟，则用于开始构建数据模型的对应开始时间T_C1最晚可以被设置为9：59：59 PM。在这种情况下，T_C1不应被设置为晚于9：59：59 PM的时间，因为9：59：59 PM是在9：00 PM可用的计算资源的估计量C_F将适用的最晚时间。如果在T_L= 10 PM的T_R为90分钟，则用于开始构建数据模型的开始时间T_C2最晚可以被设置为10：29PM；并且如果在T_L = 11 PM的T_R为80分钟，则用于开始构建数据模型的对应开始时间T_C3是空（null），因为在预期访问时间T_A 11：59：00 PM之前的80分钟早于T_L = 11 PM。作业调度器352然后可以在T_C1、T_C2、T_C3中选择最晚的可能开始时间作为用于调度数据模型构建的T_C，其在这种情况下是T_C2 =10：29 PM。

在一些实施例中，作业调度器352可以被配置为持续地监视数据设施134和核心商务设施136，以便可能需要更新输入数据的总尺寸S_F、可用计算资源的量C_F或预期访问时间T_A的任何指示。如果输入数据的总尺寸S_F、可用计算资源的量C_F和预期访问时间T_A中的任一个已经改变，或者高度可能改变，则作业调度器352可以相应地更新用于开始构建数据模型的开始时间T_C。

例如，作业调度器352可以在开始构建数据模型的所确定的时间T_C之前，确定输入数据的总尺寸S_F已经增加（或减少）到S_F’，并且基于输入数据的增加（或减少）的尺寸S_F’和数据模型的定义来估计对于构建数据模型所需的修订的总时间T_R’，修订的总时间T_R’大于（或小于）用于构建数据模型的先前估计的总时间T_R。作业调度器352接下来可以基于数据模型的预期访问时间T_A和对构建数据模型所需的修订的总时间T_R’来确定用于开始构建数据模型的更新时间T_C’，更新时间T_C’早于（或晚于）开始构建数据模型的先前确定时间T_C。作业调度器352然后可以重新调度数据模型的构建以在较早（或较晚）的更新时间T_C’开始。

作为另一个示例，作业调度器352可以：在开始构建数据模型的所确定的时间T_C之前，获得数据模型的更新的预期访问时间T_A’；基于数据模型的更新的预期访问时间T_A’和对于构建数据模型所需的估计总时间T_R，确定开始构建数据模型的更新时间T_C’；以及重新调度数据模型的构建以在更新的时间T_C’开始。

对于又一个示例，作业调度器352可以：在开始构建数据模型的所确定时间T_C之前，获得数据模型的更新的预期访问时间T_A’；如果适当，则基于更新的访问时间T_A’确定输入数据的更新尺寸S_F’；以及基于输入数据的更新尺寸S_F’和数据模型的定义来估计对于构建数据模型所需的修订的总时间T_R’。作业调度器352接下来可以基于数据模型的更新的预期访问时间T_A’和对构建数据模型所需的修订的总时间T_R’来确定用于开始构建数据模型的更新时间T_C’。作业调度器352然后可以重新调度数据模型的构建以在较早（或较晚）的更新时间T_C’开始。

可选地，如果数据模型的开始时间T_C已经被计算了多次并且保持相对恒定（例如，总是在8AM-8：0AM的范围内），则作业调度器352可以将开始时间T_C固定在8：00 AM到8：20AM之间的时间，使得数据处理引擎350不必花费计算开始时间T_C的资源。可能存在周期性检查（例如，每周或每月）来调整开始时间T_C（如果有必要）或由系统管理器设置。同时，其他数据模型的动态开始时间T_C可以被不断地细化。

图7是图示用于动态调度数据模型构建作业的示例过程700的流程图。过程700可以由电子商务平台100（例如，使用数据处理引擎350）实现。过程700可以由执行指令的处理设备（例如，在核心服务器510或应用服务器530处）实现。

在操作701，可以基于唯一标识符来标识要构建的数据模型。数据设施134或数据处理引擎350可以存储需要每天构建的所需数据模型的列表，例如基于用户需求或商业需求的预定义表格。数据模型列表可以通过唯一标识符来标识每个数据模型，或者可以包含到存储在数据设施134上的数据模型定义的链接。

在操作702，可以确定预期访问时间T_A。例如，所需数据模型列表可以包含每个所需数据模型的默认预期访问时间T_A。给定数据模型的预期访问时间T_A可以在电子商务平台100中预定义；例如，它可以作为每个数据模型的部分存储在数据模型定义1345中。在一些实施例中，可以通过基于指示在一段时间（例如，N天）内的实际访问时间的历史数据调整预定义访问时间来估计所估计的预期访问时间T_A。在其他实施例中，可以仅基于历史数据来估计预期访问时间T_A。例如，估计的访问时间T_A可以被设置为在过去时段中最早的实际访问时间，或者可以是基于过去时段内的多个实际访问时间计算的平均值。

在操作703，可以确定对构建数据模型所需的输入数据的总尺寸S_F。例如，输入数据的尺寸可以基于现有输入数据的尺寸S_X和在当前时间T_P和未来时间（诸如预期访问时间T_A）之间接收的输入数据的估计尺寸S_Y来确定。现有输入数据的尺寸S_X可以通过查询数据设施134来获得，该数据设施134存储到目前为止因此针对数据模型收集的所有输入数据。例如，可以基于与包含在数据模型中的每个数据实体相关联的输入数据的相应尺寸来获得数据模型在当前时间T_P的现有输入数据的尺寸S_X。尺寸可以按照数据行来表示，或者可以用比特、字节、KB、MB、GB或TB来表示。

此外，可以基于历史记录1343来确定在当前时间T_P和未来时间之间接收的输入数据的估计尺寸S_Y，历史记录1343具有表示在各个时间段（例如从9 PM到10 PM以及从10：01PM到11 PM）期间为每个数据模型接收的输入数据的历史尺寸的信息。例如，输入数据的估计尺寸S_Y可以基于在前一天的相同时段期间实际接收的输入数据的尺寸来确定。在一些实施例中，为了计及数据收集中的潜在错误或未预料到的激增，可以在估计当前时间T_P和未来时间之间接收的输入数据的尺寸S_Y中添加或应用调整因子。接下来，在当前时间T_P的现有输入数据的尺寸S_X和在当前时间T_P和预期访问时间T_A之间接收的输入数据的估计尺寸S_Y可以相加在一起，并被存储为将被收集以构建数据模型的输入数据的估计总尺寸S_F。

在操作704，数据处理引擎350可以周期性地检查预期访问时间T_A是否需要从T_A的最后计算或从最后检查开始更新。该检查可以通过基于最新近的操作条件重新确定预期访问时间T_A来实现，该最新近的操作条件可以是或可以不是自上次T_A计算或自上次检查以来已经改变的。如果重新确定的预期访问时间T_A不同于预期访问时间的先前值，则在操作706，可以将重新确定的预期访问时间T_A的值存储为更新的预期访问时间T_A。在一些实施例中，如果电子商务平台100的系统管理器或系统组件已经请求数据模型的更新的访问时间T_A’，则可以向数据处理引擎350发送通知，并且在操作706，可以存储预期访问时间T_A的更新值，从而替换先前的值。

在一些实施例中，当在操作706更新预期访问时间T_A时，可以将更新的值发送到操作703，以基于更新的预期访问时间T_A来重新计算用于数据模型的输入数据的总尺寸S_F。

在操作705，可以基于输入数据的总尺寸S_F、数据模型的定义、指示用于构建数据模型的过去处理时间的历史记录和/或可用的计算资源或容量来确定对于构建数据模型所需的总时间T_R，如本公开中所述。在一些实施例中，基于历史记录，对于构建数据模型所需的相应总时间T_R可以在当前时间和预期访问时间T_A之间的多个未来时间（例如，在t= 9 PM处的T_{R_9P}、在t= 10 PM处的T_{R_10P}）中的每一个开始估计。每个相应的总时间T_R可以基于在对应时间点（例如，9 PM、10 PM…）处可用的计算资源的相应估计量C_F和输入数据的总尺寸S_F来计算。

在操作707，数据处理引擎350可以周期性地（例如，每30分钟）检查对于构建数据模型所需的输入数据的总尺寸S_F是否需要自最后一次S_F计算或自最后一次检查以来进行更新。例如，可以检测到电子商务平台100的网络流量中的异常或意外激增，这可以被解释为指示日期模型的输入数据可能已经增加。在这种情况下，数据处理引擎350可以重新计算和更新输入数据的总尺寸S_F。作为另一个示例，电子商务平台100的系统管理器或系统组件可以发送通知，该通知指示输入数据通常可以基于预测或检测到的事件而增加或减少。例如，快闪销售可能导致在线商店的增加的输入数据，而影响大都市地区的大范围停电可能指示减少的输入数据。当电子商务平台100预测或检测到这样的事件时，可以相应地重新计算和更新输入数据的总尺寸S_F。

在操作708，对于构建数据模型所需的总时间T_R可以基于用于数据模型的输入数据的更新的总尺寸S_F来修订。

在操作709，可以基于数据模型的预期访问时间T_A和对构建数据模型所需的估计总时间T_R来计算用于开始构建数据模型的开始时间T_C。当存在针对数据模型构建过程估计的多个总时间T_R时，其中每个T_R与来自在当前时间和预期访问时间T_A之间的多个未来时间（例如，在t= 9 PM处的T_{R_9P}、在t= 10 PM处的T_{R_10P}）的相应未来时间相关联，可以为每个T_R计算开始时间T_C，并将其与来自多个未来时间的相应未来时间相关联。然后可以从多个开始时间T_C中选择最终开始时间T_{C_FINAL}。

在操作710，数据模型可以被调度在确定或更新的开始时间T_C或T_{C_FINAL}处构建。

贯穿过程700，数据处理引擎350可以周期性地监视数据设施134和核心商务设施136，以便输入数据的总尺寸S_F、可用计算资源的量C_F或预期访问时间T_A可能需要更新的任何指示。如果输入数据的总尺寸S_F、可用计算资源的量C_F和预期访问时间T_A中的任一个已经改变，或者高度可能改变，则在操作711，可以通过重新计算输入数据的总尺寸S_F、可用计算资源的量C_F和预期访问时间T_A中的一个或多个来更新用于开始构建数据模型的开始时间T_C。在开始时间T_C或T_{C_FINAL}已经在操作711被更新的情况下，数据处理引擎350可以返回到操作710来调度数据模型的构建以在更新的开始时间开始。

在操作712，在数据模型构建过程期间，关于正在构建的数据模型的各种元数据可以被记录并存储在历史记录1343中，所述各种元数据包括例如：输入数据的实际总尺寸、针对构建数据模型花费的实际时间、可用计算资源的实际量。在数据模型已经被构建和访问之后，附加的元数据可以被记录和存储在历史记录1343中，所述附加的元数据包括例如：数据模型的实际访问时间，以及它被访问的次数。

代替以静态方式批量调度数据处理作业（例如，典型地，当资源使用倾向于最低时调度作业），所描述的数据处理引擎350和过程700的实施例使用数据模型构建的历史记录以及现有信息（诸如例如，关于要处理的输入数据、要构建的数据模型或可用计算资源的知识），来估计对开始和完成数据模型构建最可能需要的总时间量，并且然后基于估计的所需总时间量和构建的数据模型的预期访问时间来调度数据模型构建。

本公开中的方法可能被认为是与传统的数据处理方法相反的直觉，因为为了捕获可能最多的输入数据量，调度数据模型来尽可能晚地被构建，通常将不与最低资源使用的（一个或多个）时间一致，这通常是批量调度的情况和目的。此外，本文公开的实施例使能实现对于不同的数据模型定制构建时间，这也不同于传统的批量调度解决方案。对于不同的数据模型，具有不同的构建时间可以帮助更好地分配计算资源，因为数据处理作业在一段时间内展开。

尽管本公开描述了具有以特定次序的步骤的方法和过程，但是方法和过程的一个或多个步骤可以视情况而定被省略或变更。一个或多个步骤可以视情况而定以不同于描述它们的次序发生。

尽管至少部分地按照方法描述了本公开，但是本领域普通技术人员将理解，本公开还针对用于执行所描述方法的至少一些方面和特征的各种组件，无论是通过硬件组件、软件还是两者的任何组合。因此，本公开的技术方案可以以软件产品的形式体现。合适的软件产品可以存储在预先记录的存储设备或其他类似的非易失性或非暂时性计算机可读介质中，例如包括DVD、CD-ROM、USB闪存盘、可移动硬盘或其他存储介质。软件产品包括有形地存储在其上的指令，所述指令使得处理设备（例如，个人计算机、服务器或网络设备）能够执行本文公开的方法的示例。

在不脱离权利要求的主题的情况下，本公开可以以其他特定形式体现。所描述的示例实施例在所有方面中都应被视为仅是说明性的并且非限制性的。从一个或多个上述实施例选择的特征可以被组合以创建未明确描述的替代实施例，适合于此类组合的特征在本公开的范围内被理解。

还公开了公开范围内的所有值和子范围。此外，尽管本文公开和示出的系统、设备和过程可以包括特定数量的元件/组件，但是系统、设备和组装件可以被修改以包括更多或更少的此类元件/组件。例如，尽管所公开的元件/组件中的任一个可以被称为单数，但是本文公开的实施例可以被修改为包括多个此类元件/组件。本文描述的主题旨在覆盖和包含技术中所有合适的改变。

所有参考文献特此通过引用以其整体并入。

本教导还可以扩展到一个或多个以下编号的条款的特征：

条款

1.一种用于调度数据处理作业的方法，包括：

标识要构建的数据模型，该数据模型与定义要在构建该数据模型中使用的输入数据的数据模型定义相关联；

确定输入数据的尺寸；

获得用于数据模型的预期访问时间；

基于输入数据的尺寸和数据模型的定义来估计对于构建数据模型所需的总时间；

基于用于数据模型的预期访问时间和构建数据模型所需的估计总时间来确定开始构建数据模型的时间；和

调度数据模型的构建以在确定的时间开始。

2.根据条款1所述的方法，进一步包括：

在开始构建数据模型的确定的时间之前，确定输入数据的尺寸已经增加；

基于输入数据的增加的尺寸和数据模型的定义，估计对于构建数据模型所需的修订的总时间，修订的总时间大于对于构建数据模型的先前估计的总时间；

基于用于数据模型的预期访问时间和构建数据模型所需的修订的总时间，确定开始构建数据模型的更新时间，更新时间早于开始构建数据模型的先前确定的时间；和

重新调度数据模型的构建以在较早的更新时间开始。

3.根据条款1所述的方法，进一步包括：

在开始构建数据模型的确定的时间之前，确定输入数据的尺寸已经减小；

基于输入数据的减小的尺寸和数据模型的定义，估计对于构建数据模型所需的修订的总时间，修订的总时间小于对于构建数据模型的先前估计的总时间；

基于用于数据模型的预期访问时间和对于构建数据模型所需的修订的总时间，确定开始构建数据模型的更新时间，更新时间晚于开始构建数据模型的先前确定的时间；和

重新调度数据模型的构建以在较晚的更新时间开始。

4.根据条款1所述的方法，进一步包括：

在开始构建数据模型的确定的时间之前，获得用于数据模型的更新的预期访问时间；

基于用于数据模型的更新的预期访问时间和对于构建数据模型所需的估计总时间，确定开始构建数据模型的更新时间；和

重新调度数据模型的构建以在更新的时间开始。

5.根据条款1所述的方法，其中，输入数据的尺寸基于用于数据模型的预期访问时间来确定。

6.根据条款1所述的方法，其中，基于历史记录确定预期访问时间。

7.根据条款1所述的方法，其中，基于历史记录来估计对于构建数据模型所需的总时间，所述历史记录包括：表示构建数据模型所花费的历史时间的数据。

8.根据条款7所述的方法，其中，基于历史记录来估计对于构建数据模型所需的总时间，所述历史记录包括：表示构建在结构上与数据模型相似的不同数据模型所花费的历史时间的数据，或当构建数据模型时的服务器容量。

9.根据条款7所述的方法，其中，数据模型的构建依赖于第二数据模型，并且其中估计对于构建数据模型所需的总时间包括估计构建第二数据模型所需的总时间。

10.根据条款1所述的方法，其中确定输入数据的尺寸包括：

确定输入数据的当前尺寸；和

估计在当前时间和未来时间之间要生成的输入数据的预期尺寸，

其中输入数据的尺寸基于输入数据的当前尺寸和要生成的输入数据的估计尺寸之和来确定。

11.根据条款10所述的方法，其中，基于先前每单位时间生成的输入数据的平均尺寸来确定要生成的输入数据的预期尺寸。

12.根据条款1所述的方法，进一步包括：

确定可用于构建数据模型的计算资源的量，

其中对于构建数据模型所需的总时间的估计进一步基于可用于构建数据模型的计算资源的量。

13.根据条款12所述的方法，其中确定可用计算资源的量包括基于历史记录估计在多个未来时间的每一个处可用的计算资源的相应量。

14.根据条款13所述的方法，包括：

基于历史记录，估计在多个未来时间的每一个处开始构建数据模型所需的相应总时间；和

基于在多个未来时间的每一个处开始构建数据模型所需的估计的相应总时间来确定开始构建数据模型的时间。

15.一种系统，包括：

与存储装置通信的处理设备，处理设备被配置为执行指令以使得所述系统：

标识要构建的数据模型，该数据模型与定义要在构建该数据模型中使用的输入数据的数据模型定义相关联；

确定输入数据的尺寸；

获得用于数据模型的预期访问时间；

基于输入数据的尺寸和数据模型的定义来估计对于构建数据模型所需的总时间；

基于用于数据模型的预期访问时间和构建数据模型所需的估计总时间来确定开始构建数据模型的时间；和

调度数据模型的构建以在确定的时间开始。

16.根据条款15所述的系统，其中，处理设备被配置为执行指令以使得所述系统：

在开始构建数据模型的确定的时间之前，确定输入数据的尺寸已经增加；

基于输入数据的增加的尺寸和数据模型的定义，估计对于构建数据模型所需的修订的总时间，修订的总时间大于对于构建数据模型的先前估计的总时间；

基于用于数据模型的预期访问时间和构建数据模型所需的修订的总时间，确定开始构建数据模型的更新时间，更新时间早于开始构建数据模型的先前确定的时间；和

重新调度数据模型的构建以在较早的更新时间开始。

17.根据条款15所述的系统，其中，处理设备被配置为执行指令以使得所述系统：

在开始构建数据模型的确定的时间之前，确定输入数据的尺寸已经减小；

基于输入数据的减小的尺寸和数据模型的定义，估计对于构建数据模型所需的修订的总时间，修订的总时间小于对于构建数据模型的先前估计的总时间；

基于用于数据模型的预期访问时间和对于构建数据模型所需的修订的总时间，确定开始构建数据模型的更新时间，更新时间晚于开始构建数据模型的先前确定的时间；和

重新调度数据模型的构建以在较晚的更新时间开始。

18.根据条款15所述的系统，其中，处理设备被配置为执行指令以使得所述系统：

在开始构建数据模型的确定的时间之前，获得用于数据模型的更新的预期访问时间；

基于用于数据模型的更新的预期访问时间和对于构建数据模型所需的估计总时间，确定开始构建数据模型的更新时间；和

重新调度数据模型的构建以在更新的时间开始。

19.根据条款15所述的系统，其中，基于历史记录来估计对于构建数据模型所需的总时间，所述历史记录包括：表示构建数据模型所花费的历史时间的数据；表示构建在结构上与数据模型相似的不同数据模型所花费的历史时间的数据，或当构建数据模型时的服务器容量。

20.根据条款15所述的系统，其中，数据模型的构建依赖于第二数据模型，并且其中估计对于构建数据模型所需的总时间包括估计构建第二数据模型所需的总时间。

21.根据条款15所述的系统，其中确定输入数据的尺寸包括：

确定输入数据的当前尺寸；和

估计在当前时间和未来时间之间要生成的输入数据的预期尺寸，

其中输入数据的尺寸基于输入数据的当前尺寸和要生成的输入数据的估计尺寸之和来确定。

22.根据条款15所述的系统，其中，处理设备被配置为执行指令以使得所述系统：

确定可用于构建数据模型的计算资源的量，

其中对于构建数据模型所需的总时间的估计进一步基于可用于构建数据模型的计算资源的量。

23.根据条款22所述的系统，其中，处理设备被配置为执行指令以使得所述系统为了确定可用计算资源的量：基于历史记录估计在多个未来时间的每一个处可用的计算资源的相应量。

24.根据条款23所述的系统，其中，处理设备被配置为执行指令以使得所述系统：

基于历史记录，估计在多个未来时间的每一个处开始构建数据模型所需的相应总时间；和

基于在多个未来时间的每一个处开始构建数据模型所需的估计的相应总时间来确定开始构建数据模型的时间。

25.一种其上存储有计算机可执行指令的计算机可读介质，其中所述指令当被系统的处理设备执行时，使得所述系统：

标识要构建的数据模型，该数据模型与定义要在构建该数据模型中使用的输入数据的数据模型定义相关联；

确定输入数据的尺寸；

获得用于数据模型的预期访问时间；

基于输入数据的尺寸和数据模型的定义来估计对于构建数据模型所需的总时间；

基于用于数据模型的预期访问时间和构建数据模型所需的估计总时间来确定开始构建数据模型的时间；和

调度数据模型的构建以在确定的时间开始。

Claims (15)

1.一种动态调度数据处理作业的计算机实现的方法，所述方法包括：

标识要构建的数据模型，所述数据模型与定义要在构建所述数据模型中使用的输入数据的数据模型定义相关联；

确定输入数据的尺寸；

获得用于数据模型的预期访问时间；

基于输入数据的尺寸和数据模型的定义来估计对于构建数据模型所需的总时间；

基于用于数据模型的预期访问时间和构建数据模型所需的估计总时间来确定开始构建数据模型的时间；和

调度数据模型的构建以在确定的时间开始。

2.根据权利要求1所述的方法，进一步包括：

在开始构建数据模型的确定的时间之前，确定输入数据的尺寸已经改变，所述改变是尺寸的增加或减小；

基于输入数据的尺寸改变和数据模型的定义，估计对于构建数据模型所需的修订的总时间，修订的总时间大于或小于对于构建数据模型的先前估计的总时间；

基于用于数据模型的预期访问时间和构建数据模型所需的修订的总时间，确定开始构建数据模型的更新时间，所述更新时间早于开始构建数据模型的先前确定的时间或晚于开始构建数据模型的先前确定的时间；和

重新调度数据模型的构建以在更新的时间开始。

3.根据任一前述权利要求所述的方法，进一步包括：

在开始构建数据模型的确定的时间之前，获得用于数据模型的更新的预期访问时间；

基于用于数据模型的更新的预期访问时间和对于构建数据模型所需的估计总时间，确定开始构建数据模型的更新时间；和

重新调度数据模型的构建以在更新的时间开始。

4.根据任一前述权利要求所述的方法，其中，输入数据的尺寸基于用于数据模型的预期访问时间来确定。

5.根据任一前述权利要求所述的方法，其中，基于历史记录确定预期访问时间。

6.根据任一前述权利要求所述的方法，其中，基于历史记录来估计对于构建数据模型所需的总时间，所述历史记录包括：表示构建数据模型所花费的历史时间的数据。

7.根据权利要求6所述的方法，其中：

基于历史记录来估计对于构建数据模型所需的总时间，所述历史记录包括：表示构建在结构上类似于数据模型的不同数据模型所花费的历史时间的数据，或者当构建数据模型时的服务器容量；或者

数据模型的构建依赖于第二数据模型，并且其中估计对于构建数据模型所需的总时间包括估计构建第二数据模型所需的总时间。

8.根据任一前述权利要求所述的方法，其中确定输入数据的尺寸包括：

确定输入数据的当前尺寸；和

估计在当前时间和未来时间之间要生成的输入数据的预期尺寸，

其中输入数据的尺寸基于输入数据的当前尺寸和要生成的输入数据的估计尺寸之和来确定。

9.根据权利要求8所述的方法，其中，基于先前每单位时间生成的输入数据的平均尺寸来确定要生成的输入数据的预期尺寸。

10.根据任一前述权利要求所述的方法，进一步包括：

确定可用于构建数据模型的计算资源的量，

其中对于构建数据模型所需的总时间的估计进一步基于可用于构建数据模型的计算资源的量。

11.根据权利要求10所述的方法，其中确定可用计算资源的量包括基于历史记录估计在多个未来时间的每一个处可用的计算资源的相应量。

12.根据权利要求11所述的方法，包括：

基于历史记录，估计在多个未来时间的每一个处开始构建数据模型所需的相应总时间；和

基于在多个未来时间的每一个处开始构建数据模型所需的估计的相应总时间来确定开始构建数据模型的时间。

13.根据任一前述权利要求所述的方法，其中所述数据处理作业是多个调度的数据处理作业之一，第一数据处理作业不同于要用在构建数据模型中的输入数据中的第二数据处理作业，其中对于为第一数据处理作业构建数据模型所需的总时间不同于对于为第二数据处理作业构建数据模型所需的总时间，所述方法包括动态改变开始为第一数据处理作业和第二数据处理作业中的每一个构建数据模型的时间，以便补偿第一数据处理作业和第二数据处理作业中的每一个的输入数据的不同尺寸。

14.根据权利要求13所述的方法，其中每个数据处理作业随时间按顺序作用。

15.一种系统，包括：

与存储装置通信的处理设备，处理设备被配置为执行指令以使得所述系统实行任一前述权利要求的方法。

Images