文章列表
MegaStore是Google在BigTable之上实现了一个跨机房高可用的数据库。它提供了类似DB的数据分布、索引的功能，实现了在EntityGroup内部以及EntityGroup之间的事务性，并且通过Paxos协议实现在DC之间多备份的一致性。
MegaStore的目标：在跨机房PB级的数据规模上，支持交互式在线服务。我们知道在Google内部的访问情况是，每天几百亿次的访问请求的应用，读写比例大概在7：1。在这样的规模上，需要达到的特性：1）高扩展性，无论在机器扩展性还是数据规模上2）快速的开发迭代速度，3）低延迟4）数据一致性5）高可用
MegaStore的实现原理：1）从数 ...
背景：
当前大规模数据分析框架的发展朝着两个趋势在变化：
1）任务执行时间更短。
2）更大的任务并行度。
因此，在当前分布式计算框架的调度系统中，需要有所改变，以满足如下的需求：
1）更快的任务调度效率，mill-seconds级别。
2）良好的容错，High Availability.
3）较高的吞吐率，High Throughput.
背景
在HMaster、RegionServer内部，创建了RpcServer实例，并与Client三者之间实现了Rpc调用，HBase0.95内部引入了Google-Protobuf作为中间数据组织方式，并在Protobuf提供的Rpc接口之上，实现了基于服务的Rpc实现，本文详细阐述了HBase-Rpc实现 ...
借鉴于LevelDB、Cassandra的Compaction方法，https://issues.apache.org/jira/browse/HBASE-7667 提出了Stripe Compaction的方法。
Motivation：1）过多Region会增大RS维护的开销，降低RS的读写性能。随着数据量的增大，在一定程度上增加Region个数，会提高系统的吞吐率。然而，RS上服务的Region个数增多，增加了RS下内存维护的开销，尤其每个Store下都配置有一个MemStore，从而会造成频率更高的Flush操作，影响系统的读写性能。因此，如果能够提出更轻量级的mini-Region ...
背景：
在hbase应用中，如果使用C++来访问HBase，往往通过ThriftServer进行数据的读写，ThriftServer服务的状况直接影响了应用服务的体验。因此，在HBase ThriftServer之上的Metrics系统、以及实时监控系统，可以第一时间发现服务质量变化以及相关问题，同时，良好的监控系统，也有助于服务的完善。
ThriftServer实时监控系统的挑战
1）ThriftServer的服务具有分散性。我们一般为不同的应用启动多个ThriftServer，那么如果我们想多维度统计分析某个应用的统计状况，就会比较困难。例如：百川抓取平台，随机使用多个Thrift ...
1、背景
随着大数据表格应用的驱动，我们的HBase集群越来越大，然而由于机器、网络以及HBase内部的一些不确定性的bug，使得系统面临着一些不确定性的故障。
因此，HBase上有很多的Region组成，需要控制每个表格的Region的状态。
分析：
1）实时掌控Region的状态。应用的每次访问要直接与HBase某个Region关联，需要探测Table上Region是否处于可用状态。
2）Region的读写与底层的HDFS的状态相互关联。这种关联决定了通过Region的读写状况的监控，也可以反映HDFS的状况。
1、hbase压缩与编码的配置
安装LZO
解决方案：1）apt-get install liblzo2-dev2)hadoop-gpl-compression-0.2.0-dev.jar 放入classpath把libgpl下的共享库文件放入/opt/hbase/hbase/lib/native/Linux-amd64-64/libgplcompression.a libgplcompression.la libgplcompression.so libgplcompression.so.0 libgplcompression.so.0.0.03)配置：<property> ...
背景：
随着HBase在性能和稳定性持续改善和成功案例的积累，HBase逐渐成为了在大数据NoSQL领域的事实标准。越来越多有着大数据应用和处理需求的互联网公司、IT公司，将离线或者半在线的数据平台搭建在HBase之上。
在深入使用和运维过程中，我们发现当新的应用需求而来时，处于性能和效率的考虑，我们就要根据数据规模单独搭建系统，而应用需求和规模的变化，会给HBase的运维和资源使用带来了一定的困扰：
1）HBase集群越多，运维成本就越大。因为稳健的Hbase监控是要从底层存储设备、网络资源、内存、CPU、hdfs、RegionServer到应用服务器读写性能的自下向上的体系，搭建H ...
Compaction介绍
Compaction是buffer->flush->merge的Log-Structured Merge-Tree模型的关键操作，主要起到如下几个作用：
1）合并文件
2）清除删除、过期、多余版本的数据
3）提高读写数据的效率
Minor & Major Compaction的区别
1）Minor操作只用来做部分文件的合并操作以及包括minVersion=0并且设置ttl的过期版本清理，不做任何删除数据、多版本数据的清理工作。
2）Major操作是对Region下的HStore下的所有StoreFile执行合并操作，最终的结果是整理 ...
HBase Flush操作流程以及对读写服务的影响
HBase的Flush操作的触发条件：
1)Manual调用，HRegionInterface#flushRegion，可以被用户态org.apache.hadoop.hbase.client.HBaseAdmin调用flush操作实现，该操作会直接触发HRegion的internalFlush。
2)HRegionServer的一次更新操作，使得整个内存使用超过警戒线。警戒线是globalMemStoreLimit, RS_JVM_HEAPSIZE * conf.getFloat(“hbase.regionserver.glo ...
本研究针对HBase 0.94.* 及以上版本的系统。
RegionServer
本目标主要集中分析在RegionServer提供的相关Metrics接口。在0.94新版本中，Metrics包括：RegionServerMetrics、JvmMetrics、以及RegionServerDynamicMetrics。下面分别进行介绍。
1、RegionServerMetrics
这是延续了以前版本的Metrics。它主要是以RegionServer为单位的基本功能的监控信息的收集，主要包括：
1）通用信息的收集。例如RS内store个数、storefiles的个数等。
2）与RS整 ...
OpenTSDB是一个架构在Hbase系统之上的实时监控信息收集和展示平台。
它在海量数据的压力下，仍然保证了存储的效率，那么它背后有什么值得借鉴的地方呢？
1）使用AsyncHbase而非HBase自带的HTable。使用线程安全、非阻塞、异步、多线程并发的HBase API，在高并发和高吞吐时，可以获得更好的效果。建议在使用AsyncHBase时，在CPU core有保证的前提下，可以设置16或者24。
2）采用固定长度的Rowkey，让Rowkey包含尽可能多的检索信息。这一点的话，OpenTSDB存储的数据要包含大量的metrics和tag信息，这些信息的长度是变长的，因此， ...
Region是HBase的资源管理单位，在Region的生命周期内，一个Region迁移会发生在如下的情况下：1）HMaster的Load Balance，造成部分Region在RS之间迁移。默认使用了org.apache.hadoop.hbase.master.DefaultLoadBalancer，仅仅考虑RS上Region个数的分配的均衡性。
2）Region Split过程。这部分内容可以参考http://blog.sina.com.cn/s/blog_4a1f59bf01018tu4.html
3) RS Offline过程-〉LOG Split过程-〉Region迁移。
在 ...
HBase Metrics
HBase Metrics是一种监控信息实时收集机制。它负责收集的信息有：
功能性信息（Compaction Queue、Store Files个数等）
JVM使用信息 (Heap Memory 的变化)
rpc访问信息
借助与Hadoop Metrics同样的方式，向Ganglia汇报。
Ganglia is a scalable distributed monitoring system for high performance computing systems such as clusters and Grids.
based on ...
HBase数据存储状况
1、2PB+ of online data in HBase (6PB+ with replication; excludes backups),存储了message data, metadata, search index 等信息。
2、每天大概有8B+Messages，增长到每月大概产生250TB的数据。
3、Traffic to HBase ▪ 75+ Billion R+W ops/day ▪ At peak: 1.5M ops/sec ▪ ~ 55% Read vs. 45% Write ops 。
Facebook选择HBase的原因
▪ ...