3. Hadoop: что это?
Хранение и обработка больших объемов
данных (петабайты)
1 PiB = 250 Bytes ~ 1015 Bytes
Пользователи: Twitter, Yahoo, Facebook,
LinkedIn
Применение: логи, аналитика, data mining/
machine learning
4. Hadoop: point 1 - Sequential IO
Пример: 1010 записей по 100 байт (1 ТБ), изменяем 1% записей (одна машина, один диск).
Случайный доступ: 1 месяц, линейное чтение-запись: 5.5 часов. Ускорение в 120 раз.
5. Hadoop: point 2&3 - Data locality & Replication
Типовой сервер:
● 1-2 GiGE ports = 120-240 MB/s
● 4-10 Disks = 320-800 MB/s
Вывод: обрабатывать данные нужно там же где и хранить.
Время наработки на отказ диска 500k часов (57 лет).
Если в системе 1000 дисков - 2 мертвых диска в месяц.
Вывод: репликация - обязательна.
7. MapReduce
Способ организации вычислений.
1. Map(key1, value1) → [{key2, value2}]
2. Shuffle([{key2,value2}] → [{key2,[value2]}]
3. Reduce(key2, [value2]) → [value3]
Бенефиты:
● масштабируемость по данным
● концентрация на логике обработки
9. HBase
Распределенное key-value хранилище поверх HDFS.
Пространство ключей разбивается на регионы, распределяемые между
несколькими серверами и хранящиеся в HDFS. Значения группируются по
семействам колонок (CF).
Поддерживаемые операции:
● scan - проход по подмножеству ключей и значений
● put - запись нового значения
● delete
11. Hadoop в поиске Фетчер: обработка
заданий на
закачку
Контент
● хранение и обработка логов (0.5 Задания
ПБ) Логи
● данные хранилище скачанных
данных перед импортом в HBase
Hadoop
● промежуточные результаты Контент,
● данные для индексирования флаги, ранки,
зоны, и т.п.
● бэкапы готовых баз
Индексаторы: готовят
поисковый индекс
Главное: хранилище HBase
12. HBase в поиске: webpages
Ключ: ссылка вида com.vk:http/help.php?page=about
Семейства колонок: flags, crawl, link, rf, imgjoin, parsed, snap
Данные: всё о страницах
● состояние фетчера - когда качали/будем качать, что получили, и т.д.
● флаги - стопицот классификаторов
● ссылки - кто ссылается, на кого ссылается
● ранжирование - стопицот параметров
● картинки
● оригинальный контент
● обработанный контент
Самая толстая таблица, 230 ТБ, 20 млрд ссылок, 10 млрд страниц с контентом.
Количество значений ~500 млрд.
В таблице 7000 регионов, средний размер региона 31 Гб.
13. HBase в поиске: queries & websites
Queries: информация о запросах пользователей, используется в опечаточнике и
ранжировании. Используются фичи HBase: версионность и TTL.
Размер 5.3 ТБ, 7 млрд строк.
Websites: данные о сайтах. Хранится состояние фетчера и ранжирования.
Размер 85 Гб, 200 млн строк.
14. Основные процессы
Fetcher - закачка интернетов:
● Подготовка заданий
● Закачка (отдельные сервера)
● Заливка данных в HBase
● Чистка базы от старых
записей
● Заливка URL'ов
● Дамп контента в индексаторы
● Прочее: sitemaps, robots, etc.
15. ТТХ
160 машин, 8 ТБ памяти, 2.5 ПБ диски. За последние полгода выросли в 8 раз.
Типовая конфигурация: 16 ядер, 50 ГБ, 8-14 дисков по 2 ТБ. Сеть - 2*GiGE.
16. Грабли: compactions
Compact - процесс слияния нескольких файлов с данными в один. Minor - сливаются несколько
небольших файлов. Major - все файлы семейства колонок объединяются в один.
Ошибка HBase - все minor compact превращались в major.
В результате, каждая заливка
выливалась в перелопачивание
сотен терабайт данных.
Решение: https://github.
com/Shmuma/hbase/commits/com
pact-promotion
После исправления,
интенсивность ввода-вывода
уменьшилась в 8 раз.
17. Грабли: деление регионов
Для эффектвного выполнения сканов, обработка всех регионов должна занимать примерно одно
время. Однако, в случае сложной схемы данных, этот критерий разный для разных задач.
Возможные критерии деления:
1. размер региона (реализована в HBase)
2. количество записей в регионе/колонке
3. отклонение размера колонки региона от среднего
4. время обработки региона неким набором задач
Текущее решение - №3. Проблемы:
● временные всплески в размере регионов, вызывающие их необратимое деление
● неточность деления (много пустых ссылок занимают такой же объем что и мало больших
документов)
Решение: переход на хэшированые ключи. Недостаток: сложно удалять опрометчиво залитые данные.
18. Грабли: быстрые сканы
Везде в литературе по HBase рекомендуют заводить не более 1-2 CF. На самом
деле все не так. В случае разнородных данных и разнообразия методов их
обработки, много CF - способ повышения производительности.
Проблема: при скане, по признакам из маленькой колонки (флаги) отбираются
редкие данные из большой колонки (snap). При этом hbase читает все данные
из обеих CF.
Решение: https://issues.apache.org/jira/browse/HBASE-5416
Ускорение сканов ~20 раз.
19. Тайные знания
● dfs.datanode.socket.write.timeout = 300000 (5 мин). Везде рекомендуют
выставлять в 0. Ноль ведет к залипанию потоков RS.
● mapred.reduce.parallel.copies = 2. Везде рекомендуют поставить
побольше. Копирование ускоряется, но одновременные копии валят RS.
● io.sort.factor = 10. Рекомендации - чем больше, тем лучше. Это бред -
большие значения ведут к превращению последовательных операций в
случаные и отстрелу RS.
● mapred.job.tracker.handler.count = 20. Связано с parallel.copies - ставить
сильно много тоже плохо.
● hbase.server.versionfile.writeattempts = 10.
20. Итоги и перспективы
В целом, итоги использования Hadoop и HBase
положительные.
Основной позитивный момент - предоставление команде
разработчиков поиска эффективного инструмента для
работы с полной копией рунета.
21. СПАСИБО!
Максим Лапань
Ведущий разработчик, Поиск@mail.ru
lapan@corp.mail.ru
