在大量客户端请求访问数据或者写入数据的时候，只有少数几个或者一个 RegionServer 做出响应，导致该服务器的负载过高，造成读写效率低下，而此时其他的服务器还是处于空闲的状态，就是所谓“旱的旱死，涝的涝死”。那么为什么会造成这种情况，主要的原因就是数据分布不均匀，可能是数据量分布不均匀，也可能是冷热数据分布不均匀。而糟糕的 RowKey 设计就是发生热点即数据倾斜的源头，所以这里会详细说说HBase如何处理热点数据问题。

HBase 的参数很多，一般都是在使用和优化的过程中不断地调整的，这里只列举出比较重要和常用的几个HBase参数优化方案，大家可以参考一下。

1. 协处理器coprocessor方案。 原理就是自定义协处理器，实现`双写`,就是写主表的时候，同时写索引表[这里这个索引表是根据业务对查询的需求建立的]。 比如我们要查询的主表是A, 里面有RowKey，还有一列ColumnA. 如果想对ColumnA这一列建立索引，就自定义一个协处理器(观察者模式),当我们写入A表中一条数据，比如 行键rowkey(123)，cloumnA列值：abc，这时协处理在索引表(自己建立，比如A_INDEX)中插入一条记录 行键为刚才列A的值abc，列值为主表的rowk

对于Flink，Spark在Yarn上提交的LongTime Job(比如一个批处理作业要运行几个小时或者本身就是实时作业)，其作业的运行日志我们不能等到作业结束后，通过Yarn日志聚合后查看，我们希望作业提交后就能够马上看到运行日志(这里注意，你的作业被调度到集群的各个计算节点中，比如你的集群有100个节点，你的作业可能被调度到几十个个节点中)，如何能够实时方面的查看所有节点产生的日志呢？

Spark Streaming消费Kafka，对于offset的管理方式一般有如下方式：1. checkpoint 方式管理，通过checkpoint可以将消费的offset持久化存储到hdfs，失败后作业可以从checkpoint恢复。 但是这里的主要问题是，如果你的程序作了升级，比如业务逻辑变更了，你修改了代码，这时是无法从之前的checkpoint恢复的。因为checkpoint第一次持久化的时候会把整个相关的jar给序列化成一个二进制文件，每次重启都会从里面恢复，换句话说不支持应用升级。