Changes between Version 1 and Version 2 of reference1

Timestamp:

08/17/2012 02:27:46 PM (14 years ago)

Author:

liaojiaohe

Comment:

矫正，错字太多

reference1

@@ -1 @@
-亮点：实时 Coprocessors 数据压缩  预分区
+亮点：实时 Coprocessors 数据压缩  预分区 RegionServer监控
 
 以下为文字实录：
@@ -31 +31 @@
 优化强依赖Zookeeper的宕机超时判断监控进程的启动流程，我发现当前我的Region Server已经启动了，我会主动向我的Region Server拉动它，保证了PD的唯一性。为什么不采用在系统级的PS一下，检查一它的进行字符匹配，其实我们认为这不是很可靠，假如说程序当中判断失误，我们有可能会检查到原本不属于进程该检查，会造成监控的失误，误删除的现象存在，我们启动了自己认为可靠的程序进行监控。
 
-同时我们认为除了自己本机Region Server会宕掉之后，还存在这台机器完全宕机的风险，完全宕机如果Region Server所在的机器，所启动的监控进程它只监控自己当前的Region Server，就会面临这样一个问题，如果整台机器全部管掉了，我们监控其实失效了，肯定还是要回到原来的起点当中等待ZK的超市，除了本机监控之外还应该依赖于其他当中相互覆盖的监控方式，比如说，相邻两个结点，除了只监控自己本机PID是否存在和自己端口是否存在，我还可以检查进程相邻第二台机器B的服务端口是否存在，这就做到了看似非常复杂的网络结构的完整监控模式。目前，我们将思路已经提了专利，我们也提到了社区，我们跟社区的思路不是特别一样社区有另外考虑，在5075社区考虑是否用Java的方式来做，大同小异，跟我们做的优化目的是一样，总之为了减少等待时间。
+同时我们认为除了自己本机Region Server会宕掉之后，还存在这台机器完全宕机的风险，完全宕机如果Region Server所在的机器，所启动的监控进程它只监控自己当前的Region Server，就会面临这样一个问题，如果整台机器全部管掉了，我们监控其实失效了，肯定还是要回到原来的起点当中等待ZK的超时，除了本机监控之外还应该依赖于其他当中相互覆盖的监控方式，比如说，相邻两个结点，除了只监控自己本机PID是否存在和自己端口是否存在，我还可以检查进程相邻第二台机器B的服务端口是否存在，这就做到了看似非常复杂的网络结构的完整监控模式。目前，我们将思路已经提了专利，我们也提到了社区，我们跟社区的思路不是特别一样社区有另外考虑，在5075社区考虑是否用Java的方式来做，大同小异，跟我们做的优化目的是一样，总之为了减少等待时间。
 
-我们当前解决方案只能说检查当前机器的服务是否存在，不能检查我们当前机器它Region Server内部的问题，比方说这台机器当中发生的异常状况，死锁，这是内核的问题，Region Server更内层的东西进行加以优化和修订。所以说我们也是有利有弊的过程，不是完全像第二种说到的情况。关于Region Server宕机恢复第二流程，就是重做HLog的时间，0.9X系列目前单线程，如果设置256兆，如果写读量非常大，周期上线是32Hlog，这32和250乘起来，Java处理速度，能有50到每秒不错了，实际上达不到这种速度，在现有机械盘当中缓冲区和内存交互速度是30兆每秒，可以算一下256乘以32除以30，很可观的数字，得到了现有系统当中业务量重做Hlog的时间，串行处理必然降低了速度，在社区的0.92意识到这个问题，Hlog分发到每台Region Server都会写入最终数据块的服务区当中，这样的话，利用了每个台机器服务能力，我们每台机器只做一个Hlog的恢复，256除以30，速度可以看到得到质的提升，就是并行的方案。有一定请各位注意，0.92并行Hlog可能出现丢数据的现象，0.94代码并行做过一些修复，我们初期用了1364版本，但是在0.94系列里面做过同步的代码，保证至少测试当中都是能过的，目前应用系统当中还没有发现丢数据的现象。
+我们当前解决方案只能说检查当前机器的服务是否存在，不能检查我们当前机器它Region Server内部的问题，比方说这台机器当中发生的异常状况，死锁，这是内核的问题，Region Server更内层的东西进行加以优化和修订。所以说我们也是有利有弊的过程，不是完全像第二种说到的情况。关于Region Server宕机恢复第二流程，就是重做HLog的时间，0.9X系列目前单线程，如果设置256兆，如果写读量非常大，周期上线是32个Hlog，这32和250乘起来，Java处理速度，能有50M每秒不错了，实际上达不到这种速度，在现有机械盘当中缓冲区和内存交互速度是30兆每秒，可以算一下256乘以32除以30，很可观的数字，得到了现有系统当中业务量重做Hlog的时间，串行处理必然降低了速度，在社区的0.92意识到这个问题，Hlog分发到每台Region Server都会写入最终数据块的服务区当中，这样的话，利用了每个台机器服务能力，我们每台机器只做一个Hlog的恢复，256除以30，速度可以看到得到质的提升，就是并行的方案。有一定请各位注意，0.92并行Hlog可能出现丢数据的现象，0.94代码并行做过一些修复，我们初期用了1364版本，但是在0.94系列里面做过同步的代码，保证至少测试当中都是能过的，目前应用系统当中还没有发现丢数据的现象。
 
-还有一个问题扫描原数据的问题，如果Rewion越多数据肯定是越多的，现有问题也存在一系列的问题，RPC的问题，特定场景才会发现的，如果发生这个问题，可能延迟几分钟时间，如果没有这个问题，这部分所带来的消耗也并不是太长，主要会集中在第二步当中，第一步肯定要加以防范，这个参数其实非常简单。第二步也是参数上的优化，大家可以实验。
+还有一个问题扫描原数据的问题，如果Region越多数据肯定是越多的，现有问题也存在一系列的问题，RPC的问题，特定场景才会发现的，如果发生这个问题，可能延迟几分钟时间，如果没有这个问题，这部分所带来的消耗也并不是太长，主要会集中在第二步当中，第一步肯定要加以防范，这个参数其实非常简单。第二步也是参数上的优化，大家可以实验。
 
 我们宕机服务Region恢复的优化，我们解决方案采用并行方式，优于单线程串行的时间，直接使用了HBase初期启动，速度上大大提升，这是我们最终的效果图。这个效果图在第一个阶段当中，我们将缩短零秒并行10秒左右，其实15分钟到20分钟的优化上线的时间。这是我们效果最终对比，时间可以看得出来，优化后比优化前速度有质的提升，单位是一千到900，这个是秒。最重要的一点，我们在HDFS做了HA的优化，现在社区提出非常多的HA方案，他们都是作为为了解决HDFS单点问题所存在的，现在方案写到本地文件系统和其他东西当中，目前所做的工作至今是尚不成熟的，这部分有的是功能上满足不了。我们在新的社区代码当中发现了，保证在发现机器宕机之后像Node的关系，我们来源于社区还会还自于社区，依赖于社区已有的解决方案，我们加以做了整合和自己的二次研发。