Hadoop Distributions: Bottlenecks and Tuning
•Als PPTX, PDF herunterladen•
1 gefällt mir•928 views
This presentation by Alexey Diomin, R&D Engineer at Altoros, explains how to spot performance bottlenecks in Hadoop and overviews five approaches to eliminating them.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (11)
Ähnlich wie Hadoop Distributions: Bottlenecks and Tuning
Ähnlich wie Hadoop Distributions: Bottlenecks and Tuning (11)
Mehr von Altoros
Mehr von Altoros (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Hadoop Distributions: Bottlenecks and Tuning
- 4. How to find the bottleneck? 4
- 5. 5
- 6. 6
- 8. 8
- 9. 9
- 10. 10
- 11. 11
- 12. 12
- 13. 1. Increase size of cluster 2. Increase input block size 3. Increase buffer size 13
- 14. 1. Increase size of cluster 2. Increase input block size 3. Increase buffer size 14
- 15. 15
- 16. 16
- 17. 17
- 18. 1. Increase size of cluster 2. Increase input block size 3. Increase buffer size 18
- 19. 19
- 20. 1. Increase size of cluster 2. Increase input block size 3. Increase buffer size 20
- 23. Wordcount Reduce function as Combine combine 1: <a, 1> <b, 1> <a, 1> => <a, 2> <b, 1> combine 2: <a, 1> <b, 1> => <a, 1> <b, 1> Reduce: <a, {1, 2}> <b, {1, 1}> => <a, 3> <b, 2> 23
- 24. Mean combine 1: <k,40> <k,30> <k,20> => <k, 30> combine 2: <k,2> <k,8> => <k, 5> Reduce: => <k, 17.5> <k, {30, 5}> 24
- 25. Mean combine 1: <k,40> <k,30> <k,20> => <k, 30> combine 2: <k,2> <k,8> => <k, 5> Reduce: => <k, 17.5> <k, {30, 5}> (40 + 30 + 20 + 2 + 8)/5 = 17.5 25
- 26. Mean combine 1: <k,<40,1>> <k,<30,1>>, <k,<20,1>> => <k, <90,3> > <k,<2,1>> <k, <8,1>> => <k, <10, 2> > Reduce: => <k, 20> combine 2: <k, {<90,3>, <10,2>} > 26
- 27. 27
Hinweis der Redaktion
- вывод map, если в буфер не влазит то сброс на диск, потом merge-sort.в определенный момент 2х кратное превышение использования диска относительно вывода map
- данные гоняются по сети, нагрузка на io – disk read & network
- вывод map, если в буфер не влазит то сброс на диск, потом merge-sort.в определенный момент 2х кратное превышение использования диска относительно вывода map
- Задачка: сколько записей и чтений на диск можно получить имея вывод X.идеально: X записали из map, X считали на этапе fetchсуровая реальность: write: X(spill) + X (merge-sort) + X (fetch/spill) = 3 Xread: X (merge-sort) + X (fetch) + X (toreducer) = 3 X
- Задачка: сколько записей и чтений на диск можно получить имея вывод X.идеально: X записали из map, X считали на этапе fetchсуровая реальность: write: X(spill) + X (merge-sort) + X (fetch/spill) = 3 Xread: X (merge-sort) + X (fetch) + X (toreducer) = 3 X
- увеличим количество машин в 2 раза, а заодно и в параметрах проставим в 2 раза больше map и reducemap и reduce => eachother => в 4 раза больше коннектов на получение данных => лимиты на обработку handlers, на самой датанодеВЫВОД: количество одновременно запущенных map/reduceинстансов должно определяться в первую очередь задачей, линейное масштабирование это сказка
- увеличим количество машин в 2 раза, а заодно и в параметрах проставим в 2 раза больше map и reducemap и reduce => eachother => в 4 раза больше коннектов на получение данных => лимиты на обработку handlers, на самой датанодеВЫВОД: количество одновременно запущенных map/reduceинстансов должно определяться в первую очередь задачей, линейное масштабирование это сказка
- 2) увеличим блок данных для map => выскочили за размеры буфера => лишний spill на диск => больше дискового io => все медленней. ВЫВОД: размер блока для обработки на вход map должен быть достаточно большим чтобы заполнить буфер, но не больше, иначе лишняя активность на диске
- 2) увеличим блок данных для map => выскочили за размеры буфера => лишний spill на диск => больше дискового io => все медленней. ВЫВОД: размер блока для обработки на вход map должен быть достаточно большим чтобы заполнить буфер, но не больше, иначе лишняя активность на диске
- 3) увеличим размер кеша на map/reduce => ограничения размера для буфера в jvm (больше 2х гб на массив не выделить)Тут уже ничего не поделать, нужно учитывать что у map/reduce функций есть свои лимиты и они легко достижимы
- компрессия => размен cpu на diskio => snappy, достаточно шустрое решение для потокового сжатия
- Combiner - не всегда возможно использовать в лоб (например мы считаем с помощью hive/pig) или у нас веселая функция
- incorrect
- incorrect
- правильное решение, но требует дополнительных манипуляций на всех уровнях: 1) меняем MapOutputFormat (в значении не просто число, а сумма свернутых чисел и количество чисел для получения текущей суммы)2) отдельная функция для Combine