Всем привет! Сегодня мы хотим рассказать о нашем знакомстве с большими данными, которое началось в 2012 году, когда волна популярности темы больших данных еще не захлестнула рынок.
К тому времени у нас уже был накоплен опыт в области построения хранилищ данных.
Мы рассмотрели различные способы улучшения стандартных архитектур хранилищ данных, поскольку заказчик хотел обрабатывать большие объемы данных за короткое время и при ограниченном бюджете.
Мы понимали, что большие объемы данных для стандартного хранилища прекрасно обрабатываются на MPP-платформах, но по факту это дорого.
Это означает, что нам нужна недорогая распределенная система.
Это оказался Hadoop. Он требует минимальных первоначальных вложений, а первые результаты можно получить очень быстро.
В будущем — горизонтальное, почти линейное масштабирование, открытая платформа и множество интересных дополнительных функций: например, NoSQL, быстрый поиск данных, что-то вроде языка доступа к данным SQL. Тестовое задание заключалось в изучении обогащения данных на Hadoop: мы измеряли, сколько времени занимает обработка стандартных объединений данных.
Например, пересечение 100 ГБ и 10 ГБ по меркам реляционных баз данных — это серьезный объем (использовать индексы с полной проверкой неразумно).
На наших тестовых серверах аналогичные задачи выполнялись за считанные минуты, тогда как в реляционном хранилище — десятки минут. С учетом затраченных средств на реляционное хранилище и стоимости массива среднего уровня для хранилища данных (превышающей стоимость локального массива в среднем на порядок) выбор средств для проведения таких вычислений и хранения данных было очевидно.
Для проверки подхода к решению задачи нам понадобилось:
- Компетенции в области разработки Hadoop
- тестовый кластер
Для ускорения тестирования мы использовали облачные сервисы Amazon EC2, что позволило нам без задержек получить оборудование и начать установку стека Hadoop от Cloudera. Стенд был готов через два дня.
В качестве оборудования мы использовали 10 экземпляров с 8 ГБ ОЗУ и 2 процессорами.
Дисков по 50 ГБ на каждой машине с учетом тройной репликации данных (по умолчанию) хватило для решения пилотной задачи.
10 экземпляров было получено экспериментальным путем, так как при уменьшении количества экземпляров резко падала производительность.
Теперь, с развитием сборок от вендоров, кластер можно установить «в пару кликов».
Однако объединение не является основной целью Hadoop. Его сила в аналитических способностях.
Прекрасно понимая это, мы получили первый реальный случай.
Пилотной задачей было отследить абонентов, посещающих зону вылета в аэропортах Москвы, и отправить им актуальное предложение по мобильной связи.
Единственными входными данными был абонентский трафик и список вышек, обслуживающих зону вылета в аэропорту.
Но это не большие данные.
Большие данные появляются в момент второго требования к задаче: идентифицировать и исключить из итоговой выборки всех провожающих, встречающих, таксистов, работников магазинов и т.п.
Радиус действия вышек сотовой связи не ограничивается только условными границами сети.
зона вылета, поэтому сюда могут попасть все близлежащие абоненты, в том числе находящиеся за пределами здания аэропорта.
Все здорово, но кластер Amazon для этого использовать нельзя — ведь мы имеем дело с персональными данными сотового оператора.
Стало очевидно, что внедрение Big Data — вопрос времени, и заказчик решил купить первый кластер.
Размер кластера был рассчитан на год вперед с учетом стратегии развития Big Data и закуплено 20 машин HP 380 G8 (2 CPU/48 ГБ RAM/12x3 Tb диск).
Через полгода после того, как мы начали работать с большими данными, наша команда выросла до 5 человек, а к концу 2013 года ее было уже 14 человек.
Нам пришлось досконально разобраться во всем, что связано со стеком Hadoop. Наши сотрудники прошли сертифицированные курсы от Cloudera: обучение администрированию кластера, разработке на MapReduce, HBase. Этот бэкграунд позволил нам быстро разобраться во всех тонкостях Hadoop, получить представление о лучших практиках разработки MapReduce и приступить к делу.
Кстати, сейчас есть много хороших онлайн-курсов (например, на Coursera).
Реализация первой бизнес-задачи подразумевала постоянную работу триггера: поиск нужных записей с нужными параметрами базовых станций из входящего потока данных.
В Hadoop профили подписчиков рассчитывались ежедневно: сначала вручную, а затем с помощью машинного обучения.
Данные профиля подписчика были загружены в хранилище ключей/значений в памяти Redis. Входящий поток данных обрабатывался с помощью Apache Storm. На этом этапе учитывался профиль абонента, интересующая нас вышка сотовой связи и ее сектор.
Далее этот поток обрабатывался через политику контакта с абонентом (например, чтобы абонент не получал СМС больше необходимого количества раз) и попадал в очередь передачи СМС.
Ради эксперимента мы попытались решить проблему только с помощью MapReduce, но получилось плохо: высокая нагрузка на кластер, долгая инициализация Java-машины каждый раз.
Не делай этого.
Сейчас компания-заказчик установила собственный промышленный кластер, и мы тестируем технологии на виртуальных машинах и оцениваем возможности их использования на реальных задачах.
Так началось наше знакомство.
Ах да — меня зовут Алексей Беднов и я готов ответить на ваши вопросы в комментариях.
Теги: #Большие данные #NoSQL #Hadoop #MapReduce #hbase #Cloudera #Большие данные #Hadoop
-
Игра
19 Oct, 24 -
Как Удалить Список Последних Документов
19 Oct, 24 -
Чтение Rss-Каналов С Помощью Rss-Агрегатора
19 Oct, 24 -
Гипотетический Полет К Далеким Мирам
19 Oct, 24 -
Проект Fab Lab — Интернет Для Атомов
19 Oct, 24 -
Файловый Хостинг От File Qube.
19 Oct, 24
