Peace, Хабр!

Последние дни много разговоров, что криптовалюта — способ: a) сберечь свои рублевые сбережения от обесценивания, b) вывести из под риска национализации валютные сбережения.

И действительно (хорошая новость): на текущий момент ограничений по покупке и хранению криптовалют для резидентов РФ нет. Ну почти нет. По сравнению с фиатными биржами — нет.

Но (плохие новости):

• Американские сенаторы уже обсуждают меры по ограничению использованию криптовалют для обхода санкций со стороны России [1],
• Евросоюз занят тем же самым [2],
• ФБР появилось подразделение по контролю за оборотом криптовалюты ([3], анонс от 17 февраля 2022, хотя межгосударственные финансовые дела вряд ли в их юрисдикции).

Еще хорошая новость (последняя):
Хрустальный шар/магический кристалл Гарри Поттер еще не подвез, поэтому сценарий с обходом санкций через криптовалютные переводы и с противостоянием этому обходу — это потенциальное будущее.

Снова плохая новость (не последняя):
Если Вам кажется, что риски в этом потенциальном будущем для Вас, как для частного инвестора, высокие, то Вам не кажется.

И что с этим делать?
Правильно — разобраться что, где, как (и надо ли) хранить условиях санкций.

Peace, Хабр!

Честно говоря, я долго думал, как бы потактичнее начать. Но ничего не придумал. Поэтому напишу прямо: я хочу, чтоб моя жена и ребенок ни в чем не нуждались. И у меня была уверенность, что могу им дать все, что потребуется: от любви до игрушечной железной дороги.

Сегодня пошел 8-ой день, как от этой уверенности почти ничего не осталось.

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

Hello, Habr!

About a month ago, I had a feeling of constant anxiety. I began to eat poorly, sleep even worse, and constantly read to a ton of news about the pandemic. Based on them, the coronavirus either captured, or liberated our planet, was either a conspiracy of world governments, or the vengeance of the pangolin, the virus either threatened everyone at once, or personally me and my sleeping cat…

Hundreds of articles, social media posts, youtube-telegram-instagram-tik-tok (yes, I sin) content of varying degrees of content quality did not lead me to anything but an even greater sense of anxiety.

But one day I bought buckwheat decided to end it all. As soon as possible!

Привет, Хабр! Где-то месяц назад у меня появилось чувство постоянного беспокойства. Я стал плохо есть, еще хуже спать и постоянно читать-смотреть-слушать тонну новостей о пандемии. Исходя из них коронавирус то ли захватывал, то ли освобождал нашу планету, являлся то ли заговором масонов мировых правительств, а то ли местью панголина, вирус то ли угрожал всем и сразу, а то ли персонально мне и моему коту…

Сотни статей, постов в соцсетях, youtube-telegram-instagram-tik-tok (да уж простите) контента разной степени содержательности (и сомнительности) не приводили меня ни к чему, кроме уже описанного на Хабре разрушения мозга и еще большему чувству беспокойства.

Но в один день я купил гречки решил со всем этим нужно покончить. Как можно скорее!

UPD: добавил секцию 'Результат'.

Нужно построить больше GPU

Deep Learning – одно из наиболее интенсивно развивающихся направлений в области машинного обучения. Успехи исследований в области глубокого (глубинного) обучения вызывают за собой рост количества ML/DL-фреймворков (в т.ч. и от Google, Microsoft, Facebook), имплементирующих данные алгоритмы. За все возрастающей вычислительной сложностью DL-алгоритмов, и, как следствие, за увеличивающейся сложностью DL-фреймворков уже давно не угоняются аппаратные мощности ни настольных, ни даже серверных CPUs.

Выход нашли, и он простой (кажется таким) – использовать для такого типа compute-intensive-задач расчеты на GPU/FPGA. Но и тут проблема: можно, конечно, для этих целей использовать видеокарту любимого ноутбука, но какой русский data scientist не любит быстрой езды NVidia Tesla?

Подходов к владению высокопроизводительными GPU минимум два: купить (on-premises) и арендовать (on-demand). Как накопить и купить – тема не этой статьи. В этой — мы рассмотрим, какие предложения есть по аренде инстансов VM c высокопроизводительными GPU у облачных провайдеров Amazon Web Service и Windows Azure.

Стандартный план любого хакатона ↓

R, один из популярнейших языков программирования среди data scientist'ов, получает все большую и большую поддержку как среди opensource-сообщества, так и среди частных компаний, которые традиционно являлись разработчиками проприетарных продуктов. Среди таких компаний – Microsoft, чья интенсивно увеличивающая поддержка языка R в своих продуктах/сервисах, привлекла к себе и мое внимание.

Одним из «локомотивов» интеграции R с продуктами Майкрософт является облачная платформа Microsoft Azure. Кроме того, появился отличный повод повнимательнее взглянуть на связку R + Azure – это проходящий в эти выходные (21-22 мая) хакатон по машинному обучению, организованный Microsoft.

Хакатон – мероприятие, где кофе время чрезвычайно ценный ресурс. В контексте этого я ранее писал о best practices обучения моделей в Azure Machine Learning. Но Azure ML – это не инструмент для прототипирования; это скорее сервис для создания продукта с SLA со всеми вытекающими отсюда затратами как на время разработки, так и на стоимость владения.

R же прекрасно подходит для создания прототипов, для копания (mining) в данных, для быстрой проверки своих гипотез – то есть
всего того, что нам нужно на такого типа соревнованиях! Ниже я расскажу, как использовать всю мощь R в Azure – от создания прототипа до публикации готовой модели в Azure Machine Learning.

Стандартный план любого хакатона ↓



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

Повествование в этой статье будет проходить в такой же стремительной манере, в какой, как я полагаю, для большинства участников и пройдет хакатон. Никакой воды (если вы не знакомы с Azure ML, то «воду» или какой-то ознакомительный материал лучше все-таки почитать), долгих определений и таких длинных вступлений как это — только то, что вам нужно, чтобы победить на хакатоне.

В заключительной четвертой части статьи подробно обсудим наиболее сложную с технической точки зрения часть antifraud-сервиса – аналитическую систему распознания мошеннических платежей по банковским картам.

Выявление различного рода мошенничеств является типичным кейсом для задач обучения с учителем (supervised learning), поэтому аналитическая часть антифрод-сервиса, в соответствии с лучшими отраслевыми практиками, будет построена с использованием алгоритмов машинного обучения.

Для стоящей перед нами задачи воспользуемся Azure Machine Learning – облачным сервисом выполнения задач прогнозной аналитики (predictive analytics). Для понимания статьи будут необходимы базовые знания в области машинного обучения и знакомство с сервисом Azure Machine Learning.

Цель

В этой части я опишу проект, на первом шаге которого мы обучим четыре модели, используя логистическую регрессию, персептрон, метод опорных векторов и дерево решений. Из обученных моделей выберем ту, которая дает большую точность на тестовой выборке и опубликуем ее в виде REST/JSON-сервиса. Далее для полученного сервиса напишем программного клиента и проведем нагрузочное тестирование на REST-сервис.

Это третья часть эксперимента по созданию системы распознания мошеннических платежей (antifraud-система). Целью является создание доступного (в плане стоимости разработки и владения) antifraud-сервиса, который позволит сразу нескольким участникам проведения online-платежей – мерчантам, агрегаторам, платежным системам, банкам – снизить риски проведения мошеннических платежей (fraud) через их площадки.

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

В первой части эксперимента было описано, почему проблема мошеннических платежей (fraud) стоит остро перед всеми участниками рынка online-платежей, какие сложности на пути создания собственной системы мониторинга мошеннических платежей (antifraud-системы) предстоит преодолеть, и почему для большинства мерчантов такие системы – дорогое удовольствие, за которое они не всегда готовы платить.

Еще одно, усложняющее разработку подобных систем, обстоятельство — то, что antifraud-система является business-critical системой и ее простой будет вести либо к остановке бизнес-процесса (приема оплаты), либо при некорректной работе системы к увеличению рисков финансовых и репутационных потерь для компании (интернет-магазина, банка).

Поэтому практики и подходы, перечисленные в статье применимы не только на стороне мерчанта, но на стороне других участников интернет-эквайринга – агрегаторов, платежных систем, банков. Более того, перечисленные в статье подходы зачастую являются закрытыми от сообщества best practices в соответствующих организациях.

В этой части будут описаны требования к antifraud-системе, чье влияние на программную архитектуру является существенным.

Эта статья представляет собой описание эксперимента по созданию системы обнаружения мошеннических платежей по банковским картам.

В первой части статьи я расскажу почему вопрос мошеннических платежей (fraud) стоит так остро для всех участников рынка электронных платежей – от интернет-магазинов до банков – и в чем основные сложности, из-за которых стоимость разработки таких систем подчас является слишком высокой для многих участников ecommerce-рынка.

Во второй части будут описаны требования технического и нетехнического характера, которые предъявляются к таким системам, и то, как я собираюсь снизить стоимость разработки и владения antifraud-системы на порядок(и).

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

В четвертой части статьи подробно обсудим наиболее сложную с технической точки зрения и наиболее интеллектуальную часть системы – аналитическую систему распознания мошеннических платежей.

Get Started!

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

Не менее интенсивно растет количество мошеннических операций и разнообразие видов мошенничества. Россия, наряду с Англией, Францией, Германией, Испанией, входит в топ-5 европейский стран по годовому объему мошеннических операций с банковским картами. Общий объем потерь от мошенничества по картам в 2013 году в Европе превысило 1 млрд. евро. На Россию приходится 110 млн. евро, из них 2,4 млн. евро мошенничество при оплате через интернет.

Полная цепочка участников проведения online-платежа при покупке товара/услуги через интернет в общем случае выглядит приблизительно так:

Около полугода назад я публиковал ретроспективу того, что интересного для исследователей происходит в облаке Microsoft Azure.

Продолжу эту тему, немного сместив акцент в области, которые для меня последние пару лет неизменно остаются наиболее интересными в ИТ: Big Data, машинное обучение и их симбиозом с облачными технологиями.

Ниже обсудим преимущественно октябрьские анонсы сервисов Microsoft Azure, предоставляющих возможность пакетной и real-time обработки больших массивов данных, высокопроизводительный кластер по требованию, широкую поддержку алгоритмов машинного обучения.

Photon – масштабируемая, отказоустойчивая и географически распределенная система обработки потоковых данных в режиме реального времени. Система является внутренним продуктом Google и используется в Google Advertising System. Research paper [5], описывающие базовые принципы и архитектуру Photon, был представлен на научной конференции ACM SIGMOD в 2013 году.

В paper [5] заявлено, что пиковая нагрузка на систему может составлять миллионы событий в минуту со средней end-to-end задержкой менее 10 секунд.
* 'Скорость света' в заголовке — наглая ложь гипербола.

Dremel – масштабируемая система обработки запросов в режиме близком к режиму реального времени (near-real-time), предназначенная для анализа неизменяемых данных [4].

Авторы research paper [4] (среди которых, судя по всему, и наши соотечественники — Сергей Мельник и Андрей Губарев), в котором описываются базовые принципы и архитектура Dremel, заявляют, что система в силах:

• выполнять агрегирующие запросы над боле чем над триллионом строк за секунды;
  
• масштабируется на тысячи CPU;
  
• предназначена для работы с петабайтами данных;
  
• имеет тысячи пользователей внутри Google (дословно «at Google» [4]).
  

UPD1: ниже картинка-дежавю для внимательных читателей.

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 позволяет системе масштабироваться на миллионы вычислительных узлов через сотни дата-центров и работать с триллионами строк данных.

Colossus (или GFS2) – это проприетарная распределенная файловая система от Google, запущенная на production-серверах в 2009 году. Colossus является эволюционным развитием GFS. Как и ее предшественник GFS, Colossus оптимизирована для работы с большими наборами данных, прекрасно масштабируется, является высокодоступной и отказоустойчивой системой, а также позволяет надежно хранить данные.

В то же время, Colossus решает часть задач, с которыми GFS не справлялась, и устраняет некоторые узкие места предшественника.

Хранение и обработка данных – задача, которую человечество с переменным успехом решает ни одну тысячу лет. Проблемы, связанные с решением этой задачи, связаны не только с физическим объемом данных (volume), но и со скоростью изменчивости этих данных (velocity) и многообразием (variety) источников данных – то, что аналитики Gartner в своих статьях [11, 12] обозначили как «3V».

Computer Science не так давно столкнулась с проблемой Больших Данных, решения которой от ИТ ждут частные компании, правительства, научное сообщество.

И в мире уже появилась компания, которая, с переменным успехом, справляется с проблемой Big Data вот уже 10 лет. По моему ощущению (т.к. чтобы заявить достоверно нужны открытые данные, которых в свободном доступе нет) ни одна коммерческая или некоммерческая организация не оперирует большим объемом данных, чем компания, о которой идет речь.

Именно эта компания являлась основным контрибьютором идей платформы Hadoop, а также многих компонентов экосистемы Hadoop, таких как HBase, Apache Giraph, Apache Drill.

Как Вы догадались, речь идет о Google.

За последние пол месяца произошло 3 ИТ-события, лежащие в плоскости Big Data, Cloud Computing и на их симбиозе. По странному стечению обстоятельств эти события остались без должного внимания как со стороны хабросообщества, так и со стороны немногочисленных профессиональных сетевых сообществ в LinkedIn и Facebook.

События, о которых идет речь — конференция «Strata + Hadoop World», релиз стабильной версии Hadoop 2.2.0 и облачного сервиса Windows Azure HDInsight. О косвенной и прямой взаимосвязи этих событий речь и пойдет ниже.

UPD: сменил заголовок статьи, т.к. прошлый заголовок я написал, пока был лунатиком (шутка, разумеется).

На прошлой неделе на Хабре появилось 2 поста о фреймворке распределенных вычислений от Microsoft Research – Dryad. В частности, подробно были описаны концепции и архитектура ключевых компонентов Dryad – среды исполнения Dryad и языка запросов DryadLINQ.

Логическим завершением цикла статей о Dryad видится сравнение фреймворка Dryad с другими, знакомыми разработчикам MPP-приложений, инструментами: реляционными СУБД (в т.ч. параллельными), GPU-вычислениями и платформой Hadoop.

Предметом внимания вчерашнего поста на Хабре стал фреймворк распределенных вычислений от Microsoft Research — Dryad.

В основе фреймворка лежит представление задания, как направленного ациклического графа, где вершины графа представляют собой программы, а ребра — каналы, по которым данные передаются. Также обзорно была рассмотрена экосистема фреймворка Dryad и сделан подробный обзор архитектуры одного из центральных компонентов экосистемы фреймворка – среды исполнения распределенных приложений Dryad.

В этой статье обсудим компонент верхнего уровня программного стэка фреймворка Dryad – язык запросов к распределенному хранилищу DryadLINQ.