我正在考虑使用HBase存储日志（Web日志数据），每个日志将有大约20个不同的值（比如列），我想运行基于这些列过滤结果的查询。
我最初的想法是在每列下多次保存每个日志（单元格），这是日志中每个字段的值。这将导致数据大小增加约20倍，但我认为这可以提高性能。行键是带有前缀的时间戳，即源ID 每个源将产生大约40-100M的日志行（可能有数万个源） 我还需要低延迟，可能低于10秒（因此目前不能选择像Hive这样的解决方案）
您认为这是正确的架构设计吗？如果不是你认为什么是正确的，或者我应该使用别的东西（什么）？ 谢谢你的所有答案。
答案 0 :(得分：3)
我们正在做类似于博客的事情。我们做的事情比您提出的案件稍微复杂一点，但我可以看到可能遇到的问题的相似之处。
我们在hive中创建了表来存储我们正在收集的各种数据然后有一个工作来运行查询并将这些数据加载到预先聚合的HBase中的表中。
这有助于降低数据增加和复制的级别，因为原始数据只存储一次，然后存储所需的聚合。使用Hive存储原始数据可以更灵活地通过不同维度和各种数据操作进行聚合。
根据您的具体目标，HBase可能是存储的唯一要求，但如果目标是聚合和分析数据，我认为Hive和HBase可以更好地协同工作。
如果您的结果不需要“实时”，那么仅使用配置单元存储原始数据并从查询生成报告也可能是一种可接受的解决方案。
我绝不是HStack设置的权威资源。我甚至不是现有系统设计的关键成员。我遇到过一种情况，我们无法在hbase中存储数据并检索它，同时保持hbase的最佳设置/组织。我们需要存储数据来检索它的方法会在其他方面引起很多麻烦。
我希望我的ramblings能以某种方式提供一些帮助。 ：）