设为首页 加入收藏

TOP

hbase和hdfs的一些故事
2019-02-12 13:31:24 】 浏览:16
Tags:hbase hdfs 一些 故事
hdfs一开始设计的时候,文件是只能写入一次,然后就只读的.一开始工作的相安无事,但是有一天,hbase跑到了hdfs上,hbase作为数据库,总要保持一定的持久性,所以它弄了个log,叫做wal,记录每一次操作,这样就算region server系统崩溃,Memstore的东西毁于一旦,还是可以靠wal来恢复.问题在于wal是存储在hdfs上的,hdfs上的文件只有被正确close以后,才是合法的hdfs文件.因此我认为wal有以下几种方案
1 每次操作产生的wal都成为单独的hdfs文件.这个方案产生的hdfs文件太多,不现实
2 只保持一个wal文件在hdfs上处于open,每次操作产生的wal都write到这个wal上,用类似fsync的功能把wal持久化到hdfs,定期close这个wal文件切换到下一个.这个方案问题在于hdfs当时没有fsync这样的功能,只有把这个wal close以后,这个wal才是合法的.假设系统一小时使用一个wal,在59分钟的时候系统崩溃,这个wal的前59分钟数据就等于丢失了.
3 hdfs增加append操作,每次hbase产生wal,都append到原来的wal文件上

2和3的区别是2是长时间保持一个文件打开,每次把wal写入,到一定时候再close这个文件.3则是需要每次append wal到一个已经close的文件上.

后来hdfs选择了方案3,增加了append操作.不幸的是,hdfs增加的append操作bug挺多,他们最终又打算把这个append去掉.但是有一些开发者在这期间搞出来了sync(我感觉是这期间搞出来的,但是很怀疑为什么把sync放到append的branch里,不明白sync为什么依赖append),sync可以保证hbase的持久性(我感觉是使方案2成为了可能),但是要想使用sync需要首先设置dfs.support.append.也就是说想要sync就不得不启用有缺陷的append.
而且当时append和sync这两个重要功能是在hadoop的branch "0.20.append",这个branch基于branch "0.20.2",而基于"0.20.2"这个branch的还有一个"0.20.security"的branch,包含了security的功能.所以导

乱桓隹⒄咚,"there has been an 18 month period where there has been no one Apache release that had all the committed features of Apache Hadoop"(无力吐槽了,按理说branch应该merge回trunk的).下面的图表显示了当时的状态.
难怪另一个开发者说"HDFS sync has a colorful history"


[img]http://dl2.iteye.com/upload/attachment/0105/7313/f3ffb286-4d0c-337f-a333-ef9b7c8f3f9a.png[/img]


[img]http://dl2.iteye.com/upload/attachment/0105/7315/ab54e69f-3cb5-3df0-b3b7-975ed12fcd95.png[/img]

后面的故事总算回归正轨(其实是中间过程我懒得看了):
[url]https://issues.apache.org/jira/browse/HDFS-3120[/url]

hadoop 1.x: sync始终启用,"dfs.support.appends"配置项去掉,隐藏了append功能
hadoop 2.x: hsync/hflush始终启用,"dfs.support.appends"配置项可以用来开启append功能,该配置项默认启用.

[quote]The work on branch-20-append was to support sync, for durable HBase WALs, not append. The branch-20-append implementation is known to be buggy. There's been confusion about this, we often answer queries on the list like this. Unfortunately, the way to enable correct sync on branch-1 for HBase is to set dfs.support.append to true in your config, which has the side effect of enabling append (which we don't want to do).
For v1.x let's:
Always enable the sync path (currently only enabled if dfs.support.append is set)
Remove the dfs.support.append configuration option. Let's keep the code paths though in case we ever fix append on branch-1, in which case we can add the config option back
For 2.x let's
Always enable the hsync/hflush path
The dfs.support.appends only enables the append specific paths (since the hsync/hflush paths are now always on). Append will still default to being enabled so there is no net effect by default.[/quote]

其实hdfs的hsync/hflush也有一番曲折(HDFS sync has a colorful history),但那是另一个故事了.

所以我们这些上来就用hadoop 2.x的人,是多么幸运啊
参考资料如下

[url]http://blog.cloudera.com/blog/2012/01/an-update-on-apache-hadoop-1-0/[/url]
[url]http://blog.cloudera.com/blog/2009/07/file-appends-in-hdfs/[/url]
[url]http://hadoop-hbase.blogspot.com/2012/05/hbase-hdfs-and-durable-sync.html[/url]

编程开发网
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇大数据系列之数据库Hbase知识整理.. 下一篇Hbase连接异常,JAR包冲突解决攻略

评论

帐  号: 密码: (新用户注册)
验 证 码:
表  情:
内  容:

array(4) { ["type"]=> int(8) ["message"]=> string(24) "Undefined variable: jobs" ["file"]=> string(32) "/mnt/wp/cppentry/do/bencandy.php" ["line"]=> int(217) }