Hbase在工作集群的参数调优
HBase使用规范
1 HBase1.1 使用场景1.半结构化或非结构化数据,对于数据结构字段不够确定或杂乱无章非常难按一个概念去进行抽取的数据。
2.记录很稀疏,列数量不固定，null及空列不存储。
3.存储变动历史记录的数据。
HBase是多版本号数据,依据Row key和Column key定位到的Value能够有随意数量的版本号值。
4.仅要求最终一致性,对于数据存储事务的要求不像金融行业和财务系统这么高，只要保证最终一致性。
5.高可用和海量数据以及很大的瞬间写入量，支持PB级数据，写性能要求在万行每秒以上。
6.适用于插入比查询操作更频繁的情况。
比如，对于历史记录表和日志文件。
7.业务场景简单,不需要太多的关系型数据库特性，列入交叉列，交叉表，事务，连接等。
1.2 配置规范1.部署架构图2.Regionserver必须和DataNode部署一一对应3.不同的业务表建立对应的namespace，避免将所有表创建在default命名空间下。
4.表的列族必须小于3个5.给表预分配10个分区6.对于访问少及顺序访问表关闭数据缓存7.表的rowkey必须具备唯一性8.不允许多个线程在同一时间共用同一个HTable实例9.数据写入失败要做异常处理10.在Java API中要在finally块中调用HTable的close方法11.Scan数据时要指定StartKey和EndKey12.提供内网访问方式3种方式:1)HBase RESTServer2)HBase ThriftServer3)HBase java API1.3 命名规范1.命名空间采用英文单词、阿拉伯数字的组合形式，其中，单词必须大写，并且首字符必须为英文字符，不能是数字。
2.命名空间不要使用连接符（下划线）拼接多个单词，简单语义的采用单个单词，复杂语义的采用多个单词的首字母拼接。
3.命名空间长度限制在4~8字符之间。
4.命名空间命名空间与项目名称、组织机构名称等保持一致。
hbase运维参考手册(项目实战)
1Hbase日常运维aA1.1监控Hbase运行状况1.1.1操作系统1.1.1.1IOa.群集网络IO，磁盘IO，HDFS IOIO越大说明文件读写操作越多。
当IO突然增加时，有可能：pact队列较大，集群正在进行大量压缩操作。
2.正在执行mapreduce作业可以通过CDH前台查看整个集群综合的数据或进入指定机器的前台查看单台机器的数据：b.Io wait磁盘IO对集群的影响比较大，如果io wait时间过长需检查系统或磁盘是否有异常。
通常IO增加时io wait也会增加，现在FMS的机器正常情况io wait在50ms以下跟主机相关的指标可以在CDH前台左上角先点“主机”选项卡然后选要查看的主机：1.1.1.2CPU如果CPU占用过高有可能是异常情况引起集群资源消耗，可以通过其他指标和日志来查看集群正在做什么。
1.1.1.3内存1.1.2JAVAGC 情况regionserver长时间GC会影响集群性能并且有可能会造成假死的情况1.1.3重要的hbase指标1.1.3.1region情况需要检查1.region的数量（总数和每台regionserver上的region数）2.region的大小如果发现异常可以通过手动merge region和手动分配region来调整从CDH前台和master前台以及regionServer的前台都可以看到region数量，如master前台：在region server前台可以看到storeFile大小：1.1.3.2缓存命中率缓存命中率对hbase的读有很大的影响，可以观察这个指标来调整blockcache的大小。
从regionserver web页面可以看到block cache的情况：1.1.3.3读写请求数通过读写请求数可以大概看出每台regionServer的压力，如果压力分布不均匀，应该检查regionServer上的region以及其它指标master web上可以看到所以regionServer的读写请求数regionServer上可以看到每个region的读写请求数1.1.3.4压缩队列压缩队列存放的是正在压缩的storefile，compact操作对hbase的读写影响较大通过cdh的hbase图表库可以看到集群总的压缩队列大小：可以通过CDH的hbase主页查询compact日志：点击“压缩”进入：1.1.3.5刷新队列单个region的memstore写满(128M)或regionServer上所有region的memstore大小总合达到门限时会进行flush操作,flush 操作会产生新的storeFile同样可以通过CDH的hbase前台查看flush日志：1.1.3.6rpc调用队列没有及时处理的rpc操作会放入rpc操作队列，从rpc队列可以看出服务器处理请求的情况1.1.3.7文件块保存在本地的百分比datanode和regionserver一般都部署在同一台机器上，所以region server管理的region会优先存储在本地，以节省网络开销。
hbase连接参数
HBase是一种分布式的、可伸缩的、大数据存储服务，使用Hadoop的HDFS作为底层存储。
要连接HBase，需要配置一些参数，以下是一些常见的连接参数：
1.hbase.zookeeper.quorum: 指定ZooKeeper集群的地址，HBase通过
ZooKeeper进行协调。
2.hbase.zookeeper.property.clientPort: 指定ZooKeeper的端口号，默认
为2181。
3.hbase.master: 指定HBase主服务器的地址和端口号，格式为
hostname:port。
4.hbase.zookeeper.session.timeout: 指定ZooKeeper的会话超时时间，单
位为毫秒。
5.hbase.client.scanner.caching: 指定扫描器缓存大小，可以提高扫描性
能。
6.hbase.client.keyvalue.maxsize: 指定单个键值对的最大大小，超过此大
小的键值对将不会被存储。
7.hbase.client.retries.number: 指定客户端重试次数，当与HBase服务器
通信失败时可以尝试重新连接。
这些参数可以在连接HBase时进行配置，以便更好地控制连接和通信的行为。
具体的参数值取决于实际需求和环境配置。
Hbase创建表参数说明
Hbase创建表参数说明Hbase创建表操作及参数说明1、创建命名空间 create_namespace 'test'2、创建user表，列族：info create 'test:user', 'info'3、查看表结构 describe 'test:user'表结构Table test:user is ENABLEDtest:userCOLUMN FAMILIES DESCRIPTION{NAME => 'info', BLOOMFILTER => 'ROW', VERSIONS => '1', IN_MEMORY => 'false', KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', COMPRESSION => 'NONE', MIN_VERSIONS => '0', BLOCKCACHE => 'true', BLOCKSIZE => '65536', REPLICATION_SCOPE => '0'}表结构参数详情1 DESCRIPTION2 'test:user', //namespace:tableName3 {4 NAME => 'info', //列族5 BLOOMFILTER => 'ROW', //参见：/book.html#bloom.filters.when6 VERSIONS => '1', //设置保存的版本数7 IN_MEMORY => 'false', //设置激进缓存，优先考虑将该列族放⼊块缓存中，8 //针对随机读操作相对较多的列族可以设置该属性为true9 KEEP_DELETED_CELLS => 'false', //参见：/book.html#cf.keep.deleted10 DATA_BLOCK_ENCODING => 'NONE', //数据块编码⽅式设置11 //参见：/book.html#data.block.encoding.enable12 TTL => 'FOREVER', //参见：/book.html#ttl13 'ColumnFamilies can set a TTL length in seconds, and HBase reached. This applies to all versions of a row - even the current one. The TTL time encoded in the HBase for the row is specified in UTC.'14 COMPRESSION => 'NONE', //设置压缩算法15 MIN_VERSIONS => '0', //最⼩存储版本数16 BLOCKSIZE => '65536', //设置HFile数据块⼤⼩（默认64kb）17 REPLICATION_SCOPE => '0', //配置HBase集群replication时需要将该参数设置为1.18 //参见：/blog/2012/08/hbase-replication-operational-overview/?utm_source=tuicool19 'REPLICATION_SCOPE is a column-family level attribute user has to alter each column family with the alter command as shown above, for all the column families he wants to replicate.'20 OCKCACHE => 'true' //数据块缓存属性21 }。
在线网络游戏数据分析的架构及优化
在线网络游戏数据分析的架构及优化在游戏以及其他应用的研发和运营过程中，如何了解应用的运行状况成了一个问题。
为了解决这个问题，我们像大多数公司一样，开始组建自己的数据分析团队。
到目前为止，行云数据分析平台每日接收和处理的原始日志有200GB左右，集群规模在20台服务器上下，每天为数十个产品的日常运营提供数据支持。
在这个过程中，我们在数据处理技术方面做了很多的探索，在此也希望和大家分享一下。
系统架构数据处理系统的架构和流程，最基本的框架流程如下图所示：每天，来自各个项目的数据每时每刻都在打入数据分析系统。
这些数据通过数据采集环节，被初步整理成一定的格式，然后录入集中的数据存储系统中。
当然，我们系统呈献给用户的是各种统计指标。
所谓统计指标，即对原始数据的聚合，形成一定的统计结论。
所以，我们需要有查询系统，基于海量的数据进行。
在我们的系统中，各个部分的技术选型如下：紫色的部分即为各个部分的技术实现客户的应用数据，通过REST API打入数据处理系统中。
这部分我们考虑使用PHP来实现，主要考虑其实现简单，便于水平扩展；处理速度也可以接受。
Rest API接收到的原始数据，在进入存储之前，还需要进一步整理，主要有两方面的原因：一是一些不合理的日志需要筛选出去；二是我们在这一步，有时候需要把接收到的数据转换成更基本的数据。
一个例子是应用程序可能会打入一个应用加载事件visit。
那么，我们收到visit的时候，还需要判断这个用户是不是第一次出现；以及用户加载的时候的一些refer信息，等等。
所以，这一步的逻辑比Rest API要复杂，做这些逻辑判断所需要的信息也更多，因此我们选用java开发了这一模块。
我们收集到的大量数据，有两方面的信息：一是事件信息，记录发生过的事件：用户A在某个时刻登录了一次；用户B在另一个时刻进行了一次购买，等等。
这种事件信息占了系统所存储信息的大部分，而且绝大部分是不断新增的数据。
我们采用HBase来存储这部分信息，一方面，HBase对于批量的写入性能很好；另一方面，在rowkey设计合理的情况下，其索引和查询性能也不错。
hbase连接参数
HBase连接参数是用于连接HBase数据库的配置参数，涵盖了定义、用法、重点、难点和注意事项等方面。
下面将详细介绍这些参数，并结合应用案例进行说明。
1.定义HBase连接参数是指在客户端连接HBase时需要配置的参数，用于建立与HBase服务器的连接，并指定客户端与服务器之间的通信方式。
2.用法HBase连接参数通常在客户端应用程序中设置，用于指定HBase服务器的地址、端口号以及其他连接相关的配置。
例如，在Java中使用HBase客户端连接HBase时，需要创建一个Configuration对象，并通过set方法设置各个连接参数。
3.重点HBase连接参数的重点包括以下几个方面：●HBase服务器的地址和端口号：这是连接HBase服务器的必要参数，用于指定HBase服务器的网络地址和监听端口。
●客户端的线程池大小：该参数用于设置客户端连接池的大小，以控制并发连接的数量。
●连接超时时间：指定客户端与服务器之间的连接超时时间，以防止长时间等待无响应的服务器。
●其他高级配置：如心跳检测、压缩等，可根据实际需求进行配置。
4.难点HBase连接参数的难点主要包括以下几点：●客户端与服务器的网络通信问题：需要确保客户端与服务器之间的网络通信正常，避免出现连接超时、丢包等问题。
●参数配置的合理性和性能优化：需要根据实际应用场景和性能需求，合理配置连接参数，并对其进行性能优化，以充分发挥HBase的性能优势。
●HBase的安全性配置：HBase支持Kerberos认证和SASL加密通信，需要正确配置相关参数以确保数据的安全性。
5.注意事项在使用HBase连接参数时，需要注意以下几点：●正确设置HBase服务器的地址和端口号，确保连接的可用性。
●根据实际需求配置线程池大小，避免资源浪费或连接不足的问题。
●根据实际网络状况设置合适的连接超时时间，以避免长时间等待无响应的服务器。
●注意配置安全性相关的参数，如Kerberos认证和SASL加密通信等，以确保数据的安全性。
hbase 原理与实践
hbase 原理与实践HBase（Hadoop Database）是一个开源的分布式NoSQL数据库，它构建在Hadoop分布式文件系统（HDFS）之上，并受Google Bigtable 的启发。
HBase旨在存储和管理大规模数据集，并提供高可用性和强一致性。
以下是HBase的原理和实践概述：HBase的原理：1. 数据模型：HBase采用列族-列-行的数据模型，其中数据按行存储，每一行都有一个唯一的行键。
列族包含多个列，而每个列可以包含多个版本。
这种模型非常适合处理稀疏数据，因为只有实际存储的数据才会占用存储空间。
2. 分布式存储：HBase使用HDFS来存储数据，数据被分割成多个区域（region），每个区域被存储在不同的Region Server上。
这使得HBase能够存储大规模数据，并提供横向扩展性。
3. 强一致性：HBase提供强一致性，确保数据的可靠性。
它使用ZooKeeper来进行协调和领导选举，以确保数据的一致性。
4. 高可用性：HBase具有内置的自动故障恢复机制，如果一个Region Server宕机，数据将自动迁移到其他可用的Region Server 上，以确保系统的高可用性。
5. 快速读写：HBase是为快速读写操作而设计的，特别是在随机访问大数据集时表现出色。
HBase的实践：1. 安装和配置：首先，你需要安装HBase并配置它，包括HBase 的主要配置文件，如hbase-site.xml，hbase-env.sh等。
2. 数据建模：设计HBase数据模型，包括表的结构、列族、列等，以满足应用程序的需求。
考虑如何组织数据以获得最佳性能。
3. API和客户端：使用HBase的Java API或其他支持的客户端库，如HBase Shell或REST API，与HBase进行交互。
4. 数据导入和导出：将数据导入到HBase表中，可以使用工具如Apache HBase Bulk Load或MapReduce作业。
编辑hbase-site.xml文件的方法
编辑hbase-site.xml文件的方法一、引言HBase是一个开源的、分布式的、可扩展的NoSQL数据库，常用于大数据存储和处理。
hbase-site.xml文件是HBase的配置文件，用于设置HBase的各项参数。
本文将介绍如何编辑hbase-site.xml文件。
二、编辑前的准备工作1. 确认你已经安装并正确配置了HBase环境。
2. 确保你有对HBase配置文件（hbase-site.xml）的写入权限。
1. 打开HBase的配置目录，通常在HBase的安装目录下的"conf"文件夹中。
2. 找到并打开hbase-site.xml文件。
如果文件不存在，你可以创建一个新的。
3. 使用文本编辑器（如Notepad++、Sublime Text等）打开文件，确保文件的编码格式为UTF-8。
4. 开始编辑文件，根据需要修改各项参数。
以下是一些常见的参数及其说明：a. <property>标签下的各个属性，如hbase.rootdir，用于设置HBase的数据存储位置；b. regionserver.wal禄限一址大小，用于设置HBase的数据备份大小；c. maxattempts，用于设置处理任务的最大失败次数；d. master.http-port，用于设置HBase的主服务器的HTTP端口等。
5. 在修改完所有参数后，保存并关闭文件。
6. 在HBase中重启HBase服务以使新的配置生效。
四、注意事项1. 在修改配置文件时，请务必仔细阅读并理解每个参数的含义和影响，再进行修改。
2. 修改后的配置文件应当备份，以防意外情况发生。
3. 如果你对HBase的配置不熟悉，建议在修改前咨询专业人士或查阅相关文档。
4. 在修改过程中，如果遇到任何问题，请及时停止并寻求帮助。
五、总结编辑hbase-site.xml文件是HBase系统管理中非常重要的一步，它直接影响到HBase的运行效率和稳定性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
因官方Book Performance Tuning部分章节没有按配置项进行索引，不能达到快速查阅的效果。
所以我以配置项驱动，重新整理了原文，并补充一些自己的理解，如有错误，欢迎指正。
配置优化zookeeper.session.timeout默认值：3分钟（180000ms）说明：RegionServer与Zookeeper间的连接超时时间。
当超时时间到后，ReigonServer会被Zookeeper从RS集群清单中移除，HMaster收到移除通知后，会对这台server负责的regions重新balance，让其他存活的 RegionServer接管.调优：这个timeout决定了RegionServer是否能够及时的failover。
设置成1分钟或更低，可以减少因等待超时而被延长的failover时间。
不过需要注意的是，对于一些Online应用，RegionServer从宕机到恢复时间本身就很短的（网络闪断，crash等故障，运维可快速介入），如果调低timeout 时间，反而会得不偿失。
因为当ReigonServer被正式从RS集群中移除时，HMaster 就开始做balance了（让其他RS根据故障机器记录的WAL日志进行恢复）。
当故障的RS在人工介入恢复后，这个balance动作是毫无意义的，反而会使负载不均匀，给RS带来更多负担。
特别是那些固定分配regions的场景。
hbase.regionserver.handler.count默认值：10说明：RegionServer的请求处理IO线程数。
调优：这个参数的调优与内存息息相关。
较少的IO线程，适用于处理单次请求内存消耗较高的Big PUT场景（大容量单次PUT或设置了较大cache的scan，均属于Big PUT）或ReigonServer的内存比较紧张的场景。
较多的IO线程，适用于单次请求内存消耗低，TPS要求非常高的场景。
设置该值的时候，以监控内存为主要参考。
这里需要注意的是如果server的region数量很少，大量的请求都落在一个region上，因快速充满memstore触发flush导致的读写锁会影响全局TPS，不是IO线程数越高越好。
压测时，开启Enabling RPC-level logging，可以同时监控每次请求的内存消耗和GC的状况，最后通过多次压测结果来合理调节IO线程数。
这里是一个案例?Hadoop and HBase Optimization for Read Intensive Search Applications，作者在SSD的机器上设置IO线程数为100，仅供参考。
hbase.hregion.max.filesize默认值：256M说明：在当前ReigonServer上单个Reigon的最大存储空间，单个Region超过该值时，这个Region会被自动split成更小的region。
调优：小region对split和compaction友好，因为拆分region或compact小region 里的storefile速度很快，内存占用低。
缺点是split和compaction会很频繁。
特别是数量较多的小region不停地split, compaction，会导致集群响应时间波动很大，region数量太多不仅给管理上带来麻烦，甚至会引发一些Hbase的bug。
一般512以下的都算小region。
大region，则不太适合经常split和compaction，因为做一次compact和split 会产生较长时间的停顿，对应用的读写性能冲击非常大。
此外，大region意味着较大的storefile，compaction时对内存也是一个挑战。
当然，大region也有其用武之地。
如果你的应用场景中，某个时间点的访问量较低，那么在此时做compact和split，既能顺利完成split和compaction，又能保证绝大多数时间平稳的读写性能。
既然split和compaction如此影响性能，有没有办法去掉？compaction是无法避免的，split倒是可以从自动调整为手动。
只要通过将这个参数值调大到某个很难达到的值，比如100G，就可以间接禁用自动split（RegionServer不会对未到达100G的region做split）。
再配合RegionSplitter这个工具，在需要split时，手动split。
手动split在灵活性和稳定性上比起自动split要高很多，相反，管理成本增加不多，比较推荐online实时系统使用。
内存方面，小region在设置memstore的大小值上比较灵活，大region则过大过小都不行，过大会导致flush时app的IO wait增高，过小则因store file 过多影响读性能。
hbase.regionserver.global.memstore.upperLimit/lowerLimit默认值：0.4/0.35upperlimit说明：hbase.hregion.memstore.flush.size 这个参数的作用是当单个Region内所有的memstore大小总和超过指定值时，flush该region的所有memstore。
RegionServer的flush是通过将请求添加一个队列，模拟生产消费模式来异步处理的。
那这里就有一个问题，当队列来不及消费，产生大量积压请求时，可能会导致内存陡增，最坏的情况是触发OOM。
这个参数的作用是防止内存占用过大，当ReigonServer内所有region的memstores所占用内存总和达到heap的40%时，HBase会强制block所有的更新并flush这些region以释放所有memstore占用的内存。
lowerLimit说明：同upperLimit，只不过lowerLimit在所有region的memstores所占用内存达到Heap的35%时，不flush所有的 memstore。
它会找一个memstore内存占用最大的region，做个别flush，此时写更新还是会被block。
lowerLimit算是一个在所有region强制flush导致性能降低前的补救措施。
在日志中，表现为“** Flush thread woke up with memory above low water.”调优：这是一个Heap内存保护参数，默认值已经能适用大多数场景。
参数调整会影响读写，如果写的压力大导致经常超过这个阀值，则调小读缓存hfile.block.cache.size增大该阀值，或者Heap余量较多时，不修改读缓存大小。
如果在高压情况下，也没超过这个阀值，那么建议你适当调小这个阀值再做压测，确保触发次数不要太多，然后还有较多Heap余量的时候，调大hfile.block.cache.size提高读性能。
还有一种可能性是?hbase.hregion.memstore.flush.size保持不变，但RS维护了过多的region，要知道 region数量直接影响占用内存的大小。
hfile.block.cache.size默认值：0.2说明：storefile的读缓存占用Heap的大小百分比，0.2表示20%。
该值直接影响数据读的性能。
调优：当然是越大越好，如果写比读少很多，开到0.4-0.5也没问题。
如果读写较均衡，0.3左右。
如果写比读多，果断默认吧。
设置这个值的时候，你同时要参考?hbase.regionserver.global.memstore.upperLimit?，该值是 memstore 占heap的最大百分比，两个参数一个影响读，一个影响写。
如果两值加起来超过80-90%，会有OOM的风险，谨慎设置。
hbase.hstore.blockingStoreFiles默认值：7说明：在flush时，当一个region中的Store（Coulmn Family）内有超过7个storefile时，则block所有的写请求进行compaction，以减少storefile数量。
调优：block写请求会严重影响当前regionServer的响应时间，但过多的storefile也会影响读性能。
从实际应用来看，为了获取较平滑的响应时间，可将值设为无限大。
如果能容忍响应时间出现较大的波峰波谷，那么默认或根据自身场景调整即可。
hbase.hregion.memstore.block.multiplier默认值：2说明：当一个region里的memstore占用内存大小超过hbase.hregion.memstore.flush.size两倍的大小时，block该region的所有请求，进行flush，释放内存。
虽然我们设置了region所占用的memstores总内存大小，比如64M，但想象一下，在最后63.9M的时候，我Put了一个200M的数据，此时memstore的大小会瞬间暴涨到超过预期的hbase.hregion.memstore.flush.size的几倍。
这个参数的作用是当 memstore的大小增至超过hbase.hregion.memstore.flush.size 2倍时，block所有请求，遏制风险进一步扩大。
调优：这个参数的默认值还是比较靠谱的。
如果你预估你的正常应用场景（不包括异常）不会出现突发写或写的量可控，那么保持默认值即可。
如果正常情况下，你的写请求量就会经常暴长到正常的几倍，那么你应该调大这个倍数并调整其他参数值，比如hfile.block.cache.size和hbase.regionserver.global.memstore.upperLimit/lowerLimit，以预留更多内存，防止HBase server OOM。
hbase.hregion.memstore.mslab.enabled默认值：true说明：减少因内存碎片导致的Full GC，提高整体性能。
调优：详见/avoid-full-gc-in-hbase-using-arena-allocation其他启用LZO压缩LZO对比Hbase默认的GZip，前者性能较高，后者压缩比较高，具体参见?Using LZO Compression。
对于想提高HBase读写性能的开发者，采用LZO是比较好的选择。
对于非常在乎存储空间的开发者，则建议保持默认。
不要在一张表里定义太多的Column FamilyHbase目前不能良好的处理超过包含2-3个CF的表。
因为某个CF在flush发生时，它邻近的CF也会因关联效应被触发flush，最终导致系统产生更多IO。
批量导入在批量导入数据到Hbase前，你可以通过预先创建regions，来平衡数据的负载。