Комментарии 18
похоже на рекламную брошюрку "Через полгода после начала работ с Big Data у нас выросла команда до 5 сотрудников, а к концу 2013 г. нас стало уже 14 человек"
много интересных дополнительных функций: например, NoSQL
А как это понять?
Тут скорее всего они имели в виду не Apache Hadoop, а CDH, который включает в себя Apache HBase (к которому можно сделать отсылку «NoSQL»), Apache Solr (aka «быстрый поиск по данным»), Apache Hive (aka «подобие SQL-языка доступа к данным», то есть HiveQL)
«Всё здорово, только кластер Amazon для этого использовать нельзя – ведь мы имеем дело с персональными данными сотового оператора.»— т.е. оператор предоставил вам не обезличенные данные?
Про что статья? Чего сказать-то хотели?
Видимо о том, как потратить кучу денег и не получить результата.
Статья о нашем первом опыте знакомства с BigData и Hadoop-технологиями. Она открывает цикл статей о применении Hadoop для решения разнородных практических задач. Мы занимаемся разработкой под Hadoop уже более 2 лет и хотели бы поделиться своей экспертизой.
Как вычленили в итоге продавцов, встречающих-провожающих?
Общее описание алгоритма поиска людей, посещающих зону вылета в аэропортах Москвы:
1) Ограничивается область покрытия сотовых вышек в зонах вылета/прилёта в аэропортах.
2) Формируется список абонентов во временном интервале, соответствующем времени рейса, у которых была любая сетевая активность (звонки / смс / интернет-трафик) в зоне действия вышек из п. 1.
3) Из списка из п. 2 выбираются
— абоненты, у которых в искомом временном интервале произошло событие включения/выключения телефона (потенциальные пассажиры самолета),
— абоненты, которые в течение месяца проводят более 20 часов в зоне действия вышек из п.1 (предположительно, продавцы),
— абоненты, у которых есть транзакции в этот же день в области действия вышек Москвы (предположительно, встречающие / провожающие).
1) Ограничивается область покрытия сотовых вышек в зонах вылета/прилёта в аэропортах.
2) Формируется список абонентов во временном интервале, соответствующем времени рейса, у которых была любая сетевая активность (звонки / смс / интернет-трафик) в зоне действия вышек из п. 1.
3) Из списка из п. 2 выбираются
— абоненты, у которых в искомом временном интервале произошло событие включения/выключения телефона (потенциальные пассажиры самолета),
— абоненты, которые в течение месяца проводят более 20 часов в зоне действия вышек из п.1 (предположительно, продавцы),
— абоненты, у которых есть транзакции в этот же день в области действия вышек Москвы (предположительно, встречающие / провожающие).
Похоже, что на волне популярности «Big Data» этот пост призван показать, что «смотрите, мы в AT Consulting тоже умеем Hadoop, у нас есть реальный проект и 14 специалистов, прошедших курсы Cloudera».
В целом же были бы интересны подробности: диаграма архитектуры решения, достигнутые показатели производительности с указанием характеристик железа, проблемы интеграции, с которыми вы столкнулись и как вы их решали. Также вы говорите про машинное обучение — тоже интересно, что за модель обучаете и на каких данных
В целом же были бы интересны подробности: диаграма архитектуры решения, достигнутые показатели производительности с указанием характеристик железа, проблемы интеграции, с которыми вы столкнулись и как вы их решали. Также вы говорите про машинное обучение — тоже интересно, что за модель обучаете и на каких данных
Эти вопросы будут подробнее рассмотрены в наших следующих статьях.
Это зависит от конкретной задачи. В продуктивных задачах используются алгоритмы
— байесовский классификатор
— логрегрессия
— метод опорных векторов
Основная область применения этих алгоритмов — прогнозная аналитика на основе транзакционных данных абонентов.
что за модель обучаете и на каких данных
Это зависит от конкретной задачи. В продуктивных задачах используются алгоритмы
— байесовский классификатор
— логрегрессия
— метод опорных векторов
Основная область применения этих алгоритмов — прогнозная аналитика на основе транзакционных данных абонентов.
Входящий поток данных обрабатывался при помощи Apache Storm.
Интересно было бы услышать подробнее об этом.
Основная цель использования Apache Storm — реалтайм фильтрация и обогащение транзакционных данных из источника.
Данные передаются потоком с помощью Apache Kafka, на кластере непрерывно работает Storm-задача, которая анализирует этот поток, фильтрует транзакции из потока по определенным критериям и сохраняет нужные в in-memory key/value хранилище Redis.
Данные передаются потоком с помощью Apache Kafka, на кластере непрерывно работает Storm-задача, которая анализирует этот поток, фильтрует транзакции из потока по определенным критериям и сохраняет нужные в in-memory key/value хранилище Redis.
Дык вот такие детали и есть самое интересное. Все остальное уже сто раз описано-переписано в интернете.
Почему Storm, а не спарковские микробатчи, кстати? :)
Почему Storm, а не спарковские микробатчи, кстати? :)
В общем случае — потому что у нас уже была некоторая экспертиза в Spark Streaming, а эта задача — отличный повод протестировать новый инструмент. :-)
Ну и основная направленность Streaming — возможность проведения аналитики с использованием оконных функций, в данном случае эта возможность оказалась бы избыточна, т.к. требовалась только быстрая фильтрация транзакций.
Ну и основная направленность Streaming — возможность проведения аналитики с использованием оконных функций, в данном случае эта возможность оказалась бы избыточна, т.к. требовалась только быстрая фильтрация транзакций.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Big Data — первый опыт ED IB