單純從技術的角度來說其實沒有好壞之分，技術選型需要結合實際的業務場景來定。從問題描述上看大致可以從幾個方面來考慮：
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自成體系，維護起來稍微好點；當然這個是相對的，絕對來說都不會容易。比如新功能開發，比如成本控制等等。。。