通用大数据存储与分析处理平台-Hadoop.docx

通用大数据存储与分析处理平台总体建设方案(Hadoop)目录1Hadoop11.1概述11.1.1Hadoop能做什么11.2特点11.3软件设计11.3.1Hadoop 中的文件格式11.3.2机架感知101.4Hadoop知识学习篇111.4.1RPC111.4.2Avro、Thrift111.4.3Java接口111.4.4FileSystem总结11.4.5文件读取过程/文件写入过程41.4.6Hadoop均衡器11.4.7Hadoop存档11.4.8数据完整性31.4.9压缩41.4.10序列化【优点】61.4.11序列化框架111.4.12MapReduce过程中的序列化与反序列化201.4.13HDFS数据结构251.4.14MapReduce框架261.4.15MapReduce工作机制391.4.16推测执行【优点】421.4.17重用JVM【优化】431.4.18IDS431.4.19输入格式431.4.20输出格式151.4.21计数器201.4.22排序技术241.4.23连接331.4.24DistributedCache381.4.25作业链接421.4.26默认的MapReduce作业431.4.27集群规范431.4.28网络拓扑优点441.4.29环境设置481.4.30守护进程的关键属性491.4.31安全性531.4.32安全模式531.4.33fsck工具531.4.34日常维护551.5Hadoop知识总结篇571.5.1Hadoop通信协议总结571.5.2通过日志掌握Hadoop运行过程（HDFS/MAPREDUCE）11.5.3MapReduce配置调优11.5.4MapReduce过程配置11.6应用程序运行JOB21.7Hadoop源码篇22Accumulo43海量数据查询支撑分系统43.1Dremel43.1.1概述43.1.2软件设计53.1.3一句话总结93.2Drill93.2.1概述93.3Tez103.4Impala*143.5Tajo*143.6序列化框架与RPC153.6.1Avro153.6.2Protocol153.6.3Thrift153.7缓存154算法研究*164.1BloomFilter164.1.1集合表示和元素查询164.1.2错误率估计174.1.3最优的哈希函数个数184.1.4位数组的大小184.1.5总结194.2Bit Map（BitSet）204.2.1Bit Map的基本思想204.2.2Map映射表224.2.3位移转换224.2.4扩展254.2.5Bit-Map的应用254.2.6Bit-Map的具体实现254.3哈希算法324.4二叉树434.5堆与堆排序434.6双层桶划分494.7trie树504.8外排序565海量数据处理思路585.1Bloom filter805.2Hashing815.3bit-map825.4堆835.5双层桶划分835.6数据库索引845.7倒排索引(Inverted index)845.8外排序855.9trie树866经典博文88从Hadoop框架与MapReduce模式中谈海量数据处理886.1.1前言886.1.2第一部分、mapreduce模式与hadoop框架深入浅出886.1.3架构扼要886.1.4Mapreduce模式896.1.5Hadoop框架906.1.6Hadoop的组成部分906.1.7第二部分、淘宝海量数据产品技术架构解读学习海量数据处理经验926.1.8淘宝海量数据产品技术架构92mapreduce的二次排序 SecondarySort95V1 Hadoop1.1 概述1.1.1 Hadoop能做什么1、搜索引擎（Doug Cutting 设计Hadoop的初衷，为了针对大规模的网页快速建立索引）。2、大数据存储，利用Hadoop的分布式存储能力，例如数据备份、数据仓库等。3、大数据处理，利用Hadoop的分布式处理能力，例如数据挖掘、数据分析等。4、科学研究，Hadoop是一种分布式的开源框架，对于分布式计算有很大程度地参考价值。 大数据存储 海量数据批量处理：n 排序、连接 n ETL（去重、转化）n 数据挖掘n 日志处理n 用户细分特征建模n 个性化广告推荐n 智能仪器推荐1.2 特点1. 高可靠性。Hadoop按位存储和处理数据的能力值得人们信赖。2. 高扩展性。Hadoop是在可用的计算机集簇间分配数据并完成计算任务的，这些集簇可以方便地扩展到数以千计的节点中。3. 高效性。Hadoop能够在节点之间动态地移动数据，并保证各个节点的动态平衡，因此处理速度非常快。4. 高容错性。Hadoop能够自动保存数据的多个副本，并且能够自动将失败的任务重新分配。5. 低成本。与一体机、商用数据仓库以及QlikView、Yonghong Z-Suite等数据集市相比，hadoop是开源的，项目的软件成本因此会大大降低。1.3 软件设计1.3.1 Hadoop 中的文件格式SequenceFile SequenceFile是Hadoop API 提供的一种二进制文件，它将数据以的形式序列化到文件中。这种二进制文件内部使用Hadoop 的标准的Writable 接口实现序列化和反序列化。它与Hadoop API中的MapFile 是互相兼容的。Hive 中的SequenceFile 继承自Hadoop API 的SequenceFile，不过它的key为空，使用value 存放实际的值， 这样是为了避免MR 在运行map 阶段的排序过程。如果你用Java API 编写SequenceFile，并让Hive 读取的话，请确保使用value字段存放数据，否则你需要自定义读取这种SequenceFile 的InputFormat class 和OutputFormat class。图1：Sequencefile 文件结构SequenceFile读写实例private static final String DATA =One,Two,buckle my shoe,Three,four,shut the door,File,six,pick up sticks,Seven,eight,lay them straight,Nie,ten,a big fat hen;public static void writeToHDFS(String args) throws IOException for(int j=1;j=5;j+)String uri =hdfs:/mylinux:9000/data/exam/seqfiles/seq_+System.currentTimeMillis();Configuration conf =new Configuration();FileSystem fs = FileSystem.get(URI.create(uri),conf);Path path =new Path(uri);IntWritable key = new IntWritable();Text value =new Text();SequenceFile.Writer writer= null;writer =SequenceFile.createWriter(fs, conf, path, key.getClass(), value.getClass();for(int i=0;i+value);RCFile RCFile是Hive推出的一种专门面向列的数据格式。 它遵循“先按列划分，再垂直划分”的设计理念。当查询过程中，针对它并不关心的列时，它会在IO上跳过这些列。需要说明的是，RCFile在map阶段从远端拷贝仍然是拷贝整个数据块，并且拷贝到本地目录后RCFile并不是真正直接跳过不需要的列，并跳到需要读取的列， 而是通过扫描每一个row group的头部定义来实现的，但是在整个HDFS Block 级别的头部并没有定义每个列从哪个row group起始到哪个row group结束。所以在读取所有列的情况下，RCFile的性能反而没有SequenceFile高。图2：RCFile 文件结构3 AvroAvro是一种用于支持数据密集型的二进制文件格式。它的文件格式更为紧凑，若要读取大量数据时，Avro能够提供更好的序列化和反序列化性能。并且Avro数据文件天生是带Schema定义的，所以它不需要开发者在API 级别实现自己的Writable对象。最近多个Hadoop 子项目都支持Avro 数据格式，如Pig 、Hive、Flume、Sqoop和Hcatalog。图3：Avro MR 文件格式4. 文本格式除上面提到的3种二进制格式之外，文本格式的数据也是Hadoop中经常碰到的。如TextFile 、XML和JSON。 文本格式除了会占用更多磁盘资源外，对它的解析开销一般会比二进制格式高几十倍以上，尤其是XML 和JSON，它们的解析开销比Textfile 还要大，因此强烈不建议在生产系统中使用这些格式进行储存。 如果需要输出这些格式，请在客户端做相应的转换操作。 文本格式经常会用于日志收集，数据库导入，Hive默认配置也是使用文本格式，而且常常容易忘了压缩，所以请确保使用了正确的格式。另外文本格式的一个缺点是它不具备类型和模式，比如销售金额、利润这类数值数据或者日期时间类型的数据，如果使用文本格式保存，由于它们本身的字符串类型的长短不一，或者含有负数，导致MR没有办法排序，所以往往需要将它们预处理成含有模式的二进制格式，这又导致了不必要的预处理步骤的开销和储存资源的浪费。5. 外部格式Hadoop实际上支持任意文件格式，只要能够实现对应的RecordWriter和RecordReader即可。其中数据库格式也是会经常储存在Hadoop中，比如Hbase，Mysql，Cassandra，MongoDB。 这些格式一般是为了避免大量的数据移动和快速装载的需求而用的。他们的序列化和反序列化都是由这些数据库格式的客户端完成，并且文件的储存位置和数据布局(Data Layout)不由Hadoop控制，他们的文件切分也不是按HDFS的块大小（blocksize）进行切割。文件存储大小比较与分析我们选取一个TPC-H标准测试来说明不同的文件格式在存储上的开销。因为此数据是公开的，所以读者如果对此结果感兴趣，也可以对照后面的实验自行做一遍。Orders 表文本格式的原始大小为1.62G。 我们将其装载进Hadoop 并使用Hive 将其转化成以上几种格式，在同一种LZO 压缩模式下测试形成的文件的大小。Orders_text117326900451.61G非压缩TextFileOrders_tex2772681211736MLZO压缩TextFileOrders_seq119355135871.80G非压缩SequenceFileOrders_seq2822048201783MLZO压缩SequenceFileOrders_rcfile116487463551.53G非压缩RCFileOrders_rcfile2686927221655MLZO压缩RCFileOrders_avro_table115683593341.46G非压缩AvroOrders_avro_table2652962989622MLZO压缩Avro表1：不同格式文件大小对比从上述实验结果可以看到，SequenceFile无论在压缩和非压缩的情况下都比原始纯文本TextFile大，其中非压缩模式下大11%， 压缩模式下大6.4%。这跟SequenceFile的文件格式的定义有关： SequenceFile在文件头中定义了其元数据，元数据的大小会根据压缩模式的不同略有不同。一般情况下，压缩都是选取block 级别进行的，每一个block都包含key的长度和value的长度，另外每4K字节会有一个sync-marker的标记。对于TextFile文件格式来说不同列之间只需要用一个行间隔符来切分，所以TextFile文件格式比SequenceFile文件格式要小。但是TextFile 文件格式不定义列的长度，所以它必须逐个字符判断每个字符是不是分隔符和行结束符。因此TextFile 的反序列化开销会比其他二进制的文件格式高几十倍以上。RCFile文件格式同样也会保存每个列的每个字段的长度。但是它是连续储存在头部元数据块中，它储存实际数据值也是连续的。另外RCFile 会每隔一定块大小重写一次头部的元数据块（称为row group，由hive.io.rcfile.record.buffer.size控制，其默认大小为4M），这种做法对于新出现的列是必须的，但是如果是重复的列则不需要。RCFile 本来应该会比SequenceFile 文件大，但是RCFile 在定义头部时对于字段长度使用了Run Length Encoding进行压缩，所以RCFile 比SequenceFile又小一些。Run length Encoding针对固定长度的数据格式有非常高的压缩效率，比如Integer、Double和Long等占固定长度的数据类型。在此提一个特例Hive 0.8引入的TimeStamp 时间类型，如果其格式不包括毫秒，可表示为”YYYY-MM-DD HH:MM:SS”，那么就是固定长度占8个字节。如果带毫秒，则表示为”YYYY-MM-DD HH:MM:SS.fffffffff”，后面毫秒的部分则是可变的。Avro文件格式也按group进行划分。但是它会在头部定义整个数据的模式（Schema）， 而不像RCFile那样每隔一个row group就定义列的类型，并且重复多次。另外，Avro在使用部分类型的时候会使用更小的数据类型，比如Short或者Byte类型，所以Avro的数据块比RCFile 的文件格式块更小。序列化与反序列化开销分析我们可以使用Java的profile工具来查看Hadoop 运行时任务的CPU和内存开销。以下是在Hive 命令行中的设置：hiveset file=true;hiveset file.params =-agentlib:hprof=cpu=samples,heap=sites, depth=6,force=n,thread=y,verbose=n,file=%s当map task 运行结束后，它产生的日志会写在$logs/userlogs/job- 文件夹下。当然，你也可以直接在JobTracker的Web界面的logs或jobtracker.jsp 页面找到日志。我们运行一个简单的SQL语句来观察RCFile 格式在序列化和反序列化上的开销：hive select O_CUSTKEY,O_ORDERSTATUS from orders_rc2 where O_ORDERSTATUS=P;其中的O_CUSTKEY列为integer类型，O_ORDERSTATUS为String类型。在日志输出的最后会包含内存和CPU 的消耗。下表是一次CPU 的开销：rankselfaccumcounttracemethod20 0.48%79.64%65315554org.apache.hadoop.hive.ql.io.RCFile$Reader.getCurrentRow280.24%82.07%32315292org.apache.hadoop.hive.serde2.columnar.ColumnarStruct.init550.10%85.98%14315788org.apache.hadoop.hive.ql.io.RCFileRecordReader.getPos560.10%86.08%14315797org.apache.hadoop.hive.ql.io.RCFileRecordReader.next表2：一次CPU的开销其中第五列可以对照上面的Track信息查看到底调用了哪些函数。比如CPU消耗排名20的函数对应Track：TRACE 315554: (thread=200001) org.apache.hadoop.hive.ql.io.RCFile$Reader.getCurrentRow(RCFile.java:1434) org.apache.hadoop.hive.ql.io.RCFileRecordReader.next(RCFileRecordReader.java:88) org.apache.hadoop.hive.ql.io.RCFileRecordReader.next(RCFileRecordReader.java:39)org.apache.hadoop.hive.ql.io.CombineHiveRecordReader.doNext(CombineHiveRecordReader.java:98)org.apache.hadoop.hive.ql.io.CombineHiveRecordReader.doNext(CombineHiveRecordReader.java:42) org.apache.hadoop.hive.ql.io.HiveContextAwareRecordReader.next(HiveContextAwareRecordReader.java:67)其中，比较明显的是RCFile，它为了构造行而消耗了不必要的数组移动开销。其主要是因为RCFile 为了还原行，需要构造RowContainer，顺序读取一行构造RowContainer，然后给其中对应的列进行赋值，因为RCFile早期为了兼容SequenceFile所以可以合并两个block，又由于RCFile不知道列在哪个row group结束，所以必须维持数组的当前位置，类似如下格式定义： ArrayRowContainer extends List而此数据格式可以改为面向列的序列化和反序列化方式。如：Maparray,array,array.这种方式的反序列化会避免不必要的数组移动，当然前提是我们必须知道列在哪个row group开始到哪个row group结束。这种方式会提高整体反序列化过程的效率。关于Hadoop文件格式的思考1 高效压缩Hadoop目前尚未出现针对数据特性的高效编码（Encoding）和解码(Decoding)数据格式。尤其是支持Run Length Encoding、Bitmap 这些极为高效算法的数据格式。HIVE-2065 讨论过使用更加高效的压缩形式，但是对于如何选取列的顺序没有结论。关于列顺序选择可以看Daniel Lemire的一篇论文 Reordering Columns for Smaller Indexes1。作者同时也是Hive 0.8中引入的bitmap 压缩算法基础库的作者。该论文的结论是：当某个表需要选取多个列进行压缩时，需要根据列的选择性(selectivity)进行升序排列，即唯一值越少的列排得越靠前。 事实上这个结论也是Vertica多年来使用的数据格式。其他跟压缩有关的还有HIVE-2604和HIVE-2600。2 基于列和块的序列化和反序列化不论排序后的结果是不是真的需要，目前Hadoop的整体框架都需要不断根据数据key进行排序。除了上面提到的基于列的排序，序列化和反序列化之外，Hadoop的文件格式应该支持某种基于块（Block） 级别的排序和序列化及反序列化方式，只有当数据满足需要时才进行这些操作。来自Google Tenzing论文中曾将它作为MR 的优化手段提到过。“Block Shuffle：正常来说，MR 在Shuffle 的时候使用基于行的编码和解码。为了逐个处理每一行,数据必须先排序。然而，当排序不是必要的时候这种方式并不高效,我们在基于行的shuffle基础上实现了一种基于block的shuffle方式，每一次处理大概1M的压缩block，通过把整个block当成一行，我们能够避免MR框架上的基于行的序列化和反序列化消耗，这种方式比基于行的shuffle 快上3倍以上。”3 数据过滤（Skip List）除常见的分区和索引之外，使用排序之后的块（Block）间隔也是常见列数据库中使用的过滤数据的方法。Google Tenzing同样描述了一种叫做ColumnIO 的数据格式，ColumnIO在头部定义该Block的最大值和最小值，在进行数据判断的时候，如果当前Block的头部信息里面描述的范围中不包含当前需要处理的内容，则会直接跳过该块。Hive社区里曾讨论过如何跳过不需要的块 ，可是因为没有排序所以一直没有较好的实现方式。包括RCFile格式，Hive的index 机制里面目前还没有一个高效的根据头部元数据就可以跳过块的实现方式。4 延迟物化真正好的列数据库，都应该可以支持直接在压缩数据之上不需要通过解压和排序就能够直接操作块。通过这种方式可以极大的降低MR 框架或者行式数据库中先解压，再反序列化，然后再排序所带来的开销。Google Tenzing里面描述的Block Shuffle 也属于延迟物化的一种。更好的延迟物化可以直接在压缩数据上进行操作，并且可以做内部循环， 此方面在论文Integrating Compression and Execution in Column-Oriented Database System5的5.2 章节有描述。 不过考虑到它跟UDF 集成也有关系，所以，它会不会将文件接口变得过于复杂也是一件有争议的事情。5 与Hadoop框架集成无论文本亦或是二进制格式，都只是最终的储存格式。Hadoop运行时产生的中间数据却没有办法控制。包括一个MR Job在map和reduce之间产生的数据或者DAG Job上游reduce 和下游map之间的数据，尤其是中间格式并不是列格式，这会产生不必要的IO和CPU 开销。比如map 阶段产生的spill，reduce 阶段需要先copy 再sort-merge。如果这种中间格式也是面向列的，然后将一个大块切成若干小块，并在头部加上每个小块的最大最小值索引，就可以避免大量sort-mege操作中解压反序列化排序合并（Merge）的开销，从而缩短任务的运行时间。其他文件格式Hadoop社区也曾有对其他文件格式的研究。比如，IBM 研究过面向列的数据格式并发表论文Column-Oriented Storage Techniques for MapReduce4，其中特别提到IBM 的CIF（Column InputFormat)文件格式在序列化和反序列化的IO消耗上比RCFile 的消耗要小20倍。里面提到的将列分散在不同的HDFS Block 块上的实现方式RCFile 也有考虑过，但是最后因为重组行的消耗可能会因分散在远程机器上产生的延迟而最终放弃了这种实现。此外，最近Avro也在实现一种面向列的数据格式，不过目前Hive 与Avro 集成尚未全部完成。有兴趣的读者可以关注avro-806 和hive-895。总结Hadoop 可以与各种系统兼容的前提是Hadoop MR 框架本身能够支持多种数据格式的读写。但如果要提升其性能，Hadoop 需要一种高效的面向列的基于整个MR 框架集成的数据格式。尤其是高效压缩，块重组（block shuffle），数据过滤（skip list）等高级功能，它们是列数据库相比MR 框架在文件格式上有优势的地方。相信随着社区的发展以及Hadoop 的逐步成熟，未来会有更高效且统一的数据格式出现。1.3.2 机架感知HDFS作为Hadoop中的一个分布式文件系统，而且是专门为它的 MapReduce设计，所以HDFS除了必须满足自己作为分布式文件系统的高可靠性外，还必须为MapReduce提供高效的读写性能，那么HDFS是 如何做到这些的呢？首先，HDFS将每一个文件的数据进行分块存储，同时每一个数据块又保存有多个副本，这些数据块副本分布在不同的机器节点上，这种数据 分块存储+副本的策略是HDFS保证可靠性和性能的关键，这是因为：一.文件分块存储之后按照数据块来读，提高了文件随机读的效率和并发读的效率；二.保 存数据块若干副本到不同的机器节点实现可靠性的同时也提高了同一数据块的并发读效率；三.数据分块是非常切合MapReduce中任务切分的思想。在这 里，副本的存放策略又是HDFS实现高可靠性和搞性能的关键。HDFS采用一种称为机架感知的策略来改进数据的可靠性、可用性和网络带宽的利用率。通过一个机架感知的过程，NameNode可以确定每一个 DataNode所属的机架id(这也是NameNode采用NetworkTopology数据结构来存储数据节点的原因，也是我在前面详细介绍NetworkTopology类 的原因)。一个简单但没有优化的策略就是将副本存放在不同的机架上，这样可以防止当整个机架失效时数据的丢失，并且允许读数据的时候充分利用多个机架的带 宽。这种策略设置可以将副本均匀分布在集群中，有利于当组件失效的情况下的均匀负载，但是，因为这种策略的一个写操作需要传输到多个机架，这增加了写的代 价。在大多数情况下，副本系数是3，HDFS的存放策略是将一个副本存放在本地机架节点上，一个副本存放在同一个机架的另一个节点上，最后一个副本放在不同机 架的节点上。这种策略减少了机架间的数据传输，提高了写操作的效率。机架的错误远远比节点的错误少，所以这种策略不会影响到数据的可靠性和可用性。与此同 时，因为数据块只存放在两个不同的机架上，所以此策略减少了读取数据时需要的网络传输总带宽。在这种策略下，副本并不是均匀的分布在不同的机架上：三分之 一的副本在一个节点上，三分之二的副本在一个机架上，其它副本均匀分布在剩下的机架中，这种策略在不损害数据可靠性和读取性能的情况下改进了写的性能。下 面就来看看HDFS是如何来具体实现这一策略的。1.4 Hadoop知识学习篇1.4.1 Java接口从HDAOOP 的URL中读取数据：FsUrlStreamHandlerFactory实例让java识别Hadoop URL；但Java虚拟机只能调用一次；故使用静态代码。staticURL.setURLStreamHandlerFactory(new FsUrlStreamHandlerFactory();public static void main(String args)String hdfsUri =hdfs:/mylinux:9000/data/mapred/wcout1/1397662485603/part-r-00000;InputStream in =null;try in = new URL(hdfsUri).openStream();IOUtils.copy(in, System.out, 4096); catch (MalformedURLException e) / TODO Auto-generated catch blocke.printStackTrace(); catch (IOException e) / TODO Auto-generated catch blocke.printStackTrace();使用FileSystem API1、获取文件系统实例 static FileSystem get(URI uri, Configuration conf)2、使用open函数获取文件的输入流 FSDataInputStream open(Path f, int bufferSize)3、创建文件 FSDataOutputStream create(Path f,FsPermission permission,boolean overwrite,int bufferSize,short replication,long blockSize,Progressable progress)4、创建目录boolean mkdirs(Path f, FsPermission permission)5、获取文件元数据 abstract FileStatus getFileStatus(Path f)6、列出文件 abstract FileStatus listStatus(Path f)FileStatus listStatus(Path f, PathFilter filter)7、globalStatus（通配）FileStatus globStatus(Path pathPattern)FileStatus globStatus(Path pathPattern, PathFilter filter)表 1通配符及其含义8、删除数据boolean delete(Path f, boolean recursive) 只有recursive 为true时，非空目录才能被删除。9、创建文件并写入数据String localSrc =args0;String dest = args1;InputStream in =new BufferedInputStream(new FileInputStream(localSrc);Configuration conf =new Configuration();FileSystem fs = FileSystem.get(URI.create(dest), conf);OutputStream out =fs.create(new Path(dest),new Progressable()Overridepublic void progress() System.out.print(. ););IOUtils.copyBytes(in, out,4096,true);10、获取数据并输出String uri=hdfs:/mylinux:9000/data/exam/movie10m/users.dat;Configuration conf=new Configuration();try FileSystem fs = FileSystem.get(URI.create(uri), conf);System.out.println(fs.getClass().toString();InputStream in=null;in = fs.open(new Path(uri);IOUtils.copyBytes(in, System.out, conf); catch (IOException e) / TODO Auto-generated catch blocke.printStackTrace();991.4.2 FileSystem总结图 1 FileSystem继承体系FileSystem类详解序号类变化描述1FilterFileSystem该类主要是在其内部定义了一个Filesystem属性：protectedFileSystemfs;它是一个文件系统的实现类，该文件系统包含了一些其他的Filesystem文件系统，并以这些Filesystem文件系统作为基本的文件系统，可能用来转换数据或者提供附加功能。2RawLocalFileSystem增加了static final URI NAME = URI.create(file:/);private Path workingDir; workingDir在该类的构造方法中，通过获取系统的属性“user.dir”属性初始化的：RawLocalFileSystem类是实现了FileSystem的API的一个原生本地文件系统。该类中包含了3个与文件读写相关的内部类，分别为：TrackingFileInputStream类通过继承自基类FileSystem类的Statistics statistics属性，来跟踪文件系统中数据流动。LocalFSFileInputStream类包装了一个FileInputStream流属性，通过构造方法构造一个TrackingFileInputStream来完成输入流的相关操作。LocalFSFileOutputStream类包装了一个FileOutputStream流属性，以来FileOutputStream定义 的操作来实现对文件系统中的输出流的操作。该类还实现了org.apache.hadoop.fs.Syncable接口，使得该文件输出流类能够实现并 调用该接口定义的sync()方法，实现强制对基本设备的缓冲区执行同步操作。还有一个内部类，是封装文件信息的实体类RawLocalFileStatus，实现了getGroup、setOwner与getOwner、 setPermission与getPermission、execCommand等方法，其中set前缀的方法设置对应的信息都是通过执行Shell命 令来实现的；而get前缀的方法获取对应的信息也是通过执行Shell命令，并调用一个私有方法loadPermissionInfo加载必要的信息。另外，RawLocalFileSystem继承实现了FileSystem抽象类中基本的文件操作，例如文件创建、打开、删除等等。3ChecksumFileSystem这个基于校验和文件的文件系统，增加了如下两个属性：private static final byte CHECKSUM_VERSION = new byte c, r, c, 0; private int bytesPerChecksum = 512; private boolean verifyChecksum = true;bytesPerChecksum默认值为512字节，你可以通过配置Hadoop的core-default.xml文件中的I/O属性io.bytes.per.checksum设置；该类是一个基于校验和的文件系统的抽象类，它继承自FilterFileSystem类，它的特点就是在客户端为每一个原生文件（raw file）创建一个校验和文件，扩展名为“.crc”，用它可以校验原生文件的完整性4HarFileSystem private URI uri; /the version of this har filesystem private int version; / underlying uri private URI underLyingURI; private Path archivePath; / the masterIndex of the archive private Path masterIndex; / the index file private Path archiveIndex; / the har auth private String harAuth;HarFileSystem是Hadoop归档文件系统（Hadoop Archive Filesystem）的实现，该文件系统具有索引文件及其相关内容。用来标识归档文件系统的URI的形式如下所示： har:/underlyingfsscheme-host:port/archivepath 或者 har:/archivepath5LocalFileSystemstatic final URI NAME = URI.create(file:/); static private Random rand = new Random(); FileSystem rfs;LocalFileSystem类实现了FileSystem的API，它是一个基于校验和的本地文件系统。通过构造方法可以看到，它是以org.apache.hadoop.fs.RawLocalFileSystem为基本文件系统的；该类实现了ChecksumFileSystem类中定义但未实现的，用于向文件系统报告校验和文件出错的方法，同时把出错的校验和文件重命名后，移动到指定的目录（bad_files）中，在该目录中的文件是不能够被重新使用的文件系统汇总 fs.file.impl org.apache.hadoop.fs.LocalFileSystem