1. hbase架构
hbase架构如上，从部署维度考虑，其架构特性如下：
- 计算(hbase)、存储(hdfs)分离，且均为高可用架构
- 自动服务发现机制
- 链路长，关联组件多
- 平行拓展，性能要求高
2. hbase 组件
- zookeeper：zk负责hbase服务注册发现，以及hbase master管理数据存放，有独立的存储盘
- hbase：核心功能组件，分为master 和 regionserver
- master： 控制中心，主要负责数据调度管控，及regionserver的分区管理，可以多副本，主备关系，无选举
- regionserver：存储管理节点，支持数据读写，多副本，多副本共同形成类似于RAID-0存储结构，但因分区信息由master存放在zk上做管理，所以挂掉部分也对业务影响不大，不会导致整套服务无法读写
- hadoop：作为存储池，提供hdfs分布式存储能力，分为namenode 和 datanode
- namenode：
- datanode：
3. helm部署
3.1 部署
#chart包位置：https://artifacthub.io/packages/helm/gradiant/hbase
helm repo add gradiant https://gradiant.github.io/charts/
#部署hbase 的chart包版本0.1.6，对应hbase版本(2.0.1），zk（3.6.2），hadoop（2.7.7）
helm install my-hbase gradiant/hbase --version 0.1.6
3.2 版本定制
若上述hbase版本不符合使用需求，可以将上述chart包拉取到本地，定制参考：https://blog.csdn.net/weixin_34281537/article/details/89621989
4. 趟坑
4.1 snappy压缩算法不支持
描述： 因上述hbase底层存储用的hadoop(2.7.7)版本偏低，默认不支持snappy（hadoop2.8之后默认支持），业务方使用会产生很多失败region，并且RIT会很高，通过hbase hbck会有不一致问题
解决：定制(hadoop、hbase)镜像，具体如下：
- 制作hadoop镜像：将hadoop镜像拉到本地，定制Dockerfile，在hadoop镜像中安装snappy的库，并将snappy库及其软链放到/opt/hadoop-2.7.7/lib/native/目录下，制作镜像，并上传到私有仓库
- 制作hbase镜像：将hbase镜像拉到本地，定制Dockerfile，在hadoop镜像中安装snappy的库，并将上述/opt/hadoop-2.7.7/lib/native/目录下的库复制一份，放到/opt/hbase/lib/native/Linux-amd64-64下，若该目录不存在，则创建
- 制作hbase镜像：找到与上面安装snappy库版本一致的jar包（地址：https://mvnrepository.com/artifact/org.xerial.snappy/snappy-java）并下载，然后将该jar包放在/opt/hbase/lib/目录下，制作镜像，并上传到私有仓库
- 制作chart包：将hbase的chart 包拉取到本地，修改依赖的hadoop chart中使用的镜像，修改hbase自己使用的镜像
4.2 regionserver host不一致
描述：hbase 依赖于hostname，regionserver配置了多个service，导致coredns对host命令解析出来的结果会有多条，默认安装时部署了一个headless service，因业务需求在集群外访问regionserver，要regionserver IP 固定，因网络组件还不支持固定IP，故对每个regionserver配置了一个service，导致每个regionserver可以被解析出几个不同的结果
解决：解决方式两种：
- pod固定IP：最佳方式，可以把headless删除，只单独对每个regionserver配置一个service（可能有同学会疑问，不固定IP也可以这么搞，可以，但解决不了问题，host解析出来的结果会带上pod IP，如果pod重建，不光IP会变，host结果也会变）
- 取舍：只配置一个service，不单独为每个regionserver配置service，解除hbase 一致性隐患，优先保持功能，使用体验降级
4.3 初始化失败
描述： zk地址、hdfs地址访问不通
解决： 因zk、hdfs的地址均是动态生成，变量配置转换不合理，在chart包部署时替换成相应组件service name可以解决
4.4 性能不够
描述： cpu、mem、pv、hbase Xms Xmx等涉及到性能的参数，部署时未作评估调优
解决：优化chart包，做成定制化，提前做好评估部署，以免部署完使用了一段时间后，出现问题再调整
4.5 hbase和hadoop依赖同样的native库路径
描述： hbase 启动需要加载hadoop及相关压缩算法库，和hadoop有部分同样的依赖，在cloudera-manager部署模式下，可能hbase和hadoop部署在一台机器下，依赖建一个软链接即可，但k8s部署下是两套不同的镜像，导致依赖找不到，启动失败或运行中报错
解决： 将cm模式下相互依赖的包、库等，在hbase、hadoop都创建对应路径，并存放同样的文件，如：hbase的目录/opt/hbase/lib/native/Linux-amd64-64/和 hadoop的目录/opt/hadoop-2.7.7/lib/native/，可以尽量存放同样的库文件及软链
