使用Apache Flink技术执行BigBench工作负载外文翻译资料

 2022-11-21 16:54:28

英语原文共 8 页，剩余内容已隐藏，支付完成后下载完整资料

使用Apache Flink技术执行BigBench工作负载

Sonia Bergamaschi, Luca Gagliardelli, Giovanni Simonini* and Song Zhu

Department of Engineering 'Enzo Ferrari', University of Modena and Reggio Emilia, Modena, Italy

摘要：在工业4.0时代，我们面临着管理和分析大量数据所带来的的挑战，（如传感器的数据管理，工业制造中的机器故障预测，以及电子商务中的网络日志分析等）为了处理所谓的大数据管理与分析，在过去的十年里，人们提出了大量的处理框架。有很多人正关注着并行化处理框架，比如MapReduce，Apache Hive，Apache Flink。但是，林林总总的框架中，想要对它们进行性能评估并不是件易事，而且要严格依赖于实际应用的要求。本文着重与比较两种广泛使用、最具潜力的大数据处理框架：Apache Flink与Apache Hive，它们都是Apache旗下的分布式数据处理平台。为了评估这两个框架，我们使用为Apache Hive开发的基准BigBench。我们重新实现了Apache Hive BigBench最重要的查询使它们能够在Apache Flink上工作，以便能够

比较在两个框架上执行的相同查询的结果。我们的结果显示Apache Flink，如果配置得当，能够胜过Apache Hive。

关键词：大数据管理、Apache Flink、Apache Hive、BigBench、Benchmarking

引言

近几年，各行各业的数据量的增长速度是越来越快[21]，这是由于在工业4.0时代，各种智能机器的使用产生了大量的数据。比如，例如，生产个人护理产品的消费品包装公司每33毫秒会产生5000条数据样本，每年会产生4万亿数据样本[22]。实时分析这些海量数据（大数据）和提取有价值的信息对于行业来说是具有战略意义的。参考之前的内容，公司需要快速分析其数据以检查一切工作是否正常。

随着数据量的不断增加，与所谓的大数据相关的项目也在激增，无论是在学术领域还是生产生活领域[1，13，12，14]。管理和分析这些海量数据，分布式和并行计算是最有前途的方法。值得一提的是，作为新技术的开创者之一的Google，设计了一种新的并行处理模式来管理其庞大的数据量，Google文件系统和MapReduce。这种新的范例简化了商品硬件上分布式应用程序的开发，允许这些应用的高度可扩展性。事实上，Google文件系统[15]发布后，MapReduce范式非常普遍。受这种范式启发，现有框架[16,17,18]都有自己的特征，例如：用于编程语言的API，数据挖掘和机器学习算法支持。在这种情况下，很难评估哪个适合特定的应用程序，商业案例或公司。

这项工作的目标是通过在大数据分析各个方面的表现来评估Apache Flink的性能。Flink是开源的分布式大数据分析框架（如Hadoop和Hive）。但是，Flink核心是一个用Java和Scala编写的分布式流式数据流引擎。 Flink项目的目标是建立MapReduce的系统和无共享并行数据库管理系统之间桥接。该系统的优点是在一个单一框架中提供批处理和流处理。这使它成为商业公司处理传统批处理需求（例如数据仓库）以及工业4.0的实时处理需求（例如实时管理传感器数据）的理想选择。

为了评估Flink，我们选择采用BigBench，这是一个面向业务的基准，非常适合评估工业环境下的大数据框架。 BigBench是由Oracle，TeraData，英特尔与加拿大多伦多大学中间件系统研究组合作开发的开源大数据基准测试。由于BigBench是为Apache Hive编写的，为了进行比较，我们调整了基准使其可以适用于Flink引擎。

本文的其余部分的结构如下。第二节主要包含有关Flink和BigBench的概述和相关工作。第3部分致力于使用Flink框架开发BigBench工作负载。评估和比较的结果在第4节中给出。最后，我们在第5节得出关于实验结果的结论。

研究背景以及相关工作

Apache Flink

Apache Flink（以前称为Stratosphere）是一种分布式大规模并行数据分析系统。其目的是为了让程序员从显式编程软件必须运行在分布式架构上的负担中解脱出来。它通过提供一组高级API来编程用户定义函数（UDF），这些函数在并行分布式计算中自动转换并在Flink框架上执行。因此，我们可以将Flink看作一个通用的分布式平台，旨在为数据处理引擎层提供完整的可扩展解决方案。

通常，Flink允许通过图1a所示的系统堆栈来处理用户定义的函数（UDF）代码。 Flink内核为数据流的分布式计算提供数据分配，通信和容错能力。最重要的是，有几个API用于创建应用程序。Flink有一个主从架构，由作业管理器和一个或多个任务管理器组成，如图1b所示。作业管理器是主节点，它协调Flink系统中的所有计算，而任务管理器是工作人员，实际执行分布式程序。这种架构对于程序员来说是完全透明的，只需要知道暴露的API就可以编写程序。定义自己的序列化器。Flink能够提供简易的数据表示，并通过低级优化算法直接对原始数据进行转换，而无需从二进制表示中反序列化对象。就性能而言，这意味着计算常见操作（例如排序和哈希）的能力即使在复杂的数据类型上也可以非常有效，从而大大降低开销。

（a）（b）

图1.（a）Flink组成架构；（b）Flink执行周期

BigBench

这项工作的范围是尽可能多的在大数据应用的方面评估Flink，因此我们选择了BigBench [19]作为基准。该基准测试的数据模型涵盖3类数据类型，结构化，半结构化和非结构化数据;此外，其工作负载旨在涵盖各种业务案例和技术方面。

大多数BigBench数据模型的基本特征，特别是关于结构化关系表的特征，都是根据TCP-DS（TPC Benchmark DS：“用于包括大数据在内的决策支持解决方案的基准标准”）进行调整的[2]。除了来自TCP-DS的结构化关系数据模型之外，BigBench还利用半结构化和非结构化数据丰富了结构化部分。图2展示了BigBench的简化数据模型。结构化数据描述了产品零售商;而半结构化数据则由零售商网站上的点击构成;以及非结构化数据是由客户提交的产品评论。

图2 BigBench的简化数据模型

BigBench采用扩展版本的并行数据生成框架（PDGF）[3]来生成合成数据。 PDGF是一个并行数据生成器，它能够为任意模式生成大量数据。 虽然标准PDGF可用于生成仅结构化数据，但BigBench开发了扩展版PDGF来生成半结构化和非结构化数据。 BigBench可以通过使用比例因子产生不同的数据量。 为了更好地突出显示根据测试比例因子的数据量变化，通过这些比例因子分别生成了1,50,100,150和200 GB数据，在图4a中示出了具有比例因子1和比例缩放方法的表的大小以及在 图4b的图表报告了关于主表格的大小信息及其与不同比例因子相关的数据量趋势。

图3 BigBench 查询

Workload

BigBench工作负载的主要部分是一组针对使用自身生成的数据执行的查询。这些查询是根据30个业务问题定义的。在图3中显示了具有30个查询特征的表格。其中十个来自TPC-DS工作负载与结构化数据。剩下的20个是根据McKinsey关于大数据使用案例和机会的报告确定的商业用例设计的[7]。这20个查询中有7个针对半结构化数据运行，5个运行在数据模型的非结构化部分上。

从查询实现的角度来看：

bull;14个是纯粹的HiveQL查询;

bull;4个通过使用Python实现;

bull;2个是基于Java的MR作业;

bull;5个利用OpenNLP库实施情感分析和命名实体识别;

bull;5个使用Mahout来执行机器学习算法。

在BigBench的标准版本中，所有查询都使用Hive。我们的工作包括使用Flink框架开发查询以及比较两个框架的性能。

（a）（b）

图4 （a）BigBench表格缩放；（b）BigBench量与不同的比例因子

相关工作

评估大数据框架并不是一个简单的问题。有新兴的基准来实现这一目标。但是，每个基准都有自己的特点，并对大数据应用程序的某些特定方面进行评估。 Geoffrey C. Fox等[4]对大数据基准进行了分析，其中分类提供了大数据基准测试。

另一项关于BigBench的工作与我们的类似，但通过使用Spark引擎，由Todor Ivanov等人[5]完成，作者使用Spark SQL实现了BigBench查询，并将Hive与Hadoop引擎的性能与工作负载的性能用Spark SQL实现。在这种情况下，Spark在许多情况下性能优于Hadoop，因此Spark使用主内存抽象，而Hadoop在磁盘上使用MapReduce。Spark表现不佳的少数情况是由于联合操作，并且在新的Spark版本中解决。另一方面，Juwei Shi等人[6]已经确定，在某些情况下Hadoop比Spark更好。这些作品表明，大数据框架中没有绝对的赢家。每个框架都可以采取在大数据分析的特定方面具有优势。有了这个观点，我们接近Flink的绩效评估。 Flink上的作品很少，因此它对于Spark来说仍然是一项新技术。 Ovidiu-Cristian Marcu等人[7]分析了Flink和Spark之间的比较，其中两个框架是通过使用各种算法进行比较，例如：字数; grep的; Tera Sort; K-手段;网页排名;连接的组件。我们的方法是使用标准基准，并使用Flink引擎来实现工作负载。

进展

我们采用了30个BigBench查询中的13个，通过Flink DataSet API翻译它们，然后在Flink引擎上执行。特别是参考图3，我们翻译了第1,5,6,8,11,13,15,17,20,23,24,25,29个查询。我们选择这些查询是因为它们涉及广泛的跨域，功能谱：市场购物篮分析，机器学习算法和聚类处理。

通过对BigBench工作负载中提出的非结构化文本使用MapReduce方法实施的大多数查询涉及用于从计划文本中提取情感的UDF。这些内置函数的导入不会涉及任何进一步的面向引擎的实现。我们报告两个重要的转换示例。

请注意，我们实现BigBench查询的复杂性与最初的Hive实现相同：结果之间的差异取决于两个框架如何管理内存和任务。 Hive基于Hadoop，它使用传统的MapReduce实现[23]，因此每个转换分两个阶段执行：映射和缩减。在这两个阶段之间，结果被写入磁盘。Flink使用不同的范例，将地图和减少操作合并为一个作业[17]。中间结果保存在内存中。由于内存访问速度比磁盘快得多，Flink的实现比Hive更好。

查询11：皮尔森乘积矩相关系数。 BigBench文档报告说，此查询“对于给定的产品，在给定时间范围内衡量产品月收入的情绪相关性（包括评论数量和平均评论评级）”。 特别是，如果查询时间固定，则查询计算每个销售商品的评论总数和平均评论评分。 然后，使用Hive内置聚合函数（UDAF）中包含的相关函数，为每个项目计算总评论数量与平均比率之间的Pearson相关性[8]，以发现这些变量之间的任何关系。 Flink Pearson相关系数UDF是根据文献[9]提出的实现方式开发的，相关公式如（1）所示，，y=

X是每件商品的评论数量，Y是每件商品的平均评分。

Flink实施工作流程如图5所示。该实施方案最具挑战性的一个方面是处理临时汇总值。 因为Flink工作使用MapReduce范例，所以不可能多次传递数据以进一步后续处理，因为行一经处理就会不断地推送给下一个操作员，也会在不同的机器上。出于这个原因，为了执行正确的计算，有必要将行与它们各自的均值向量结合起来，最后，在收集所需的汇总值之后，通过a来提取相关系数在临时DataSet上进行FlatMap转换。

图5 查询11 Flink工作流程

查询25：客户K-Means集群。正如BigBench文档[19]中所报告的，该查询执行“客户细分分析：客户沿着以下关键购物维度分离：最近上次访问的次数，访问次数和金额。在给定年份内使用商店和在线购买数据进行计算。在建立分离模型后，报告分配给他们“组”的分析客户。查询从分别报告客户和购买信息的两个视图生成K-Means的数据集。每个客户的特征向量包括：

bull; 客户ID;

bull;新近度：一个布尔值，指示客户是否在过去60天内进行了购买;

bull;频率：购买总量;

bull;总支出：花费总额。

为了在Flink中实现这个查询，我们使用了Spark Machine Learning Library（Spark MLlib）[20]，它提供了对许多不同机器学习算法的高级访问，其中包括K-Means。 Hive和Flink实现的主要区别是给定的ML算法接收输入数据集的数据源。 Hive确实将查询执行的临时结果直接保存在HDFS上的结果元数据中，而Flink将临时结果存储在CSV文件中。图6显示了Flink执行的工作流程：首先，它将客户数据与购买数据结合起来，然后为客户ID分组数据，然后使用UDF减少功能为每个客户计算特征向量；将部分结果保存在CSV文件中，最后使用MLlib的K-Means算法对特征向量进行详细说明

图6 查询25 Flink工作流程

K均值算法的参数k的变

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[22915]，资料为PDF文档或Word文档，PDF文档可免费转换为Word

原文和译文剩余内容已隐藏，您需要先支付 30元 才能查看原文和译文全部内容！立即支付

以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。

您可能感兴趣的文章