hbase 学习(十四)Facebook针对hbase的优化方案分析

  • 时间:
  • 浏览:0
  • 来源:大发欢乐生肖APP下载_大发欢乐生肖APP官网

使用hbase的目的是为了海量数据的随机读写,后来在实际使用中却发现针对随机读的优化和gc是另2个 很大的什么的问题,后来hbase的数据是存储在Hdfs,而Hdfs是面向流失数据访问进行设计的,就难免带来深度的下降。下面介绍一下Facebook Message系统在HBase online storage场景下的另2个 案例(《Apache Hadoop Goes Realtime at Facebook》, SIGMOD 2011),最近亲戚我应该 们 在存储领域顶级会议FAST2014上发表了一篇论文《Analysis of HDFS Under HBase: A Facebook Messages Case Study》分析了亲戚我应该 们 在使用HBase中遇到的一点什么的问题和处理方案。该论文首先讲了Facebook的分析法子包括tracing/analysis/simulation,FM系统的架构和文件与数据构成等,接下来刚开始分析FM系统在性能方面的一点什么的问题,并提出了处理方案。

Figure 2描述了每一层的I/O构成,解释了在FM系统对外请求中读占主导,后来后来logging/compaction/replication/caching因为写被严重放大。

注:关于拿Flash/SSD做cache,还并能参考HBase BucketBlockCache(

FM系统的几种文件类型如Table 2所示,你类式是纯业务的逻辑描述。在HBase的每个RegionServer上的每个column family对应另2个 后来多个HFile文件。FM系统带有8个column family,后来每个column family存储的数据的类型和大小不一样,使得每个column family的读写比是不一样的。后来很少数据是读写全部都是请求的,一点cache all writes后来作用不大(Figure 4)。  

如Figure 16所示,一般分布式数据库系统分为另2个 层次:db layer/replication layer/local layer。你类式分层架构的最大优点是简洁清晰,每层各司其职。类式db layer只前要处理DB相关的逻辑,底层的存储认为是available和reliable的。

HBase是图中a)的架构,数据的冗余replication由HDFS来负责。后来你类式带来另2个 什么的问题后来 类式compaction操作会读取多个三备份的小文件到内存merge-sorting成另2个 三备份的大文件,你类式操作不到在其中的另2个 RS/DN上完成,那末从一点RS/DN上的数据读写全部都是带来网络传输I/O。

图中b)的架构后来 把replication层贴到 了DB层的上方,Facebook举的例子是Salus,不过我对你类式东西没熟悉。我认为Cassandra后来 你类式架构的。你类式架构的缺点后来 DB层前要处理底层文件系统的什么的问题,前要保证和一点节点的DB层协调一致,太复杂性了。

图中c)的架构是在a的基础上的类式改进,Spark使用的后来 你类式架构。HBase的compaction操作就还并能复杂性成join和sort曾经另2个 RDD变换。   

后来少次要同样的数据会被老是 读取,一点另2个 大的cache并能把200%左右的读取操作拦截而不要 触发磁盘I/O,后来不到这少次要的hot data前要被cache。那末拿哪此样的存储介质做cache呢?Figure 11说明后来拿足够大的Flash做二级缓存,cache命中率会明显提高,一同cache命中率跟内存大小关系无须大。

都曾经设计专门的数据中心网络拓扑来优化网络I/O负载,相关研究成果在计算机网络顶级会议SIGCOMM上发表了多篇论文,后来后来其对网络路由器的改动伤筋动骨,最后都那末成功推广开来。   

FM系统的主要读写I/O负载

Figure 19展示了combined logging的原理。现在HBase的多个RS会向同另2个 DataNode发送写log请求,而目前DataNode端会把来自这另2个 RS的log分别写到不同的文件/块中,会因为该DataNode磁盘seek操作较多(不再是磁盘顺序I/O,后来 随机I/O)。Combined logging后来 把来自不同RS的log写到同另2个 文件中,曾经就把DataNode的随机I/O转化成了顺序I/O。

对于每个column family的文件,90%是小于15M的。后来少量的很糙大的文件会拉高column family的平均文件大小。类式MessageMeta你类式column family的平均文件大小是293M。从哪此文件的生命周期来看,大次要FM的数据存储在large,long-lived files,然而大次要文件却是small, short-lived。这对HDFS的NameNode提出了很大的挑战,后来HDFS设计的初衷是为了存储少量、大文件准备的,所有的文件的元数据是存储在NameNode的内存中的,还有有NameNode federation。

FM系统的主要I/O访问类型

下面就考虑缘何架构并能加速你类式系统了。目前Facebook的HBase系统每个Node挂15块200MB/s深度、10ms寻址时间的磁盘。Figure 9表明:a)增加磁盘块数很糙用;b)增加磁盘深度没啥大用;c)降低寻址时间非常有用。

亲戚亲戚我应该 们 知道亲戚亲戚我应该 们 比较关心Flash/SSD寿命的什么的问题,在内存和Flash中shuffling数据并能使得最热的数据被交换到内存中,从而提升读性能,后来会降低Flash的寿命,后来随着技术的发展你类式什么的问题带来的影响后来那末小。

说完加速读的cache,接着讨论了Flash作为写buffer是不是 会带来性能上的提升。后来HDFS写操作我希望数据被DataNode成功接收到内存中就保证了持久性(后来三台DataNode一同存储,一点认为从DataNode的内存flush到磁盘的操作不要 另2个 DataNode都失败),一点拿Flash做写buffer不要 提高性能。虽然 加写buffer会使后台的compaction操作降低他与前台服务的I/O争用,后来会增加很大复杂性度,一点还是不要 了。最后亲戚我应该 们 给出了结论后来 拿Flash做写buffer没用。

后来亲戚我应该 们 还计算了,在你类式存储栈中加入Flash做二级缓存不但能提升性能达3倍之多,后来只前要增加5%的成本,比加内存性价比高一点。

2.分层架构的缺点和改进方案 

总的来说,HBase stack的logging/compaction/replication/caching会放大写I/O,因为业务逻辑上读为主导的HBase系统在地层实际磁盘I/O中写趋于稳定了主导。

FM系统的主要文件类型和大小  



下面从temporal locality, spatial locality, sequentiality的深度来看。

73.7%的数据只被读取了一次,后来1.1%的数据被读取了大概64次。也后来 说不到少次要的数据被重复读取了。后来从触发I/O的深度,不到19%的读操作读取的是只被读取一次的数据,而大次要I/O是读取哪此热数据。

在HDFS你类式层,FM读取数据那末表现出sequentiality,也后来 说明high-bandwidth, high-latency的机械磁盘全部都是服务读请求的理想存储介质。后来对数据的读取也那末表现出spatial locality,也后来 说I/O预读取也没啥作用。

处理方案1. Flash/SSD作为cache使用

)  

Figure 17展示了local compaction的原理,曾经的网络I/O的一半转化成了本地磁盘读I/O,后来还并能利用读cache加速。亲戚亲戚我应该 们 都知道在数据密集型计算系统中网络交换机的I/O瓶颈非常大,类式MapReduce Job中Data Shuffle操作后来 最耗时的操作,前要强大的网络I/O深度。