Data Analysis / Big Data

Машинное обучение против кредитных рисков, или «давай, Джини, давай» Банк — это по определению «кредитно-денежная организация», и от того, насколько успешно эта организация выдает и возвращает кредиты, зависит ее будущее. Чтобы успешно работать с кредитами, нужно понимать финансовое положение заемщиков, в чем помогают факторы кредитного риска (ФКР). Кредитные аналитики выявляют их в огромных массивах банковской информации, обрабатывают эти факторы и прогнозируют дальнейшие изменения. Обычно для этого используется описательная и диагностическая аналитика, но мы решили подключить к работе инструменты машинного обучения. О том, что получилось, читайте в посте. Читать: https://habr.com/ru/companies/vtb/articles/417739/ #ru @big_data_analysis | Другие наши каналы

4 года Data Science в Schibsted Media Group В 2014-м году я присоединился к небольшой команде в Schibsted Media Group в качестве 6-го специалиста по Data Science в этой компании. С тех пор я поработал над многими начинаниями в области Data Science в организации, в которой теперь таких уже 40 с лишним человек. В этом посте я расскажу о некоторых вещах, о которых узнал за последние четыре года, сперва как специалист, а затем как менеджер Data Science. Этот пост следует примеру Robert Chang и его отличной статьи «Doing Data Science in Twitter», которую я нашел очень ценной, когда впервые прочитал ее в 2015-м году. Цель моего собственного вклада ― поведать настолько же полезные мысли специалистам и менеджерам Data Science по всему миру. Я поделил пост на две части: * Часть I: Data Science в реальной жизни * Часть II: Управление командой Data Science Читать: https://habr.com/ru/articles/417497/ #ru @big_data_analysis | Другие наши каналы

Как мы сделали систему, которая назначает клиентам скидки на основе индивидуальных характеристик В маркетинге есть хрестоматийные примеры: вероятность того, что человек вернется в магазин после второй покупки гораздо выше, чем после первой. Поэтому в MoneyMan (сервис онлайн-кредитования, входит в ID Finance) на второй заем действует скидка 30%, на третий – 10%, а на четвертый – всего 5%. Обычно к этому моменту лояльность клиента достигает максимума, и он начинает пользоваться сервисом по привычке. Самый большой дисконт (50%) мы даем клиентам, которые не пользовались сервисом 90 дней. Это точка невозврата для нашего бизнеса: без дополнительных стимулов только 1% от всех пользователей возвращается к сервису после такого срока. Читать: https://habr.com/ru/companies/idfinance/articles/417393/ #ru @big_data_analysis | Другие наши каналы

Капсульные нейронные сети В 2017 году Джеффри Хинтон (один из основоположников подхода обратного распространения ошибки) опубликовал статью, в которой описал капсульные нейронные сети и предложил алгоритм динамической маршрутизации между капсулами для обучения предложенной архитектуры. У классических свёрточных нейронных сетей есть недостатки. Внутреннее представление данных сверточной нейронной сети не учитывает пространственные иерархии между простыми и сложными объектами. Так, если на изображении в случайном порядке изображены глаза, нос и губы для свёрточной нейронной сети это явный признак наличия лица. А поворот объекта ухудшает качество распознавания, тогда, как человеческий мозг легко решает эту задачу. Для свёрточной нейронной сети 2 изображения схожи [2] Читать: https://habr.com/ru/articles/417223/ #ru @big_data_analysis | Другие наши каналы

Интеграция Spark Streaming и Kafka Здравствуйте, коллеги! Напоминаем, что не так давно у нас вышла книга о Spark, а прямо сейчас проходит последнюю корректуру книга о Kafka. Надеемся, эти книги окажутся достаточно успешными для продолжения темы — например, для перевода и издания литературы по Spark Streaming. Перевод об интеграции этой технологии с Kafka мы и хотели вам сегодня предложить Читать: https://habr.com/ru/companies/piter/articles/417123/ #ru @big_data_analysis | Другие наши каналы

Splunk How-to, или Как и где научиться Splunk В этой статье мы хотим поделиться с вами полезными материалами и ресурсами, с помощью которых можно научиться работать в Splunk. Понятно, что самый лучший опыт — это участие в проектах и набивание собственных шишек на практике, но все таки теория тоже важна. В этой статье мы расскажем как и где лучше изучать Splunk. Читать: https://habr.com/ru/companies/tssolution/articles/417065/ #ru @big_data_analysis | Другие наши каналы

С точностью до сотых: топ-10 докладов SmartData 2017 Зрители конференции SmartData — люди, которые любят работать с данными. Надо полагать, что и оценки докладам после прошлогодней конференции они выставляли очень вдумчиво. А теперь по этим оценкам мы составили топ-10 видеозаписей. И заодно, чтобы порадовать любителей данных, указали по каждому из десяти докладов все сопутствующие числа: место в топе, точный зрительский рейтинг, количество зрителей. Вообще говоря, зачастую у соседних позиций в топе рейтинги различаются незначительно. Так что, пожалуй, не стоит придавать много значения «кто идёт за кем» — важнее, что все эти доклады получили высокие оценки. Но с другой стороны, как же это не придавать много внимания числам, когда это так увлекательно! Читать: https://habr.com/ru/companies/jugru/articles/416985/ #ru @big_data_analysis | Другие наши каналы

RabbitMQ против Kafka: два разных подхода к обмену сообщениями В прошлых двух статьях мы рассказывали об IIoT — индустриальном интернете вещей — строили архитектуру, чтобы принимать данные от сенсоров, паяли сами сенсоры. Краеугольным камнем архитектур IIoT да и вообще любых архитектур работающих с BigData является потоковая обработка данных. В ее основе лежит концепция передачи сообщений и очередей. Стандартом работы с рассылкой сообщений сейчас стала Apache Kafka. Однако, для того, чтобы разобраться в ее преимуществах (и понять ее недостатки) было бы хорошо разобраться в основах работы систем очередей в целом, механизмах их работы, шаблонах использования и основной функциональности. Мы нашли отличную серию статей, которая сравнивает функциональность Apache Kafka и другого (незаслуженно игнорируемого) гиганта среди систем очередей — RabbitMQ. Эту серию статей мы перевели, снабдили своими комментариями и дополнили. Хотя серия и написана в декабре 2017 года, мир систем обмена сообщениями (и особенно Apache Kafka) меняется так быстро, что уже к лету 2018-го года некоторые вещи изменились. Читать: https://habr.com/ru/companies/itsumma/articles/416629/ #ru @big_data_analysis | Другие наши каналы

Чек-лист по анализу логов событий безопасности Сегодня тема мониторинга IT – инфраструктуры и анализа логов набирает все большую и большую популярность. В первую очередь все задумываются о мониторинге событий безопасности, о чем и будет идти речь в данной статье. Несмотря на то, что на эту тему сказано и написано уже довольно много, вопросов возникает еще больше. И поэтому мы решили сделать перевод статьи «Сritical Log Review Checklist for Security Incidents», написанную Anton Chuvakin и Lenny Zeltser, которая будет полезна как для тех, кто только начинает работать с мониторингом событий безопасности, так и для тех, кто имеет с этим дело довольно давно, чтобы еще раз проверить себя, не упускаете ли вы некоторые возможности. Читать: https://habr.com/ru/companies/tssolution/articles/416313/ #ru @big_data_analysis | Другие наши каналы

Откуда взялись нейросети и что происходит сейчас В последние несколько лет тема искусственного интеллекта активно обсуждается, так как один из подходов к ее изучению активно набирает обороты среди крупных корпораций. Этот подход – нейросети. Еще недавно, около года назад, это слово можно было услышать отовсюду. Сегодня рассмотрим историю изучения искусственного интеллекта человечеством (оказывается, ему уже около 2000 лет) и сегодняшние реалии. Читать: https://habr.com/ru/companies/microsoft/articles/416343/ #ru @big_data_analysis | Другие наши каналы

Распределенная обработка графов со Spark GraphX «Simplicity is prerequisite for reliability» by Edsger Dijkstra Пролог Графы — столь наглядная и проста для понимания структура данных, еще со времен Леонарда Эйлера заставляла ломать умы человечества над разнородными задачами, вроде того как можно пройти по всем семи мостам Кёнигсберга, не проходя ни по одному из них дважды или как разъездному посреднику, найти самый выгодный маршрут. Читать: https://habr.com/ru/articles/415939/ #ru @big_data_analysis | Другие наши каналы

Машинное зрение для ритейла. Как прочитать ценники в магазине Машинное зрение – очень актуальная тема в наши дни. Для решения задачи по распознаванию магазинных ценников с использованием нейронных сетей мы выбрали фреймворк TensorFlow. В статье пойдет речь именно о том, как с его помощью локализовать и идентифицировать несколько объектов на одном магазинном ценнике, а также распознать его содержимое. Похожая задача распознавания ценников IKEA уже решалась на Хабре с применением классических инструментов обработки изображений, доступных в библиотеке OpenCV. Отдельно хотелось бы отметить, что решение может работать как на платформе SAP HANA в связке с Tensorflow Serving, так и на SAP Cloud Platform. Задача распознавания цены товара актуальна и для покупателей, которые хотят «шарить» цены друг с другом и выбирать магазин для покупок, и для ритейлеров — они хотят узнавать про цены конкурентов в режиме реального времени. Хватит лирики – гоу в технику! Читать: https://habr.com/ru/companies/sap/articles/415657/ #ru @big_data_analysis | Другие наши каналы

Лицензионная политика Oracle выталкивает аналитику на Hadoop Крупный бизнес и кровавый энтерпрайз уже давно нашли замену взрослым рсубд на задачах DWH и аналитики. DWH массово движется в сторону DataLake и Hadoop. Выглядит, что и небольшим компаниям уже нет особого смысла запускать аналитику на серьезной рсубд. С ростом кол-ва ядер доступных даже небольшому бизнесу пытаться лицензировать полноценную редакцию взрослой субд типа Oracle смысла мало. Standard редакция Oracle хоть и лицензируется по сокетам, но при этом вырезан важнейший функционал. Во первых в standard редакции нет partitioning Читать: https://habr.com/ru/articles/415045/ #ru @big_data_analysis | Другие наши каналы

А нам все «вертикально» — СУБД Vertica Привет! Меня зовут Сергей, я работаю главным инженером в Сбертехе. В ИТ-сфере я примерно 10 лет, из которых 6 занимаюсь базами данных, ETL-процессами, DWH и всем, что связано с данными. В этом материале я расскажу о Vertica — аналитической и по-настоящему колоночной СУБД, которая эффективно сжимает, хранит, быстро отдает данные и отлично подходит в качестве big data решения. Читать: https://habr.com/ru/companies/sberbank/articles/414895/ #ru @big_data_analysis | Другие наши каналы

Распределенное хранилище данных в концепции Data Lake: установка CDH Продолжаем делиться опытом по организации хранилища данных, о котором начали рассказывать в предыдущем посте. На этот раз хотим поговорить о том, как мы решали задачи по установке CDH. Читать: https://habr.com/ru/companies/neoflex/articles/414831/ #ru @big_data_analysis | Другие наши каналы

Релиз mongodb 3.2 немного подробностей На днях вышел новый стабильный релиз mongodb. В этой версии был добавлен ряд нововведений таких как новый GUI для визуальной работы с mongodb, LEFT JOIN, валидация документа и т.д. некоторые из этих свойств мы и рассмотрим на небольших примерах ниже. * Частичный ( partial ) индекс * Валидация * Нововведения агрегационного фреймворка * Новые опции в утилитах импорта экспорта * Нововведения в CRUD * WiredTiger и fsyncLock * Новое GUI compass Читать: https://habr.com/ru/articles/192870/ #ru @big_data_analysis | Другие наши каналы

Hive vs Pig. На что мне столько ETL? Лучше день потерять, но потом за пять минут долететь (с) Привет коллеги. Хочу поделиться с вами соображениями о том, чем отличаются фреймворки Hive и Pig, входящие в экосистему Hadoop. По сути, это два очень похожих продукта, цель у которых одна — взять на себя всю техническую реализацию MapReduce, предоставив взамен возможность описывать процесс обработки данных на более абстрактном уровне. В этой статье мы увидим как выглядят выборки в этих двух системах, и попытаемся понять, в каких случаях надо использовать то или иное решение. Читать: https://habr.com/ru/articles/223217/ #ru @big_data_analysis | Другие наши каналы

Как мы запрос в 100 раз ускоряли, или не все хеш-функции одинаково плохи Мы разрабатываем базу данных. Однажны к нам обратилась компания, которая столкнулась со следующей задачей: Есть некоторое множество объектов, и некоторое множество тегов. Каждый объект может содержать несколько тегов. Какие-то теги очень редкие, а какие-то встречаются часто. Одному объекту один тег может быть сопоставлен несколько раз. Новые объекты, теги и связи между ними непрерывно добавляются. Задача — очень быстро отвечать на вопросы вида: «сколько есть объектов, у которых есть тег А или B, но нету тега С» и похожие. На такие запросы хотелось бы отвечать за десятые доли секунды, при этом не останавливая загрузку данных. Мы получили от них их данные вплоть до сегодняшнего дня, развернули тестовый кластер из четырех машин, и начали думать, как правильно распределить данные и как правильно представить задачу в виде SQL-запроса, чтобы получить максимальную производительность. В итоге решили, что запрос может иметь вид: SELECT COUNT(*) FROM ( SELECT object_id, (MAX(tag == A) OR MAX(tag == B)) AND MIN(tag != C) AS good FROM tags WHERE tag IN (A, B, C) GROUP BY object_id ) WHERE good == 1; Чтобы такой запрос выполнялся быстро, мы разбили данные между серверами кластера по object_id, а внутри каждого сервера отсортировали их по тегам. Таким образом сервер, выполняющий запрос, может отправить запрос без изменений на все сервера с данными, а затем просто сложить их результаты. На каждом сервере с данными для выполнения запроса достаточно найти строки для тегов A, B и C (а так как данные по тегу отсортированы, это быстрая операция), после чего выполнить запрос за один проход по этим строкам. Худший тег имеет несколько десятков миллионов объектов, несколько десятков миллионов строк обработать за десятые доли секунды видится возможным. Стоит отметить, что подзапрос содержит GROUP BY object_id. GROUP BY в данной ситуации можно выполнить несколькими способами, например, если данные после тега отсортированы по object_id, то можно выполнить что-то похожее на merge sort. В данной ситуации, однако, мы данные по object_id не отсортировали, и оптимизатор разумно решил, что для выполнения GROUP BY надо построить хеш-таблицу. Мы загрузили все данные в кластер, и запустили запрос. Запрос занял 25 секунд. Читать: https://habr.com/ru/articles/222565/ #ru @big_data_analysis | Другие наши каналы

Dell Fluid Cache for SAN: когда данные всегда под рукой Предпосылки возникновения технологии. Майер Амшель, основатель известной династии Ротшильдов, в кодексе для своих потомков упомянул, что тот кто владеет информацией, владеет миром. Столь важную для любой компании информацию мы черпаем из данных, которые сами по себе, находясь внутри БД не несут нам никакой пользы. Для этого данные нужно обработать, то есть предоставить приложению, например, из области бизнес-аналитики (Business Intelligence). В предыдущие десятилетия, когда объём данных, частота их изменений и количество обращений к ним оставались достаточно низкими, мы могли позволить себе хранить их на медленных носителях и волновались в основном за стоимость единицы хранения (доллар за мегабайт, гигабайт и так далее). Сегодня, в эпоху Big Data, когда успешными становятся те компании, которые быстрее других реагируют на рыночные изменения, важным становится не стоимость за гигабайт, а стоимость за быструю транзакцию или за потребителя этих быстрых транзакций. Читать: https://habr.com/ru/companies/dell_technologies/articles/222239/ #ru @big_data_analysis | Другие наши каналы

Долой оковы MongoDB Многие из нас в свое время бросились с энтузиазмом осваивать MongoDB, действительно красота — удобный JSON формат, гибкая схема (точнее полное ее отсутствие), от установки системы до первого использования проходят буквально минуты. Но через некоторое время, уже когда Mongo надежно «зашита» в наш проект наступает разочарование. Простейшие запросы требуют постоянного тыкания в документацию, чуть более сложные способны убить почти целый день рабочего времени, а уж если понадобится join разных коллекций — то увы… И вот уже кто-то возвращается к Постгресу с его частичной поддержкой JSON… Но, к счастью, уже куется, уже спешит к нам полноценная замена Mongo, полноценная полу-структурированная Big Data СУБД AsterixDB. Этот проект возглавляет профессор UCI Michael Carey, ученик легендарного пионера СУБД Майкла Стоунбрейкера. Проект стартовал просто как исследовательское начинание в области Big Data и изначально ориентировался на создание общего стэка для MapReduce и SQL. Но, буквально несколько лет назад, было принято решение построить Big Data JSON СУБД. По словам Майкла Кери, «AsterixDB is Mongo done right.» В чем же основные фишки AsterixDB? Читать: https://habr.com/ru/articles/222083/ #ru @big_data_analysis | Другие наши каналы