CN103593452A - 一种基于MapReduce机制的数据密集型成本优化方法 - Google Patents

Abstract

本发明涉及一种基于MapReduce机制的数据密集型计算成本优化方法，在数据的流行程度和访问情况动态变化的状态下，优化MapReduce任务的执行时间和执行成本。该方法包括：提出云计算环境下基于MapReduce机制的成本计算模型；在该模型的基础上，根据负载中数据流行程度动态改变Map子任务的副本数目；对于访问次数较多，访问较频繁的热数据，通过增加其副本数目以减少文件抢夺和网络的带宽资源竞争，使其计算成本与计算时间达到最优；对于访问次数较少，访问较不频繁的冷数据，通过减少其副本数目以降低副本的创建与存储成本，使其计算成本与计算时间达到最优。利用本发明，云计算用户能够有效的减小资源使用成本，并能以更加高效的方式保证作业计算结果的可靠性与完整性。

Description

一种基于MapReduce机制的数据密集型成本优化方法

技术领域

本发明涉及一种基于成本优化方法，更确切地说是涉及一种基于MapReduce机制的数据密集型计算成本优化方法。该方法适用于负载中数据的流行程度和访问情况动态变化的状态下，云计算用户的计算成本与计算时间的优化问题。

背景技术

随着信息技术的发展，越来越多的工业和学术组织都面临着处理不断增长的大量大规模数据的挑战，例如文件分析处理、科学模拟等应用。作为处理大规模数据和数据密集型应用最主流的编程模型，MapReduce将大规模输入数据集有效分解为固定大小的数据块，分布式的存储在集群中的不同节点，并通过分布式并行计算模型，大大简化了大规模数据的计算任务。其中，为了解决系统的容错与数据可用性问题，在大型计算集群中，大部分基于MapReduce的存储系统均采用数据冗余的方法，即通过创建数据副本的方式，在任一数据块由于某种原因不可用的情况下，使用其副本以避免任务的重新启动与重复执行。目前，基于MapReduce的存储系统的数据副本均采用分级固定数目的方式，比如，Hadoop分布式存储系统分别在节点内部，机架内部与机架远程三个级别创建3份副本。然而，实际负载中数据的流行程度随着时间不断动态变化。一方面，在大型的繁忙系统中，某些热数据被多次重复访问，使其存储该数据的节点变为热点。在热点中，文件的争夺与带宽资源的限制成为了制约任务执行时间的重要瓶颈。对于云计算用户来说，任务执行时间的长期拖延意味着执行成本的浪费与服务质量的下降。另一方面，某些冷数据的访问次数远小于默认副本数目，因此额外的数据副本提高了存储成本与副本创建成本。在这种情况下，系统需要一种基于MapReduce机制的数据密集型计算成本优化方法，能够根据负载中数据的访问情况，利用成本计算模型，动态的改变数据副本数目，在保证系统的容错性与数据可用性的同时，优化云计算用户的计算时间与计算成本。

发明内容

本发明的目的是提供一种基于MapReduce机制的数据密集型计算成本优化方法，克服了上述繁忙中热数据的文件争夺与资源受限的不足，解决了由负载中数据的动态访问情况所造成的计算时间与成本浪费的问题；能够实时根据负载中数据访问情况将数据划分为热数据与冷数据，从而动态的改变数据副本数目，优化云计算用户的计算时间与计算成本。

为了达到上述目的，本发明采用的技术方案如下：

一种基于MapReduce机制的数据密集型计算成本优化方法，是根据负载中数据流行程度动态改变Map子任务的副本数目；对于访问次数较多，访问较频繁的热数据，通过增加其副本数目以减少文件抢夺和网络的带宽资源竞争，使其计算成本与计算时间达到最优；对于访问次数较少，访问较不频繁的冷数据，通过减少其副本数目以降低副本的创建与存储成本，使其计算成本与计算时间达到最优。

其具体过程为：根据对负载中数据访问情况的分析，通过数据流行度分类机制，以同一时刻数据的访问次数作为参考指标，以Hadoop分布式存储系统系统默认数据备份数3为参考值，将数据划分为热数据和冷数据。其中，数据的访问次数大于或者等于3的为热数据，反之为冷数据。在此数据划分的基础上，由数据副本数目决策算法根据数据密集型计算成本模型计算数据作假副本数目。

进一步的，上述技术方案包括负载采集与输入模块，数据流行度分类机制模块，数据副本数目决策算法模块，数据副本数目自动调节模块；模块自上至下依次设置，负载采集与输入模块输入连接到数据流行度分类机制模块，数据流行度分类机制模块将数据分为冷数据与热数据后，作为输入连接到数据副本数目决策算法模块，所述数据副本数目决策算法模块输出最佳数据备份数之后，将此备份数作为输入连接到数据副本数目自动调节模块。

进一步的，上述技术方案：所述负载采集与输入模块实时对负载进行采样与处理，采样的时间长短（时间窗口）可根据用户对于所要求的分析精确程度进行调整。默认时间窗口为1小时，时间窗口越长，负载分析的精确度越高，反之越低。

进一步的，上述技术方案：所述数据流行度分类机制模块根据同一时刻对某数据的访问数量，将数据分为冷数据和热数据。具体地，当数据的同一时刻的访问量大于或者等于3的时候，数据为热数据，反之为冷数据。值得注意的是，所述方案中同一时刻某数据的访问量数目并不是最终的该数据备份数目。

进一步的，上述技术方案：所述数据副本数目决策算法模块首先建立数据密集型计算成本模型，根据目前主流的云计算平台——亚马逊弹性计算云系统的分级定价模型与定价标准，将数据密集型计算成本分为数据执行成本、数据存储成本与数据I/O读写成本三个部分，并按照公式（1）计算：

C_total＝C_exe+C_storage+C_io   （1）

公式（1）中，C_total代表计算总成本，C_exe代表数据执行成本，C_storage代表数据存储成本，C_io代表数据I/O读写成本，C_total、C_exe、C_storage分别按照公式（2）、（3）、（4）计算：

C_exe＝u_exe×N_m×T_total   （2）

C_storage＝u_storage×S_total×T_total   （3）

$C_{\mathrm{io}}=C_{\mathrm{write}}+C_{\mathrm{read}}=\frac{u_{\mathrm{io}}\×S_{\mathrm{total}}\×R_f}{4\mathrm{KB}}+\frac{u_{\mathrm{io}}\×S_{\mathrm{total}}}{4\mathrm{KB}}---\left(4\right)$

公式（2）（3）（4）中，u_exe代表计算执行单价，与计算实例类型有关，计算实例配置越高，u_exe数值越高。u_exe由云计算平台提供商提供，单位为美元每小时每个计算实例；N_m代表计算集群中的计算实例数量，单位为个；T_total代表计算总时间，单位为小时；u_storage代表数据存储单价，由云计算平台提供商提供，单位为美元每个月每GB；S_total代表数据总量，包括原始数据及其数据备份，单位为GB；u_io代表数据I/O读写单价，由云计算平台提供商提供，单位为美元每百万次读写请求；R_f代表数据备份数，单位为个。

其中，公式（4）的数据I/O读写成本可分为I/O写成本C_write与I/O读成本C_read两部分;本发明中，成本计算模型将弹性块存储Elastic Block Store（EBS）作为数据默认存储方式，而EBS按照硬盘所使用的底层文件系统中的数据块大小收费；例如，在Linux系统中，ext3文件系统所使用的典型数据块大小为4KB；因此，假设每一个数据块在经历每一个Map和Reduce操作时都会被读一次，同时，每一个数据备份都会被写一次，那么数据的写成本C_write可表示为u_io与总数据写请求次数的乘积，即S_total×R_f/4KB；而数据的读成本C_read可表示为u_io与总数据读请求次数的乘积，即S_total/4KB。

进一步的，上述技术方案：所述数据副本数目决策算法模块建立数据密集型计算时间模型，并按照公式（5）计算：

T_total＝T_upload+T_exe   （5）

公式（5）中，T_upload代表数据上传时间，单位为小时；T_exe代表计算实例实际运行时间，单位为小时，T_upload、T_exe分别按照公式（6）、（7）计算：

T_upload＝s_f×(λ+μ×R_f)   （6）

$T_{\mathrm{exe}}=\frac{t_{\mathrm{exe}}/\mathrm{node}/\mathrm{GB}\×s_f}{N_m}---\left(7\right)$

公式（6）（7）中，s_f代表每个独立文件的大小，单位为GB；λ和μ代表读写能力指数，与计算实例的配置与网络配置有关，能够通过实验测得，单位为小时每GB；t_exe/node/GB代表计算实例的计算效率，单位为小时每实例每GB。

进一步的，上述技术方案：所述数据副本数目决策算法模块通过公式（1）（2）（3）（4）（5）模型，将数据创建成本转换为数据执行成本、数据存储成本与数据I/O读写成本，并按照公式（8）计算：

$C_{\mathrm{create}}=C_{\mathrm{exe}}+C_{\mathrm{storage}}+C_{\mathrm{io}}{=u}_{\mathrm{exe}}\×N_m\×T_{\mathrm{create}}+u_{\mathrm{storage}}\×S_{\mathrm{total}}\×T_{\mathrm{create}}+\frac{u_{\mathrm{io}}\×S_{\mathrm{total}}\×R_f}{4\mathrm{KB}}---\left(8\right)$

公式（8）中，C_create代表数据创建成本，单位为美元；T_create代表数据创建时间，单位为小时。在数据创建过程中，计算节点（实例）仍处于运行状态，因此数据创建成本包括实例的执行成本，以及原有数据的存储成本。此外，创建数据的过程即数据的写入过程，包括了R_f份数据的写入成本。数据创建时间越长，创建成本越大。

进一步的，上述技术方案：所述数据副本数目决策算法模块以成本为最终优化目标，建立密集型计算总成本与数据副本数目之间的关系，通过成本模型确定数据副本数目，从而达到成本最优化。

进一步的，上述技术方案：所述数据副本数目自动调节模块根据数据副本数目决策算法的输出最佳数据备份数目，以文件为单位更改Hadoop系统配置文件，动态调整数据的备份数目，使其运行时间与运行成本最优化。上述动作在任务运行过程中执行，并不中断任务的运行，对任务本身透明，从而最大程度的节省任务的运行时间。

本发明所述的一种基于MapReduce机制的数据密集型计算成本优化方法的有益效果是：

实时性强：本发明根据负载中数据的访问情况，自适应的划分数据，并且动态实时为不同类型的数据分配不同的数据副本，最大程度的保证了不同数据类型的计算成本最优化。

应用性强：本发明根据目前最流行的云计算平台——亚马逊弹性计算云的分级定价机制制定成本模型，最大程度的保证了模型的有效性与可靠性，实际应用性强。

附图说明

图1为本发明一种基于MapReduce机制的数据密集型计算成本优化方法执行流程图。

具体实施方式

应该指出，以下详细说明都是例示性的，旨在对本发明提供进一步的说明。除非另有指明，本文使用的所有技术和科学术语具有与本发明所属技术领域的普通技术人员通常理解的相同含义。

本发明实施例所述的一种基于MapReduce机制的数据密集型计算成本优化方法，根据负载中数据流行程度动态改变Map子任务的副本数目；对于访问次数较多，访问较频繁的热数据，通过增加其副本数目以减少文件抢夺和网络的带宽资源竞争，使其计算成本与计算时间达到最优；对于访问次数较少，访问较不频繁的冷数据，通过减少其副本数目以降低副本的创建与存储成本，使其计算成本与计算时间达到最优。

其具体过程为：

根据对负载中数据访问情况的分析，通过数据流行度分类机制，以同一时刻数据的访问次数作为参考指标，以Hadoop分布式存储系统系统默认数据备份数3为参考值，将数据划分为热数据和冷数据。其中，数据的访问次数大于或者等于3的为热数据，反之为冷数据。在此数据划分的基础上，由数据副本数目决策算法根据数据密集型计算成本模型计算数据作假副本数目。

如图1所示，本发明实施例所述的一种基于MapReduce机制的数据密集型计算成本优化方法执行流程图。参见图1，数据流行度分类机制通过对输入负载的分析，以同一时刻数据的访问次数作为参考指标，以Hadoop分布式存储系统默认备份数（3）为参考值，将数据划分为热数据和冷数据。进一步说明，若同一时刻某数据的访问次数大于等于3，则该数据为热数据；反之为冷数据。

继续参考图1，在数据流行度分类机制将数据划分为热数据和冷数据的基础上，由数据副本数目决策算法计算数据最佳副本数目，计算最佳数据副本数目。数据副本数目决策算法以成本模型为依据，将模型中的使用到的各项云计算平台定价指标作为已知条件，在MapReduce任务执行之前确定集群节点数目，以及总存储单元大小；在任务执行过程中的访问次数，以及网络架构作为衡量指标，以成本最优为目标，计算并输出最佳数据副本数目。

继续参考图1，根据数据副本数目决策算法的输出，系统将以文件为单位，在Map子任务执行过程中动态的改变系统配置参数，使其不同文件的副本数目达到计算预期值，从而使得最终计算成本达到最优化。

所述负载采集与输入模块实时对负载进行采样与处理，采样的时间长短（时间窗口）可根据用户对于所要求的分析精确程度进行调整。默认时间窗口为1小时，时间窗口越长，负载分析的精确度越高，反之越低。采集的负载作为输入连接到数据流行度分类机制模块。

所述数据流行度分类机制模块接受负载采集与输入模块的采集结果，根据同一时刻对某数据的访问数量是否大于Hadoop系统默认数据备份数3，将数据分为热数据和冷数据，并将其数据分类结果作为输入连接到数据副本数目决策算法模块。

所述数据副本数目决策算法模块首先建立数据密集型计算成本模型，将数据密集型计算成本分为数据执行成本、数据存储成本与数据I/O读写成本三个部分,并按照公式（1）计算：

C_total＝C_exe+C_storage+C_io   （1）

公式（1）中，C_total代表计算总成本，C_exe代表数据执行成本，C_storage代表数据存储成本，C_io代表数据I/O读写成本，C_total、C_exe、C_storage分别按照公式（2）、（3）、（4）计算：

C_exe＝u_exe×N_m×T_total   （2）

C_storage＝u_storage×S_total×T_total   （3）

$C_{\mathrm{io}}=C_{\mathrm{write}}+C_{\mathrm{read}}=\frac{u_{\mathrm{io}}\×S_{\mathrm{total}}\×R_f}{4\mathrm{KB}}+\frac{u_{\mathrm{io}}\×S_{\mathrm{total}}}{4\mathrm{KB}}---\left(4\right)$

公式（2）（3）（4）中，u_exe代表计算执行单价，与计算实例类型有关，计算实例配置越高，u_exe数值越高。u_exe由云计算平台提供商提供，单位为美元每小时每个计算实例；N_m代表计算集群中的计算实例数量，单位为个；T_total代表计算总时间，单位为小时；u_storage代表数据存储单价，由云计算平台提供商提供，单位为美元每个月每GB；S_total代表数据总量，包括原始数据及其数据备份，单位为GB；u_io代表数据I/O读写单价，由云计算平台提供商提供，单位为美元每百万次读写请求；R_f代表数据备份数，单位为个。

通过计算时间模型，将数据创建成本转换为计算执行成本、数据存储成本与数据I/O读写成本，并以成本为最终优化目标，建立密集型计算总成本与数据副本数目之间的关系，通过成本模型确定最佳数据副本数目，并作为输入连接到系统数据副本数目自动调节模块。其中，计算时间模型可以按照公式（5）计算：

T_total＝T_upload+T_exe   （5）

公式（5）中，T_upload代表数据上传时间，单位为小时；T_exe代表计算实例实际运行时间，单位为小时，T_upload、T_exe分别按照公式（6）、（7）计算：

T_upload＝s_f×(λ+μ×R_f)   （6）

$T_{\mathrm{exe}}=\frac{t_{\mathrm{exe}}/\mathrm{node}/\mathrm{GB}\×s_f}{N_m}---\left(7\right)$

公式（6）（7）中，s_f代表每个独立文件的大小，单位为GB；λ和μ代表读写能力指数，与计算实例的配置与网络配置有关，能够通过实验测得，单位为小时每GB；t_exe/node/GB代表计算实例的计算效率，单位为小时每实例每GB。

所述数据副本数目决策算法模块通过公式（1）（2）（3）（4）（5）模型，将数据创建成本转换为数据执行成本、数据存储成本与数据I/O读写成本，并按照公式（8）计算：

$C_{\mathrm{create}}=C_{\mathrm{exe}}+C_{\mathrm{storage}}+C_{\mathrm{io}}{=u}_{\mathrm{exe}}\×N_m\×T_{\mathrm{create}}+u_{\mathrm{storage}}\×S_{\mathrm{total}}\×T_{\mathrm{create}}+\frac{u_{\mathrm{io}}\×S_{\mathrm{total}}\×R_f}{4\mathrm{KB}}---\left(8\right)$

公式（8）中，C_create代表数据创建成本，单位为美元；T_create代表数据创建时间，单位为小时。在数据创建过程中，计算节点（实例）仍处于运行状态，因此数据创建成本包括实例的执行成本，以及原有数据的存储成本。此外，创建数据的过程即数据的写入过程，包括了R_f份数据的写入成本。数据创建时间越长，创建成本越大。

所述数据副本数目自动调节模块根据数据副本数目决策算法的输出最佳数据备份数目，以文件为单位更改Hadoop系统配置文件，动态调整数据的备份数目，使其运行时间与运行成本最优化，其优化问题可以表达为下列公式：

min(C_total＝C_exe+C_storage+C_io)   （9.1）

s.t.1≤R_f≤N_m   （9.2）

R_f∈N   （9.3）

上述动作在任务运行过程中执行，并不中断任务的运行，对任务本身透明，从而最大程度的节省任务的运行时间。

其原理为：基于MapReduce机制的数据密集型计算影响计算时间与成本的最根本原因为数据局部性与负载均衡。为此，本发明能够通过动态创建数据副本，以提高数据局部性，改善系统负载均衡。本发明不同于其他相关研究，将数据备份数目设定为数据访问数，类似方法的弊端在于数据备份的增长与数据密集型计算的时间缩短量并不成正比。在数据访问数确定的情况下，数据备份数增长到一定程度之后，数据密集型计算的时间与成本并不继续减小，反而因为副本的创建成本、存储成本与I/O成本的提高而增加计算时间与成本。而本发明以成本为最终优化目标，能够有效的保证数据备份数目在提高数据局部性与改善系统负载均衡的前提下，降低副本的创建成本、存储成本与I/O成本，从而保证数据密集型计算时间与成本的最优化。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (5)

1.一种基于MapReduce机制的数据密集型计算成本优化方法，其特征在于：技术方案包括负载采集与输入模块，数据流行度分类机制模块，数据副本数目决策算法模块，数据副本数目自动调节模块；模块自上至下依次设置，负载采集与输入模块输入连接到数据流行度分类机制模块，数据流行度分类机制模块将数据分为冷数据与热数据后，作为输入连接到数据副本数目决策算法模块，所述数据副本数目决策算法模块输出最佳数据备份数之后，将此备份数作为输入连接到数据副本数目自动调节模块；

具体过程为：根据对负载中数据访问情况的分析，通过数据流行度分类机制，以同一时刻数据的访问次数作为参考指标，以Hadoop分布式存储系统系统默认数据备份数3为参考值，将数据划分为热数据和冷数据；其中，数据的访问次数大于或者等于3的为热数据，反之为冷数据；在此数据划分的基础上，由数据副本数目决策算法根据数据密集型计算成本模型计算数据作假副本数目；

这种优化方法根据负载中数据流行程度动态改变Map子任务的副本数目；对于访问次数较多，访问较频繁的热数据，通过增加副本数目以减少文件抢夺和网络的带宽资源竞争，使计算成本与计算时间达到最优；对于访问次数较少，访问较不频繁的冷数据，通过减少副本数目以降低副本的创建与存储成本，使计算成本与计算时间达到最优。

2.根据权利要求1所述的一种基于MapReduce机制的数据密集型计算成本优化方法，其特征在于：数据副本数目决策算法模块建立了数据密集型计算成本模型，根据目前主流的云计算平台——亚马逊弹性计算云系统的分级定价模型与定价标准，将数据密集型计算总成本分为数据执行成本、数据存储成本与数据I/O读写成本三个部分，并按照公式（1）计算：

C_total＝C_exe+C_storage+C_io   （1）

公式（1）中，C_total代表计算总成本，C_exe代表数据执行成本，C_storage代表数据存储成本，C_io代表数据I/O读写成本，C_total、C_exe、C_storage分别按照公式（2）、（3）、（4）计算：

C_exe＝u_exe×N_m×T_total   （2）

C_storage＝u_storage×S_total×T_total   （3）

$C_{\mathrm{io}}=C_{\mathrm{write}}+C_{\mathrm{read}}=\frac{u_{\mathrm{io}}\×S_{\mathrm{total}}\×R_f}{4\mathrm{KB}}+\frac{u_{\mathrm{io}}\×S_{\mathrm{total}}}{4\mathrm{KB}}---\left(4\right)$

公式（2）（3）（4）中，u_exe代表计算执行单价，u_exe由云计算平台提供商提供，单位为美元每小时每个计算实例；N_m代表计算集群中的计算实例数量，单位为个；T_total代表计算总时间，单位为小时；u_storage代表数据存储单价，由云计算平台提供商提供，单位为美元每个月每GB；S_total代表数据总量，包括原始数据及其数据备份，单位为GB；u_io代表数据I/O读写单价，由云计算平台提供商提供，单位为美元每百万次读写请求；R_f代表数据备份数，单位为个;

其中，公式（4）的数据I/O读写成本可分为I/O写成本C_write与I/O读成本C_read两部分;本发明中，成本计算模型将弹性块存储Elastic Block Store（EBS）作为数据默认存储方式，而EBS按照硬盘所使用的底层文件系统中的数据块大小收费；例如，在Linux系统中，ext3文件系统所使用的典型数据块大小为4KB；因此，假设每一个数据块在经历每一个Map和Reduce操作时都会被读一次，同时，每一个数据备份都会被写一次，那么数据的写成本C_write可表示为u_io与总数据写请求次数的乘积，即S_total×R_f/4KB；而数据的读成本C_read可表示为u_io与总数据读请求次数的乘积，即S_total/4KB。

3.根据权利要求1所述的一种基于MapReduce机制的数据密集型计算成本优化方法，其特征在于：数据副本数目决策算法模块建立数据密集型计算时间模型，并按照公式（5）计算：

T_total＝T_create+T_exe   （5）

公式（5）中，T_upload代表数据上传时间，单位为小时；T_exe代表计算实例实际运行时间，单位为小时，T_upload、T_exe分别按照公式（6）、（7）计算：

T_create＝s_f×(λ+μ×R_f)   （6）

$T_{\mathrm{exe}}=\frac{t_{\mathrm{exe}}/\mathrm{node}/\mathrm{GB}\×s_f}{N_m}---\left(7\right)$

公式（6）（7）中，s_f代表每个独立文件的大小，单位为GB；λ和μ代表读写能力指数，通过实验测得，单位为小时每GB；t_exe/node/GB代表计算实例的计算效率，单位为小时每实例每GB。

4.根据权利要求1所述的一种基于MapReduce机制的数据密集型计算成本优化方法，其特征在于：通过公式（1）（2）（3）（4）（5），将数据创建成本转换为数据执行成本、数据存储成本与数据I/O读写成本，并按照公式（8）计算：

$C_{\mathrm{create}}=C_{\mathrm{exe}}+C_{\mathrm{storage}}+C_{\mathrm{io}}{=u}_{\mathrm{exe}}\×N_m\×T_{\mathrm{create}}+u_{\mathrm{storage}}\×S_{\mathrm{total}}\×T_{\mathrm{create}}+\frac{u_{\mathrm{io}}\×S_{\mathrm{total}}\×R_f}{4\mathrm{KB}}---\left(8\right)$

公式（8）中，C_create代表数据创建成本，单位为美元；T_create代表数据创建时间，单位为小时；其中，数据创建成本与总成本的关系为：总成本计算中所需要的总时间包括了数据创建过程中所消耗的创建时间T_create；在数据创建过程中，计算节点（实例）仍处于运行状态，因此进一步产生数据执行成本，以及数据的存储成本；此外，创建数据的过程即数据的写入过程，包括了R_f份数据的写入成本。

5.根据权利要求1所述的一种基于MapReduce机制的数据密集型计算成本优化方法，其特征在于：以成本为最终优化目标，建立密集型计算总成本与数据副本数目之间的关系，通过成本模型确定数据副本数目，从而达到成本最优化。

Images