Apache HBase

今日有朋友加好友与我探讨一些问题，我觉得这些问题倒挺有价值的；于是就想在本公众号开设一个问答专栏，方便技术交流与分享，专栏名就定为：《读者来信》。如遇到本人能力有限难以解决的问题，该贴将会被转发至我的资源圈寻求大佬们出手帮助，并附上提问者微信二维码。也欢迎大家在留言区积极探讨解决方案~ 来信人：黄*伟 小猿提问 如果我用Spark处理文件写进HBase，文件按日期每天增量下发，如果只想在HBase中保留最近90天的文件数据，有什么好的方法吗？TTL会有禁用表操作，后端查询就会报错。除了TTL，还有别的解决方案吗？ 小猿分析 该问题主要的症结点在于：建表之初，没有及时给列族设置TTL，入数据之后想到可以设置表的TTL属性来保证数据时效性但又不想禁用表。怎么办呢？ 小猿解答 这里，小猿给出两条解决方案： 方案一： 其实在稍微高一点的HBase版本，设置表TTL属性已经可以在线进行，不需要disable表了。如果不确定，可以先建一个测试表在线设置一下TTL试一试。如果支持，那可以选择在低峰期通过HBase Shell手动修改列族的时效性，一劳永逸。 hbase(main):030:0> create 'test','f1' 0 row(s) in 1.2990 seconds => Hbase::Table - test hbase(main):031:0> desc 'test'

本文作者：HelloDeveloper 在 4 月 7 日由 @百度 主办、 @InfoQ 策划组织和实施的第 25 期百度技术沙龙活动上，来自百度数据流计算系统 DStream 项目负责人杨栋（ @Sherlock__Yang）、58 同城 (58.com) 云平台技术负责人，58 同城技术中心架构部架构师徐振华（ @浊者）分别分享了各自在海量数据存储和处理上取得的成果及经验，话题涉及“Hypertable Goes Realtime at Baidu”，以及“58 同城在分布式存储方面的架构实践”等。本文将对他们各自的分享做下简单的回顾，同时提供相关资料的下载。 主题一：Hypertable Goes Realtime at Baidu（微盘下载讲稿） 来自百度数据流计算系统 DStream 项目负责人杨栋第一个为大家分享，本次演讲的主要内容包括：Hypertable 能够满足应用的哪些需求、实际应用中遇到的挑战有哪些、可靠性 or 性能、如何应对这些挑战以及 Hypertable 和 HBase 有哪些异同。杨栋提到，在 Noah 系统最初建设时，主要遇到了以下的问题： MySQL Not inherently distributed（数据的无序增长、频繁地手工分配数据）；表大小的限制；不够灵活的结构 Hadoop 不支持随机写入；随机读取的支持也不理想 由此

1.数据采集到hadoop中； 2.数据在采集过程中，一部分丢给hdfs，一部分丢该实时的处理系统(kafka) kafka严格上说并不是消息队列，消息队列是符合 gms 规范的，有先后顺序的，kafka不保证顺序，严格意义上说kafka是一个分布式的消息缓存，队列是取一个少一个，而缓存是一直存在的 为什么要放到kafka呢，因为要对数据进行实时处理，会接一个storm，实时流式计算系统，hadoop是离线系统 把数据抽取出来想要的字段，例如上网时间，电话号码，上网的流量，请求的url等，然后存储到Hbase中 Hbase与HDFS有什么区别？ Hbase会根据每一行的主键（rowkey)的字典顺序将数据进行排序，因此只要把行键设计的好，就可以提高查询效率 大量的数据在Hbase存储，在mysql、cracle要就存满了，为什么在Hbase可以存储下？ Hbase天生就是分布式实现的，mysql是靠人为取分库分表，而Hbase对用户呈现就是一张表，但是这张表本质上的分布在多个服务器上管理的，这样的好处就是这个表可以无限的扩容，像细胞一样分裂表，存储变大后就会分裂出其他表。对用户来说是透明的扩容 Hbase有一个主服务器Master，从服务器管理分，一般从服务器和datanode放在一起 Hbase的业务需求比较简单 获取基站数据 把基站信信息放到hafka中

hbase为单机版且与应用在同一台机器上，不用配置任何参数 hbase为集群，最小连接代码如下 Configuration config = HBaseConfiguration.create(); config.set("hbase.zookeeper.quorum", "localhost"); // Until 2.x.y versions // ---- or ---- config.set("hbase.masters", "localhost:1234"); // Starting 3.0.0 version 来源： oschina 链接： https://my.oschina.net/u/2499008/blog/3217563

3 月，跳不动了？>>> 1.只需要引入HBase的客户端依赖即可。 <!--Hbase客户端--> <dependency> <groupId>org.apache.hbase</groupId> <artifactId>hbase-client</artifactId> <version>1.2.1</version> </dependency> 2.HBaseUtils.java 工具类抽取 public class HBaseUtils { private static Configuration configuration; // 1.获取配置对象 static { configuration = HBaseConfiguration.create(); configuration.set("hbase.zookeeper.quorum","hadoop1:2181,hadoop2:2181,hadoop3:2181"); } // 2.获取连接对象 public static Admin getAdmin() throws IOException { Connection connection = ConnectionFactory.createConnection(configuration); Admin admin = connection.getAdmin();

3 月，跳不动了？>>> 关于这个环境变量。存放在hadoop-env.sh里面。 这个环境变量是hadoop执行程序时会查询class的路径。以前遇到过在本地开发Hbase程序，本地编译通过(本地开发有在IDE里面导入jar包)，打包jar包(并未包含开发时的Hbase的lib中的jar包因为考虑到运行linux环境中有这些jar包)然后在linux环境下hadoop jar XXX运行报错不能够找到类。原因是环境中的Hbase 的lib路径没有包含在HADOOP_CLASSPATH里面 解决方法在hadoop-env.sh里面添加一行 export HADOOP_CLASSPATH = $HADOOP_CLASSPATH :/XXX/hbase/lib/* (*一定要不然报错) 包含jar包即可解决问题 点赞 6 收藏 分享 文章举报 Allocator 发布了40 篇原创文章 · 获赞 55 · 访问量 11万+ 私信 关注 来源： oschina 链接： https://my.oschina.net/u/4340310/blog/3210504

3 月，跳不动了？>>> 求职期间，我们遇到的大数据开发和大数据平台开发有什么区别？ 不少人问过我一个问题，大数据开发和大数据平台开发，有什么不一样？今天就这个话题说几句。先给大家上两张boss上的图： 首先，大数据开发通常指的是基于大数据产业链的一系列开发任务，涉及到大数据平台开发、大数据应用开发、大数据分析等，另外还包括数据采集产品的开发、数据整理产品的开发等等，如果向上延伸的话，部分大数据开发任务与人工智能开发任务也具有密切的联系。 大数据平台开发通常有两层含义，一层是进行大数据平台自身的开发，这属于研发级开发任务，比如大数据平台Hadoop就是采用Java语言开发的。整个大数据平台还涉及到一系列产品，包括HBase、Hive、Avro、Zookeeper、Pig、Mahout、Cassandra等，开发这些产品也需要一个庞大的团队。进行大数据平台研发的程序员往往需要具备丰富的开发经验，同时具备较强的研发能力，能够搭建出一个稳定的分布式计算体系。 另一层含义是在大数据平台下进行应用开发，比如在Hadoop、Spark平台下进行具体的大数据应用开发等，这部分开发通常属于应用级开发，难度要相对小一些，但是往往需要与具体的场景进行紧密的联系，需要开发者具备一定的行业背景知识。 目前大数据应用开发主要的任务有两个，其一是进行已有软件产品的大数据改造

某厂面试归来，发现自己落伍了！>>> 互联网发展到现在，由于数据量大、操作并发高等问题，大部分网站项目都采用分布式的架构。 而分布式系统最大的特点数据分散，在不同网络节点在某些时刻（数据未同步完，数据丢失），数据会不一致。 在2000年，Eric Brewer教授在PODC的研讨会上提出了一个猜想：一致性、可用性和分区容错性三者无法在分布式系统中被同时满足，并且最多只能满足其中两个！ 在2002年，Lynch证明其猜想，上升为定理。被这就是大家所认知的CAP定理。 CAP是所有分布式数据库的设计标准。例如Zookeeper、Redis、HBase等的设计都是基于CAP理论的。 CAP定义 所谓的CAP就是分布式系统的三个特性： Consistency，一致性。所有分布式节点的数据是否一致。 Availability，可用性。在部分节点有问题的情况（数据不一致、节点故障）下，是否能继续响应服务（可用）。 Partition tolerance，分区容错性。允许在节点（分区）数据不一致的情况。 深入理解 有A、B、C三个分布式数据库。 当A、B、C的数据是完全相同，那么就符合定理中的Consistency（一致性）。 假如A的数据与B的数据不相同，但是整体的服务（包含A、B、C的整体）没有宕机，依然可以对外系统服务，那么就符合定理中的Availability（可用性）。

一. Hbase 的 region 我们先简单介绍下 Hbase 的 架构和 region ： 从物理集群的角度看，Hbase 集群中，由一个 Hmaster 管理多个 HRegionServer，其中每个 HRegionServer 都对应一台物理机器，一台 HRegionServer 服务器上又可以有多个 Hregion（以下简称 region）。要读取一个数据的时候，首先要先找到存放这个数据的 region。而 Spark 在读取 Hbase 的时候，读取的 Rdd 会根据 Hbase 的 region 数量划分 stage。所以当 region 存储设置得比较大导致 region 比较少，而 spark 的 cpu core 又比较多的时候，就会出现无法充分利用 spark 集群所有 cpu core 的情况。 我们再从逻辑表结构的角度看看 Hbase 表和 region 的关系。 　　Hbase是通过把数据分配到一定数量的region来达到负载均衡的。一个table会被分配到一个或多个region中，这些region会被分配到一个或者多个regionServer中。在自动split策略中，当一个region达到一定的大小就会自动split成两个region。 　　Region由一个或者多个Store组成，每个store保存一个columns family

先给结论吧： HBase利用compaction机制，通过大量的读延迟毛刺和一定的写阻塞，来换取整体上的读取延迟的平稳。 1.为什么要compaction 在上一篇 HBase读写 中我们提到了，HBase在读取过程中，会创建多个scanner去抓去数据。 其中，会创建多个storefilescanner去load HFile中的指定data block。所以，我们很容易就想到，如果说HFile太多的话，那么就会涉及到很多磁盘IO，这个就是常说的“读放大”现象。 因此，就有了今天的主题，HBase的核心特性——compaction。 通过执行compaction，可以使得HFile的数量基本稳定，使得IO seek次数稳定，然后每次的查询rt才能稳定在一定范围内。 2.compaction的分类 compaction分为两种，minor compaction和major compaction。 Minor compaction主要是将一些相邻的小文件合并为大文件，这个过程仅仅做文件的合并，并不会删除deleted type的数据和ttl过期的数据。 Major compaction是指将一个HStore下的所有文件合并为一个HFile，这个过程会消耗大量系统资源，一般线上会关闭自动定期major compaction的功能（将参数hbase.hregion