hbase开发源码

1. hbase源代码 纯java开发的吗

是的，纯java开发的nosql

2. 如何搭建Hbase源码阅读环境，并能进行编译运行

hbase源码导入eclipse分三步：
1.svn下载源码
2.mvn package -Dmaven.test.skip.exec=true编译源码
3.导入eclipse，可以用插件，用mvn eclipse:eclipse生成eclipse文件，导入eclipse。

3. hbase源码怎么导入eclipse

hbase源码导入eclipse分三步：
1.svn下载源码
2.mvn package -Dmaven.test.skip.exec=true编译源码
3.导入eclipse，可以用插件，用mvn eclipse:eclipse生成eclipse文件，导入eclipse。

4. 【HBase】HBase 自动拆分和预分区

[TOC]

HBase 中，表会被划分为1...n 个 Region，被托管在 RegionServer 中。

Region 二个重要的属性：StartKey 与 EndKey 表示这个 Region 维护的 RowKey 范围，当读/写数据时，如果 RowKey 落在某个 start-end key 范围内，那么就会定位到目标region并且读/写到相关的数据。

默认，HBase 在创建表的时候，会自动为表分配一个 Region，正处于混沌时期，start-end key 无边界，所有 RowKey 都往这个 Region里分配。

当数据越来越多，Region 的 size 越来越大时，达到默认的阈值时（根据不同的拆分策略有不同的阈值），HBase 中该 Region 将会进行 split，会找到一个 MidKey 将 Region 一分为二，成为 2 个 Region。而 MidKey 则为这二个 Region 的临界，左为 N 无下界，右为 M 无上界。< MidKey 被分配到 N 区，> MidKey 则会被分配到 M 区。

随着数据量进一步扩大，分裂的两个 Region 达到临界后将重复前面的过程，分裂出更多的 Region。

Region 的分割操作是不可见的，Master 不会参与其中。RegionServer 拆分 Region的步骤是：先将该 Region 下线，然后拆分，将其子 Region 加入到 META 元信息中，再将他们加入到原本的 RegionServer 中，最后汇报 Master。

执行 split 的线程是 CompactSplitThread。

在 2.0.5 版本中，HBase 提供了 7 种自动拆分策略：

他们之间的继承关系如下：

有三种配置方法：

0.94.0 之前的默认拆分策略，这种策略非常简单，只要 Region 中的任何一个 StoreFile 的大小达到了 hbase.hregion.max.filesize 所定义的大小 ，就进行拆分。

1）相关参数：

hbase.hregion.max.filesize

2）部分源码 ：

拆分的阈值大小可在创建表的时候设置，如果没有设置，就取 hbase.hregion.max.filesize 这个配置定义的值，如果这个配置也没有定义，取默认值 10G。

3）拆分效果：

经过这种策略的拆分后，Region 的大小是均匀的，例如一个 10G 的Region，拆分为两个 Region 后，这两个新的 Region 的大小是相差不大的，理想状态是每个都是5G。

**ConstantSizeRegionSplitPolicy **切分策略对于大表和小表没有明显的区分，阈值（hbase.hregion.max.filesize）：

4）创建表时配置：

该策略继承自 ConstantSizeRegionSplitPolicy，是 0.94.0 到 2.0.0 版本的默认策略，其 优化了原来 ConstantSizeRegionSplitPolicy 只是单一按照 Region 文件大小的拆分策略，增加了对当前表的分片数作为判断因子 。当Region中某个 Store Size 达到 sizeToCheck 阀值时进行拆分，sizeToCheck 计算如下：

如果表的分片数为 0 或者大于 100，则切分大小还是以设置的单一 Region 文件大小为标准。如果分片数在 1~99 之间，则由 min(单一 Region 大小， Region 增加策略的初始化大小 * 当前 Table Region 数的3次方) 决定 。

Region 增加策略的初始化大小计算如下：

1）相关参数：

hbase.hregion.max.filesize

hbase.increasing.policy.initial.size

hbase.hregion.memstore.flush.size

2）部分源码：

在默认情况，使用 策略拆分 Region 的过程是:

3）拆分效果：

和 ConstantSizeRegionSplitPolicy 一样，也是均匀拆分。

不同的是， 切分策略弥补了ConstantSizeRegionSplitPolicy 的短板，能够自适应大表和小表，并且在大集群条件下对于很多大表来说表现很优秀。

但并不完美，这种策略下很多小表会在大集群中产生大量小 Region，分散在整个集群中。而且在发生 Region 迁移时也可能会触发 Region 分裂。

4）创建表时配置：

2.0 版本默认切分策略。SteppingSplitPolicy 是 的子类，其对 Region 拆分文件大小做了优化，如果只有1个 Region 的情况下，那第1次的拆分就是 256M，后续则按配置的拆分文件大小（10G）做为拆分标准。

1）相关参数：

同 。

2）全部源码：

它的源码只有一个方法，优化了 getSizeToCheck 方法，其他都是继承 自 类。

3）拆分效果：

在 策略中，针对大表的拆分表现很不错，但是针对小表会产生过多的 Region，SteppingSplitPolicy 则将小表的 Region 控制在一个合理的范围，对大表的拆分也不影响。

4）创建表时配置：

KeyPrefixRegionSplitPolicy 是 的子类，该策略除了具备其父类自动调整 Region 拆分阈值大小、适应大小表的特点外，增加了对拆分点(splitPoint，拆分点就是 Region 被拆分处的 RowKey)的定义，可以保证有相同前缀的 RowKey不会被拆分到两个不同的 Region 里面。

1）相关参数：

在 的配置之上增加了一个参数。

KeyPrefixRegionSplitPolicy.prefix_length

2）部分源码：

先从父类获取拆分点，如果设置了 prefixLength > 0，就从父类拆分点中截取需要的前缀作为新的拆分点返回。

3）拆分效果：

KeyPrefixRegionSplitPolicy （SteppingSplitPolicy、、BusyRegionSplitPolicy (HBase-2.x Only)）按照 RowKey 的前缀去拆分 Region，但是什么时候拆分，原 Region 容量的最大值是多少还是需要使用 的方法去计算 。

如果所有数据都只有一两个前缀，那么采用默认的策略较好。 如果前缀划分的比较细，查询就比较容易发生跨 Region 查询的情况，此时采用KeyPrefixRegionSplitPolicy 较好。

所以这个策略适用的场景是：

4）创建表时配置：

继承自 ，也是根据 RowKey 前缀来进行拆分的。不同就是：KeyPrefixRegionSplitPolicy 是根据 RowKey 的固定前几位字符来进行判断，而 是根据分隔符来判断的。

1）相关参数：

在 的配置之上增加了一个参数。

.delimiter

2）部分源码：

先找到分隔符下标位置，然后从父类的拆分点截取出来。

3）拆分效果：

根据 RowKey 中指定分隔字符做为拆分，显得更加灵活，如 RowKey 的值为“userid_eventtype_eventid”，userId 不是定长的，则 可以取 RowKey 值中从左往右且第一个分隔字符串之前的字符做为拆分串，在该示例中就是“userid”。

4）创建表时配置：

之前的策略都未考虑 Region 热点问题，考虑某些 Region 可能被频繁访问，负荷很大，BusyRegionSplitPolicy 策略同样继承自 ，但主要针对 Region 问题，是在 2.x 中新增加的拆分策略。

1）相关参数：

在 的配置之上增加了如下参数：

hbase.busy.policy.blockedRequests

hbase.busy.policy.minAge

hbase.busy.policy.aggWindow

2）部分源码：

在判断是否需要进行拆分的时候，先调用父类的 shouldSplit 方法检验，如果需要则直接返回 true，否则需要判断当前时间是否比开始时间大于 minAge 值，如果是的，则计算请求阻塞率 blockedReqRate，如果阻塞率大于设定的阈值，则进行拆分。

阻塞率的计算如下：

主要的计算逻辑是：请求的被阻塞率(aggBlockedRate) = curTime - prevTime 时间内新增的阻塞请求 / 这段时间的总请求。

3）拆分效果：

如果系统常常会出现热点 Region，又对性能有很高的追求，那么这种策略可能会比较适合。

它会通过拆分热点 Region 来缓解热点 Region 的压力，但是根据热点来拆分Region 也会带来很多不确定性因素，因为不能确定下一个被拆分的 Region 是哪个。

4）创建表时配置：

DisabledRegionSplitPolicy 就是不使用 Region 拆分策略，将所有的数据都写到同一个 Region 中。

1）全部源码：

源码很简单，就是直接返回 false。

2）拆分效果：

这个策略极少使用。

即使在建表的时候合理的进行了预拆分，还没有写入的数据的时候就已经手动分好了 Region，但是随着数据的持续写入，我预先分好的 Region 的大小也会达到阈值，那时候还是要依靠 HBase 的自动拆分策略去拆分 Region。

但这种策略也有它的用途：

假如有一批静态数据，一次存入以后不会再加入新数据，且这批数据主要是用于查询，为了性能好一些，可以先进行预分区后，各个 Region 数据量相差不多，然后设置拆分策略为禁止拆分，最后导入数据即可。

3）创建表时配置：

已经有自动分区了，为什么还需要预分区？

HBase 在创建表的时候，会自动为表分配一个Region，当一个 Region 达到拆分条件时（shouldSplit 为 true），HBase 中该 Region 将会进行 split，分裂为2个 Region，以此类推。表在进行 split 的时候，会耗费很多的资源，有大量的 io 操作，频繁的分区对 HBase 的性能有很大的影响。

所以，HBase 提供了预分区功能，让用户可以在创建表的时候对表按照一定的规则分区。

假设初始 10 个 Region，那么导入大量数据的时候，就会均衡到 10 个 Region 里面，显然比初始 1 个 Region 要好很多， 合理的预分区可以减少 Region 热点问题，提升写数据的性能和速度，而且也能减少后续的 split 操作 。

首先要明白数据的 RowKey 是如何分布的，然后根据 RowKey 的特点规划要分成多少 Region，每个 Region 的 startKey 和 endKey 是多少，接着就可以预分区了。

比如，RowKey 的前几位字符串都是从 0001~0010 的数字，这样可以分成10个Region：

第一行为第一个 Region 的 stopKey。为什么后面会跟着一个"|"，是因为在ASCII码中，"|"的值是124，大于所有的数字和字母等符号。

shell中建分区表

也可以通过指定 SPLITS_FILE 的值指定分区文件，从文件中读取分区值，文件格式如上述例子所示：

预分区后，可以从 HBase ui 页面观察到：

HBase API 建预分区表

为防止热点问题，同时避免 Region Split 后，部分 Region 不再写数据或者很少写数据。也为了得到更好的并行性，希望有好的 load blance，让每个节点提供的请求处理都是均等的，并且 Region 不要经常 split，因为 split 会使 server 有一段时间的停顿，随机散列加上预分区是比较好的解决方式。

预分区一开始就预建好了一部分 Region，这些 Region 都维护着自已的 start-end keys，再配合上随机散列，写数据能均等地命中这些预建的 Region，就能通过良好的负载，提升并行，大大地提高了性能。

hash + 预分区

在 RowKey 的前面拼接通过 hash 生成的随机字符串，可以生成范围比较随机的 RowKey，可以比较均衡分散到不同的 Region 中，那么就可以解决写热点问题。

假设 RowKey 原本是自增长的 long 型，可以将 RowKey 先进行 hash，加上本身 id ，组成rowkey，这样就生成比较随机的 RowKey 。

那么对于这种方式的 RowKey 设计，如何去进行预分区？

partition + 预分区

partition 顾名思义就是分区式，这种分区有点类似于 maprece 中的 partitioner，将区域用长整数作为分区号，每个 Region 管理着相应的区域数据，在 RowKey 生成时，将 id 取模后，然后拼上 id 整体作为 RowKey 。

1. HBase Region 自动拆分策略
2. hbase预分区

5. HBase宕机恢复-SplitWAL

HBase检测宕机是通过Zookeeper实现的， 正常情况下RegionServer会周期性向Zookeeper发送心跳，一旦发生宕机，心跳就会停止，超过一定时间（SessionTimeout,我们集群配置的是30s）Zookeeper就会认为RegionServer宕机离线，并将该消息通知给Master。

Master检测到宕机之后会将宕机RegionServer上的所有Region重新分配到集群中其他正常RegionServer上去，再根据HLog进行丢失数据恢复，恢复完成之后就可以对外提供服务，整个过程都是自动完成的。

HBase切分HLog当前主要有两种模式Distributed Log Splitting和Distributed Log Replay。
由于我们的集群没有配置hbase.master.distributed.log.replay=true,所以这里主要研究Distributed Log Splitting流程。

Distributed Log Splitting
整体流程：

Regionserver作为实际工作的执行者，抢占任务以及抢占任务之后的工作流程：

源码：

整个切分过程中可能出现的问题、解决方法：（持续更新）

1.RS节点假死后，DataNode进程处于存在但不可服务的状态，会导致hbase split wal超时到几乎无法进行，10分钟后DataNode彻底下线才能恢复性能

处理：联系SA关机、重启机器，可以加速集群恢复

参考： http://hbasefly.com/2016/10/29/hbase-regionserver-recovering/

6. 大数据有什么技术，大数据技术内容介绍

大数据是众多学科与统计学交叉产生的一门新兴学科。大数据牵扯的数据挖掘、云计算一类的，所以是计算机一类的专业。分布比较广，应用行业较多。

零售业：主要集中在客户营销分析上，通过大数据技术可以对客户的消费信息进行分析。获知客户的消费习惯、消费方向等，以便商场做好更合理商品、货架摆放，规划市场营销方案、产品推荐手段等。

金融业：在金融行业里头，数据即是生命，其信息系统中积累了大量客户的交易数据。通过大数据可以对客户的行为进行分析、防堵诈骗、金融风险分析等。

医疗业：通过大数据可以辅助分析疫情信息，对应做出相应的防控措施。对人体健康的趋势分析在电子病历、医学研发和临床试验中，可提高诊断准确性和药物有效性等。

制造业：该行业对大数据的需求主要体现在产品研发与设计、供应链管理、生产、售后服务等。通过数据分析，在产品研发过程中免除掉一些不必要的步骤，并且及时改善产品的制造与组装的流程。

7. hbase 源码 什么语言开发的

是用java开发的，hbase包含两个核心服务，一个是HMaster，一个是HRegionServer，在hbase部署的服务器上调用jps命令能查看到这两个进程。

8. hbase单机模式下，使用java API远程连接hbase的问题。

首先你应该看Master进程是否已经成功启动，检查下master的60010监控界面。这日志报的是连接拒绝 ，或者关闭防火墙

极有可能是你PC机网络无法连接到虚拟机里边，你可以从本机telnet下虚拟机上master的端口，看下能连上不

9. Hbase源代码不开放

不开放。Hbase源代码是进行过加密设置的，没有进行对外开放，是为了更好的做好保密工作，有非常重要的信息技术类文件，各部门领导员工都非常重视。

10. java可以用来开发什么软件呀

1、嵌入式领域
Java在嵌入式领域也有很大的应用。你只需要130KB就能够使用Java技术（在一块小的芯片或者传感器上），这显示了这个平台是多么的可靠。Java最初是为了嵌入式设备而设计的。
事实上，这也是Java最初的一项“立即编写，随处运行”主旨的一部分。
2、大数据技术
Hadoop和其他的大数据技术也在不同程度使用着Java，例如Apache的基于Java的Hbase，Accumulo（开源），以及ElasticSearch。 但是Java并没有占领整个领域，还有其他的大数据技术例如MongoDB就是使用C++编写的.如果Hadoopor和ElasticSearch逐渐发展，那么Java就能有潜力在大数据技术领域上得到更大的发展空间。
3、软件工具
很多有用的软件和开发工具都是运用Java编写和开发的，例如Ecilpse，InetelliJIdea和NetbansIDE.。我认为这些都是最经常使用的用Java编写的桌面应用程序。就如上面所说，Swing曾经在图形用户界面的客户端开发非常流行，它们大多数应用在金融服务领域以及投资银行。虽然现在JavaFx正在逐渐地流行起来，但仍然无法替代Swing，而且C#已经在大部分金融领域中代替了Swing。
4、网站应用
Java同样也在电子商务和网站开发上有着广泛的运用。你可以运用很多RESTfull架构，这些架构是用SpringMVC，Struts2.0和类似的框架开发出来的。 甚至简单的Servlet，JSP和Struts在各种政府项目也是备受欢迎，许多政府，医疗，保险，教育，国防和其他部门的网站都是建立在Java之上的。
5、在金融服务行业的服务器应用
Java在金融服务业有着很大应用。很多的全球性投资银行例如GoldmanSachs（高盛投资公司），Citigroup（花旗集团），Barclays（巴克莱银行），StandardCharted（英国渣打银行）和一些其他银行都用Java编写前台和后台的电子交易系统，结算、信息确认系统，数据处理项目和以及其他的项目。
Java被运用于编写服务端应用，但大多数没有前端，都是从一个服务端（上一级）接受数据，处理数据后发向其他的处理系统（下一级）。 JavaSwing由于能开发出图形用户界面的客户端供交易者使用而备受欢迎，但是现在C#正在快速地取代Swing的市场，这让Swing倍有压力。
6、交易系统
第三方交易系统，金融服务行业的一大部分，同样也是使用Java编写的。例如像Murex这种受欢迎的交易系统，运用于与许多的银行前端链接，同样也是用Java编写的。
7、J2MEApps
虽然IOS和Android的到来几乎扼杀了J2ME的市场，但是仍然有很多的低端诺基亚和三星手机在使用着J2ME。 曾经有段时间大部分的游戏,手机应用都是利用MIDP和CLDC,或者J2ME部分平台编写的，以适用于Android系统。J2ME依然在蓝光、磁卡、机顶盒等产品中流行着。app之所以如此流行是因为对于所有的诺基亚手机，app仍然适用于J2ME。
8、高频交易领域
Java平台已经大大提高了性能特点和JITS，并且Java也拥有像C++级别的传输性能。因此，Java也流行于编写高并发系统。 虽然Java的传输性能不比C++，但你可以不用考虑Java的安全性，可移植性和可维护性等问题（Java内部已经实现好了），而且Java有着更快的运行速度。安全性等问题会使一个没有经验的C++程序员编写的应用程序变得更加缓慢和不可靠。
9、科学应用
现在Java经常是科学应用的默认选择，包括了自然语言处理。这最主要的原因是因为Java比起C++或者其他语言有更加的安全，可移植，可维护，而且Java有着更好的高级并发工具。
10、安卓Apps
如果你想知道Java应用在哪里，你离答案并不远。打开你的安卓手机或者任何的App，它们完全是用有着谷歌AndroidAPI的Java编程语言编写的，这个API和JDK非常相似。前几年安卓刚开始起步而到今日已经很多Java程序员是安卓App的开发者。