www.mail.ru

Использование Hadoop и HBase в поиске

Hadoop: что это? Хранение и обработка больших объемов

данных (петабайты)1 PiB = 250 Bytes ~ 1015 Bytes

Пользователи: Twitter, Yahoo, Facebook, LinkedIn Применение: логи, аналитика, data mining/ machine learning

Hadoop: point 1 - Sequential IO

Пример: 1010 записей по 100 байт (1 ТБ), изменяем 1% записей (одна машина, один диск).Случайный доступ: 1 месяц, линейное чтение-запись: 5.5 часов. Ускорение в 120 раз.

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 мертвых диска в месяц.Вывод: репликация - обязательна.

Hadoop: HDFS Распределенное, отказоустойчивое хранилище данных.

● Отсутствует операция перезаписи данных

● Блоки большого размера (128-256 МБ)

MapReduceСпособ организации вычислений.1. Map(key1, value1) → [{key2, value2}]2. Shuffle([{key2,value2}] → [{key2,[value2]}]3. Reduce(key2, [value2]) → [value3]

Бенефиты:● масштабируемость по данным● концентрация на логике обработки

Hadoop: MapReduce

Данные логически делятся на записи, которые могут обрабатываться независимо → автоматическое распараллеливание задачи.

HBaseРаспределенное key-value хранилище поверх HDFS. Пространство ключей разбивается на регионы, распределяемые между несколькими серверами и хранящиеся в HDFS. Значения группируются по семействам колонок (CF). Поддерживаемые операции:

● scan - проход по подмножеству ключей и значений● put - запись нового значения● delete

HBase: архитектура

Hadoop в поиске ● хранение и обработка логов (0.5

ПБ)● данные хранилище скачанных

данных перед импортом в HBase● промежуточные результаты● данные для индексирования● бэкапы готовых баз

Главное: хранилище HBase

Hadoop

Фетчер: обработка заданий на закачку

КонтентЗадания

Логи

Индексаторы: готовят поисковый индекс

Контент, флаги, ранки, зоны, и т.п.

HBase в поиске: webpagesКлюч: ссылка вида com.vk:http/help.php?page=aboutСемейства колонок: flags, crawl, link, rf, imgjoin, parsed, snapДанные: всё о страницах

● состояние фетчера - когда качали/будем качать, что получили, и т.д.● флаги - стопицот классификаторов● ссылки - кто ссылается, на кого ссылается● ранжирование - стопицот параметров● картинки● оригинальный контент● обработанный контент

Самая толстая таблица, 230 ТБ, 20 млрд ссылок, 10 млрд страниц с контентом.Количество значений ~500 млрд.В таблице 7000 регионов, средний размер региона 31 Гб.

HBase в поиске: queries & websites Queries: информация о запросах пользователей, используется в опечаточнике и ранжировании. Используются фичи HBase: версионность и TTL.Размер 5.3 ТБ, 7 млрд строк. Websites: данные о сайтах. Хранится состояние фетчера и ранжирования. Размер 85 Гб, 200 млн строк.

Основные процессыFetcher - закачка интернетов:● Подготовка заданий● Закачка (отдельные сервера)● Заливка данных в HBase● Чистка базы от старых

записей● Заливка URL'ов● Дамп контента в индексаторы● Прочее: sitemaps, robots, etc.

ТТХ160 машин, 8 ТБ памяти, 2.5 ПБ диски. За последние полгода выросли в 8 раз.Типовая конфигурация: 16 ядер, 50 ГБ, 8-14 дисков по 2 ТБ. Сеть - 2*GiGE.

Грабли: compactionsCompact - процесс слияния нескольких файлов с данными в один. Minor - сливаются несколько небольших файлов. Major - все файлы семейства колонок объединяются в один.Ошибка HBase - все minor compact превращались в major.

В результате, каждая заливка выливалась в перелопачивание сотен терабайт данных. Решение: https://github.com/Shmuma/hbase/commits/compact-promotion После исправления, интенсивность ввода-вывода уменьшилась в 8 раз.

Грабли: деление регионовДля эффектвного выполнения сканов, обработка всех регионов должна занимать примерно одно время. Однако, в случае сложной схемы данных, этот критерий разный для разных задач.Возможные критерии деления:1. размер региона (реализована в HBase)2. количество записей в регионе/колонке3. отклонение размера колонки региона от среднего4. время обработки региона неким набором задач

Текущее решение - №3. Проблемы:● временные всплески в размере регионов, вызывающие их необратимое деление● неточность деления (много пустых ссылок занимают такой же объем что и мало больших

документов)Решение: переход на хэшированые ключи. Недостаток: сложно удалять опрометчиво залитые данные.

Грабли: быстрые сканыВезде в литературе по HBase рекомендуют заводить не более 1-2 CF. На самом деле все не так. В случае разнородных данных и разнообразия методов их обработки, много CF - способ повышения производительности.Проблема: при скане, по признакам из маленькой колонки (флаги) отбираются редкие данные из большой колонки (snap). При этом hbase читает все данные из обеих CF.Решение: https://issues.apache.org/jira/browse/HBASE-5416Ускорение сканов ~20 раз.

Тайные знания● 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.

Итоги и перспективыВ целом, итоги использования Hadoop и HBase положительные. Основной позитивный момент - предоставление команде разработчиков поиска эффективного инструмента для работы с полной копией рунета.

Максим ЛапаньВедущий разработчик, Поиск@mail.ru

lapan@corp.mail.ru

СПАСИБО!