Big Data *

Хабр, привет! Публикуем обзор третьего и четвертого дня Data Science Week 2016, а именно это были Sberbank Data Day и день, посвященный теме искусственного интеллекта.

Вчера наша команда провела вебинар на тему «Инструменты для работы Data Scientist». В его рамках мы рассмотрели, кто такой data scientist и какими инструментами он пользуется. Поговорили о платформе FlyElephant и чем она может быть полезной для работы data scientist’а.

После того, как в предыдущих статьях данной серии обзоров распределённого Java-фреймворка Apache Ignite мы сделали первые шаги, познакомились с основными принципами построения топологии и даже сделали стартер для Spring Boot, неизбежно встаёт вопрос о кэшировании, которое является одной из основных функций Ignite. Прежде всего, хотелось бы понять, нужно ли оно, когда библиотек для кэширования на Java и так полным-полно. Тем, что предоставляется реализация стандарта JCache (JSR 107) и возможность распределённого кэширования в наше время удивить сложно. Поэтому прежде чем (или вместо того чтобы) рассматривать функциональные возможности кэша Apache Ignite, мне бы хотелось посмотреть, насколько он быстр.

Для исследования применялся бенчмарк cache2k-benchmark, разработанный с целью доказательства того, что у библиотеки cache2k кэш самый быстрый. Вот заодно и проверим. Настоящая статья не преследует цель всеобъемлющего тестирования производительности, или хотя бы научно достоверного, пусть этим занимаются разработчики Apache Ignite. Мы просто посмотрим на порядок величин, основные особенности и взаимное расположение в рейтинге, в котором будут ещё cache2k и нативный кэш на ConcurrentHashMap.

Big Data – это проблема. Количество информации растет с каждым днем, и она накапливается как снежный ком. Прекрасно то, что проблема эта имеет решения, только в мире JVM больший данных процессят десятки тысяч проектов.

В 2012 году увидел свет фреймворк Apache Spark, разработанный на Scala и рассчитанный на повышение производительности определенных классов задач в работе с Big Data. Проекту уже 4 года он повзрослел и дорос до версии 2.0, к которой (на самом деле уже начиная с версии 1.3-1.5) имеет мощный и удобный API для работы с Java. Чтобы понять, для кого это все надо, какие именно задачи стоит решать при помощи Spark, а какие не стоит, мы поговорили с Евгением EvgenyBorisov Борисовым, автором тренинга «Welcome to Spark», который пройдет 12-13 октября в Петербурге.

Привет, Хаброжители! Ранее мы переводили статью «Знакомство с Apache Spark». Сейчас вы знакомим Вас с одноименной книгой, написанной Сэнди Ризай, Ури Лезерсоном, Шоном Оуэн, Джошем Уиллсом.

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

В течение последних шести лет в Яндексе идет работа над системой под кодовым называнием YT (по-русски мы называем её «Ыть»). Это основная платформа для хранения и обработки больших объемов данных — мы уже о ней рассказывали на YaC 2013. С тех пор она продолжала развиваться. Сегодня я расскажу о том, с чего началась разработка YT, что нового в ней появилось и что ещё мы планируем сделать в ближайшее время.



Кстати, 15 октября в офисе Яндекса мы расскажем не только о YT, но и о других наших инфраструктурных технологиях: Media Storage, Yandex Query Language и ClickHouse. На встрече мы раскроем тайну — расскажем, сколько же в Яндексе MapReduce-систем.

Какую задачу мы решаем?

По роду своей деятельности Яндекс постоянно сталкивается с необходимостью хранить и обрабатывать данные таких объемов, с которыми обычному пользователю никогда не приходится иметь дело. Поисковые логи и индексы, пользовательские данные, картографическая информация, промежуточные данные и результаты алгоритмов машинного обучения — все это может занимать сотни петабайт дискового пространства. Для эффективной обработки подобных объемов традиционно используется парадигма MapReduce, позволяющая достичь хорошего баланса между эффективностью вычислений и простотой пользовательского кода.

Хабр, привет! Публикуем обзор первых двух дней Data Science Week 2016, в которые наши спикеры говорили о взаимоотношениях с клиентом и внутренней оптимизации.

Вот уже вышло две статьи в потенциально очень длинной серии обзоров распределённой платформы Apache Ignite (первая про настройку и запуск, вторая про построение топологии). Данная статья посвящена попытке подружить Apache Ignite и Spring Boot. Стандартным способом подключения некой библиотеки к Spring Boot является создание для этой технологии «стартера». Несмотря на то, что Spring Boot весьма популярен и на Хабре описывался не единожды, про то, как делать стартеры, вроде бы ещё не писали. Этот досадный пробел я постараюсь закрыть.

Статья посвящена преимущественно Spring Boot'у и Spring Core, так что те, кого тема Apache Ignite не интересует, всё равно могут узнать что-то новое. Код выложен на GitHub, стартера и демо-приложения.

В предыдущей статье я рассказал о том, как построить простейшую топологию для Apache Ignite. Она состояла из одного клиента и одного сервера, клиент слал на сервер сообщение и сервер его отображал. Было рассказано о том, как настроить продукт и проконтролировать его жизнедеятельность. Теперь пришло время для более сложного примера. Будет продемонстрировано построение сложной топологии и более интересные сценарии взаимодействия. Предполагается, что читатель ознакомился с базовыми операциями с Apache Ignite, изложенными в первой статье. В результате прочтения этих двух статей у читателя могут возникнуть какие-то предположения о том, как ему применить этот, без преувеличения, мощный продукт в своих проектах. Также статья будет полезна тем, кто интересуется построением высокопроизводительных систем, и хочет подсмотреть готовое решение для своего велосипеда.

Хабр, привет! В скором времени, 5 октября, у нас стартует уже 5-ый набор программы “Специалист по большим данным”. Сейчас проходит активная стадия подготовки к организации этого 3-месячного марафона, и мы с коллегами задались вопросами, что же будет нового в этом наборе.

Программа уже существует на рынке 1.5 года, обкатана и проработана с разных сторон, но есть важные изменения в силу того, что технологии не стоят на месте.

Big Data наступают по всем фронтам — их роль растёт в науке, бизнесе, медицине, управлении безопасностью и в экономике. Поэтому каждая из сфер готова на на шутку бороться за лучшие умы специалистов. Среди самых удачных попыток найти самых-самых — важнейшее мировое соревнование в области анализа данных CIKM Cup 2016, который проходит в рамках 25-ой международной конференции CIKM Conf. 2016. Российская технологическая компания DCA, специализирующаяся на работе с большими данными и высоконагруженными системами, на этот раз стала партнером конференции и соревнования. DCA сформировала задачу, которую предстоит решить участникам CIKM Cup 2016, а также обеспечила необходимым набором данных для анализа. Хотите узнать немного больше о задаче и попробовать силы в соревнованиях Data Scientist — вам под кат. Кому как не нам знать, насколько сильны российские специалисты в сфере обработки данных.

Мы ищем своих Брюсов Уиллисов.

Рискну предположить, что среднестатистический читатель этой статьи с продуктом Apache Ignite не знаком. Хотя, возможно, слышал или даже читал статью на Хабре, в которой описывается один из возможных сценариев использования этого продукта. О принудительном использовании Ignite в качесте L2 кэша для Activiti я писал недавно. Возможно, узнав о том, что это написанный на Java open source продукт, позиционирующий себя как «высокопроизводительная, интегрированная и распределённая in-memory платформа для вычисления и обработки больших объёмов данных в реальном времени», обладающая, помимо прочего возможностью автоматического деплоймента вашего проекта на все ноды сложной топологии, вам захочется с ним познакомиться. Испытав такое желание, вы обнаружите, что Ignite документирован не то, чтобы совсем плохо, но и не очень хорошо. Есть туториал, кое-какой javadoc, но полного и целостного впечатления от ознакомления с этими источниками не возникает. В настоящей статье я попытаюсь восполнить этот пробел на основе собственного опыта познания Ignite, полученного преимущественно путём дебага. Возможно, в своих выводах и впечатлениях я буду не всегда прав, но таковы издержки метода. От читателя и тех, кто захочет повторить мой путь, требуется не так много, а именно знание Java 8 core, multithreading и Spring core.

В статье будет рассмотрен и препарирован пример класса «Hello World!» с использованием данной технологии.

Команда FlyElephant приглашает всех 28 сентября в 16.00 на вебинар «Инструменты для работы Data Scientist». В его рамках мы рассмотрим, кто такой data scientist и какими инструментами он пользуется. Поговорим о платформе FlyElephant и чем она может быть полезной для работы data scientist’а.

Содержание вебинара:

• Data Science
• Data Scientist vs Data Engineer
• How does it work?
• Notebook / IDE
• Methods & Algorithms
• Software
• Deep Learning Tools
• Programming Languages
• Cloud Services
• Computing power
• Competitions
• FlyElephant

Зарегистрироваться на вебинар можно здесь.

Сегодня хочу рассказать вам об open source проекте под названием Bagri. Bagri — это распределенная база данных документов (document database), или как сейчас модно говорить NoSQL база данных, написанная на Java и спроектированная с учетом требований, в основном используемых в корпоративном секторе, таких как высокая готовность, отказоустойчивость, масштабируемость и поддержка транзакционности.

Когда имеет смысл использовать Bagri

Систему хорошо использовать в первую очередь в тех случаях, когда документооборот основан на XML. Это финансы, логистика, страхование, медицина, и другие индустрии где формат документов, которыми обмениваются участники, строго определён корпоративными схемами XSD. Система позволяет не парсить каждый входящий документ, а класть его в базу как есть, а потом эффективно выполнять любые запросы над хранимыми документами используя мощный инструментарий XQuery 3.1.

Bagri построена поверх продуктов реализующих распределенный кэш, таких как Hazelcast, Coherence, Infinispan и других подобных систем. Именно за счет возможностей распределенного кэша Bagri поддерживает требования корпоративного сектора прямо из коробки. Распределенный кэш используется системой не только как хранилище данных, но и как распределенная система обработки этих данных, что позволяет эффективно и быстро обрабатывать любые большие объемы слабо структурированных данных. Транзакционность в системе решена с помощью алгоритма реализующего multi-version concurrency control

Продолжение предыдущих публикаций «Инструменты DataScience как альтернатива классической интеграции ИТ систем»,
«Экосистема R как инструмент для автоматизации бизнес-задач» и Джентельменский набор пакетов R для автоматизации бизнес-задач. Настоящая публикация преследует 2 цели:

1. Взглянуть на типичные задачи, которые встречаются в бизнесе, под немного другим углом.
2. Попробовать их решить, частично или полностью, с использованием средств, предоставляемых R.
   

Хабр, привет! 8-13 сентября команда New Professions Lab провела в Москве второй форум Data Science Week. Как и обещали, публикуем презентации наших спикеров:

Сегодня необходимо хотя бы в общих чертах иметь представление о мире big data. Мы отобрали публикации, в которых доступно объясняют, что такое большие данные и как их используют. Статьи рассчитаны, скорее, на новичков, но и люди, разбирающиеся в теме, смогут найти для себя интересные (или просто забавные) кейсы.

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

Apache Spark – универсальный инструмент для процессинга больших данных, с которым можно писать в Hadoop с различных СУБД, стримить всякие источники в реальном времени, параллельно делать с данными какую-нибудь сложную обработку, и все это не при помощи каких-то батчей, скриптов и SQL-запросов, а при помощи функционального подхода.


Про Spark ходит несколько мифов:

• Spark’y нужен Hadoop: не нужен!
• Spark’у нужна Scala: не обязательно!

Почему? Смотрите под катом.