大数据框架复习-hbase+sqoop_sqoop hbase切分rowkey

大数据框架复习-hbase+sqoop

hbase的架构

• 

  • HFile：磁盘上保存原始数据的实际的物理文件；
  • Store：HFile存储在Store中，一个Store对应HBase表的一个列族；
  • Region：Hbase表的分片，根据rowkey值被切分为不同的region存储在regionServer，在一个 RegionServer 中可以有多个不同的 region。
  • Client：维护护着一些 cache 来加快对 hbase 的访问， 比如 region的位置信息
  • zookeeper：hbase有内置的zk，但为了保持统一性还是外置，作用
    • 保证任何时候，集群中只有一个master；
    • 存储所有region的xunzhirukou
    • 监控regionserver的状态，将regionserver的上线和下线信息实时通知给master
  • Hmaster
    • 为 Region server 分配region
    • . 负责 region server的负载均衡
  • HRegion 虽然是负载均衡的最小单元，但并不是物理存储的最小单元。

• client—HRegionServer—Hregion—

• hbase是建立在hdfs之上的，提供高可靠性、 高性能、列存储、可伸缩、实时读写 NoSql 的数据库系；Region Server 和 HDFS DataNode 往往是分布在一起的

• 仅能通过主键(row key)和主键的 range 来检索数据，仅支持单行事务(可通过 hive 支持来实现多表join等复杂操作）

• Hbase 查询数据功能很简单，不支持 join 等复杂操作，不支持复杂的事务（行级的事务） Hbase 中支持的数据类型：byte[] 与 hadoop 一样，Hbase 目标主 要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力。

• 特点：

  • 大：一个表可以有十亿行，上百万列
  • 面向列：面向列的存储和权限控制，列独立检索；
  • 稀疏：对于为空(null)的列，并不占用存储空间，因此，表可以设计的非常稀疏

habse与hdfs的关系

• hdfs
  • 为分布式存储提供文件系统
  • 针对存储大尺寸的文件进行优化，不需要对 HDFS 上的文件进行随机读写
  • 直接使用文件
  • 数据模型不灵活
  • 使用文件系统和处理框架
  • 优化一次写入，多次读取的方式
• hbase
  • 提供表状的面向列的数据存储
  • 针对表状数据的随机读写进行优化
  • 使用 key-value 操作数据
  • 提供灵活的数据模型
  • 使用表状存储，支持 MapReduce，依赖hdfs
  • 优化了多次读，以及多次写

hbase是怎么写数据的

• Client写入 -> 存入MemStore，一直到MemStore满 -> Flush成一个StoreFile， 直至增长到一定阈值 -> 触发Compact合并操作 -> 多个StoreFile合并成一个 StoreFile，同时进行版本合并和数据删除 -> 当 StoreFiles Compact 后，逐步形成越来越大的 StoreFile -> 单个 StoreFile 大小超过一定阈值后（默认 10G）， 触发 Split 操作，把当前 Region Split 成 2 个 Region，Region 会下线，新 Split 出的 2 个孩子 Region 会被 HMaster 分配到相应的 HRegionServer 上，使得原先 1 个 Region 的压力得以分流到 2 个 Region 上
• 由此过程可知，HBase 只是增加数据，没有更新和删除操作，用户的更新和删除 都是逻辑层面的，在物理层面，更新只是追加操作，删除只是标记操作。 用户写操作只需要进入到内存即可立即返回，从而保证 I/O 高性能。

hdfs和hbase各自使用场景

• 首先一点需要明白：Hbase 是基于 HDFS 来存储的。

HDFS：

1. 一次性写入，多次读取。
2. 保证数据的一致性。
3. 主要是可以部署在许多廉价机器中，通过多副本提高可靠性，提供了容错 和恢复机制

Hbase：

1. 瞬间写入量很大，数据库不好支撑或需要很高成本支撑的场景
2. 数据需要长久保存，且量会持久增长到比较大的场景。
3. HBase 不适用与有 join，多级索引，
4. 大数据量（100s TB 级数据）且有快速随机访问的需求。如：淘宝的交易历史记录。数据量巨大无容置疑，面向普通用户的请求必然要即时响应。kylin的数据就存储在hbase中；
5. 业务场景简单，不需要关系数据库中很多特性（例如交叉列、交叉表，事务，连接等等

hbase的存储结构

• Hbase 中的每张表都通过行键(rowkey)按照一定的范围被分割成多个子表 （HRegion），默认一个 HRegion 超过 256M 就要被分割成两个，由 HRegionServer管理，管理哪些 HRegion 由 Hmaster 分配。
• HRegion 存取一个子表时，会创建一个 HRegion 对象，然后对表的每个列族（Column Family）创建一个 store 实例， 每个 store 都会有 0 个或多个 StoreFile 与之对应，每个 StoreFile 都会对应一个 HFile，HFile 就是实际的存储文件，一个 HRegion 还拥有一个 MemStore 实例

hbase 的热点现象（数据倾斜）怎么产生？解决方法？

• 热点现象：某个小的时段内，对 HBase 的读写请求集中到极少数的 Region 上，导致这些 region 所在的 RegionServer 处理请求量骤增，负载量明显偏大，而其他的 RgionServer 明显空闲
• 原因：
  • HBase 中的行是按照 rowkey 的字典顺序排序的，这种设计优化了 scan 操作，可 以将相关的行以及会被一起读取的行存取在临近位置，便于 scan。然而糟糕的 rowkey 设计是热点的源头
  • 热点发生在大量的 client 直接访问集群的一个或极少数个节点（访问可能是读， 写或者其他操作）。大量访问会使热点 region 所在的单个机器超出自身承受能 力，引起性能下降甚至 region 不可用，这也会影响同一个 RegionServer 上的其 他 region，由于主机无法服务其他 region 的请求。
• 解决方法：
  • 加盐：在 rowkey 的前面增加随机数，使得它和之前的 rowkey 的开头不同。 分配的前缀种类数量应该和你想使用数据分散到不同的 region 的数量一 致。*加盐之后的 rowkey 就会根据随机生成的前缀分散到各个 region 上， 以避免热点
  • 哈希：哈希可以使负载分散到整个集群，但是读却是可以预测的。使用确定的哈希可以让客户端重构完整的 rowkey，可以使用 get 操作准确获取某一个行数据
  • 反转：第三种防止热点的方法时反转固定长度或者数字格式的 rowkey。 这样可以使得 rowkey 中经常改变的部分（最没有意义的部分）放在前面。但是牺牲了 rowkey的有序性，
  • 时间戳反转；
  • HBase 建表预分区：创建 HBase 表时，就预先根据可能的 RowKey 划分出多 个 region 而不是默认的一个，从而可以将后续的读写操作负载均衡到不 同的 region 上，避免热点现象。

hbase的rowkey设计原则

• 长度原则：100 字节以内，8 的倍数最好，可能的情况下越短越好。过长影响存储效率；
• 散列原则：高位散列，低位时间字段。避免热点问题。
• 唯一原则：充分利用这个排序的特点，将经常读取的数据存储到一块，将最近可能会被访问 的数据放到一块。

hbase的列簇设计原则

• 原则：在合理范围内能尽量少的减少列簇就尽量减少列簇，因为列簇是共享 region 的，每个列簇数据相差太大导致查询效率低下。

hbase的compact作用，什么时候触发，分为哪两种，区别？

• 在 hbase 中每当有 memstore 数据 flush 到磁盘之后，就形成一个 storefile， 当 storeFile 的数量达到一定程度后，就需要将 storefile 文件来进行 compaction 操作
• 作用：
  • 合并文件
  • 清除过期，多于版本的数据；
  • 提供读写效率；
• 两种compaction的方式：minor、major
  • Minor 操作只用来做部分文件的合并操作
  • Major 操作是对 Region 下的 HStore 下的所有 StoreFile 执行合并操 作，最终的结果 是整理合并出一个文件

sqoop的参数

• /opt/module/sqoop/bin/sqoop import \
  --connect \
  --username \
  --password \
  --target-dir \
  --delete-target-dir \
  --num-mappers \
  --fields-terminated-by   \
  --query   "$2" ' and $CONDITIONS;'
  1
  2
  3
  4
  5
  6
  7
  8
  9

Sqoop导入导出Null存储一致性问题

• Hive中的Null在底层是以“\N”来存储，而MySQL中的Null在底层就是Null，为了保证数据两端的一致性。
• 在导出数据(hdfs到mysql)时采用–input-null-string和–input-null-non-string两个参数。
• **导入数据（mysql到hdfs）**时采用–null-string和–null-non-string。

sqoop导出时数据一致性问题

• sqoop 底层运行的其实是map 任务，默认4个map。如果4个map中有两个map失败了，但是另外两个是成功的。这个时候导入进mysql中的数据是不正确的，重新再导一次全部任务都成功，这两次的数据会不一致。
• 为了保证导出的时候数据是一致的sqoop有两个参数配合使用
  • –staging-table mysql表名_tmp \
–clear-staging-table \
  • sqoop会先把数据导入进这张临时表中，所有任务都成功了。才会在mysql 中把临时表中的数据导入到真正的表中

sqoop底层运行的任务只有Map阶段，没有reduce阶段

• sqoop导出数据5min-2hour都有，比较慢，毕竟是mr任务；

部分资料来自五分钟学大数据、尚硅谷