Привет Хабр! RBKmoney снова выходит на связь и продолжает цикл статей о том, как написать платежный процессинг своими руками.

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

Социальные сети — это один из наиболее востребованных на сегодняшний день интернет-продуктов и один из основных источников данных для анализа. Внутри же самих социальных сетей самой сложной и интересной задачей в сфере data science по праву считается формирование ленты новостей. Ведь для удовлетворения всё возрастающих требований пользователя к качеству и релевантности контента необходимо научиться собирать информацию из многих источников, вычислять прогноз реакции пользователя и балансировать между десятками конкурирующих метрик в А/Б-тесте. А большие объемы данных, высокие нагрузки и жесткие требования к скорости ответа делают задачу ещё интереснее.

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

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

Из каких деталей построена наша система:

• детектор и классификатор одежды, обуви и сумок на изображениях;
• краулер, индексатор или модуль работы с электронными каталогами магазинов;
• модуль поиска похожих изображений;
• JSON-API для удобного взаимодействия с любым устройством и сервисом;
• веб-интерфейс или мобильное приложение для просмотра результатов.

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

Постановка задачи и создание рубрикатора

Задача и основной use-case системы звучит довольно просто и понятно:

• пользователь подает на вход (например, посредством мобильного приложения) фотографию, на которой присутствуют предметы одежды и/или сумки и/или обувь;
• система определяет (детектирует) все эти предметы;
• находит к каждому из них максимально похожие (релевантные) товары в реальных интернет-магазинах;
• выдает пользователю товары с возможностью перейти на конкретную страницу товара для покупки.

Говоря проще, цель нашей системы — ответить на знаменитый вопрос: “А у вас нет такого же, только с перламутровыми пуговицами?”

GitHub использует MySQL в качестве основного хранилища данных для всего, что не связано с git, поэтому доступность MySQL имеет ключевое значение для нормальной работы GitHub. Сам сайт, интерфейс API на GitHub, система аутентификации и многие другие функции требуют доступа к базам данных. Мы используем несколько кластеров MySQL для обработки различных служб и задач. Они настроены по классической схеме с одним главным узлом, доступным для записи, и его репликами. Реплики (остальные узлы кластера) асинхронно воспроизводят изменения главного узла и обеспечивают доступ для чтения.

Доступность главных узлов критически важна. Без главного узла кластер не поддерживает запись, а это значит, что нельзя сохранить необходимые изменения. Фиксация транзакций, регистрация проблем, создание новых пользователей, репозиториев, обзоров и многое другое будет просто невозможно.

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

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

В начале года мы решили научиться хранить и читать отладочные логи ВКонтакте более эффективно, чем раньше. Отладочные логи — это, к примеру, логи конвертации видео (в основном вывод команды ffmpeg и список шагов по предварительной обработке файлов), которые иногда бывают нам нужны лишь спустя 2-3 месяца после обработки проблемного файла.

На тот момент у нас было 2 способа хранения и обработки логов — наш собственный logs engine и rsyslog, которые мы использовали параллельно. Стали рассматривать другие варианты и поняли, что нам вполне подходит ClickHouse от Яндекса — решили его внедрять.

В этой статье я расскажу о том, как мы начали использовать ClickHouse ВКонтакте, на какие грабли при этом наступили, и что такое KittenHouse и LightHouse. Оба продукта выложены в open-source, ссылки в конце статьи.

Всем привет! В своей прошлой статье я писал об организации модульной системы мониторинга для микросервисной архитектуры. Ничего не стоит на месте, наш проект постоянно растёт, и количество хранимых метрик — тоже. Как мы организовали переход с Graphite+Whisper на Graphite+ClickHouse в условиях высоких нагрузок, об ожиданиях от него и результатах миграции читайте под катом.

С чего все началось

Все началось с Эппл Маркета — я обнаружил, что у них есть программа, позволяющая определить спелость арбуза. Программа… странная. Чего стоит, хотя бы, предложение постучать по арбузу не костяшками пальцев, а… телефоном! Тем не менее, мне захотелось повторить это достижение на более привычной платформе Андроид.

У Grafana есть возможность показывать статус, у Grafana есть возможность показывать данные во времени. Однако, как это ни парадоксально, у Grafana до настоящего момента не было удобного способа показывать статус во времени!

Мы представляем свой плагин — Statusmap panel. Он позволяет наглядно отобразить состояния набора объектов за выбранный промежуток времени. В качестве примера, демонстрирующего работу плагина, представим себе множество локаций, в которых для кого-то готовят кофе:


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

Выглядит интересно? Но начнём с того, как мы вообще к этому пришли.

Зачем еще одно руководство?

Когда передо мной поставили задачу сделать черновой вариант push notifications, быстрый поиск показал, что на хабре уже есть много статей по настройке push notifications. Вот наиболее, на мой взгляд, годные:

Как работает JS: веб push-уведомления
Web PUSH Notifications быстро и просто924/
Service Workers. Web Push и где они обитают

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

Настройка уведомлений в итоге заняла три дня и мне кажется, что это несколько многовато. Надеюсь, моя статья поможет кому-то настроить push notifications за три часа вместо трех дней.
Проект, на котором я работаю, реализован на Django и описывать ход работы я буду применительно к этому фреймворку, но желающие легко адаптируют его к Flask или чему-либо еще.

Итак, погнали.

Недавно LINBIT выпустили свое новое решение для оркестрации и управления множеством DRBD-массивов.

К примеру у вас может быть несколько нод и у каждой будет собственный LVM или ZFS пул в котором LINSTOR будет автоматически создавать новые тома и реплицировать их между нодами используя DRBD-протокол.

LINSTOR поддерживает thin-provisioning, снапшоты и много других интересных штук.
Это решение хорошо подойдет для виртуальных машин и контейнеров.

Каждый день пользователи совершают миллионы действий в интернете. Проекту FACETz DMP необходимо структурировать эти данные и проводить сегментацию для выявления предпочтений пользователей. В материале мы расскажем о том, как команда сегментировала аудиторию в 600 миллионов человек, обрабатывала 5 миллиардов событий ежедневно и работала со статистикой, используя Kafka и HBase.



В основе материала — расшифровка доклада Артема Маринова, специалиста по большим данным в компании Directual, c конференции SmartData 2017.

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


Материал подготовлен на основе выступления Пола Стека (Paul Stack) на нашей осенней конференции DevOops 2017. Пол — инфраструктурный разработчик, который раньше работал в HashiCorp и участвовал в разработке инструментов, используемых миллионами людей (например, Terraform). Он часто выступает на конференциях и доносит практику с переднего края внедрений CI/CD, принципы правильной организации operations-части и умеет доходчиво рассказать, зачем вообще админам этим заниматься. Далее в статье повествование ведется от первого лица.

В данной статье приводится доступный теоретический обзор сверточных нейронных сетей (Convolutional Neural Network, CNN) и разъясняется их применение к задаче классификации изображений.

Это реальная история. События, о которых рассказывается в посте, произошли в одной теплой стране в 21ом веке. На всякий случай имена персонажей были изменены. Из уважения к профессии всё рассказано так, как было на самом деле.

Привет, Хабр. В этом посте речь пойдет про пресловутое А/Б тестирование, к сожалению даже в 21ом веке его не избежать. В онлайне уже давно существуют и процветают альтернативные варианты тестирования, в то время, как в офлайне приходится адаптироваться по ситуации. Об одной такой адаптации в массовом офлайн ритейле мы и поговорим, приправив историю опытом взаимодействия с одной топовой консалтинговой конторой, в общем го под кат.

Перевод How Machines Make Sense of Big Data: an Introduction to Clustering Algorithms.

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

В мире энтерпрайза наступило пресыщение фронтовыми системами, шинами данных и прочими классическими системами, которые внедряли все кому не лень последние 10-15 лет. Но есть один сегмент, который до недавнего времени был в статусе «все хотят, но никто не знает, что это». И это Big Data. Красиво звучит, продвигается топовыми западными компаниями – как не стать лакомым кусочком?



Но пока большинство только смотрит и приценивается, некоторые компании начали активно внедрять решения на базе этого технологического стека в свой IT ландшафт. Важную роль в этом сыграло появление коммерческих дистрибутивов Apache Hadoop, разработчики которых обеспечивают своим клиентам техническую поддержку. Ощутив необходимость в подобном решении, один из наших клиентов принял решение об организации распределенного хранилища данных в концепции Data Lake на базе Apache Hadoop.

Принципы SOLID — это стандарт программирования, который все разработчики должны хорошо понимать, чтобы избегать создания плохой архитектуры. Этот стандарт широко используется в ООП. Если применять его правильно, он делает код более расширяемым, логичным и читабельным. Когда разработчик создаёт приложение, руководствуясь плохой архитектурой, код получается негибким, даже небольшие изменения в нём могут привести к багам. Поэтому нужно следовать принципам SOLID.

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

Чтобы понять принципы SOLID, нужно чётко понимать, как использовать интерфейсы. Если у вас такого понимания нет, то сначала почитайте документацию.

Я буду объяснять SOLID самым простым способом, так что новичкам легче будет разобраться. Будем рассматривать принципы один за другим.

Если вы прочитаете документацию по PHP, вы узнаете о массе операторов. Если вы не знаете ещё PHP-операторы, сперва изучите их, а потом вернитесь к прочтению этой статьи.

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

Примечание: рекомендации рассчитаны на Google Kubernetes Engine. Если вы работаете в другом облаке, на собственном сервере, на миникубе или чем-то еще, будут отличия. Я не углубляюсь в технические детали. Если хотите подробностей, обратитесь к официальной документации.

Всем привет! Я тимлид проекта Рамблер/топ-100. Это лонгрид о том, как мы проектировали архитектуру обновлённого сервиса веб-аналитики, с какими сложностями столкнулись по пути и как с ними боролись. Если вам интересны такие базворды как Clickhouse, Aerospike, Spark, добро пожаловать под кат.