Hadoop Distributions: Bottlenecks and Tuning
Download as PPTX, PDF1 like932 views
The document discusses performance monitoring and optimization strategies for Apache Hadoop, covering various target groups including Cloudera and Hortonworks. It suggests methods for finding bottlenecks in the system, mainly focused on increasing cluster size, input block size, and buffer size. Additionally, it includes examples of data aggregation functions such as combiner and reduce, illustrating how to combine and reduce datasets effectively.
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
Editor's Notes
- #9: вывод map, если в буфер не влазит то сброс на диск, потом merge-sort.в определенный момент 2х кратное превышение использования диска относительно вывода map
- #10: данные гоняются по сети, нагрузка на io – disk read & network
- #11: вывод map, если в буфер не влазит то сброс на диск, потом merge-sort.в определенный момент 2х кратное превышение использования диска относительно вывода map
- #12: Задачка: сколько записей и чтений на диск можно получить имея вывод 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
- #13: Задачка: сколько записей и чтений на диск можно получить имея вывод 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
- #14: увеличим количество машин в 2 раза, а заодно и в параметрах проставим в 2 раза больше map и reducemap и reduce => eachother => в 4 раза больше коннектов на получение данных => лимиты на обработку handlers, на самой датанодеВЫВОД: количество одновременно запущенных map/reduceинстансов должно определяться в первую очередь задачей, линейное масштабирование это сказка
- #15: увеличим количество машин в 2 раза, а заодно и в параметрах проставим в 2 раза больше map и reducemap и reduce => eachother => в 4 раза больше коннектов на получение данных => лимиты на обработку handlers, на самой датанодеВЫВОД: количество одновременно запущенных map/reduceинстансов должно определяться в первую очередь задачей, линейное масштабирование это сказка
- #19: 2) увеличим блок данных для map => выскочили за размеры буфера => лишний spill на диск => больше дискового io => все медленней. ВЫВОД: размер блока для обработки на вход map должен быть достаточно большим чтобы заполнить буфер, но не больше, иначе лишняя активность на диске
- #20: 2) увеличим блок данных для map => выскочили за размеры буфера => лишний spill на диск => больше дискового io => все медленней. ВЫВОД: размер блока для обработки на вход map должен быть достаточно большим чтобы заполнить буфер, но не больше, иначе лишняя активность на диске
- #21: 3) увеличим размер кеша на map/reduce => ограничения размера для буфера в jvm (больше 2х гб на массив не выделить)Тут уже ничего не поделать, нужно учитывать что у map/reduce функций есть свои лимиты и они легко достижимы
- #22: компрессия => размен cpu на diskio => snappy, достаточно шустрое решение для потокового сжатия
- #23: Combiner - не всегда возможно использовать в лоб (например мы считаем с помощью hive/pig) или у нас веселая функция
- #25: incorrect
- #26: incorrect
- #27: правильное решение, но требует дополнительных манипуляций на всех уровнях: 1) меняем MapOutputFormat (в значении не просто число, а сумма свернутых чисел и количество чисел для получения текущей суммы)2) отдельная функция для Combine