ETL+Q自动扩展框架设计

数据仓库提取、转换、加载+Q自动扩展框架

1 引言

ETL工具是用于从一个或多个源系统向数据仓库填充最新、干净记录的专用软件。
目前大多数ETL工具将此类操作组织为工作流。在逻辑层面，E（抽取）可视为从源系统捕获数据流，通常涉及多个高频率吞吐量的源。接着，T代表数据的转换和数据清洗，即修改数据以使其符合分析模式。L（加载）表示将数据加载到数据仓库中，供后续查询和分析使用。在实现此类系统时，除了需要完成上述所有步骤外，用户还需关注ETL+Q（提取、转换、加载与查询）在此特定场景下可能带来的可扩展性要求。

在定义提取、转换、加载+查询（ETL+Q）时，用户必须考虑数据源的存在，以及数据从何处以何种方式被抽取并进行转换（例如补全、清洗、验证），随后加载到数据仓库中，最后是数据仓库模式。这些步骤中的每一步都需要不同的处理能力、资源和数据处理方式。然而，在某些应用场景中（例如电信、能源分配或股票市场的近实时监控），提取、转换、加载对性能要求较高。大多数情况下，这是因为数据量过大，单个抽取、转换、加载或查询节点已无法满足需求。因此，必须增加更多节点来从数据源抽取数据，并需制定相应的抽取策略[例如轮询（RR）或按需]。其他阶段，即转换和加载，也必须进行相应的扩展。

抽取后，数据必须重新定向并分发到可用的转换节点上。由于转换涉及繁重的任务（比抽取更重），因此需要多个节点以确保可接受的执行/转换时间。在数据完成转换并准备加载后，必须安排加载周期（例如每晚、每小时、每分钟）以及加载时间控制（例如最大加载时间 = 5 小时）。这意味着在转换和加载过程之间，数据必须存储在某个位置。

关于数据仓库，在某些应用场景中，全部数据无法容纳在单个节点中，即使能够容纳，也无法在可接受的时间范围内执行查询。因此，需要多个数据仓库节点，并采用特定的模式来实现数据的分发、复制，最终在可接受的时间范围内完成查询。本文研究如何在大数据仓库中提供具有高数据速率输入的提取、转换、加载+Q可扩展性。我们提出了一套机制和算法，用于并行化和扩展整个提取、转换、加载+Q过程的每个部分，这些机制和算法随后将被纳入一个自动扩展（横向扩展和收缩）的提取、转换、加载+Q框架中。

所展示的结果证明，所提出的机制能够在需要时进行横向扩展。

2 相关工作

我们的框架通过自动扩展处理管道的每个部分来优化提取、转换、加载。
这些是与优化和扩展提取、转换、加载相关的一些前期工作。

为了提高ETL过程的效率，Simitsis 等人 (2005b, 2005a) 提出了基于启发式算法的搜索方法，通过将问题建模为搜索空间图来决定哪种执行方式更高效，从而最小化ETL执行成本。图是通过对关系代数操作符进行分解而生成的。启发式规则基于每个状态被访问的次数来创建。

Albrecht 和 Naumann (2009) 研究了如何通过实现一组基本的管理操作符 （如“MATCH”、“MERGE”、“INVERT”、“SEARCH”、“DEPLOY”） 来管理大型ETL流程。该框架是基于Web的。用户通过拖放可用的过滤器来创建ETL流，然后该框架使用一组优化算法确定ETL的最佳执行顺序。

Karagiannis 等人 (2013) 讨论了调度 ETL活动（也称为转换、任务、操作）执行的问题，旨在最小化 ETL执行时间 和分配的内存。该论文研究了四种调度策略（轮询、最小成本预测、最小内存预测和混合策略）对不同流程结构和配置的影响。结果表明，使用不同的调度策略可以在内存消耗和执行时间方面提高 ETL 性能。

Wang 和 Guo (2011) 提出了一种基于多智能体系统 (MAS) 数据划分技术的分布式ETL引擎架构。他们还研究了对大规模数据流进行水平和垂直划分的方法。
该系统将工作流划分为多个子工作流，由智能体进行并行执行，同时添加一个分割节点以分发任务。每个子工作流由一个智能体执行，从而使多个智能体能够协同完成工作。最后，通过另一个额外的节点——合并器，将所有结果进行合并。

Liu 等人 (2012) 描述了一种使用 Map‐Reduce 实现可扩展性的提取、转换、加载编程框架。数据源和目标维度需要进行配置和部署。该框架内置支持星型模式和雪花模式。用户必须使用框架构造器实现并行的 ETL 程序。他们采用了基于 Python 的 ETL 编程框架 pygrametl (Thomsen 和 Bach Pedersen, 2009)。流程包括两个阶段：维度处理和事实处理。数据从分布式文件系统 (DFS) 上的数据源（文件）读取，由框架实例进行转换并处理为维度值和事实，再将数据物化到数据仓库中。该框架要求用户声明（编码）目标表和转换函数。然后采用主/从架构（一个主节点，多个工作节点），每个工作节点并行运行任务。主节点负责分发数据、调度任务并监控工作节点。

刘（2012）提出了一种在Map‐Reduce之上构建ETL流程的工具，以在普通计算机上并行化提取、转换、加载操作。ETLMR包含多项创新性贡献。它支持高级别的ETL专用维度结构，用于处理星型模式、雪花模式以及数据密集型维度。由于采用了Map‐Reduce，它能够自动扩展到更多节点（无需修改ETL流程），同时还能提供自动数据节点间同步（即使是雪花模式等复杂维度结构）。除了可扩展性之外，Map‐Reduce 还为 ETLMR 提供了高度的容错性。ETLMR 没有自身的数据存储（注意：离线维度存储仅用于加速目的），而是一个适用于并行处理大规模数据的 ETL 工具。ETLMR 提供一个配置文件，用于声明维度、事实、用户自定义函数（UDF）以及其他运行时参数。

西米蒂斯等（2010）研究了实现实时ETL的数据流分区问题。该方法通过考虑多种技术，在数据新鲜度、可恢复性和容错性等方面进行权衡来做出选择。在此方法中，分区可以基于轮询、哈希（HS）、范围（RG）、随机、取模、复制以及其他方式（瓦西里亚迪斯和西米蒂斯，2009）。

Pentaho数据集成（PDI）（Pentaho，2014）是一种ETL（图形化）设计工具，并提供Hadoop支持。它包含一个数据集成（ETL）引擎以及图形用户界面应用，允许用户定义数据集成作业和转换。它支持在单节点计算机、云或集群上进行部署。内部支持通过套接字、Web服务（例如，SOAP、XML）等方式与其他系统进行连接/集成。

2.1 分析

上述研究通过优化数据访问、重排序操作符执行以及尽可能地管理可用计算资源，来专注于每个独立ETL过程的优化。一些方法未使用并行性，这限制了其扩展能力。此类方法可以很容易地与我们所提出的框架结合使用。为了在高要求环境中保证充分的ETL和查询处理服务，系统必须能够自动扩展。一种直接的可扩展性方法是采用Map‐Reduce来实现整个ETL过程，正如部分相关研究中所提出的那样。然而，Map‐Reduce模型并未提供：

• 自动实时性能监控和扩展机制，必须手动添加新节点
• 由于使用分布式文件系统和Map‐Reduce范式，导致网络流量增加
• 整个ETL过程必须使用Map‐Reduce编程模型进行编码，增加了复杂性和潜在的性能限制
• 效率取决于使用操作符的实现方法，特别是在需要数据交换时。

所提出的框架通过以下方式提供了更好的可用性和性能：

• 提供基于监控的自动扩展机制
• 允许独立地扩展提取、转换、加载+Q流程的每个零件
• 允许使用任何编程语言定义提取、转换、加载，只要为该框架提供了连接器
• 数据（维度表或所有表）可以在数据仓库节点之间复制，避免通过网络进行大量数据交换以合并结果。

3 架构

在本节中，我们介绍所提出的架构AScale的主要组件。图1展示了其主要组件：

• 组件（1）到（7），除了（5）之外，均为提取、转换、加载与查询（ETL+Q）流程。“自动扩展器”（13）是负责性能监控并在必要时对系统进行扩展的组件。
• “配置文件”（12）表示保存所有用户配置的位置。
• ‘通用数据仓库管理器’（11）利用用户提供的配置和可用的‘配置API’ （10）来设置系统，使其根据所需的参数和选定的算法执行。‘通用数据仓库管理器’（11）还设置了自动可扩展性的配置参数（13）以及‘调度器’（14）将应用的策略。
• ‘配置API’（10）是一种访问接口，允许用户通过（11）自动或手动配置所提出的通用数据仓库架构的每个零件。
• “调度器”（14）负责在组件之间应用数据传输策略。
• “就绪节点区域”（9）表示未被使用的节点。这些节点可以添加到系统的任何部分（2）至（6）以进行横向扩展，从而在需要的地方提升性能，或通过纵向收缩移除节点，以节省可在其他地方使用的资源。

所有这些组件在设置为相互交互时，可为提取、转换、加载+Q以及数据仓库流程提供自动可扩展性，用户无需担心其可扩展性或管理问题。

用户无需编写整个ETL管道，而只需专注于编写转换和数据仓库模式（图1中灰色高亮部分），其余可扩展性细节由AScale自动处理。此外，用户还可以选择任意数据仓库引擎来存储数据（例如，关系型数据仓库、列式存储、非SQL、Map‐Reduce架构）。

4 可扩展性机制

在本节中，我们介绍 AScale（提取、转换、加载+Q 自动扩展框架）的每个零件如何单独扩展以获得必要的性能。

图2 描述了提取、转换、加载扩展的每个零件，包括：
1 数据源1的增加以及数据源速率的提高意味着数据量的增加，从而需要对所提出的框架的其他部分进行扩展。每个数据源1都有一个关联的提取频率（例如，每分钟一次）。2 “提取与数据分发节点”将抽取的（原始数据）转发和/或复制到转换节点。通过监控提取时间来检测2中的扩展需求。如果提取时间超过最大配置限制，或者在下一次提取时刻（例如，每分钟）之前数据提取尚未完成，则需要增加更多的数据分发节点2。

3 转换节点处理用户编写的数据转换。这些节点包含一个缓冲队列，用于监控数据流入。如果队列大小超过某个限制，将通过在另一个节点中复制转换代码来扩展转换节点。4 数据缓冲区用于存储已转换的数据，可以位于内存和/或磁盘中。
根据内存监控参数对节点进行扩展。如果在任何时候内存使用达到最大配置可用内存，则必须添加一个新节点。

5个数据交换机负责从“数据”中进行数据分发（弹出/提取） 缓冲区并将数据放置到正确的节点中以加载到数据仓库。每个数据交换节点配置为支持最大数据速率（例如，100 兆字节/秒）。如果在定义的时间窗口内超过或达到该限制，则需要更多的数据交换节点。

6 数据仓库可以是单个节点，也可以通过多个节点并行化。
数据仓库的可扩展性基于两个参数：加载时间和查询响应时间。如果数据仓库节点加载数据的时间超过配置的最大时间，则会添加更多节点并对数据进行重新分配。如果查询的平均执行时间超过期望的响应时间，则也必须增加数据仓库节点。

最后，AScale中引入的另一种可扩展性机制是全局期望ETL处理时间。可以为整个ETL过程定义一个全局时间，如果超过了该全局时间，则最接近其扩展限制的AScale管道组件将进行扩容。

5 配置参数

根据用户提供的配置参数，系统会自动进行扩展。所有组件协同工作，在提取、转换、加载+Q流程的每个阶段需要更高效率时，为提取、转换、加载+Q提供自动可扩展性。相反，当某个阶段不再需要过多资源时，系统会自动缩减规模。图2中所示各个零件实现自动可扩展性的主要配置参数涉及：
1 数据提取的源位置配置；提取频率、最大抽取持续时间。
2 分发算法，使用轮询算法由转换节点分发数据。
3 需要应用的转换。用户可以在ASclae框架中编程实现转换，使用（导入）提供的Java库，或使用任何其他语言通过提供的API进行连接编程。
4 数据缓冲区大小（内存和磁盘）。
5 最大支持分发速率。

6 加载频率、最大加载持续时间、数据仓库模式（由用户创建）、事实表和维度表的定义（即复制参数）。
7 最大期望的查询执行时间参数。如果查询所花费的时间超过配置的数据仓库节点将进行扩展。

6 扩展

在本节中，我们解释了AScale用于监控、检测和扩展每个处理模块的机制及配置参数。
在介绍了一些最重要的配置参数之后，我们将详细说明扩展决策的制定方式。为此，我们解释了所实现的算法，并说明了它们的工作原理。最后，针对AScale的每个部分，我们明确了用于在不同AScale模块之间共享和传输数据的数据分布策略。

6.1 为自动可扩展性配置AScale

为了克服性能限制，提取、转换、加载+Q 过程的每个部分都必须能够扩展。我们可能会有许多数据源提供数据，在处理的每个阶段，单个计算节点可能无法处理所有的数据提取、转换或 AScale 管道中的任何其他部分。

在本节中，我们描述了AScale用于独立且按需扩展每个模块的可扩展性配置参数。
图3 显示了每个可能需要扩展以提供所需性能的 AScale 模块。

表1 数据提取的API配置

行号	代码
1	extractSetDataSourceLog(
2	"source1" //源ID
3	{“logA”, “logB”}, //log ID
4	{“\*/10 \*\*\*\*\*”, “\*/10 \* \* \* \* \*”}//提取频率
5	{“5s”, “5s”}); //最大提取时间

提取节点2 根据提取频率（表1 第4行）和最大提取时间（表1 第5行）来监控，以确定扩展需求。
如果超过最大提取时间，则会添加更多抽取节点。如果未定义最大提取时间， 则当提取时间超过频率周期持续时间时，将从就绪节点区域9中添加更多节点2。

表2 API配置以配置转换的最大队列大小

行号	代码
1	transformSetMaxSize(
2	"16GB" //最大队列大小
3	"5GB"); //用于扩展检测的最大限制大小

转换节点3 包含一个具有最大负载大小的数据队列。表2 第2行指定了最大队列大小，第3行指定了用于扩展检测的最大限制大小。
入站数据进入队列，然后由转换节点（由数据仓库开发人员编程的转换操作）提取和转换数据。如果在任何时候队列填充超过某个配置限制，则表明入站数据速率高于输出转换数据速率，因此必须添加更多的转换节点。
向上扩展时，会添加一个新节点，并将其他节点中存在的完整转换过程复制到新节点。

表3 API配置用于指定数据缓冲模块存储大小

行号	代码
1	dataBufferSetSize(
2	"dataBuffer1",
3	"5GB", //最大缓冲区内存大小
4	"10GB", //限制缓冲区内存大小
5	"500GB", //最大值缓冲磁盘大小
6	250GB //限制缓冲区磁盘大小
7	"D:"); //数据缓冲区磁盘位置

数据缓冲节点 4 将保存转换后的数据，直到下一次数据仓库加载时刻。

扩展决策基于多个参数：最大允许内存缓冲区大小；最大允许数据写入速度； 以及最大允许磁盘大小。表3说明了这些参数。
如果内存使用量达到最大配置数据缓冲区内存大小，则数据将被交换到磁盘。
即使如此，若内存仍完全填满并达到最大内存大小，则必须添加更多数据缓冲节点。此外，如果磁盘空间达到配置限制，也必须添加更多数据缓冲节点。

表4 数据交换支持的数据速率的API配置

行号	代码
1	dataSwitchSetDataRate(
2	"dataSwitch1" //数据交换 ID 名称
3	"80000l/ s", //最大支持数据速率
4	"2m"); //触发横向扩展的最大延迟时间

数据交换节点 5 在数据仓库节点之间分发和复制数据。这些节点使用基于调度器的提取策略从数据缓冲区 4 中提取数据，并将其加载到数据仓库节点 6 中。然而，每个数据交换节点可处理的数据量存在限制。表4 第3行中的命令行用于指定每秒最大支持的数据速率（以行数为单位）。第4行表示触发横向扩展机制前的最大允许延迟时间。如果在配置的时间段内，数据交换节点始终以最大配置数据速率运行，则意味着这些节点已按配置达到其最大容量，必须进行横向扩展。

表5 数据仓库抽取频率的API配置

行号	代码
1	dataWarehouseSetLoad(
2	"\* 30 1 \* \* \*" //加载频率
3	"5小时", //最大加载时间
4	"100MB"); //最大批处理文件

数据仓库节点 6 在固定的时间点对特定时间窗口内的数据进行加载。表5 第2行使用Unix cronjob 时间格式表示加载频率，第3行表示最大允许加载时间。如果超过最大允许加载时间，则需要增加更多数据仓库节点。另一个数据仓库扩展场景涉及查询执行时间。如果查询输出结果所需时间超过配置限制的最大值，则数据仓库节点 6 必须扩展以提供更高的性能。

表6 最大查询执行时间API配置

行号	代码
1	querySetMaxDWQueryExecutionTime(
2	value); //数据仓库查询的最大执行时间
3
4	查询集最大D-DW查询执行时间(
5	值）；// D-DW 查询的最大执行时间

表6 显示了用于配置最大查询执行时间的 API。输入参数包括期望的最大执行时间，单位为秒 (s) 或分钟 (m)。

7 可扩展性决策算法

本节定义了可扩展性决策方法以及使AScale能够自动对提议的流水线的每个零件进行横向扩展和纵向收缩的算法。

7.1 提取和数据分发器

图4描述了用于扩展的算法。根据现有数据源的数量和不断增长的数据生成速率，最终需要对抽取节点进行扩展。是否增加更多的“提取与数据分发节点”取决于当前节点数量是否能够在配置的最大提取时间限制内以正确的频率完成数据的提取和处理。例如，如果提取频率设定为每5分钟一次，提取持续时间为10秒，则每次提取时，“提取与数据分发节点”在提取全部数据时所花费的时间不能超过10秒，否则就需要进行横向扩展。如果没有配置最大提取持续时间，则提取过程必须在下一次提取时刻之前完成，该时刻由提取频率参数指定。

图5描述了用于纵向收缩的算法。为了节省资源并实现资源的再利用，数据提取节点可以进行纵向收缩。该决策基于上次执行时间做出。如果至少两个或更多节点的上次执行时间均小于最大提取时间的一半减去配置的变化参数(X)，则其中一个节点将被设置为待机（作为待命节点）或被移除，其余节点将接管其工作。

7.2 转换

转换过程至关重要。如果转换速度较慢，则可能无法以当前数据速率进行数据提取，因此在需要时将无法获得用于加载和查询的信息。

转换节点具有一个输入队列，如图6所示。在图6中，我们展示了用于确定何时扩展转换阶段的转换队列。如果该队列由于实际的转换节点无法处理所有到达的数据（即当前流入数据速率大于转换输出数据速率）而达到开发人员配置的极限大小，则需要进行横向扩展。图6描述了用于扩展的算法。

图7描述了用于纵向收缩的算法。如果在某一时刻，至少有两个节点的队列大小小于极限大小的一半，则将其中一个节点设置为待机（作为就绪节点）或移除。

7.3 数据缓冲区

数据缓冲节点根据内存大小、数据从内存交换到磁盘的速度以及用于存储数据的可用存储空间进行横向扩展。当可用内存队列大小超过某一极限时，数据开始被交换到磁盘，以使内存使用量降至极限大小以下。即使如此，若数据缓冲区内存达到最大内存限制大小时，数据缓冲区将进行扩展。这意味着输入数据速率（进入内存存储）无法足够快地交换到磁盘存储，因此需要更多节点。

如果磁盘空间超过某个配置大小而变满，数据缓冲区也会设置为横向扩展。

图8描述了用于扩展数据缓冲节点的算法。数据缓冲区也可以进行纵向收缩。在这种情况下，如果任何一个数据缓冲区的数据可以容纳在另一个节点的数据缓冲区内，系统将执行此操作。

7.4 数据交换

数据交换节点根据配置的最大支持数据速率进行扩展。该数据速率在超过配置的时间窗口后无法达到或超过。如果数据速率在某个配置的时间窗口内高于配置限制，数据交换节点将执行横向扩展。图9描述了用于扩展数据交换节点的算法。数据交换机也可以纵向收缩。在这种情况下，如果至少两个节点的数据速率低于配置最大值的一半减去一个（Z）配置的变化参数，系统将允许其纵向收缩。

7.5 数据仓库

每次加载过程或任何查询执行后，都会检测数据仓库可扩展性需求。数据仓库加载过程每次启动时都有配置限制时间长度需要遵守。如果超过该时间，则数据仓库必须进行横向扩展。同样，查询也有最大执行时间。如果查询执行时间超过限制，则数据仓库必须进行横向扩展。横向扩展的节点数量基于之前的节点数量和执行时间，假设具有线性可扩展性来确定。

$$
\text{所需节点数} = \left( \frac{\text{loadTime}}{\text{targetTime}} \right) \times n
$$

在此方程中，“loadTime”表示上次记录的加载时间，“targetTime”表示期望的目标加载时间，“n”表示当前节点数量。

图10描述了当最大加载时间被超过时用于扩展数据仓库的算法。

数据仓库可扩展性不仅取决于加载和集成速度要求，还取决于最大查询执行时间。查询执行后，如果查询时间超过配置的最大值，则设置数据仓库进行横向扩展。图11描述了基于查询执行时间用于扩展数据仓库的算法。

当且仅当平均查询执行时间和平均加载时间满足条件(1)和(2)时（其中n表示节点数量），才会对数据仓库节点进行纵向收缩：

$$
(n - 1) \times \text{avgQueryTime} \leq \text{desireQueryTime} \quad (1)
$$

$$
(n - 1) \times \text{avgLoadTime} \leq \text{maxLoadTime} \quad (2)
$$

每次数据仓库进行横向扩展或缩减时，节点内的数据都需要重新平衡。用于横向扩展的默认重新平衡过程基于以下阶段：从数据仓库节点提取并复制数据；将提取的信息加载到新节点中（数据被提取并加载到可用节点上，就像处理新数据一样）。
数据仓库的横向扩展和纵向收缩都需要管理员批准，因为此过程可能导致长时间离线。

7.6 全局ETL可扩展性

除了为 ETL+Q 管道的每个部分定义部分限制外，配置所需的全局ETL处理时间也很有用。在这种情况下，AScale 将选择对性能较慢的部分进行横向扩展。

图12通过一个示例解释了ET和L的扩展。假设ET和L的当前执行时间分别为2小时和10小时，期望的执行时间为5小时。基于这些时间，ET的目标时间为0.83小时，L的目标时间为4.17小时。然后通过应用以下公式线性估算所需的节点数量：

$$
\text{所需节点数} = \left( \frac{\text{currentTime}}{\text{targetTime}} \right) \times n
$$

其中“currentTime”是当前执行时间，“targetTime”是期望的执行时间，“n”表示当前节点数量。对于该示例，计算结果为：ET需要 $2 ÷ 0.83 × 2 = 4.82$，对应取整为5个节点；而L需要 $10 ÷ 4.17 × 2 = 4.80$，对应取整为5个节点。注意，在ET中，额外的节点仅添加到E过程，随后T过程根据入站数据队列监控进行扩展，以跟上提取速率。

另一种选择是同时配置两种时间约束限制：为整个ETL过程设置全局时间约束，同时为各个零件设置局部约束。在这种情况下，AScale可以利用局部约束来决定在何处进行扩展。

8 实验设置

在本节中，我们描述了实验设置中所使用的测试平台、硬件、软件以及ETL操作。
为了模拟数据仓库以及所有ETL流程，构建了一个实验设置。选择使用TPC‐H数据作为源数据日志，SSB作为数据仓库模式和查询，目的是重用研究小组的相关工作，例如费雷拉和富尔塔多（2013）以及马丁斯等（2011），这些工作已经开发了部分框架管道。这一选择还使我们能够更好地控制数据转换以及相应的暂存区数据量和数据同步，从而以较低的复杂性构建系统，更便于测试所提出的 AScale概念。

用于抽取的数据源日志： 模拟日志的结构与TPC‐H生成的数据日志结构相同，包含表示以下各表的日志：零件、供应商、国家、地区、零件供应。对于“订单明细”和“订单”表，它们被合并到单个日志中，其结构如下：该日志由一组“订单”行组成，且针对每个订单，日志中包含相应的关联订单明细行作为该订单的后续行。
数据提取是基于每个订单的开始和结束（包括相应的项目）进行的，以确保数据的完整性和一致性。

数据转换： 从TPC‐H日志文件中提取数据后，将对其进行转换。TPC‐H的表，零件、供应商、国家、地区、零件供应也保留在使用PostgreSQL数据库的转换节点（暂存区）中。存储的数据将进行转换，以重新创建SSB模式。
应用了额外的转换操作：姓名被拆分并重组为姓和名字；每个名字的首字母大写，其余字母小写；地址通过使用内存中的翻译查找表将关键词（例如street）转换为缩写词，进行清洗和转换；邮政编码通过内存中的映射表将每个城市关联对应的邮政编码后添加（拼接）；电话号码根据邮政地址代码被转换为每三位一组的数字，并添加国家和城市代码；类别被转换/写成完整文本（无缩写）；美元金额被转换为欧元；尺寸和重量被转换为标准化国际单位制。这些转换操作产生的数据输出随后被存储，ready to load。

数据仓库： 该数据仓库具有与SSB基准相同的基线结构。

8.1 硬件和软件

实验测试使用了12台计算机，称为节点，具有以下特性：Intel Core i5‐5300U处理器 （3M缓存，最高3.40 GHz）；16 GB DDR3内存；西部数据1TB硬盘 7500转/分钟；以太网连接 1 Gbit/秒；SMC SMCOST16交换机，48个以太网端口，1 Gbit/秒。
安装/使用的软件。在实验评估之前，12个节点被格式化并安装了以下软件： Windows 7企业版64位；Java JDK 8；Netbeans 8.0.2 用于Microsoft Windows (X64)的Oracle Database 11g第1版；用于动态数据仓库的MySQL 5.6.23；用于在转换过程中进行查找的PostgreSQL 9.4；作为复杂事件处理引擎的Esper 5.1.0 for Java； TPC‐H基准数据集；SSB基准，代表数据仓库模式和查询。
在本次实验评估中，我们假设每个节点对应一台物理机。然而，由于可用资源有限，创建了一些虚拟节点，并对其他节点的资源进行了重新分配和复用，以确保AScale管道处理不受影响。

9 典型数据仓库场景

在本节中，我们评估了AScale在一个场景下的表现：由于日志大小和资源有限，如果不应用可扩展性，数据加载将耗时过长。我们从仅使用两个节点（两台物理机）开始，其中一个节点用于处理抽取和转换，另一个节点用于存放数据仓库。
AScale被设置为监控系统，并在需要时进行扩展。

数据仅在预定义的时间段内（例如夜间）从源系统中抽取、转换和加载，以便在第二天可供分析使用。抽取、转换和加载的总时间最长不得超过9小时（例如 从凌晨0点到早上9点）。AScale 配置为每24小时进行一次抽取，最大抽取持续时间为4小时；转换队列的极限大小为10 GB；数据仓库加载配置为每24小时执行一次，最大持续时间为9小时。

图13中的实验结果展示了使用两个节点（两台物理机）的AScale ETL总时间，其中一个节点用于抽取、转换、数据缓冲区和数据交换[图13(a)], ，另一个节点用于数据仓库[图13(b)]。在日志大小达到10 GB时，ETL过程可以在期望的时间窗口内完成。然而，当增加到50 GB时，9小时已不足以完成完整的ETL过程。在这种情况下，使用一个节点的数据仓库加载过程（加载、更新索引、更新视图）（平均加载时间873分钟）和两个节点（平均加载时间483分钟）均超过了期望的时间窗口。当扩展到3个节点，即增加另一个数据仓库节点[图13(b)],时，ETL过程重新回到期望的时间范围内。

10 近实时和最小停机时间场景

在本节中，我们评估所提出的框架在近实时场景以及需要最小化停机时间的场景下的横向扩展和纵向收缩能力。近实时场景要求数据始终保持最新并可供查询 （即数据新鲜度）。为了保证这一点，有必要在预定义的极短时间窗口内集成新数据。
场景设置如下：E（提取）和 L（加载）设置为每 2 秒执行一次；T（转换） 配置了最大队列大小为 500 兆字节；加载过程以最大 100 兆字节的批处理方式进行。ETL 过程最多允许耗时 3 秒。

图14和图15显示了AScale在数据速率分别增加或减少时自动进行扩展和缩容，以实现配置的近实时ETL时间界限。X轴表示数据速率，范围从每秒10,000行到每秒500,000行；Y轴表示以秒为单位的ETL时间；系统目标设定为在3秒内完成ETL过程；图表展示了AScale各个部分的扩展和缩容情况，通过在必要时增加或移除节点实现；总共逐步使用/移除了7个数据源，每个数据源最大平均提供70,000行/秒； AScale总共使用了12个节点来实现配置的时间界限。
图14中的横向扩展结果表明，随着数据速率的增加以及ETL管道的某些部分出现过载，通过在AScale框架的每个部分使用所有提议的监控机制，各个模块能够在需要的位置和时间进行扩展，以提供更高的性能。
纵向收缩 结果如图15所示，显示了当前节点数量不再需要以确保所需性能的时刻，从而移除部分节点（即设置为待机状态的就绪节点，供其他零件使用）。
接下来的小节详细说明了在近实时场景中，提取、转换、加载和查询的每个部分如何实现横向扩展。

10.1 数据抽取的可扩展性

考虑到生成高频率数据的数据源以及用于抽取所生成数据的抽取节点，当数据流过高时，单个数据节点无法处理所有入站数据。在本节中，我们研究抽取节点如何扩展以应对不同的数据速率，采用的数据设置与之前使用的类似上一节中，最大允许提取时间设置为1秒（maxextractionTime < maxdesiredExtractionTime）； 提取频率设置为每3秒一次（maxextractionTime < 提取频率）。

图16展示了近实时环境下的抽取节点自动横向扩展能力。左侧Y轴表示平均提取时间（秒），右侧Y轴表示使用的节点数量；X轴表示数据速率；黑线表示提取时间；灰线表示随着横向扩展的节点数量。每当提取时间超过配置的1秒阈值限制时，系统会自动从就绪节点池中添加一个新节点。新增节点后，更多节点将用于从相同数量的数据源中提取数据，从而提升抽取性能。

10.2 转换可扩展性

在提取、转换、加载过程中，数据被提取后将进行转换。由于此过程可能计算量较大，因此有必要扩展转换节点，以确保所有数据都能及时处理而不会延迟。系统会监控数据流入转换队列，一旦检测到队列的使用量超过某个预设阈值（即 Rateextract ≥ Ratetransform），AScale 将对转换过程进行扩展。
转换节点的横向扩展机制被设置为：在将数据交换到磁盘之前，队列内存大小的最大值限制为5 GB，触发扩展机制的限制为500 MB（对应10万行）。图17显示了当队列大小超过配置限制时新增的转换节点。Y轴表示队列大小的平均值（以行数为单位），X轴表示数据以每秒行数表示的速率。每个绘制的条形代表平均转换队列大小（最多4个节点）。
如图17所示，一旦数据速率达到80,000行/秒，AScale检测到队列过载（队列大小超过100,000行），并触发添加一个新节点。在120,000行/秒的条形中可以看到新增的节点，此时两个队列使系统能够满意地处理该数据速率。随后，当数据速率达到200,000行/秒时，最大队列大小再次达到，触发再增加一个节点。在 240,000行/秒的条形中可以看出横向扩展，此时三个队列再次能够处理增加的负载。如图17所示，当数据速率分别达到320,000行/秒和440,000行/秒时，又相继添加了第四和第五个节点以实现进一步的横向扩展。

图17 ‘放大框A’ 展示了当转换节点的队列大小超过配置限制时所发生情况的细节。一旦检测到过载，就会添加一个新的转换节点。新节点大约需要 1 分钟才能准备就绪（参见放大框A），该延迟对应于复制/同步节点及其相应暂存区所需的时间。在节点完全运行后，数据将使用最小重命名工作（LWR）算法进行分发，从而使新节点的队列平衡所有节点的大小。

10.3 数据缓冲节点

数据缓冲节点用于保存已转换的数据，直到其被加载到数据仓库中。在此实验中，数据缓冲区的配置如下：我们仅考虑数据生成/生产者，没有数据‘消费者’，因此缓冲区必须保存所有入站数据；生成数据速率设置为每秒 1,500,000 行（即转换输出数据速率），使得磁盘速度无法足够快地交换所有数据，导致内存持续增加直至达到最大值；可用内存存储设置为 10 GB；内存存储在数据交换到磁盘前的限制设置为 5 GB；可用磁盘存储为 1 TB。
当达到限制内存大小（5 GB）时，数据开始被交换到磁盘中。然而，由于磁盘速度无法处理所有入站数据速率，内存达到最大极限大小（10 GB）。此时会添加一个新的数据缓冲区节点。新节点添加后，使用LWR分发数据，导致新添加节点的队列增长更快。一段时间后，每个数据缓冲区中的数据量恢复到正常水平。

图18展示了一种极端情况，即数据从内存写入磁盘（交换空间）的速度不够快。这种情况导致了数据缓冲区节点的横向扩展。图18中显示数据队列大小持续增加直至达到“限制内存大小”（5 GB），此时数据开始被交换到磁盘以释放内存空间。然而，由于数据速率过高，内存使用量继续上升直至达到“最大内存大小”。一旦内存达到“最大内存大小”，系统将添加另一个节点，并由两个节点共同分发数据。在图18中，我们还展示了第二个节点的数据内存队列逐渐增加，并再次发生交换过程。但由于此时有两个节点共同处理入站数据速率，数据交换速度能够及时释放内存。

10.4 数据仓库加载和查询可扩展性

在本节中，我们测试数据仓库可扩展性，当加载过程耗时过长，或查询执行时间超过配置的响应时间界限时，将触发数据仓库可扩展性。

为了测试加载可扩展性，我们创建了以下设置：加载数据来自批处理文件，每个文件大小约为100兆字节；最大允许加载时间设置为60秒；每次添加一个数据仓库节点时，我们显示迁移到新节点的数据大小以及重新平衡数据所需的秒数；所有加载和再平衡时间均包括预加载任务（即删除所有索引和视图）和后加载任务（即构建所有索引和视图）的执行时间。

加载可扩展性： 图19中的实验结果展示了当要加载的数据大小增加时，数据仓库的扩展情况，以及随之而来的加载时间超过预定义界限的情况：左侧Y轴表示平均加载时间秒；右侧Y轴显示数据仓库节点数量；X轴表示以兆字节为单位的数据批大小；位于Y轴= 60秒处的水平条表示最大配置加载时间；在每次横向扩展时刻均有注释，标明数据重新平衡大小及执行时间；黑色绘制线表示平均加载时间；灰色绘制线表示数据仓库节点数量。
图19中的结果展示了随着数据大小增加，加载性能如何下降，以及添加新节点后性能如何提升。添加新节点后，性能得到改善，达到配置的最大加载限制。

查询可扩展性：在运行查询时，如果超过了最大期望查询执行时间，数据仓库将进行横向扩展，以提供更好的查询执行性能。为测试AScale查询可扩展性，考虑了以下工作负载：

• 工作负载1（WL 1）： 总大小为50 GB，执行随机选择的Q1.1、Q2.1、Q3.1、 Q4.1，每查询期望执行时间：1分钟（60秒）。
• 工作负载2 (WL 2) – 与工作负载1相同，但使用1到8个并发会话。

工作负载1研究了在运行大量查询时，所提出的机制如何实现数据仓库的横向扩展。
工作负载2研究了AScale在并发会话（例如，并发用户数）下的可扩展性。两个工作负载的设置目标均为保证每查询最大执行时间为60秒。

基于查询的可扩展性，工作负载1：图20显示了工作负载1的实验结果，其中：Y轴表示以秒为单位的平均执行时间；X轴表示每节点数据大小和当前节点数量；60秒以上的水平线表示期望查询执行时间；白色条形表示总工作负载时间，灰色条形表示再平衡时间（即提取数据、加载到节点中、重建索引和视图）。结果表明，每次执行查询时，若平均查询时间不低于配置的最大查询执行时间，则会增加一个额外节点（横向扩展）。在每次横向扩展中，再平衡时间表示从现有节点提取数据、重新分发数据以及重建索引和视图所需的必要时间。一旦平均查询时间低于配置的期望执行时间，该框架便停止对数据仓库节点进行扩展。

并发会话查询可扩展性，工作负载1： 图21 显示了数据仓库在并发会话执行时的扩展情况。图21 中左侧Y轴表示平均查询执行时间（单位：秒）；X轴表示会话数量、每节点数据大小和节点数量；灰色条形表示数据再平衡平均时间（单位：秒），即从节点提取数据、加载到新节点以及重建索引和视图所需的时间；白色条形表示平均查询执行时间。图21 的结果表明，随着并发会话数量的增加，系统会扩展节点数量以提供更高的性能，因此平均查询执行时间符合配置的参数。
由于加载和查询执行都是针对数据仓库进行的，并且数据仓库是可扩展的，因此当数据仓库加载性能提升时，AScale 查询执行性能也会同时提升，反之亦然。

11 结论与未来工作

我们提出了一种方法和一个名为AScale的框架，能够自动地对提取、转换、加载+查询（ETL+Q）过程进行伸缩，使开发人员只需专注于概念上的提取、转换、加载+查询模型。本文的主要贡献包括：一种可自动并行化提取、转换、加载与查询执行（ ETL+Q）的方法，能够在各个组件需要横向扩展或纵向收缩时对其进行独立调整；动态数据仓库（D‐DW）。我们提出了一种内存动态存储与处理方法，将其引入系统后，可实现完全的数据新鲜度和实时性；对所提方案进行了实验评估，结果表明AScale能够在检测到性能瓶颈时实现横向扩展，并在不需要资源时实现纵向收缩。
未来工作有许多有趣的方向，例如，实现主动和预测性可扩展性机制、使用可视化工具（拖放）构建模式并配置ETL流程、探索在云环境中实现弹性可扩展性的适用性。