Всем привет!
Спешу поделиться материалами с выступления на конференции Microsoft DevCon School, которая проходила 1 ноября на территории центра Digital October.
Сейчас выложу только слайды, но постепенно дополню отчет и другими материалами с конференции.
UPD [13.11.2016]: опубликован исходный код demo-задач, решаемых на интенсиве по R.
R, один из популярнейших языков программирования среди data scientist'ов, получает все большую и большую поддержку как среди opensource-сообщества, так и среди частных компаний, которые традиционно являлись разработчиками проприетарных продуктов. Среди таких компаний – Microsoft, чья интенсивно увеличивающая поддержка языка R в своих продуктах/сервисах, привлекла к себе и мое внимание.
Одним из «локомотивов» интеграции R с продуктами Майкрософт является облачная платформа Microsoft Azure. Кроме того, появился отличный повод повнимательнее взглянуть на связку R + Azure – это проходящий в эти выходные (21-22 мая) хакатон по машинному обучению, организованный Microsoft [1].
В прошлой части я озвучил 3 тезиса:
Azure Machine Learning (Azure ML) – облачный сервис для выполнения задач, связанных с машинным обучением. Почти наверняка Azure ML будет центральным сервисом, которым вы будете пользоваться, в случае, если захотите обучить модель, в облаке Azure.
Подробный рассказ про Azure ML не входит в цели данного поста, в тем более, что о сервисе уже достаточно написано: Azure ML для data scientist’ов [3], best practices обучения модели в Azure ML [4]. Сконцентрируемся на следующей задаче: организация командной работы с максимально безболезненным переносом R-скриптов с локального компьютера в Azure ML Studio.
R, один из популярнейших языков программирования среди data scientist'ов, получает все большую и большую поддержку как среди opensource-сообщества, так и среди частных компаний, которые традиционно являлись разработчиками проприетарных продуктов. Среди таких компаний – Microsoft, чья интенсивно увеличивающая поддержка языка R в своих продуктах/сервисах, привлекла к себе и мое внимание.
Одним из «локомотивов» интеграции R с продуктами Майкрософт является облачная платформа Microsoft Azure. Кроме того, появился отличный повод повнимательнее взглянуть на связку R + Azure – это проходящий в эти выходные (21-22 мая) хакатон по машинному обучению, организованный Microsoft [1].
Хакатон – мероприятие, где кофе время чрезвычайно ценный ресурс. В контексте этого я ранее писал о
best practices обучения моделей в Azure Machine Learning.
Но Azure ML – это не лучший инструмент для прототипирования; это скорее сервис для создания готового продукта со всеми вытекающими отсюда затратами как на время разработки, так и на стоимость владения.
R же прекрасно подходит для создания прототипов, для копания (mining) в данных, быстрой проверки своих гипотез – то есть всего того, что нам нужно на такого типа соревнованиях! Ниже я расскажу, как использовать всю мощь R в Azure – от создания прототипа до публикации готовой модели в Azure Machine Learning.
Прошлая неделя [c 28.03.2016 по 03.04.2016] была насыщена новостями о новинках/изменениях как в облачной платформе Azure, в частности, так и технологиях/продуктах Microsoft, в общем. Те, кто следит за новостями, знают, что такой всплеск связан с только что прошедшими конференциями «Strata + Hadoop World» и «//Build 2016».
Изменений настолько много, что, не приложив серьезных усилий, довольно сложно понять, какие перспективы открывают новинки как для увеличения эффективности существующих решений, так и для создания чего-то революционно нового.
Ниже я сделаю обзор изменений по темам, которые вызывают у меня наибольший профессиональный интерес – Data Platform и Data Science.
Hello!
I want to share with IT community the materials from my presentation at the Moscow Data Fest conference. To begin, I will publish only slides of my speech. Then, as the opportunity arises, I will upload a video of presentation.
The presentation focused on cloud-based service of predictive analytic - Azure Machine Learning.
I will describe concepts and principles underlying Azure ML, as well as talk about how Azure ML can help data scientists to perform classification, clustering, sentiment analysis algorithms in Big Data-ready and LSML fashion.
По оценке компании McKinsey финансовая индустрия владеет до 25% данных, имеющихся в мире. Из них банки США хранят >1 экзабайта данных (McKinsey, 2013), объем данных российского банковского сектора оценивается в >100 терабайт (IBS, 2013).
Традиционно, используя имеющиеся данные, розничные банки на разных уровнях управления решают задачи:
Перед современным банком по каждой из перечисленных задач стоит целый ряд проблем. Опишем их тезисно ниже.
Клиентоориентированность
Клиенты банков становятся все более и более требовательными как к банковскому сервису, так и к банковским продуктам.
Клиентам уже не нужна «просто пластиковая карта». Клиентам нужен составной продукт, который позволит им покупать товары (offline и online);
продукт, с постоянным и удобным доступом (со смартфона, планшета, домашнего ПК); продукт, который позволит экономить средства (скидки по карте, cashback, бонусы).
Управление рисками
Модели расчет банковских рисков, скоринговые модели все более и более усложняются, одновременно со сложностью моделей (качественной сложностью) растет и объем анализируемых данных (количественная сложность).
А все увеличивающееся разнообразие способов оплаты (mPOS, мобильные платежи) и количество получателей платежей открывает все новые и новые фронты
борьбы с мошенничеством.
Оптимизация операционных затрат
Увеличение конкуренции как со стороны виртуальных банков, так и со стороны стартапов, предоставляющих финансовые сервисы
(P2P-кредитование, агрегаторы банковских счетов), вынуждают игроков на рынке банковских услуг снижать маржинальность многих банковских продуктов.
В такой ситуации «полноценным» банкам важно уменьшать операционные издержки.
Общая проблема: обработка данных
Все возрастающие объемы как внутренних данных банка (профили клиентов, журнал финансовых операций и т.д.),
так и внешних данных (данные НБКИ, отзывы в социальных сетях и т.д.) требует от банка качественно новых подходов к хранению и обработке данных.
Это лишь поверхностный список проблем, с которыми банковский сектор уже столкнулся.
Ниже мы рассмотрим практические банковские кейсы, которые решают разные части этих (и не только) проблем, а также как симбиоз концепций Больших Данных и методов машинного обучения позволяет эти проблемы решать.
Около полугода назад я публиковал ретроспективу того, что интересного для исследователей происходит в облаке Microsoft Azure.
Продолжу эту тему, немного сместив акцент в области, которые для меня последние пару лет неизменно остаются наиболее интересными в ИТ: Big Data, машинное обучение и их симбиозом с облачными технологиями.
Ниже обсудим преимущественно октябрьские анонсы сервисов Microsoft Azure, предоставляющих возможность пакетной и real-time обработки больших массивов данных, высокопроизводительный кластер по требованию, широкую поддержку алгоритмов машинного обучения.
Ценность данных падает во времени. В некоторых системах ценность данных во времени падает драматически. К кейсам с такими характеристиками традиционно относят:
Для всех этих задач latency является одним из ключевых требований к работе разрабатываемого ПО.
В этой статье обсудим фреймворки/платформы, предоставляющие разработчикам инструменты работы с Большими Данными в real-time- или near-real-time-режиме.
Статья из цикла «Google Platform»
Photon – масштабируемая, отказоустойчивая и географически распределенная система обработки потоковых данных в режиме реального времени. Система является внутренним продуктом Google и используется в Google Advertising System. Research paper [5], описывающие базовые принципы и архитектуру Photon, был представлен на научной конференции ACM SIGMOD в 2013 году.
В research paper [5] заявлено, что пиковая нагрузка на систему может составлять миллионы событий в минуту со средней end-to-end задержкой менее 10 секунд.
Статья из цикла «Google Platform»
Dremel – масштабируемая система обработки запросов в режиме близком к режиму реального времени (near-real-time), предназначенная для анализа неизменяемых данных [4].
Авторы research paper [4] (среди которых, судя по всему, и наши соотечественники - Сергей Мельник и Андрей Губарев), в котором описываются базовые принципы и архитектура Dremel, заявляют, что система в силах:
Статья из цикла «Google Platform»
Spanner – географически распределенная высокомасштабируемая мультиверсионная база данных с поддержкой распределенных транзакций. База данных была разработана инженерами Google для внутренних сервисов корпорации. Research paper [8], описывающие базовые принципы и архитектуру Spanner, был представлен на научной конференции 10th USENIX Symposium on Operating Systems Design and Implementation в 2012 году.
Spanner является эволюционным развитием NoSQL-предшественника – Google Bigtable. Сам же c Spanner относят к семейству NewSQL-решений. В research paper [8] заявляется, что дизайн Spanner позволяет системе масштабироваться на миллионы вычислительных узлов через сотни дата-центров и работать с триллионами строк данных.
Статья из цикла «Google Platform»
Colossus (или GFS2) – это проприетарная распределенная файловая система от Google, запущенная в production-режиме в 2009 году. Colossus является эволюционным развитием GFS. Как и ее предшественник GFS, Colossus оптимизирована для работы с большими наборами данных, прекрасно масштабируется, является высокодоступной и отказоустойчивой системой, а также позволяет надежно хранить данные.
В то же время, Colossus решает часть задач, с которыми GFS не справлялась, и устраняет некоторые узкие места предшественника.
Статья из цикла «Google Platform»
MapReduce – это программная модель, описанная инженерами Google в research paper [2], и ассоциированная с этой программной моделью реализация (фреймворк), позволяющий обрабатывать большие объемы данных распределено.
В простейшем случае в программной модели MapReduce выделяют 2 фазы:
Статья из цикла «Google Platform»
Bigtable – высокопроизводительная база данных, реализующая колоночную схему хранения и построенная на основе GFS и некоторых других внутренних продуктах Google. Как и GFS, Bigtable – проприетарная система, внутреннее устройство которой, тем не менее, было подробно описано инженерами Google в research paper [3].
Bigtable – хорошо масштабирующееся хранилище данных, рассчитанное на хранение петабайтов информации и работающее на commodity-серверах. Bigtable работает на production-серверах с 2005 года. В разное время в BigTable хранили данные web-индексов, сервисов Google Analytics, Google Earth, Google Finance [3].
Статья из цикла «Google Platform»
Google File System (GFS) – распределенная файловая система (ФС) Google. Система является проприетарной, по некоторым сведениям работа над GFS была начата еще в 2000 году; общие принципы построения были довольно подробно описаны в документе [1], представленном на ACM SIGOPS Operating Systems Review в 2003 году.
Вводная статья цикла «Google Platform»
Хранение и обработка данных – это задача, которую человечество с переменным успехом решает ни одну тысячу лет. Проблемы, связанные с решением этой задачи, связаны не только с физическим объемом данных (volume), но и со скоростью изменчивости этих данных (velocity) и многообразием (variety) источников данных – то, что аналитики Gartner в своих статьях [11, 12] обозначили как «3V».
Количественные изменения в системе неизменно переходят в качественные [13]. Изобретение письменности, книгопечатанье, автоматизированные средства обработки данных разумно рассматривать, как ответ на вызов, который ставит проблема 3V.
Современная Computer Science сейчас встретилась с проблемой Больших данных, решения которой от ИТ ждут частные компании, правительства, научное сообщество (которое не занято в computer science).
Но в мире есть одна компания, которая встретилась с проблемой Big Data еще порядка 10 лет назад. По моему ощущению (т.к. чтобы заявить достоверно нужны открытые данные, которых в свободном доступе нет) ни одна коммерческая или некоммерческая организация не оперирует большим объемом данных, чем эта компании.
Именно эта компания являлась основным контрибьютором идей платформы Hadoop, а также многих компонентов экосистемы Hadoop, таких как HBase, Apache Giraph, Apache Drill.
Как Вы догадались, речь идет о Google.
За последние пол месяца произошло три ИТ-события, лежащие в плоскости Big Data, Cloud Computing и на их симбиозе. По странному стечению обстоятельств эти события остались без должного внимания как со стороны хабросообщества, так и со стороны немногочисленных профессиональных сетевых сообществ в LinkedIn и Facebook.
События, о которых идет речь — конференция «Strata + Hadoop World», релиз стабильной версии Hadoop 2.2.0 и облачного сервиса Windows Azure HDInsight. О косвенной и прямой взаимосвязи этих событий речь и пойдет ниже.
В июне 2011 года было опубликовано исследование, проведенное аналитическим агентством IDC по заказу компании EMC, согласно которому объем информации в мире увеличивается более чем в два раза каждые два года. Согласно этому исследованию, в 2011 году будет создано и реплицировано 1,8 зеттабайт данных – быстрее, чем по закону Мура.
Объем данных генерируемый и собираемый современными научно-исследовательским центрами, финансовыми институтами, социальными сетями действительно огромен. В дата-центрах Facebook уже хранится более 15 млрд. изображений, нью-йоркская фондовая биржа NYSE создает и реплицирует ежедневно около 1 Тб данных, большой адронный коллайдер генерирует около 40 Тб экспериментальных данных в день.
Представьте себе фреймворк общего назначения для распределенного исполнения приложений со следующими статистическими показателями (статистические данные за 2011 год):
А теперь представьте, что это не Hadoop.
О том, что это за фреймворк, о идеях и концепциях, заложенных в его основу и о том, почему этот фреймворк более инновационный (субъективно), чем Hadoop, речь пойдет в цикле статей (о нем ниже).
Третья статья из цикла статей «Dryad. Big Data от Microsoft»
В первых двух статьях цикла «Dryad. Big Data от Microsoft» был рассмотрен фреймворк распределенных вычислений от Microsoft – Dryad. В частности, подробно были описаны концепции и архитектура ключевых компонентов Dryad – среды исполнения Dryad и языка запросов DryadLINQ.
В третьей заключительной части цикла будет проведено сравнение фреймворка Dryad с другими MPP «инструментами» – реляционными СУБД, GPU-вычислениями и платформой Hadoop.
