Hadoop-0.20.0源代码分析（17）

最新推荐文章于 2020-09-27 00:58:32 发布
最新推荐文章于 2020-09-27 00:58:32 发布
阅读量417 收藏
点赞数
文章标签： 代码分析 permissions 存储 path byte file
本文深入分析了Hadoop HDFS中与FSEditLog相关的类及其工作原理，包括FSEditLog内部的EditLogFileOutputStream类的继承层次结构、EditLogOutputStream类的统计变量与刷新方法、FSEditLog类的构造方法、创建EditLog日志文件的方法以及相关操作流程。重点阐述了同步操作、文件创建、新文件创建检查、缓冲区准备与刷新等关键步骤。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

继续为分析org.apache.hadoop.hdfs.server.namenode.FSNamesystem类做准备，这里分析与FSEditLog相关的几个类，当然，FSEditLog类才是核心的。

  • FSEditLog.EditLogFileOutputStream内部静态类

该类是定义在org.apache.hadoop.hdfs.server.namenode.FSEditLog类内部的静态类，表示将EditLog日志通过打开一个该输出流实例写入到本地磁盘。该输出流类的继承层次结构如下所示：

[java] view plain copy print ?
  1. ◦java.io.OutputStream(implements java.io.Closeable, java.io.Flushable)  
  2.      ◦org.apache.hadoop.hdfs.server.namenode.EditLogOutputStream  
  3.           ◦org.apache.hadoop.hdfs.server.namenode.FSEditLog.EditLogFileOutputStream  

首先，看EditLogOutputStream这个抽象类的定义。

EditLogOutputStream类是一个用来支持将EditLog日志文件中内容持久化（写入）到存储目录中的通用抽象类。该抽象类定义了两个统计变量，如下所示：

[java] view plain copy print ?
  1. private long numSync;        // 对EditLog日志文件执行同步操作（同步写入磁盘）的次数   
  2. private long totalTimeSync;  // 同步EditLog日志文件到磁盘，所花费的总累加时间  

该抽象类中实现的方法都是与更新统计变量相关的，如下所示：

[c-sharp] view plain copy print ?
  1. /** 
  2.  * 将数据持久化到存储目录，保持数据同步一致，同时刷新统计数据 
  3.  */  
  4. public void flush() throws IOException {  
  5.   numSync++; // 执行该方法一次，则同步数据统计变量加1   
  6.   long start = FSNamesystem.now(); // 此次开始同步的时刻（用来计算此次同步所花费的时间，记入对应统计变量中）   
  7.   flushAndSync(); // 调用刷新与执行同步的操作   
  8.   long end = FSNamesystem.now(); // 此次同步结束时间   
  9.   totalTimeSync += (end - start); // 计算此次同步花费时间，累加到统计变量totalTimeSync上   
  10. }  
  11.   
  12. /** 
  13.  * 获取执行flushAndSync()同步方法花费的总时间 
  14.  */  
  15. long getTotalSyncTime() {  
  16.   return totalTimeSync;  
  17. }  
  18.   
  19. /** 
  20.  * 获取调用flushAndSync()方法执行同步的次数 
  21.  */  
  22. long getNumSync() {  
  23.   return numSync;  
  24. }  
 

该抽象类中定义了一些抽象方法，这些方法需要在该类的子类中给出具体实现：

[java] view plain copy print ?
  1. /** 
  2.  * 获取该EditLogOutputStream输出流的名称 
  3.  */  
  4. abstract String getName();  
  5.   
  6. /** 
  7.  * 该方法继承自OutputStream，表示向该输出流对象中写入字节 
  8.  */  
  9. abstract public void write(int b) throws IOException;  
  10.   
  11. /** 
  12.  * 将EditLog日志记录写入到该输出流对象中 
  13.  * （日志记录通过操作名称和一个Writable参数的数组来表征） 
  14.  */  
  15. abstract void write(byte op, Writable ... writables) throws IOException;  
  16.   
  17. /** 
  18.  * 创建并初始化一个新的EditLog日志存储对象 
  19.  */  
  20. abstract void create() throws IOException;  
  21.   
  22. /** {@inheritDoc} */  
  23. abstract public void close() throws IOException;  
  24.   
  25. /** 
  26.  * 所有已经被写入到该输出流对象中的数据，将准备对其执行刷新（flush）操作。 
  27.  * （在执行刷新的过程中，新的数据仍然能够被写入到该输出流对象中） 
  28.  */  
  29. abstract void setReadyToFlush() throws IOException;  
  30.   
  31. /** 
  32.  * Flush并且sync所有准备好的数据（调用了setReadyToFlush()方法表示准备），持久化到相应的（持久）存储中 
  33.  */  
  34. abstract protected void flushAndSync() throws IOException;  
  35.   
  36. /** 
  37.  * 获取当前EditLog日志文件的大小 
  38.  * 得到EditLog日志文件的长度是为了检查日志文件是否大到需要启动一个检查点进程来处理 
  39.  */  
  40. abstract long length() throws IOException;  

通过对EditLogOutputStream抽象类的分析，我们获知：一个EditLog日志文件也是通过流式进行写的，而且定时对日志文件进行同步，写入持久存储中，其中支持写入字节和Writable类型数据；在同步的过程中，需要记录同步统计数据；当EditLog日志文件达到一定大小的时候，需要启动检查点进程来进行处理。

然后，我们看FSEditLog.EditLogFileOutputStream内部静态类的具体实现。

该类继承自EditLogOutputStream抽象类，实现了该抽象类中定义的抽象方法，能够在一个本地文件（local file）中存储EditLog日志文件。

该类定义了如下属性：

[java] view plain copy print ?
  1. private File file; // EditLog日志文件记录所存储的本地文件   
  2. private FileOutputStream fp;    // 存储EditLog日志记录的文件输出流对象    
  3. private FileChannel fc;         // 执行同步操作（sync）的文件输出流对象对应的通道   
  4. private DataOutputBuffer bufCurrent;  // 当前用于写操作的数据缓冲区   
  5. private DataOutputBuffer bufReady;    // 为了执行写操作而准备的数据缓冲区   
  6. static ByteBuffer fill = ByteBuffer.allocateDirect(512); // 预分配大小为512的字节缓冲区  

下面是FSEditLog.EditLogFileOutputStream类的构造方法：

[java] view plain copy print ?
  1. EditLogFileOutputStream(File name) throws IOException {  
  2.   super();  
  3.   file = name; // EditLog日志文件对应的本地文件名称   
  4.   bufCurrent = new DataOutputBuffer(sizeFlushBuffer); // 分配sizeFlushBuffer = 512*1024   
  5.   bufReady = new DataOutputBuffer(sizeFlushBuffer); // 分配sizeFlushBuffer = 512*1024   
  6.   RandomAccessFile rp = new RandomAccessFile(name, "rw"); // 根据文件File name创建一个随机读写文件实例   
  7.   fp = new FileOutputStream(rp.getFD()); // 为向fp输出流对象中追加数据而打开该输出流   
  8.   fc = rp.getChannel(); // 获取fp对应的通道   
  9.   fc.position(fc.size()); // 设置输出流通道对应文件流的当前位置   
  10. }  

通过上面的构造方法，可见通过构造方法已经准备好了写EditLog日志文件的条件，定位到EditLog对应于本地存储文件流的当前写入位置，也就是说对日志文件的操作时追加写操作。

下面看该类中实现的方法：

[java] view plain copy print ?
  1. @Override  
  2. String getName() {  
  3.   return file.getPath(); // 返回EditLog日志文件对应的本地存储文件的路径   
  4. }  
  5.   
  6. @Override  
  7. public void write(int b) throws IOException {  
  8.   bufCurrent.write(b); // 将字节写入当前数据缓冲区bufCurrent   
  9. }  
  10.   
  11. @Override  
  12. void write(byte op, Writable ... writables) throws IOException {  
  13.   write(op); // 调用重载的write方法，写入操作名称（其实是一个操作代码）   
  14.   for(Writable w : writables) { // 迭代Writable对象数组   
  15.     w.write(bufCurrent); // 分别写入到前数据缓冲区bufCurrent   
  16.   }  
  17. }  
  18.   
  19. /** 
  20.  * 创建一个空的EditLog日志文件 
  21.  */  
  22. @Override  
  23. void create() throws IOException {  
  24.   fc.truncate(0); // 设置当前文件的大小（如果文件大小大于0，删除文件中的全部字节数据）   
  25.   fc.position(0); // 设置当前写位置（初始化）   
  26.   bufCurrent.writeInt(FSConstants.LAYOUT_VERSION); // 在EditLog日志文件最前面写入版本号   
  27.   setReadyToFlush(); // 设置准备刷新状态   
  28.   flush(); // 执行刷新操作（将版本号写入到输出流中）   
  29. }  
  30.   
  31. @Override  
  32. public void close() throws IOException {  
  33.   // 在所有追加写事务执行flush与sync操作完成以后，该方法被调用   
  34.   int bufSize = bufCurrent.size();  
  35.   if (bufSize != 0) {  
  36.     throw new IOException("FSEditStream has " + bufSize +  " bytes still to be flushed and cannot " + "be closed.");  
  37.   }   
  38.   bufCurrent.close(); // 关闭当前数据缓冲区   
  39.   bufReady.close(); // 关闭预执行flush准备数据缓冲区   
  40.   
  41.   fc.truncate(fc.position()); // 从事务日志中删除最后面的OP_INVALID标记（因为在调用setReadyToFlush方法结束时，写入了OP_INVALID标记）   
  42.   fp.close(); // 关闭EditLog日志文件对应的本地存储文件输出流对象   
  43.     
  44.   bufCurrent = bufReady = null; // 释放   
  45. }  
  46.   
  47. /** 
  48.  * 所有已经被写入到该输出流对象中的数据，将准备对其执行刷新（flush）操作。 
  49.  * （在执行刷新操作的过程中，新的数据仍然能够被写入到该输出流对象中） 
  50.  */  
  51. @Override  
  52. void setReadyToFlush() throws IOException {  
  53.   assert bufReady.size() == 0 : "previous data is not flushed yet";  
  54.   write(OP_INVALID);           // 在文件末尾写入一个标记OP_INVALID   
  55.   DataOutputBuffer tmp = bufReady; // 切换缓冲区：将当前的bufCurrent切换为准备好要执行flush操作的bufReady   
  56.   bufReady = bufCurrent;  
  57.   bufCurrent = tmp;  
  58. }  
  59.   
  60. /** 
  61.  * 将bufCurrent中数据到持久存储中 
  62.  * currentBuffer is not flushed as it accumulates new log records 
  63.  * while readyBuffer will be flushed and synced. 
  64.  */  
  65. @Override  
  66. protected void flushAndSync() throws IOException {  
  67.   preallocate();            // 如果必要的话，为文件预分配内存   
  68.   bufReady.writeTo(fp);     // 将bufReady中数据写入到文件   
  69.   bufReady.reset();         // 重启bufReady数据缓冲区   
  70.   fc.force(false);          // 因为调用preallocate()方法对文件进行了预分配，也就没必要更新该文件元数据信息   
  71.   fc.position(fc.position()-1); // 设置当前写入位置：回退排除文件末尾的标记OP_INVALID   
  72. }  
  73.   
  74. /** 
  75.  * 获取当前EditLog日志文件的大小（包括bufReady与bufCurrent） 
  76.  */  
  77. @Override  
  78. long length() throws IOException {  
  79.   return fc.size() + bufReady.size() + bufCurrent.size(); // 返回文件大小 = 文件实际大小 + bufReady大小 + bufCurrent大小   
  80. }  
  81.   
  82. // 为日志文件预分配一个大数据块   
  83. private void preallocate() throws IOException {  
  84.   long position = fc.position(); // 获取文件当前位置   
  85.   if (position + 4096 >= fc.size()) {  
  86.     FSNamesystem.LOG.debug("Preallocating Edit log, current size " + fc.size());  
  87.     long newsize = position + 1024*1024; // 1MB   
  88.     fill.position(0); // 预分配数据缓冲区fill写入位置为0   
  89.     int written = fc.write(fill, newsize); // 为日志文件增加分配newsize个字节   
  90.     FSNamesystem.LOG.debug("Edit log size is now " + fc.size() +  " written " + written + " bytes " + " at offset " +  newsize);  
  91.   }  
  92. }  
  93.   
  94. /** 
  95.  * 获取与该输出流相关联的文件 
  96.  */  
  97. File getFile() {  
  98.   return file;  
  99. }  

通过对上面方法的阅读分析，可以了解到，EditLog日志文件是与本地磁盘上的一个文件相对应的，实际也是写入到这个本地文件中的。在执行流式追加写的过程中，设置了两个重要的数据缓冲区，bufReady 与bufCurrent，通过切换这两个数据缓冲区来将不断追加写入到EditLogFileOutputStream流对象中的数据，同步到本地磁盘文件中。而且，当执行flushAndSync方法进行同步时候，如果必要会对EditLog日志文件对应的本地文件进行预分配，保证可持续做好写事务操作的记录。

  • FSEditLog.EditLogFileInputStream内部静态类

该类org.apache.hadoop.hdfs.server.namenode.FSEditLog.EditLogFileInputStream是对EditLog日志文件进行读取的输入流实现类。该输入流类与EditLogFileOutputStream输出流类的组织关系类似，它的继承层次关系如下所示：

[java] view plain copy print ?
  1. ◦java.io.InputStream(implements java.io.Closeable)  
  2.      ◦org.apache.hadoop.hdfs.server.namenode.EditLogInputStream  
  3.           ◦org.apache.hadoop.hdfs.server.namenode.FSEditLog.EditLogFileInputStream  

首先，看抽象流类EditLogInputStream。该类是一个用来支持读取本地存储目录中对应的文件，从而得到EditLog日志文件的通用抽象类。该抽象类比较简单，定义获取继承了一组抽象方法，如下所示：

[java] view plain copy print ?
  1. /** 
  2.  * 获取该输入流的名称 
  3.  */  
  4. abstract String getName();  
  5.   
  6. /** 
  7.  * 估算大概存在多少字节可读的数据 
  8.  */  
  9. public abstract int available() throws IOException;  
  10.   
  11. /** 
  12.  * 从该输入流中读取下一个字节的数据 
  13.  */  
  14. public abstract int read() throws IOException;  
  15.   
  16. /** 
  17.  * 从该输入流off位置读取len个字节到字节数组b中 
  18.  */  
  19. public abstract int read(byte[] b, int off, int len) throws IOException;  
  20.   
  21. /** 
  22.  * 关闭该输入流，释放相关资源 
  23.  */  
  24. public abstract void close() throws IOException;  
  25.   
  26. /** 
  27.  * 获取当前EditLog日志文件的大小 
  28.  */  
  29. abstract long length() throws IOException;  

没什么可说的，继续看FSEditLog.EditLogFileInputStream内部静态类的具体实现吧。

FSEditLog.EditLogFileInputStream内部静态类也比较简单，就是提供了对EditLog日志文件的读取操作，也是基于流的，该类源代码如下所示：

[java] view plain copy print ?
  1. static class EditLogFileInputStream extends EditLogInputStream {  
  2.   private File file; // EditLog日志文件对应的本地文件   
  3.   private FileInputStream fStream; // 文件file对应的输入流对象   
  4.   
  5.   EditLogFileInputStream(File name) throws IOException { // 构造方法   
  6.     file = name;  
  7.     fStream = new FileInputStream(name); // 构造file的输入流实例   
  8.   }  
  9.   
  10.   @Override  
  11.   String getName() { // 获取file的路径   
  12.     return file.getPath();  
  13.   }  
  14.   
  15.   @Override  
  16.   public int available() throws IOException {  
  17.     return fStream.available(); // 获取从该输入流可以读取到的字节数   
  18.   }  
  19.   
  20.   @Override  
  21.   public int read() throws IOException {  
  22.     return fStream.read(); // 从该输入流中读取一个字节的数据   
  23.   }  
  24.   
  25.   @Override  
  26.   public int read(byte[] b, int off, int len) throws IOException {  
  27.     return fStream.read(b, off, len); // 将该输入流中从off位置开始读取len个字节到字节数组b中   
  28.   }  
  29.   
  30.   @Override  
  31.   public void close() throws IOException {  
  32.     fStream.close(); // 关闭该输入流   
  33.   }   
  34.   
  35.   @Override  
  36.   long length() throws IOException {  
  37.     return file.length(); // 返回文件大小 = 文件实际大小 + bufReady大小 + bufCurrent大小   
  38.   }  
  39. }  

  • FSEditLog类

该类维护一个记录对文件系统命名空间进行修改操作的日志文件。

我们已经对FSEditLog.EditLogFileOutputStream类与FSEditLog.EditLogFileInputStream类非常熟悉了，它们是与EditLog日志文件的读写密切相关的。

在FSEditLog类内部还有一个实现了Writable接口的可序列化内实体类FSEditLog.BlockTwo，它能够从以旧格式存储的块中读写数据，如下所示：

[java] view plain copy print ?
  1. static class BlockTwo implements Writable {  
  2.   long blkid; // 块ID   
  3.   long len; // 块长度   
  4.   
  5.   static {                                      // 注册   
  6.     WritableFactories.setFactory  
  7.       (BlockTwo.class,  
  8.        new WritableFactory() {  
  9.          public Writable newInstance() { return new BlockTwo(); }  
  10.        });  
  11.   }  
  12.   
  13.   
  14.   BlockTwo() {  
  15.     blkid = 0;  
  16.     len = 0;  
  17.   }  
  18.   
  19.   public void write(DataOutput out) throws IOException {  
  20.     out.writeLong(blkid);  
  21.     out.writeLong(len);  
  22.   }  
  23.   
  24.   public void readFields(DataInput in) throws IOException {  
  25.     this.blkid = in.readLong();  
  26.     this.len = in.readLong();  
  27.   }  
  28. }  

通过一个BlockTwo对象，能够读写块的ID和块的长度。 

另一个是事务ID的封装内部实体类FSEditLog.TransactionId，表示EditLog日志文件记录的修改操作这样的事务ID，在FSEditLog类中主要是用来作为当前执行事务的线程对应的线程局部变量的拷贝：ThreadLocal<TransactionId>。该类如下所示：

[java] view plain copy print ?
  1. private static class TransactionId {  
  2.   public long txid;  
  3.   
  4.   TransactionId(long value) {  
  5.     this.txid = value;  
  6.   }  
  7. }  

FSEditLog.TransactionId类只封装了一个事务ID，再没有其它内容了。 

我们再看FSEditLog类。

首先看，对文件系统命名空间进行不同操作的操作代码，通过向EditLog日志文件中写入对应的操作代码来表示实际的操作，这些操作代码包含：

[java] view plain copy print ?
  1. private static final byte OP_INVALID = -1; // 非法操作   
  2. private static final byte OP_ADD = 0; // 添加文件操作   
  3. private static final byte OP_RENAME = 1;  // 重命名   
  4. private static final byte OP_DELETE = 2;  // 删除   
  5. private static final byte OP_MKDIR = 3;   // 创建目录   
  6. private static final byte OP_SET_REPLICATION = 4; // 设置副本因子   
  7. // 下面两个仅仅为了保证后向兼容   
  8. @Deprecated private static final byte OP_DATANODE_ADD = 5;  
  9. @Deprecated private static final byte OP_DATANODE_REMOVE = 6;  
  10. private static final byte OP_SET_PERMISSIONS = 7; // 设置权限   
  11. private static final byte OP_SET_OWNER = 8; // 设置属主   
  12. private static final byte OP_CLOSE = 9;    // 写操作完成后的关闭操作   
  13. private static final byte OP_SET_GENSTAMP = 10;    // 存储时间戳   
  14. // 下面两个已经不再使用，如果LAST_UPGRADABLE_LAYOUT_VERSION等于-17或者更新，则可以删除掉   
  15. private static final byte OP_SET_NS_QUOTA = 11; // 设置文件系统命名空间配额   
  16. private static final byte OP_CLEAR_NS_QUOTA = 12; // 清除文件系统命名空间配额   
  17. private static final byte OP_TIMES = 13; // 为一个文件设置mod & access时间   
  18. private static final byte OP_SET_QUOTA = 14; // 设置名称和磁盘配额  

再看该类中定义的其它属性，如下所示：

[java] view plain copy print ?
  1. private static int sizeFlushBuffer = 512*1024; // 数据缓冲区大小，主要是写日志文件过程中为两个执行切换的数据缓冲区分配大小   
  2. private ArrayList<EditLogOutputStream> editStreams = null; // EditLogOutputStream输出流对象列表   
  3. private FSImage fsimage = null; // FsImage映像   
  4.   
  5. private long txid = 0; // 单调递增事务ID计数器，用来为事务分配ID的   
  6. private long synctxid = 0; // 最后执行sync同步操作的事务ID   
  7. private long lastPrintTime; // 最后一次将统计数据输出到日志文件的时间   
  8. private boolean isSyncRunning; // 是否当前正在执行sync同步操作   
  9.   
  10. private long numTransactions;        // 事务数量统计变量   
  11. private long numTransactionsBatchedInSync; // 批量sync事务的数量的统计变量   
  12. private long totalTimeTransactions;  // 执行全部事务的时间统计变量   
  13. private NameNodeMetrics metrics; // Namenode统计数据的统计变量   
  14.   
  15. // 存储线程的当前事务   
  16. private static final ThreadLocal<TransactionId> myTransactionId = new ThreadLocal<TransactionId>() {  
  17.   protected synchronized TransactionId initialValue() {  
  18.     return new TransactionId(Long.MAX_VALUE);  
  19.   }  
  20. };  

该类的构造方法如下所示：

[java] view plain copy print ?
  1. FSEditLog(FSImage image) { // 通过FSImage实例来构造，FSImage类会在之后分析   
  2.   fsimage = image;   
  3.   isSyncRunning = false; // 当前没有进行同步sync   
  4.   metrics = NameNode.getNameNodeMetrics(); // 通过Namenode获取到其状态统计数据对象，用来跟踪与EditLog相关的信息（写入Namenode的统计数据对象中）   
  5.   lastPrintTime = FSNamesystem.now(); //  初始化时间   
  6. }  
 

关于一个FSEditLog类的实例能够做哪些事情，我们从该类中挑选几个比较关键的方法来详细解释说明。

1、创建一个EditLog日志文件

如下所示：

[java] view plain copy print ?
  1. public synchronized void createEditLogFile(File name) throws IOException {  
  2.   EditLogOutputStream eStream = new EditLogFileOutputStream(name); // 根据指定的文件名，构造EditLog日志文件的输出流   
  3.   eStream.create(); // 创建EditLog日志文件，并写入版本号LAYOUT_VERSION，同时设置当前待写入的位置   
  4.   eStream.close(); // 关闭输出流   
  5. }  

另外，还有一个用来表示当前最新的edit文件edit.new，当该文件丢失的时候，需要进行创建，该操作对应于方法createNewIfMissing，如下所示：

[java] view plain copy print ?
  1. synchronized void createNewIfMissing() throws IOException {  
  2. or (Iterator<StorageDirectory> it = fsimage.dirIterator(NameNodeDirType.EDITS); it.hasNext();) { // 检查是否edit.new文件丢失   
  3.     File newFile = getEditNewFile(it.next());  
  4.     if (!newFile.exists())  
  5.       createEditLogFile(newFile); // 如果不存在，就调用上面的createEditLogFile创建一个   
  6.   }  
  7. }  
  

2、打开 一个EditLog日志文件

方法open实现了打开日志文件的功能。实际上，当创建一个FSEditLog类的实例以后（通过构造方法构造得到），调用open方法打开一个该文件的输出流，准备后继向流中持续追加日志记录。open方法如下所示：

[java] view plain copy print ?
  1. public synchronized void open() throws IOException {  
  2.   numTransactions = totalTimeTransactions = numTransactionsBatchedInSync = 0; // 初始化这些统计变量   
  3.   if (editStreams == null)  
  4.     editStreams = new ArrayList<EditLogOutputStream>(); // 初始化该日志文件实例的EditLogOutputStream流对象列表   
  5.    // 通过FSImage实例获取到Namenode对应的EDITS类型的存储目录的迭代器实例（因为这是一组存储目录，势必对应用来写EditLog日志的输出流EditLogFileOutputStream列表）   
  6.    // 注意：FSImage实例实际上只拥有一张登记了全部EDITS类型的存储目录的表，至于该存储目录中是否存在对应的文件，在加载的时候回检测出来，并采取相应的策略   
  7.   for (Iterator<StorageDirectory> it = fsimage.dirIterator(NameNodeDirType.EDITS); it.hasNext();) {   
  8.     StorageDirectory sd = it.next();  
  9.     File eFile = getEditFile(sd); // 获取一个EditLog文件   
  10.     try {  
  11.       EditLogOutputStream eStream = new EditLogFileOutputStream(eFile); // 打开该EditLog文件输出流   
  12.       editStreams.add(eStream); // 加入列表   
  13.     } catch (IOException e) {  
  14.       FSNamesystem.LOG.warn("Unable to open edit log file " + eFile);  
  15.       it.remove(); // 如果处理该目录sd发生异常，从存储目录列表中删除该目录sd   
  16.     }  
  17.   }  
  18. }  

调用open方法，其实是从Namenode来加载EditLog日志文件所对应的全部存储目录，并打开每一个与EditLog日志文件相关的本地文件的文件输出流，为了便于FSEditLog类实例管理这些输出流，使用一个ArrayList来存放于内存中。

3、处理输出流IO异常

通过前面分析，一个FSEditLog类的实例维护一个EditLogOutputStream输出流对象列表，那么当某个输出流对象发生IO异常的时候，需要对其作出处理，而不能影响其它事务的执行。 该类中给出了三个处理IO异常的方法，如下所示：

[java] view plain copy print ?
  1. /** 
  2.  * 如果发生与EditLog日志相关的IO异常，会从editStreams列表中删除掉发生IO异常的输出流对象 
  3.  * 第一个：根据输出流对象在editStreams列表中索引来处理 
  4.  */  
  5. synchronized void processIOError(int index);  
  6.   
  7. /** 
  8.  * 如果发生与EditLog日志相关的IO异常，会从editStreams列表中删除掉发生IO异常的输出流对象 
  9.  * 第二个：根据存储目录名称来处理editStreams列表中对应的输出流对象  
  10.  */  
  11. synchronized void processIOError(StorageDirectory sd);  
  12.   
  13. /** 
  14.  * 如果发生与EditLog日志相关的IO异常，会从editStreams列表中删除掉发生IO异常的输出流对象 
  15.  * 第三个：对列表editStreams中的输出流对象进行批量检查并对发生IO异常的输出流对象处理 
  16.  */  
  17. private void processIOError(ArrayList<EditLogOutputStream> errorStreams);  

在FSEditLog类中处理IO异常的时候，还需要将处理的情况报告到FSImage中，因为FSImage也维护了一个指定为要删除的存储目录列表，保证数据状态的同步与一致。

4、加载EditLog日志文件

实现的方法为loadFSEdits方法，因为加载一个EditLog日志文件的时候，需要将对应EditLog日志文件记录内容应用到一个滞留于内存中的结构上，保证内存中对应结构与日志同步。因为该方法比较重要，通过它能够看到如何在日志文件与其对应的内存映像之间进行切换，尽管该方法代码比较多。我还是贴出来分析，能够更好地看到这个过程，加深理解。必要的时候我会对代码行修改，减少显示行数。

loadFSEdits方法实现如下所示：

[java] view plain copy print ?
  1. static int loadFSEdits(EditLogInputStream edits) throws IOException {  
  2.   FSNamesystem fsNamesys = FSNamesystem.getFSNamesystem(); // 获取到一个FSNamesystem对象   
  3.   FSDirectory fsDir = fsNamesys.dir; // 得到一个fsNamesys.dir的引用   
  4.   int numEdits = 0, logVersion = 0;  
  5.   String clientName = null, clientMachine = null, path = null;  
  6.   // 这是一组统计变量   
  7.   int numOpAdd = 0, numOpClose = 0, numOpDelete = 0, numOpRename = 0, numOpSetRepl = 0, numOpMkDir = 0,  
  8.       numOpSetPerm = 0, numOpSetOwner = 0, numOpSetGenStamp = 0, numOpTimes = 0, numOpOther = 0;  
  9.   long startTime = FSNamesystem.now(); // EditLog日志文件开始加载的时间   
  10.   
  11.   DataInputStream in = new DataInputStream(new BufferedInputStream(edits)); // EditLog日志文件对应的输入流   
  12.   try {   
  13.     in.mark(4); // 设置EditLog日志文件输入流当前位置，从而读取日志文件的版本（很可能发生版本号信息丢失的情况）   
  14.     // 如果EditLog日志文件大于2G，调用available方法将会返回一个负数，为了避免不得不调用available方法的情况，设置一个Boolean变量，并指定其值为true   
  15.     boolean available = true;  
  16.     try {  
  17.       logVersion = in.readByte(); // 从输入流中读取版本号信息   
  18.     } catch (EOFException e) {  
  19.       available = false; // 发生异常则置于available为false，表示当前EditLog日志文件不可用（可能日志文件存在问题）   
  20.     }  
  21.     if (available) { // 日志文件可用   
  22.       in.reset(); // 重置   
  23.       logVersion = in.readInt(); // 读取版本号   
  24.       if (logVersion < FSConstants.LAYOUT_VERSION) // 判断读取到的版本号是否合法   
  25.         throw new IOException("Unexpected version of the file system log file: "  + logVersion + ". Current version = " + FSConstants.LAYOUT_VERSION + ".");  
  26.     }  
  27.     assert logVersion <= Storage.LAST_UPGRADABLE_LAYOUT_VERSION : "Unsupported version " + logVersion;  
  28.   
  29.     while (true) {  
  30.       long timestamp = 0, mtime = 0, atime = 0, blockSize = 0;  
  31.       byte opcode = -1;  
  32.       try {  
  33.         opcode = in.readByte(); // 读取一个字节   
  34.         if (opcode == OP_INVALID) { // 因为我们已经知道，在开始写日志的时候，写完版本号以后，可能写入一个字节的OP_INVALID（也就是-1）；并且在写日志过程中，会将这个标记删除掉的，如果没有及时删除掉，很可能在该日志上根本没有事务记录，也可能发生了IO异常   
  35.           FSNamesystem.LOG.info("Invalid opcode, reached end of edit log " + "Number of transactions found " + numEdits);  
  36.           break; // 没有事务记录，直接退出，不再读取EditLog日志文件了   
  37.         }  
  38.       } catch (EOFException e) {  
  39.         break; // 没有事务记录   
  40.       }  
  41.       numEdits++; // 每读取到EditLog日志文件中一个记录的事务，就增加一个计数   
  42.       switch (opcode) { // 根据读取到的操作代码，进行相应的处理   
  43.       case OP_ADD:  
  44.       case OP_CLOSE: { // OP_ADD（添加）或OP_CLOSE（关闭）文件操作   
  45.         int length = in.readInt();  
  46.         if (-7 == logVersion && length != 3|| -17 < logVersion && logVersion < -7 && length != 4 || logVersion <= -17 && length != 5) { // 判断读取到的版本号是否合法   
  47.             throw new IOException("Incorrect data format."  + " logVersion is " + logVersion + " but writables.length is " + length + ". ");  
  48.         }  
  49.         path = FSImage.readString(in); // 读取文件路径   
  50.         short replication = adjustReplication(readShort(in)); // 读取副本数（必要的话需要修改该值）   
  51.         mtime = readLong(in); // 读取文件修改时间   
  52.         if (logVersion <= -17) {  
  53.           atime = readLong(in); // 如果版本号小于-17，读取文件访问时间   
  54.         }  
  55.         if (logVersion < -7) {  
  56.           blockSize = readLong(in); // 读取块大小   
  57.         }  
  58.         Block blocks[] = null;  
  59.         if (logVersion <= -14) {  
  60.           blocks = readBlocks(in); // 读取块列表   
  61.         } else {  
  62.           BlockTwo oldblk = new BlockTwo();  
  63.           int num = in.readInt();  
  64.           blocks = new Block[num];  
  65.           for (int i = 0; i < num; i++) {  
  66.             oldblk.readFields(in);  
  67.             blocks[i] = new Block(oldblk.blkid, oldblk.len, Block.GRANDFATHER_GENERATION_STAMP);  
  68.           }  
  69.         }  
  70.   
  71.         // 旧版本HDFS没有在文件中存储块大小，如果某个文件块多于1个，使用第一个作为块大小，否则使用默认值   
  72.         if (-8 <= logVersion && blockSize == 0) {  
  73.           if (blocks.length > 1) {  
  74.             blockSize = blocks[0].getNumBytes();  
  75.           } else {  
  76.             long first = ((blocks.length == 1)? blocks[0].getNumBytes(): 0);  
  77.             blockSize = Math.max(fsNamesys.getDefaultBlockSize(), first);  
  78.           }  
  79.         }  
  80.            
  81.         PermissionStatus permissions = fsNamesys.getUpgradePermission();  
  82.         if (logVersion <= -11) {  
  83.           permissions = PermissionStatus.read(in); // 读取权限   
  84.         }  
  85.   
  86.         // 读取文件中最后一个块的clientname, clientMachine and block locations   
  87.         if (opcode == OP_ADD && logVersion <= -12) {  
  88.           clientName = FSImage.readString(in);  
  89.           clientMachine = FSImage.readString(in);  
  90.           if (-13 <= logVersion) {  
  91.             readDatanodeDescriptorArray(in);  
  92.           }  
  93.         } else {  
  94.           clientName = "";  
  95.           clientMachine = "";  
  96.         }  
  97.   
  98.         // The open lease transaction re-creates a file if necessary.   
  99.         if (FSNamesystem.LOG.isDebugEnabled()) {  
  100.           FSNamesystem.LOG.debug(opcode + ": " + path + " numblocks : " + blocks.length + " clientHolder " +  clientName + " clientMachine " + clientMachine);  
  101.         }  
  102.         fsDir.unprotectedDelete(path, mtime); // 从namespace中删除该文件，并更新目录配额信息   
  103.   
  104.         // 将path添加到文件树fsDir中   
  105.         INodeFile node = (INodeFile)fsDir.unprotectedAddFile(path, permissions, blocks, replication, mtime, atime, blockSize);  
  106.         if (opcode == OP_ADD) { // 如果是添加操作码   
  107.           numOpAdd++; // 统计   
  108.           INodeFileUnderConstruction cons = new INodeFileUnderConstruction(  
  109.                                     node.getLocalNameBytes(), node.getReplication(), node.getModificationTime(),  
  110.                                     node.getPreferredBlockSize(), node.getBlocks(), node.getPermissionStatus(),  
  111.                                     clientName, clientMachine, null);  
  112.           fsDir.replaceNode(path, node, cons); // 使用cons替换node   
  113.           fsNamesys.leaseManager.addLease(cons.clientName, path); // 将cons加载到内存中，加入到租约管理器中   
  114.         }  
  115.         break;  
  116.       }   
  117.       case OP_SET_REPLICATION: { // 设置副本数操作   
  118.         numOpSetRepl++; // 统计   
  119.         path = FSImage.readString(in); // 读取文件   
  120.         short replication = adjustReplication(readShort(in)); // 读取并调整副本数   
  121.         fsDir.unprotectedSetReplication(path, replication, null); // 更新目录fsDir   
  122.         break;  
  123.       }   
  124.       case OP_RENAME: { // 重命名操作   
  125.         numOpRename++; // 统计   
  126.         int length = in.readInt(); // 读取长度   
  127.         if (length != 3) {  
  128.           throw new IOException("Incorrect data format. " + "Mkdir operation.");  
  129.         }  
  130.         String s = FSImage.readString(in); // 读取源文件名称   
  131.         String d = FSImage.readString(in); // 读取重命名后文件名称   
  132.         timestamp = readLong(in); // 读取重命名文件时间戳   
  133.         FileStatus dinfo = fsDir.getFileInfo(d); // 获取文件d的描述信息   
  134.         fsDir.unprotectedRenameTo(s, d, timestamp); // 更新目录fsDir   
  135.         fsNamesys.changeLease(s, d, dinfo); // 修改租约信息   
  136.         break;  
  137.       }  
  138.       case OP_DELETE: { // 删除操作   
  139.         numOpDelete++; // 统计   
  140.         int length = in.readInt(); // 删除文件名称长度   
  141.         if (length != 2) {  
  142.           throw new IOException("Incorrect data format. " + "delete operation.");  
  143.         }  
  144.         path = FSImage.readString(in); // 读取长度   
  145.         timestamp = readLong(in); // 读取删除文件时间戳   
  146.         fsDir.unprotectedDelete(path, timestamp); // 执行删除   
  147.         break;  
  148.       }  
  149.       case OP_MKDIR: { // 创建目录操作   
  150.         numOpMkDir++; // 统计   
  151.         PermissionStatus permissions = fsNamesys.getUpgradePermission(); // 获取文件系统中路径的默认权限   
  152.         int length = in.readInt();  
  153.         if (-17 < logVersion && length != 2 || <= -17 && length != 3) {  
  154.           throw new IOException("Incorrect data format. " + "Mkdir operation.");  
  155.         }  
  156.         path = FSImage.readString(in); // 读取目录名称   
  157.         timestamp = readLong(in); // 读取创建目录时间戳   
  158.   
  159.         if (logVersion <= -17) {  
  160.           atime = readLong(in);  
  161.         }  
  162.   
  163.         if (logVersion <= -11) {  
  164.           permissions = PermissionStatus.read(in);  
  165.         }  
  166.         fsDir.unprotectedMkdir(path, permissions, timestamp); // 在fsDir目录中创建目录path   
  167.         break;  
  168.       }  
  169.       case OP_SET_GENSTAMP: { // 设置时间戳操作   
  170.         numOpSetGenStamp++; // 统计   
  171.         long lw = in.readLong(); // 读取设置的时间戳   
  172.         fsDir.namesystem.setGenerationStamp(lw); // 在fsDir中设置时间戳   
  173.         break;  
  174.       }   
  175.       case OP_DATANODE_ADD: { // 丢弃的操作码   
  176.         numOpOther++;  
  177.         FSImage.DatanodeImage nodeimage = new FSImage.DatanodeImage();  
  178.         nodeimage.readFields(in);  
  179.         break;  
  180.       }  
  181.       case OP_DATANODE_REMOVE: { // 丢弃的操作码   
  182.         numOpOther++;  
  183.         DatanodeID nodeID = new DatanodeID();  
  184.         nodeID.readFields(in);  
  185.         break;  
  186.       }  
  187.       case OP_SET_PERMISSIONS: { // 设置权限   
  188.         numOpSetPerm++; // 统计   
  189.         if (logVersion > -11)  
  190.           throw new IOException("Unexpected opcode " + opcode  + " for version " + logVersion);  
  191.         fsDir.unprotectedSetPermission(FSImage.readString(in), FsPermission.read(in)); // 在fsDir中同步设置   
  192.         break;  
  193.       }  
  194.       case OP_SET_OWNER: { // 设置属主操作   
  195.         numOpSetOwner++;  
  196.         if (logVersion > -11)  
  197.           throw new IOException("Unexpected opcode " + opcode + " for version " + logVersion);  
  198.         fsDir.unprotectedSetOwner(FSImage.readString(in), FSImage.readString_EmptyAsNull(in), FSImage.readString_EmptyAsNull(in)); // 在fsDir中同步设置属主   
  199.         break;  
  200.       }  
  201.       case OP_SET_NS_QUOTA: { // 设置namespace配额操作   
  202.         if (logVersion > -16) {  
  203.           throw new IOException("Unexpected opcode " + opcode + " for version " + logVersion);  
  204.         }  
  205.         fsDir.unprotectedSetQuota(FSImage.readString(in), readLongWritable(in), FSConstants.QUOTA_DONT_SET); // 在fsDir中同步设置namespace配额   
  206.         break;  
  207.       }  
  208.       case OP_CLEAR_NS_QUOTA: { // 清除namespace配额操作   
  209.         if (logVersion > -16) {  
  210.           throw new IOException("Unexpected opcode " + opcode + " for version " + logVersion);  
  211.         }  
  212.         fsDir.unprotectedSetQuota(FSImage.readString(in), FSConstants.QUOTA_RESET, FSConstants.QUOTA_DONT_SET); // 在fsDir中同步清除namespace配额   
  213.         break;  
  214.       }  
  215.       case OP_SET_QUOTA: // 设置名称和磁盘配额   
  216.         fsDir.unprotectedSetQuota(FSImage.readString(in), readLongWritable(in), readLongWritable(in));   // 在fsDir中同步设置磁盘配额                                      
  217.         break;  
  218.       case OP_TIMES: { // 设置文件的mod & access时间操作   
  219.         numOpTimes++;  
  220.         int length = in.readInt();  
  221.         if (length != 3) {  
  222.           throw new IOException("Incorrect data format. " + "times operation.");  
  223.         }  
  224.         path = FSImage.readString(in);  
  225.         mtime = readLong(in);  
  226.         atime = readLong(in);  
  227.         fsDir.unprotectedSetTimes(path, mtime, atime, true); // 在fsDir上同步设置   
  228.         break;  
  229.       }  
  230.       default: {  
  231.         throw new IOException("Never seen opcode " + opcode);  
  232.       }  
  233.       }  
  234.     }  
  235.   } finally {  
  236.     in.close();  
  237.   }  
  238.   FSImage.LOG.info("Edits file " + edits.getName() + " of size " + edits.length() + " edits # " + numEdits + " loaded in " + (FSNamesystem.now()-startTime)/1000 + " seconds.");  
  239.   
  240.   if (FSImage.LOG.isDebugEnabled()) {  
  241.     FSImage.LOG.debug("numOpAdd = " + numOpAdd + " numOpClose = " + numOpClose   
  242.         + " numOpDelete = " + numOpDelete + " numOpRename = " + numOpRename   
  243.         + " numOpSetRepl = " + numOpSetRepl + " numOpMkDir = " + numOpMkDir  
  244.         + " numOpSetPerm = " + numOpSetPerm   
  245.         + " numOpSetOwner = " + numOpSetOwner  
  246.         + " numOpSetGenStamp = " + numOpSetGenStamp   
  247.         + " numOpTimes = " + numOpTimes  
  248.         + " numOpOther = " + numOpOther);  
  249.   }  
  250.   
  251.   if (logVersion != FSConstants.LAYOUT_VERSION) // 如果版本号不等于LAYOUT_VERSION=-8   
  252.     numEdits++; // 也进行统计   
  253.   return numEdits;  
  254. }  

通过该方法的实现，实际上在从多个EditLog 中读取日志信息的时候，主要是将日志文件中对应的事务，通过FSDirectory fsDir = fsNamesys.dir及时更新到文件系统的目录上，保持数据状态同步一致。

5、其它方法

还有几个方法，分别表示对EditLog日志文件的操作，比如：

关闭日志文件方法rollEditLog，同时创建一个edits.new文件；

删除旧日志文件purgeEditLog方法，同时将edits.new文件重命名为edits；

同步日志文件方法logSync，只对当前线程对日志文件作出的全部修改，同步到日志文件上。

aeh129
关注
Hadoop学习总结之二：HDFS读写过程解析
forfuture1978的专栏
11-10 4851
一、文件的打开 1.1、客户端 HDFS打开一个文件，需要在客户端调用DistributedFileSystem.open(Path f, int bufferSize)，其实现为： public FSDataInputStream open(Path f, int bufferSize) throws IOException {   return new DFSClient.DFSDataInputStream(     
HDFS源码分析(二)-----元数据备份机制
走在前往架构师的路上
08-15 4971
前言在Hadoop中，所有的元数据的保存都是在namenode节点之中，每次重新启动整个集群，Hadoop都需要从这些持久化了的文件中恢复数据到内存中，然后通过镜像和编辑日志文件进行定期的扫描与合并，ok，这些稍微了解Hadoop的人应该都知道，这不就是SecondNameNode干的事情嘛，但是很多人只是了解此机制的表象，内部的一些实现机理估计不是每个人都又去深究过，你能想象在写入编辑日志的过程
Hadoop HDFS源码分析 读取命名空间镜像和编辑日志数据
weixin_30859423的博客
02-22 219
读取命名空间镜像和编辑日志数据 1.读取命名空间镜像 类FSImage是 命名空间镜像的java实现，在源码中，英文注释为， /** * FSImage handles checkpointing and logging of the namespace edits. * */ FSImage.loadFSImage(FSNamesystem, StartupOptio...
Hadoop源码解读
管子（zero）的杂乱空间
01-06 872
Hadoop源代码分析（一） 关键字:分布式云计算 完整文章及图，在我的资源里面，可以去下载。Google的核心竞争技术是它的计算平台。Google的大牛们用了下面5篇文章，介绍了它们的计算设施。 GoogleCluster：http://research.google.com/archive/googlecluster.html Chubby：http://labs.google.c...
Hadoop写文件create代码追踪
qq_29989725的博客
09-08 455
服务端代码分析 NameNodeRpcServer.create方法：namenode所有的rpc响应都由NameNodeRpcServer来处理 1.参数配置及检查 检查namenode的状态 checkNNStartup(); private void checkNNStartup() throws IOException { if (!this.nn.isStarted()) { String message = NameNode.composeNotStart
hdfs-over-ftp-hadoop-0.20.0.rar_ftp_ftpoverhdfs_hdfs文件传入ftp_java
09-14
压缩包子文件 "hdfs-over-ftp-hadoop-0.20.0" 没有提供具体的文件名，但我们可以假设它包含了源代码、文档、配置文件等，这些内容可能包括： 1. **源代码**：实现了FTP与HDFS交互的Java类和库，可能包括FTP服务器的...
Hadoop-0.20.0：从HDFS与MapReduce理解Hadoop框架
Hadoop源代码分析深入探讨了Apache Hadoop框架的核心组件，尤其是其分布式文件系统Hadoop Distributed File System (HDFS)和MapReduce并行计算模型。在Hadoop-0.20.0版本中，Hadoop框架的设计目标是将这两种技术有机...
Hadoop-0.20.0源代码分析（01）
热门推荐
千与的专栏
09-19 1万+
Hadoop 框架是两个模型实现的有机整合，亦即Hadoop分布式文件系统（HDFS）与MapReduce并行编程模型，也就是说，Hadoop框架要能够提供的基本功能就是，在存储系统HDFS上进行MapReduce并行计算，所以，如果想要了解Hadoop框架的工作原理和运行机制，主要从这两个方面着手。其实，Hadoop中MapReduce并行计算应该是在HDFS实现的，因此了解计算所基于HDF
深入解析Hadoop 0.20.0：源代码探索HDFS与MapReduce
Hadoop-0.20.0是Hadoop的一个版本，本文将针对这个版本的源代码进行深入分析，帮助理解Hadoop的工作原理和运行机制。 首先，HDFS是Hadoop的核心组件，它是一个高度容错性的分布式文件系统，设计用于跨大量廉价硬件...
hbase-0.20.0.tar.gz
02-11
在解压"hbase-0.20.0.tar.gz"后，你会得到一个名为"hbase-0.20.0"的目录，里面包含了HBase的源代码、文档、配置文件和示例。你可以通过编译源代码将其部署到Hadoop集群上，或者在本地进行单机测试。配置文件如`conf/...
Hadoop3.2.1 【 HDFS 】源码分析 : 文件系统FSImage解析
张伯毅的专栏
09-27 1万+
FSImage处理检查点和命名空间 edits 的日志记录。
性能调优
liuwei063608的专栏
03-28 3686
目 录 12 性能调优 12.1 配置原则 12.2 Manager 12.2.1 提升Manager配置服务参数的效率 12.2.2 根据集群节点数优化Manager配置 12.3 HBase 12.3.1 提升BulkLoad效率 12.3.2 提升连续put场景性能 12.3.3 Put和Scan性能综合调优 12.3.4 提升实时
hadoop分布式文件系统（HDFS）常用API学习
yyhnap的博客
04-16 2427
1、org.apache.hadoop.fs.FileSystem 范围 方法 返回值 描述 addDelegationTokens(String renewer, Credentials credentials) Token&lt;?&gt;[] 添加新的token，返回所有的token append(Path f) FSData...
hadoop踩坑记录（1）
_Tucci
04-11 5866
windows单机安装hadoop 3.1.0。建议将java换成java8。最开始用的java10各种问题 到hadoop官网下载。 windows的需要下载一个这个https://github.com/steveloughran/winutils；然后根据自己的hadoop版本，替换掉bin中的文件。 然后将hadoop解压。之后将解压目录设置环境变量HADOOP_HOME。然后配置配置...
Hadoop HDFS源码学习笔记（四）
一剪梅
03-13 1730
一、首先根据HDFS的API写一段程序，然后是用Eclipse进行debug 单步跟踪，从而查看源码执行流程： import java.net.URI; import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.fs.FSDataInputStream; import org.apache.hadoop.fs
hadoop源码走读
fangliangjin1_2008的专栏
06-07 1127
引言代码走读的基本路线为：外围资料的查看->对Hadoop项目的整体了解->Block->INode->DataNode->NameNode代码的走读计划大概分为三块：1.      DataNode和NameNode的基本原理，和它们的详细工作机制。2.      HDFS接口的实现。3.      DataNode和NameNode的管理接口，重点在InfoServer。
大数据 （011）Hadoop-MR执行环境之---总述+本地测试环境讲解
张--小涛涛
08-03 2379
总述 上一章中我们是本地开发好打jar包上传至服务器进行执行，但是开发过程中这样显然是行不通的，因此我们需要更多的执行环境。 MR执行环境有两种：本地测试环境，服务器环境 一、本地测试环境 本地开发好环境是在windows下执行的。通过eclipse可以看到执行信息。 二、服务器环境 首先需要在src下放置服务器上...
hadoop文件系统与I/O流
weixin_34257076的博客
04-01 185
本文地址：http://www.cnblogs.com/archimedes/p/hadoop-filesystem-io.html，转载请注明源地址。 hadoop借鉴了Linux虚拟文件系统的概念，引入了hadoop抽象文件系统，并在此基础上，提供了大量的具体文件系统的实现，满足构建于hadoop上应用的各种数据访问需求 hadoop文件系统API hadoop提供一个抽象的文件系统，H...
Hive（十）Hive性能调优总结
weixin_42073629的博客
09-23 760
一、Fetch抓取 1、理论分析 Fetch抓取是指，Hive中对某些情况的查询可以不必使用MapReduce计算。例如：SELECT * FROM employees;在这种情况下，Hive可以简单地读取employee对应的存储目录下的文件，然后输出查询结果到控制台。 在hive-default.xml.template文件中hive.fetch.task.conversion默认是more，老版本hive默认是minimal，该属性修改为more以后，在全局查找、字段查找、limit
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值