了解更多开源内容请访问：开源基础软件社区https://ost.51cto.com【本期亮点】Hadoop和Hadoop的性能优化系统星火框架。云计算重复数据删除技术减少了冗余。压缩框架Ares如何统一不同的算法。在线数据压缩“摇摆门趋势”。揭开新移动云存储SDM的神秘面纱。【技术DNA】【智能场景】大数据概念背景介绍大数据（BigData），又称海量数据，是指所涉及的数据量太大，无法通过主流软件工具，在合理时间内通过捕获、管理、处理和组织信息，以帮助企业做出更积极的业务决策。但是大数据是一个抽象的概念。业界对大数据没有统一的定义，用上面的定义似乎很难理解。因此，有以下用“4Vs”来定义大数据的方法。大数据特性说到大数据的特性，就不得不提到“4V”。那么什么是“4V”呢？“4V”是用来描述大数据特性的四个英文单词：Volume（体积）、Velocity（速度）、Variety（多样性）和Value（价值）。用“4V”的方法给出大数据的中文定义，即满足数据量大、数据传输速度快、数据种类繁多、数据价值密度低的大数据。每天，大家用微信、QQ和朋友聊天，用支付宝、淘宝完成线上线下的支付。时代变了，互联网产生的数据已经远远超过多年前的“3G时代”。例如，下图形象地描述了2021年各大互联网公司每分钟产生的数据。例如，Tiktok每分钟产生5000次下载，发送1.976亿封电子邮件，上传500小时的视频。虽然不是国内的数据，但也能反映出国内的一些情况，让我们体会到大数据时代数据的庞大和数据类型的复杂。侧面也能反映出处理这些数据的难度。问题解决那么大数据是如何一步步发展到今天的呢？在回答这个问题之前，先介绍一下两个非常重要的项目ApacheSpark和ApacheHadoop，它们都是由著名的ApacheFoundation开源的。ApacheHadoop简介ApacheHadoop是由DougCutting发明的开源、可靠、可扩展的分布式计算框架。这个项目的名字和logo的来源也很有意思。是老大手里拿着的玩具的名字。和ApacheHadoop的logo对比，是不是觉得很像？ApacheHadoop可以做什么？构建大型数据仓库以及PB级的数据存储、处理、分析、统计等服务，这些Hadoop都不是问题。而且，在搜索引擎时代、数据仓库时代、数据挖掘时代，以及今天的机器学习时代，Hadoop分别扮演着重要的角色。ApacheSpark简介ApacheSpark是由加州大学伯克利分校的AMP实验室（Algorithms,Machines,andPeopleLab）开发的通用内存并行计算框架。具有运行速度快、易用性好、通用性强、随处运行的特点。ApacheSpark支持使用内存处理来提升大数据分析应用程序的性能。大数据解决方案旨在处理对于传统数据库来说太大或太复杂的数据，使用Spark处理内存中的大量数据比基于磁盘的替代方案要快得多。两者之间的连接ApacheHadoop提供分布式数据存储功能HDFS，也提供MapReduce进行数据处理。虽然MapReduce可以在不依赖ApacheSpark的情况下处理数据，ApacheSpark也可以在不依赖HDFS的情况下完成数据的存储，但是如果两者结合起来，让ApacheHadoop提供分布式集群和分布式文件系统，ApacheSpark就可以依赖HDFS而不是MapReduce弥补了MapReduce计算能力的不足。或许，有了以上两个框架，就可以完美应对当今大数据时代出现的问题，但是如果你看看下图中全球数据量的预测及其增长率，你会觉得有一天，现有的技术已经不能满足我们了，我们的技术还有待完善。如何从Hadoop的源码上进行改进此时，或许我们应该看看ApacheHadoop的源码。ApacheHadoop起源于Nutch。Nutch的设计目标是构建一个面向全网的大型搜索引擎，包括网页爬取、索引、查询等功能，但是随着爬取网页数量的增加，遇到了严重的扩展性问题——如何解决数十亿网页？网页存储和索引问题。谷歌在2003年到2014年发表的三篇论文为这个问题带来了解决方案。三篇论文分别提到了三个关键技术点GFS、MapReduce和BigTable。最终在Hadoop生态系统中演变成HDFS、HadoopMapReduce和HBase。GFS：GoogleFileSystem，谷歌的分布式文件系统。MapReduce：Google用于解决PageRank问题的分布式计算模型。BigTable：列式存储Hbse的理论基础。其中，HadoopMapReduce是ApacheHadoop的重要组成部分之一。它是数据中心中重要的数据处理引擎，可以帮助用户避免维护物理基础设施的成本。许多研究都集中在MapReduce任务上，以提高数据中心性能并大幅降低能耗。本期阅读的论文也研究了MapReduce相关的数据压缩。从数据压缩开始数据压缩算法的取舍取决于各种因素，例如压缩程度、数据质量、压缩算法类型或数据类型。最终的数据大小或I/O减少取决于压缩率，而压缩率取决于数据和压缩算法。这意味着较低的比率将减少内存和I/O使用。以下是Hadoop功能中Hadoop中可用压缩格式的摘要：上表中所有选定的压缩编码器和解码器都是无损的，因为数据需要安全存储。gzip和deflate编解码器都使用deflate算法，而不是lz77和Huffman编码的组合。两者的区别在于哈夫曼编码阶段可拆分压缩bzip2编解码器使用Burrows-Wheeler（块排序）文本压缩和哈夫曼编码算法。Bzip2可以独立或并行压缩数据块。Snappy是一个使用lz77思想的快速数据压缩和解压缩库。Snappy块是不可分割的，但Snappy块内的文件是可分割的。lzo(Lempel-Ziv-Oberhumer)压缩算法是lz77压缩算法的变体。算法分为寻找匹配、写入不匹配的字面数据、确定匹配的长度、写入匹配的token部分。压缩数据文件由一个lz4序列组成，该序列包含标记、文字长度、偏移量和匹配长度。Zstandart是Facebook开发的基于lz77的算法，支持字典、大规模搜索框以及使用有限状态熵和霍夫曼编码的熵编码步骤。Hadoop支持的压缩格式太多，所以需要一种可以动态选择压缩方式的算法，根据数据类型选择压缩格式。I/O性能的相关工作。作者分析了几篇论文，以找到提高I/O性能和能源效率的方法。首先，笔者阅读了三篇论文。在这篇论文中，作者将4个计算机节点集群起来，研究了在小工作量的情况下，在MapReduce上进行一些数据压缩的性能提升和能量利用率。其次，本文作者从现有的几种方法和压缩算法中确定了压缩方式，以减少数据加载时间，提高并发性。最后，本文作者研究了两种动态选择算法，通过定期压缩算法表征和实时系统资源状态监控来实现最佳I/O性能。关于能源效率。作者选取了多篇论文，分析了不同的能源模型来预测MapReduce作业的能源消耗。通过调整数据复制因子和数据块大小参数，可以最大限度地减少作业执行时间和能耗。其次，通过另一篇论文预测MapReduce工作负载能耗的线性回归模型，作者发现通过精确??的资源分配和智能动态电压和频率缩放调度，可以实现显着的节能效果。此外，作者还了解了修改Hadoop以实现操作集群大小缩减的早期工作。最后，作者阅读了一种调整HPC集群的并行度、网络带宽和电源管理功能的策略，以达到高效执行MapReduce的目的。作者最终通过修改Hadoop/Spark框架中关于能效的各种配置参数来提升HadoopMapReduce作业的性能。本文旨在提出一种系统，用于选择最佳压缩工具并调整压缩因子以实现最佳性能。测试方法框架研究人员通过研究节省CPU和节省I/O之间的权衡，进一步调整压缩因子，评估使用基于压缩工具的Hadoop和Spark框架的大数据应用程序的运行效率。同时，性能优化方法允许用户探索和优化大数据应用。下图展示了测试方法框架：分布式I/O基准测试工具决策服务将应用类型和复杂度通过RESTAPI发送给服务事务模块，选择最优配置。在模拟模块中研究和实施了几个MapReduce类型的基准测试、工具和应用程序。作为分布式I/O基准测试工具，TestDFSIO基准测试用于对HDFS进行压力测试并确定集群I/O速度。TestDFSIO对于识别网络瓶颈和强调集群节点上的硬件、操作系统和Spark/Hadoop配置也是必不可少的。TestDFSIO10使用单独的Map任务（或Spark作业）来执行批量数据的并行读取和写入。收集有关Reduce任务的统计信息以获得HDFS吞吐量和平均I/O的摘要。下表是TestDFSIO选项的总结：其他测试应用程序描述了许多可用于测试HDFS和MapReduce层的MapReduce应用程序。用于检查HDFS和MapReduce层的Terasort包包括用于生成数据的TeraGen、用于排序数据的Terasort和用于验证数据排序的TeraValidate。TeraGen旨在生成大量数据，这些数据是TeraSort的输入。生成数据的大小和输出是输入参数。Terasort对TeraGen生成的数据进行排序。TeraValidate检查排序后的TeraSort输出。输入和输出路径是TeraSort和TeraValidate基准参数。WordCount工作负载读取文本文件并计算找到单词的频率。LogAnalyzer工作负载读取一个日志文件作为输入，检测与输入正则表达式匹配的行，并输出一个报告，告知关键字是否存在以及出现了多少次。对算法聚类数据分析技术进行了测试，以根据相似性度量对整个数据进行分组。k-Means聚类是数据科学中最简单、功能强大且流行的无监督机器学习算法之一。已使用并行k-MeansMapReduce应用程序，允许管理大型数据集以查找对象之间的距离。使用背景部分中描述的压缩算法压缩评估内容和指标输入数据。在Hadoop和Spark环境指标中评估了三种类型的输入数据、七种压缩算法和五种工作负载（TestDFSIO、TeraSort、WordCount、LogAnalyzer、k-Means），以研究不同工作负载的环境和压缩算法。下表给出了具体的评估指标：实验验证环境配置采用由一个主节点和16个从节点组成的Hadoop/Spark集群进行实验，有以下不同配置：1+4、1+8和1+16。集群中每个节点都运行Openstack中间件，每个节点使用一台装有UbuntuServer18.04操作系统、3GB内存和120GBSATA共享硬盘的虚拟机。使用Hadoop3.2.1版、Spark2.4.5版、JavaJDK1.8版和HDFS块大小128MB。复制因子设置为2（默认值为3），方便数据节点下线。每个ApacheHadoop和Spark环境的实验总数为240。压缩文件与原始文件的压缩比分析所有实验均使用4GB、8GB和16GB数据工作负载执行。数据压缩减少了存储使用。压缩文件和原始文件压缩率分析如下图所示。从上图我们可以得出压缩率最好的算法是Gzip、Zstandard和Bzip2算法，平均为13-17%。gzip和bzip2的压缩率相差大约4%。根据基准测试，Gzip的执行时间比Bzip2压缩快大约7倍。Lzo、Lz4和Snappy算法的压缩率比Gzip压缩低26-27%，执行时间快约7倍，这将在下一节中介绍。LogAnalyzer实验该实验表明，使用lz4压缩格式的Spark，以及8GB和16GB的数据集，提高了47%；20-70%CPU和18-20%内存用于可拆分压缩数据；8-10%CPU和14-28%内存用于不可分割的压缩数据，无论输入数据如何无论大小，LogAnalyzer在Hadoop上的执行时间使用lz4压缩格式优化了4.4%。对于Hadoop，8节点和4节点配置的标准偏差为2%，对于Spark，8节点配置的标准偏差为9%，4节点配置的标准偏差为27%。Hadoop集群中所有节点的平均CPU使用率为6-6.5%，内存使用率为12-16.5%。在Spark上，未压缩输入数据的平均CPU使用率为15-25%和18-28%；可拆分压缩数据为20-70%和18-20%；对于压缩数据，平均CPU使用率为8-10%和14-28%。在Hadoop上，平均资源使用率几乎相同。LogAnalyzer实验比较了4GB、8GB和16GB数据卷在16节点Hadoop和Spark配置上的执行时间，如下所示：WordCount实验在调查WordCount大规模模拟应用程序时有所不同。实验表明，压缩编解码器略微提高了具有16GB输入数据的Hadoop框架的执行时间。Lz4和Lzo编解码器在这两种情况下都表现出最佳性能。在Hadoop上，Lz4的性能略高于Lzo，而在Spark上则相反（Lzo的执行时间更短）。8节点和16节点配置的Hadoop执行时间几乎相同，但在4节点上，平均执行时间增加了1.4%。平均执行时间在Spark8节点集群上增加了17%，在四节点集群上增加了51%。在Hadoop集群上，平均CPU使用率为5.3-6.7%，内存使用率为12-17.3%。在具有未压缩输入数据的Spark集群上，CPU使用率为20-47%，内存为30-42%。对于使用不可拆分编解码器压缩的输入数据，平均CPU使用率为6-7%和内存的2030%，对于使用可拆分编解码器压缩的数据，平均CPU使用率为6-7%，内存为20-50%，内存为30%-70%。作为Hadoop环境中WordCount作业的LogAnalyzer，平均资源使用率几乎相同。Lzo编解码器显示了Wordcount作业的最佳性能，它比未压缩数据快8%，但平均多使用12%的CPU和23%的内存。WordCount在16节点Hadoop和Spark配置上对4GB、8GB和16GB数据进行的实验性能比较如下：TestDFSIOexperiments编解码器还改进了LogAnalyzer和WordCount应用程序的执行时间。Gzip和Snappy不可拆分编解码器减少了存储大小但增加了执行时间。可拆分压缩编解码器对Spark环境有重大影响。压缩编解码器未用于TeraGen和TestDFSIO基准测试，因为算法人工生成了数据。下图显示了TestDFSIO基准测试在具有16节点配置的Hadoop和Spark环境中的执行时间：具有写入选项的TeraSort实验集群基准测试在8节点配置中的运行时间大致相同。Hadoop的偏差为2%，Spark的偏差为1%。读取选项的执行时间在Hadoop上增加了82%，在Spark上增加了31%。在四节点配置中，写入在Hadoop上慢了4%，在Spark上慢了18%，而14读选项在这两种环境中都慢了三倍。图6显示了TeraGen、TeraSort、TeraValidate基准测试在具有16节点配置的Hadoop和Spark环境中的执行时间。TeraGen和TeraValidate在Hadoop上工作得更快，在Spark上工作得更快。与Hadoop相比，Spark在基准仿真??时间上平均减少了12%。在八节点Hadoop和Spark集群上，TeraGen和TeraSort的结果几乎相同，仅相差2%，但对于TeraValidate，基准执行时间在Hadoop上增加了20%，在Spark上增加了50%。在四个节点上，与16节点配置相比，Hadoop集群使用TeraGen平均快13%，使用Terasort平均快3%，使用Teravalidate慢43%。在四个节点上，Spark集群TeraGen快7%，TeraSort慢4%，Teravalidate慢72%。在这两种环境中，平均CPU使用率为5-7%，内存在Hadoop上为12-14%，在Spark上为15-16%。16个节点Hadoop/Spark上4GB、8GB和16GB数据的TeraSort基准执行时间如下所示：k-means实验在k-Means集群应用程序中，使用1GB、2GB、4GB输入数据大小进行实验。根据下图，Gzip、Snappy和Zstandart编解码器表现出与输入未压缩时几乎相同的性能。16个节点Hadoop/Spark上1GB、2GB和4GB数据的K-means基准执行时间如下图所示：更好的性能。Lz4编解码器的压缩率约为93%，可实现最佳性能。而不是Hadoop（偏差为1%），在Spark的四节点和八节点配置上，执行时间平均增加了30%和93%。在Hadoop上，最佳性能表明Zstandard编解码器比未压缩数据快6.4%。在Hadoopk-Means集群上，与LogAnalyzer和WordCount相比，平均资源使用率几乎相同。平均CPU使用率为6-7%，而内存使用率为16-18%。Spark上表现最差的是Gzip、Zstandard和Snappy编解码器，它们平均使用6-8%的CPU和30-48%的内存。如果k-Means输入数据未压缩，则平均CPU使用率为37-50%，而内存为30-44%。在其他编解码器的情况下，平均CPU使用率为11-56%，而内存为26-44%。Spark集群上的最佳性能显示lz4，它比未压缩的输入数据平均快8.8%，但平均多使用3%的CPU和多1%的内存。内存和处理器使用情况的统计数据下表显示了内存和处理器使用情况的统计分析，以表征数据并调查分散情况。两种框架下，TestDFSIO和TeraSort结果的SD较小，结果可靠性较高，但LogAnalyzer、WordCount和k-Means的数据与统计平均值存在明显差异。下表显示了五个工作负载的内存和处理器使用情况的平均值和SD（标准偏差）分析：具有最佳性能的摘要和最佳解决方案系统。上述文章针对不同的应用程序（包括TestDFSIO、TeraSort、WordCount、LogAnalyzer和K-means）评估了Hadoop和Spark环境中的4GB、8GB和16GB数据工作负载。所提出的系统使用评估结果来选择最佳配置环境。我们的压缩数据处理分析结果表明，无论输入数据大小如何，Lz4编解码器都能在Hadoop上实现最佳性能。Spark仅在使用Lz4的4Gb输入数据以及使用Zstandard编解码器的8Gb和16Gb时实现最佳性能。了解更多开源知识，请访问：开源基础软件社区https://ost.51cto.com。
