Конференцията на Habr не е дебютна история. Преди това проведохме доста големи събития на Toaster за 300-400 души, но сега решихме, че малките тематични срещи ще бъдат уместни, чиято посока можете да зададете, например, в коментарите. Първата конференция в този формат се проведе през юли и беше посветена на backend разработката. Участниците изслушаха доклади за характеристиките на прехода от бекенда към ML и за дизайна на услугата Quadrupel на портала за държавни услуги, а също така участваха в кръгла маса, посветена на Serverless. За тези, които не успяха да присъстват лично на събитието, в тази публикация ви разказваме най-интересните неща.
От backend разработка до машинно обучение
Какво правят инженерите по данни в ML? Как задачите на backend разработчика и ML инженера са подобни и различни? Какъв път трябва да извървите, за да смените първата си професия с втората? Това разказа Александър Паринов, който се насочи към машинното обучение след 10 години бекенд работа.
Александър Паринов
Днес Александър работи като архитект на системи за компютърно зрение в X5 Retail Group и допринася за проекти с отворен код, свързани с компютърно зрение и дълбоко обучение (github.com/creafz). Уменията му се потвърждават от участието му в топ 100 на световната класация на Kaggle Master (kaggle.com/creafz), най-популярната платформа за състезания по машинно обучение.
Защо да преминете към машинно обучение
Преди година и половина Джеф Дийн, ръководител на Google Brain, изследователският проект на Google за изкуствен интелект, базиран на дълбоко обучение, описа как половин милион реда код в Google Translate са заменени от невронна мрежа Tensor Flow, състояща се само от 500 реда. След обучението на мрежата качеството на данните се повиши и инфраструктурата стана по-проста. Изглежда, че това е светлото ни бъдеще: вече не трябва да пишем код, достатъчно е да направим неврони и да ги напълним с данни. Но на практика всичко е много по-сложно.
ML инфраструктура в Google
Невронните мрежи са само малка част от инфраструктурата (малкият черен квадрат на снимката по-горе). Необходими са много повече спомагателни системи, за да получават данни, да ги обработват, съхраняват, проверяват качеството и т.н., имаме нужда от инфраструктура за обучение, внедряване на код за машинно обучение в производството и тестване на този код. Всички тези задачи са точно подобни на това, което правят бекенд разработчиците.
Процес на машинно обучение
Каква е разликата между ML и backend?
В класическото програмиране ние пишем код и това диктува поведението на програмата. В ML имаме малък код на модела и много данни, които хвърляме към модела. Данните в ML са много важни: един и същ модел, обучен на различни данни, може да покаже напълно различни резултати. Проблемът е, че данните почти винаги са разпръснати и се съхраняват в различни системи (релационни бази данни, NoSQL бази данни, регистрационни файлове, файлове).
Версиране на данни
ML изисква версия не само на кода, както при класическата разработка, но и на данните: необходимо е ясно да се разбере на какво е обучен моделът. За да направите това, можете да използвате популярната библиотека Data Science Version Control (dvc.org).
Маркиране на данни
Следващата задача е етикетиране на данни. Например, маркирайте всички обекти на картината или кажете към кой клас принадлежи. Това се прави от специални услуги като Yandex.Toloka, работата с която е значително опростена от наличието на API. Трудностите възникват поради „човешкия фактор“: можете да подобрите качеството на данните и да намалите грешките до минимум, като поверите една и съща задача на няколко изпълнители.
Визуализация в Tensor Board
Записването на експерименти е необходимо за сравняване на резултатите и избор на най-добрия модел въз основа на някои показатели. Има голям набор от инструменти за визуализация - например Tensor Board. Но няма идеални начини за съхраняване на експерименти. Малките компании често се задоволяват с електронна таблица в Excel, докато големите използват специални платформи за съхраняване на резултатите в база данни.
Има много платформи за машинно обучение, но нито една от тях не покрива 70% от нуждите
Първият проблем, с който човек трябва да се сблъска при пускането на обучен модел в производство, е свързан с любимия инструмент на учените за данни - Jupyter Notebook. В него няма модулност, тоест изходът е такава „кърпа“ от код, която не е разделена на логически части - модули. Всичко е смесено: класове, функции, конфигурации и т.н. Този код е труден за версия и тестване.
Как да се справим с това? Можете да се примирите, като Netflix, и да създадете своя собствена платформа, която ви позволява да пускате тези лаптопи директно в производство, да прехвърляте данни към тях като вход и да получавате резултати. Можете да принудите разработчиците, които пускат модела в производство, да пренапишат кода нормално, да го разделят на модули. Но с този подход е лесно да направите грешка и моделът няма да работи по предназначение. Следователно идеалният вариант е да се забрани използването на Jupyter Notebook за код на модела. Ако, разбира се, специалистите по данни се съгласят с това.
Модел като черна кутия
Най-лесният начин да пуснете модел в производство е да го използвате като черна кутия. Имате някакъв клас модел, дадени са ви теглата на модела (параметри на невроните на обучената мрежа) и ако инициализирате този клас (извиквате предсказващия метод, подавате му картина), ще получите определен прогноза като изход. Какво се случва вътре, няма значение.
Отделен сървърен процес с модел
Можете също така да повдигнете определен отделен процес и да го изпратите през RPC опашка (със снимки или други изходни данни. На изхода ще получим прогнози.
Пример за използване на модел във Flask:
@app.route("/predict", methods=["POST"])
def predict():
image = flask.request.files["image"].read()
image = preprocess_image(image)
predictions = model.predict(image)
return jsonify_prediction(predictions)
Проблемът с този подход е ограничението на производителността. Да кажем, че имаме код на Phyton, написан от специалисти по данни, който е бавен, и искаме да изтръгнем максимална производителност. За да направите това, можете да използвате инструменти, които конвертират кода в естествен или го конвертират в друга рамка, пригодена за производство. Има такива инструменти за всяка рамка, но няма идеални; ще трябва да ги добавите сами.
Инфраструктурата в ML е същата като в обикновения бекенд. Има Docker и Kubernetes, само за Docker трябва да инсталирате runtime от NVIDIA, което позволява на процесите вътре в контейнера да имат достъп до видеокарти в хоста. Kubernetes се нуждае от плъгин, за да може да управлява сървъри с видео карти.
За разлика от класическото програмиране, в случая на ML има много различни движещи се елементи в инфраструктурата, които трябва да бъдат проверени и тествани - например код за обработка на данни, конвейер за обучение на модели и производство (вижте диаграмата по-горе). Важно е да тествате кода, който свързва различни части от тръбопроводи: има много части и много често възникват проблеми на границите на модула.
Как работи AutoML
Услугите на AutoML обещават да изберат оптималния модел за вашите цели и да го обучат. Но трябва да разберете: данните са много важни в ML, резултатът зависи от тяхната подготовка. Маркирането се извършва от хора, което е изпълнено с грешки. Без строг контрол резултатът може да бъде боклук и все още не е възможно процесът да се автоматизира; необходима е проверка от специалисти - учени по данни. Това е мястото, където AutoML се разпада. Но може да бъде полезно за избор на архитектура - когато вече сте подготвили данните и искате да проведете серия от експерименти, за да намерите най-добрия модел.
Как да влезем в машинното обучение
Най-лесният начин да влезете в ML е, ако разработвате в Python, който се използва във всички рамки за дълбоко обучение (и обикновени рамки). Този език е практически задължителен за тази сфера на дейност. C++ се използва за някои задачи за компютърно зрение, например в системи за управление на самоуправляващи се автомобили. JavaScript и Shell - за визуализация и такива странни неща като стартиране на неврон в браузъра. Java и Scala се използват при работа с Big Data и за машинно обучение. R и Julia са обичани от хора, които изучават математическа статистика.
Най-удобният начин да получите практически опит като начало е в Kaggle; участието в едно от състезанията на платформата дава повече от година изучаване на теория. На тази платформа можете да вземете нечий друг публикуван и коментиран код и да се опитате да го подобрите, оптимизирате за вашите цели. Бонус - вашият ранг в Kaggle влияе върху заплатата ви.
Друг вариант е да се присъедините към екипа на ML като backend разработчик. Има много стартиращи фирми за машинно обучение, където можете да придобиете опит, като помагате на колегите си да решат проблемите си. И накрая, можете да се присъедините към една от общностите на специалистите по данни - Open Data Science (ods.ai) и други.
Лекторът публикува допълнителна информация по темата на линка
"Квадрупел" - услуга за целеви известия на портала "Държавни услуги"
Евгений Смирнов
Следващият лектор беше ръководителят на отдела за развитие на инфраструктурата на електронното правителство Евгений Смирнов, който говори за Quadruple. Това е целева услуга за уведомяване за портала Gosuslugi (gosuslugi.ru), най-посещаваният правителствен ресурс в Runet. Дневната аудитория е 2,6 милиона, общо има 90 милиона регистрирани потребители на сайта, от които 60 милиона са потвърдени. Натоварването на API на портала е 30 хиляди RPS.
Технологии, използвани в задната част на държавните служби
“Quadrupel” е целенасочена услуга за известяване, с помощта на която потребителят получава оферта за услуга в най-подходящия за него момент, като зададе специални правила за известяване. Основните изисквания при разработването на услугата бяха гъвкави настройки и достатъчно време за изпращане на имейли.
Как работи Quadrupel?
Диаграмата по-горе показва едно от правилата за работа на Quadrupel, използвайки пример за ситуация с необходимостта от подмяна на шофьорска книжка. Първо, услугата търси потребители, чийто срок на валидност изтича след месец. Показва им се банер с предложение за получаване на съответната услуга и се изпраща съобщение по имейл. За тези потребители, чийто срок вече е изтекъл, банерът и имейлът се променят. След успешна размяна на права, потребителят получава други известия – с предложение за актуализиране на данните в самоличността.
От техническа гледна точка това са groovy скриптове, в които е написан кодът. Входът е данни, изходът е вярно/невярно, съвпадение/несъвпадение. Има общо повече от 50 правила - от определяне на рождения ден на потребителя (текущата дата е равна на датата на раждане на потребителя) до сложни ситуации. Всеки ден тези правила идентифицират около милион съвпадения - хора, които трябва да бъдат уведомени.
Quadrupel канали за уведомяване
Под капака на Quadrupel има база данни, в която се съхраняват потребителски данни, и три приложения:
- Работник предназначени за актуализиране на данни.
- API за почивка взима и доставя самите банери до портала и мобилното приложение.
- Scheduler започва работа по преизчисляване на банери или масови съобщения.
За да актуализира данни, бекендът се управлява от събития. Два интерфейса - rest или JMS. Събитията са много, преди да бъдат записани и обработени, те се обобщават, за да не се правят ненужни заявки. Самата база данни, таблицата, в която се съхраняват данните, изглежда като хранилище на ключови стойности - ключът на потребителя и самата стойност: флагове, показващи наличието или отсъствието на съответните документи, срокът им на валидност, обобщена статистика за реда на услугите от този потребител и т.н.
След запазване на данните, в JMS се задава задача, така че банерите да бъдат незабавно преизчислени - това трябва незабавно да се покаже в мрежата. Системата стартира през нощта: задачите се хвърлят в JMS на потребителски интервали, според които правилата трябва да бъдат преизчислени. Това се улавя от процесорите, участващи в преизчисляването. След това резултатите от обработката отиват на следващата опашка, която или записва банерите в базата данни, или изпраща задачи за уведомяване на потребителя към услугата. Процесът отнема 5-7 часа, лесно се мащабира поради факта, че винаги можете да добавите манипулатори или да повдигнете инстанции с нови манипулатори.
Услугата работи доста добре. Но обемът на данните нараства, тъй като има повече потребители. Това води до увеличаване на натоварването на базата данни - дори като се вземе предвид факта, че Rest API разглежда репликата. Втората точка е JMS, който, както се оказа, не е много подходящ поради високата консумация на памет. Има висок риск от препълване на опашката, което да доведе до срив на JMS и спиране на обработката. Невъзможно е да се повдигне JMS след това, без да се изчистят регистрационните файлове.
Предвижда се проблемите да бъдат решени чрез шардинг, което ще позволи балансиране на натоварването на базата данни. Има също планове за промяна на схемата за съхранение на данни и промяна на JMS на Kafka - по-устойчиво на грешки решение, което ще разреши проблемите с паметта.
Backend-като-услуга Vs. Без сървър
Отляво надясно: Александър Боргарт, Андрей Томиленко, Николай Марков, Ара Израелян
Backend като услуга или решение без сървър? Участници в обсъждането на този наболял проблем на кръглата маса бяха:
- Ара Израелян, CTO CTO и основател на Scorocode.
- Николай Марков, старши инженер по данни в Aligned Research Group.
- Андрей Томиленко, началник на отдела за развитие на RUVDS.
Разговорът беше модериран от старши разработчик Александър Боргарт. Дебатите, в които участваха и слушателите, представяме в съкратен вариант.
— Какво е Serverless според твоето разбиране?
Андрю: Това е изчислителен модел - Lambda функция, която трябва да обработва данни, така че резултатът да зависи само от данните. Терминът идва или от Google, или от Amazon и неговата услуга AWS Lambda. За доставчика е по-лесно да се справи с такава функция, като разпредели пул от капацитет за нея. Различни потребители могат да бъдат независимо отчитани на едни и същи сървъри.
Nicholas: Казано по-просто, ние прехвърляме част от нашата ИТ инфраструктура и бизнес логика в облака, към аутсорсинг.
ара: От страна на разработчиците - добър опит да се спестят ресурси, от страна на търговците - да се спечелят повече пари.
— Дали без сървър е същото като микроуслугите?
Nicholas: Не, Serverless е по-скоро организация на архитектурата. Микроуслугата е атомна единица с някаква логика. Без сървър е подход, а не „отделен обект“.
ара: Функция без сървър може да бъде пакетирана в микроуслуга, но това вече няма да бъде без сървър, а ще престане да бъде функция Lambda. При Serverless дадена функция започва да работи само в момента, в който бъде поискана.
Андрю: Те се различават по продължителността на живота си. Пуснахме функцията Lambda и я забравихме. Работи за няколко секунди и следващият клиент може да обработи заявката си на друга физическа машина.
— Кои везни са по-добри?
ара: При хоризонтално мащабиране функциите Lambda се държат точно по същия начин като микроуслугите.
Nicholas: Какъвто и брой реплики да зададете, толкова ще има; Serverless няма проблеми с мащабирането. Направих набор от реплики в Kubernetes, стартирах 20 екземпляра „някъде“ и 20 анонимни връзки ви бяха върнати. Напред!
— Възможно ли е да се напише бекенд на Serverless?
Андрю: Теоретично, но няма смисъл. Ламбда функциите ще разчитат на едно хранилище - трябва да осигурим гаранция. Например, ако потребителят е извършил определена транзакция, тогава следващия път, когато се свърже, той трябва да види: транзакцията е завършена, средствата са кредитирани. Всички Lambda функции ще блокират при това повикване. Всъщност куп функции без сървър ще се превърнат в една услуга с една точка за достъп до базата данни.
— В какви ситуации има смисъл да се използва безсървърна архитектура?
Андрю: Задачи, които не изискват споделено съхранение - същото копаене, блокчейн. Където трябва да броите много. Ако имате много изчислителна мощност, тогава можете да дефинирате функция като „изчислете хеша на нещо там...“ Но можете да разрешите проблема със съхранението на данни, като вземете например Lambda функции от Amazon и тяхното разпределено съхранение . И се оказва, че пишете редовна услуга. Ламбда функциите ще имат достъп до хранилището и ще осигурят някакъв отговор на потребителя.
Nicholas: Контейнерите, които работят без сървър, са изключително ограничени в ресурсите. Има малко памет и всичко останало. Но ако цялата ви инфраструктура е разположена изцяло в някакъв облак - Google, Amazon - и имате постоянен договор с тях, има бюджет за всичко това, тогава за някои задачи можете да използвате сървърни контейнери. Необходимо е да сте вътре в тази инфраструктура, защото всичко е пригодено за използване в специфична среда. Тоест, ако сте готови да свържете всичко с облачната инфраструктура, можете да експериментирате. Предимството е, че не е нужно да управлявате тази инфраструктура.
ара: Фактът, че Serverless не изисква да управлявате Kubernetes, Docker, да инсталирате Kafka и т.н., е самозаблуда. Същите Amazon и Google инсталират това. Друго нещо е, че имате SLA. Можете също така да възложите всичко, вместо да го кодирате сами.
Андрю: Самото без сървър е евтино, но трябва да платите много за други услуги на Amazon - например базата данни. Хората вече ги съдиха, защото те таксуваха луди суми пари за портата на API.
ара: Ако говорим за пари, тогава трябва да вземете предвид този момент: ще трябва да обърнете цялата методология на разработката в компанията на 180 градуса, за да прехвърлите целия код към Serverless. Това ще отнеме много време и пари.
— Има ли някакви достойни алтернативи на платения Serverless от Amazon и Google?
Nicholas: В Kubernetes стартирате някаква работа, тя се изпълнява и умира - това е доста Serverless от архитектурна гледна точка. Ако искате да създадете наистина интересна бизнес логика с опашки и бази данни, тогава трябва да помислите малко повече за това. Всичко това може да бъде разрешено, без да напускате Kubernetes. Не бих си направил труда да влача допълнително внедряване.
— Колко важно е да наблюдавате какво се случва в Serverless?
ара: Зависи от системната архитектура и бизнес изискванията. По същество доставчикът трябва да предостави отчети, които ще помогнат на екипа за devops да разбере възможните проблеми.
Nicholas: Amazon има CloudWatch, където се предават всички регистрационни файлове, включително тези от Lambda. Интегрирайте препращане на журнали и използвайте отделен инструмент за преглед, предупреждение и т.н. Можете да поставите агенти в контейнерите, които стартирате.
- Нека обобщим.
Андрю: Мисленето за ламбда функции е полезно. Ако създадете сами услуга - не микроуслуга, а такава, която пише заявка, осъществява достъп до базата данни и изпраща отговор - функцията Lambda решава редица проблеми: с многопоточност, мащабируемост и т.н. Ако вашата логика е изградена по този начин, тогава в бъдеще ще можете да прехвърлите тези Lambda към микроуслуги или да използвате услуги на трети страни като Amazon. Технологията е полезна, идеята е интересна. Доколко това е оправдано за бизнеса е все още открит въпрос.
Николай: Serverless е по-добре да се използва за оперативни задачи, отколкото за изчисляване на някаква бизнес логика. Винаги мисля за това като за обработка на събития. Ако го имате в Amazon, ако сте в Kubernetes, да. В противен случай ще трябва да положите доста усилия, за да накарате Serverless да работи самостоятелно. Необходимо е да се разгледа конкретен бизнес случай. Например, една от моите задачи сега е: когато файлове се появят на диска в определен формат, трябва да ги кача в Kafka. Мога да използвам WatchDog или Lambda. От логическа гледна точка и двата варианта са подходящи, но като реализация Serverless е по-сложен и аз предпочитам по-простия начин, без Lambda.
ара: Serverless е интересна, приложима и много красива от техническа гледна точка идея. Рано или късно технологията ще достигне точката, в която всяка функция ще се стартира за по-малко от 100 милисекунди. Тогава по принцип няма да има въпрос дали времето за изчакване е критично за потребителя. В същото време приложимостта на Serverless, както вече казаха колегите, зависи изцяло от бизнес проблема.
Благодарим на нашите спонсори, които ни помогнаха много:
- ИТ конферентно пространство «» за сайта на конференцията.
- Календар на ИТ събитията и публикация"» за информационна поддръжка и новини.
- «"за подаръци.
- за съвместно творчество.
- "Асоциация за електронни съобщения" за участие и опит.
- Основен спонсор - за всички!
Източник: www.habr.com