Александр Крижановский ( krizhanovsky, NatSys Lab.)

По Сети уже давно бегает эта картинка, по крайней мере, я ее часто видел на Фейсбуке, и появилась идея рассказать про нее:

Действующие лица (Команда): разработчиков – 2 человека, админ – 1 человек.

Статья повествует об использовании таких технологий, как Ansible, Docker Swarm, Jenkins и Portainer для реализации CI/CD-пайплайна с возможностью контроля за ним с помощью красивого веб-интерфейса.

Вступление

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

С другой стороны, есть бизнес, который хочет денег, да побольше, и поэтому постоянно думает о снижении времени вывода продукта на рынок. Другими словами, бизнес мечтает об ускорении получения MVP (a.k.a. Minimum Viable Product) в новых продуктах или при обновлении существующих.

Ну а чего же хочет админ? А админ – человек простой, он хочет, чтобы сервис не падал и не мешал играть в Кваку Танки и чтобы его пореже дергали разработчики и бизнес.
Поскольку для реализации желаний админа, как показывает правда жизни, его силами должны реализоваться и мечты других героев, представители ИТ-тусовки много работали над этим. Часто получалось достичь желаемого, придерживаясь методологии DevOps и реализуя принципы CI/CD (Continuous Integration and Delivery).

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

Есть у нас веб-приложение. Относительно большое и старое — много-много кода, в котором много-много разных запросов к базе данных. При этом мы не гугл, но несколько тысяч запросов в секунду на сервер БД приходится.

Ну и безусловно растёт наше приложение во все стороны — добавляются новые фичи, наворачиваются и усложняются старые, растёт количество клиентов и соответственно количество данных в БД. И в один не очень прекрасный момент приходит понимание, что что-то наше приложение тормозит. А значит надо или найти, что именно нагружает БД, хотя могло бы не нагружать, ну или если ничего такого нет, то взять ещё серверов побольше, да помощнее.

Стандартный совет как найти, что нагружает MySQL — включить slow-query-log и посмотреть, какие запросы будут туда попадать. Но в MySQL 5.7 по умолчанию присутствует куда лучший инструмент — sys schema, которая агрегирует данные из performance schema и позволяет их получить простыми запросами, буквально вида «Ok, MySQL, покажи мне топ запросов по максимальному суммарному времени выполнения»

Это практическое пособие познакомит вас c Ansible. Вам понадобится виртуальная или реальная машина, которая будет выступать в роли узла для Ansible. Окружение для Vagrant идет в комплекте с этим пособием.

Ansible — это программное решение для удаленного управления конфигурациями. Оно позволяет настраивать удаленные машины. Главное его отличие от других подобных систем в том, что Ansible использует существующую инфраструктуру SSH, в то время как другие (chef, puppet, и пр.) требуют установки специального PKI-окружения.

Пособие покрывает такие темы:

1. Установка Ansible и Vagrant
2. Файл инвенторизации
3. Модули shell, copy, сбор фактов, переменные
4. Запуск на группу хостов
5. Плейбуки
6. Пример: поднимаем кластер, устанавливаем и настраиваем Apache и балансировщик нагрузок HAproxy
7. Обработка ошибок, откат
8. Шаблоны конфигурации
9. Роли

Ansible использует так называемый push mode: конфигурация «проталкивается» (push) с главной машины. Другие CM-системы обычно поступают наоборот – узлы «тянут» (pull) конфигурацию с главной машины.

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

Очень долго хотел написать статью, но не хватало времени. Нигде (в том числе на Хабре) не нашёл такой простой альтернативы munin, как описанная в этой статье.

У data scientist-ов сотни распределений вероятности на любой вкус. С чего начать?

Data science, чем бы она там не была – та ещё штука. От какого-нибудь гуру на ваших сходках или хакатонах можно услышать:«Data scientist разбирается в статистике лучше, чем любой программист». Прикладные математики так мстят за то, что статистика уже не так на слуху, как в золотые 20е. У них даже по этому поводу есть своя несмешная диаграмма Венна. И вот, значит, внезапно вы, программист, оказываетесь совершенно не у дел в беседе о доверительных интервалах, вместо того, чтобы привычно ворчать на аналитиков, которые никогда не слышали о проекте Apache Bikeshed, чтобы распределённо форматировать комментарии. Для такой ситуации, чтобы быть в струе и снова стать душой компании – вам нужен экспресс-курс по статистике. Может, не достаточно глубокий, чтобы вы всё понимали, но вполне достаточный, чтобы так могло показаться на первый взгляд.

Обычный будний день в одной организации перестал быть обычным после того, как несколько десятков человек не смогли продолжать свою деятельность, так как замерли все привычные процессы. Прекратила свою работу CRM, перестала откликаться база менеджеров, аналогичная картина была с бухгалтерскими базами. На системного администратора обрушился шквал звонков пользователей с сообщениями о проблемах и требованиями срочного вмешательства. Системный администратор, который сравнительно недавно начал карьеру в этой компании, попытался подключиться к NAS и обнаружил, что устройство не откликается. После отключения питания и повторного включения NAS вернулся к жизни, но запуска виртуальных машин не произошло. Для пользователей оказалось доступным только общее хранилище файлов. Анализ проблем системным администратором показал, что один из двух RAID массивов не содержит томов и является чистым неразмеченным пространством. Какими были дальнейшие действия системного администратора, история умалчивает, но достаточно быстро он осознал, что у него нет четкого плана действий по восстановлению данных и рабочей среды компании. На данном этапе шесть накопителей на жестких магнитных дисках (2 HDD – 3 TB HDS5C3030ALA630, 4 HDD – 4 TB WD4000FYYZ-01UL1B1) из этого NAS поступают в наше распоряжение. В техническом задании нам предлагается «восстановить таблицу разделов».

Астрологи объявили месяц статей о домашних NAS на Хабре, так что поделюсь и своей историей успеха...

Не так давно я попробовал новый FreeNAS Coral. Понравилось мне в нем если не все, то очень многое: это и новый гипервизор bhyve, и повсеместное использование 9P для проброса файловой системы на гостя, а так же идея с docker и многое другое.

Кроме того я ещё больше влюбился в ZFS со всеми её плюшками, такими как дедупликация и сжатие на лету.

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

В статье так же будет немного рассказано про Docker и автоматический прокси с автоматическим получением сертификатов Letsencrypt.

Проблема

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

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

Адаптивность методов повышения точности динамических измерений следует понимать, как использование прогнозирования значений дисперсий и погрешности для следующего цикла измерений. Такое прогнозирование осуществляется в каждом цикле измерений. Для этой цели применяются фильтры Винера, работающие в частотной области. В отличии от фильтра Винера, фильтр Калмана работает во временной, а не в частотной области. Фильтр Калмана был разработан для многомерных задач, формулировка которых осуществляется в матричной форме. Матричная форма достаточно подробно описана для реализации на Python в статье [1], [2]. Описание работы фильтра Калмана, приведенная в указанных статьях, рассчитана на специалистов в области цифровой фильтрации. Поэтому возникла необходимость рассмотреть работу фильтра Калмана в более простой скалярной форме.

Открытый курс машинного обучения mlcourse.ai сообщества OpenDataScience – это сбалансированный по теории и практике курс, дающий как знания, так и навыки (необходимые, но не достаточные) машинного обучения уровня Junior Data Scientist. Нечасто встретите и подробное описание математики, стоящей за используемыми алгоритмами, и соревнования Kaggle Inclass, и примеры бизнес-применения машинного обучения в одном курсе. С 2017 по 2019 годы Юрий Кашницкий yorko и большая команда ODS проводили живые запуски курса дважды в год – с домашними заданиями, соревнованиями и общим рейтингом учаcтников (имена героев запечатлены тут). Сейчас курс в режиме самостоятельного прохождения.

Второе занятие посвящено визуализации данных в Python. Сначала мы посмотрим на основные методы библиотек Seaborn и Plotly, затем поанализируем знакомый нам по первой статье набор данных по оттоку клиентов телеком-оператора и подглядим в n-мерное пространство с помощью алгоритма t-SNE. Есть и видеозапись лекции по мотивам этой статьи в рамках второго запуска открытого курса (сентябрь-ноябрь 2017).

UPD 01.2022: С февраля 2022 г. ML-курс ODS на русском возрождается под руководством Петра Ермакова couatl. Для русскоязычной аудитории это предпочтительный вариант (c этими статьями на Хабре – в подкрепление), англоговорящим рекомендуется mlcourse.ai в режиме самостоятельного прохождения.

Сейчас статья уже будет существенно длиннее. Готовы? Поехали!

Хочу поделиться простым рецептом, как можно эффективно выполнять большое число http-запросов и других задач ввода-вывода из обычного Питона. Самое правильное, что можно было бы сделать — использовать асинхронные фреймворки вроде Торнадо или gevent. Но иногда этот вариант не подходит, потому что встроить event loop в уже существующий проект проблематично.

В моем случае уже существовало Django-приложение, из которого примерно раз в месяц нужно было выгрузить немного очень мелких файлов на AWS s3. Шло время, количество файлов стало приближаться к 50 тысячам, и выгружать их по очереди стало утомительным. Как известно, s3 не поддерживает множественное обновление за один PUT-запрос, а установленная опытным путем максимальная скорость запросов с сервера ec2 в том же датацентре не превышает 17 в секунду (что очень не мало, кстати). Таким образом, время обновления для 50 тысяч файлов стало приближаться к одному часу.

Питонисты с детства знают, что от использования потоков (тредов операционной системы) нет никакого толка из-за глобального лока интерпретатора. Но немногие догадываются, что как и любой лок, этот время от времени освобождается. В частности, это происходит при операциях ввода-вывода, в том числе и сетевых. А значит, потоки можно использовать для распараллеливания http-запросов — пока один поток ожидает ответа, другой спокойно обрабатывает результат предыдущего или готовит следующий.

Получается, всего-то нужен пул потоков, который будет выполнять запросы. К счастью, такой пул уже написан. Начиная с версии 3.2 для унификации всей асинхронной работы в Питоне появилась библиотека concurrent.futures. Для второй версии Питона есть бекпорт под именем futures. Код до безобразия прост:

from concurrent.futures import ThreadPoolExecutor

with ThreadPoolExecutor(concurrency) as executor:
    for _ in executor.map(upload, queryset):
        pass

Здесь concurrency — число рабочих потоков, upload — функция, выполняющую саму задачу, queryset — итератор объектов, которые по одному будут передаваться в задачу. Уже этот код при concurrency в 150 смог пропихнуть на сервера Амазона ≈450 запросов в секунду.

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

Задача

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

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

В этой статье я опишу установку и настройку Active/Active кластера на основе Pacemaker, Corosync 2.x и CLVM с использованием разделяемого хранилища. Покажу, как приспособить этот кластер для работы с контейнерами LXC и Docker. Опишу команды для работы с кластером. И припомню те грабли, в которые вляпался, что, надеюсь, облегчит судьбу следующим проходимцам.

В качестве серверных дистрибутивов буду использовать CentOS 7 + epel и актуальные версии пакетов в них. Основной инструмент для работы с Pacemaker-ом будет PCS (pacemaker/corosync configuration system).

Хочу рассказать вам еще об одном способе балансировки нагрузки. Про Pacemaker и IPaddr (ресурс-агент) и настройке его для Active/Passive кластера сказано уже и так достаточно много, но информации по организации полноценного Active/Active кластера, используя этот модуль я нашел крайне мало. Постараюсь исправить эту ситуацию.

Для начала расскажу подробнее чем такой метод балансировки примечателен:

• Отсутсвие внешнего балансировщика — На всех нодах в кластере настраивается один общий виртуальный IP-адрес. Все запросы отправляются на него. Ноды отвечают на запросы на этот адрес случайно и по договоренности между ссобой.
• Высокая доступность — Если одна нода падает ее обязаности подхватывает другая.
• Простота настройки — Настройка осуществляется всего в 3-5 команд.
  

Как вы думаете, чего в апельсине больше — кожуры, или, хм, апельсина?



Предлагаю, если есть возможность, пойти на кухню, взять апельсин, очистить и проверить. Если лень или нет под рукой — воспользуемся скучной математикой: объем шара мы помним из школы. Пусть, скажем, толщина кожуры равна от радиуса, тогда , ; вычтем одно из другого, поделим объем кожуры на объем апельсина… получается, что кожуры что-то около 16%. Не так уж мало, кстати.

Как насчет апельсина в тысячемерном пространстве?

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

• во-первых, в тысячемерном гиперапельсине кожуры больше, чем мякоти
• а во-вторых, ее больше примерно в 246993291800602563115535632700000000000000 раз

То есть, каким бы странным и противоречивым это ни казалось, но почти весь объем гиперапельсина содержится в ничтожно тонком слое прямо под его поверхностью.

Начнем с этого, пожалуй.

То, о чем я попытаюсь сейчас рассказать, выглядит как настоящая магия.

Если вы что-то знали о нейронных сетях до этого — забудьте это и не вспоминайте, как страшный сон.
Если вы не знали ничего — вам же легче, полпути уже пройдено.
Если вы на «ты» с байесовской статистикой, читали вот эту и вот эту статьи из Deepmind — не обращайте внимания на предыдущие две строчки и разрешите потом записаться к вам на консультацию по одному богословскому вопросу.

Итак, магия:


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

Введение

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

Деревья принятия решений

Дерево принятия решений — это дерево, в листьях которого стоят значения целевой функции, а в остальных узлах — условия перехода (к примеру “ПОЛ есть МУЖСКОЙ”), определяющие по какому из ребер идти. Если для данного наблюдения условие истина то осуществляется переход по левому ребру, если же ложь — по правому.

Оглавление

Часть 1 — линейная регрессия
Часть 2 — градиентный спуск
Часть 3 — градиентный спуск продолжение

Введение

Этим постом я начну цикл «Нейронные сети для новичков». Он посвящен искусственным нейронным сетям (внезапно). Целью цикла является объяснение данной математической модели. Часто после прочтения подобных статей у меня оставалось чувство недосказанности, недопонимания — НС по-прежнему оставались «черным ящиком» — в общих чертах известно, как они устроены, известно, что делают, известны входные и выходные данные. Но тем не менее полное, всестороннее понимание отсутствует. А современные библиотеки с очень приятными и удобными абстракциями только усиливают ощущение «черного ящика». Не могу сказать, что это однозначно плохо, но и разобраться в используемых инструментах тоже никогда не поздно. Поэтому моей первичной целью является подробное объяснение устройства нейронных сетей так, чтобы абсолютно ни у кого не осталось вопросов об их устройстве; так, чтобы НС не казались волшебством. Так как это не математический трактат, я ограничусь описанием нескольких методов простым языком (но не исключая формул, конечно же), предоставляя поясняющие иллюстрации и примеры.

Цикл рассчитан на базовый ВУЗовский математический уровень читающего. Код будет написан на Python3.5 с numpy 1.11. Список остальных вспомогательных библиотек будет в конце каждого поста. Абсолютно все будет написано с нуля. В качестве подопытного выбрана база MNIST — это черно-белые, центрированные изображения рукописных цифр размером 28*28 пикселей. По-умолчанию, 60000 изображений отмечены для обучения, а 10000 для тестирования. В примерах я не буду изменять распределения по-умолчанию.

Нахождение экстремума(минимума или максимума) целевой функции является важной задачей в математике и её приложениях(в частности, в машинном обучении есть задача curve-fitting). Наверняка каждый слышал о методе наискорейшего спуска (МНС) и методе Ньютона (МН). К сожалению, эти методы имеют ряд существенных недостатков, в частности — метод наискорейшего спуска может очень долго сходиться в конце оптимизации, а метод Ньютона требует вычисления вторых производных, для чего требуется очень много вычислений.

Для устранения недостатков, как это часто бывает, нужно глубже погрузиться в предметную область и добавить ограничения на входные данные. В частности: МНС и МН имеют дело с произвольными функциями. В статистике и машинном обучении часто приходится иметь дело с методом наименьших квадратов (МНК). Этот метод минимизирует сумму квадрата ошибок, т.е. целевая функция представляется в виде

Алгоритм Левенберга — Марквардта является нелинейным методом наименьших квадратов. Статья содержит:

• объяснение алгоритма
• объяснение методов: наискорейшего спуска, Ньтона, Гаусса-Ньютона
• приведена реализация на Python с исходниками на github
• сравнение методов