Download - Lapan 20.04 hadoop h-base
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 положительные. Основной позитивный момент - предоставление команде разработчиков поиска эффективного инструмента для работы с полной копией рунета.