配置單元查詢優化

Question

我們有一個大小為100TB的表，並且有多個客戶使用同一張表（即每個客戶在不同的條件下使用）。 現在，問題陳述是客戶每次嘗試查詢其表時都要從上到下進行掃描。

這為所有查詢帶來了很多緩慢。 我們甚至無法基於任何業務密鑰對表進行分區/存儲。 有人可以提供解決方案或指向類似的問題陳述及其解決方案。

您可以提供您的建議以及替代技術，以便我們選擇最合適的技術。 謝謝。

Answer 1

我的2美分：嘗試使用帶有GZip壓縮（默認）和巧妙的分區/排序功能的ORC表...

• 每個在其WHERE子句中使用分區鍵的SELECT都將執行“分區修剪”，因此避免掃描所有內容[確定，確定，您說您在特定情況下沒有好的候選人，但總的來說，這樣做可以先說]
• 然后在范圍內的每個ORC文件中，將檢查最小/最大計數器的“條帶修剪”，進一步限制I / O

通過在插入時對數據進行巧妙的分區和巧妙的排序，使用最頻繁的過濾器，修剪可以非常高效。

然后，您可以研究優化，例如使用非默認的ORC條帶大小，非默認的“每個減少的字節數”閾值等。

參考：

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塊在3個節點（20％）上“本地”可用，其余節點（80％）“遠程”上可用。 更高的復制因子可以減少I / O和網絡瓶頸-當然會以磁盤空間為代價。