我有多個Spark Sessions在不同的驅動節點上查詢同一個HDFS檔案，比方說表T1。下面是T1的結構。
- 按日期劃分 <
- 按日期磁區
- 然后按用戶ID的前2位數字磁區 。
- 用戶ID欄位 。
- 用戶的其他相關資訊 。
| 磁區日期 | 磁區的前2位數字 | 用戶ID其他資訊17 | 01 | 01234 | ... | 18 | 01234...18 |
|---|
現在我嘗試了兩種情況，
。創建8個不同的spark會話，并將其放在不同的位置。
在不同的驅動節點上創建8個多個spark會話（使用集群模式），并在完全相同的磁區和用戶ID上并發查詢，每個會話獲得代碼中限制的所有資源，例如每個會話需要
- 1個驅動/1個CPU
- 1個驅動程式/1個CPU/4GB
- 4個執行器/每個執行器1個CPU/每個執行器4GB 。
下面是查詢樣本。
SELECT * FROM T1
WHERE user_id = '01234' AND partition_date IN ('17', '18') AND partition_first_2_digit IN ('01'/span>, '02')
只創建一個spark會話，使用上述相同的字串進行查詢。這個會話也獲得了代碼中限制的所有資源，這相當于多個會話的情況。
- 1個驅動程式/1個CPU/4GB
- 4個執行器/每個執行器1個CPU/每個執行器4GB 。
結果讓我很吃驚，在多個spark會話的情況下，每個應用程式的查詢時間是10分鐘，這比一個spark會話的5分鐘高得多！
我很好奇，為什么多個spark會話會使查詢速度大大降低？有沒有人有同樣的問題？
提前感謝您。
預先感謝大家！
uj5u.com熱心網友回復：
理論上，在這兩種情況下，性能應該是一樣的，但還有其他因素可能會影響作業的調度。根據我的經驗，你可能會遇到這些制約因素中的任何一個。
這些是我在職業生涯中見過的一些問題，也可能有其他因素。我建議從你的系統管理員那里獲得yarn schedular或佇列的訪問權，看看其中是否是罪魁禍首。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/318968.html
標籤：
上一篇：ApacheNutchIndexerPlugintoManticoreSearch例外:java.lang.NoClassDefFoundError:com/manticoresearch/clien