01：课程回顾

BulkLoad
- 功能：将数据直接转换成HFile文件，直接放入表中，不经过内存
- 场景：短时间内大量数据写入Hbase表，离线应用中
- 流程：a-将数据生成HFILE文件【HfileOutputFormat2】 b-将HFile加载到表中
SQL on Hbase
- 问题：a-Hbase不支持SQL，使用成本比较高，b-不知道Rowkey前缀，无法实现索引查询
- 需求：a-实现SQL on Hbase，b-构建二级索引
- Hive on Hbase
  - 设计：使用Hbase来替代Hive表底层存储
  - 本质：构建了一层映射关系，通过Hadoop中读写Hbase类来实现
  - 优点：底层有计算引擎，SQL比较完善，实现对Hbase大数据量分析处理
  - 缺点：不适合做即席查询，不支持构建二级索引
  - 场景：离线场景中，利用Hbase提高数仓读写性能，实现分布式数据分析处理，或者使用SQL处理半结构化数据
- Phoenix on Hbase
  - 设计：为了解决Hbase在使用过程中遇到的两个问题，专门为Hbase设计的工具
  - 本质：底层直接基于Hbase原生API来构建，并且封装了大量的协处理器
  - 优点：查询性能相对较快，数据存储读写功能比较强大，例如二级索引
  - 缺点：SQL语法不是很完善，没有分布式计算引擎，不能实现非常复杂转换处理
  - 场景：即席查询

Znyoung大约 36 分钟

分布式面向列的NoSQL数据库Hbase(四)

01：课程回顾

Hbase Java API
- 掌握基本流程：先构建Connection[ZK]、DDL【HbaseAdmin】、DML【Table】
- 掌握核心类：Put、Get、Delete、Scan、ResultScanner、Result、Cell
Hbase 存储结构
- 概念
  - Table：逻辑上操作对象，Table是分布式的概念，用于客户端读写数据对象
  - Region：物理上存储数据对象，Region代表每个分区，默认每张表只有1个Region，每个Region存储在不RS
  - RegionServer：Hbase从节点进程，负责管理表的Region，接受所有Region的读写请求
- Hbase分布式的划分规则
  - 基本原则：表的每一个分区都有一个范围，所有分区的范围合并在一起一定是-oo ~ +oo
  - 分区规则：按照Rowkey属于哪个Region的范围，就读写哪个Region
  - 设计目的：构建表中数据的全局有序，加快读取的性能
  - Hbase基于HDFS查询性能慢的问题，怎么解决？
    - Rowkey：作为索引、Rowkey有序
    - 列族的设计
    - 积极使用内存：优先读Memstore、允许构建读缓存BlockCache
    - 写入HDFS的文件是二进制的HFILE文件
- 读写流程
  - 写：先追加写WAL【Hlog】、写入内存【只做新增，逻辑上更新和删除】
    - Flush：将内存中的数据写入HDFS
    - Compaction：将多个文件合并为整体有序大文件，清理无用数据
    - Split：一个分区的数据过多，读写性能降低，通过Split提高并行度
  - 读：先读Memstore【写缓存】，再读BlockCache【读缓存】，最后读StoreFile
  - 元数据检索流程：管理元数据【Zookeeper】、表的元数据【hbase:meta】
- 存储结构
  - Table | RegionServer
    - |
    - Region：表的分区
      - |
      - Store：按照列族划分
        
        |
        
        Memstore：内存区域
        
        StoreFile：逻辑上属于Store，物理上存储在HDFS中的HFILE文件
- 热点问题
  - 现象：存储不均衡，导致了读写都集中在某个Region上，其他Region相对来说比较空闲
  - 原因：1-没有预分区，2-分区范围没有按照Rowkey设计， 3-rowkey是连续的
  - 解决：1-建表的时候按照rowkey构建预分区，2-设计不连续的rowkey
- Hbase表的设计
  - rowkey：业务原则、唯一原则、组合原则、散列原则【加盐】、长度原则
  - columnfamily：个数原则【按照列的个数来设计】、长度原则

Znyoung大约 8 分钟

分布式面向列的NoSQL数据库Hbase(三)

01：课程回顾

Hbase集群管理
- 启动：start-dfs.sh / start-zk.sh / start-hbase.sh
- 监控：HMaster：16010
- 关闭：stop-hbase.sh / stop-zk.sh / stop-dfs.sh
Hbase Shell命令行
- DDL：list_namespace、create_namespace、drop_namespace、list、create ‘ns:tbname’, 列族、drop、desc
- DML：put
  - put使用
  - 功能：为表中的某一行添加某一列，如果存在就更新，不存在就插入
  - 语法：put ns:tbname, rowkey, cf:col , value

Znyoung大约 34 分钟

分布式面向列的NoSQL数据库Hbase(二)

01：课程回顾

Hbase中核心概念
- Rowkey：行健，类似于主键
  - 区别：Hbase中每一张表都有主键这一列，建表的时候自带这一列
  - 功能：1-每个Rowkey唯一决定一行【插入更新】，2-作为Hbase表中的唯一索引
  - 内容：由开发者自己决定
- ColumnFamily：列族，对列的分组，将列划分到不同的列族
  - 规则：建表的时候会指定表中有几个列族，Hbase表中除Rowkey任何一列都必须属于某个列族
  - 存储：相同列族的数据都放在相同的物理区域
  - 设计：将列进行分组后，查询时可以指定读取某个列族的列，加快查询性能
  - 思想：牺牲一定写的性能，来换取更高查询性能
- Qualifier：列标签，等同于列的概念
  - 规则：任何一列都必须属于某个列族，访问时候，使用列族名称：列名
  - 特殊：Hbase中每一个Rowkey可以拥有不同的列
- VERSIONS：多版本，某一个rowkey的某一列允许存储多个版本的值
  - 规则：列族属性，默认情况下每个列族下的列只允许存储1个版本
  - 实现：查询时默认只显示最新版本
  - 区分：每一列的数据在写入时都会自带一个时间戳，使用时间戳来区分不同版本
- 底层存储：面向列的存储
  - 每个Rowkey只是代表Hbase中逻辑上一行，每个Rowkey在物理层会对应多个KV
  - Rowkey的每一列只是代表Hbase逻辑上列，每一列在物理层会对应一个KV
  - K：rowkey+cf+col+ts
  - V：value
  - 对数据构建有序：每个KV按照rowkey、cf、col升序排序，按照ts降序排序【字典排序】
Hbase的分布式架构和部署
- 架构角色：普通分布式主从架构
  - HMaster：主：管理节点：管理从节点，管理元数据，分区
  - HRegionServer：从：存储节点：负责存储表的Region，接收所有对Region读写请求，提供分布式内存
- 架构组成
  - Hbase：负责对外提供读写请求，提供分布式内存读写
  - HDFS：负责提供Hbase底层持久化存储，提供分布式磁盘读写
  - Zookeeper：1-负责辅助选举Active HMaster，2-存储Hbase的管理元数据

Znyoung大约 7 分钟

分布式面向列的NoSQL数据库Hbase(一)

资料

01：课程回顾

Kafka收尾

Kafka为什么基于磁盘的日志消息队列系统，但是读写速度很快？
- 写：先写内存PageCache，然后顺序写入磁盘【追加】
- 读：先读内存PageCache，Segment对分区数据进行划分，通过稀疏索引来加快查询，通过0拷贝机制来读取
Kafka中如何保证一次性语义？
- 一次性语义：至多一次，至少一次，有且仅有一次
- 生产不丢失：ack 应答机制 + retries 重试机制
- 生产不重复：实现生产幂等性保证：生产id + 数据id ，事务机制【操作放入一个Topic中】
- 消费不丢失不重复：手动管理commit offset：文件、MySQL、Zookeeper、Redis
Kafka中一些概念：AR、ISR、OSR、HW、LEO？
- AR：一个分区的所有副本
- ISR：正在同步的副本，可用副本，写入数据以及选举Leader都是从ISR中选择
- OSR：没有同步的副本，不可用副本，超过一定的时间没有和Leader通信
- LEO：分区的每个副本当前已经写入的位置+1，下一个待写的位置
- HW：消费的高水位线，指的是消费者消费这个分区能够消费到的位置+1，等于这个分区所有副本最小LEO

Znyoung大约 12 分钟

分布式消息队列系统Kafka、Hbase

01：课程回顾

02：课程目标

【模块一：消费分配策略】

03：【掌握】基本规则及分配策略

目标：掌握Kafka消费者组中多个消费者的分配规则
实施
- 问题
  - 1-多个topic多个分区，一个消费者组有多个消费者，Kafka是怎么自动分配保证负载均衡？
    - 消费者组：CG1=>多个消费者：C1、C2、C3
    - 订阅多个Topic：Topic1 Topic2 Topic3 =>每个Topic都有多个分区
  - 2-如果有一个消费者C1故障，超过一定时间没有恢复，这个消费者A原来负责的分区怎么分摊给别的消费者？
    - C1故障以后，C1负责的分区，怎么重新分配效率更高？
- 基本规则
  - 一个分区的数据只能由这个消费者组中的某一个消费者消费
  - 一个消费者可以消费多个分区的数据
- 分配策略：决定了多个分区如何分配给多个消费者
  - 属性：partition.assignment.strategy = org.apache.kafka.clients.consumer.RangeAssignor
  - RangeAssignor：范围分配，默认的分配策略
  - RoundRobinAssignor：轮询分配，常见于Kafka2.0之前的版本

Znyoung大约 29 分钟