徐州网站建设新闻,网站分站是怎么做的,微信公众平台设计,网站优化细节在正文开始之前#xff0c;请先来回答一下这个问题#xff1a; 题目#xff1a;输入为3个文件#xff0c;a.txt 300MB,b.txt 100MB,c.txt 58.MB#xff0c;使用MapReduce的example程序#xff0c;计算Wordcount#xff0c;请问#xff0c;应该有多少个MapTask#xf…在正文开始之前请先来回答一下这个问题 题目输入为3个文件a.txt 300MB,b.txt 100MB,c.txt 58.MB使用MapReduce的example程序计算Wordcount请问应该有多少个MapTaskA、5       B、4       C、3       D、2 这是一个MR知识点中非常简单的一个问题其中涉及到的知识点大概如下 1.HDFS Block拆分为啥是128MB HDFS选择将数据块的默认大小设置为128MB有以下几个原因 1.减少元数据开销较大的数据块大小可以减少元数据metadata的数量因为元数据存储了文件的信息如文件名、权限和数据块的位置等。较小的数据块会导致更多的元数据增加了管理和存储的开销。 2.提高数据传输效率较大的数据块可以提高数据传输的效率。在Hadoop集群中数据块是以流的方式进行传输的较大的数据块可以减少寻址和传输的开销提高数据的读取和写入速度。 3.适应大规模数据处理HDFS主要用于大规模数据处理如大数据分析和批处理作业。较大的数据块可以更好地适应这些大规模数据处理需求减少了数据切分和处理的开销。 2.MR对于输入数据的拆分 在 MapReduce 中Map 操作的输入拆分格式取决于使用的输入格式。以下是常见的输入拆分格式 1.TextInputFormat将输入拆分为按行划分的文本块。每个 Map 任务处理一行或多行文本。 2.KeyValueTextInputFormat类似于 TextInputFormat但将每行拆分为键值对。键和值之间使用分隔符进行分割。 3.SequenceFileInputFormat将输入拆分为 SequenceFile 格式的块。SequenceFile 是一种二进制文件格式可存储键值对。 4.NLineInputFormat将输入拆分为固定数量的行块。每个 Map 任务处理一块。 5.CombineTextInputFormat将小文件组合成更大的输入拆分块以减少 Map 任务的数量。这样可以提高作业的整体性能。 这些输入拆分格式的选择取决于输入数据的特性和处理需求。可以根据具体的情况选择合适的输入拆分格式来优化 Map 操作的性能。 以上都是大家在各个平台所能看到的理论答案直接拿出来给大家做科普那就太没诚意了。我们今天就来点实操性的实践出真知。 1.Map Task个数验证 根据以上题目内容咋们来制造一波测试数据集按照题目设定搞来三个文件分别大小如下 [rootbigdata input]# du -h * 299M  a.txt 100M  b.txt58M   c.txt 数据来源说明下载的是《西游记》电子txt版单个文件大概是3MB左右然后使用追加的方式累计文件中。 我们将这个数据上传到HDFS运行一波看看这个有多少个Map个数。 #数据上传到DHFS hdfs dfs -put input /apps/mapreduce/#运行测试命令hadoop jar ./hadoop-mapreduce-examples-3.3.4.jar    \wordcount    \/apps/mapreduce/input    \/apps/mapreduce/output 运行结果结果如下图展示其中Map个数为5Reduce为1所以开头的答案是A请问您答对了吗 下图是使用Yarn UI2 看到的页面这样更直观知道每个task任务的执行流程。 接下来你是不是觉得我应该写为啥是5为啥是1呢恭喜您猜错了还是太年轻这东西值得我拿出来在公众号做分享吗会被其他同行看不起的。咋们要讲就要讲实际能用的和工作相关的。 2.存储结构对比验证 在实际工作中遇上题目这种a、b、c的情况比较少但是分析一个???MB左右的数据却经常遇到。接下来分析一个同样的458MB的文件但是这里的文件存储结构是3MB * 153个那么又会发生这么样的故事呢 数据准备将我们准备好的单个3MB的文件循环copy并编号1-153输入到input2文件夹。简单的shell大家自己脑补下毕竟这不是今天的重点。完成后的数据格式如下 接下来上传数据运行测试案例 #数据上传到DHFS hdfs dfs -put input2 /apps/mapreduce/#运行测试命令hadoop jar ./hadoop-mapreduce-examples-3.3.4.jar    \wordcount    \/apps/mapreduce/input2    \/apps/mapreduce/output2 毫无意外这次运行明显慢了很多运行的结果情况如下 UI2任务流程图 对比两次任务执行时间第一次为33s第二次为139s,同样的大小的数据居然差了4.21倍。这是啥概念如果不是很明白那就换个说法加大点时间老板让你去写个分析SQL别人上午写下午出结果而你上午写让他明天等结果…,那么恭喜你你在老板的小本本里面了。 你以为这就完了NO因为在实际企业中没几个正常人写MR都是些SQL那么我们来看看同样分析458MB的数据Aa、b、c存储法B3 mb * 153存储法两种存储结构带来的花销是一样的吗 3.Hive分区中结构对比实验 接下来我们就使用同样的SQL分析同样大小的数据但是因为存储结构的不同给运行带来的影响。 首先创建一个实验表 --创建表 CREATE EXTERNAL TABLE IF NOT EXISTS student.student0(  id string comment 学号,  name string comment 姓名,  sex string comment 性别,  age int comment 年龄,  department string comment 班级)  partitioned by(dt string)  ROW FORMAT DELIMITED FIELDS TERMINATED BY |  LINES TERMINATED BY \n; 验证下数据存储情况 --插入数据 insert into student.student0 values (965,maoshu.ran,男,18,Shanghai,2023-06-27);--查看数据信息与存储结构 hdfs dfs -get /warehouse/tablespace/external/hive/student.db/student0/dt2023-06-27/000000_0--查看数据内容965|maoshu.ran|男|18|Shanghai 接下来我们就按上面的存储结构“965|maoshu.ran|男|18|Shanghai”制造一波测试案例数据。经过测试大概75000条数据存储为3MB。我们先生成单个3MB文件在批量叠加。 #单个3MB数据生产 for i in {0..75000}; do echo 20230627printf %06d\n $i|maoshu.ran|男|18|Shanghai000000_0.txt; done#创建数据集存储目录mkdir dt2023-06-27mkdir dt2023-06-28#数据集A制作cat 000000_0.txt dt2023-06-27/000000_0.txtcat 000000_0.txt dt2023-06-27/000000_0.txt... #数据集B制作 sed s/20230627/20230628/g -i 000000_1.txtfor i in {1..157}; do cp 000000_1.txt dt\2023-06-28/000000_$i.txt; done 最后整个目录结构和文件结构如下 将数据上传到hive数据目录并确认数据是否能够读取到。 #数据上传到hdfs hdfs dfs -put dt\2023-06-27 /warehouse/tablespace/external/hive/student.db/student0hdfs dfs -put dt\2023-06-28 /warehouse/tablespace/external/hive/student.db/student0/#刷新hive分区到hive命令行中MSCK REPAIR TABLE student0;show partitions student0; OK dt2023-06-27 dt2023-06-28 接下来写SQL验证太难的SQL笔者不会写因为“懒”我们就写最简单的count(*) 测试结果前确认下输入模式: 确认下输入格式 Hive set hive.input.formathive.input.formatorg.apache.hadoop.hive.ql.io.CombineHiveInputFormat; 发现默认使用的是CombineHiveInputFormat,看来HIVE很有先见之明啊。我们先用这个模式跑下验证 进行场景A验证 select count(*) from student0 where dt2023-06-27; 其运行的流程图如下3个Map1个reduce总执行时间是39.959s 进行场景B验证 select count(*) from student0 where dt2023-06-28;47.341 执行时间是47.341s使用了Combine模式这个Task个数明显小于153效果还是很明显的。但是很明显执行时间和task个数均比场景A多。 接下来我们切换为MR中默认的TextInputFormat看看 set hive.input.formatorg.apache.hadoop.mapred.TextInputFormat;运行统计命令如上其结果有点飘 场景A运行情况 场景B运行情况 虽然运行情况不太如愿但是也能看出来情景B的Task个数明显多于场景A。 4.总结 在我们的整个验证过程中 Hive中的SQL演示在日常的数据分析工作中是很常见的。同样的SQL同样规模数据为啥运行时间不一样可能并不是因为你写的SQL有问题不妨思考下会不会是底层存储的问题 所以课后作业来了HDFS 小文件会带来哪些影响