Всем привет! Сегодня мы хотим рассказать про наше знакомство с Big Data, которое началось в 2012 году, когда рынок ещё не накрыла волна популярности темы больших данных.



К тому времени у нас уже накопилась экспертиза в области построения хранилищ данных. Мы рассматривали различные пути улучшения стандартных архитектур ХД, поскольку заказчик хотел обрабатывать большие объёмы данных за короткое время и при ограниченном бюджете. Мы понимали, что большие объёмы данных для стандартного хранилища прекрасно обрабатываются на MPP-платформах, но де-факто это дорого. Значит, нам нужна недорогая распределенная система. Ей оказался Hadoop. Он нуждается в минимальных начальных вложениях, а первые результаты можно получить очень быстро. В дальнейшей перспективе – горизонтальное, практически линейное масштабирование, открытая платформа и много интересных дополнительных функций: например, NoSQL, быстрый поиск по данным, подобие SQL-языка доступа к данным.

Тестовая задача состояла в исследовании обогащения данных на Hadoop: мы замеряли, сколько времени отрабатывают стандартные join-ы данных. Например, пересечение 100 Гб и 10 Гб по меркам реляционных БД – это серьёзные объёмы (индексы при full scan использовать неразумно). На наших тестовых серверах подобные задачи отрабатывали за минуты против десятков минут на реляционном хранилище. С учётом денежных средств, потраченных на реляционное хранилище, и стоимости mid-range массива для ХД (превышает стоимость локального массива в среднем на порядок), выбор для проведения подобных расчётов и средства складирования данных был очевиден.

Для тестирования подхода к решению задачи, нам было необходимо:

• компетенции по разработке под Hadoop
  
• тестовый кластер
  

Мы делали пилотный проект на стеке Hadoop, опираясь на прочитанные книги: «Hadoop: The Definitive Guide» и «MapReduce Design Patterns». У нашей команды уже была экспертиза по Java, и переход на парадигму MapReduce не стал проблемой даже для тех, кто пришёл из Oracle Database. Тогда для старта достаточно было прочитать и усвоить пару книг.

Чтобы ускорить тестирование, мы использовали облачные сервисы от Amazon EC2, что позволило без задержек получить железо и начать установку стека Hadoop от Cloudera. За два дня стенд был готов. В качестве железа мы использовали 10 инстансов с 8 Гб ОЗУ и 2 CPU. Дисков по 50 Гб на каждой машине с учётом тройной репликации данных (по умолчанию) хватило с запасом для решения пилотной задачи. 10 инстансов получили опытным путём, т.к. при снижении количества инстансов производительность резко падала. Сейчас, с развитием сборок от вендоров, кластер ставится «в пару кликов».

Однако join – не основное призвание Hadoop. Его сила в аналитических способностях. Прекрасно понимая это, мы получили первый реальный кейс. Пилотная задача состояла в отслеживании абонентов, посещающих зону вылета в аэропортах Москвы, и направления им релевантного предложения по мобильной связи. Из входных данных были только трафик абонентов и список вышек, которые обслуживают зону вылета в аэропорту. Но это не Big Data.

Big Data появляется в момент второго требования по задаче: определить и исключить из итоговой выборки всех провожающих, встречающих, таксистов, работников магазинов и т.д. Радиус действия сотовых вышек не ограничен только условными границами зоны вылета, поэтому сюда могут попасть и все близлежащие абоненты, в том числе вне здания аэропорта.

Всё здорово, только кластер Amazon для этого использовать нельзя –  ведь мы имеем дело с персональными данными сотового оператора. Стало очевидным, что внедрение Big Data – дело времени, и заказчик решил купить первый кластер. Был рассчитан сайзинг кластера на год вперёд с учётом стратегии развития Big Data и закупили 20 машин HP 380 G8 (2 CPU/48 G RAM/12x3 Tb disk).

Через полгода после начала работ с Big Data у нас выросла команда до 5 сотрудников, а к концу 2013 г. нас стало уже 14 человек. Нам предстояло досконально разобраться во всём, что касается стека Hadoop. Наши сотрудники прошли сертифицированные курсы от компании Cloudera: тренинги по администрированию кластера, разработке на MapReduce, HBase. Этот бэкграунд позволил нам быстрее понять все тонкости работы Hadoop, получить представление о лучших приёмах разработки под MapReduce и взяться за дело. Кстати, сейчас появилось много хороших онлайн-курсов (например, на Coursera).

Реализация первой бизнес-задачи подразумевала постоянную работу в качестве триггера: искать нужные записи с нужными параметрами базовых станций из входящего потока данных. В Hadoop на ежедневной основе считались профили абонентов: сначала вручную, а потом и с применением машинного обучения. Данные о профиле абонента перегружались в in-memory key/value хранилище Redis. Входящий поток данных обрабатывался при помощи Apache Storm. На этом этапе учитывался профиль абонента, интересующая нас сотовая вышка и её сектор. Далее этот поток обрабатывался через политику контактов абонентов (например, чтобы абонент не получал SMS больше положенного количества раз) и поступал на очередь передачи SMS.

Ради эксперимента мы попробовали решить задачу только средствами MapReduce, но получилось плохо: высокая нагрузка на кластер, долгая инициализация Java-машины каждый раз. Не делайте так.

Сейчас у компании-заказчика установлен свой собственный промышленный  кластер, а мы на виртуальных машинах тестируем технологии и оцениваем возможности их применения на реальных задачах.

Вот как-то так наше знакомство и завязалось.

Ах да – меня зовут Беднов Алексей и я готов ответить на ваши вопросы в комментариях.