SlideShare a Scribd company logo
文档名称:HBase 使用 hadoop 特点分析文档




        HBase 使用 hadoop 特点分析文档



文档版本控制
 文档版本号    日期         作者       审核人    说明
 V0.2                刘景龙




                               -1-
文档名称:HBase 使用 hadoop 特点分析文档




目录
1.     HDFS 设计目标 ........................................................................................................................ 3
2.     HBase 需求分析 ....................................................................................................................... 4
     2.1 随机读 ................................................................................................................................ 4
       2.1.1 数据发送接收 .................................................................................................................. 4
       2.1.2 连接管理 .......................................................................................................................... 4
       2.1.3 连接重用 .......................................................................................................................... 6
       2.1.4 本地文件操作 .................................................................................................................. 6
       2.1.5 Read/pread 使用 ............................................................................................................... 7
       2.1.6 HDFS 块信息预取 ........................................................................................................... 8
       2.1.7 锁控制 .............................................................................................................................. 8
       2.1.8 社区相关动向 .................................................................................................................. 8
     2.2 Append & flush .................................................................................................................. 8
    2.2.1HLog 写入......................................................................................................................... 9
    2.2.2 Mem store flush 过程 ....................................................................................................... 9
  2.3 Client 容错 ....................................................................................................................... 10
3. 总结 ......................................................................................................................................... 10
4. 后续工作计划 ......................................................................................... 错误!未定义书签。
5. 参考文档 ................................................................................................................................. 11
6. 快速索引 ................................................................................................. 错误!未定义书签。




                                                                      -2-
文档名称:HBase 使用 hadoop 特点分析文档




1. HDFS 设计目标

     本文档分析是基于 HBase0.20.4 和 Hadoop0.20.2,主要讨论了 HBase 典型应用场景
   中 hadoop 相关特点,进而整理 HBase 对 HDFS 系统特性的需求,以便完成后期的迁移,
   开展后续工作。对于 hbase 中可采用的相关优化点,暂不予讨论。HDFS 的设计目标主
   要包括以下几方面:
       1. Hardware Failure
       2. Streaming Data Access
       3. Large Data Sets
       4. Simple Coherency Model
       5. Moving Computation is Cheaper than Moving Data
       6. Portability Across Heterogeneous Hardware and Software Platforms
    不难看出最初 HDFS 是针对 mapreduce 设计的,其设计目标主要是针对流式大规模
   数据访问。对比 mapreduce 和 hbase 应用的特点,mapreduce 需求包括以下几个特点[1]:
      1. Mapreduce task 输出数据特点:顺序写。
      2. Mapreduce task 输入数据特点:顺序读。
      3. 通常来讲一个 task 有一个输入,一个输出,平均每个节点有 8-16 个 task。对于
          datanode 来讲,并发 client 相对固定,而且数量较小。
      4. Mapreduce task 可以在任意节点运行。
      HBase 对 HDFS 需求包括以下几点:
     1. 随机读。对应于 HBase 中 get 操作。
     2. Append & flush。Sync 操作的支持,需要保证 HLog 可以被可靠存储。并且在语
         义上保证:
          a) 对文件的 append 不影响之前已经 flush 的数据。如果 append 失败,其他
               reader 能够访问 append 之前 flush(或者 close)的数据。
         b)     flush 可确保数据被持久化存储到 hdfs。
     3. Client 容错。Client 容错是说对于 DFSClient 进行容错处理(该 DFSClient 对应于
         HBase 中的 region server 和 HMaster)   ,在语义上保证 2 点:
          a) 控制 DFSClient 对上层应用 (即:HBase) 抛出异常, 并在 DFSClient 层进行
               fail over 处理
          b) 如果遇到致命错误,需要向 HBase 抛出异常,则需要 HBase 对应节点进行
               出错处理,避免由于个别 exception,导致 HBase 集群不可用的情况。([注]
               致命错误:      会造成 region server down 机,
                                                  并导致 region 在其他 region server
               上加载)


            需求               MR               HBase
            大规模存储
                             √                √
            系统容错
                             √                √
            顺序写
                             √                √


                                    -3-
文档名称:HBase 使用 hadoop 特点分析文档


            顺序读
                             √              √
            随机读              -
                                            √
            client 容错        -
                                            √
            Append & flush   -
                                            √


2. HBase 需求分析

2.1 随机读
   本章我们将分为以下几个主题来展开讨论,目标是分析可能影响延迟的因素,结合当前
实现方式,明确其优缺点。由于 HBase 当前写入模式采取异步写的模式,写入操作会先写
入 memstore,当 memstore 达到一定阈值时进行 flush,写入延迟不大,因此本文档中暂不讨
论写过程。

2.1.1 数据发送接收
    本节我们主要关注的是数据的发送与读取,对于大规模顺序读写(类 mapreduce 应用)                         ,
预取数据会节省大量的网络交互。                 但是对于 HBase 这种随机读/顺序读操作为主的应用而言。
预读机制有可能会造成巨大的资源浪费,并有可能影响操作的实时性。
    当前实现中为了对大规模顺序读性能进行优化,每次读块的时候,datanode 会将当前偏
移量到块结束的全部数据发送给 DFSClient。             多余的数据会存放在 datanode 的 tcp send queue
和 DFSClient 的 tcp receive queue 中,当连接数过多的时候,      有可能造成 DFSClient
                                                                (即: region
server)的 socket OOM。但是这种设计对于连接数较少,大规模顺序读写为主的 mapreduce
应用是有很大好处的,大量的读操作实际并不需要进行网络通信,只需从本地的 buffer 中取
数据即可。但是对于随机读操作,该实现方式将会造成大量多余数据的传输。严重影响每次
操作的延迟。因此,我们有必要更精细的控制 datanode 对 DFSClient 的数据发送。修改的时
候需要注意以下几点:
    a) 尽量不改变现有 HBase 和 HDFS api 接口
    b) datanode 是否需要多发数据,依赖于 client 端的操作模式(顺序读或者随机读)                  ,所
        以是否需要多发数据应通过 client 设置。
    ★★
2.1.2 连接管理
HDFS 中使用的连接包括 2 种,一种是 RPC 调用,另一种是 socket 连接。
1. RPC 分析
        当前实现中,rpc client 使用 rpc 通常有以下 2 种方式。
     a) RPC.waitforProxy
             该调用主要用于 datanode 访问 namenode 时(和 secondary namenode 访问
            namenode 时)   。它封装了 getProxy,与 getProxy 不同的是,它考虑了 namenode
            没 有 启 动 , 或 者 namenode 忙 的 情 况 , catch 住 了 ConnectException ,
            SocketTimeoutException,并进行了无限重试(重试上限为 Long.MAX)
     b) RPC.getProxy

                                   -4-
文档名称:HBase 使用 hadoop 特点分析文档


        该调用主要用于 client 连接 datanode 和 client 连接 namenode 的时候。              后面我们会
  做详细讨论。
        此外当系统 close 或应用结束时,rpc 通信组件中的一些资源需要显式回收。这个操
  作是在 RPC.stopProxy 中完成。这个操作被封装到 FileSystem 的 close()操作中。
       Rpc client 端连接管理中,我们主要关注连接数和重试机制造成的延时。连接数有可
  能会对系统稳定性造成影响,而不恰当的重试机制有可能会造成过多的延迟。
       (1) Rpc 建立连接阶段
        在建立连接的时候,当前实现中,新建 socket 连接会设置以下几个参数:
        a) tcpNoDelay,通过 ipc.client.tcpnodelay 设置, 默认为 false
        b) socket timeout,通过 ipc.ping.interval 设置, 默认为 1 分钟
        c) socket connect() 通过 NetUtils.connect 设置超时,为 20 s
        如果连接失败会进行重试,
        a) 当遇到 SocketTimeoutException 的时候,会 close 掉之前的连接(如果有的话),
  sleep 1 秒,然后进行重试。对于 SocketTimeoutException 的最大重试次数为 45
        b) 当遇到其他 IOException 的时候,会 close 掉之前的连接(如果有的话), sleep 1
  秒 , 然 后 进 行 重 试 。 对 于 其 他 IOException 的 最 大 重 试 次 数 通 过
  ipc.client.connect.max.retries 进行设置, 默认为 10。
        由上可见,对于 rpc 连接对应的机器,最差情况下,会有 (20 + 1) * (45 + 10) = 1155
  s = 19.25 min 的时间花在 rpc 的新建连接上。如果当时对应机器恰好网络繁忙,则有可
  能造成一个 rpc 的延迟超高。
        建议:    可以参考 HADOOP-6889 的思想,          引入 rpc timeout。对于延迟 敏感的应用       (比
  如:HBase)      ,过多的重试次数,有可能会造成响应时间的浪费。
       (2) Rpc 执行阶段
       Rpc client 中最重要的数据结构是 Connection id 到 Connection 对象的 hashmap。其
   中 Connection id 包含了 remote address, port 等信息, Connection 对象包含了 socket
                                                        而
   和由 socket 建立的输入/输出流。
       Rpc client 使用的是短连接,每次 rpc call 会新建一个 socket 连接,在收到 rpc server
   响应的时候关闭连接。rpc 接受响应是通过从 PingInputStream 中读取响应数据来实现,
   PingInputStream 在 读 操 作 中 会 捕 捉                 SocketTimeoutException, 当 出 现
   SocketTimeoutException 的时候,ping 远程机器。如果 ping 不通 rpc server,则 close 掉
   连接,否则重新从 socket 中读取数据。重复以上步骤,直到正常读出数据为止。
        对于 client 或者 datanode 连接 namenode 的时候,如果 namenode 暂时无法访问,
  则集群命名空间暂时不可用,client 有必要一直重试,直到 namenode 可访问为止。至
  于 client 会通过 rpc 连接 datanode,只有当 DFSClient 写数据失败,进行 block recovery
  的时候才会发生。这种情况下,不断重试也是合理的。
        server 端一共有 3 个线程,handler,listener,responser。listener 中用了 select()处
  理 client 端的请求。当 listener 收到一个请求后,accept 该 client 连接,并将该连接注册
  到 read key。在 read 中将数据放入到 call queue 队列中。而 handler 线程则不停的从
  callQueue 中取出 Call 对象执行。处理完成后,调用 responder.doRespond(),将该次 rpc
  的应答放到 responseQueue 中,由 responser 线程的主循环发送应答到 client 端。
        综上,我们可以看到在 RPC 框架中,RPC 调用采用短连接的方式,因此不会由于过
  多连接导致系统稳定性问题。
        RPC 的 fail over 处理方面可以通过以下方式进行优化:在 RPC 连接建立的时候,可
  以通过修改 SocketTimeoutException 的重试次数和 ipc.client.connect.max.retries 来调优打

                                     -5-
文档名称:HBase 使用 hadoop 特点分析文档


      开连接所用时间开销。★
           [注]:该优化对于系统空闲状态时,无优化效果。
2. Socket(由于当前版本 RPC 也是基于 socket 实现,这里我们特指非 RPC 的 socket 应用)
          DFSClient 使用 Socket 主要分为 2 个场景,读和写。
          读操作时连接的建立包括 2 个时机,调用 read() 接口和 pread() 接口。
          当使用 read() 接口时,连接的建立有 2 个入口。
            a) blockSeekTo()的时候,      会将之前 DFSInputStream 已经持有的 socket 关闭。             然后
                 选择合适的 datanode,      建立连接。      如果 blockSeekTo 的 datanode 与之前 datanode
                 相同,则连接建立销毁的时间开销会影响单次操作的延迟。★
            b) 调用 readBuffer 进行实际读数据的时候,如果发生 IOException 异常,(比如:
                 网络超时), 则会通过 blockSeekTo()关闭连接,建立连接。如果此时 DFSClient
                 同 datanode 之间网络不稳定,造成瞬断的情况,有可能造成无谓的重试。对
                 单次读操作的延迟会有影响。 ★
            当使用 pread()接口时,      如果需要的 block 信息没有被预取,              则会 RPC 调用 namenode
       的 getBlockLocation()方法获取块的位置信息。             然后对每一个需要读的块重复以下几步操
       作:
            a) 创建 socket 连接
            b) 进行数据传输
            c) 当数据传输完毕,关闭 socket 连接
          写操作时,DFSClient 仅当分配一个新 block 时会调用 createBlockOutputStream()建立
     一条到第一个 datanode 的 socket 连接。             该连接设置了连接超时和 socket 超时均为 1 分零
     9 秒。 (3000 * nodes.length + dfs.socket.timeout。默认 nodes.length 为 3, dfs.socket.timeout
     为 1 分钟)    ,socket send buffer 为 128K。该连接仅当主动 close 文件和创建连接出错时,
     会被关闭。
          在 HBase 应用中,写文件主要有 2 个时机,mem store flush 和写 HLog。
          Mem store flush 时,会新建一个 HFile,然后将 mem store 中的内容写入 HFile,完成
     flush 后,将文件 close 掉,因此不会造成过多连接。
          创建 region 的时候会新建一个日志文件,DFSClient 保持一条到 datanode 的连接。
     RollWriter()调用时会 close 掉该文件(close 文件操作中会 close 掉 DFSClient 到 datanode
     的连接)Rollwriter 有 2 个触发时机, region 新建的时候
              。                           (1)               (HMaster 启动或者 create table
     的时候)     ,会 new HLog 对象,此时会调用 roll writer,close 掉对应连接。(2) 每小时会进
     行一次日志滚动,这时对应的日志文件会被 close 掉。
          每一个 region server 到 datanode 的连接数上限为该 region server 拥有的 region 数。
     且每小时日志滚动时会将对应连接 close 掉。                     因此,  在写操作时不会造成连接数过多的问
     题。
2.1.3 连接重用
       当前 HDFS 实现中,每个 DFSClient 同 datanode 之间维护一个独立的连接,通过该连接
进行交互通信,在不同 DFSClient 之间连接不进行共享。在 HBase 中,单个 region server 在
scan 的时候,       有可能会打开很多文件            (文件数依赖于 scan 的 region 数和每个 region 的 store
file 数,此时连接的数量是应用相关的)                    。作为平台,有必要在 HDFS 进行连接重用。★★
       相关 patch : HBASE-2492, HDFS-941
2.1.4 本地文件操作
            主要针对 datanode 中 meta 文件和 block 的文件的处理。



                                           -6-
文档名称:HBase 使用 hadoop 特点分析文档


         在 HDFS 读操作中,每次读操作都会 new 一个 BlockSender 对象,在此对象中打开
    block 和 meta 文件,读完一个块的时候,关闭这两个文件。block 读取的策略是从当前
    offset 到块的结束顺序读完全部内容,          并发回给 DFSClient。每次读文件的大小为 64K
                                                              (如
    果 offset 到块结尾不足 64k,则为 block 长度 - 当前 offset) 读的过程中,每
                                                   。
    io.bytes.per.checksum (默认为 512B)
                                   ,进行一次 checksum 校验。
         当前 datanode 实现方式造成性能损耗的地方包括以下几处:
    1. 每读一个块都需要重新打开,关闭 block 和 meta 文件。
        建议: 建立 fd 池,缓存 fd。减少重复打开关闭文件的开销。 ★★
        相关 patch: HDFS-1323
    2. 循环顺序读,且每次读 64k 的方式不适合随机读的方式。
        建议:将 datanode 增加无预读模式或者少量预读(随机读操作有可能会取某个 row
        的多个 version, 多个 version 之间的访问为顺序读,这种情况少量预读有利于提高
        读效率)      ,以减少额外的数据传输开销。 ★★★
    3. 每 512 个字节进行一次 checksum 校验的方式,会浪费大量 cpu 时间。
        建议:io.bytes.per.checksum 约等于一行的长度。由于 HBase 中保证行的原子性。
        Checksum 可以基于行(对于一行做一次 checksum)★

2.1.5 Read/pread 使用
     Read/pread 基本流程请见 6.2。
Pread:
     Pread(是 position read 的简称)是指 int read(long position, byte[] buffer, int offset, int
length)接口。在语义上该函数相当于 seek + read。
     该函数根据要读的数据的 offset 和 readLen,计算出要读的 blockRange。getBlockRange()
这个函数中要判断要读的 blocks 是否在 locatedBlocks 中,如果不在,要向 namenode 查询。
     然后再针对获得的 blockRange 中每个 block 读取数据,选取 datanode,创建连接,对每
个 block 重新生成一个 BlockReader。
 Seek+read:
    此 read 为 int read(byte[] buffer, int offset, int length)接口。默认情况下该函数顺序读,当
需要随机读的时候需要结合 seek()使用。
    在 new BlockReader 的时候,read 会把当前位置到 block 结束的长度传给 datanode,这
样 DataNode 就可以 read ahead,这样由于 tcp buffer 作用可以加快连续读的性能。
    如果 seek 的时候 seek 的目的位置和当前位置在同一个 block 就只需直接读取。如果不
在,则需调用函数 blockSeekTo()建立到目的 datanode 的连接。
    Pread 和 seek+read 主要不同的地方在于 getBlockRange(用于 pread)和 getBlockAt(用
于 read) Pread 中 getBlockRange 是取从当前 position 到 buffer 结束的块位置信息。read 中
        。
的 getBlockAt 是取当前 position 对应的块信息。所以,getBlockRange() 同 getBlockAt() 相比
会获取更多的 block location 信息。对于当前 HBase 应用来讲,buffer 的大小约为 64K(一个
HBase block 的大小)   ,所以 getBlockRange()至多比 getBlockAt()多获取 1 个块的信息。
    如果 buffer 刚好跨过 2 个 HDFS block, pread 需要获取 2 个块的位置信息。
                                             则                         此外,pread
中每次调用都需要调用 getBlockRange()对 cache 中的 block location 信息进行查找。而 read
仅当跨块的时候,才会调用 getBlockAt()在 cache 中寻找 block location 信息。
    综上,read()同 pread()相比节省了 cache 查找的开销和 getBlockRange()多取块的开销。
但由于这两项均为内存操作(pread 至多比 read 多一次 getBlockLocation() RPC 调用)               ,性能
优化空间很小,可暂不优化。

                                         -7-
文档名称:HBase 使用 hadoop 特点分析文档


    相关 patch : HBASE-1505, HBASE-2180
2.1.6 HDFS 块信息预取
    分析:
         评估 dfs.read.prefetch.size 大小对于延迟的影响
         当前 hdfs 会在文件 open 的时候,取一定数量块的位置信息(默认取 10 块)    。
         预取块的特性有利于类 mapreduce 的应用(大规模顺序读写)        ,当大规模顺序读写
    的时候,可以有效减少对 namenode 的 getBlockLocations()调用。但是对于大量随机读操
    作的时候,预取可能会造成对 namenode 的额外压力。
    建议:
         HBase 在使用 DFSClient 的时候,根据应用随机程度设置预取块数。
2.1.7 锁控制
     1.Datanode 中锁机制的分析
     Datanode 中的操作大都需要通过 FSDataset 完成,FSDataset 中的操作会加一把大锁。
每个操作都会锁住整个 FSDataset 对象。定性的,我们可以考虑使用读写锁代替互斥锁。以
减少同步的开销。★
     相关 patch : HDFS-1148

2.1.8 社区相关动向
     在完成了之前的分析,          我们发现社区中有很多聪明的人们在和我们做同样的工作。                        我们
可以通过学习和分析相关的 issue 取其精华。
针对 2.1.4,
     HDFS-1323 将本地对 block 文件和 meta 文件的访问池化,避免重复 open file
     HDFS-1034 Enhance datanode to read data and checksum file in parallel
针对 2.1.3,
  HDFS-380 在 DFSClient pread() 时建立长连接,以提高 hdfs 随机读的性能
  HDFS-1325 设置读 timeout,避免 idle 连接长期占用资源
针对 2.1.2,HADOOP-6889 增加 rpc timeout,修改 rpc 的重试机制
针对 2.1.7,HDFS-1148 Convert FSDataset to ReadWriteLock
其他:
  HDFS-1214 hdfs client metadata cache
  HDFS-516 Low Latency distributed reads
测试相关:
  HADOOP-6637 Benchmark overhead of RPC session establishment
  HDFS-236 Random read benchmark for DFS
迁移相关
  HADOOP-6904, HDFS-1335 使不同版本 DFSClient 和 Namenode 可以互相访问。


2.2 Append & flush
  根据之前的调研,我们整理了有可能需要 append 和 flush 功能的相关应用场景。主要包
括:(注:这里说的 flush 是指通用文件系统语义的 flush 操作,相当于 hdfs 中的 sync)
  1. HLog 写入
    2. Mem store flush
    3. Compaction

                                       -8-
文档名称:HBase 使用 hadoop 特点分析文档


     此外,   需要写文件的场景还包括日志分割。                 但是日志分割的场景主要用于 HMaster 启动
时,使用一次,然后关闭文件。不增加 flush 接口,也不会造成数据丢失。但是按照当前日
志分割的流程:
     1. 打开对应日志文件,将其中内容读入到 queue 中。
     2. 然后将对应日志文件删除
     3. 将 queue 中的数据分发到不同的 HLog 文件中,然后将 HLog close 掉
     在 3 完成之间,就会将之前的日志文件删除,所以有可能造成日志数据丢失,需要修改
HBase 使用方式。★★★
     下面我们分析下以上 3 个相关应用场景中,使用当前版本 hdfs 可能潜在的风险:
2.2.1HLog 写入
     写入 HLog 的场景包括 Delete(), incrementColumnValue(), put()。HLog 的写入就是
append 到 sequence file 一个 key-value 对,该操作本身并不保证数据安全性。当前 HBase 为
了防止日志数据丢失,引入了日志的滚动机制。
     日志滚动的目的主要是保证日志滚动之前的日志可以被可靠存储,删除多余的日志文
件。每个 region server 中有一个 LogRoller 线程,每 hbase.regionserver.logroll.period 进行一
次日志滚动。      (默认 1 小时滚动一次)         。日志滚动所做的事情就是 close()掉之前的日志,并删
除已经 flush 的 log 文件,重新 create 一个 HLog。此外,日志滚动时,会 schedule flush,异
步的将 mem store 中的数据 flush 到 HFile。
     所以,  我们可以认为,       在日志滚动的 1 小时间隔内,           HLog 的数据是不安全的。       如果 region
server down 机,会导致 HLog 数据丢失。
需求功能:     (请参见 HADOOP-1700)★★★
1. 单 Writer 和多个 Reader 可以并发访问。
2. Writer 调用 flush 之后,保证数据被持久化。
3. Writer 频繁 flush 不会对 HDFS 造成过高负载。
4. Reader 可以读取到其 open 之前 flush 的数据。
5. HDFS 不偷偷丢数据。
7. append 之后,之前已经 flush(或者 close)的数据不会丢。
2.2.2 Mem store flush 过程
     在 region server 中有单独一个线程处理 mem store 的 flush。 操作将数据塞到 mem store
                                                        Put
中,当 mem store 的大小满足一定大小(通过 hbase.hregion.memstore.flush.size 配置,默认
为 64M)将数据刷到 hdfs 上。
    每次 Mem flush 操作将 memstore 中的数据写入到 StoreFile 中。对于每个 store,flush 结
束会立即 close 掉对应的 store file,以保证数据安全。
    当之前的 StoreFile 被 close 之后,     会重新打开一个新的 store file,    并从中读取 index 信息。
所以当 mem flush 结束时,region server 会拥有一条到 datanode 的 socket 长连接。
    在 flush 结束的时候,在 HLog 中写入一条 FLUSHCACHE-COMPLETE 记录,只是 append
一个 key-value 到 HLog 中,当前 HDFS 实现并不保证这条记录被持久化。
    由上述过程,我们可以认为在每次 flush mem store 之后,数据是安全的。
    在 flush memstore 过程中,  如果 region server down 机,会导致未 flush 的 store 和 mem store
中的数据丢失。此类错误在其他 region server 接管该 region,replay HLog 的时候,可以修复
丢失数据。
    此外, memstore flush 之前,
          在                     如果 region server 挂掉, 会导致 mem store 中的数据丢失。
但是如果 HLog 已经被持久化,则当 region server 重新启动时,可以通过 replay HLog 完成
数据恢复。

                                      -9-
文档名称:HBase 使用 hadoop 特点分析文档



2.3 Client 容错
  在 mapreduce 计算框架中,如果一个 task 计算失败,框架会将 task 重新启动,所以 task
失效不是个很严重的问题。而对于 HBase 而言,region server 作为 client,如果其失效退出,
将导致某些 region 不可访问,即使其他 region server 重新加载该 region,也会造成一定时间
的系统 down time。
  我们需要做两方面工作:
  1. 优化重试机制,避免一个节点失效导致多次重试失败的情况。 (比如:HDFS-630)
     ★★★
  2. 重新设计 DFSClient 对 Exception 处理的机制。当 DFSClient 重试了 n 次后,当前实
     现会丢出一个 Exception。★★★★
  相关 patch:HDFS-127 HDFS-927


   3. 总结

  本文档中对 HBase 使用 hdfs 相关功能的需求进行了定性的分析汇总。           本文档从随机读,
数据安全,client 容错三方面分析了 HBase 对 HDFS 使用的特性,并对相关功能点进行详细
分析。第二章中列出了需要解决的相关问题,并以红星标出。红星越多则越重要。
  在此我们按照优先级列出当前版本 hdfs 需要改进的地方。
  功能:
  1. Sync() 功能支持(sequence file)
     Sync 操作需要实现以下语义:
     Sequence file 提供 sync() 接口,实现 flush 的语义。
  2. Datanode 多发数据问题
     当前 client 的实现,如果 client 请求一个字节,datanode 会将该字节 offset 到 block
     结尾的全部数据发送给 client。由于 HBase 需要同时满足顺序读和随机读的需求,
     需要通过 client 配置,决定是否多发数据。
  稳定性:
  1. Review DFSClient 异常处理机制 (HDFS-127 HDFS-927)
     在 DFSClient 层保证处理不致命的错误。将致命错误抛出。
      ([注] 致命错误:会造成 region server 进程退出,并导致该 region 在其他 region
      server 上加载。会存在一段时间的 down time。)
  2. Datanode 坏盘导致 region server 退出的问题 (HDFS-630)。
  3. Client 到 datanode 连接数过多问题
     解决方案分为 3 层:
     a) HBase 清理其不需要的资源。包括 close()不需要的文件。
     b) 实现 DFSClient 到 datanode 的连接重用,包括读写。
     c) DFSClient 对未关闭的连接进行回收。避免影响其他应用。
  性能:
   1. 增加 Block sender 本地读 fd 池,避免每次读操作都打开/关闭本地文件。
   2. 合并 meta 和 block 文件,以减少随机读 2 个本地文件造成的磁盘寻道开销。
   3. 文件 open 的时候,加大预取块位置信息的大小。
   4. 如果不改变 datanode 的时候,blockSeekTo 重用之前已有连接。
   5. 改变 io.bytes.per.checksum 减少 checksum 时间花费。

                              - 10 -
文档名称:HBase 使用 hadoop 特点分析文档


    6. 在 FSDataset 中使用读写锁。


   4. 参考文档
   [1] HBase and HDFS by Todd Lipcon of Cloudera
        http://wiki.apache.org/hadoop/HBase/HBasePresentations?action=AttachFile&do=view
        &target=HUG9_HBaseAndHDFS_ToddLipcon_Cloudera.pdf
   [2] http://wiki.apache.org/hadoop/Hbase



   5. 附录

  6.1 相关 jira
      HDFS-1323 将本地对 block 文件和 meta 文件的访问池化,避免重复 open file
      HDFS-1034 Enhance datanode to read data and checksum file in parallel,
      HDFS-380 在 DFSClient pread() 时建立长连接,以提高 hdfs 随机读的性能
      HDFS-1325 设置读 timeout,避免 idle 连接长期占用资源
      HADOOP-6889 增加 rpc timeout,修改 rpc 的重试机制
      HDFS-1148 Convert FSDataset to ReadWriteLock
      HDFS-1214 hdfs client metadata cache
      HDFS-516 Low Latency distributed reads
      HADOOP-6637 Benchmark overhead of RPC session establishment
      HDFS-236 Random read benchmark for DFS
      HADOOP-6904,HDFS-1335 使不同版本 DFSClient 和 Namenode 可以互相访问




                                         - 11 -

More Related Content

What's hot

Web性能测试指标参考v0.2
Web性能测试指标参考v0.2Web性能测试指标参考v0.2
Web性能测试指标参考v0.2beiyu95
 
Hadoop 設定與配置
Hadoop 設定與配置Hadoop 設定與配置
Hadoop 設定與配置
鳥 藍
 
Linux内存管理
Linux内存管理Linux内存管理
Linux内存管理
zijia
 
硬件体系架构浅析
硬件体系架构浅析硬件体系架构浅析
硬件体系架构浅析
frogd
 
Hadoop 簡介 教師 許智威
Hadoop 簡介 教師 許智威Hadoop 簡介 教師 許智威
Hadoop 簡介 教師 許智威
Awei Hsu
 
一次Web性能测试小结
一次Web性能测试小结一次Web性能测试小结
一次Web性能测试小结beiyu95
 
Oracle rac资源管理算法与cache fusion实现浅析
Oracle rac资源管理算法与cache fusion实现浅析Oracle rac资源管理算法与cache fusion实现浅析
Oracle rac资源管理算法与cache fusion实现浅析
frogd
 
Hbase在淘宝的应用与优化 修改
Hbase在淘宝的应用与优化 修改Hbase在淘宝的应用与优化 修改
Hbase在淘宝的应用与优化 修改yp_fangdong
 
Baidu Cloud Foundry
Baidu Cloud FoundryBaidu Cloud Foundry
Baidu Cloud Foundry
James Watters
 
receiving packets faster
receiving packets fasterreceiving packets faster
receiving packets faster
yang peng
 
Dnsse cv9
Dnsse cv9Dnsse cv9
Dnsse cv9
itsuki810
 
大规模数据处理
大规模数据处理大规模数据处理
大规模数据处理Kay Yan
 
Sql调优clustering factor影响数据删除速度一例
Sql调优clustering factor影响数据删除速度一例Sql调优clustering factor影响数据删除速度一例
Sql调优clustering factor影响数据删除速度一例maclean liu
 
SRE 讀書會 Round 4 #37 - DNS 時快時慢,我該怎麼辦
SRE 讀書會 Round 4 #37 - DNS 時快時慢,我該怎麼辦SRE 讀書會 Round 4 #37 - DNS 時快時慢,我該怎麼辦
SRE 讀書會 Round 4 #37 - DNS 時快時慢,我該怎麼辦
HanLing Shen
 
Ted yu:h base and hoya
Ted yu:h base and hoyaTed yu:h base and hoya
Ted yu:h base and hoya
hdhappy001
 
HFile,Compact And Split of HBase
HFile,Compact And Split of HBaseHFile,Compact And Split of HBase
HFile,Compact And Split of HBasejhao niu
 
淘宝图片存储与Cdn系统
淘宝图片存储与Cdn系统淘宝图片存储与Cdn系统
淘宝图片存储与Cdn系统Dai Jun
 

What's hot (17)

Web性能测试指标参考v0.2
Web性能测试指标参考v0.2Web性能测试指标参考v0.2
Web性能测试指标参考v0.2
 
Hadoop 設定與配置
Hadoop 設定與配置Hadoop 設定與配置
Hadoop 設定與配置
 
Linux内存管理
Linux内存管理Linux内存管理
Linux内存管理
 
硬件体系架构浅析
硬件体系架构浅析硬件体系架构浅析
硬件体系架构浅析
 
Hadoop 簡介 教師 許智威
Hadoop 簡介 教師 許智威Hadoop 簡介 教師 許智威
Hadoop 簡介 教師 許智威
 
一次Web性能测试小结
一次Web性能测试小结一次Web性能测试小结
一次Web性能测试小结
 
Oracle rac资源管理算法与cache fusion实现浅析
Oracle rac资源管理算法与cache fusion实现浅析Oracle rac资源管理算法与cache fusion实现浅析
Oracle rac资源管理算法与cache fusion实现浅析
 
Hbase在淘宝的应用与优化 修改
Hbase在淘宝的应用与优化 修改Hbase在淘宝的应用与优化 修改
Hbase在淘宝的应用与优化 修改
 
Baidu Cloud Foundry
Baidu Cloud FoundryBaidu Cloud Foundry
Baidu Cloud Foundry
 
receiving packets faster
receiving packets fasterreceiving packets faster
receiving packets faster
 
Dnsse cv9
Dnsse cv9Dnsse cv9
Dnsse cv9
 
大规模数据处理
大规模数据处理大规模数据处理
大规模数据处理
 
Sql调优clustering factor影响数据删除速度一例
Sql调优clustering factor影响数据删除速度一例Sql调优clustering factor影响数据删除速度一例
Sql调优clustering factor影响数据删除速度一例
 
SRE 讀書會 Round 4 #37 - DNS 時快時慢,我該怎麼辦
SRE 讀書會 Round 4 #37 - DNS 時快時慢,我該怎麼辦SRE 讀書會 Round 4 #37 - DNS 時快時慢,我該怎麼辦
SRE 讀書會 Round 4 #37 - DNS 時快時慢,我該怎麼辦
 
Ted yu:h base and hoya
Ted yu:h base and hoyaTed yu:h base and hoya
Ted yu:h base and hoya
 
HFile,Compact And Split of HBase
HFile,Compact And Split of HBaseHFile,Compact And Split of HBase
HFile,Compact And Split of HBase
 
淘宝图片存储与Cdn系统
淘宝图片存储与Cdn系统淘宝图片存储与Cdn系统
淘宝图片存储与Cdn系统
 

Viewers also liked

Ignite 2016 kiwifoo, Snells Beach, New Zealand
Ignite 2016 kiwifoo, Snells Beach, New ZealandIgnite 2016 kiwifoo, Snells Beach, New Zealand
Ignite 2016 kiwifoo, Snells Beach, New Zealand
Fabiana Kubke
 
CETS 2012, Christine O'Malley, slides for Using Variables in Lectora to Colle...
CETS 2012, Christine O'Malley, slides for Using Variables in Lectora to Colle...CETS 2012, Christine O'Malley, slides for Using Variables in Lectora to Colle...
CETS 2012, Christine O'Malley, slides for Using Variables in Lectora to Colle...
Chicago eLearning & Technology Showcase
 
Hostway StreamPlay Presentation
Hostway StreamPlay PresentationHostway StreamPlay Presentation
Hostway StreamPlay Presentation
Hostway Romania
 
Problem management in Steria operations
Problem management in Steria operationsProblem management in Steria operations
Problem management in Steria operationsAndreas Aasen
 
투이컨설팅 제34회 Y세미나 : 설문결과
투이컨설팅 제34회 Y세미나 : 설문결과투이컨설팅 제34회 Y세미나 : 설문결과
투이컨설팅 제34회 Y세미나 : 설문결과
2econsulting
 
Organigrama original 84813
Organigrama original 84813Organigrama original 84813
Organigrama original 84813
colombiaexclusiva
 
thuoc dan tham qua da
thuoc dan tham qua dathuoc dan tham qua da
thuoc dan tham qua daNgô Định
 
CETS 2012, Susan Fisher, slides for Mobile Decisions: Ensuring the Solution M...
CETS 2012, Susan Fisher, slides for Mobile Decisions: Ensuring the Solution M...CETS 2012, Susan Fisher, slides for Mobile Decisions: Ensuring the Solution M...
CETS 2012, Susan Fisher, slides for Mobile Decisions: Ensuring the Solution M...
Chicago eLearning & Technology Showcase
 
CETS 2013, Greg Owen-Boger, Dale Ludwig, & Seth Kannof, Producing eLearning V...
CETS 2013, Greg Owen-Boger, Dale Ludwig, & Seth Kannof, Producing eLearning V...CETS 2013, Greg Owen-Boger, Dale Ludwig, & Seth Kannof, Producing eLearning V...
CETS 2013, Greg Owen-Boger, Dale Ludwig, & Seth Kannof, Producing eLearning V...
Chicago eLearning & Technology Showcase
 
Ch1
Ch1Ch1
MOLABTVX
MOLABTVXMOLABTVX
MOLABTVX
Nat Pham
 
Davis presentation1 powerpoint fernandez davis
Davis presentation1 powerpoint fernandez davisDavis presentation1 powerpoint fernandez davis
Davis presentation1 powerpoint fernandez davis
LM9
 
Dragon News 2010 No 3
Dragon News 2010 No 3Dragon News 2010 No 3
Dragon News 2010 No 3
bjorn_odenbro
 
X|Media|Lab KL: Animation and Games CALL FOR NOMINATIONS
X|Media|Lab KL: Animation and Games CALL FOR NOMINATIONSX|Media|Lab KL: Animation and Games CALL FOR NOMINATIONS
X|Media|Lab KL: Animation and Games CALL FOR NOMINATIONS
Technopreneurs Association of Malaysia
 
투이컨설팅 제12회 Y세미나 : 설문결과
투이컨설팅 제12회 Y세미나 : 설문결과투이컨설팅 제12회 Y세미나 : 설문결과
투이컨설팅 제12회 Y세미나 : 설문결과
2econsulting
 
V2 digital collaboration
V2 digital collaborationV2 digital collaboration
V2 digital collaboration
Mary Jo Davis
 
Passione portugal 31/08
Passione portugal 31/08Passione portugal 31/08
Passione portugal 31/08
Tr Mais
 
5Q Communications "Less Is More" Lightning Speech (Pecha Kucha)
5Q Communications "Less Is More" Lightning Speech (Pecha Kucha)5Q Communications "Less Is More" Lightning Speech (Pecha Kucha)
5Q Communications "Less Is More" Lightning Speech (Pecha Kucha)
Five Q
 
Java 8 Concurrency Updates
Java 8 Concurrency UpdatesJava 8 Concurrency Updates
Java 8 Concurrency Updates
Damian Łukasik
 
Course module biotech_1_it
Course module biotech_1_itCourse module biotech_1_it
Course module biotech_1_it
rupalidhir
 

Viewers also liked (20)

Ignite 2016 kiwifoo, Snells Beach, New Zealand
Ignite 2016 kiwifoo, Snells Beach, New ZealandIgnite 2016 kiwifoo, Snells Beach, New Zealand
Ignite 2016 kiwifoo, Snells Beach, New Zealand
 
CETS 2012, Christine O'Malley, slides for Using Variables in Lectora to Colle...
CETS 2012, Christine O'Malley, slides for Using Variables in Lectora to Colle...CETS 2012, Christine O'Malley, slides for Using Variables in Lectora to Colle...
CETS 2012, Christine O'Malley, slides for Using Variables in Lectora to Colle...
 
Hostway StreamPlay Presentation
Hostway StreamPlay PresentationHostway StreamPlay Presentation
Hostway StreamPlay Presentation
 
Problem management in Steria operations
Problem management in Steria operationsProblem management in Steria operations
Problem management in Steria operations
 
투이컨설팅 제34회 Y세미나 : 설문결과
투이컨설팅 제34회 Y세미나 : 설문결과투이컨설팅 제34회 Y세미나 : 설문결과
투이컨설팅 제34회 Y세미나 : 설문결과
 
Organigrama original 84813
Organigrama original 84813Organigrama original 84813
Organigrama original 84813
 
thuoc dan tham qua da
thuoc dan tham qua dathuoc dan tham qua da
thuoc dan tham qua da
 
CETS 2012, Susan Fisher, slides for Mobile Decisions: Ensuring the Solution M...
CETS 2012, Susan Fisher, slides for Mobile Decisions: Ensuring the Solution M...CETS 2012, Susan Fisher, slides for Mobile Decisions: Ensuring the Solution M...
CETS 2012, Susan Fisher, slides for Mobile Decisions: Ensuring the Solution M...
 
CETS 2013, Greg Owen-Boger, Dale Ludwig, & Seth Kannof, Producing eLearning V...
CETS 2013, Greg Owen-Boger, Dale Ludwig, & Seth Kannof, Producing eLearning V...CETS 2013, Greg Owen-Boger, Dale Ludwig, & Seth Kannof, Producing eLearning V...
CETS 2013, Greg Owen-Boger, Dale Ludwig, & Seth Kannof, Producing eLearning V...
 
Ch1
Ch1Ch1
Ch1
 
MOLABTVX
MOLABTVXMOLABTVX
MOLABTVX
 
Davis presentation1 powerpoint fernandez davis
Davis presentation1 powerpoint fernandez davisDavis presentation1 powerpoint fernandez davis
Davis presentation1 powerpoint fernandez davis
 
Dragon News 2010 No 3
Dragon News 2010 No 3Dragon News 2010 No 3
Dragon News 2010 No 3
 
X|Media|Lab KL: Animation and Games CALL FOR NOMINATIONS
X|Media|Lab KL: Animation and Games CALL FOR NOMINATIONSX|Media|Lab KL: Animation and Games CALL FOR NOMINATIONS
X|Media|Lab KL: Animation and Games CALL FOR NOMINATIONS
 
투이컨설팅 제12회 Y세미나 : 설문결과
투이컨설팅 제12회 Y세미나 : 설문결과투이컨설팅 제12회 Y세미나 : 설문결과
투이컨설팅 제12회 Y세미나 : 설문결과
 
V2 digital collaboration
V2 digital collaborationV2 digital collaboration
V2 digital collaboration
 
Passione portugal 31/08
Passione portugal 31/08Passione portugal 31/08
Passione portugal 31/08
 
5Q Communications "Less Is More" Lightning Speech (Pecha Kucha)
5Q Communications "Less Is More" Lightning Speech (Pecha Kucha)5Q Communications "Less Is More" Lightning Speech (Pecha Kucha)
5Q Communications "Less Is More" Lightning Speech (Pecha Kucha)
 
Java 8 Concurrency Updates
Java 8 Concurrency UpdatesJava 8 Concurrency Updates
Java 8 Concurrency Updates
 
Course module biotech_1_it
Course module biotech_1_itCourse module biotech_1_it
Course module biotech_1_it
 

Similar to Hbase使用hadoop分析

高性能并发Web服务器实现核心内幕
高性能并发Web服务器实现核心内幕高性能并发Web服务器实现核心内幕
高性能并发Web服务器实现核心内幕ideawu
 
百度系统部分布式系统介绍 马如悦 Sacc2010
百度系统部分布式系统介绍 马如悦 Sacc2010百度系统部分布式系统介绍 马如悦 Sacc2010
百度系统部分布式系统介绍 马如悦 Sacc2010
Chuanying Du
 
Lamp高性能设计
Lamp高性能设计Lamp高性能设计
Lamp高性能设计锐 张
 
Redis介绍
Redis介绍Redis介绍
Redis介绍
zhaolinjnu
 
Hbase架构简介、实践
Hbase架构简介、实践Hbase架构简介、实践
Hbase架构简介、实践
Li Map
 
The Construction and Practice of Apache Pegasus in Offline and Online Scenari...
The Construction and Practice of Apache Pegasus in Offline and Online Scenari...The Construction and Practice of Apache Pegasus in Offline and Online Scenari...
The Construction and Practice of Apache Pegasus in Offline and Online Scenari...
acelyc1112009
 
Cassandra简介.ppt
Cassandra简介.pptCassandra简介.ppt
Cassandra简介.pptjames tong
 
Heartbeat v2 安装和配置原理
Heartbeat v2 安装和配置原理Heartbeat v2 安装和配置原理
Heartbeat v2 安装和配置原理
Pickup Li
 
Hadoop学习总结
Hadoop学习总结Hadoop学习总结
Hadoop学习总结ordinary2012
 
Nosql三步曲
Nosql三步曲Nosql三步曲
Nosql三步曲
84zhu
 
高性能Web服务器Nginx及相关新技术的应用实践
高性能Web服务器Nginx及相关新技术的应用实践高性能Web服务器Nginx及相关新技术的应用实践
高性能Web服务器Nginx及相关新技术的应用实践
self study
 
高性能Web服务器Nginx及相关新技术的应用实践
高性能Web服务器Nginx及相关新技术的应用实践高性能Web服务器Nginx及相关新技术的应用实践
高性能Web服务器Nginx及相关新技术的应用实践
rewinx
 
高性能Web服务器Nginx及相关新技术的应用实践
高性能Web服务器Nginx及相关新技术的应用实践高性能Web服务器Nginx及相关新技术的应用实践
高性能Web服务器Nginx及相关新技术的应用实践Frank Cai
 
大规模数据处理
大规模数据处理大规模数据处理
大规模数据处理airsex
 
Ocean base 千亿级海量数据库-日照
Ocean base 千亿级海量数据库-日照Ocean base 千亿级海量数据库-日照
Ocean base 千亿级海量数据库-日照
Shaoning Pan
 
Ria的强力后盾:rest+海量存储
Ria的强力后盾:rest+海量存储 Ria的强力后盾:rest+海量存储
Ria的强力后盾:rest+海量存储
zhen chen
 
Hacking Nginx at Taobao
Hacking Nginx at TaobaoHacking Nginx at Taobao
Hacking Nginx at Taobao
Joshua Zhu
 
海量日志分析系统实践,Dba
海量日志分析系统实践,Dba海量日志分析系统实践,Dba
海量日志分析系统实践,DbaCevin Cheung
 
ByPat博客出品-高性能Web服务器nginx及相关新技术的应用
ByPat博客出品-高性能Web服务器nginx及相关新技术的应用ByPat博客出品-高性能Web服务器nginx及相关新技术的应用
ByPat博客出品-高性能Web服务器nginx及相关新技术的应用redhat9
 

Similar to Hbase使用hadoop分析 (20)

高性能并发Web服务器实现核心内幕
高性能并发Web服务器实现核心内幕高性能并发Web服务器实现核心内幕
高性能并发Web服务器实现核心内幕
 
百度系统部分布式系统介绍 马如悦 Sacc2010
百度系统部分布式系统介绍 马如悦 Sacc2010百度系统部分布式系统介绍 马如悦 Sacc2010
百度系统部分布式系统介绍 马如悦 Sacc2010
 
Lamp高性能设计
Lamp高性能设计Lamp高性能设计
Lamp高性能设计
 
Redis介绍
Redis介绍Redis介绍
Redis介绍
 
Hbase架构简介、实践
Hbase架构简介、实践Hbase架构简介、实践
Hbase架构简介、实践
 
Hbase
HbaseHbase
Hbase
 
The Construction and Practice of Apache Pegasus in Offline and Online Scenari...
The Construction and Practice of Apache Pegasus in Offline and Online Scenari...The Construction and Practice of Apache Pegasus in Offline and Online Scenari...
The Construction and Practice of Apache Pegasus in Offline and Online Scenari...
 
Cassandra简介.ppt
Cassandra简介.pptCassandra简介.ppt
Cassandra简介.ppt
 
Heartbeat v2 安装和配置原理
Heartbeat v2 安装和配置原理Heartbeat v2 安装和配置原理
Heartbeat v2 安装和配置原理
 
Hadoop学习总结
Hadoop学习总结Hadoop学习总结
Hadoop学习总结
 
Nosql三步曲
Nosql三步曲Nosql三步曲
Nosql三步曲
 
高性能Web服务器Nginx及相关新技术的应用实践
高性能Web服务器Nginx及相关新技术的应用实践高性能Web服务器Nginx及相关新技术的应用实践
高性能Web服务器Nginx及相关新技术的应用实践
 
高性能Web服务器Nginx及相关新技术的应用实践
高性能Web服务器Nginx及相关新技术的应用实践高性能Web服务器Nginx及相关新技术的应用实践
高性能Web服务器Nginx及相关新技术的应用实践
 
高性能Web服务器Nginx及相关新技术的应用实践
高性能Web服务器Nginx及相关新技术的应用实践高性能Web服务器Nginx及相关新技术的应用实践
高性能Web服务器Nginx及相关新技术的应用实践
 
大规模数据处理
大规模数据处理大规模数据处理
大规模数据处理
 
Ocean base 千亿级海量数据库-日照
Ocean base 千亿级海量数据库-日照Ocean base 千亿级海量数据库-日照
Ocean base 千亿级海量数据库-日照
 
Ria的强力后盾:rest+海量存储
Ria的强力后盾:rest+海量存储 Ria的强力后盾:rest+海量存储
Ria的强力后盾:rest+海量存储
 
Hacking Nginx at Taobao
Hacking Nginx at TaobaoHacking Nginx at Taobao
Hacking Nginx at Taobao
 
海量日志分析系统实践,Dba
海量日志分析系统实践,Dba海量日志分析系统实践,Dba
海量日志分析系统实践,Dba
 
ByPat博客出品-高性能Web服务器nginx及相关新技术的应用
ByPat博客出品-高性能Web服务器nginx及相关新技术的应用ByPat博客出品-高性能Web服务器nginx及相关新技术的应用
ByPat博客出品-高性能Web服务器nginx及相关新技术的应用
 

More from baggioss

Hdfs写流程异常处理
Hdfs写流程异常处理Hdfs写流程异常处理
Hdfs写流程异常处理
baggioss
 
Hic 2011 realtime_analytics_at_facebook
Hic 2011 realtime_analytics_at_facebookHic 2011 realtime_analytics_at_facebook
Hic 2011 realtime_analytics_at_facebook
baggioss
 
[Hi c2011]building mission critical messaging system(guoqiang jerry)
[Hi c2011]building mission critical messaging system(guoqiang jerry)[Hi c2011]building mission critical messaging system(guoqiang jerry)
[Hi c2011]building mission critical messaging system(guoqiang jerry)
baggioss
 
Hic2011
Hic2011Hic2011
Hic2011
baggioss
 
Hdfs introduction
Hdfs introductionHdfs introduction
Hdfs introduction
baggioss
 
Hdfs
HdfsHdfs
Hdfs
baggioss
 
Hdfs
HdfsHdfs
Hdfs
baggioss
 
Hdfs原理及实现
Hdfs原理及实现Hdfs原理及实现
Hdfs原理及实现
baggioss
 

More from baggioss (8)

Hdfs写流程异常处理
Hdfs写流程异常处理Hdfs写流程异常处理
Hdfs写流程异常处理
 
Hic 2011 realtime_analytics_at_facebook
Hic 2011 realtime_analytics_at_facebookHic 2011 realtime_analytics_at_facebook
Hic 2011 realtime_analytics_at_facebook
 
[Hi c2011]building mission critical messaging system(guoqiang jerry)
[Hi c2011]building mission critical messaging system(guoqiang jerry)[Hi c2011]building mission critical messaging system(guoqiang jerry)
[Hi c2011]building mission critical messaging system(guoqiang jerry)
 
Hic2011
Hic2011Hic2011
Hic2011
 
Hdfs introduction
Hdfs introductionHdfs introduction
Hdfs introduction
 
Hdfs
HdfsHdfs
Hdfs
 
Hdfs
HdfsHdfs
Hdfs
 
Hdfs原理及实现
Hdfs原理及实现Hdfs原理及实现
Hdfs原理及实现
 

Hbase使用hadoop分析

  • 1. 文档名称:HBase 使用 hadoop 特点分析文档 HBase 使用 hadoop 特点分析文档 文档版本控制 文档版本号 日期 作者 审核人 说明 V0.2 刘景龙 -1-
  • 2. 文档名称:HBase 使用 hadoop 特点分析文档 目录 1. HDFS 设计目标 ........................................................................................................................ 3 2. HBase 需求分析 ....................................................................................................................... 4 2.1 随机读 ................................................................................................................................ 4 2.1.1 数据发送接收 .................................................................................................................. 4 2.1.2 连接管理 .......................................................................................................................... 4 2.1.3 连接重用 .......................................................................................................................... 6 2.1.4 本地文件操作 .................................................................................................................. 6 2.1.5 Read/pread 使用 ............................................................................................................... 7 2.1.6 HDFS 块信息预取 ........................................................................................................... 8 2.1.7 锁控制 .............................................................................................................................. 8 2.1.8 社区相关动向 .................................................................................................................. 8 2.2 Append & flush .................................................................................................................. 8 2.2.1HLog 写入......................................................................................................................... 9 2.2.2 Mem store flush 过程 ....................................................................................................... 9 2.3 Client 容错 ....................................................................................................................... 10 3. 总结 ......................................................................................................................................... 10 4. 后续工作计划 ......................................................................................... 错误!未定义书签。 5. 参考文档 ................................................................................................................................. 11 6. 快速索引 ................................................................................................. 错误!未定义书签。 -2-
  • 3. 文档名称:HBase 使用 hadoop 特点分析文档 1. HDFS 设计目标 本文档分析是基于 HBase0.20.4 和 Hadoop0.20.2,主要讨论了 HBase 典型应用场景 中 hadoop 相关特点,进而整理 HBase 对 HDFS 系统特性的需求,以便完成后期的迁移, 开展后续工作。对于 hbase 中可采用的相关优化点,暂不予讨论。HDFS 的设计目标主 要包括以下几方面: 1. Hardware Failure 2. Streaming Data Access 3. Large Data Sets 4. Simple Coherency Model 5. Moving Computation is Cheaper than Moving Data 6. Portability Across Heterogeneous Hardware and Software Platforms 不难看出最初 HDFS 是针对 mapreduce 设计的,其设计目标主要是针对流式大规模 数据访问。对比 mapreduce 和 hbase 应用的特点,mapreduce 需求包括以下几个特点[1]: 1. Mapreduce task 输出数据特点:顺序写。 2. Mapreduce task 输入数据特点:顺序读。 3. 通常来讲一个 task 有一个输入,一个输出,平均每个节点有 8-16 个 task。对于 datanode 来讲,并发 client 相对固定,而且数量较小。 4. Mapreduce task 可以在任意节点运行。 HBase 对 HDFS 需求包括以下几点: 1. 随机读。对应于 HBase 中 get 操作。 2. Append & flush。Sync 操作的支持,需要保证 HLog 可以被可靠存储。并且在语 义上保证: a) 对文件的 append 不影响之前已经 flush 的数据。如果 append 失败,其他 reader 能够访问 append 之前 flush(或者 close)的数据。 b) flush 可确保数据被持久化存储到 hdfs。 3. Client 容错。Client 容错是说对于 DFSClient 进行容错处理(该 DFSClient 对应于 HBase 中的 region server 和 HMaster) ,在语义上保证 2 点: a) 控制 DFSClient 对上层应用 (即:HBase) 抛出异常, 并在 DFSClient 层进行 fail over 处理 b) 如果遇到致命错误,需要向 HBase 抛出异常,则需要 HBase 对应节点进行 出错处理,避免由于个别 exception,导致 HBase 集群不可用的情况。([注] 致命错误: 会造成 region server down 机, 并导致 region 在其他 region server 上加载) 需求 MR HBase 大规模存储 √ √ 系统容错 √ √ 顺序写 √ √ -3-
  • 4. 文档名称:HBase 使用 hadoop 特点分析文档 顺序读 √ √ 随机读 - √ client 容错 - √ Append & flush - √ 2. HBase 需求分析 2.1 随机读 本章我们将分为以下几个主题来展开讨论,目标是分析可能影响延迟的因素,结合当前 实现方式,明确其优缺点。由于 HBase 当前写入模式采取异步写的模式,写入操作会先写 入 memstore,当 memstore 达到一定阈值时进行 flush,写入延迟不大,因此本文档中暂不讨 论写过程。 2.1.1 数据发送接收 本节我们主要关注的是数据的发送与读取,对于大规模顺序读写(类 mapreduce 应用) , 预取数据会节省大量的网络交互。 但是对于 HBase 这种随机读/顺序读操作为主的应用而言。 预读机制有可能会造成巨大的资源浪费,并有可能影响操作的实时性。 当前实现中为了对大规模顺序读性能进行优化,每次读块的时候,datanode 会将当前偏 移量到块结束的全部数据发送给 DFSClient。 多余的数据会存放在 datanode 的 tcp send queue 和 DFSClient 的 tcp receive queue 中,当连接数过多的时候, 有可能造成 DFSClient (即: region server)的 socket OOM。但是这种设计对于连接数较少,大规模顺序读写为主的 mapreduce 应用是有很大好处的,大量的读操作实际并不需要进行网络通信,只需从本地的 buffer 中取 数据即可。但是对于随机读操作,该实现方式将会造成大量多余数据的传输。严重影响每次 操作的延迟。因此,我们有必要更精细的控制 datanode 对 DFSClient 的数据发送。修改的时 候需要注意以下几点: a) 尽量不改变现有 HBase 和 HDFS api 接口 b) datanode 是否需要多发数据,依赖于 client 端的操作模式(顺序读或者随机读) ,所 以是否需要多发数据应通过 client 设置。 ★★ 2.1.2 连接管理 HDFS 中使用的连接包括 2 种,一种是 RPC 调用,另一种是 socket 连接。 1. RPC 分析 当前实现中,rpc client 使用 rpc 通常有以下 2 种方式。 a) RPC.waitforProxy 该调用主要用于 datanode 访问 namenode 时(和 secondary namenode 访问 namenode 时) 。它封装了 getProxy,与 getProxy 不同的是,它考虑了 namenode 没 有 启 动 , 或 者 namenode 忙 的 情 况 , catch 住 了 ConnectException , SocketTimeoutException,并进行了无限重试(重试上限为 Long.MAX) b) RPC.getProxy -4-
  • 5. 文档名称:HBase 使用 hadoop 特点分析文档 该调用主要用于 client 连接 datanode 和 client 连接 namenode 的时候。 后面我们会 做详细讨论。 此外当系统 close 或应用结束时,rpc 通信组件中的一些资源需要显式回收。这个操 作是在 RPC.stopProxy 中完成。这个操作被封装到 FileSystem 的 close()操作中。 Rpc client 端连接管理中,我们主要关注连接数和重试机制造成的延时。连接数有可 能会对系统稳定性造成影响,而不恰当的重试机制有可能会造成过多的延迟。 (1) Rpc 建立连接阶段 在建立连接的时候,当前实现中,新建 socket 连接会设置以下几个参数: a) tcpNoDelay,通过 ipc.client.tcpnodelay 设置, 默认为 false b) socket timeout,通过 ipc.ping.interval 设置, 默认为 1 分钟 c) socket connect() 通过 NetUtils.connect 设置超时,为 20 s 如果连接失败会进行重试, a) 当遇到 SocketTimeoutException 的时候,会 close 掉之前的连接(如果有的话), sleep 1 秒,然后进行重试。对于 SocketTimeoutException 的最大重试次数为 45 b) 当遇到其他 IOException 的时候,会 close 掉之前的连接(如果有的话), sleep 1 秒 , 然 后 进 行 重 试 。 对 于 其 他 IOException 的 最 大 重 试 次 数 通 过 ipc.client.connect.max.retries 进行设置, 默认为 10。 由上可见,对于 rpc 连接对应的机器,最差情况下,会有 (20 + 1) * (45 + 10) = 1155 s = 19.25 min 的时间花在 rpc 的新建连接上。如果当时对应机器恰好网络繁忙,则有可 能造成一个 rpc 的延迟超高。 建议: 可以参考 HADOOP-6889 的思想, 引入 rpc timeout。对于延迟 敏感的应用 (比 如:HBase) ,过多的重试次数,有可能会造成响应时间的浪费。 (2) Rpc 执行阶段 Rpc client 中最重要的数据结构是 Connection id 到 Connection 对象的 hashmap。其 中 Connection id 包含了 remote address, port 等信息, Connection 对象包含了 socket 而 和由 socket 建立的输入/输出流。 Rpc client 使用的是短连接,每次 rpc call 会新建一个 socket 连接,在收到 rpc server 响应的时候关闭连接。rpc 接受响应是通过从 PingInputStream 中读取响应数据来实现, PingInputStream 在 读 操 作 中 会 捕 捉 SocketTimeoutException, 当 出 现 SocketTimeoutException 的时候,ping 远程机器。如果 ping 不通 rpc server,则 close 掉 连接,否则重新从 socket 中读取数据。重复以上步骤,直到正常读出数据为止。 对于 client 或者 datanode 连接 namenode 的时候,如果 namenode 暂时无法访问, 则集群命名空间暂时不可用,client 有必要一直重试,直到 namenode 可访问为止。至 于 client 会通过 rpc 连接 datanode,只有当 DFSClient 写数据失败,进行 block recovery 的时候才会发生。这种情况下,不断重试也是合理的。 server 端一共有 3 个线程,handler,listener,responser。listener 中用了 select()处 理 client 端的请求。当 listener 收到一个请求后,accept 该 client 连接,并将该连接注册 到 read key。在 read 中将数据放入到 call queue 队列中。而 handler 线程则不停的从 callQueue 中取出 Call 对象执行。处理完成后,调用 responder.doRespond(),将该次 rpc 的应答放到 responseQueue 中,由 responser 线程的主循环发送应答到 client 端。 综上,我们可以看到在 RPC 框架中,RPC 调用采用短连接的方式,因此不会由于过 多连接导致系统稳定性问题。 RPC 的 fail over 处理方面可以通过以下方式进行优化:在 RPC 连接建立的时候,可 以通过修改 SocketTimeoutException 的重试次数和 ipc.client.connect.max.retries 来调优打 -5-
  • 6. 文档名称:HBase 使用 hadoop 特点分析文档 开连接所用时间开销。★ [注]:该优化对于系统空闲状态时,无优化效果。 2. Socket(由于当前版本 RPC 也是基于 socket 实现,这里我们特指非 RPC 的 socket 应用) DFSClient 使用 Socket 主要分为 2 个场景,读和写。 读操作时连接的建立包括 2 个时机,调用 read() 接口和 pread() 接口。 当使用 read() 接口时,连接的建立有 2 个入口。 a) blockSeekTo()的时候, 会将之前 DFSInputStream 已经持有的 socket 关闭。 然后 选择合适的 datanode, 建立连接。 如果 blockSeekTo 的 datanode 与之前 datanode 相同,则连接建立销毁的时间开销会影响单次操作的延迟。★ b) 调用 readBuffer 进行实际读数据的时候,如果发生 IOException 异常,(比如: 网络超时), 则会通过 blockSeekTo()关闭连接,建立连接。如果此时 DFSClient 同 datanode 之间网络不稳定,造成瞬断的情况,有可能造成无谓的重试。对 单次读操作的延迟会有影响。 ★ 当使用 pread()接口时, 如果需要的 block 信息没有被预取, 则会 RPC 调用 namenode 的 getBlockLocation()方法获取块的位置信息。 然后对每一个需要读的块重复以下几步操 作: a) 创建 socket 连接 b) 进行数据传输 c) 当数据传输完毕,关闭 socket 连接 写操作时,DFSClient 仅当分配一个新 block 时会调用 createBlockOutputStream()建立 一条到第一个 datanode 的 socket 连接。 该连接设置了连接超时和 socket 超时均为 1 分零 9 秒。 (3000 * nodes.length + dfs.socket.timeout。默认 nodes.length 为 3, dfs.socket.timeout 为 1 分钟) ,socket send buffer 为 128K。该连接仅当主动 close 文件和创建连接出错时, 会被关闭。 在 HBase 应用中,写文件主要有 2 个时机,mem store flush 和写 HLog。 Mem store flush 时,会新建一个 HFile,然后将 mem store 中的内容写入 HFile,完成 flush 后,将文件 close 掉,因此不会造成过多连接。 创建 region 的时候会新建一个日志文件,DFSClient 保持一条到 datanode 的连接。 RollWriter()调用时会 close 掉该文件(close 文件操作中会 close 掉 DFSClient 到 datanode 的连接)Rollwriter 有 2 个触发时机, region 新建的时候 。 (1) (HMaster 启动或者 create table 的时候) ,会 new HLog 对象,此时会调用 roll writer,close 掉对应连接。(2) 每小时会进 行一次日志滚动,这时对应的日志文件会被 close 掉。 每一个 region server 到 datanode 的连接数上限为该 region server 拥有的 region 数。 且每小时日志滚动时会将对应连接 close 掉。 因此, 在写操作时不会造成连接数过多的问 题。 2.1.3 连接重用 当前 HDFS 实现中,每个 DFSClient 同 datanode 之间维护一个独立的连接,通过该连接 进行交互通信,在不同 DFSClient 之间连接不进行共享。在 HBase 中,单个 region server 在 scan 的时候, 有可能会打开很多文件 (文件数依赖于 scan 的 region 数和每个 region 的 store file 数,此时连接的数量是应用相关的) 。作为平台,有必要在 HDFS 进行连接重用。★★ 相关 patch : HBASE-2492, HDFS-941 2.1.4 本地文件操作 主要针对 datanode 中 meta 文件和 block 的文件的处理。 -6-
  • 7. 文档名称:HBase 使用 hadoop 特点分析文档 在 HDFS 读操作中,每次读操作都会 new 一个 BlockSender 对象,在此对象中打开 block 和 meta 文件,读完一个块的时候,关闭这两个文件。block 读取的策略是从当前 offset 到块的结束顺序读完全部内容, 并发回给 DFSClient。每次读文件的大小为 64K (如 果 offset 到块结尾不足 64k,则为 block 长度 - 当前 offset) 读的过程中,每 。 io.bytes.per.checksum (默认为 512B) ,进行一次 checksum 校验。 当前 datanode 实现方式造成性能损耗的地方包括以下几处: 1. 每读一个块都需要重新打开,关闭 block 和 meta 文件。 建议: 建立 fd 池,缓存 fd。减少重复打开关闭文件的开销。 ★★ 相关 patch: HDFS-1323 2. 循环顺序读,且每次读 64k 的方式不适合随机读的方式。 建议:将 datanode 增加无预读模式或者少量预读(随机读操作有可能会取某个 row 的多个 version, 多个 version 之间的访问为顺序读,这种情况少量预读有利于提高 读效率) ,以减少额外的数据传输开销。 ★★★ 3. 每 512 个字节进行一次 checksum 校验的方式,会浪费大量 cpu 时间。 建议:io.bytes.per.checksum 约等于一行的长度。由于 HBase 中保证行的原子性。 Checksum 可以基于行(对于一行做一次 checksum)★ 2.1.5 Read/pread 使用 Read/pread 基本流程请见 6.2。 Pread: Pread(是 position read 的简称)是指 int read(long position, byte[] buffer, int offset, int length)接口。在语义上该函数相当于 seek + read。 该函数根据要读的数据的 offset 和 readLen,计算出要读的 blockRange。getBlockRange() 这个函数中要判断要读的 blocks 是否在 locatedBlocks 中,如果不在,要向 namenode 查询。 然后再针对获得的 blockRange 中每个 block 读取数据,选取 datanode,创建连接,对每 个 block 重新生成一个 BlockReader。 Seek+read: 此 read 为 int read(byte[] buffer, int offset, int length)接口。默认情况下该函数顺序读,当 需要随机读的时候需要结合 seek()使用。 在 new BlockReader 的时候,read 会把当前位置到 block 结束的长度传给 datanode,这 样 DataNode 就可以 read ahead,这样由于 tcp buffer 作用可以加快连续读的性能。 如果 seek 的时候 seek 的目的位置和当前位置在同一个 block 就只需直接读取。如果不 在,则需调用函数 blockSeekTo()建立到目的 datanode 的连接。 Pread 和 seek+read 主要不同的地方在于 getBlockRange(用于 pread)和 getBlockAt(用 于 read) Pread 中 getBlockRange 是取从当前 position 到 buffer 结束的块位置信息。read 中 。 的 getBlockAt 是取当前 position 对应的块信息。所以,getBlockRange() 同 getBlockAt() 相比 会获取更多的 block location 信息。对于当前 HBase 应用来讲,buffer 的大小约为 64K(一个 HBase block 的大小) ,所以 getBlockRange()至多比 getBlockAt()多获取 1 个块的信息。 如果 buffer 刚好跨过 2 个 HDFS block, pread 需要获取 2 个块的位置信息。 则 此外,pread 中每次调用都需要调用 getBlockRange()对 cache 中的 block location 信息进行查找。而 read 仅当跨块的时候,才会调用 getBlockAt()在 cache 中寻找 block location 信息。 综上,read()同 pread()相比节省了 cache 查找的开销和 getBlockRange()多取块的开销。 但由于这两项均为内存操作(pread 至多比 read 多一次 getBlockLocation() RPC 调用) ,性能 优化空间很小,可暂不优化。 -7-
  • 8. 文档名称:HBase 使用 hadoop 特点分析文档 相关 patch : HBASE-1505, HBASE-2180 2.1.6 HDFS 块信息预取 分析: 评估 dfs.read.prefetch.size 大小对于延迟的影响 当前 hdfs 会在文件 open 的时候,取一定数量块的位置信息(默认取 10 块) 。 预取块的特性有利于类 mapreduce 的应用(大规模顺序读写) ,当大规模顺序读写 的时候,可以有效减少对 namenode 的 getBlockLocations()调用。但是对于大量随机读操 作的时候,预取可能会造成对 namenode 的额外压力。 建议: HBase 在使用 DFSClient 的时候,根据应用随机程度设置预取块数。 2.1.7 锁控制 1.Datanode 中锁机制的分析 Datanode 中的操作大都需要通过 FSDataset 完成,FSDataset 中的操作会加一把大锁。 每个操作都会锁住整个 FSDataset 对象。定性的,我们可以考虑使用读写锁代替互斥锁。以 减少同步的开销。★ 相关 patch : HDFS-1148 2.1.8 社区相关动向 在完成了之前的分析, 我们发现社区中有很多聪明的人们在和我们做同样的工作。 我们 可以通过学习和分析相关的 issue 取其精华。 针对 2.1.4, HDFS-1323 将本地对 block 文件和 meta 文件的访问池化,避免重复 open file HDFS-1034 Enhance datanode to read data and checksum file in parallel 针对 2.1.3, HDFS-380 在 DFSClient pread() 时建立长连接,以提高 hdfs 随机读的性能 HDFS-1325 设置读 timeout,避免 idle 连接长期占用资源 针对 2.1.2,HADOOP-6889 增加 rpc timeout,修改 rpc 的重试机制 针对 2.1.7,HDFS-1148 Convert FSDataset to ReadWriteLock 其他: HDFS-1214 hdfs client metadata cache HDFS-516 Low Latency distributed reads 测试相关: HADOOP-6637 Benchmark overhead of RPC session establishment HDFS-236 Random read benchmark for DFS 迁移相关 HADOOP-6904, HDFS-1335 使不同版本 DFSClient 和 Namenode 可以互相访问。 2.2 Append & flush 根据之前的调研,我们整理了有可能需要 append 和 flush 功能的相关应用场景。主要包 括:(注:这里说的 flush 是指通用文件系统语义的 flush 操作,相当于 hdfs 中的 sync) 1. HLog 写入 2. Mem store flush 3. Compaction -8-
  • 9. 文档名称:HBase 使用 hadoop 特点分析文档 此外, 需要写文件的场景还包括日志分割。 但是日志分割的场景主要用于 HMaster 启动 时,使用一次,然后关闭文件。不增加 flush 接口,也不会造成数据丢失。但是按照当前日 志分割的流程: 1. 打开对应日志文件,将其中内容读入到 queue 中。 2. 然后将对应日志文件删除 3. 将 queue 中的数据分发到不同的 HLog 文件中,然后将 HLog close 掉 在 3 完成之间,就会将之前的日志文件删除,所以有可能造成日志数据丢失,需要修改 HBase 使用方式。★★★ 下面我们分析下以上 3 个相关应用场景中,使用当前版本 hdfs 可能潜在的风险: 2.2.1HLog 写入 写入 HLog 的场景包括 Delete(), incrementColumnValue(), put()。HLog 的写入就是 append 到 sequence file 一个 key-value 对,该操作本身并不保证数据安全性。当前 HBase 为 了防止日志数据丢失,引入了日志的滚动机制。 日志滚动的目的主要是保证日志滚动之前的日志可以被可靠存储,删除多余的日志文 件。每个 region server 中有一个 LogRoller 线程,每 hbase.regionserver.logroll.period 进行一 次日志滚动。 (默认 1 小时滚动一次) 。日志滚动所做的事情就是 close()掉之前的日志,并删 除已经 flush 的 log 文件,重新 create 一个 HLog。此外,日志滚动时,会 schedule flush,异 步的将 mem store 中的数据 flush 到 HFile。 所以, 我们可以认为, 在日志滚动的 1 小时间隔内, HLog 的数据是不安全的。 如果 region server down 机,会导致 HLog 数据丢失。 需求功能: (请参见 HADOOP-1700)★★★ 1. 单 Writer 和多个 Reader 可以并发访问。 2. Writer 调用 flush 之后,保证数据被持久化。 3. Writer 频繁 flush 不会对 HDFS 造成过高负载。 4. Reader 可以读取到其 open 之前 flush 的数据。 5. HDFS 不偷偷丢数据。 7. append 之后,之前已经 flush(或者 close)的数据不会丢。 2.2.2 Mem store flush 过程 在 region server 中有单独一个线程处理 mem store 的 flush。 操作将数据塞到 mem store Put 中,当 mem store 的大小满足一定大小(通过 hbase.hregion.memstore.flush.size 配置,默认 为 64M)将数据刷到 hdfs 上。 每次 Mem flush 操作将 memstore 中的数据写入到 StoreFile 中。对于每个 store,flush 结 束会立即 close 掉对应的 store file,以保证数据安全。 当之前的 StoreFile 被 close 之后, 会重新打开一个新的 store file, 并从中读取 index 信息。 所以当 mem flush 结束时,region server 会拥有一条到 datanode 的 socket 长连接。 在 flush 结束的时候,在 HLog 中写入一条 FLUSHCACHE-COMPLETE 记录,只是 append 一个 key-value 到 HLog 中,当前 HDFS 实现并不保证这条记录被持久化。 由上述过程,我们可以认为在每次 flush mem store 之后,数据是安全的。 在 flush memstore 过程中, 如果 region server down 机,会导致未 flush 的 store 和 mem store 中的数据丢失。此类错误在其他 region server 接管该 region,replay HLog 的时候,可以修复 丢失数据。 此外, memstore flush 之前, 在 如果 region server 挂掉, 会导致 mem store 中的数据丢失。 但是如果 HLog 已经被持久化,则当 region server 重新启动时,可以通过 replay HLog 完成 数据恢复。 -9-
  • 10. 文档名称:HBase 使用 hadoop 特点分析文档 2.3 Client 容错 在 mapreduce 计算框架中,如果一个 task 计算失败,框架会将 task 重新启动,所以 task 失效不是个很严重的问题。而对于 HBase 而言,region server 作为 client,如果其失效退出, 将导致某些 region 不可访问,即使其他 region server 重新加载该 region,也会造成一定时间 的系统 down time。 我们需要做两方面工作: 1. 优化重试机制,避免一个节点失效导致多次重试失败的情况。 (比如:HDFS-630) ★★★ 2. 重新设计 DFSClient 对 Exception 处理的机制。当 DFSClient 重试了 n 次后,当前实 现会丢出一个 Exception。★★★★ 相关 patch:HDFS-127 HDFS-927 3. 总结 本文档中对 HBase 使用 hdfs 相关功能的需求进行了定性的分析汇总。 本文档从随机读, 数据安全,client 容错三方面分析了 HBase 对 HDFS 使用的特性,并对相关功能点进行详细 分析。第二章中列出了需要解决的相关问题,并以红星标出。红星越多则越重要。 在此我们按照优先级列出当前版本 hdfs 需要改进的地方。 功能: 1. Sync() 功能支持(sequence file) Sync 操作需要实现以下语义: Sequence file 提供 sync() 接口,实现 flush 的语义。 2. Datanode 多发数据问题 当前 client 的实现,如果 client 请求一个字节,datanode 会将该字节 offset 到 block 结尾的全部数据发送给 client。由于 HBase 需要同时满足顺序读和随机读的需求, 需要通过 client 配置,决定是否多发数据。 稳定性: 1. Review DFSClient 异常处理机制 (HDFS-127 HDFS-927) 在 DFSClient 层保证处理不致命的错误。将致命错误抛出。 ([注] 致命错误:会造成 region server 进程退出,并导致该 region 在其他 region server 上加载。会存在一段时间的 down time。) 2. Datanode 坏盘导致 region server 退出的问题 (HDFS-630)。 3. Client 到 datanode 连接数过多问题 解决方案分为 3 层: a) HBase 清理其不需要的资源。包括 close()不需要的文件。 b) 实现 DFSClient 到 datanode 的连接重用,包括读写。 c) DFSClient 对未关闭的连接进行回收。避免影响其他应用。 性能: 1. 增加 Block sender 本地读 fd 池,避免每次读操作都打开/关闭本地文件。 2. 合并 meta 和 block 文件,以减少随机读 2 个本地文件造成的磁盘寻道开销。 3. 文件 open 的时候,加大预取块位置信息的大小。 4. 如果不改变 datanode 的时候,blockSeekTo 重用之前已有连接。 5. 改变 io.bytes.per.checksum 减少 checksum 时间花费。 - 10 -
  • 11. 文档名称:HBase 使用 hadoop 特点分析文档 6. 在 FSDataset 中使用读写锁。 4. 参考文档 [1] HBase and HDFS by Todd Lipcon of Cloudera http://wiki.apache.org/hadoop/HBase/HBasePresentations?action=AttachFile&do=view &target=HUG9_HBaseAndHDFS_ToddLipcon_Cloudera.pdf [2] http://wiki.apache.org/hadoop/Hbase 5. 附录 6.1 相关 jira HDFS-1323 将本地对 block 文件和 meta 文件的访问池化,避免重复 open file HDFS-1034 Enhance datanode to read data and checksum file in parallel, HDFS-380 在 DFSClient pread() 时建立长连接,以提高 hdfs 随机读的性能 HDFS-1325 设置读 timeout,避免 idle 连接长期占用资源 HADOOP-6889 增加 rpc timeout,修改 rpc 的重试机制 HDFS-1148 Convert FSDataset to ReadWriteLock HDFS-1214 hdfs client metadata cache HDFS-516 Low Latency distributed reads HADOOP-6637 Benchmark overhead of RPC session establishment HDFS-236 Random read benchmark for DFS HADOOP-6904,HDFS-1335 使不同版本 DFSClient 和 Namenode 可以互相访问 - 11 -