东境物语

数据分布问题简述分布式产生的根源是“规模”，规模可理解为计算和存储的需求。当单机能力无法承载日益增长的计算存储需求时，就要寻求对系统的扩展方法。通常有两种扩展方式：提升单机能力(scale up)，增加机器(scale out，水平扩展)。限于硬件技术，单机能力的提升在一个阶段内是有上限的；而水平扩展在理论上可以是无限的，同时，也更廉价、更容易落地。水平扩展可以通过快速、简单的“加机器”，有效解决业务快速增长的问题，这几乎是现代分布式系统必备的能力。对于爆发式增长的业务，水平扩展似乎是唯一可选择的方案。

说明：从严格的列式存储的定义来看，Hbase并不属于列式存储，有人称它为面向列的存储，请各位看官注意这一点。行式存储传统的数据库是关系型的，且是按行来存储的。如下图：其中只有张三把一行数据填满了，李四王五赵六的行都没有填满。因为这里的行结构是固定的，每一行都一样，即使你不用，也必须空到那里，而不能没有。来一张形象的图：不管你坐或不坐，座位都在那里，不离不弃。列式存储为了与传统的区别，新型数据库叫做非关系型数据库，是按列来存储的。如下图：初次看列式存储稍微有点懵，下面给

1、第一种设计rowkey方式：随机数+messageId，如果想让最近的数据快速get到，可以将时间戳加上，我这里的region是0001|到0009|开头的，因为hbase的数据是字典序排序的，所以如果我生成的 rowkey=0002rer4343343422,则当前这条数据就会保存到0001|~0002|这个region里，因为我的messageId都是字母+数字，“|”的ASCII值大于字母、数字。2、创建表时没有提前预分区，创建的表默认只有一个region，大量的数据写入当前region；

由于HBase这样的删除和更新机制，如果后面没有一个对于过期数据处理的机制，会导致过期数据越来越大，因此后面的compact操作中的major compact就顺便将过期的数据删除掉了。当对数据进行修改，修改的数据会将当前的数据覆盖，由hbase在写入数据时自动赋予修改数据后的时间戳，每个 Cell 中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。保证每次获取的数据时最新修改后的数据。新的数据的timestamp会大于老的数据，这样读取的时候，判断时间戳就可以取出最新的数据了。

Memstore是HBase框架中非常重要的组成部分之一，是HBase能够实现高性能随机读写至关重要的一环。深入理解Memstore的工作原理、运行机制以及相关配置，对hbase集群管理、性能调优都有着非常重要的帮助。Memstore 概述HBase中，Region是集群节点上最小的数据服务单元，用户数据表由一个或多个Region组成。在Region中每个ColumnFamily的数据组成一个Store。每个Store由一个Memstore和多个HFile组成，如下图所示：之前我们提到，HB

访问hbase table中的行，rowkey 可以是任意字符串(最大长度 是 64KB，实际应用中长度一般为 10-100bytes)，在hbase内部，rowkey保存为字节数组，存储时，数据按照rowkey的字典序排序存储。（预分区个数=节点的倍数，看数据量估算，region不足了会被分列，预分区后每个region的rowkey还是有序的）1、hbase的中的数据是按照字典序排序的，当大量连续的rowkey集中写在个别的region，各个region之间数据分布不均衡；

HBase 存在热点问题。热点问题首选解决方法是 Rowkey 的散列与预分区设计Rowkey 散列可以参看HBase Rowkey 设计指南。

单单一张 HBase 数据表只能根据 Rowkey 来查询。多维度查询下是不够用的，可以尝试二级索引。Phoenix、Solr 以及 ElasticSearch 都可以用于构建二级索引。

本篇总结记录了在防止hbase产生热点问题时的解决方案，主要从两个方面进行分析，一设计合理的rowkey，将数据集进行合理的散列。二设计合理的预分区，将散列后的数据集均匀的插入到region中，以防止hbase产生数据倾斜等热点问题。后续遇到更好的设计方案再及时更新。

Table可以直接理解为表，而Family和Qualifier其实都可以理解为列，一个Family下面可以有多个Qualifier，所以可以简单的理解为，HBase中的列是二级列，也就是说Family是第一级列，Qualifier是第二级列。而从好的方面来说，更少的split会让系统提供更加稳定的在线服务。family越多，那么获取每一个cell数据的优势越明显，因为io和网络都减少了，而如果只有一个family，那么每一次读都会读取当前rowkey的所有数据，网络和io上会有一些损失。

列族不宜过多，将相关性很强的 key-value 都放在同一个列族下；尽量最小化行键和列族的大小；提前预估数据量，再根据 RowKey 规则，提前规划好 Region 分区，在创建表的时候进行预分区；在业务上没有特别要求的情况下，只使用一个版本，即最大版本和最小版本一样，均为1；根据业务需求合理设置好失效时间（存储的时间越短越好）；根据查询条件，设置合理的BloomFilter配置。【HBase】HBase 列族属性配置 - 简书。

徐春明——腾讯金融与支付数据库平台组负责人，在数据库行业有超过10年的工作经验，擅长MySQL数据库运维、内核开发。近期深入研究HBase相关技术，负责HBase技术在腾讯支付场景的落地。摘要：本次分享讲述的是关系型数据库在腾讯金融支付场景下遇到的挑战，选择HBase背后的主要原因以及我们是如何打造高性能、高可靠、高可用的HBase数据中心。最后是关于HBase在互联网金融业务方面遇到的挑战和解决之道。分享大纲：1、关系数据库挑战—扩展性、可维护性、易用性2、如何打造HBase中心—高.

hbase的rowkey设计决定了数据的分区和查询的方式，是使用hbase前一定要想清楚的，以下简单列举了设计hbase rowkey时需要考虑的问题1. rowkey是唯一的吗？rowkey相同的记录在hbase里被认为是同一条数据的多个版本，查询时默认返回最新版本的数据，所以通常rowkey都需要保证唯一，除非用到多版本特性最佳设计实践：rowkey就好比数据库的里的主键，他唯...

一、宽表和高表定义HBase 中的表可以设计为高表（tall-narrow table） 和 宽表（flat-wide table）：宽表是指很多列较少行，即列多行少的表，一行中的数据量较大，行数少； 高表是指很多行较少列，即行多列少，一行中的数据量较少，行数大。二、宽表和高表的优劣HBase的键分为两种：列键：包括了列族名和限定符，定位到列的索引 行健：相当于关系型数据库中...

Hbase 概述大数据及 NoSQL 的前世今生传统的关系型数据库处理方式是基于全面的 ACID 保证，遵循 SQL92 的标准表设计模式（范式）和数据类型，基于 SQL 语言的 DML 数据交互方式。长期以来这种基于关系型数据库的 IT 信息化建设中发展良好，但受制于关系型数据库提供的数据模型，对于逐渐出现的，为预先定义模型的数据集，关系型数据库不能很好的工作。越来越多的业务系统需要能够...

背景对接业务类型HBase是建立在Hadoop生态之上的Database，源生对离线任务支持友好，又因为LSM树是一个优秀的高吞吐数据库结构，所以同时也对接了很多线上业务。在线业务对访问延迟敏感，并且访问趋向于随机，如订单、客服轨迹查询。离线业务通常是数仓的定时大批量处理任务，对一段时间内的数据进行处理并产出结果，对任务完成的时间要求不是非常敏感，并且处理逻辑复杂，如天级别报表、安全和用户...