Big Data — первый опыт ED IB

    Всем привет! Сегодня мы хотим рассказать про наше знакомство с 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-машины каждый раз. Не делайте так.

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

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

    Ах да – меня зовут Беднов Алексей и я готов ответить на ваши вопросы в комментариях.
    AT Consulting
    0,00
    Компания
    Поделиться публикацией

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 18

      +1
      похоже на рекламную брошюрку "Через полгода после начала работ с Big Data у нас выросла команда до 5 сотрудников, а к концу 2013 г. нас стало уже 14 человек"
        0
        много интересных дополнительных функций: например, NoSQL

        А как это понять?
          0
          Тут скорее всего они имели в виду не Apache Hadoop, а CDH, который включает в себя Apache HBase (к которому можно сделать отсылку «NoSQL»), Apache Solr (aka «быстрый поиск по данным»), Apache Hive (aka «подобие SQL-языка доступа к данным», то есть HiveQL)
          +2
          «Всё здорово, только кластер Amazon для этого использовать нельзя – ведь мы имеем дело с персональными данными сотового оператора.»
          — т.е. оператор предоставил вам не обезличенные данные?
            +1
            Пфф, 'ФАМИ? ИЯ' — данные обезличены
            +4
            Про что статья? Чего сказать-то хотели?
              +3
              Видимо о том, как потратить кучу денег и не получить результата.
                0
                Статья о нашем первом опыте знакомства с BigData и Hadoop-технологиями. Она открывает цикл статей о применении Hadoop для решения разнородных практических задач. Мы занимаемся разработкой под Hadoop уже более 2 лет и хотели бы поделиться своей экспертизой.
                +2
                Как вычленили в итоге продавцов, встречающих-провожающих?
                  0
                  Общее описание алгоритма поиска людей, посещающих зону вылета в аэропортах Москвы:

                  1) Ограничивается область покрытия сотовых вышек в зонах вылета/прилёта в аэропортах.
                  2) Формируется список абонентов во временном интервале, соответствующем времени рейса, у которых была любая сетевая активность (звонки / смс / интернет-трафик) в зоне действия вышек из п. 1.
                  3) Из списка из п. 2 выбираются
                  — абоненты, у которых в искомом временном интервале произошло событие включения/выключения телефона (потенциальные пассажиры самолета),
                  — абоненты, которые в течение месяца проводят более 20 часов в зоне действия вышек из п.1 (предположительно, продавцы),
                  — абоненты, у которых есть транзакции в этот же день в области действия вышек Москвы (предположительно, встречающие / провожающие).
                    0
                    А вы еще и рейсы брали в расчет?
                      0
                      Разумеется, был сформирован список рейсов с указанием времени вылета, которое учитывалось в работе алгоритма.
                  +2
                  Похоже, что на волне популярности «Big Data» этот пост призван показать, что «смотрите, мы в AT Consulting тоже умеем Hadoop, у нас есть реальный проект и 14 специалистов, прошедших курсы Cloudera».

                  В целом же были бы интересны подробности: диаграма архитектуры решения, достигнутые показатели производительности с указанием характеристик железа, проблемы интеграции, с которыми вы столкнулись и как вы их решали. Также вы говорите про машинное обучение — тоже интересно, что за модель обучаете и на каких данных
                    0
                    Эти вопросы будут подробнее рассмотрены в наших следующих статьях.

                    что за модель обучаете и на каких данных

                    Это зависит от конкретной задачи. В продуктивных задачах используются алгоритмы
                    — байесовский классификатор
                    — логрегрессия
                    — метод опорных векторов
                    Основная область применения этих алгоритмов — прогнозная аналитика на основе транзакционных данных абонентов.
                    +2
                    Входящий поток данных обрабатывался при помощи Apache Storm.


                    Интересно было бы услышать подробнее об этом.
                      0
                      Основная цель использования Apache Storm — реалтайм фильтрация и обогащение транзакционных данных из источника.
                      Данные передаются потоком с помощью Apache Kafka, на кластере непрерывно работает Storm-задача, которая анализирует этот поток, фильтрует транзакции из потока по определенным критериям и сохраняет нужные в in-memory key/value хранилище Redis.
                        0
                        Дык вот такие детали и есть самое интересное. Все остальное уже сто раз описано-переписано в интернете.
                        Почему Storm, а не спарковские микробатчи, кстати? :)
                          0
                          В общем случае — потому что у нас уже была некоторая экспертиза в Spark Streaming, а эта задача — отличный повод протестировать новый инструмент. :-)
                          Ну и основная направленность Streaming — возможность проведения аналитики с использованием оконных функций, в данном случае эта возможность оказалась бы избыточна, т.к. требовалась только быстрая фильтрация транзакций.

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое