Блог компании ibm

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




Мое знакомство с service mesh было во многом случайным, когда в 2017 году мне на глаза попался анонс о сотрудничестве Google и IBM по созданию нового open source проекта. Не сказать, что партнерства крупнейших технологических компаний редки, но именно этот случай вызвал у меня большой интерес. Во-первых, примеров взаимодействия именно компаний Google и IBM все же не так много: пожалуй, наиболее известными фактами будут работа вокруг открытой аппаратной архитектуры OpenPOWER, а также наличие сервисов IBM в Google Cloud. Во-вторых, несмотря на наличие примеров, когда и Google, и IBM развивают один и тот же open source проект (Kubernetes или TensorFlow), случаев, чтобы обе эти компании стали именно основателями проекта, очень мало, и они достаточно уникальны. И, в-третьих, наличие среди основателей проекта IBM и Google компании Lyft конкурента Uber как сервиса вызова такси, вызывало вопросы и неподдельный интерес. Тот анонс в 2017 году рассказывал о выпуске технологии Istio, предназначенной для управления взаимодействием различных сервисов. Поначалу не совсем очевидно, в чем заключается проблема и зачем создавать такой проект, так как подходов по управлению взаимодействием между сервисами было известно довольно много. Чтобы понять проблематику, стоит взглянуть на ситуацию шире и посмотреть на изменения в ИТ-архитектуре на тот момент времени.

Что такое service mesh

Причины появления и столь стремительно нарастающей популярности service mesh неразрывно связаны с изменениями в ИТ архитектуре. Представить появление service mesh без микросервисной архитектуры достаточно сложно давайте посмотрим почему. Можно долго спорить, что такое микросервисная архитектура, так как единого и устоявшегося определения нет (и вообще эта тема заслуживает отдельной статьи), но для упрощения остановимся на следующих ключевых характеристиках: это небольшие автономные части бизнес-логики, реализованные как сервисы, каждый из которых имеет свой цикл сборки и поддержки. В таком случае логично задуматься о том, как эти небольшие сервисы будут взаимодействовать друг с другом и как контролировать этот процесс. Здесь и появляется service mesh. В реальной жизни эту технологию можно сравнить с дорожным навигатором. На дорогах могут случаться различные ситуации: аварии, заторы, выход из строя светофоров, а система позволяет вам добраться из пункта А в пункт Б наиболее оптимальным способом, зная обо всех произошедших событиях.

Ключевыми задачами, которые берет на себя service mesh, являются:

• управление трафиком
• балансировка нагрузки
• обеспечение безопасности при взаимодействии сервисов
• сбор метрик и мониторинг

Другим аналогом service mesh из реальной жизни может быть служба почтовой доставки: она решает, что делать с посылкой, если вас нет дома или вы переехали, следит за безопасностью транспортировки, обеспечивает приватность передачи посылки и отслеживает статусы.

Эволюция развития service mesh

В настоящее время service mesh стал отдельным слоем и во многом стандартом де-факто современной ИТ-архитектуры на уровне инфраструктуры. Можно ли строить современные решения без service mesh и реализовывать этот функционал как-то по-другому? Конечно, да, только вопрос в удобстве, гибкости, времени реализации и дальнейшей поддержке решения. Безусловно, задачи, связанные с управлением трафика или балансировкой, можно решить самому на уровне кода для каждого из сервисов. Но так как микросервисная архитектура подразумевает существование десятков, сотен или даже тысяч различных сервисов, то реализовывать один и тот же функционал при разработке каждого из них совсем не удобно. Зачем разрабатывать один и тот же функционал десятки или сотни раз, если можно вынести его отдельно?
Первые реализации service mesh были сделаны на прикладном уровне. Самый известный пример фреймворк (или набор библиотек) Netflix OSS, доступный для использования с 2012 года. В него вошли компоненты, реализующие функционал, присущий service mesh: с помощью Eureka производится обнаружение сервисов (service discovery), с помощью Hystrix ряд паттернов обнаружений ошибок (circuit breaker), Zuul решает задачи динамической маршрутизации (dynamic routing).

На необходимость изменения этого подхода оказали сильное влияние следующие факторы:

• поддержка нескольких языков программирования и отсутствие зависимости от них
• удобство разделения прикладных и инфраструктурных задач для DevOps: возможность вносить изменения в прикладной код без влияния на инфраструктуру
• развитие контейнерных технологий

Как ни крути, Netflix OSS куда больше был интегрирован в прикладную логику сервиса, требовал использование стека технологий Netflix, имел зависимость библиотек от языка разработки и не был заточен для использования в контейнерах.
Istio как пример следующей волны эволюции технологии использует sidecar (Envoy от Lyft), то есть прокси, который располагается рядом с каждым сервисом и берет на себя функционал по управлению политиками безопасности, трафиком, сбор телеметрии и пр. Это позволяет быть нейтральным к выбору языка программирования, иметь хорошую интеграцию с Kubernetes как стандарта де-факто по оркестрации контейнерных сред и не иметь никаких зависимостей от прикладной логики сервисов. По факту именно на этом шаге эволюции технологии service mesh произошло ее окончательное выделение в отдельный инфраструктурный слой как самостоятельный уровень современной ИТ-архитектуры.

Адаптация технологии в корпоративном мире

Все большая популярность микросервисной архитектуры и контейнерных технологий и те преимущества, которые они дают, не оставили в стороне большие российские корпорации, которые начали задумываться об использовании этих подходов у себя. Вместе с этим возникает ряд вопросов по использованию service mesh и, в частности, Istio. Многие сомневаются в том, что технология достаточно зрелая для использования в корпоративном мире, что обладает достаточным функционалом и способна выдерживать большие нагрузки. Ниже будут даны ответы на пять наиболее популярных вопросов, которые нам задавали ИТ сотрудники корпораций про использование Istio, чтобы помочь убедиться в ее готовности к внедрению.

Вопрос 1: Достигла ли технология Istio достаточной зрелости для внедрения в корпорациях?

Так как мы говорим о крупных организациях, то для них вопрос зрелости той или иной технологии является одним из самых первых. Что подразумевается под зрелостью? Параметрами зрелости могут быть функциональность, стабильность работы, количество промышленных внедрений, максимальная нагрузка, а также соответствие ряду нефункциональных требований, например, по отказоустойчивости или масштабированию. Важно понимать, что для каждой компании количественные значения каждого из параметров будут своими в зависимости от ее масштабов и сценариев использования.
Что можно сказать про Istio? С точки зрения стабильности работы в мире open source немаловажным является выпуск версии 1.0, которая сообществом контрибьюторов Istio была представлена еще летом 2018 года. Примерами по использованию технологии являются уже десятки компаний, наиболее известными среди которых являются Ebay, Yahoo и банк ING. Интересными примером является история использования Istio при эксплуатации истребителя F16. Отдельно стоит выделить факт, что ведущие облачные провайдеры IBM и Google предоставляют сервисы на базе Istio для своих клиентов. Более того, Istio используется даже как часть новых open source фреймворков. Пример: Kabanero, направленный на более быструю разработку приложений поверх контейнерной инфраструктуры.

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

Вопрос 2: Service mesh для новых сред с контейнерами, а что делать с традиционным ландшафтом на виртуальных машинах?

Service mesh принадлежит типу технологий, относящихся к cloud native, которые создавались в эру развития контейнеров. Но, вспоминая реальность ИТ ландшафта корпораций, можно заметить, что промышленных систем, работающих поверх контейнеров не так много, и корпорации стоят лишь в начале пути по их массовому использованию. Многие бизнес-критичные задачи по-прежнему работают на виртуальных машинах и здесь возникает вопрос: неужели для них нельзя использовать Istio?
Краткий ответ конечно, можно. Istio позволяет создавать разные конфигурации с использованием как контейнерной инфраструктуры, так и виртуальных машин или даже bare metal. Для связи виртуальных машин и service mesh необходимо выполнить ряд действий, например обеспечить видимость IP-адресов кластера с Istio и пр. Более подробное описание и примеры можно найти здесь.

Вопрос 3: Какую модель развертывания выбрать?

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

• один или несколько кластеров (мультикластер)
• один или несколько сетевых сегментов
• одна или несколько контрольных точек управления (control panel)
• одна или несколько сеток (mesh)

На текущий момент времени можно сказать, что опция мультикластерного развертывания является наиболее востребованной в корпорациях среди прочих не случайно этому аспекту уделяется большая часть работы сообщества вокруг проекта Istio. Каковы причины выбора именно этой опции? Это наличие большого количества команд разработки отдельных продуктов и систем, это необходимость развертывания в нескольких ЦОД, это разделение на зоны разработки, тестирования и промышленной эксплуатации. Из-за всех этих требований опция развертывания одного кластера даже с несколькими сервисными сетками внутри него не позволяет обеспечить необходимый уровень изоляции ресурсов.
Безусловно, внутри мультикластерного развертывания могут быть также варианты размещения контрольных панелей: не обязательно размещать одну контрольную панель на один кластер, несколько кластеров могут использовать одну контрольную панель.
На практике на определение опции развертывания уходит не одна неделя проектирования, так как архитекторам необходимо прийти к компромиссу между хорошим уровнем изоляции ресурсов и накладными расходами на взаимодействие между кластерами.

Вопрос 4: А какую нагрузку выдержит?

Так как речь идет о корпорациях, то, как правило, они обслуживают большое число клиентов и, соответственно, имеют на своих системах большие нагрузки. Поэтому вопрос абсолютно не праздный и на практике не редки случаи, когда та или иная новая технология не давала нужную производительность и не могла обеспечить предоставление сервисов компании по запросу клиентов.
Конечно, самый грамотный ответ на этот вопрос: зависит от множества факторов. То, как развернута система, какие требования по отказоустойчивости или изоляции, какая версия технологии используется все эти факторы оказывают прямое воздействие на производительность. Но вряд ли этот ответ способен дать хоть какие-то оценки, поэтому посмотрим на уже имеющийся опыт других компаний. К сожалению, в открытых источниках сложно найти детальную информацию от компаний по их опыту использования Istio, но на различных встречах, митапах или конференциях уже в начале 2019 года одной из компаний в области информационной безопасности были представлены цифры в десятки тысяч транзакций в секунду (TPS) системы, использующей Istio. Многие корпорации провели пилотные проекты и получили результаты в несколько сотен транзакций в секунду. Много это или мало? Для примера, только несколько крупных банков России имеют нагрузки в несколько тысяч TPS на своих ИТ системах, поэтому оценка даже в несколько сотен TPS с лихвой покроет подавляющее большинство задач любой корпорации.

Вопрос 5: Когда будут нужные нам фичи?

Во время внедрения Istio технические специалисты организаций часто обращаются в IBM как к компании-основателю проекта с вопросами о сроках реализации конкретных новых фич технологии.

На этом вопросе можно хорошо показать разницу между проприетарным программным обеспечением от какого-либо вендора и миром open source. Многие корпорации с точки зрения своих ожиданий одинаково относятся и к тем, и другим технологиям, хотя в ряде моментов различия достаточно большие и ждать такой же ответственности от участников open source проекта, как от компании-производителя коммерческого ПО, странно. Безусловно, за большинством успешных open source проектов стоит одна или несколько компаний, которая, как правило, и является основателем. Но в отличие от коммерческого ПО, компания-основатель не может просто так взять и добавить фичу в проект без обратной связи от других контрибьюторов. Здесь есть и свои плюсы, и минусы. Бывали случаи, когда один из контрибьюторов брался за реализацию конкретной фичи, в которой были заинтересованы многие участники проекта, но срывал сроки из-за занятости и болезни, отодвигая релиз на несколько месяцев вперед. Поэтому в случае open source проекта гарантировать выход конкретной фичи в конкретный срок намного тяжелее, чем в случае с коммерческим ПО. С другой стороны, нет такой прямой зависимости от решения одной компании, так как реализацию может взять на себя другой участник проекта.

Поэтому четкого ответа на этот вопрос не существует, но есть ряд рекомендаций, которые позволят держать руку на пульсе происходящего в open source проекте. На примере Istio cписок рабочих групп проекта известен, их встречи и протоколы обсуждений открыты, доступна возможность задавать вопросы и описывать проблемы во всех этих, а также многих других вещах представители корпораций могут участвовать. В текущий момент времени корпорации крайне осторожно принимают участие в жизни сообщества, и очень хочется надеяться, что в ближайшее время этот тренд изменится.

Вместо заключения

Что можно сказать в итоге? Несмотря на то, что Istio достаточно молодая технология, ее текущий уровень зрелости и существующий функционал полностью отвечают требованиям корпораций. Видно, что среди крупных российских компаний интерес к Istio за последний год существенно вырос и все больше и больше ИТ команд начинают свои первые проекты, а ряд из них уже использует технологию в промышленной среде.
Для тех, кто хочет видеть Istio не только в своих ИТ системах, но и на полке или столе, мой коллега создал модель парусника как копию логотипа Istio для распечатки на 3D-принтере, которую можно скачать здесь.

Рашик Пармар, почетный сотрудник (IBM Fellow), вице-президент в регионе EMEA по технологиям IBM и член жюри глобального конкурса программистов Call for Code считает, что масштабно решать глобальные проблемы нужно путем ответственного использования вычислительных технологий (ВТ).

На счету Рашика почти 40 лет работы в IBM на технических должностях, а также уже несколько лет участия в жюри конкурса Call for Code, где он оценивает и отбирает лучшие заявки от 400 тыс. конкурсантов.



Темой проводимого IBM совместно с рядом единомышленников глобального конкурса для разработчиков Call for Code 2021 стали климатические изменения как главный вызов, стоящий сегодня перед нашей планетой. Представители ООН считают изменение климата беспрецедентной по своим масштабам проблемой. И если сейчас не принимать меры для ее решения, то в будущем потребуется гораздо больше сил и ресурсов, чтобы адаптироваться к изменившимся условиям. Для желающих развить свои профессиональные навыки и применить их в карьере, познакомиться с новаторами со всего мира или создать собственное решение, которое поможет в борьбе с изменениями климата, сейчас самое время сделать первый шаг и присоединиться к Call for Code.

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

Ответственное использование ВТ

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

Общение с порядком сотни технических директоров в прошлом году привели автора к выводу, что дело не только в проблемах экологии и изменения климата, но и в вопросах равенства и расовой справедливости. У руководителей есть ряд опасений, которые они не всегда могут сформулировать во всей полноте. Вот некоторые их них. Достаточно ли мы делаем для того, чтобы сократить углеродный след наших технологических решений? Хорошо ли мы следим за тем, чтобы наша инфраструктура минимально воздействовала на окружающую среду? Можно ли делать это более продуктивно? Задумывается ли мы об эффективности кода? Является ли этот код не только надежным и безопасным, но также инклюзивным и ценным? Этично ли мы используем данные граждан? Насколько инклюзивны наши системы в целом? Способны ли они поддержать многообразие общества, которому служат?

Концепция

Ответственное использование ВТ это и образ жизни, и образ мышления. Мировые технологии впитали в себя множество расовых стереотипов. Думая о дискриминации по цвету кожи, вспоминается такой привычный термин, как черный список. Нужно очень многое изменить. Разработчики должны осознавать, что созданный ими код будут использовать все. Конечно, мир не станет другим в одночасье. Это, скорее, как эффект бабочки, чей взмах крыла может вызвать торнадо на другом конце планеты. Нужно только верить, что за маленькими переменами идут большие последствия. Благодаря даже небольшим усилиям разработчиков сегодня можно добиться существенных результатов в будущем.

Реализация

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

Это действительно возможно, и у нас есть необходимые инструменты. Можно сопоставить общую эффективность кода и то, как быстро он выполняется. Уже за счет этого можно получить некоторое представление об углеродном следе. Также есть возможность измерить количество энергии, потребляемой центром обработки данных. Облачные провайдеры могут точно назвать свой объем выбросов CO2 за год. Они также знают, какая у них доля потребляемой энергии из возобновляемых источников.

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

Не кодом единым

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

Как, например, сделали победители конкурса Call for Code в прошлом году. Люди, как правило, стремятся нести добро в этот мир, и TheHeroLoop создали специальную платформу, которая объединяет единомышленников. Она дает людям возможность стать волонтером на локальном уровне и, допустим, помочь соседу с доставкой еды во время пандемии.

Разработчики Prometeo придумали необычный способ защитить пожарных. Их решение на базе интернета вещей (IoT) использует несложные и доступные технологии, давая рекомендации и советы пожарным тем самым увеличивая шансы на выживание в опасных ситуациях.

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

Присоединяйтесь к движению

Хотите стать участником Call for Code? Сделайте это сегодня.

Ссылка на оригинальный материал на английском: https://developer.ibm.com/blogs/call-for-code-earth-day/



Рашик Пармар, почетный сотрудник (IBM Fellow), вице-президент в регионе EMEA по технологиям IBM и член жюри глобального конкурса программистов Call for Code

Здравствуйте друзья!
Компания IBM предлагает вам поучаствовать в онлайн вебинаре.
6 августа (четверг)
Буквально за полтора часа у вас появится возможность разобраться в интересующих вас вопросах для дальнейшего создания собственных проектов.

• 13:00 Александр Гаврин, Solution IT Architect.
  Мастер-класс по созданию чат-бота с подключением к телеграмму.
• 13:45 Александр Халиков, Технический эксперт IBM Automation.
  Бизнес-логика в IBM Cloud Pak for Automation и как с ней работать
  
  Описание

  Как строить бизнес-логику без кода, развернуть приложение IBM Cloud Pak for Automation с нуля в облаке и подключить к нему ваши сервисы
  

Регистрация в облаке -
Вебинар

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

Что такое контролируемое обучение?

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

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

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

Что такое неконтролируемое обучение?

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

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

• Кластеризация это метод интеллектуального анализа данных, применяемый для группирования неразмеченных данных исходя из их сходств и различий. Например, в рамках алгоритмов кластеризации по K-средним похожие точки данных объединяются в группы, где значение K представляет размер группы и степень структурированности. Этот метод подходит для сегментации рынка, сжатия изображений и т.д.
• Ассоциация метод неконтролируемого обучения, в котором для выявления взаимосвязей между переменными и заданным набором данных используются определенные правила. Эти методы часто применяются для анализа покупательского поведения и создания рекомендательных сервисов и отбора товаров в категориях Вместе с этим товаром покупают.
• Снижение размерности это метод обучения, который используется в том случае, когда в определенном наборе данных слишком много признаков(или размерностей). Он сокращает количество входных данных до управляемого, сохраняя при этом их целостность. Этот метод часто используется на этапе обработки данных, например когда автокодировщики удаляют помехи из визуальных данных для повышения качества изображения.

Основная разница между контролируемым и неконтролируемым обучением: размеченные данные

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

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

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

Другие ключевые различия между контролируемым и неконтролируемым обучением

• Цели.Цель контролируемого обучения прогнозировать результаты по новым данным. Вы заранее знаете, какого рода результат ожидать. Цель неконтролируемого обучения получить полезную информацию из огромного объема новых данных. В ходе обучения машина сама определяет, какая информация из набора необычна или представляет интерес.
• Области применения. Модели контролируемого обучения идеально подходят для обнаружения спама, анализа тональности высказываний, прогнозирования погоды, изменения цен и т.д. Модели неконтролируемого обучения созданы для выявления отклонений, повышения эффективности рекомендательных сервисов, прогнозирования поведения клиентов и медицинской визуализации.
• Сложность.Контролируемое обучение это простой метод машинного обучения, который обычно рассчитывается с использованием таких программ как R или Python.Неконтролируемое обучение требует мощных инструментов для работы с большим количеством неклассифицированных данных. Модели неконтролируемого обучения отличаются высокой вычислительной сложностью, поскольку для получения необходимых результатов нужна большая обучающая выборка.
• Недостатки. Модели неконтролируемого обучения могут быть затратными по времени, а разметка входных и выходных данных требует опыта и знаний. Методы неконтролируемого обучения могут давать очень неточные результаты, если выходные переменные не будут валидироваться человеком.

Контролируемое и неконтролируемое обучение: что лучше?

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

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

Частично контролируемое обучение идеально подходит для работы с медицинскими снимками: небольшое количество учебных данных может значительно повысить точность. Например, врач-рентгенолог может пометить небольшой набор КТ-снимков с опухолями или патологиями, чтобы машина более точно выявляла пациентов, которым потребуется уделить больше внимания.

Подробную информацию о разработке моделей машинного обучения см. в бесплатных обучающих материалах на порталедля разработчиков IBM Developer Hub.

Джулианна Делуа (Julianna Delua)

Эксперт в области анализа и обработки данных/машинного обучения IBM Analytics

Исходный текст: https://www.ibm.com/cloud/blog/supervised-vs-unsupervised-learning

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



В конце 2015 года руководители рабочей группы почетный сотрудник и вице-президент IBM Джей Гамбетта (Jay Gambetta) и Джерри Чоу (Jerry Chow), ныне директор по разработке аппаратной части квантовых систем, заручившись поддержкой со стороны научного сообщества, предложили разместить квантовый процессор в облаке. Чтобы выйти на этот качественно новый этап, потребовались месяцы совместной работы представителей с нескольких континентов, направленные на развитие глобальной экосистемы квантовых вычислений.

Так, в рабочую группу для разработки ядра платформы и пользовательского интерфейса был приглашен эксперт по облачному ПО Исмаэль Фаро (Ismael Faro). К группе также присоединился сторонний дизайнер Карл де Торрес (Carl De Torres), который работал над внешним видом приложения. Рабочая группа хотела сделать акцент на устройстве с пятью кубитами. Математические операции, называемые квантовыми вентилями, связывали кубиты в квантовые схемы. Диаграммы, отображающие схемы и вентили, выглядели так же, как музыкальные ноты на нотном стане. Поэтому команда хотела получить интерфейс, который бы позволял интуитивно сочинять такие схемы. За пару выходных дней Фаро, прежде не имевший опыт работы с квантовыми устройствами, подготовил прототип веб-страницы и приложения и это оказалось именно тем, что хотела рабочая группа.


_{Макет концепции платформы IBM Quantum Experience, созданный в январе 2016 года (Фото: Исмаэль Фаро)}

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

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

Квантовые вычисления выходят в Интернет

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


_{Ученый-исследователь отдела квантовых вычислений IBM Антонио Корколес работает на планшете в квантовой лаборатории IBM рядом с открытым криогенным холодильником}

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

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

Система IBM Quantum Experience (теперь называется IBM Quantum) заработала 4 мая 2016 года. Ручеек быстро превратился в бурный поток: в первую неделю для работы с IBM Quantum Experience зарегистрировалось 7 тыс. пользователей, а к концу второй их число превысило 17 тыс.


_{Компоновка устройства IBM с пятью сверхпроводящими кубитами (Фото: IBM)}

Пожалуй, самые важные уроки были усвоены за первые несколько месяцев после запуска. Группа анализировала сотни отзывов пользователей и отслеживала собственные исправления, чтобы сделать работу удобнее и систематизировать процесс для ввода в продуктив еще большего числа квантовых устройств. Пока сотрудники, используя канал Slack, исправляли отдельные ошибки по индивидуальным запросам, велась работа над активным поиском более долговременных исправлений. Это было нужно для того, чтобы рабочая группа могла вернуться к разработке нового оборудования, а не выступать в роли службы технической поддержки для растущего парка процессоров.

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

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

Факты и цифры

Система облачного доступа к квантовым компьютерам IBM Quantum Experience поддерживает целый ряд квантовых систем, доступ к которым с помощью IBM Quantum Composer, IBM Quantum Lab и Qiskit получили исследователи, компании и активное сообщество Open Source разработчиков.

Сегодня на платформе IBM Quantum зарегистрировано более 325 тыс. пользователей. Каждый день тысячи разработчиков запускают на квантовых компьютерах IBM не менее двух миллиардов квантовых схем, и теперь им в этом помогает открытый набор средств разработки ПО Qiskit.

• Количество зарегистрированных пользователей: > 325 тыс.
• Количество скачиваний Qiskit: > 650 тыс.
• Количество научных статей, опубликованных благодаря использованию IBM Quantum: > 700
• Количество организаций в коммерческой сети IBM Quantum Network: > 140
• Количество выполняемых квантовых схем: > 2 млрд в день

Смотрите оригинальный материал на английском с дополнительными деталями, а также слушайте подкаст с участием российского победителя конкурса Quantum Challenge.