二者的对比大致如下：

ES和Hbase的写入都是基于LSM树结构，写入性能应该是相当的，不过ES在写入时需要做更多的事情（比如分词构建倒排索引，构建DocValues，进行字段类型的校验，且主副本都需构建索引等），所以ES消耗的CPU是比较高的，但如果只是满足Hbase相关的查询场景，有些东西也是可以通过配置省去的。
在查询场景中，ES能同时支持全文检索和时序检索场景，可以支持丰富的查询需求，并且都是ES本身具备的能力。相对来说，Hbase的scan查询就要弱不少，不过开源生态中有OpenTSDB，SparkSQL，Phoenix，Hive等组件，可以用来丰富Hbase的查询能力（其中OpenTSDB和Phoenix是基于Hbase来构建的，SparkSQL和Hive是基于Hdfs来构建的）。但是，在全文检索这块还是缺失的，所以阿里云上的Hbase通过借助Solr来弥补这块的能力。
在数据的负载均衡这块，ES相对比较简单，很多时候都需要业务方进行索引的滚动、分裂等操作来实现集群的负载均衡。而Hbase提供的StochasticLoadBalancer策略（会综合考虑Region负载、读写请求数、移动代价等因素），更加符合实际的需求。
对于集群的稳定性，ES是计算和存储合一的设计，Hbase则是计算和存储分离的设计，Hbase负责计算部分，存储则交给其依赖的Hdfs来保障。相对来说，计算和存储分离的设计，在海量数据的场景中，稳定性和成本控制是更有优势的。现在很多大公司在使用ES的时候，都采用类似Hbase的做法，将计算和存储分离开，底层存储则利用公司内部提供的分布式文件系统。
对于内存管理这块，ES以前的版本内存管理成本是很高的，1TB左右的数据存储，大约会消耗2G左右的堆内存，这样一台机器存储的数据量就很有限，直到2020年的7.3版本中，才开始将一些数据放到堆外，但是目前采用的LRU内存淘汰策略还是比较简单的，腾讯云的增强版ES在off-heap堆外内存的管理这块进行了优化，提供了更加精细化的管理。Hbase在内存管理这块，相对是比较成熟的，它提供了几种缓存管理策略供用户选择，在实际实现中，一般将BucketCache和LRUBlockCache搭配使用，称为CombinedBlock-Cache。
------------------------------------------------