针对hive表的查询优化

Question

我们有一个100TB大小的表，我们有多个客户使用同一个表（即每个客户使用不同的条件）。现在问题陈述是每次客户尝试查询从上到下扫描的表。

这会给所有查询带来很多缓慢。我们甚至无法根据任何业务键对表进行分区/存储。有人可以提供解决方案或指向类似的问题陈述及其解决方案。

您可以提供您的建议以及替代技术，以便我们选择最适合的建议。感谢。

Answer 1

我的2美分：尝试使用GZip压缩的ORC表（默认）和巧妙的分区/排序......

• 在 WHERE 子句中使用分区键的每个 SELECT 将 做分区修剪＆＃34;因此，避免扫描所有 [好的，好的，你说在你的具体情况下你没有好的候选人，但总的来说它可以做到所以我必须先提到它]
• 然后在范围内的每个ORC文件中，最小/最大计数器将是 检查＆＃34;条带修剪＆＃34;，进一步限制I / O

聪明的分区＆amp;在 INSERT 时巧妙地排序数据，使用最频繁的过滤器，修剪效率非常高。

然后，您可以查看优化，例如使用非默认ORC条带大小，非默认＆＃34;字节每减速器＆＃34;门槛等。

参考：

1. http://fr.slideshare.net/oom65/orc-andvectorizationhadoopsummit
2. https://cwiki.apache.org/confluence/display/Hive/LanguageManual+ORC
3. https://streever.atlassian.net/wiki/display/HADOOP/Optimizing+ORC+Files+for+Query+Performance
4. http://thinkbig.teradata.com/hadoop-performance-tuning-orc-snappy-heres-youre-missing/

最后一件事：有15个节点用于运行查询，复制因子为3，每个HDFS块都可用＆＃34;本地＆＃34; 3节点（20％）和＆＃34;远程＆＃34;其余的（80％）。更高的复制因子可能会减少I / O和网络瓶颈 - 当然是以磁盘空间为代价。