单纯从技术的角度来说其实没有好坏之分，技术选型需要结合实际的业务场景来定。从问题描述上看大致可以从几个方面来考虑：
1）数据量
每天5G数据量，按存储1年的数据来考虑，大概是1.8T，es和hbase都能支持，并且两者都可以通过扩展集群来加大可存储的数据量。随着数据量的增加，es的读写性能会有所下降，从存储原始数据的角度来看，hbase要优于es
2）数据更新
es数据更新是对文档进行更新，需要先将es中的数据取出，设置更新字段后再写入es。hbase是列存储的，可以方便地更新任意字段的值。
3）查询复杂度
hbase支持简单的行、列或范围查询，若没有对查询字段做二级索引的话会引发扫全表操作，性能较差。而ES提供了丰富的查询语法，支持对多种类型的精确匹配、模糊匹配、范围查询、聚合等操作，ES对字段做了反向索引，即使在亿级数据量下还可以达到秒级的查询响应速度。
4）字段扩展性
hbase和es都对非结构化数据存储提供了良好的支持。es可以通过动态字段方便地对字段进行扩展，而hbase本身就是基于列存储的，可以很方便地添加qualifier来实现字段的扩展
从基本功能来说这两个确实有相似性，但是根据业务需求不同，我觉得有几点可以考虑：
1. 查询复杂度：HBase支持简单的行或者range查询，比如给一个PK查该行的数据，或者给一个begin/end查这个范围的数据，如果想完成更复杂的功能就不太容易。而ES支持的查询比较丰富，或者说这些查询都带有一点复杂计算的味道了。比如你有个论坛，你想查帖子里面是否包含敏感词，如果采用HBase就比较麻烦，使用HBase你可以将帖子存进来、读出去，但是要查内容里面的东西，只能一点点过滤；而ES是可以比较方便的帮助你完成这个功能的；
2. 数据量：按道理说两者都是支持海量数据的，但是据我个人感觉，HBase可能更容易支持更多的数据，因为其一开始设计就是解决海量问题的；而ES是后来慢慢增强其存储扩展性的；那么也就是说，HBase上手起来扩展性不太会阻碍你使用；ES可能要多费点劲。当然，听说也有人写了ES基于Azure或者S3的存储插件，但是稳定性不知道如何；
3. 剩下的就是比较远的考虑，比如维护性，HBase基于Hadoop那一套，组件多，维护起来代价也不低，而ES自成体系，维护起来稍微好点；当然这个是相对的，绝对来说都不会容易。比如新功能开发，比如成本控制等等。。。