免责声明：我是rdbms人员，最近负责优化大数据系统。因此，我下面的观点和想法可能是幼稚的，而不是“大数据”的性质。
问题：我有一个大数据（hive+hdfs）系统（目前约有1000万条记录，预计未来几年会增长——每年约2500万条记录），我们正试图在此基础上构建临时查询系统。我们的目标是提供一个搜索系统，它可以让客户提交具有多个过滤条件（where conditions）的查询，并且该系统可以支持数据获取，理想情况下是log n复杂度。我们正在寻找更多的搜索和过滤，而不是执行聚合函数。
我知道配置单元不适用于临时查询，而是用于批处理，但目前，我们不想替换配置单元。在我的研究中，我认为impala和drill是很好的候选者（如果我遗漏了什么，请纠正我），但是这两种方法似乎都是押注于并行查询执行，而不是内存缓存和索引，它们更像是hive的替代品，而不是对hive的补充。
我想到的解决方案是：考虑到我们知道数据并且可以预测将被频繁过滤的列，我在想，构建一个外部缓存系统，它由以下两个组件组成，将对这个案例有更大的帮助：
基于b-树/跳过列表的列索引，将过滤条件解析为ID列表(多列将有多个索引树）。多个过滤条件将需要经过一个交叉过程，这将导致最终的数据集。
一个基于hashtable/trie（更倾向于hashtable）的索引，它将帮助将标识符解析为相应的配置单元分区（或缓存键）。
理论上，使用上述两种方法，我们应该能够将给定的查询转换为logn中的标识符列表（优化搜索），然后通过只搜索那些感兴趣的分区来优化实际检索。一个简单的基于lru的缓存可以在“搜索系统”和实际Hive之间使用，以更快地检索数据。
问题：你能告诉我，如果你看到任何明显的问题，这和你能建议任何替代品？与这个想法相比， Impala /钻有明显的收益吗(我更看重的是性能提升，而不是构建的方便性）
提前谢谢。