Otkrsist 03 2016 by endrustol

СУ БД

Открытые системы

№03 2016 ISSN 1028-7493 ИТ для бизнеса — архитекторам информационных систем

www.osmag.ru

СУБД: поколение Больших данных ISSN 1028-7493

•  Инструменты анализа графов

•  Платформы Индустриального интернета •  Процессоры для HPC и машинного обучения •  «Умное» хранение Больших Данных •  Ренессанс СУБД: проблема выбора

Источник: Daimler

Люди боятся полностью самоуправляющихся автомобилей

Только 10% участников опроса, проведенного исследователями Мичиганского университета, сообщили, что без всяких опасений готовы передвигаться на полностью самоуправляющихся автомобилях. У двух третей опрошенных такая перспектива вызывает умеренное или даже сильное беспокойство. Но если бы управление автомобилями было не полностью автоматизировано, то без опасений на них ездили бы 16% опрошенных, а с умеренным или сильным беспокойством — половина. Наконец, только 6% участников опроса готовы были бы ездить на самоуправляющемся автомобиле без руля и педалей. Остальные предпочли бы оставить средства ручного управления. Исследователи считают, что участники опроса ошибаются. Частично автоматизированное управление может быть опаснее полностью автоматизированного. Водитель частично автоматизированного автомобиля должен быть постоянно готов взять управление на себя, но ему трудно сохранять концентрацию внимания, если он не полностью вовлечен в процесс, отмечают исследователи.

Источник: Quinn Dombrowski/Flickr, CC BY-SA 2.0

AltOS

Приложение распознает несвежее пиво

В Мадридском университете разработали датчик и приложение для Android, оценивающие свежесть пива. Пивовары определяют его качество путем хроматографического анализа уровня содержания различных веществ, в том числе фурфурола — соединения, которое образуется по мере старения пива и придает ему несвежий привкус. Компактный датчик, который его создатели описали в журнале Analytical Chemistry, изготовлен из полимера, похожего на используемый для контактных линз. При взаимодействии с фурфуролом датчик, выполненный в виде диска, меняет цвет с желтого на розовый. Мобильное приложение, проанализировав снимок датчика, по его цвету определяет, пригодно ли пиво для употребления. Технология разработана по заказу пивоваренной компании, но, по словам исследователей, ее можно адаптировать и для других пищевых продуктов, в том числе для меда, молока и кофе.

Владельцы российских ресторанов могут перенять опыт своих зарубежных коллег, отказавшись от практики предоставления бесплатного доступа в Интернет своим посетителям. Об этом рассказал «Российской газете» президент Федерации рестораторов и отельеров России Игорь Бухаров. По его словам, американские маркетологи уже заметили, что использование Интернета клиентами ресторанной индустрии негативно сказывается на ней. Раньше бесплатный Wi-Fi был мотиватором, заманивающим клиентов в рестораны и заведения общепита, продолжает собеседник. Но сейчас подавляющее число посетителей, особенно молодежь, вместо того, чтобы активно заказывать еду, сидят в смартфонах, и это раздражает рестораторов, так как влияет на чек и потребление ресторанных услуг.

Источник: Solar Roadways

Рестораны против бесплатного Wi-Fi

В Миссури хотят замостить дороги солнечными батареями

В стартапе Solar Roadways разработали солнечные панели для мощения дорог, способные сделать наш мир похожим на виртуальную реальность из фильма «Трон»: такое дорожное покрытие может не только вырабатывать энергию, но также подогревать дорогу и светиться. Предполагается, что с помощью свечения можно будет создавать программируемую дорожную разметку. А еще энергетические дороги смогут подзаряжать электромобили. По замыслу разработчиков, дороги с солнечными батареями должны будут вырабатывать достаточно энергии для снабжения электричеством жилых домов и предприятий. Несмотря на кажущуюся утопичность идеи, Solar Roadways удалось заручиться поддержкой местных властей и пользователей сайта краудфандинга Indiegogo.

колонка редактора

Здесь и сейчас А

налитики и лица, принимающие решения, уже не довольствуются заранее подготовленными данными, которые, как правило, описывают прошедшие события, — им требуются сведения реального времени и инструменты, позволяющие мгновенно интегрировать, фильтровать, анализировать разноформатную информацию, поступающую в огромных объемах из различных распределенных в пространстве источников. Большие Данные, Интернет вещей и облачные хранилища требуют средств виртуализации данных, которые позволяют работать с ними там, где они нужны в конкретный момент времени, комбинируя новые инструменты с уже имеющимися в компаниях программами интеграции и анализа для реализации различных сценариев обработки сколь угодно глубоких «озер» данных. Естественно, рынок отвечает на такие запросы, и, например, только сегмент средств интеграции, составивший на конец 2015 года около 3 млрд долл., стабильно растет почти на 11% ежегодно. Изобилие типов данных и возможных срезов их исследования привело к появлению новых разнообразных сред их обработки: систем NoSQL и СУБД класса in-memory, Hadoop и архитектуры когнитивного хранения. Только различных СУБД сегодня насчитывается более 300, но ни одна из них не может поддержать всех запрашиваемых аналитиками сценариев, одновременно обеспечивая параллельное выполнение и масштабирование данных. Задачи анализа социальных сетей, например, требуют выполнения миллионов операций считывания и миллиардов операций записи в режиме реального времени, а СУБД NewSQL и Not-Only SQL, поддерживающие приложения для решения таких задач, различаются возможностями обработки массивов данных и пропускной способностью. Как разобраться в современном ландшафте СУБД, функциональность которых варьируется в широких пределах и нередко перекрывается? Что требуется для выбора решения, наилучшим образом подходящего для конкретной задачи? Авторы статьи «Ренессанс СУБД: проблема выбора», выступая в роли менеджеров по связям с реальностью, предлагают методику подбора систем управления базами данных, в наибольшей степени отвечающих конкретным потребностям.

За последние 60 лет емкость устройств хранения выросла на шесть порядков и продолжает увеличиваться. Новые типы устройств, например на базе флеш-памяти, обеспечивают повышение производительности, а средства компрессии и дедупликации данных в реальном времени позволяют строить системы хранения, эффективные для многих сценариев применения. Этого арсенала пока достаточно, чтобы справиться с экспоненциальным ростом объемов данных, но хватит ли возможностей нынешних технологий в будущем, сулящем продолжение стремительного накопленния данных и увеличение сложности систем их обработки? Рано или поздно темпы увеличения физического пространства хранения начнут отставать от темпов роста объемов данных и традиционная модель перманентного хранения всех данных упрется в нехватку ресурсов. Авторы статьи «Когнитивное хранение для Больших Данных» предлагают повысить эффективность систем хранения данных — не запоминать все подряд, а прежде разобраться в семантике данных, определить их ценность, что позволит и меньше хранить, и проще раскладывать по уровням хранения. Идея не нова, однако реальные «умные» хранилища, способные предсказать, где, что и как складировать, появляются только сейчас. Автоматически оценив соответствие данных потребностям и предпочтениям конкретной сферы применения, можно выбрать как, с каким уровнем защиты и как долго хранить информацию, что позволит добиться существенной экономии емкости хранения. Популярность разного рода когнитивных сервисов будет неуклонно расти, и к 2018 году ожидается, что половина всех разработчиков (против нескольких процентов сегодня) так или иначе будут заняты именно созданием «умных» систем, а объем рынка таких решений к 2020 году превысит 60 млрд долл. На протяжении почти полувека реляционные СУБД играли ключевую роль во многих областях деятельности, однако современным приложениям нужна функциональность, не свойственная этим системам, — в частности, требуется возможность изменения схем хранения и поддержки многообразия типов и моделей данных. Помимо этого, СУБД должна уметь элегантно, экономично и автоматически масштабироваться. Как считают авторы статьи «Операционные СУБД NoSQL: сегодня

и завтра», такие системы уже появляются и способны поддерживать мультимодельность данных. Конкуренция на рынке СУБД приведет к тому, что и разработчики продуктов NoSQL, и традиционные поставщики реляционных СУБД, включая и российских, таких как «Постгрес профессиональный», РЕЛЭКС и «Ред Софт», будут расширять круг применений своих систем, наращивая функциональность и заполняя пустые ниши. Суммарный доход от NoSQL-решений за период с 2013 по 2018 год оценивается в 14 млрд долл. — такие системы теснят крупных поставщиков реляционных СУБД, заставляя их вводить в свои решения все новые функции под угрозой потери клиентов. Опрос, проведенный аналитиками Forrester, показал, что по состоянию на середину 2016 года около 30% CIO уже применяют СУБД NoSQL, а еще 12% планируют это сделать. Среди лидеров называют MongoDB, Amazon DynamoDB, DataStax, MarkLogic, IBM Cloudant, Couchbase, Oracle NoSQL, MapR и Redis Labs. Такой интерес объясняется возможностями СУБД NoSQL эластично масштабироваться при работе с динамическими нагрузками; поддержкой гибких схем и моделей организации разных типов данных; обеспечением экстремально высоких скоростей чтения-записи; простотой и относительно низкой стоимостью управления. Однако, чтобы системы NoSQL достигли такого же уровня надежности и зрелости, как традиционные СУБД, предстоит решить еще немало задач — например, разработать стандарты, обеспечивающие переносимость приложений и исключающие привязку к производителю. Это станет одним из показателей того, что технологиями NoSQL можно пользоваться здесь и сейчас.  Дмитрий Волков

www.osmag.ru • 03/2016 • Открытые системы • 1

ОТКРЫТЫЕ СИСТЕМЫ. СУБД Журнал основан в 1993 году Главный редактор

Дмитрий Волков, с.н.с., ИПМ РАН

Научный редактор

Наталья Дубова

Редакционный совет: Валерий Аджиев, к.т.н., с.н.с., Национальный центр компьютерной анимации, Университет Борнмута (Великобритания); Фуад Алескеров, д.т.н., профессор, НИУ ВШЭ; Михаил Горбунов-Посадов, д.физ.-мат.н., зав. отделом ИПМ РАН, доцент, МГУ; Юрий Зеленков, д.т.н., зав. кафедрой прикладной информатики, Финансовый университет при Правительстве РФ; Сергей Д. Кузнецов, д.физ.-мат.н., профессор, МГУ; Сергей О. Кузнецов, д.физ.-мат.н., профессор, НИУ ВШЭ; Михаил Кузьминский, к.хим.н., с.н.с., ИОХ РАН; Александр Легалов, д.т.н., профессор, СФУ; Владимир Сухомлин, д.т.н., профессор, МГУ; Павел Храмцов, к.т.н., доцент, МИФИ; Игорь Федоров, к.т.н., профессор, МЭСИ; Виктор Шнитман, д.т.н., профессор, МФТИ; Леонид Эйсымонт, к.физ.-мат.н., научный консультант, НИИ «Квант» Корректор Ирина Карпушина Верстка и графика Мария Рыжкова Дизайн обложки Денис Кирков

Адрес для корреспонденции: 127254, г. Москва, а/я 42

Телефоны: +7 495 725-4780/84, +7 499 703-1854 +7 495 725-4785 (распространение, подписка) Факс: +7 495 725-4783 E-mail: osmag@osp.ru

Подписной индекс:

99482 — «Каталог российской прессы» (МАП) 72773 — Объединенный каталог «Пресса России» АПР 59869 — «Каталог. Издания органов научно-технической информации»

© 2016 Издательство «Открытые системы» Журнал зарегистрирован в Министерстве РФ по делам печати, телерадиовещания и средств массовых коммуникаций 03.07.2015 Свидетельство ПИ № ФС 77-62328 Журнал выходит 4 раза в год Цена свободная Выпуск издания осуществлен при финансовой поддержке Федерального агентства по печати и массовым коммуникациям

Учредитель и издатель: ООО «Издательство «Открытые cистемы» Россия, 127254, Москва, проезд Добролюбова, дом 3, комн.13 Президент Михаил Борисов Генеральный директор Галина Герасина Директор ИТ-направления Павел Христов Коммерческий директор Татьяна Филина Все права защищены. При использовании материалов необходимо разрешение редакции и авторов. В номере использованы иллюстрации и фотографии: ООО «Издательство «Открытые cистемы» и IEEE Computer Society. Отпечатано в ООО «Богородский полиграфический комбинат» 142400, Московская область, г. Ногинск, ул. Индустриальная, д. 40б (495) 783-9366, (49651) 73179

12+

Тираж 4 000 экз.

Содержание № 3 (213) 2016 Новости. факты. тенденции.

HPE поглощает SGI Работать с SQL как с Excel Облака — невозможно отказаться Сервис Google понимает человеческий язык Аналоговый компьютер смоделирует живые организмы Популярность ассемблера растет благодаря Интернету вещей Специалисты по программам с открытым кодом востребованы на рынке На SDN переведут сегмент сети «Ростелекома» в одном из российских регионов «Яндекс» открывает исходный код аналитической СУБД ClickHouse IBS выпустила серию «Скала-СР» для высоконагруженных СУБД и аналитических систем Open vSwitch стал проектом Linux Foundation MongoDB в облаке

В Фокусе: СУБД 8О перационные СУБД NoSQL: сегодня и завтра Джигнеш Пател

Операционные СУБД NoSQL — это пока новшество, не все еще понимают их возможности и отличия от традиционных реляционных систем управления базами данных.

12 Ренессанс СУБД: проблема выбора Венкат Гудивада, Дана Рао, Виджай Рагхаван

По мере роста потребностей в обработке Больших Данных появляются новые модели управления данными, позволяющие выполнять миллиарды запросов в секунду. Одновременно, чтобы не отстать от рынка, меняют и традиционные реляционные модели. Как разобраться в современном ландшафте СУБД и выбрать решение, наилучшим образом удовлетворяющее конкретным требованиям?

18 Инструменты анализа графов

Александр Смирнов, Дамир Гайнанов Программы поиска оптимальных маршрутов давно стали обыденностью, однако нахождение кратчайшего пути — не единственный практический результат теории графов, реализация методов которой стала возможной благодаря специальным СУБД и распределенным инструментальным средам.

20 Когнитивное хранение для Больших Данных Джованни Черубини, Дженс Джелитто, Винодх Венкатесан

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

платформы 26 Из ускорителей в процессоры Михаил Кузьминский

Летом 2016 года на рынке появилось второе поколение ускорителей Xeon Phi с архитектурой Knights Landing, что сулит изменения в инфраструктурах обработки Больших Данных.

менеджмент ИТ 29 Как повысить эффективность бизнеса? Антон Саввин

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

интернет вещей 32 На пороге Индустриального интернета вещей

Владимир Краюшкин, Марина Пирогова, Ирина Лешихина Интернет вещей пришел из мира повседневных «умных» устройств, а теперь настало время Индустриального интернета. Однако для развертывания Индустриального интернета требуется платформа разработки решений.

интеграция 34 Цифровая трансформация и BPM Юлия Вагнер, Мария Сефер

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

облака 36 Инструмент цифровой трансформации Анатолий Третьяков

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

мир 38 Работа на опережение Игорь Левшин

Ежедневно появляются сотни мобильных приложений, среди которых много критичных как для бизнеса, так и для жизнедеятельности общества. Лаборатория HPE Mobile Center выпускает инструменты для тестирования мобильных приложений, охватывающие практически все платформы и типы устройств.

41 «Чудеса» Льва Королева Руслан Смелянский

Машинный перевод, система ПРО и первая мультипрограммная ОС — эти и другие «чудеса», воплощенные в реальность Львом Николаевичем Королевым, которому 6 сентября 2016 года должно было бы исполниться 90 лет, заложили более полувека назад основы технологической независимости страны.

ИТ-университеты 44 ИСТИНА в науке и образовании Валерий Васенин, Сергей Афонин, Александр Козицын

Сегодня в Интернете доступны разнообразные данные о деятельности научных и образовательных организаций, представляющие интерес для подготовки и принятия управленческих решений. Однако все они, как правило, хранятся в базах с разной структурой, и для их обработки требуются системы, способные интегрировать сведения из различных источников. Одна из таких систем — система «ИСТИНА».

библиотека 46 ИТ для спасателей, кибербезопасность и будущее пользовательских интерфейсов Александр Тыренко

Темы майского, июньского и июльского номеров журнала Computer (IEEE Computer Society, Vol. 49, No. 5, 6, 7 2016) — применение ИТ в работе аварийно-спасательных служб, проблемы информационной безопасности в эпоху Третьей платформы и новые горизонты проектирования пользовательских интерфейсов.

новости. факты. тенденции.

Открытые системы

сегодня Новая MRAM похоронит флеш-память

Компании IBM и Samsung объявили о создании технологического процесса производства энергонезависимой памяти, которая работает в 100 тыс. раз быстрее флеш-памяти NAND и имеет практически неограниченный ресурс циклов чтения и записи. Компании разрабатывают магниторезистивную (MRAM) память следующего поколения с использованием технологии STT (spin-transfer torque), что позволит создавать более эффективные микросхемы памяти небольшой емкости для датчиков Интернета вещей, носимых устройств и мобильной техники, где сейчас используется флеш-память NAND. Если флеш-памяти NAND для записи данных требуется одна миллисекунда, то у MRAM эта процедура занимает всего 10 наносекунд. В обозримом будущем память STT MRAM вряд ли придет на смену микросхемам DRAM, но встроенную флеш-память она вполне способна потеснить.

HPE поглощает SGI

В Hewlett Packard Enterprise объявили о покупке компании SGI — эта сделка окончит семилетний период существования последней под данным наименованием после того, как Rackable Systems купила ставшую банкротом Silicon Graphics. Приобретение позволит HPE расширить свои возможности в области высокопроизводительных вычислений (HPC) и аналитики данных. По данным IDC, годов ой о б ъ е м р ы нка HPC — 11 млрд долл., а рост в следующие три года, по прогнозу, будет составлять 6–8%. В то же время тесно связанный с рынком HPC сегмент аналитики будет расти вдвое быстрее. В HPE отмечают растущую роль суперкомпьютеров в прогнозировании погоды, биологии, информационной безопасности и распознавании мошенничеств. SGI выпускает серверы, системы хранения данных и программные продукты, но жемчужиной продуктового ассортимента компании в последнее время стали системы линейки UV, выполняющие вычисления в памяти. В феврале HPE заключила с SGI соглашение о поставках системы на основе UV 300H — суперкомпьютера SGI, спроектированного специально для SAP HANA. Новый восьмипроцессорный сервер HPE заполнил нишу в линейке между ProLiant DL580 Gen9 и Integrity Superdome X. После завершения сделки, планируемого не позднее января 2017 года, SGI войдет в состав подразделения HPE Data Center Infrastructure Group.

www.osmag.ru • 03/2016 • Открытые системы • 3

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

Работать с SQL как с Excel

Сотрудники лаборатории искусственного интеллекта МТИ создали приложение, радикально упрощающее разработку интерфейсов для корпоративных баз данных. Обычно для этого нанимают программистов соответствующего профиля, и сложные запросы на SQL им приходится составлять вручную. Новая система, получившая название Sieuferd, выглядит подобно Excel, и, как обещают разработчики, в ней разберется любой, кто хорошо знает эту электронную таблицу. Запросы и отчеты в Sieuferd составляются с помощью выпадающих меню. Графический интерфейс позволяет переносить в систему данные из многих источников, сортировать и фильтровать их, группировать с помощью алгебраических функций, скрывать ненужные столбцы и строки и т. д. Основное меню имеет всего 17 позиций, большинство из которых покажутся знакомыми пользователям электронных таблиц. В докладе, посвященном системе, ее создатели доказывают, что этих несложных функций достаточно, чтобы составить любой возможный запрос, отвечающий стандарту SQL-92.

Облака — невозможно отказаться

Аналитики Gartner прогнозируют, что к 2020 году политика отказа от использования облаков на предприятиях станет такой же немыслимой, какой сегодня представляется политика отказа от Интернета. Если в предыдущие годы многие крупные поставщики программного обеспечения остерегались облаков, то сегодня облачная доставка ПО становится либо главной, либо единственной формой. Сейчас основная часть инноваций при разработке ПО распространяется прежде всего на облачные функции, а на локальные варианты новшества переносятся позднее. Аналитики убеждены, что облако станет стандартной платформой для развертывания ПО, в том числе разрабатываемого на заказ. В Gartner также уверены, что наиболее широко из всех видов облаков будут использоваться гибридные. Кроме того, аналитики прогнозируют, что к 2019 году больше 30% инвестиций в создание нового ПО, совершаемых 100 крупнейшими разработчиками, пойдет на продукты, предназначенные только для облаков различных видов. Согласно еще одному прогнозу, к 2020 году поставщики инфраструктуры в виде сервиса (IaaS) и платформ в виде сервиса (PaaS) будут продавать больше вычислительной мощности, чем будет добавляться в корпоративных центрах обработки данных. С 2011 года оборот рынка IaaS увеличивался больше чем на 40% в год, а до 2019 года включительно рост будет составлять 25%, предсказывают в Gartner. С ростом числа организаций, применяющих бимодальные ИТ и облачные сервисы, программно-конфигурируемые ЦОД ста-

4 • Открытые системы • 03/2016 • www.osmag.ru

Компания Google представила новый сервис Cloud Natural Language API, который должен помочь разработчикам в написании приложений, понимающих язык человека. Средства обработки естественного языка позволят разрабатывать приложения, анализирующие характер взаимодействия между людьми, а это, в свою очередь, станет ключом к созданию интеллектуальных цифровых помощников и роботов, способных общаться на естественном языке. В основу API положены те же исследования, что делались в Google при создании синтаксического анализатора английского текста Parsey McParseface. Общедоступная бета-версия нового интерфейса API была представлена вместе с API Speech, преобразующим записанную речь в текст. Объединение двух API позволит разрабатывать приложения, понимающие речь, а Google сможет укрепить свои позиции в борьбе с Microsoft, Amazon и IBM, которые также запускают интеллектуальные сервисы на своих общедоступных облачных платформах.

Облачные вычисления замедляют рост спроса на электроэнергию

За период с 2005 по 2010 год потребление энергии центрами обработки данных выросло на 24%, но с переходом на виртуализацию, облачные вычисления и оптимизированное управление ситуация меняется. По прогнозу авторов исследования, проведенного в Национальной лаборатории им. Лоуренса в Беркли, с 2014 по 2020 год потребление энергии вырастет лишь на 4%, несмотря на резкое увеличение потребности в вычислительных ресурсах. По данным исследования, общий расход электричества в дата-центрах США составил в 2014 году 70 млрд кВт×ч — 1,8% от общего потребления энергии в стране. Но, судя по нынешним тенденциям, в следующие четыре года этот рост почти остановится. С 2000 по 2005 год поставки серверов увеличивались каждый год на 15%, общее их количество в ЦОД за этот период почти удвоилось. В 2005–2010 годах ежегодный прирост уменьшился до 5%, в том числе из-за экономических проблем, а сейчас этот показатель — 3%, и, по прогнозу, он сохранится на этом уровне до 2021 года. Снижение обусловлено повышением энергоэффективности и более оптимальной загрузкой за счет виртуализации и перехода на облачные вычисления, в том числе благодаря сосредоточению задач в гипермасштабных ЦОД от 37 тыс. м2. В Google между те м нас т рое ны еще более оптимистично и считают, что общий расход электроэнергии к 2020 году снизится.

Источник: Facebook

Источник: MIT

Сервис Google понимает человеческий язык

новости. факты. тенденции.

Источник: MIT

Специалисты по программам с открытым кодом востребованы на рынке

Аналоговый компьютер смоделирует живые организмы

Головной мозг человека действует по принципу аналогового компьютера — хотя он и работает с дискретными сигналами, информация в цифровой форме не хранится. Ученые МТИ и Дартмутского колледжа объявили о разработке компилятора для аналоговых компьютеров — программы, транслирующей инструкции на высокоуровневом языке в описания соединений на схеме аналогового компьютера. Эта работа позволяет проложить путь к высокоточному аналоговому моделированию отдельных органов или даже целых организмов. На вход компилятору подаются дифференциальные уравнения, применяемые биологами для описания динамики происходящего в живых клетках. На выходе программа генерирует схемы протекания электрического тока через специально разработанный аналоговый чип. В принципе, отмечают авторы, компилятор может работать с любым программируемым аналоговым устройством. При выполнении простейшего теста из четырех уравнений компилятор сгенерировал аналоговую схему меньше чем за минуту, а на 75 уравнений у него ушло около часа. Разработка такой же схемы вручную заняла бы гораздо больше времени. Цитоморфные аналоговые схемы всего из нескольких транзисторов способны решать сложнейшие дифференциальные уравнения, тогда как электронным схемам для того же понадобились бы миллиарды транзисторов.

Популярность ассемблера растет благодаря Интернету вещей

Низкоуровневый язык ассемблера в последние годы уступил свои позиции высокоуровневым языкам, но благодаря устройствам Интернета вещей, на которых выполняется только код ассемблера, его популярность вновь начала расти. Согласно индексу Tiobe, оценивающему популярность языков программирования на основе количества поисковых запросов в Интернете, ассемблер в июле во второй раз в этом году вернулся на десятое место. Впрочем, аналитики полагают, что вряд ли он задержится в десятке надолго. В ближайшие месяцы его вполне могут потеснить Ruby, R или MatLab. В альтернативном индексе PyPL ассемблер занимает 18-е место. Если в формуле Tiobe учитывается множество поисковых ресурсов, то PyPL анализирует только поиск учебных материалов по языку в Google. Полностью первая десятка Tiobe выглядит следующим образом: Java (19,8%), C (12,2%), C++ (6,3%), Python (4,2%), C# (3,9%), PHP (3,3%), JavaScript (2,6%), Visual Basic.Net (2,5%), Perl (2,4%), ассемблер (2,3%). А в первую десятку индекса PyPL вошли: Java (23,8%), Python (13%), PHP (10,5%), C# (9%), JavaScript (7,7%), C++ (7,2%), C (7%), Objective-C (4,5%), R (3,2%) и Swift (3%).

65% менеджеров по подбору персонала, участвовавших в опросе, проведенном организацией Linux Foundation и кадровым агентством Dice, намереваются в ближайшие полгода уделять больше внимания найму сотрудников для работы с программами с открытым кодом, нежели для других направлений бизнеса. 79% менеджеров сообщили, что уже принимают различные меры для удержания таких специалистов на работе. Зарплаты специалистов по программам с открытым кодом остаются высокими, но, как и для многих других специалистов в ИТ, не они являются решающим фактором в выборе места работы. 31% опрошенных главной называют возможность работать над интересными проектами, 18% — быть на переднем крае технологий, а 17% — участвовать в деятельности международного сообщества. Только 2% опрошенных лучшей стороной своей работы считают деньги. Среди специалистов по программам с открытым кодом наиболее востребованными являются разработчики. 74% опрошенных менеджеров указали, что их компания ищет разработчиков. 58% отметили потребность в специалистах, знакомых с методикой DevOps, 51% — с облачными технологиями OpenStack, CloudStack и другими, 21% — с сетевыми технологиями.

На SDN переведут сегмент сети «Ростелекома» в одном из российских регионов

Центр прикладных исследований компьютерных сетей и компания «Сервионика» (группа «Ай-Теко») заключили договор о стратегическом партнерстве с целью продвижения отечественных решений SDN и NFV. Сотрудничество компаний начинается с пилотного проекта в «Ростелекоме»: на технологии SDN планируется перевести сегмент региональной сети в одном из регионов России. Особенностью решения станет широкое применение отечественных разработок, в их числе — созданные ЦПИКС программный коммутатор OpenFlow и SDN-контроллер RunOS, под управлением которого будет находиться весь сегмент сети. При этом будет обрабатываться реальный трафик более 11 тыс. абонентов. Сеть оператора в пилотном регионе должна заработать на новых технологиях уже с сентября, а завершение проекта ожидается в четвертом квартале 2016 года. В ходе проекта ЦПИКС отвечает за разработку стратегии внедрения SDN-решений в сеть оператора, предоставляет техническую поддержку второго уровня и проводит обучение специалистов «Сервионики», в задачи которых будут входить подготовка и инсталляция компонентов аппаратной платформы и техническая поддержка первого уровня. SDN (Software Defined Networking — «программно-конфигурируемые сети») и NFV (Network Function Virtualization — «вирт уализация сетевых функций») — новое поколение архитектурных решений, более гибких и ориентированных на поддержку облачных технологий. Использование этих инструментов позволяет снижать затраты на развитие сети, что критически важно для эффективности бизнеса операторов связи.

www.osmag.ru • 03/2016 • Открытые системы • 5

новости. факты. тенденции. «Яндекс» открывает исходный код аналитической СУБД ClickHouse

«Яндекс» решил опубликовать исходный код ClickHouse — распределенной системы управления базами данных, разработанной для сервиса веб-аналитики «Яндекс.Метрика», сообщили в компании. Технология не ограничивается аналитикой сайтов и приложений и может быть использована в телекоммуникациях, рекламе, онлайн-торговле, для обработки данных мониторинга и телеметрии, а также для решения задач информационной безопасности, рассчитывают в «Яндексе». ClickHouse хранит и быстро обрабатывает большие объемы информации для создания аналитических отчетов. Система масштабируется и позволяет хранить записи о триллионах событий. Как поясняют в компании, система опробована на задачах «высоконагруженных сервисов» «Яндекса»: ClickHouse применяется не только в «Метрике», где используется для хранения всех данных для отчетов, но и в «Маркете», «Почте», «Директе», «Вебмастере», для бизнес-аналитики и в мониторинге инфраструктуры. Интерес к ClickHouse уже проявила «Почта России», использующая для разных типов задач инструменты на основе открытого кода. Так, для хранения и обработки данных применяются Hadoop, Cassandra и PostgreSQL. «Почта России» планирует использовать ClickHouse как один из компонентов разработки и формирования онлайн-отчетности.

Источник: IBS

IBS выпустила серию «Скала-СР» для высоконагруженных СУБД и аналитических систем

IBS представила программно-аппаратные комплексы «СкалаСР» для решения специализированных задач. Они продолжают серию вычислительных платформ, представленную год назад. Среди разработанных решений — кластеры серверов «Скала-СР / Postgres Pro» и «Скала-СР / Oracle DB», предназначенные для высоконагруженных СУБД, а также гиперконвергентный комплекс «Скала СР / Аналитика» для аналитических систем, обрабатывающих данные в оперативной памяти. Платформа «Скала» — это инжиниринговый продукт компании IBS и ее партнеров: Depo Computers, «Росп латформы», Mellanox и Raidix. Она представляет собой полностью сконфигурированную гиперконвергентную систему и создана на основе отечественных решений. Продукт защищен комплексом средств ИБ и готов к сертификации ФСТЭК. Как утверждают разработчики, платформа не уступает иностранным аналогам по производительности, будучи при этом на 40% доступнее по цене.

6 • Открытые системы • 03/2016 • www.osmag.ru

Open vSwitch стал проектом Linux Foundation

Разработчики программного коммутатора с открытым кодом Open vSwitch (OVS) объявили о том, что он переходит под эгиду Linux Foundation, некоммерческого консорциума по развитию Linux. Инициаторы миграции проекта рассчитывают, что теперь доступ к нему смогут получить больше разработчиков. OVS предназначен для выполнения в гипервизорах и на системах с виртуальными машинами. Коммутатор может работать в Linux, FreeBSD и Hyper-V. Он широко применяется для виртуализации сетевых функций и лидирует по частоте использования в качестве сетевого уровня в развертываниях OpenStack, сообщают в Linux Foundation. С переходом под эгиду организации техническая схема руководства проектом останется без изменений. В разработке OVS принимают участие специалисты компаний Cisco, Ericsson, Huawei, HP, IBM, Intel, Red Hat и VMware. Недавно в Linux Foundation также был переведен OpenSwitch, став первым проектом полноценной сетевой ОС, развивающимся в рамках консорциума. В отличие от OVS, OpenSwitch предназначен преимущественно для работы на аппаратных коммутаторах top-of-rack.

Искусственный интеллект Google будет спасать жизни

Успех программы AlphaGo в игре го, сумевшей выиграть у чемпиона по го из Южной Кореи четыре партии из пяти, многими был воспринят как окончательный приговор доминированию человеческого интеллекта, но исследователь из Google Дэвид Сильвер не столь категоричен и предлагает вместо этого обратить внимание на потенциальные преимущества новой технологии. Будучи одним из ведущих архитекторов системы AlphaGo, Сильвер убежден в том, что технологии искусственного интеллекта должны повысить эффективность системы здравоохранения. Игра го, где число возможных комбинаций на доске превышает количество атомов во Вселенной, долгое время считалась самым сложным вызовом для исследователей в области искусственного интеллекта. Сначала AlphaGo обучалась на партиях экспертов, а затем миллионы раз сыграла сама с собой. В отличие от системы IBM DeepBlue, которая создавалась специально для того, чтобы победить Гарри Каспарова, AlphaGo использует нейронные сети и общие методы глубинного обучения, которое со временем трансформируется в самообучение. В начале текущего года в подразделении Google DeepMind была сформирована медицинская группа, и теперь совместно со специалистами Moorfields Eye Hospital она сосредоточится на применении технологий машинного обучения и других наработок AlphaGo в диагностике и лечении диабетической ретинопатии и возрастной макулярной дегенерации.

новости. факты. тенденции. MongoDB в облаке

Популярная СУБД NoSQL с открытым кодом MongoDB выпущена в виде управляемого облачного сервиса с почасовой оплатой. Сервис, получивший название Atlas, заботится о резервировании ресурсов, конфигурировании, установке заплат, обновлениях, резервном копировании и восстановлении после сбоев, позволяя разработчикам сосредоточиться на создании приложений. На сегодня экземпляры Atlas доступны в Amazon Web Services, позднее они также будут предлагаться в облаках Microsoft Azure и Google Cloud Platform. Новый кластер в облаке можно построить меньше чем за 10 минут — надо выбрать имя, местонахождение и размер экземпляра, желаемый размер памяти и пространства хранения, а также количество узлов для тиражирования (от 3 до 7). Поддерживается создание томов с шифрованием и сегментированных (sharded) кластеров.

Планы Oracle для виртуальной машины Java

На конференции Oracle JVM Language были обнародованы планы по дальнейшему развитию виртуальной машины Java, которая должна оставаться «полиглотом»: возможно, со временем, помимо нынешних Scala и Groovy, появятся компиляторы в байткод JVM даже для Си и C++. При этом в Oracle намерены сохранить обратную совместимость, чтобы на JVM могли работать «пыльные JAR-файлы тридцатилетней давности». Упомянуты были также усовершенствования в области «Java на Java», помогающие развиваться проектам вроде Graal, в рамках которого функциональность виртуальной машины экспонируется

через Java API, что позволяет на самом Java писать компиляторы и среды выполнения. Родственный проект — Panama, он направлен на обеспечение интероперабельности Java и C++. Доработки в области масштабируемости виртуальной машины создадут лучшие условия для параллельного выполнения независимых микросервисов под ее управлением — «от единиц до миллионов», как объясняют в Oracle. Поддержка микросервисов реализуется корпорацией и в платформе Java EE. Наряду с этим планируются усовершенствования системы типов, поддерживаемых JVM, и доработки, направленные на повышение производительности с использованием возможностей самых современных процессоров.

Microsoft улучшает средства разработки на Node.js

Корпорация Microsoft обновила инструментарий с открытым кодом Node.js Tools for Visual Studio, выпустив его в версии 1.2. Обновление рассчитано на использование с Visual Studio 2015. Важными отличиями Node.js Tools 1.2 стали более быстрая работа инструментария с технологией автозавершения кода IntelliSense и поддержка в последней пространства имен стандарта ECMAScript 6, основы JavaScript. Как сообщают в Microsoft, IntelliSense работает с популярными фреймворками Node.js, в том числе Commander, Express, jQuery и Knockout. В Node js Tools 1.2 также повышены стабильность и быстродействие; снижено число ошибок переполнения памяти, ускорена загрузка проектов; усовершенствован отладчик, устранена проблема с контрольными точками, на которую жаловались пользователи, и другие; улучшены средства модульного тестирования.

Технологии для Больших Данных В Москве прошла конференция «Технологии Больших Данных», организованная издательством «Открытые системы» и посвященная решениям, предлагаемым сегодня для обработки больших массивов данных и применяемым в различных отраслях национальной экономики. На конференции были представлены как достижения глобальных корпораций, производящих соответствующее ПО и осуществляющих аппаратное обеспечение, так и разработки с открытым исходным кодом. Работа пленарной сессии началась с разбора современных платформ NoSQL, затем обсуждались проблемы искусственного интеллекта — эта тема пронизывала почти все доклады конференции. Компания Finstar Labs представила свои достижения в понимании машиного языка отзывов в Интернете, на основе анализа которых планируется сделать поисковик, помогающий выбрать лучший вариант рекомендательного сервиса с набором нужных пользователю свойств. В МТС обработка Больших Данных используется среди прочего для определения потенциально нелояльных клиентов. Другая задача — определение качества связи. Проблемами лояльности обеспокоены и банки: компания Rubbles (SBDA Group) предлагает банкам мобильное приложение для исследования поведения клиента. Представитель компании «СКБ Контур», работающей с Федеральной налоговой службой, рассказал о решении, позволяющем сверять собранные в автоматическом режиме «торговые книги» всех отечественных компаний. Доклады о популярных СУБД PostgreSQL и MySQL соседствовали с сообщениями разработчиков таких пока еще экзотических платформ, как Tarantool, которая представляет собой СУБД NoSQL с открытым кодом и сервер приложений на языке Lua. Этот новый проект уже может похвастаться высокой производительностью обработки запросов. Графовые СУБД были представлены

Технологии БОЛЬШИХ ДАННЫХ

на конференции системой OrientDB. Не была забыта и старейшая российская разработка — СУБД «Линтер» компании «РЕЛЭКС». «1С-Битрикс» и SAP Labs, Intel и Microsoft поделились с участниками конференции своими взглядами на инструменты работы с Большими Данными. Медицинская наука была представлена Лечебно-реабилитационным центром РАМН, сотрудники которого интенсивно работают с Большими Данными. В НИЦ «Курчатовский институт» работают над тем, чтобы преодолеть ограничения систем бизнес-анализа, черпающих данные из распределенных хранилищ. В докладе представителя компании «Сбербанк-Технологии» разбирался опыт решения задачи борьбы с кредитным фродом с использованием методов обработки транзакций, биометрии, анализа текста анкет и поисковых запросов, а также изучения данных социальных сетей. Но есть области применения машинного обучения, где прогресс уже стал буквально вопросом жизни и смерти. Для поиска злоумышленников необходимо уметь надежно распознавать лица, обрабатывая видеопотоки с камер в реальном времени. В компании «Техносерв» для этого применяют не только интеллектуальное ПО, но и графические ускорители.

www.osmag.ru • 03/2016 • Открытые системы • 7

в фокусе: СУБД

Операционные СУБД NoSQL: сегодня и завтра Операционные СУБД NoSQL — это пока новшество, не все еще понимают их возможности и отличия от традиционных реляционных систем управления базами данных. Ключевые слова: архитектуры для обработки транзакций, системы поддержки принятия решений Keywords: architecture for transaction processing, decision support systems, NoSQL

Джигнеш Пател

о мере роста применения средств работы с Большими Данными к СУБД предъявляются все более высокие требования с точки зрения производительности и масштабируемости. На протяжении последних четырех десятков лет реляционные СУБД играли ключевую роль во многих областях деятельности, однако современным приложениям нужна функциональность, не свойственная этим системам, в том числе возможность изменения схем, а также поддержка многообразия типов и моделей данных. Помимо этого, новым СУБД нужно уметь элегантно, экономично и автоматически масштабироваться. Элегантность — возможность добавления узлов по мере роста объемов данных для сохранения гарантированной скорости выполнения запросов. Автоматизм — способность сбалансированно распределять данные по мере добавления узлов. А благодаря экономичности затраты на развертывание должны снижаться по мере совершенствования аппаратного обеспечения. Иначе говоря, экономия, достигнутая за счет снижения затрат на вычисления и хранение, распространяется на общую стоимость внедрения и эксплуатации СУБД. Все три названные характеристики присущи СУБД NoSQL, и хотя их название намекает на противопоставление базам SQL, к нереляционным могут относиться и системы, поддерживающие как SQL, так и другие способы опроса. Системы NoSQL были созданы, чтобы расширить, а не заменить функционал реляционных СУБД.

По сути, многие свойства NoSQL-систем не новы и не уникальны. Главное отличие в том, что в системах NoSQL акцент делается на другом наборе функций. Системы NoSQL бывают операционными и аналитическими (см. врезку). О первых говорят редко, и их особенности известны хуже [1], хотя системы NoSQL стремительно развиваются и функциональные границы между ними стираются. Начали появляться системы, поддерживающие многие модели данных, и эта тенденция сохранится, причем ожесточенная конкуренция на рынке СУБД позволяет предположить, что разработчики продуктов NoSQL будут расширять круг их применений, заполняя пустые ниши.

Определяющие особенности

Из рисунка можно понять, какие характеристики привлекают заказчиков в системах NoSQL.

Главные общие черты

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

ской активности на торговых онлайнплощадках вроде eBay или Craigslist. По мере изменения приложений, на которых базируются эти площадки, сохраняется все больше данных в расчете на каждого пользователя и каждое его действие. Согласно нормативным требованиям, могут также понадобиться запись дополнительной информации и хранение старой в течение определенного периода времени. Управление подобными данными с помощью традиционных реляционных СУБД, не предполагающих изменения однажды созданной схемы, невозможно: в достаточно сложной среде даже для простого изменения схемы, например для добавления одного столбца, может потребоваться неделя. В системах NoSQL этой проблемы нет: в них часто используется документная модель данных, когда база представляет собой коллекцию документов, или модель «ключ-значение», в которой данные представлены в виде соответствующих пар. В таких системах можно вначале загрузить данные, а уже потом определять и переопределять схемы. Гибкие модели данных позволяют, например, держать в одной и той же коллекции две записи с переменным числом описательных атрибутов. Процессы управления данными (например, контроль изменений и версий схем) протекают проще, а времени на внедрение новой функциональности требуется гораздо меньше. Гибкость запросов. С использованием гибких схем тесно связана еще одна особенность — возможность применения гибких методов поиска по базе запросов, состав-

8 • Открытые системы • 03/2016 • www.osmag.ru

в фокусе: СУБД ленных в свободной форме на основе регулярных выражений, и поиска по ключевым словам. Гибкость запросов особенно полезна, когда система NoSQL служит одновременно и как репозиторий метаданных для описания гетерогенных срезов данных, и как средство обнаружения этих срезов. Такой сценарий применения преобладает в организациях, в которых данные хранятся разрозненно. Разобщенные источники данных в этом случае появляются вследствие роста объемов информации в различных отделах или поглощенных компаниях. На предприятиях нередко хранят данные в отделах (маркетинга, продаж, бухгалтерии, кадров и т. д.), чьи функции, как правило, не связаны друг с другом. Приложения работы с Большими Данными меняют ситуацию: они дают возможность руководителям исследовать весь объем данных организации и, таким образом, принимать более обоснованные решения. Идеальным вариантом было бы существование единственной оптимальной схемы данных для всей информации предприятия, которую использовали бы все приложения. Но этой идиллии не суждено воплотиться в жизнь, по крайней мере пока не будет предложен простой способ обнаружения связей между разобщенными гетерогенными данными. Сегодня эти связи устанавливаются путем создания метаданных, описывающих основные данные и сохраняемых в системе NoSQL. Гибкие механизмы опроса позволяют выполнять поиск в метаданных по ключевым словам. Гибкость опроса обеспечивается, в частности, когда система NoSQL хранит данные в формате типа JSON, позволяющем делать прямые запросы к JSON-документам. При этом можно запрашивать не только значения атрибутов (как в реляционных СУБД), но и элементы схемы. Гибкие механизмы опроса и схемы позволяют анализировать квазиструктурированные срезы данных и проводить предварительный анализ. К системам NoSQL, которым присуща такая гибкость, относятся документные хранилища MongoDB, CouchDB и MarkLogic. Разработку гибких методов опроса можно уподобить работе по обеспечению возможности поиска по ключевым словам, проделанной для реляционных СУБД, однако системы NoSQL позволяют менять схемы данных и предоставляют больше гибкости при заполнении и использовании базы. Также активно идет исследование методов опроса XML-баз, а во многих системах NoSQL появились средства помощи в выполнении запросов — например, встроенные механизмы индексации текста.

Простота эксплуатации. Традиционные одноузловые либо функционирующие в пределах одного ЦОД системы обработки данных сложно администрировать в динамике, и особые трудности возникают при попытке оптимизации их быстродействия по мере роста размеров базы и изменения нагрузки по обработке запросов. Поэтому большинство современных систем обработки данных работают в кластерных средах, собранных из стандартных компонентов, что, однако, еще больше усложняет администрирование, поскольку нужны механизмы, позволяющие прозрачно для приложений справляться со сбоями многочисленных комплектующих. В строгих соглашениях об уровне обслуживания (service-level objectives, SLO) нередко диктуется необходимость обеспечения высокой доступности и быстродействия в круглосуточно активных средах — эти требования выполняются путем автоматического сегментирования данных, балансировки нагрузки и аварийного переключения с использованием тиражирования. Поддержка соответствующих функций должна быть изначально встроена в платформу обработки данных, а не реализована после основной разработки. Кроме того, эти функции должны автоматически адаптироваться при увеличении или уменьшении кластера. Выполнение требований доступности затрудняется в случае распределения среды по нескольким центрам обработки данных: чтобы приложения обеспечивали заданный уровень обслуживания географически распределенных пользователей, обработка этих приложений должна быть тоже распределена между несколькими ЦОД. Примеры таких приложений: рекламные платформы, которым приходится практически мгновенно принимать решения

о выборе объявлений, или мобильные игры, предоставляющие в реальном времени доступ к единому постоянно меняющемуся срезу данных. Подобно кластерным, среды из нескольких ЦОД нуждаются в механизмах тиражирования, управления сбоями и автоматической балансировки нагрузки. Но такими средами сложнее управлять, поскольку задержка передачи по сети между ЦОД гораздо больше, чем между узлами в одном и том же центре. Сообщество. У систем NoSQL обычно имеется обширное сообщество, включающее разработчиков самой системы и разработчиков приложений. Большинство систем NoSQL открыты, что дает дополнительные стимулы для совместного планирования дальнейшего развития продукта. Вокруг систем NoSQL также нередко образуется активное сообщество пользователей. Росту сообщества способствует простота развертывания и тестирования многих систем NoSQL, которые разрабатываются без расчета на обязательное наличие в организации администратора базы данных. Простота использования — большой плюс по сравнению с тяготами освоения некоторых традиционных реляционных СУБД. Усилия по повышению продуктивности труда разработчиков приложений, вкладываемые создателями NoSQL-систем, сполна окупаются — небольшие проекты нередко разрастаются в крупные, занимая постоянное место в экосистеме предприятия. В подобных случаях разработчики приложений, некогда впервые попробовавшие поработать с той или иной системой NoSQL, становятся ее проводниками в своей организации. Именно поэтому создатели систем NoSQL стараются обеспечить максимальную простоту начала использования.

Классы систем NoSQL

Реляционные базы данных обычно используются либо для оперативной обработки транзакций (Online Transaction Processing, OLTP), либо в системах поддержки принятия решений (Decision Support System, DSS). Рабочие задачи OLTP обычно состоят из кратких запросов, требующих считывания или обновления небольшого количества кортежей или записей. Пример такой задачи — система ввода заказов, размещающая в базе записи о новых заказах и извлекающая существующие. Задачи DSS состоят из сложных запросов, требующих просмотра, соединения или агрегации данных из одной или более таблиц. Например, анализ тенденций продаж обычно выполняется с помощью движка DSS. Системы NoSQL по аналогии тоже можно разделить на два основных класса: операционные, соответствующие СУБД для OLTP, и аналитические, соответствующие СУБД для DSS. Подобно реляционным системам OLTP, операционные системы NoSQL являются транзакционными. К ним относятся Aerospike, Cassandra, Couchbase, DynamoDB, HBase, MarkLogic, MongoDB, Oracle NoSQL, Redis и Riak. В отличие от них, аналитические системы NoSQL основаны на MapReduce, Hadoop и Spark. Так же как и реляционные СУБД, аналитические и операционные системы NoSQL имеют свои области применения и в значительной степени присутствуют на независимых рынках.

www.osmag.ru • 03/2016 • Открытые системы • 9

в фокусе: СУБД Перспективы

каждого пользователя в базе и легко обращаться к ней.

Контролируемая согласованность

Направления дальнейшей работы

Бесконфликтные тиражируемые структуры данных Ускорение за счет возможностей современного оборудования Универсальность Разработка эталонных тестов и стандартизация

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

Дополнительные отличительные особенности Прогнозируемое быстродействие Сложные структуры данных

Общие основные особенности Изменяемые схемы

Гибкость запросов

Простота эксплуатации

Сообщество

Низкая стоимость

Текущие характеристики и прогнозируемые направления развития систем NoSQL Низкая стоимость. Традиционные СУБД продавались на условиях лицензирования, но позволить себе платить за лицензии могли далеко не все, что стало одним из факторов, побудивших к разработке систем NoSQL. На предприятиях, внедряющих технологии Больших Данных, объемы информации обычно растут быстрее, чем доходы, а многие системы NoSQL имеют открытый код и доступны бесплатно. Крупные предприятия нередко покупают сервис, связанный с СУБД NoSQL, но все равно совокупная стоимость продукта и услуг поддержки оказывается гораздо ниже, чем у традиционных реляционных СУБД.

Дополнительные особенности

Некоторые операционные системы NoSQL характеризуются прогнозируемым быстродействием и поддержкой сложных структур данных. Прогнозируемая производительность. Для многих современных приложений работы с данными прогнозируемое быстродействие важнее, чем фиксированный уровень производительности, особенно когда речь идет о масштабировании для работы со все более обширными срезами данных. Таким образом, если у СУБД ниже абсолютное быстродействие при выполнении стандартного запроса, но этот уровень производительности неизменно сохраняется, то это станет преимуществом. Пример — приложение для обмена сообщениями. Допустим, система должна извлечь сообщение из базы, когда пользователь открывает приложение, и, чтобы создавалось впечатление отзывчивости сервиса, у системы есть лишь ограниченное время на отклик. При разработке подобного приложения программисту будет гораздо удобнее зарезервировать

заданный период времени на обслуживание запросов к базе, чтобы можно было рассчитывать, что движок СУБД с большой вероятностью уложится в это время. Гораздо важнее, чтобы эта вероятность составляла 95–99%, чем чтобы показатели среднего или наилучшего времени отклика были на определенном уровне. Некоторые традиционные системы обработки данных можно сконфигурировать так, чтобы их быстродействие было более предсказуемым, но это обычно достигается за счет избыточности ресурсов и приводит к непозволительно высоким затратам на внедрение. Сложные структуры данных. При работе с традиционными СУБД возникали трудности из-за несоответствия между типами данных, поддерживаемыми моделью и средами разработки приложений. Проблему пытались решить, в частности, путем реализации поддержки объектов в реляционных СУБД и создания объектноориентированных баз, что способствовало росту популярности объектно-ориентированных языков программирования. Однако в большинстве современных реляционных СУБД поддержка сложных коллекционных структур данных ограничена. Системы NoSQL нередко используются приложениями, сохраняющими информацию о состоянии в таких структурах, как списки и упорядоченные множества. К примеру, в игре нужно вести учет показаний доски рекордов. Если модель данных NoSQL поддерживает упорядоченные множества в качестве объекта первого класса, то историю показаний доски рекордов можно будет без проблем сохранять в базе. Многие системы NoSQL поддерживают такие структуры данных, как счетчики, списки, стеки, карты, кэши и упорядоченные множества [2]. Благодаря этому приложения могут сохранять информацию о состоянии для

10 • Открытые системы • 03/2016 • www.osmag.ru

Контролируемая согласованность

Ранние системы NoSQL обычно не отвечали стандартным требованиям к транзакционным системам — ACID (atomicity, consistency, isolation, durability — атомарность, согласованность, изолированность, долговечность), применяя вместо этого модель BASE (basic availability, soft state, eventual consistency — базовая доступность, негарантированное сохранение состояния и возможная согласованность). Эта модель предъявляет менее строгие требования к согласованности, допуская временное расхождение копий одних и тех же данных, вследствие чего в определенных ситуациях увеличивается доступность распределенной системы. Но нередки случаи, когда системы NoSQL обеспечивают ограниченное соответствие ACID, а СУБД Google Spanner довольно близко подходит к полному выполнению требований к транзакционным системам. Сегодня наблюдается тенденция к обеспечению поддержки нескольких моделей согласованности, что предоставляет приложению возможность выбирать различные компромиссы. В каком-то смысле такой отход от BASE-согласованности — это заимствование у традиционных СУБД, в которых издавна существует возможность варьирования уровней согласованности. Одно из интересных направлений дальнейших исследований состоит в том, чтобы помочь разработчикам приложений разобраться с последствиями выбора различных уровней согласованности для разных сценариев. Стоит также изучить влияние различных вариантов согласованности на быстродействие в условиях многоцентровых сред с разными нагрузками — например, с большим количеством операций записи либо чтения.

Бесконфликтное тиражирование структур

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

в фокусе: СУБД вости применяется тиражирование, в том числе в системах, распределенных между несколькими ЦОД с большой задержкой передачи между центрами.

Аппаратное ускорение

Современная экосистема серверного оборудования сильно отличается от того, что было еще несколько лет назад. В нынешних системах стало нормой использование большого числа многоядерных процессоров, обширной основной памяти и систем хранения данных на твердотельных накопителях. Задействование возможностей современного оборудования — важное направление работ, особенно для поиска экономически эффективных способов сохранения прогнозируемого быстродействия и хорошей масштабируемости в многоцентровых средах. В некоторых операционных системах NoSQL, например Aerospike, были сделаны большие шаги к достижению этих целей, однако постоянно меняющаяся аппаратная экосистема и вечная потребность в расширении функциональности (например, при разработке интегрированных средств поиска по документам предприятия) создают массу сложностей при проектировании схем, оптимизации запросов и обработке транзакций. Связанная с этим проблема — выбор способа развертывания сервисов на основе СУБД NoSQL, что традиционно осуществлялось локально и требовало инсталляции и администрирования. С переходом на облачную обработку данных соответствующие задачи передаются оператору облака, при этом обычно заключаются соглашения об уровне обслуживания, в которых могут быть указаны заданные значения быстродействия или доступности. В интересах провайдера облака предложить максимально привлекательные цели обслуживания, минимизируя при этом общую стоимость развертывания и поддержки конфигурации заказчика. Внедрение СУБД, рассчитанных на локальную установку, в облачных средах сопряжено с многочисленными трудностями, обусловленными совместным доступом многих пользователей облака к оборудованию: контроль приватности и безопасности приходится сочетать с одновременным выполнением условий соглашений об уровне обслуживания для всех заказчиков. Еще одна область, представляющая интерес, — реализация системы управления данными в виде гибридного сервиса. Некоторые системы NoSQL работают только в облаке, но нередко предприятиям нуж-

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

Универсальность

Некоторые специалисты по СУБД считают, что универсальность недостижима и для каждого класса приложений необходимо разрабатывать свои движки по обработке данных. Но внедрять слишком много платформ данных в пределах одного предприятия непрактично: наличие отдельной платформы для различных документных хранилищ, приложений, работающих с ключами и значениями, поточными данными, а также для поддержки разных видов аналитической обработки (графы, реляционная модель и т. д.) усложнит администрирование, при этом вырастет общая стоимость развертывания, снизятся темпы внедрения новых приложений и сервисов, работающих с данными. При наличии N платформ данных накладные расходы на синхронизацию всех систем и обеспечение единства обзора данных предприятия растут со скоростью N 2. Одно из решений — объединение нескольких функционалов в одной системе NoSQL, например интеграция Apache Solr и Cassandra. Распространена также интеграция Hadoop с аналитическими системами: многие операционные базы NoSQL как минимум поддерживают возможность обмена данными с файловой системой HDFS. Представляет также интерес исследование целесообразности еще более плотной конвергенции, и этот процесс уже идет, если судить по изменению позиционирования некоторых продуктов. В частности, MarkLogic изначально была системой управления XML-данными, а теперь у нее есть функции NoSQL; СУБД Couchbase начиналась как хранилище данных, а затем приобрела черты документного хранилища. Еще одна проблема, достойная изучения, — компромиссы между быстродействием и функциональностью, на которые приходится идти по мере роста масштаба платформы NoSQL и приобретения ею дополнительных функций, уже предлагаемых другими системами.

Эталонные тесты и стандартизация

Появление в 1980-х годах эталонных тестов оценки реляционных СУБД заставило разработчиков этих систем сфокусироваться на производительности, что со временем принесло свои плоды. Аналогичные инициативы могут помочь и NoSQL, однако здесь имеются сложности с разработкой теста, точно воспроизводящего характеристики среды, в которой работает NoSQL-система, а также с получением поддержки тестов со стороны широкого круга поставщиков NoSQL-систем. Стоит отметить, что такие системы нередко классифицируют по следующим перекрывающимся подкатегориям: документные хранилища (MongoDB и MarkLogic), поколоночные хранилища (Cassandra и HBase) и хранилища пар «ключзначение» (Aerospike, Couchbase, Oracle NoSQL, Redis и Riak). Для каждой подкатегории существуют свои сферы применения, однако не исключена возможность создания единого эталонного теста, который охватывал бы все сценарии, особенно с учетом прогнозируемой консолидации функционала СУБД NoSQL. Для интерфейсов программирования и языков, применяемых для взаимодействия с операционными системами NoSQL, нужны стандарты — это еще одно направление исследований. Стандарты языков можно было бы начать развивать с заимствованиями из SQL — многие соответствующие функции уже сегодня есть в новых языках запросов. Есть даже инициативы по созданию языков, целиком основанных на SQL; один из них — язык запросов СУБД Cassandra. *** Исследователи в области СУБД сегодня активно занимаются задачами, связанными с проектированием, разработкой и развертыванием нереляционных систем, способствуя развитию коммерчески доступных решений. 

Литература 1. D. Feinberg, M. Adrian. The OLTP DBMS

Market Becomes the Operational DBMS Market. Gartner, May 2013. URL: http:// www.gartner.com/doc/2498715/oltp-dbmsmarket-operational-dbms (дата обращения: 18.09.2016). 2. Aerospike. Large Data Types Guide. 2015. URL: http://www.aerospike.com/docs/guide/ ldt_guide.html (дата обращения: 18.09.2016). Джигнеш Пател (jignesh@cs.wisc.edu) — профессор, Университет штата Висконсин.

www.osmag.ru • 03/2016 • Открытые системы • 11

в фокусе: СУБД

Ренессанс СУБД: проблема выбора По мере роста потребностей в обработке Больших Данных появляются новые модели управления данными, позволяющие выполнять миллиарды запросов в секунду. Одновременно, чтобы не отстать от рынка, меняют и традиционные реляционные модели. Как разобраться в современном ландшафте СУБД и выбрать решение, наилучшим образом удовлетворяющее конкретным требованиям? Ключевые слова: инструменты Больших Данных Keywords: ACID, Big Data Tools, NoSQL, XML

Венкат Гудивада, Дана Рао, Виджай Рагхаван

о недавнего времени реляционные СУБД оставались главным инструментом управления данными на предприятиях, которым нужно ежедневно обрабатывать миллионы запросов. По оценкам IDC, объем рынка таких СУБД в 2011 году составлял 26 млрд долл., а в 2016-м достиг 41 млрд долл. [1]. Такую популярность им обеспечил SQL — декларативный язык запросов, с помощью которого пользователи любой квалификации могут оперировать данными. Реляционные СУБД поддерживают средства контроля целостности данных, аутентификацию, ролевой контроль доступа, резервное копирование и восстановление данных, а также отвечают требованиям ACID (atomicity, consistency, isolation, durability — атомарность, согласованность, изоляция и долговечность). Однако эти СУБД не всегда подходят для решения задач Больших Данных, типичных для современных приложений. Социальные сети, к примеру, требуют выполнения миллионов операций считывания и миллиардов операций записи в режиме, близком к реальному времени. Для этих приложений появились альтернативные СУБД — NoSQL, NewSQL и Not-Only SQL, различающиеся по своим возможностям обработки массивов данных и по пропускной способности [2, 3]. В Facebook, с использованием механизма кэширования в памяти, была

создана распределенная система «ключзначение», которая содержит триллионы записей и обрабатывает миллиарды запросов в секунду. Все эти СУБД лишены ряда особенностей реляционных систем, таких как обеспечение целостности данных, — вместо этого они обладают свойствами, позволяющими обрабатывать огромные объемы данных почти в реальном времени. Ввиду их относительной новизны, стандарты для работы с такими СУБД еще только разрабатываются, а модели данных варьируются в широких пределах. Некоторые системы не поддерживают транзакции, в других не используется SQL. Системы классов Not-Only SQL и NewSQL поддерживают как SQL, так и недекларативные языки запросов. Но общее правило состоит в том, что все реляционные СУБД основаны на реляционной модели данных, а системы NoSQL — нет, тогда как у системы NewSQL одновременно поддерживаются функции обоих типов. По состоянию на начало 2016 года существовало почти 300 различных СУБД, в том числе реляционных, NoSQL и NewSQL, и регулярно появляются новые. Реляционные основаны на одной модели данных и пользуются стандартным языком, поэтому их функциональность прогнозируема, а у систем NoSQL могут различаться модели данных, языки запросов, способы поддержки транзакций, интерфейсы программирования и функции безопасности. Соответственно,

их функциональность варьируется и нередко перекрывается — это обусловлено тем, что на рынке больше шансов выжить имеют системы, обладающие универсальными возможностями. По прогнозу аналитиков Market Research Media, доход от NoSQL-решений за период с 2013 по 2018 год составит 14 млрд долл. — системы NoSQL теснят крупных поставщиков реляционных СУБД, заставляя их вводить в свои решения все новые функции под угрозой риска потери клиентов. Рыночную ситуацию усложняют поставщики СУБД NoSQL, развивающие свои системы форсированными темпами и вводящие произвольные новшества. Кроме того, соперничество между традиционными поставщиками СУБД и разработчиками NoSQL подогревается стремительным развитием продуктового ландшафта, приводя к борьбе за влияние и раздуванию маркетинговой шумихи, а также к разногласиям в терминологии и классификации систем. Разобраться в этом хаосе помогут обзор доступных сегодня систем и рекомендации по выбору лучшей для решения конкретных задач.

Отличия от реляционных систем

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

Venkat N. Gudivada, Dhana Rao, Vijay V. Raghavan, Renaissance in Database Management: Navigating the Landscape of Candidate Systems, IEEE Computer, April 2016, IEEE Computer Society. All rights reserved. Reprinted with permission.

12 • Открытые системы • 03/2016 • www.osmag.ru

в фокусе: СУБД Бизнес-факторы и потребности приложений

Современный бизнес, работающий с Большими Данными, Web 2.0 и мобильными приложениями, интересуют следующие о сновные характеристики СУБД: производительность, масштабируемость и цена. Бизнесу нужны прогнозная аналитика реального времени, персонализация, динамичное ценообразование, превосходное клиентское обслуживание, средства распознавания мошенничества и аномалий, возможность отследить статус выполнения заказа по цепочке поставок и анализ протоколов доступа к веб-серверу. Все эти задачи требуют приоритета операций вставки и извлечения, которые совершаются в огромных объемах. Операции обновления и удаления между тем либо вообще не используются, либо их доля невелика. Приложениям Больших Данных приходится иметь дело с огромными объемами разнородных разреженных данных, а для этого обычно требуется горизонтально масштабируемая среда, построенная на основе стандартного оборудования. Системные разделы должны обладать способностью работать независимо друг от друга в условиях сбоев сети. Для масштабируемости и возможности обработки крупных массивов данных требуется производить автоматизированное разбиение без перекрытий. Большие объемы данных приходится распределять между узлами кластеров, что, в свою очередь, вызывает необходимость в координации распределенных систем, поддержке аварийного переключения и механизмах управления ресурсами. Борьба с сопутствующими проблемами создает дополнительные сложности и увеличивает накладные расходы, что нередко перевешивает преимущества в виде согласованности и гибких транзакционных возможностей. Современным приложениям требуются следующие возможности: простое тиражирование данных для обеспечения высокой доступности; встроенная поддержка версионного контроля и компрессии; выполнение запросов почти в реальном времени; наличие нескольких методов опроса, включая REST-API и сложные произвольные запросы; интерактивная обработка произвольных запросов, для чего нужны системы поддержки массово-параллельных вычислений наподобие MapReduce. Можно также выделить ряд важных для разработчиков особенностей современных СУБД. В частности, схема базы данных не разрабатывается заранее, а развивается по мере изменения потребностей. Нормой

Таблица 1. Примеры систем NoSQL, отвечающих современным требованиям к быстродействию и масштабируемости Система

Возможности

Riak

Высокая масштабируемость, акцент на доступности

MongoDB

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

Redis

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

HBase

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

CouchDB

Отличается высокой доступностью и поддержкой синхронизированного тиражирования; акцент на устойчивости к разделению.

Cassandra

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

стало частичное обновление записей, как в документоориентированных базах, причем вполне достаточно слабой согласованности, а полное соответствие транзакций требованиям ACID не обязательно. Системы NoSQL в той или иной степени отвечают этим характеристикам. Они масштабируемы: данные хранятся и управляются, будучи распределенными между узлами одного или нескольких кластеров, которые можно легко горизонтально масштабировать путем добавления серверов стандартной архитектуры. В некоторых системах для достижения необходимого быстродействия используется MapReduce, а многие системы позволяют менять схемы по мере добавления новых данных. Большинство NoSQLсистем имеют открытый код. Функциональность систем варьируется в больших пределах и быстро развивается, поэтому прямое сравнение по этому критерию затруднительно. В табл. 1 перечислены характерные примеры систем с открытым кодом, отвечающих высоким требованиям к масштабированию и быстродействию. Бизнес-факторы, стимулировавшие развитие систем NoSQL, привели также к появлению поколоночных реляционных СУБД и систем NewSQL. Первые основаны на оптимизированных движках хранения, обеспечивающих высокую эффективность операций считывания, необходимую приложениям оперативной аналитической обработки (OnLine Analytical Processing, OLAP). Некоторые системы NewSQL изначально рассчитаны на работу в распределенном кластере, узлы которого не имеют совместно используемых ресурсов. В других есть слой связующего ПО для секционирования, автоматически разбивающий данные между несколькими узлами распределенного кластера. Существуют также системы, разработчики которых основное внимание уделяют высокооптимизированным движкам хранения, опрашиваемым с помощью SQL. В частности, в СУБД TokuDB для индексации применяется алгоритм фрактального

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

Разработка приложений

Процесс разработки приложений для современных СУБД отличается от применяемого для реляционных баз, в которых данные рассматриваются как стратегический корпоративный разделяемый ресурс с четко определенными политиками и процедурами руководства и контроля качества. Системы NoSQL, напротив, способствуют разобщенности данных: каждая из них оптимизирована для выполнения конкретных требований к быстродействию и масштабированию, предъявляемых ограниченным кругом приложений или даже только одним. Разобщенность данных нередко продиктована не техническими, а организационными особенностями. Можно назвать семь главных аспектов, в которых разработка приложений для реляционных СУБД и систем NoSQL резко различается. Денормализация данных. Реляционные СУБД нормализуют данные, разделяя таблицы на более мелкие для минимизации избыточности. В некоторых системах NoSQL применяется противоположный процесс — для простоты данные дублируются, а обработка запросов оптимизируется за счет устранения операций соединения таблиц. Дублирование и денормализация — допустимые практики в системах NoSQL, но в реляционных СУБД они тоже возможны, хотя и применяются нечасто. Разработка схемы базы данных. По нормам реляционной модели архитекторы заранее разрабатывают схему данных, поэтому физическая модель данных может быть не оптимизированной для определенных запросов и транзакций, но одна и та же логическая модель оптимально подходит для любых запросов. Моделирование данных в NoSQL резко контрастирует с

www.osmag.ru • 03/2016 • Открытые системы • 13

в фокусе: СУБД проверенным временем принципом независимости логической и физической схем данных, принятым в реляционном мире. Создатели базы NoSQL, как правило, стараются идти навстречу разработчику на всех этапах написания приложения. Схему базы данных архитектор или разработчик приложения обычно проектирует начиная с идентификации запросов, которые ему нужны, а также структур данных, оптимально отвечающих требованиям этих запросов. Однако запросы приложения и схема базы данных тесно связаны, поэтому изменения в первых повлекут перемены и во второй. Ограничения целостности. В отличие от реляционного подхода к управлению корпоративными данными, для которого свойственны контроль избыточности и обязательное соблюдение правила целостности, некоторые системы NoSQL не позволяют задавать ограничения на диапазоны значений данных. Прозрачность архитектуры данных. Реляционные системы подразумевают прозрачность архитектурных особенностей (например, секционирования данных) для клиентских программ — СУБД раскрывают детали архитектуры данных с точки зрения производительности, но стараются скрывать их с точки зрения корректности. Некоторые системы NoSQL требуют, чтобы клиентские программы знали такие подробности. Системы «ключ-значение» дают более высокий приоритет быстродействию, нежели корректности уровня приложения. Кроме того, поскольку не все системы NoSQL имеют декларативные языки запросов, для их реализации нередко приходится писать отдельный код. Операции соединения. Реляционные СУБД поддерживают операции объединения и двухфазного контроля завершения транзакции. В системах NoSQL для моделирования отношений «многие ко многим» используются ссылки, но такие системы не поддерживают операции соединения, необходимые для извлечения таких связей. Вместо этого они синтезируются через реализацию операции соединения в коде приложения. На нем же лежит ответственность за обеспечение двухфазного подтверждения транзакций. К сожалению, реализация того и другого в приложении мешает получению преимуществ по масштабируемости, обеспечиваемых системами NoSQL. Согласованность. Реляционные системы обычно обеспечивают строгую согласованность данных, причем некоторые из них предоставляют возможность указания необходимой степени согласованности. Во многих NoSQL-приложениях реализован

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

Выбор системы

Разнообразие СУБД дает руководителям больше свободы выбора, но и усложняет поиск системы, оптимально соответствующей требованиям и ограничениям конкретных приложений. Быстрая эволюция функционала систем NoSQL приводит к слиянию систем NoSQL и NewSQL и появлению многомодельных систем, дополнительно усложняя процедуру выбора. Система NoSQL MarkLogic может работать в качестве базы данных XML, документоориентированной базы, RDF-хранилища и движка для полнотекстового поиска. А FoundationDB может использоваться в качестве реляционной СУБД, хранилища «ключ-значение» и документоориентированной базы. В общем случае задача выбора системы может показаться непосильной, однако знание определенных подробностей о данных, которыми надо управлять, может помочь в составлении списка кандидатов. Вопросы, которыми надо при этом задаться, касаются согласованности, доступности и устойчивости к разделению (consistency, availability, partition tolerance; CAP) — главных факторов, определяющих, подходит ли СУБД для конкретного приложения. Согласованность означает, что все копии одних и тех же данных в один и тот же момент идентичны; требование доступности выполняется, когда на каждый запрос приходит ответ; а устойчивость к разделению означает, что система продолжает работать, несмотря на частичные сбои или потерю произвольного сообщения. Однако, согласно теореме CAP, распределенная компьютерная система неспособна одновременно выполнить все три требования. Например, MongoDB и Redis обеспечивают согласованность и устойчивость к разделению, но не гарантируют доступность, а DynamoDB и Cassandra обеспечивают доступность и устойчивость к разделению, но не гарантируют согласованности. Реляционные СУБД

14 • Открытые системы • 03/2016 • www.osmag.ru

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

Классы систем

Согласно данным сайта DB-Engines, все СУБД, представленные сегодня на рынке, можно разделить на 13 категорий по трем основным классам: реляционные СУБД, NoSQL и NewSQL. Первые два класса делятся на шесть подклассов: реляционные (построчные и поколоночные), «ключзначение», документоориентированные, базы семейств столбцов, графовые и XML. Системы NewSQL совсем недавно отделились от реляционных, став самостоятельным классом, и подклассов у них нет. В табл. 2 приведена сводка особенностей систем и характеристик приложений, подходящих для каждого подкласса.

Реляционные

Реляционные СУБД выдержали проверку временем с точки зрения возможности обслуживания приложений оперативной обработки транзакций (OnLine Transaction Processing, OLTP). В число стандартных функций таких СУБД входят SQL, управление транзакциями, авторизация и контроль доступа, резервное копирование и восстановление. Прежде всего поддерживаются приложения, которым нужны сохранение целостности, аутентификация и детализированный контроль доступа, а также декларативные языки запросов и транзакции. Реляционные СУБД хорошо работают с фиксированной схемой и сохраняют целостность данных за счет ограничений и триггеров, выполняя транзакции в полном соответствии с принципами ACID. Хранимые процедуры помогают минимизировать перенос данных, выполняя расчеты внутри самой базы данных, но MapReduce они заменить не могут. В реляционных системах высокая доступность достигается за счет тиражиро-

в фокусе: СУБД Таблица 2. Классы и характеристики современных СУБД Класс СУБД

Подклассы

Определяющая характеристика

Типичные сценарии и примеры использования

Реляционные (строчные)

Оптимизация как для чтения, так и для записи в целях поддержки OLTP.

Приложения, которым нужны высокая целостность данных, поддержка транзакций, детальный контроль доступа: управление взаимоотношениями с клиентами, системы для страховой, банковской и финансовой отраслей.

Реляционные (поколоночные)

Эффективное выполнение операций чтения для поддержки OLAP.

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

Управление структурированными и неструктурированными данными в единой среде; оптимизация для чтения и записи; масштабируемое быстродействие, как у систем NoSQL, поддержка транзакций.

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

«Ключ-значение»

Хранение пар «ключ-значение» для гарантии быстрого извлечения; задержка выполнения запроса не зависит от размера данных.

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

Базы семейств столбцов

Эффективное хранение разреженных нетранзакционных гетерогенных данных для поддержки частичного доступа к записям.

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

Документоориентированные

Расширяет возможности систем «ключ-значение», добавляя поддержку управления квазиструктурированными данными и документами иерархической структуры; информация преимущественно организована по парам «ключ-значение» и размещена в формате JSON.

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

Графовые

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

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

Нативные XML-базы

Эффективное хранение и извлечение иерархически структурированных гетерогенных данных с высокой вариативностью записей.

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

Реляционные

NewSQL

NoSQL

вания данных и секционирования между дисковыми системами, а производительность увеличивается путем вертикального масштабирования. Но такие системы могут оказаться дорогими, и у них ограниченный круг применений. В числе ограничений реляционных СУБД, мешающих использовать их для приложений Web 2.0, называют жесткость схемы и неприемлемо высокую задержку выполнения запросов. Тем не менее, как прогнозируется, доходы от реляционных СУБД в 2016 году достигнут 41 млрд долл. при рыночной доле 93%. Движки хранения в этих СУБД обычно оптимизированы для построчной обработки — для изменения единственного значения в строке нужно получить ее всю целиком. Такая модель хранения подходит для OLTP-приложений, но сложность вычисления агрегатов по столбцам таблицы с ростом объема данных увеличивается. В поколоночных СУБД, таких как MonetDB, MonetDB/X100 и C-Store, модель хранения оптимизирована для эффективного вычисления столбцовых агрегатов, что соответствует требованиям OLAP-приложений. По состоянию на 2016 год существует как минимум 116 коммерческих и открытых реляционных СУБД, среди которых наиболее популярны Oracle, MySQL, Microsoft SQL Server, PostgreSQL и IBM DB2.

NewSQL

Системы NewSQL, развившиеся под влиянием реляционных и NoSQL СУБД, представляют собой универсальные среды управления структурированными и не-

структурированными данными. Высокая скорость обработки в них обеспечивается за счет использования оперативной памяти и твердотельных накопителей. Многие из этих систем поддерживают несколько моделей данных, но преобладает реляционная. В качестве основного языка запросов используется SQL. Типичные представители: Clustrix, VoltDB, MemSQL, NuoDB, MySQL Cluster, TokuDB и Spanner. Эти СУБД различаются системной архитектурой (master-master либо multilevel master), методами клиентского доступа, а также поддержкой транзакций, сегментирования, тиражирования и встроенных методов MapReduce. Подходящие приложения — критически зависимые от реляционных систем, но и требующие особенностей NoSQL (например, горизонтальной масштабируемости и высокого быстродействия при увеличении масштаба). В числе применений систем NewSQL — распознавание мошенничества в реальном времени, мобильная реклама, назначение расценок и перекрестные продажи в реальном времени, а также поддержка принятия геопространственных решений.

«Ключ-значение»

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

движков характерны высокая скорость извлечения и независимость времени выполнения запроса от размера данных. В числе определяющих характеристик баз «ключ-значение» — обработка Больших Данных в реальном времени, горизонтальное масштабирование, надежность и высокая доступность, причем функциональность и быстродействие варьируются в широких пределах. Эти системы тоже могут различаться по своей архитектуре (главный-главный, главный-подчиненный и клиент-сервер) и методам клиентского доступа, иметь различные характеристики обработки в памяти и поддерживать разные структуры данных. Системы «ключзначение» также могут различаться по таким факторам, как принципы хранения на дисках, поддержка транзакций, сегментация, тиражирование и встроенные функции MapReduce. По состоянию на 2016 год существуют 52 системы «ключ-значение», самые популярные из которых — Redis, Memcached, Riak и DynamoDB. Системы «ключ-значение» хорошо подходят для приложений, которым нужно миллисекундное время отклика и в которых основной способ опроса данных — это поиск по ключам. К таким приложениям относятся механизмы управления сеансами веб-приложений, конфигурационного управления, распределенных блокировок, средства для обмена сообщениями, персонализации обслуживания пользователя в играх и социальных СМИ, мобильные платформы, онлайн-игры, торги реального времени, серверы рекламных объявлений,

www.osmag.ru • 03/2016 • Открытые системы • 15

в фокусе: СУБД рекомендательные системы, многоканальная розничная торговля.

Поколоночные СУБД

Концептуально поколоночные СУБД похожи на реляционные, но при их использовании отсутствуют накладные расходы на обработку, характерные для реляционных систем. В какой-то степени поколоночные СУБД можно также рассматривать как иерархическую систему «ключ-значение». Обработка столбцов происходит аналогично тому, как это делается в реляционных СУБД, каждый столбец имеет свой индекс. Семейство столбцов задается заранее, а сами столбцы внутри семейства — нет; семейство может содержать любое число столбцов с данными любого типа, которые можно сохранить в виде байтовых массивов. Столбцы в семействе логически связаны и физически хранятся вместе. Высокая производительность достигается за счет объединения столбцов с похожими характеристиками. При изменении значения оно сохраняется как новая версия, отличающаяся отметкой времени. Благодаря возможности частичного доступа к данным производительность некоторых приложений кардинально возрастает. Среди поколоночных СУБД наиболее известны Cassandra и HBase; далее идут Bigtable, Apache Accumulo, Hypertable и Sqrrl. Все эти СУБД основаны на архитектуре «главный-главный» без разделения значений и различаются методами клиентского доступа, поддержкой транзакций, сегментирования, тиражирования и встроенных функций MapReduce. Поколоночные базы могут выполнять агрегированные операции (например, высокоэффективный поиск максимумов и минимумов в больших срезах данных) и подходят для приложений, которым требуются гибкие и меняющиеся схемы данных, гетерогенность данных, работа с разреженными и нетранзакционными данными, устойчивость к временной несогласованности, версионный контроль, нативные функции MapReduce, частичный доступ к записям и высокая скорость операций вставки и считывания. Типичный сценарий использования поколоночных СУБД — это управление временными рядами в системах для отрасли финансовых услуг, и соответствующие возможности, в частности, специально реализованы в Cassandra.

Документная модель

Документоориентированные СУБД управляют квазиструктурированными данными, в основном в форме пар «ключ-значение»,

хранимых в виде документов JSON. Каждый документ представляет собой запись с потенциально варьирующимися атрибутами. В полях сохраняются свойства, касающиеся квазиструктурированности и отличий между документами. Для эффективного поиска по полям JSON применяется индексирование. Ны рынке представлено более четырех десятков документоориентированных баз данных, и среди них самыми популярными по состоянию на 2016 год являются MongoDB, CouchDB, Couchbase, DynamoDB, MarkLogic и OrientDB. Они различаются по системной архитектуре, методам доступа и поддержке транзакций, а также по способам сегментирования, тиражирования и набору встроенных функций MapReduce. Документоориентированные базы подобны системам «ключ-значение»; некоторые системы, например Couchbase, имеют оба набора функций. В режиме «ключ-значение» значения хранятся в качестве непрозрачных объектов, а в документном режиме — в форме документов JSON. Документоориентированные базы нередко интегрируются с библиотеками полнотекстового поиска и сервисами наподобие Solr, Lucene и ElasticSearch. В частности, ElasticSearch интегрируется с MongoDB и выдает отклики в режиме реального времени на запросы документов в формате JSON. Документоориентированные базы оптимальны для приложений, нуждающихся в гибкой схеме и множестве различных типов записей (что характерно для вторичных финансовых инструментов и электронных медицинских карт); имеющих экземпляры записей с разными типами данных и большим количеством значений в одном и том же поле; работающих с документами с глубоко вложенными полями и выдающих большое число запросов с вычислением агрегатов по коллекциям документов.

Графовые базы

Графовые базы в меньшей степени рассчитаны на обработку огромных объемов данных и обеспечение высокой доступности и в большей — на работу с данными, имеющими множество связей. Вершины в графовой базе представляют объекты, а ребра моделируют отношения между ними. И у вершин, и у ребер могут быть атрибуты. Поддерживаются запросы на поиск кратчайшего пути между двумя вершинами, поиск кластеров и распознавание сообществ. Среди более чем 20 графовых баз данных, существующих по состоянию на 2016 год, самые популярные — Neo4j, OrientDB, Titan,

16 • Открытые системы • 03/2016 • www.osmag.ru

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

XML-базы

Нативные XML-базы — это старейший и самый развитый подкласс систем NoSQL, способный хранить и опрашивать более широкий круг типов данных, чем любые другие NoSQL-базы. Они превосходно подходят для управления смешанными множествами структурированных, квазиструктурированных и неструктурированных документов и имеют декларативную расширяемую модель данных, которую можно проверить по XML-схеме или шаблону DTD (Document Type Definition). Сложную проверку корректности данных, не описываемых XML-схемой, можно провести с помощью Schematron, стандартного (ISO/ IEC) языка на основе правил, который позволяет судить о присутствии или отсутствии закономерностей в XML-документах. Термин «нативные» в названии класса систем призван отличить их от реляционных СУБД, в которых поддержка XML реализована с помощью дополнений. К таким базам относятся IBM DB2, Oracle, PostgreSQL и Microsoft SQL Server. В этих базах XMLданные хранятся в виде больших символьных объектов (Character Large Object, CLOB) или фрагментов данных, распределенных по нескольким таблицам. В некоторых системах поддерживается тип данных XML, определенный в стандарте ISO 9075-14. Запросы можно совершать с помощью языков XQuery, SQL или их сочетания. В нативных же XMLбазах документы хранятся в естественной иерархической форме. Нативные XML-базы имеют ряд встроенных средств поддержки XML, большинство из которых определены в стандартах WWW. В частности, поддерживаются языки опроса и обновления XML-данных XPath и XQuery, а расширение XPath/XQuery позволяет составлять полнотекстовые поисковые запросы в форме функций XQuery.

в фокусе: СУБД С помощью декларативного языка XProc возможна конвейерная обработка XMLдокументов. Xforms — еще один декларативный язык, помогающий в создании клиентских приложений, основанных на архитектуре «модель-отображение-контроллер». Стандарт форматирования документов XSL-FO позволяет указывать формат печати, а с помощью декларативного языка XSLT можно выполнять преобразования XML-документов. Благодаря высокому уровню стандартизации (среди перечисленных лишь XSLT еще не является стандартом W3C) нативные XML-системы сокращают время разработки приложений за счет использования единой модели данных, которая устраняет необходимость в согласовании данных между уровнями приложения и позволяет людям, не обладающим техническими специальностями, выполнять разработку и сопровождение. Применение стандартных технологий повышает переносимость приложений, а также дает возможность составления политик безопасности и контроля доступа. Типичные представители нативных XMLбаз — MarkLogic, eXistdb, BaseX, TeraText Database System, Snapbridge FDX Cross Media Server и Sedna. Они подходят для приложений, которым требуется управление смешанным контентом с помощью стандартизованных технологий. Идеальные кандидаты — приложения, имеющие дело с миллионами документов, длительными транзакциями, сложной и быстро меняющейся схемой базы и опросами иерархических данных. Области применения: мультиканальная публикация из единого источника, медицина, страхование, интеграция данных, обмен сообщениями и сайты, генерируемые на основе данных.

Что впереди?

Уровень современных СУБД и рост использования облачного хостинга способствуют инновациям в сфере управления базами данных. Разработчики традиционных реляционных СУБД реализуют все больше функций NoSQL, а разработчики систем NoSQL стараются повысить их стабильность и надежность, а также обеспечить в них поддержку транзакций. Стремительное развитие систем обоих типов и обмен функциональностями между ними постепенно сотрут границы и приведут к появлению универсальных систем, имеющих функции из многих подклассов. У одной и той же системы, к примеру, могут быть одновременно функции баз «ключ-значение», документоориентированных и графовых.

Такие многомодельные СУБД станут стимулом для развития облачных баз данных, предоставляемых в виде сервиса (DBaaS). NoSQL-платформы, скорее всего, сохранят свой круг применения как системы с изменяемой схемой данных, практически неограниченной горизонтальной масштабируемостью и выполнением запросов почти в реальном времени. Рост их популярности, по-видимому, будет происходить за счет организаций, использующих много СУБД, каждая из которых подходит для определенных типов данных и приложений. Переход с реляционных систем на системы NoSQL до некоторой степени облегчится благодаря применению формата JSON. С падением цен на оперативную память получат более широкое применение базы с обработкой в памяти (In-memory), что позволит компенсировать ограничения реляционных СУБД по масштабируемости и быстродействию. Системы наподобие SAP HANA, Aerospike, VoltDB и McObject уже используют преимущества обработки в памяти.

Направления исследований

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

Безопасность

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

Поддержка многих моделей данных

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

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

База данных в виде сервиса

Корпоративные системы NoSQL, как правило, развертываются на централизованной или распределенной кластерной системе, но когда у организации нет специалистов по установке и эксплуатации систем NoSQL, их предпочтительно выполнять в облаке, что позволяет избежать лишних затрат. Особенности эксплуатации модели DBaaS пока не ясны, но в качестве промежуточного шага можно было бы реализовать «фасад», предоставляющий сервисы управления данными для многих моделей прозрачно через публичное или частное облако. Исследовательские достижения в области безопасности, множественных моделей данных и DBaaS помогут сделать фасадную модель реальностью. *** Современные приложения работают с беспрецедентными объемами разнообразных данных, предъявляя экстремальные требования к быстродействию и масштабируемости. В связи с этим традиционные реляционные СУБД утратили свою исключительность в качестве единственного инструмента управления данными. Однако, чтобы системы NoSQL достигли такого же уровня надежности и зрелости, предстоит решить еще немало задач. Кроме того, необходимы стандарты, которые обеспечат переносимость приложений, предотвратят привязку к производителю и станут показателем того, что технологии NoSQL — достаточно зрелые, чтобы ими можно было широко пользоваться. 

Литература 1. C.W. Olofson. Worldwide RDBMS 2014 Vendor

Analysis: Top 10 Vendor License Revenue by Operating Environment. Dec. 2015. URL: www. idc.com/getdoc.jsp?containerId=US40652015 (дата обращения: 18.09.2016). 2. M. Stonebraker et al. MapReduce and Parallel DBMSs: Friends or Foes? // Comm. ACM. — 2010. Vol. 53, N. 1. — P. 64–71. 3. M. Stonebraker. Stonebraker on NoSQL and Enterprises // Comm. ACM. — 2011. Vol. 54, N. 8. — P. 10–11. Венкат Гудивада (gudivadav15@ecu.edu) — профессор, Дана Рао (raod15@ecu.edu) — доцент, Университет Восточной Каролины (США), Виджай Рагхаван (vijay@cacs.louisiana.edu) — профессор, Университет Луизианы (США).

www.osmag.ru • 03/2016 • Открытые системы • 17

в фокусе: СУБД

Инструменты анализа графов Программы поиска оптимальных маршрутов давно стали обыденностью, однако нахождение кратчайшего пути — не единственный практический результат теории графов, реализация методов которой стала возможной благодаря специальным СУБД и распределенным инструментальным средам. Ключевые слова: теория графов Keywords: Apache Spark, Graph theory, Hadoop, MapReduce

Александр Смирнов, Дамир Гайнанов

разу «Маршрут построен» слышат каждый день миллионы автомобилистов: программы поиска оптимальных маршрутов в городе в объезд пробок и дорожных работ стали органической частью жизни, позволяя экономить время и деньги. Однако теория графов применяется сегодня для решения многих прикладных задач в различных отраслях: для оптимизации вирусных маркетинговых кампаний, обнаружения мошенничества в финансовой сфере путем исследования схем взаимодействия контрагентов, анализа социальных сетей и т. п. При проведении маркетинговых кампаний наибольший упор делается на производство контента, который пользователи будут с большой охотой передавать своим друзьям и знакомым, и здесь важно определить лидеров мнений — людей, имеющих много друзей в социальной сети, которую можно представить в виде графа: вершины — пользователи, ребра — связи между ними. При поиске оптимальных маршрутов движения транспорта вершина графа — это перекресток, а ребро — дорога между перекрестками. При исследовании схем взаимодействия контрагентов вершинами графа будут участники финансовых операций: физические и юридические лица, государственные организации. А ребрами — их финансовые взаимоотношения. Можно долго перечислять задачи, решаемые с применением теории графов, однако необходимо отметить, что самым сложным является правильное определение вершин и ребер, и в значительной степени это обуславливается мастерством аналитика и специалиста по данным, для работы которых сегодня предлагается ряд инструментов: графовые СУБД, распреде-

ленные фреймворки и различные универсальные средства. Типичный представитель графовых СУБД — система neo4j, использующая специализированный способ моделирования данных. Модель neo4j предусматривает два типа сущностей: вершины, которые могут обладать набором свойств, и ребра, связывающие эти вершины, при этом ребра также могут обладать набором свойств и могут относиться к разным типам. Таким образом, набор данных в neo4j может принимать следующий вид: например, вершина «Юлий Цезарь» связана ребром «является предшественником» с вершиной «Октавиан Август», при этом обе эти вершины связаны ребром типа «занимал должность» с вершиной «император Рима». Не существует жестко заданной модели данных, и при необходимости добавить связь нового типа или изменить набор свойств какойлибо вершины не составит труда. В neo4j имеется интерфейс REST API, а также ряд интерфейсов для работы с данными и API для языков программирования Java, Python и др. В СУБД имеется специализированный язык запросов Cypher, предназначенный для обращения к данным, представленным в виде графа, причем в neo4j изначально включены функции для решения наиболее типичных задач, таких как поиск кратчайшего расстояния. neo4J — не единственная, хотя и наиболее распространенная графовая система. Например, Orient DB представляет собой комбинированную графово-документную базу, позволяющую хранить в узлах не просто набор свойств, а целые документы с динамической схемой. Важное отличие еще одной графовой СУБД, Titan, состоит в возможности работы в распределенной среде. Распределенные фреймворки для работы с графами обычно являются элементами

18 • Открытые системы • 03/2016 • www.osmag.ru

экосистемы Hadoop. Наиболее популярен сегодня GraphX, использующий вычислительный механизм Spark [1], за счет чего достигаются высокие показатели производительности. В отличие от графовых СУБД, GraphX не предназначен для хранения данных в виде графа, и нельзя, например, вставить вершину или ребро в уже имеющуюся структуру описания графа. Главное назначение этого инструмента — аналитика. В GraphX имеется API для языка Scala, в котором предусмотрены ряд стандартных функций для решения типичных задач на графах, а также несколько механизмов для обхода графа вручную, что хотя и достаточно трудоемко, но открывает широкий спектр возможностей для реализации специализированных аналитических алгоритмов. Например, можно реализовать алгоритм, для которого еще нет готовых библиотек или функций, работающих в распределенной среде. Важное достоинство GraphX — простота масштабирования за счет использования вычислительных средств Spark. Граф представляется в виде двух наборов данных (вершины и ребра), выраженных специализированными для Spark абстракциями RDD (Resilient Distributed Dataset), которые могут быть созданы на основе текстовых файлов, таблиц в реляционных СУБД и других источников данных, поддерживаемых Spark [1]. Один из первых, но до сих пор достаточно широко распространенный инструмент этой группы — Giraph, главное отличие которого от GraphX состоит в применении механизма MapReduce. Благодаря тому, что в MapReduce на каждом этапе вычислений на диске сохраняются промежуточные результаты (в отличие от Spark, который для обеспечения высокой производительности работает в основном в памяти), достигаются высокая надежность и устойчивость к сбоям.

в фокусе: СУБД В отдельную группу инструментов, позволяющих работать с графами, можно выделить универсальные исследовательские средства, широко применяемые в корпоративной среде и поставляемые такими компаниями, как IBM, SAP, SAS и Teradata. В этом случае в одном инструменте обычно собраны возможности для выполнения различной аналитики: статистика, временные ряды, теория графов и т. д. При этом с точки зрения используемых подходов и вычислительных механизмов инструменты данной группы могут сильно отличаться друг от друга. В этих инструментах могут применяться различные языки программирования и API, и хотя все эти средства создаются для работы в корпоративной среде и потому предъявляют невысокие требования к подготовке пользователя, возможна ситуация, когда пользователь, привыкший в своей профессиональной деятельности иметь дело только с SQL, окажется не готов к освоению новых средств, реализованных в конкретной системе. Учитывая то, что данные инструменты часто используют принципиально отличающиеся друг от друга вычислительные модели, они могут быть ориентированы только на задачи конкретных типов: например, у какого-то из них самая сильная сторона — статистика, а графовый анализ — побочное свойство. Один из инструментов этой группы — система Teradata Aster [2], предлагающая для решения задач на графах отдельный механизм SQL-GR, позволяющий распараллелить выполнение операций на масштабируемом пространстве данных. В системе имеются функции для решения стандартных задач на графах: нахождение кратчайших путей, определение различных мер центральности, нахождение замкнутых циклов и др. Модель данных, описывающая граф в Aster, представляет собой две таблицы реляционной СУБД: таблицу вершин и таблицу ребер. Пользователям, не знакомым с языками программирования, предлагается интерфейс на базе SQL, позволяющий анализировать данные. Особенности применения инструментов каждого класса хорошо видны на примере задачи поиска кратчайшего пути. В СУБД neo4j имеется готовая функция для поиска кратчайшего пути, при этом предоставляется возможность выбора алгоритма: алгоритм Дейкстры, алгоритм А* (A-star) и др. Данная СУБД показывает высокую производительность при решении этой задачи, однако нет стандартного механизма доступа к данным через драйвер JDBC/ODBC. Кроме того, невысока производительность выполнения операции

вставки записей, что приводит к необходимости использования специального загрузчика при организации ETL-процессов, любые неточности в настройке которого приведут к тому, что перемещение в базу даже не очень большого графа может занимать весьма продолжительное время. В качестве еще одной «ложки дегтя» следует упомянуть тот факт, что данный инструмент написан на Java и при решении требовательных к памяти задач разработчикам приходится в полной мере ощутить неэффективность модели управления памятью виртуальной машины Java. При решении задачи поиска кратчайшего пути с помощью GraphX разработчикам придется вручную реализовывать соответствующий конкретный алгоритм, используя API обхода графа. Однако в качестве вознаграждения за неудобство имеется возможность выполнения кода в действительно распределенной среде с почти горизонтальным масштабированием. Другой положительной стороной GraphX является унаследованная от Spark «всеядность» источников данных. При решении задачи при помощи Teradata Aster разработчикам доступен ряд готовых функций, позволяющих находить кратчайшие пути, указав один SQL-вызов. Вычислительный механизм Aster реализован на языке Cи, что обеспечивает более эффективную работу с памятью, чем позволяют инструменты, написанные на Java. Однако Aster — коммерческий продукт, в отличие от большинства инструментов стека Hadoop и многих графовых СУБД, и это может стать препятствием для небольших компаний и отдельных разработчиков. Было бы заблуждением считать, что даже внутри одного класса задач нахождения кратчайшего пути на графе существует идеальный инструмент для ее решения. Например, нахождение кратчайших маршрутов на дорожном графе в масштабах крупного региона будет означать огромное количество вершин, через которые может проходить кратчайший путь, что сразу предполагает особые требования к производительности и масштабированию. В этом случае могут использоваться специальные инструменты и подходы к оптимизации вычислений исходя из привязки вершин графа к географическим координатам. Примером такого инструмента может служить надстройка pgRouting, устанавливаемая поверх универсальной реляционной СУБД PostgreSQL. Благодаря надстройке появляется возможность индексации записи по географическому положению, что вместе с рядом других эффективных функций этой

СУБД делает ее одной из наиболее пригодных для решения задач на дорожном графе. При выборе инструментария для решения графовой задачи нужно помнить, что применение только графового математического аппарата не всегда приводит к цели. Например, его применение при решении задачи анализа государственных закупок для выявления аномалий не принесет результата. Однако, если сопоставить параметры вершин — участников закупочного процесса, применить методы нечеткой логики (например, анализируя вершины графа «ИП Смирнов А. С., Москва, Денисовский пер., 26» и «ООО Смирнов, Денисовский 26») и рассчитать различные меры центральности таких вершин, можно получить результаты, позволяющие выдать задание для проверки регулирующим органам. *** Сегодня имеется множество инструментов, позволяющих решать задачи графовой аналитики, каждый из которых эффективен в определенных ситуациях. Например, при построении транзакционной системы, оперирующей графовой моделью данных, могут быть использованы специализированные СУБД neo4j, OrientDB и т. п. В случае, если у компании, решающей задачи графовой аналитики, уже имеются кластер Hadoop и штат квалифицированных разработчиков, знакомых с языком Scala, логично обратить внимание на систему GraphX. Предприятиям стоит взять на вооружение и универсальные аналитические решения, такие как Aster, ввиду высокой степени их готовности к применению, невысоким требованиям к подготовке пользователей в области ИТ и простоты интеграции в корпоративную информационную среду. 

Литература 1. Андрей Николаенко, Дмитрий Волков.

Новые инструменты Hadoop // Открытые системы.СУБД. — 2014. — № 10. — С. 12–14. URL: http://www.osp.ru/os/2014/10/13044382 (дата обращения: 18.09.2016). 2. Михаил Ганюшкин. Вам TUDA // Открытые системы.СУБД. — 2013. — № 2. — С. 27–29. URL: http://www.osp.ru/os/2013/02/13034552 (дата обращения: 18.09.2016). Александр Смирнов (Alexander.Smirnov@ Thinkbiganalytics.com) — евангелист Hadoop, компания Teradata, подразделение Think Big (Москва); Дамир Гайнанов (damir@dc.ru) — руководитель кафедры аналитики Больших Данных и методов видеоанализа, Уральский федеральный университет им. Б.Н. Ельцина (Екатеринбург).

www.osmag.ru • 03/2016 • Открытые системы • 19

в фокусе: СУБД

Когнитивное хранение для Больших Данных Эффективность систем хранения данных можно существенно улучшить за счет определения ценности информации. Системы когнитивного хранения смогут работать более оптимально благодаря автоматической оценке соответствия данных потребностям и предпочтениям пользователя. Ключевые слова: Большие Данные, когнитивное хранение, системы хранения Keywords: Big Data, cognitive storage, data-storage technologies, storage systems

Джованни Черубини, Дженс Джелитто, Винодх Венкатесан

а протяжении почти четырех десятков лет системы хранения данных на различных носителях, от перфокарт и магнитной ленты до жестких дисков, подключались к компьютерам напрямую. До 1990-х, когда стали создаваться сети хранения, не существовало концепций глобальной системы хранения и единого пространства имен, но затем появилась возможность совместного использования многими компьютерами ресурсов хранения и универсального эффективного управления ими. За идеей сетей хранения появилась идея виртуализации хранения, когда пулы ресурсов строятся из физических устройств хранения и организуются в логические устройства [1]; возникли концепции RAIDмассивов, экономного резервирования, виртуализации лент и миграции данных и носителей (иерархического управления хранением). Однако сетевому хранению требовалось все более сложное управляющее ПО, в связи с чем были разработаны развитые масштабируемые файловые системы, эффективно управляющие данными и метаданными, нередко в общем пространстве имен. Те же концепции были перенесены в мир облачных вычислений и облачного хранения — облако может играть роль дополнительного уровня

хранения или полноценного удаленного центра обработки данных, предоставляющего сервисы вычислений, хранения и т. п. Недавно родилась концепция программно-конфигурируемого хранения (software-defined storage, SDS) на основе оркестровщиков, динамически резервирующих ресурсы с гарантированными уровнями быстродействия, надежности, доступности и защищенности. За последние 60 лет емкость устройств для хранения данных выросла на шесть порядков и продолжает увеличиваться [2]. Стали популярными новые типы устройств, в том числе на флеш-памяти, которая сегодня обеспечивает очень высокую производительность, а благодаря значительному прогрессу в области компрессии и дедупликации данных реального времени появились гораздо более эффективные системы хранения для многих сценариев применения. Всех этих усовершенствований пока достаточно, для того чтобы администраторы хранения справлялись с экспоненциальным ростом данных. Но хватит ли возможностей нынешних технологий в будущем, с учетом того что данные и сложность систем продолжают непрерывно расти? Не начнет ли пространство хранения отставать по темпам роста от объемов данных, в связи с чем стандартная модель перманентного хранения всех данных станет нереализуемой из-за нехватки ресурсов [3]? Стоит определиться: нужно

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

Требования масштабных систем хранения

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

20 • Открытые системы • 03/2016 • www.osmag.ru

в фокусе: СУБД телей, одновременно проводя балансировку затрат, быстродействия и уровня надежности. Для непрерывного выполнения такой оптимизации системе надо в автоматическом режиме динамически переносить данные по мере изменения их свойств (ценности, характера доступа и требований защиты). Не менее важные аспекты — управление жизненным циклом данных и доступным пространством. При исчерпании последнего его можно увеличить не только путем добавления новых ресурсов, но и за счет снижения избыточности либо даже удаления наименее нужных данных. Пользователю идеальная система хранения должна давать общий обзор данных, предоставляя возможность управления ими независимо от типа (структурированные, неструктурированные, текст, графика), источника, формата, возраста, носителя (твердотельный накопитель, жесткий диск, лента), типа хранения (блочное, файловое, объектное) и т. д. Система должна обеспечивать свободный доступ к данным и возможность манипуляций с ними для аналитических нужд. Удобство управления данными можно обеспечить за счет развитых поисковых возможностей, например, реализованных с помощью подробных метаданных. Многие из перечисленных требований уже полностью или частично выполнены. SDS, например, обеспечивает более рациональное взаимодействие между приложениями и системой хранения за счет динамического резервирования ресурсов хранения с наиболее подходящими характеристиками. Новые технологии, такие как программная организация RAID-массива и клонирование с помощью контроллера хранения, позволяют системе хранения лучше адаптироваться к потребностям данных и рабочих задач при использовании стандартного оборудования. Не так давно стартап Tarmin представил основанную на SDS концепцию хранения, определяемого данными (data-defined storage, DDS), которая подразумевает проектирование систем с ориентацией на данные. Но остаются и существенные недоработки. В частности, большинство нынешних систем хранят все данные с одинаковым уровнем избыточности (например, с тиражированием на три приемника) или требуют ручного выбора избыточности. И похоже, ни одна из нынешних систем хранения не меняет уровня избыточности в зависимости от ценности данных. Концепция когнитивного хранения отличается от существующих не только

тем, что использует данные как отправную точку, принимая во внимание характеристики рабочей задачи, но и тем, что вводит ценность данных в качестве определяющего параметра конфигурирования и управления хранением, размещением и защитой данных, а также управления их жизненным циклом. Система когнитивного хранения — эластичная, динамичная, способная рационально расходовать емкость, обеспечивая избыточность только для самых нужных данных и экономя пространство за счет сохранения менее важной информации со сниженной избыточностью. Ценность данных наряду с популярностью (зависящей от частоты доступа) и характеристиками рабочей нагрузки можно использовать для определения требуемого уровня обслуживания. В отличие от ситуации, когда конкретным классам срезов данных вручную назначается то или иное качество обслуживания (Quality of Service, QoS), система когнитивного хранения автоматически идентифицирует классы и рекомендует подходящие политики для обеспечения нужного QoS. Это важнейшая особенность концепции когнитивного хранения, в первую очередь в контексте систем хранения Больших Данных, в связи с тем что при огромных и растущих объемах ручное управление QoS невозможно. В современных гетерогенных системах хранения различные типы накопителей значительно различаются по цене и характеристикам быстродействия и надежности. В частности, у SSD время доступа — сотни микросекунд, а у ленточных систем при гораздо меньшей стоимости гигабайта доступ может занимать десятки секунд. Из-за этих различий проектировщикам систем хранения сложно добиваться высокого быстродействия при относительно низких затратах, для чего нужно оптимально сопоставлять производительность и надежность накопителей с требованиями защиты и характером доступа к данным. Но постоянно растущие объемы данных, меняющийся характер доступа и потребности в защите вынуждают создавать автоматизированные системы динамического управления данными. Надежность и производительность накопителей можно улучшать, применяя методы системного уровня — например, распределяя данные между несколькими устройствами или создавая несколько копий. Принципы и время применения таких методов зависят от характеристик доступа и накопителей, а также от требо-

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

Свойства данных

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

Ценность данных

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

www.osmag.ru • 03/2016 • Открытые системы • 21

в фокусе: СУБД по их защите должны принимать сисадмины или пользователи. Для многих видов данных ценность должен специально задавать пользователь, однако некоторые данные по своей природе могут быть ценнее. К примеру, метаданные, а также уже обработанная информация обычно имеют более высокую ценность из-за затраченных вычислительных ресурсов и в связи с более высоким качеством вследствие обработки. Потеря таких данных обойдется дороже. Уникальные или эксклюзивные данные могут иметь крайне высокую ценность, если их после утраты нельзя восстановить. Таким образом, для различных категорий данных требуются разные стратегии хранения (рис. 1). Данные высокой ценности (подлежащие обязательному сохранению) могут не иметь большого объема, но хранить их нужно надежно (даже если это сопряжено с большими затратами) и в их целостности необходимо часто удостоверяться. Другие данные, например юридические, может понадобиться хранить до удаления с высокой надежностью определенное число лет. Для таких категорий данных необходимо гарантировать подходящий фиксированный уровень защищенности при минимально возможной цене и следовать оптимальным методам хранения. Еще одна категория данных, обозначенная на рис. 1 как «данные с датчиков и бизнес-данные», тоже обычно характеризуется большими объемами и высокой ценностью в момент создания, по крайней мере, если они создавались или собирались для конкретной цели. После того как данные были использованы по назначению (например, сведения о заказе в онлайн-магазине или данные диагностики пациента), их ценность уменьшается. Возможно, однако, повторное использование этих данных для какихто нужд, которое позднее увеличит их

Ценность × объем

Данные с датчиков, бизнес-данные Данные со сроком хранения Подлежащие сохранению

Время

Рис. 1. Изменение со временем общей ценности различных категорий данных

ценность (пример — адресная реклама на основе обобщенных сведений о покупательском поведении, медицинские исследования или страховки на базе долгосрочных сведений о лечении и т. п.). Эта категория данных важна для концепции когнитивного хранения, так как характеризуется одновременно и большими объемами, и ценностью, меняющейся со временем. Кроме того, общую ценность данных для бизнеса можно увеличить, минимизируя стоимость хранения, и в этом смысле когнитивное хранение дает основу для построения систем хранения, базирующихся на экономике или ценности данных. Для масштабируемости системы и защиты нужных данных их ценность должна определяться автоматически, а гранулярность изменений ценности данных зависит главным образом от контекста, в котором они используются. С технической точки зрения широкий диапазон гранулярности ценности и защиты можно обеспечить, применяя методы тиражирования и кодирования данных. Показатель ценности имеет большое значение в процессе принятия решений о том, какие данные нужно хранить, с каким уровнем избыточности и как долго, особенно для Больших Данных, затраты на хранение которых можно существенно снизить с принятием соответствующих политик. Например, только снижение избыточности данных низкой ценности с троекратной до двукратной позволит уменьшить затраты на хранение на 33%.

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

Популярность данных

Чтобы лучше понять, как выполнить различные требования крупномасштабных систем хранения, рассмотрим пример переноса всех данных организации в облако. Задача — свести к минимуму затраты и обеспечить надежное хранение и необходимые вычислительные возможности. Данные разнородны, и требования хранения для различных классов могут существенно варьироваться. Например, рабочим базам данных нужны быстрый случайный доступ и высокая доступность, поэтому их надо хранить на SSD или других быстрых накопителях с автоматическим тиражированием для надежности. А журналы операций, сохраняемые согласно нормативным требованиям, могут характеризоваться редким доступом, но их надо надежно хранить в течение фиксированного периода времени. Такие данные можно хранить на ленте, при необходимости — с тиражированием между разными географическими регионами.

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

22 • Открытые системы • 03/2016 • www.osmag.ru

Жизненный цикл данных

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

Затраты на хранение

в фокусе: СУБД Модули вычислений/аналитики

Многоуровневый модуль хранения Данные, к которым выполняется доступ

Ценность Система обучения Входные данные

• А нализ потока данных • И дентификация и выделение особенностей данных в зависимости от контекста • С опоставление особенностей данных с классами релевантности • Прогноз изменения контекста

Селектор

Система хранения •Н оситель •У ровень защиты •И збыточность • Доступность

Данные

Мигратор

Конфигурационные параметры

Диспетчер емкости Рекомендации по удалению / расширению емкости

Популярность

Модуль оценки закономерностей доступа

Рис. 2. Структура когнитивной системы хранения данных Проведя сортировку данных по категориям в зависимости от требований и сопоставив разным категориям соответствующие решения хранения, предлагаемые провайдером облачных сервисов, организация может минимизировать затраты на хранение. Допустим, провайдер предлагает три варианта избыточности: высокая (три копии) по цене 3 цента за 1 Гбайт, сниженная (две копии) по 2 цента за 1 Гбайт и низкая (RAID-5) по 1,5 цента за 1 Гбайт. Если бы в организации классифицировали свои данные по категориям и сохранили, скажем, 5% из них, считающихся наиболее важными, с высокой избыточностью, 45% менее важных — с умеренной избыточностью, а остальные 50%, наименее важные, с низкой избыточностью, то можно было бы на 40% снизить затраты по сравнению с хранением всех данных с высокой избыточностью. Если хранить на быстрых накопителях лишь данные частого доступа, затраты можно уменьшить еще значительнее. А если бы классификацией данных по категориям занимался провайдер облачного сервиса хранения, диапазон возможностей оптимизации и экономии был бы еще больше.

Когнитивное хранение

Опишем концепции и архитектуру системы когнитивного хранения данных (рис. 2).

Интеграция хранения и вычислительных мощностей

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

входящих данных, осуществляемой вычислительными и аналитическими модулями в режиме реального времени, были доступны вычислительные ресурсы. При такой обработке выполняются процедуры фильтрации и классификации — например, анализ данных для начальной идентификации связанных с ними активов и назначение различных уровней ценности; отбрасывание сомнительных или ненужных данных; анонимизация медицинских записей. В целом к классификации реального времени могут относиться любые операции предварительной оценки входящих данных с гарантированной устойчивой пропускной способностью. При распознавании нужной информации оперативный классификатор относит соответствующий срез к одному из нескольких классов релевантности в зависимости от присутствия особенностей, характеризующих информацию как нужную. Срезы данных, в которых такая информация не найдена, относятся к классу низкой релевантности. Несколько пар «детектор-классификатор» могут работать параллельно, анализируя множество потоков данных и типов событий. Классификаторы могут присваивать каждому срезу данных по несколько тегов. Помимо модулей обработки в режиме реального времени, имеются дополнительные офлайн-модули, которые выполняют мониторинг и переоценку нужности данных с течением времени, обеспечивая более глубокий анализ. Конфигурирует всю систему администратор, но возможна настройка на основании автоматически генерируемой информации.

Определение ценности данных

Для каждого нового среза данных, подлежащего сохранению, можно определить его нужность, популярность, требуемый уровень хранения и избыточность путем сравнения соответствующих метаданных и контента с другими срезами данных, уже хранимыми в системе. Для демонстрации этого принципа использовался алгоритм кластеризации методом бутылочного горлышка (Information Bottleneck, IB): эта методика обучения с учителем имеет меньшую сложность и более высокую надежность, чем другие методы. Согласно методу IB, берется совместное распределение между двумя случайными переменными X и Y и создается сжатая репрезентация X в новой переменной T так, что она сохраняет максимальный объем совместной информации X и Y. В контексте классификации данных X соответствует метаданным (набору слов), а Y — классам релевантности. Таким образом, ценность данных определяется релевантностью, ассоциируемой с Y. Экспериментальные данные для тестирования метода были взяты с лабораторного сервера, хранящего пользовательские файлы. Для классификации были собраны метаданные, в том числе идентификаторы пользователя и группы, сведения о размере файлов, правах доступа, времени и дате создания, расширениях файлов и полные пути. Данные были разделены по пользователям — каждый из них мог определять разные классы важности файлов для себя. Всего было 1,77 млн файлов и семь пользователей; максимальное число файлов на пользователя составило 886 750. Данные

www.osmag.ru • 03/2016 • Открытые системы • 23

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

Точность прогнозирования для каждого класса

0,8

Выбор уровня защиты и доступности данных

0,4

0,2

Класс 1 Класс 2 Класс 3

100

Обучающий срез данных, %

Рис. 3. Точность классификации файлов с использованием метода IB были классифицированы по определенным пользователями подклассам, представлявшим различные проекты, а все остальные файлы были определены в один большой подкласс. Каждый подкласс определялся как содержащий все файлы в некотором наборе каталогов. Были введены три класса нужности, в два из которых включили файлы из двух разных проектов, а в третий — все остальные. Выяснилось, что пользователь с максимальным числом файлов имел файлы из всех классов, поэтому данные этого пользователя были взяты за основу для экспериментов. Для этого пользователя файлы проекта 1 были самыми важными и принадлежали к классу 1, файлы проекта 2 были умеренно важными и принадлежали к классу 2, а остальные, как наименее важные, отнесли к классу 3. Размеры классов сильно разнились: класс 1 содержал лишь 157 файлов, класс 2 — 2688, а класс 3 — остальные 863 905. Для проверки реализуемости автоматического определения ценности было проведено 10 прогонов системы на случайно выбранных обучающих срезах разного размера, анализировался уровень точности с доверительным интервалом 95%. При каждом прогоне для обучения выбиралась определенная фиксированная доля файлов каждого класса. На рис. 3 показана точность прогнозирования для каждого класса. С ростом обучающего среза точность для меньших классов повышалась, приближаясь почти к 100% для примерно 30% обучающих данных.

Для более крупных систем с меньшим числом обучающих образцов для определения ценности данных, возможно, больше подойдет метод обучения «с частичным привлечением учителя» (semisupervised learning, SSL), в рамках которого используются как размеченные, так и неразмеченные данные. Перспективным представляется метод, основанный на графовом SSL. Опишем граф, каждая вершина которого означает информационный объект, хранимый в системе, каждое ребро соединяет два объекта, чьи метаданные «близки» согласно некоторому показателю сходства, а вес ребра соответствует значению этого показателя для пары вершин, соединенных данным ребром. Каждая вершина ассоциирована с ценностью соответствующего информационного объекта. Некоторому подмножеству вершин в процессе обучения присваиваются показатели ценности данных, а остальные остаются неразмеченными — для них ценность определяется исходя из связности графа. Руководящий принцип при этом такой: похожие элементы данных должны иметь схожую ценность. Для реализации этого принципа существуют несколько алгоритмов, в том числе метод собственных векторов матрицы и передача сообщений. Графовые SSL-методы особенно эффективны, если объем размеченных данных ограничен. Более высокой точности можно достичь путем исследования структуры графа, в том числе размеченных и неразмеченных вершин.

24 • Открытые системы • 03/2016 • www.osmag.ru

После первоначальной классификации срезы данных обрабатываются селектором, который с учетом класса релевантности определяет требуемый уровень защиты и тип носителя. Выбор решения также зависит от закономерностей доступа в конкретном классе релевантности, сведения о которых поступают от соответствующего компонента (рис. 2). Селектор назначает уровень защиты и выбирает тип носителя для первоначального размещения данных. Для дальнейшей оптимизации можно оценивать различные характеристики рабочей задачи — например, последовательность и частоту идущих подряд операций доступа. Каждый срез данных шифруется или тиражируется для обеспечения нужного уровня защищенности (с помощью какой-либо формы метода неравномерной защиты от ошибок) в зависимости от класса релевантности. Уровни хранения и защиты следует периодически определять заново, чтобы учитывать изменения релевантности и частоты доступа. Требуемый уровень защиты также зависит от типа возможных нарушений, в числе которых: порча данных, выраженная в виде коэффициента битовых ошибок (bit error rate, BER); стирание данных, характеризуемое средним временем до потери данных (mean time to data loss, MTTDL) или ожидаемой годовой долей потерянных данных (expected annual fraction of data loss, EAFDL); выраженное в процентах время недоступности данных.

Перенос данных между уровнями

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

в фокусе: СУБД хранения. Нынешние механизмы распределения данных по уровням обычно учитывают только популярность. Чтобы гарантировать определенный уровень защиты для данных конкретной релевантности, на разных уровнях хранения можно использовать разные схемы избыточности. Например, BER у ленточных накопителей составляет 10 -19, а у жестких дисков — 10 -15. Соответственно, при переносе среза данных между уровнями мигратору нужно адаптировать схемы избыточности так, чтобы обеспечить тот же уровень защиты. Для снижения затрат требуемую степень защиты можно гарантировать путем распределения избыточных данных между несколькими уровнями. Например, срезы с высокой нужностью и низкой или умеренной популярностью могут иметь одну копию на SSD (для скорости) и еще одну на ленте (для надежности и экономии затрат). По сравнению с тиражированием помехоустойчивые коды обеспечивают гораздо более высокую эффективность хранения при том же уровне надежности, но со сниженной скоростью доступа.

Оценка закономерностей доступа

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

Динамическое обновление критериев выбора

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

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

Управление емкостью хранения

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

Задачи для исследований

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

тью данных, например, с точки зрения контекста, в котором данные создаются и потребляются. Понимание такой корреляции, если она есть, а также ее изменение со временем могут сильно повлиять на архитектуру когнитивной системы хранения. Важнейшая тема исследований — безопасность. Если данные шифруются клиентом, то и определение ценности должно выполняться на стороне клиента до шифрования, если, конечно, не будет способов безопасно анализировать информацию в зашифрованном виде. Кроме того, нужно более глубокое понимание вопросов безопасности, чтобы определять, как уровень защищенности соотносится с ценностью данных. Предстоит выяснить, есть ли смысл предлагать варьирующиеся модели безопасности в зависимости от изменения ценности со временем и можно ли гарантировать определенный уровень защиты в том случае, если он применяется сразу после создания данных. Наконец, возникает и такой вопрос: как гарантировать предопределенный уровень защиты данных при работе с гетерогенными устройствами и данными, чья ценность варьируется со временем? Похоже, что в обеспечении гарантии надежности ключевую роль будут играть адаптивные схемы кодирования, однако их применение сопряжено с риском заметного повышения сложности и ухудшения производительности. *** Здесь были перечислены далеко не все исследовательские проблемы, а с учетом междисциплинарной природы задачи когнитивного хранения, для ее решения понадобится еще немало исследований в целом ряде областей. 

Литература 1. K. Goda, M. Kitsuregawa. The History

of Storage Systems // Proc. IEEE. — 2012. Vol. 100. — P. 1433–1440. 2. E. Eleftheriou et al. Trends in Storage Technologies // IEEE Data Eng. Bull. — 2010. Vol. 33, N. 4. — P. 4–13. 3. J. F. Gantz et al. The Expanding Digital Un i ve r s e: A Fo r e c a st of Wo r ld w id e Information Growth through 2010. White paper, IDC, 2007. Джованни Черубини, Дженс Джелитто, Винодх Венкатесан ({cbi, jje, ven}@zurich.ibm.com) — научные сотрудники Исследовательского центра IBM (Цюрих).

www.osmag.ru • 03/2016 • Открытые системы • 25

платформы

Из ускорителей в процессоры Летом 2016 года на рынке появилось второе поколение ускорителей Xeon Phi с архитектурой Knights Landing, способных заменить обычные процессоры, что сулит изменения как в индустрии высокопроизводительных систем в целом, так и в инфраструктурах обработки Больших Данных. Ключевые слова: графический процессор, платформы Больших Данных Keywords: Big Data Platform, GPGPU, GPU, graphics processor, Intel Xeon Phi, Knights Landing

Михаил Кузьминский

скорители разных типов сегодня применяются в широком спектре компьютерных систем, от ПК и до суперкомпьютеров, дополняя центральные процессоры, однако чипы второго поколения ускорителей Intel Xeon Phi серии x200 (Knights Landing) способны полностью заменить центральные процессоры x86-64. Это, в частности, означает возможность выполнения без перекомпиляции всех имеющихся программ и уменьшение сложности, связанной с обеспечением одновременного использования центральных и графических процессоров в одной системе. Ускорители Knights Landing относятся к устройствам класса MIC (Many Integrated Core Architecture) и обладают

рядом архитектурных особенностей [1, 2]. Ускорители построены на микросхемах, содержащих до 36 процессорных «плиток» (tile), связанных межсоединением по топологии двумерной решетки (см. рисунок). Каждая «плитка» содержит два процессорных ядра, специально адаптированных для выполнения приложений систем высокопроизводительных вычислений (HPC). Это ядра Intel Atom Silvermont с двумя VPU (векторными процессорными устройствами) — AVX512 для работы с числами в формате с плавающей запятой двойной точности (DP). В ядрах Atom в Knights Landing много усовершенствований по сравнению с версией для первого поколения процессоров — Intel Xeon Phi (Knights Corner). Например, добавлена внеочередная обработка команд и модернизирована AVX-архитектура, а бла-

26 • Открытые системы • 03/2016 • www.osmag.ru

годаря увеличению числа ядер, обеспечивающих выполнение по 16 операций над числами в формате DP на ядро за такт, производительность увеличилась вдвое. Как и у Knights Corner, каждое ядро нового ускорителя имеет кэши команд и данных по 32 Кбайт с дополнительным разделяемым ядрами плитки кэшем второго уровня емкостью 1 Мбайт. Во всей микросхеме обеспечивается когерентность кэша второго уровня для всех ядер c общей емкостью до 36 Мбайт. Каждое ядро предполагает одновременное использование четырех нитей, или тредов (одновременно выполняемые потоки команд, HyperThreading в процессорах Intel x86-64). Микросхемы Knights Landing изготовлены по технологии 14 нм и работают на частотах 1,3–1,5 ГГц (см. таблицу). Пиковую производительность Knights Landing при работе с числами в формате с плавающей запятой можно посчитать, умножив тактовую частоту при работе с AVX на число ядер и на 32 команды, выполняемые за такт, что дает 3 TFLOPS. Кроме базовой тактовой частоты, у Knights Landing возможна и ускоренная — до 1,7 ГГц. В состав ускорителя входят восемь модулей «ближней памяти» MCDRAM (Multi-Channel DRAM) общей емкостью 16 Гбайт и пропускной способностью 400 Гбайт/с, имеющих доступ к плитке через восемь контроллеров. В Knights Landing есть еще два контроллера для обращения к «дальней памяти» DDR4 2400 емкостью до 384 Гбайт и пропускной способностью 90 Гбайт/с. «Ближняя память» может работать в трех разных режимах: как кэш дальней памяти; в составе единого адресного пространства с дальней памятью (гладкий режим); в комбини-

платформы MCDRAM

3 канала DDR4

EDC

MCDRAM

EDC

DDR MC

EDC

MCDRAM

2 x16 1 x4

X4 DMI

D M I

PCIe v.3

MCDRAM

EDC

MCDRAM

EDC

DDR MC

36 плиток

EDC

MCDRAM

3 канала DDR4

рованном режиме, когда часть MCDRAM используется как кэш, а часть — в едином адресном пространстве с DDR4 [1]. Уникальным для ускорителей является не только такое двухуровневое построение памяти, но и поддержка интерфейса с межсоединением Intel Omni-Path, которое может стать конкурентом Infiniband. Процессор Knights Landing может связаться с Omni-Path через два внутренних канала PCIe x16, а на выходе обеспечить два порта Omni-Path c быстродействием 25 Гбайт/с при дуплексной передаче. Кроме того, Knights Landing имеет два интерфейса с PCIe x16 v.3.0, что, в частности, позволяет применять не только Omni-Path, но и известный интерфейс DMI (Direct Media Interface), первоначально предложенный корпорацией Intel для связи между северным и южным мостами на материнских платах, а затем для связи интегрировавшей их микросхемы с центральными процессорами. Knights Landing логично сопоставлять с самыми мощными графическими ускорителями компании Nvidia [3]. Как видно из таблицы, пиковая производительность ускорителей P100 немного выше, чем у Xeon Phi 7290, а пропускная способность специальной быстродействующей cтековой памяти CoWoS HBM2 в P100 также больше, чем у MCDRAM в Knights Landing. Однако это пока единственный в мире ускоритель, который, кроме быстродействующей памяти MCDRAM, может работать с оперативной памятью DDR4 большой емкости. Это крайне актуально для HPC-приложений, а в сочетании с двоичной совместимостью с x86-64 и, соответственно, с возможностью работы с популярными операционными системами делает Knights Landing полноценным процессором, способным выполнять широкий круг задач обработки Больших Данных. Архитектура графических процессоров Nvidia существенно отличается от принятой в центральных процессорах, что касается и терминологии [3], поэтому сопоставление ускорителей в таблице не совсем однозначно, а сравнение количества 64-разрядных CUDA-ядер с числом возможных нитей в Knights Landing может быть только качественным, говорящим о более высоком уровне распараллеливания в P100 относительно Xeon Phi. Арифметическая интенсивность (отношение пиковой производительности к пропускной способности) высокоскоростной памяти — число выполняемых операций с плавающей запятой при каж-

EDC

MCDRAM

Архитектура ускорителя Knights Landing дой передаче байта данных — у акселераторов Knights Landing выше, чем у P100. Однако в реальных HPC-приложениях, например в задачах прогнозирования погоды, достигаемая арифметическая интенсивность может быть гораздо ниже, чем теоретически возможная для конкретного ускорителя. Кроме того, надо иметь в виду, что в ряде приложений применяется одинарная точность (SP) или даже половинная (16-разрядная точность, HP), и тогда производительность P100 оказывается выше, чем у Knights Landing. Для выполнения приложений с преобладанием вычислений класса SP компания Nvidia предлагает специальный GPU Maxwell Titan X c пиковой производительностью 7,1 TFLOPS. Ускоритель P100 аппаратно поддерживает HP, и при этом его пиковая производительность достигает 19 TFLOPS. Кроме того, у Nvidia есть ускоренный вариант P100 c поддержкой высокоскоростного межсоединения по протоколу NVLink между CPU и GPU c дуплексной пропускной способностью 160 Гбайт/с. У таких P100 производительность для DP/SP/HP составляет 5,3/10,6/21,2 TFLOPS соответственно. Но наиболее важная особенность Knights Landing — двоичная совместимость c x86-64, что означает поддержку устоявшейся cистемы программирования — например, возможно явное указание в компиляторах Intel с языков Фортран

и Си/С++ [1] на использование массивов памяти MCDRAM, а в среде Nvidia/CUDA сделать это непросто. Итак, в случае Knights Landing впервые в индустрии складывается ситуация, когда высокая производительность ускорителя сочетается с преимуществами стандартных центральных процессоров [1]. Таким образом, можно создавать HPC-кластеры из серверов на платформе Knights Landing и Omni-Path, что способно привести к кардинальным изменениям в суперкомпьютерной индустрии. По пиковой производите льности Knights Landing при работе с числами в формате DP вдвое превосходит двухпроцессорную систему с процессорами E5-2699v4: Xeon имеет 22 ядра (2,2 ГГц), каждое из которых позволяет за такт обработать 16 чисел в формате с двойной точностью (против 32 в Knights Landing). Для расчета пиковой производительности процессоров Xeon, начиная с архитектуры Haswell (2600 v3), следует использовать не базовую, а более низкую AVXчастоту. Для процессоров E5-2600 v4 c микроархитектурой Broaswell-EP, в которых число выполняемых за такт команд такое же, как и в Haswell, частоты также отличаются. Особый интерес представляют данные производительности при выполнении признанных стандартных тестов, позволяющие сделать адекватное сопоставление

www.osmag.ru • 03/2016 • Открытые системы • 27

платформы Характеристики ускорителей Nvidia Pascal P100 Число ядер

Intel Xeon Phi Knights Corner 7120P

Intel Xeon Phi Knights Landing 7290

SM:56

Число потоковых ядер

CUDA FP64 —1792

Нитей — 244

Нитей — 288

Базовая частота (ГГц)

1,33

1,24

1,5

16 HBM2

16 GDDR5

16 MCDRAM/ 384 DDR4

720

352

437 / 115

4,7/9,3

1,2/2,4

3.0/6+*

300

245

Память (Гбайт) Пропускная способность памяти (Гбайт/с) Пиковая производительность (DP/SP, TFLOPS) Энергопотребление (Вт)

* Пиковая производительность в Knights Landing достигается при работе с AVX, при этом базовая частота понижается на 200 МГц, что связано с повышением силы тока при выполнении векторных команд.

результатов. Данные для известных тес- использовании библиотеки Intel MKL для тов SPECfp_rate_base2006 [2] свидетель- теста dgemm была достигнута реальная ствуют, что ускорители Knights Landing производительность около 2,1 TFLOPS, 7250 достигают около 80% от произво- в то время как для BLAS L2 (умножение дительности системы, состоящей из двух матрицы на вектор) — около 60 GFLOPS. 14-ядерных процессоров Xeon E5-2697 Однако надо отметить, что для MICv3 микроархитектуры Haswell с базовой архитектуры, как и для всех ускорителей частотой 2,6 ГГц, опережая в 1,2 раза по- с большим числом ядер (many-core), для следние по производительности на ватт. достижения высокой производительносСистемы Knights Landing имеет смысл ти нужно применять «пакетный» подход применять для выполнения тяжелых рас- (например, используя известную бичетов с числами в формате с плавающей блиотеку программ MAGMA) к работе запятой, поэтому на с dgemm, благодатестах SPECint_rate_ ря которому Knights base2006 процессор Landing демонстриПроцессоры для потоковых данных Knights Landing 7250 рует трехкратное Для работы с большими потоками выдает лишь 60% увеличение произданных, поступающими в реальном от производительводительности при времени, требуются гетерогенные ности той же пары умножении матриц. процессоры, сочетающие в себе возE 5 -2 6 97 v 3 п р и Умножение разможности CPU и GPU. одинаковом уровреженных матриц Леонид Черняк «Открытые системы. СУБД», № 04, 2014 не производительн а в е к т о р а к т уности в расчете на ально, например, ватт. Это означает, для некоторых мечто традиционные двухпроцессорные тодов квантовой ядерной физики. Так, серверы/х86-64 в кластерах вплоть в Национальном научном энергетическом до суперкомпьютерного уровня могут центре США на Knights Landing с 64 ядрабыть заменены на серверы с процес- ми / 1,3 ГГц и c 96 Гбайт DDR4 / 2133 МГц сорами Knights Landing, а в реальных было получено ускорение в 1,6 раза по HPC-приложениях будет достигаться сравнению с двухпроцессорным сервером, более высокая, чем демонстрируемая оснащенным 16-ядерными процессорана тестах SPEC, производительность ми Haswell / 2,3 ГГц и 128 Гбайт такой же при более низком энергопотреблении. памяти. Явное указание компилятору на Высокопроизводительным прило- использование 16 Гбайт MCDRAM в обжениям наиболее точно соответствуют щем адресном пространстве дало повытесты, основанные на BLAS и конкретно шение производительности в 1,2 раза по BLAS 3-го уровня — например, умноже- сравнению с ее применением исключиние матриц из чисел двойной точности тельно как кэш-памяти. (тест dgemm). Первые результаты уже При выполнении тестов STREAM/triad были обнародованы Джеком Донгаррой для Xeon Phi 7250 с MCDRAM достигает(J. Dongarra «Form Follows Function — ся пропускная способность 421 Гбайт/с, Do Software, Algorithms & Applications а с памятью DDR4 — 88 Гбайт/с, что близChallenge or Drag behind the Hardware ко к результатам процессоров Haswell Evolution?»). Для 68-ядерного Knights E5-2670 v3. Landing c частотой 1,3 ГГц и пиковой Примечательно, что в рейтинге Top500 производительностью 2,5 TFLOPS при (июнь 2016 года) уже появился первый

28 • Открытые системы • 03/2016 • www.osmag.ru

суперкомпьютер на платформе Knights Landing, занявший 117-е место с пиковой производительностью около 1,5 PFLOPS, — это кластер Stampede-KNL Университета Техаса. В нем используются межсоединение Intel Omni-Path и процессоры Xeon Phi 7250 — всего около 33 тысяч ядер. *** Выпуск процессоров Intel Xeon Phi Knights Landing серии x200 означает, что впервые в индустрии появилась возможность создания широкого спектра высокопроизводительных систем — от серверов до суперкомпьютеров — на новой архитектуре, двоично совместимой с x8664. В таких системах могут выполняться популярные операционные системы и имеющиеся приложения, однако в них исчезает необходимость обменов данными GPU-CPU. Единая архитектура Knights Landing облегчает создание прикладных программ, работающих в гетерогенных конфигурациях [4]. В ряде случаев Knights Landing пока уступает по быстродействию самым быстрым специализированным графическим ускорителям, однако производитель уже планирует переход к новому поколению Knights Hill [2], которые будут выпускаться по технологии 10 нм. 

Литература 1. A. Sodani. Knights Landing (KNL): 2nd

Generation Intel Xeon Phi. URL: http:// www.hotchips.org/wp-content/uploads/ hc_archives/hc27/HC27.25-Tuesday-Epub/ HC27.25.70-Processors-Epub/HC27.25.710Knights-Landing-Sodani-Intel.pdf (дата обращения: 10.09.2016). 2. G. Eric. What public disclosures has Intel made about Knights Landing? URL: https:// software.intel.com/en-us/articles/whatdisclosures-has-intel-made-about-knightslanding (дата обращения: 10.09.2016). 3. Михаил Кузьминский. Графические процессоры для HPC // Открытые системы. СУБД. — 2013. — № 10. — С. 12–15. URL: http://www.osp.ru/os/2013/10/13039063 (дата обращения: 10.09.2016). 4. Тимур Палташев, Илья Перминов. Гетерогенная архитектура для CPU, GPU и DSP // Открытые системы.СУБД. — 2013. — № 8. — С. 12–15. URL: http://www. osp.ru/os/2013/08/13037850 (дата обращения: 18.09.2016). Михаил Кузьминский (kus@free.net) — сотрудник, Институт органической химии РАН. Работа поддержана РФФИ (проект 16-07-01227).

менеджмент ИТ

Как повысить эффективность бизнеса? Причина большинства проблем любой системы кроется в ней самой и вызвана несогласованными действиями, приводящими к пустому расходованию ресурсов. Какие части ИТ-системы и как следует синхронизировать между собой? Ключевые слова: управление бизнес-процессами, управление ИТ, управление организационными изменениями, управление проектами, управление процессами Keywords: Business Process Management, IT Management, ITSM, Organizational Change Management

Антон Саввин

ольшинство неудач в функционировании любой системы принято списывать на внешние обстоятельства, однако если правая рука не знает, что делает левая, то все усилия будут расходоваться на внутреннее трение. Эволюция управления бизнес-системами проделала путь от единых иерархий через проектные и процессные матрицы к плоским мобильным структурам управления. Цифровая трансформация условно разделила бизнес-систему на часть, контактирующую с клиентом, например через мобильные устройства, и на инфраструктуру, обеспечивающую обработку событий, генерируемых клиентом. Это и есть «левая» и «правая» руки бизнес-систем. Попробуем разобраться в природе их синхронизации. Бизнес можно сравнить с открытой с двух сторон трубой переменного сечения, в которую внешний мир пытается «залить» множество событий (рис. 1), а бизнес, как разумная система, пытается уловить, привлечь к себе, отфильтровать и втянуть вовнутрь только важные и полезные для него события, преобразовав их на выходе в желаемые целевые результаты — Demand и Supply (потребность и обеспечение). Задача левой области (Demand) — определение потребностей бизнеса, а цель правой (Supply) — реализация этих потребностей. Стенки трубы — это бизнес-правила, регламентирующие и ограничивающие потоки работ. Площадь сечения трубы — это ресурсы, которые бизнес расходует на выполнение процессов. Для эффективного расходования ресурсов требуются регистрация,

корреляция и ранжирование событий, поступающих на вход. Для принятия качественных решений в область Supply должны проходить только упорядоченные потоки работ, которыми действительно надо заниматься. Такое разделение деятельности на Demand и Supply и есть базовое разделение зон ответственности людей в реальном бизнесе — не на управленцев и подчиненных, не на бизнес-подразделения и их обслугу, а на сотрудников, смотрящих во внешний мир глазами бизнеса, и сотрудников, реализующих потребности бизнеса при текущих ограничениях. При этом люди обычно склонны находиться преимущественно либо в реактивной аналитической, либо в проактивной созидательной области работ. Именно поэтому область Demand на рис. 1 отмечена синим цветом и ассоциируется с фазой Check, а область Supply отмечена красным и ассоциируется с фазой Plan классического цикла PDCA (Plan, Do, Check, Act). Однако ошибкой было бы ставить знак равенства между Demand и реактивным состоянием Check, а также между Supply и проактивным состоянием Plan. Люди, работающие преимущественно «слева» или «справа», занимаются разными, но самодостаточными делами и движутся в своем полном цикле деятельности PDCA. Труба потоков работ не делится жестко на синюю и красную половины — обе плавно проникают друг в друга. Именно в этом проникновении и кроется секрет эффективности бизнеса. А что же внутри трубы? На вопрос «Где заканчивается операционная рутина и начинается область развития и изменений?» имеется такой ответ: «Вы сами решаете, что считать

изменением в архитектуре своей системы». Нет точной границы, а есть плавный переход между стандартной, основанной на опыте деятельностью (Run) и деятельностью, направленной на изменения в системе (Change). В своих крайних состояниях Run представляет собой мгновенные автоматические системные операции, а Change — долгие проекты с большой неопределенностью. Подобно геному человека, Run несет ответственность за наследственность и повторяемость в бизнесе, а Change — за изменчивость и появление новых свойств. Модель трубы активностей можно уточнить, разместив скоротечную и зачастую автоматизированную деятельность Run вблизи оси, а медленную и нестандартную Change — по краям трубы активностей Рассмотрим такую уточненную модель через призму департамента ИТ (рис. 2). Верхняя половина такого среза, подобно ресурсно-сервисной модели ITSM [1], ассоциируется с клиентскими сервисами, а нижняя «смотрит» на техническую инфраструктуру. Каждая из областей Demand и Supply вдоль линии течения процесса делится на зону Front Office, контактирующую с внешней средой, и Back Office, расположенную ближе к центру и выполняющую внутрисистемные операции. Из рис. 2 видно, как можно эффективно выстроить организационную структуру ИТ-подразделения: оно естественным образом должно стараться повторять структуру потока работ в его отдельных частях. На левой границе трубы во Front Office Demand поток структурируется по точкам контактов с внешней средой: сверху — по клиентам и сервисам, а сни-

www.osmag.ru • 03/2016 • Открытые системы • 29

менеджмент ИТ Demand

Supply

Обращения клиентов

Реализованные проекты

Рынок Ранжирование и приоритизация событий

Мониторинг событий

Глобальные события

Цели Стратегия Стандарты

Поставки клиентам

Реализация дорожной карты работ

Настройки сервисов

Act

Новые технологии и поставщики

Chec

Изменения внутри системы

Plan

Рис. 1. Модель современного бизнеса зу — по сложившимся инфраструктурным технологиям. Ближе к центру, в области Back Office Demand, поток переструктурируется в архитектуру предметной области компании, по технологиям уже работающих в ней продуктов. В каждой отрасли (телекоме, медицине, финансах, энергоснабжении и пр.) архитектура предметной области своя, поэтому подавляющее большинство сотрудников Demand — это бизнес-аналитики, архитекторы, менеджеры проектов и технические писатели, ведь основной продукт, создаваемый Demand, — это проектные требования, а не конечный продукт.

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

Demand

Рынок и цели клиента

Supply

Plan

Act

Chec Demand front office

Далее, справа, в области Back Office Supply поток переструктурируется в архитектуру изготовления и предоставления продуктов, которая зависит не столько от предметной области, сколько от инструментария изготовления. Так, например, для создания современных ИТрешений требуется собирать людей не по знанию банковского или страхового бизнеса, а по владению технологиями (разработчики, тестировщики и т. д.). Только в этом случае «фабрика Supply» становится «мобильной», не зависящей ни от состава временно привлекаемых ресурсов, ни от конкретных заказчиков из Demand. И наконец, Front Office Supply, крайняя область справа, полностью повторяет Front Office Demand, поскольку мы циклично возвращаемся к точкам контакта с клиентами и всем внешним миром. Здесь можно было бы остановиться, однако в такой модели имеется разрыв потоков Change на верхний и нижний слои. Этот разрыв на практике соответствует разделенности и разобщенности людей и подразделений, называющих себя бизнесом, и теми, кто работает с ИТинфраструктурой. Разрыв в модели — не ошибка. Дело в том, что до сих пор речь шла о трубе событий, но в модели указывался лишь

Demand back office

Инструкции и комитеты

Supply back office

Supply front office

Change Проблемы клиентов

Клиент

Обращения клиентов

Стандарты

Change Customer demand front office

Поставки клиентам Цели Стратегия Стандарты

Run service desk

Run & change services Настройки сервисов

Demand front office

RUN

Мониторинг инфраструктуры

Реализованные проекты

Принятие решений

Supply back office

Run technical monitoring

Run service fulfilment

RUN Настройки инфраструктуры

Run & change infrastructure

Инфраструктура Проблемы инфраструктуры

Change R&D

Управление проектами Управление изменениями Управление разработкой Управление поставками

Управление клиентским опытом Управление производительностью Управление качеством Управление требованиями

Поставки клиентам

Change Новые технологии и поставщики

Change По клиентам, сервисам и технологиям

По архитектуре предметной области BSS/OSS

Рис. 2. Труба активностей с точки зрения ИТ

30 • Открытые системы • 03/2016 • www.osmag.ru

По способам управления

По технологиям разработки

По клиентам, сервисам и технологиям

Изменения инфраструктуры

менеджмент ИТ 24

00 Do

Вечер Телесный анализ

Ночь Творческий анализ

Act

Планирую Проверяю

Делаю

Отдыхаю Plan

18 РМ

Check

AМ

Plan

Делаю

Проверяю Планирую

День Телесный креатив

Утро Творческий креатив

Act

Do 12 12

Рис. 3. Круговое движение двух полярных активностей Demand и Supply поддается тем же законам, что и суточное вращение Земли вокруг своей оси. Это своего рода 24-тактовый циферблат, в который органично вписался цикл PDCA. Термины Plan, Do, Check, Act — это точки, разделяющие фазы цикла. Фазы между точками имеют почти такой же смысл: «Планирую», «Делаю», «Проверяю» и «Отдыхаю» — три четверти активных и одна пассивная Ось трубы (время)

Радиус трубы (ресурсы)

ее продольный плоский срез, хотя реальная труба объемна и требуется понять, как она устроена в поперечном срезе. Взглянув сквозь всю модель слева, можно обнаружить калейдоскоп событий — вращение Demand и Supply с периодической сменой полюсов (рис. 3). Demand и Supply, продвигаясь вперед вдоль оси времени, вращаются вокруг нее, находясь в полной противофазе... Именно так, не растворяясь друг в друге, а закручиваясь в две спирали по оси времени, Demand и Supply взаимодействуют друг с другом. Действительно, все сотрудники компании не могут одновременно бегать по клиентам, а вернувшись, все вместе наваливаться на решение одной-единственной задачи. Каждый должен заниматься параллельно своим делом в своей фазе. Чтобы увидеть суть периодичности фаз Demand & Supply, надо развернуть круговое вращение потока работ в одну ось координат (рис. 4). Медленный цикл, если смотреть глазами Demand, очень похож на происходящее в реальном бизнесе: в первой фазе, пока идут изучение рынка и планирование будущих проектов, технари-исполнители уже выполнили очередную прошлую задачу и проверяют результаты ее внедрения. На следующем этапе технический персонал перешел в режим отдыха в поисках следующей задачи, а у людей, работающих напрямую с клиентами, наступила вторая фаза основной активности. Что это за активность? Результатом Demand не должен быть конечный продукт, а могут быть только архитектура и проект, разработанные в терминах бизнеса. На этой фазе можно оторвать Supply от отдыха и привлечь его к разработке Demand-продукта, но ответственным за разработку документа, который часто называют БФТ («Бизнеси функциональные требования»), является только Demand — другого результата его деятельности нет. На третьей фазе происходят «квантовый переход» и передача эстафеты от Demand к Supply. В соответствии с технологией, Supply приступает к планированию изготовления продукта, а Demand релаксирует, проверяя, наcколько качественно отработаны БФТ, и корректируя, пока еще не поздно, планы Supply. На четвертой фазе Supply осуществляет план реализации продукта. Вмешаться в это исполнение со стороны Demand практически нет возможности И так

Plan 18

Вечер

Do 00

Ночь

Check 6

Утро

Планирую

Act 12

День

Plan 18

Планирую Supply

Делаю

Проверяю

Check

Вечер

24 Act

Ночь

Do 00

Планирую

Demand

Вечер

6 Plan

Утро

Проверяю 12 Do

День

18 Check

Вечер

24 Act

Рис. 4. Развертка трубы активностей повторяется из цикла в цикл, от почти мгновенных автоматических операций Run, выполняемых с высокой тактовой частотой, до медленных проектов Change, длящихся месяцами и кварталами. *** Секрет эффективности бизнеса зависит от умения руководства предприятия увязать Demand и Supply с тактовой частотой двух естественных асинхронных циклов PDCA. Организационную структуру компании и ИТ-подразделения изначально надо строить разделяя на части Demand и Supply, внутри которых следует максимально повторять структуру потоков работ, которые будут максимально локализованы внутри линейных подразделений. Подразделениям Demand и Supply по отдельности не стоит поручать полный цикл работ от выявления потребности бизнеса до реализации поставки — каж-

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

Литература 1. Михаил Потоцкий.

Будущее ITSM в России // Открытые системы.СУБД. — 2010. — № 5. — С. 24–26. URL: http://www. osp.ru/os/2010/05/13003046 (дата обращения: 18.07.2016). Антон Саввин (ASavvin@trans-ts.ru) — генеральный директор компании «ТрансТехСвязь» (Москва).

www.osmag.ru • 03/2016 • Открытые системы • 31

Интернет вещей

На пороге Индустриального интернета вещей Интернет вещей пришел из мира повседневных «умных» устройств, а теперь настало время Индустриального интернета, интегрирующего производственные процессы изготовления сложных изделий. Однако для развертывания Индустриального интернета требуется платформа разработки решений. Ключевые слова: Индустриальный интернет, индустрия 4.0., Интернет вещей, цифровая трансформация Keywords: digital transformation, Industrial Internet, Industry 4.0., Internet of Things, PLM

Владимир Краюшкин, Марина Пирогова, Ирина Лешихина

нтернет вещей (IoT) не только объединяет «умные» изделия, но и оказывает влияние на все мировое бизнес-сообщество, способствуя повышению конкурентоспособности компаний [1] и совершенствованию работающих в сети конечных изделий, снабженных встроенными «умными системами», которые порождают информационные потоки больших объемов, пополняют статистику изменения эксплуатационных характеристик изделий и автоматически обновляют встраиваемое программное обеспечение, что позволяет им эволюционировать. При этом сохраняются отношения информационного обмена компании-изготовителя с пользователями, а основными областями приложения Интернета вещей становятся отрасли, ориентированные на сервисы и контроль их качества: транспортное обслуживание, медицинские высокотехнологичные исследования, эксплуатация недвижимости, контроль параметров работы сложных технических устройств, сбор и отображение статистики эффективности использования технических решений. «Умные» изделия способствуют изменению понимания роли и места Интернета вещей в современном мире — к 2025 году он может приносить мировой экономике до 11,1 трлн долл. в год, а по данным аналитиков Accenture, к 2030 году вклад Интернета вещей в мировое производство мог бы составить около 14,2 трлн, что даст прибавку в 11% к мировому ВВП.

Однако существует похожий на Интернет вещей стек технологий, включающий в себя и интеллектуальные устройства, и коммуникационную инфраструктуру, и организацию выработки оперативных решений по совместному применению связанных «вещей». Речь идет о дискретном промышленном производстве, неотъемлемая часть которого — системы CAE/CAM, M2M (manufacturing to manufacturers — «производство средств производства») и DAQ (Data AcQuisition — «системы сбора данных»). Современное дискретное производство с его автоматизированными комплексами, роботизированными линиями, станками с ЧПУ включает, по сути, все компоненты Интернета вещей — любое автоматизированное рабочее место, имеющее типичный набор характеристик «умного» устройства, немыслимо без коммуникационной инфраструктуры и обязательно включает управляющее ПО. Отсюда следует, что ожидаема конвергенция Интернета вещей и стека технологий машинного производства, а прогресс в автоматизации производства будет связан с использованием технологий Интернета вещей, что в целом позволяет говорить о начале четвертой промышленной революции и развертывании Индустриального интернета (Industrial Internet of Things, IIoT). Поскольку в области CAM сформировалось и эффективно функционирует сообщество технических специалистов, существует парк производственных мощностей автоматизированного «традиционного» машинного производства, накоплен опыт технологий M2M SCADA, MES и т. п., «традиционные» технологии автоматизирован-

32 • Открытые системы • 03/2016 • www.osmag.ru

ного и автоматического производства будут и в дальнейшем активно использоваться в организации сквозных производственных процессов на уровне «цех — производственный участок — сборочная линия». Для объединения этих «традиционных» технологий, всех их типов и конфигураций с целью разработки и эксплуатации изделий любого уровня сложности требуется промежуточный слой, ответственный за унификацию процессов интеграции традиционных технологий производства в единое информационное пространство Интернета вещей. Разработка такого слоя затронет интерфейсы к устройствам, программную и инфраструктурную составляющие. Для реального Индустриального интернета необходимо провести доработку шлюзов и конвертеров из стандартов информационных моделей данных и шин передачи данных структур SCADA/MES/ M2M/DAQ, обслуживающих конечные интеллектуальные изделия производственного назначения, в стандарты представления и передачи данных в Интернет вещей. В первое время это будут недорогие контроллеры, встраиваемые как дополнительные ИТ-модули и работающие с промышленным интеллектуальным оборудованием по шинам передачи данных в форматах традиционного стека, которым предстоит транслировать получаемую от оборудования информацию в инфраструктуру Интернета вещей. Такие контроллеры-шлюзы работают с промышленными стандартами информационного обмена интеллектуального оборудования (I2C, SCI, UART, RS-232-C, CAN, Modbus, Profibus и т. д.), преобразуя поток данных реального

Интернет вещей Платформы Индустриального интернета Управление устройствами

Интеграция

Безопасность

Протоколы

Аналитика

Поддержка визуализации

2lemetry*

Да

Salesforce Heroku, ThingWorx API

SSL, ISO 27001, SAS70 Type II

MQTT**, CoAP, STOMP

Аналитика реального времени (Apache Storm)

Нет

ParStream***

Нет

R, UDX API

Нет данных

MQTT

IBM IoT Foundation Device Cloud

Да

REST API

TLS, IBM Cloud SSO, LDAP

MQTT, HTTPS

PTC ThingWorx

Да

REST API

ISO 27001, LDAP

Платформа

LogMeIn Xively- PaaS

Нет

REST API

SSL/TSL

EVRYTHNG

Нет

REST API

SSL

Bosch IoT Suite

Да

REST API

Нет данных

MQTT, AMQP, XMPP, CoAP, WebSockets HTTP, HTTPS, Sockets/ Websocket, MQTT MQTT,CoAP, WebSockets MQTT, CoAP, AMQP,STOMP

Appcelerator

Нет

REST API

SSL, IPsec, AES-256

AWS IoT

Да

REST API

Ericsson Device Connection Platform

Да

REST API

PLAT.ONE

Да

REST API

Аналитика реального времени Да, веб-портал (IBM IoT Real-Time Insights) Аналитика реального времени, Batch analytics Да, ParStream (ParStream DB) Management Console Предиктивная аналитика (ThingWorx Machine Learning), Да аналитика реального времени (ParStream DB) Нет данных

Да, консоль

Аналитика реального времени (Rules Engine)

Да

Нет данных

Да

MQTT, HTTP

Аналитика реального времени

TLS,SigV4, X.509

MQTT, HTTP

Аналитика реального времени (Amazon Kinesis, AWS Lambda)

Да (Titanium UI Dashboard) Да (AWS IoT Dashboard)

SSL/TSL, карта SIM

CoAP

Нет данных

Нет

Нет данных

Да, консоль, управление устройствами

SSL, LDAP

MQTT, SNMP

* 2 lemetry — платформа приобретена Amazon. ** M QTT (Message Queueing Telemetry Transpor) — облегченный протокол передачи сообщений между датчиками и мобильными устройствами. Предложен в IBM, затем передан OASIS, ставшей впоследствии головной организацией по PLM для НАТО; CoAP (Constrained Application Protocol) [2] — протокол приложений для встроенных устройств; STOMP (Simple Text Oriented Messaging Protocol) — простой протокол обмена сообщениями; AMQP (Advanced Message Queuing Protocol) — открытый протокол обмена сообщениями, обеспечивающий интероперабельность различных технологий обмена; XMPP (Extensible Messaging and Presence Protocol) — открытый расширенный протокол на основе XML для обмена сообщениями в режиме, близком к реальному времени. *** P arStream приобретена Cisco.

времени в пакеты передачи информации систем Интернета вещей, работающих с популярными стандартами 802.11b/g/n, 802.15.4, CGM и т. д. Имеющиеся сегодня микроконтроллеры на платформе ОС Linux, снабженные набором программируемых прототипов интерфейсных коммуникационных подсистем, уже используются для такого рода задач промежуточного слоя, позволяя станку, роботу и производственной линии работать в требуемой операционной последовательности по «своим» интерфейсам и в режиме реального времени, а с внешним миром общаться как обычное «умное» устройство Интернета вещей. Для разработки переходного к Индустриальному интернету оборудования требуется обеспечить аппаратно-«вещевую» и инфраструктурную составляющие стека Интернета вещей, а также провести изменения в организации. По сути, для активизации разработок в области Индустриального интернета необходимо наличие платформы создания решений, одновременно учитывающих особенности традиционных подходов, принятых в производстве, и стека Интернета вещей. Именно платформы, а не отдельных решений для каждого индивидуального и особенного ландшафта цифрового производства предприятия — в мире нет двух одинаковых по структуре, парку оборудования, сети поставщиков и бизнес-стратегии предприятий. Для массового перехода к Индустриальному интернету потребуется платформа, позволяющая управлять «умными» устройствами, поддерживать архитектуру интеграции, обеспечивать информационную безопасность обмена данными, вести единую мо-

дель данных, поддерживать визуализацию и решать задачи аналитики. Поставщиками такого рода платформ для Индустриального интернета могут стать компании, имеющие опыт в области автоматизации разработки и производства сложных изделий (CAM в составе PDM/PLM), способные поставлять ИТрешения и обладающие ресурсами для разработки ПО корпоративного уровня. Вряд ли стоит ожидать предложения таких платформ от компаний, занимающихся внедрением технологий Интернета вещей, — этот сектор еще слабо структурирован, и крупных компаний здесь нет. Участники этого рынка далеки от разработок в сфере автоматизации производства и не готовы предлагать свои методы для разработки в «классическом» понимании (умный дом, умный холодильник, умная метеостанция и т. д.) в качестве платформы Индустриального интернета. Более того, компании, накопившие опыт в интеграции решений Интернета вещей, становятся объектом купли-продажи для компаний — разработчиков производственных систем. Известные игроки ИТрынка, включая и поставщиков решений ERP (Cisco, IBM, SAP и др.), уже давно поодиночке не играют. И хотя они могли бы дополнить свои системы решениями Индустриального интернета, но не имеют опыта встраивания своих решений в стек технологий работы с производственным оборудованием. Иначе говоря, неясно, как, например, SAP или Cisco будут организовывать взаимодействие парка станков с ЧПУ со сварочными и транспортными роботами, а также с автоматизированными линиями.

В таблице представлены платформы Индустриального интернета, предлагающиеся сегодня на рынке. *** Для полноценного Индустриального интернета необходимо построить сеть станков с ЧПУ, роботов и автоматизированных линий, взаимодействие которых автоматически выстраивается в соответствии с процессным подходом, аналитика подпитывается за счет постоянного мониторинга параметров «умного» оборудования. Развертывание Индустриального интернета требует платформы разработки, в противном случае такая работа в каждом случае будет носить уникальный характер. Такую платформу уже сегодня способны вывести на рынок производители, работающие в секторе межмашинного взаимодействия, и поставщики систем PLM. 

Литература 1. Ирена Боянова, Джордж Херлберт,

Джеффри Воас. Интернет будущего // Открытые системы.СУБД. — 2014. — № 6. — С. 28–31. URL: http://www.osp.ru/ os/2014/06/13042314 (дата обращения: 18.08.2016). 2. Павел Храмцов. Быть или не быть стандартам Интернета вещей? // Открытые системы.СУБД. — 2015. — № 2. — С. 24–26. URL: http://www.osp.ru/os/2015/02/13046275 (дата обращения: 18.08.2016). Владимир Краюшкин (vkray@pts-russia.com) — руководитель проектов, компания «ПТС», Марина Пирогова (PirogovaMA@mpei.ru), Ирина Лешихина (liy56@mail.ru) — доценты МЭИ.

www.osmag.ru • 03/2016 • Открытые системы • 33

интеграция

Цифровая трансформация и BPM Цифровые технологии стремительно врываются во все сферы жизни общества — кардинально меняются методы управления предприятиями, а управление бизнес-процессами получило дополнительный импульс в виде обязательной автоматизации. Время «бумажных» процессов закончилось. Ключевые слова: инструментарий BPM, цифровая трансформация Keywords: BPM tools, BPMS, Digital Transformation

Юлия Вагнер, Мария Сефер

ля бизнеса цифровая трансформация [1] может стать источником новых возможностей, позволяющих расширить привычные рамки использования ИТ и получить конкурентные преимущества за счет лучшей организации работы и создания дополнительных сервисов, востребованных клиентами. Однако для этого должны быть кардинально изменены способы управления бизнес-процессами (Business Process Management, BPM), связывающие в единую модель информационные и человеческие ресурсы. Управление компанией, независимо от ее размеров и отраслевой ниши, сегодня подобно езде в автомобиле на высоких скоростях, когда все решает быстрота поступления информации и реагирования на нее. Как и в автомобиле, который, помимо педалей и руля, имеет множество дополнительных приборов, в реальном времени отражающих не только показатели машины, но и внешнее окружение, так и в современных системах управления должны присутствовать рычаги для непосредственного воздействия и всевозможные средства обработки информации. Любое решение будет эффективным только тогда, когда оно принято вовремя и на осно-

вании точной оперативной информации и аналитических данных. Но и этого недостаточно: с изменением внешних вызовов существенно изменился и общий взгляд на деятельность организации, и если раньше достаточно было анализировать выполнение отдельных функций, то сегодня возросла значимость межфункционального взаимодействия, поскольку общую картину можно получить только глядя на процессы целиком. Поэтому цифровая трансформация тесно связана с трансформацией процессной. Как управленческая дисциплина BPM сама по себе не требует обязательной автоматизации; методологически это лишь один из подходов к организации управления. До определенного момента для многих компаний было достаточно лишь описания бизнес-процессов и регламентов работ. Однако так называемые бумажные регламенты дают общую карту устройства бизнеса, но не являются инструментом управления, поскольку они не интерактивны и не предоставляют точных измерений выполняемых операций. Пытаться управлять деятельностью предприятия при помощи бумажных регламентов — это все равно что управлять автомобилем только по технической документации к нему: тут руль, там педали, тут коробка передач. Это тупиковый путь. Для нормальной езды мало прочитать

34 • Открытые системы • 03/2016 • www.osmag.ru

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

интеграция как правило, не претендуют на уникальность, мало отличаются в разных организациях, а их автоматизация обычно не требует специального программного обеспечения, если в компании есть ERP или другая система, в которой уже заложены такие процессы. Использование стандартных административных процессов позволит больше внимания уделить управлению основными процессами, от которых зависит положение компании на рынке. Эти процессы охватывают все функциональные области организации, поэтому управление ими — это управление всей организацией. И если стандартизованные административные процессы — это скорее плюс, чем минус, то в процессах, определяющих бизнес, использование стандартных методов и решений — это потеря индивидуальности и, следовательно, снижение конкурентоспособности. На современном рыночном пространстве конкурируют не продукты или услуги, а бизнес-процессы. Инструмент управления бизнес-процессами — это система BPMS (Business Process Management Suite) [2], позволяющая быстро создавать и изменять процессы, сокращая время их ввода в эксплуатацию благодаря тесной интеграции сред проектирования, разработки и исполнения. Но этого недостаточно — требуется высокое качество аналитических данных. В отличие от процессов, исполняемых «вручную», в BPMS все действия и бездействия учитываются по времени. Каждый шаг имеет своего исполнителя и свою историю, что позволяет получать точные данные для анализа и принимать решения на их основе. Кроме этого, необходимо еще правильно организовать процессы, которые должны быть спроектированы так, чтобы каждая операция выполнялась в нормативное время, а прохождение всего процесса укладывалось бы в определенные сроки. В отличие от других систем (ERP, CRM, ECM и т. д.), операции в которых выполняются только при совершении события, системы BPMS сами инициируют эти события и отслеживают своевременность выполнения операций. В случае угрозы отклонения от сроков они инициируют предупреждающие действия. Ничего из этого не способны обеспечить «бумажные» процессы. Наивно полагать, что цифровая трансформация — это только автоматизация процессов. Если бы это было так, то речь бы шла всего лишь о новом термине или очередной маркетинговой кампа-

нии. Цифровой переворот произошел в нашем сознании, когда значительная часть нашего существования переместилась в Интернет. Еще пять лет назад было достаточно разместить товар на сайте, чтобы его заметили, но сегодня это уже не так. Не покупатель ищет товар, а товар «охотится» за покупателем, отслеживая его активность в Сети, выявляя предпочтения и выбирая лучший момент для предложения. Однако многие организации при проектировании новых и реорганизации старых процессов действуют в привычном ключе: начинают все процессы с обращения заказчика и тем самым оставляют за рамками процесса либо часть самого процесса, либо часть аудитории. Бизнес-процессы должны начинаться не с обращения клиента, а задолго до того, как возникает сама идея появления продукта или услуги. Конкретных рецептов здесь нет — новые возможности возникают постоянно, и все зависит от того, насколько гибкой является компания и сколько времени у нее уходит на запуск нового процесса. Никакие технологии не помогут, если компания не готова меняться. Цифровая трансформация не обошла стороной и сами системы BPMS. Стремясь приблизить работу в системе к привычному образу поведения людей в повседневной жизни, разработчики расширяют ее функционал, создавая мобильные версии приложений, добавляя к традиционным структурированным процессам так называемые адаптивные процессы, а также социальные функции, подобные тем, которые используются в социальных сетях. Адаптивные процессы — это возможность выполнения действий, не предусмотренных заранее. Такие действия обычно выполняются вручную, вне BPMS, а их результаты просто фиксируются в процессе. Дополнение BPMS функциональностью управления адаптивными процессами (Adaptive Case Management, ACM) позволяет сохранять не только результаты работы, но и способ ее выполнения, формируя банк лучших практик. В аналогичной ситуации система предложит пользователю применить уже имеющийся кейс либо взять за основу ранее накопленный опыт и создать новый кейс. Анализ кейсов даст представление о том, как выполняется данная задача, в каком случае на нее тратится меньше времени, в каком случае получен лучший результат. В дальнейшем наиболее распространенные либо результативные сценарии могут

переводиться в процессы, которые уже проверены на практике, и их внедрение не вызовет сложностей, обычно возникающих в первые дни промышленной эксплуатации новых процессов. Функционал ACM реализован в таких системах, как Pega 7 Platform, Comindware Business Application Platform и BizAgi BPM Suite 11.0. Социальные функции — это обмен сообщениями между участниками процесса или обращение за помощью к экспертам. В любой момент времени исполнитель может привлечь к решению вопроса любого участника процесса, что сокращает время на поиск решения и, следовательно, на прохождение процесса. Кроме того, наличие внутренней социальной сети позволяет упростить многие процессы, в которых раньше для уточнения деталей или получения одобрения приходилось переназначать задания либо обходить систему. Социальные функции реализованы в таких системах, как IBM BPM, Pega 7 Platform, Comindware Business Application Platform и BizAgi BPM Suite. *** Революция — это ломка привычных устоев и появление новых условий, которые для одних становятся источником проблем, а для других — источником возможностей. Если решать проблемы, то можно отстать, а если искать возможности, то появляется шанс вырваться вперед. Цифровая трансформация в BPM — не только способ повысить производительность бизнес-процессов путем их автоматизации, но и получение ряда возможностей для перехода на качественно новый уровень работы. Для того чтобы воспользоваться этими возможностями, надо не только кардинально перестроить бизнес-процессы, но и трансформировать сознание. 

Литература 1. Александр Прохоров. Цифровая транс-

формация в цифрах // Открытые системы. СУБД. — 2016. — № 2. — С. 16–21. URL: http://www.osp.ru/os/2016/02/13049319 (дата обращения: 18.09.2016). 2. Свод знаний по управлению бизнеспроцессами: BPM CBOK 3.0 / Под ред. А.А. Белайчука, В.Г. Елиферова. Пер. с англ. — М.: Альпина Паблишер, 2016. — 480 с. ISBN 978-5-9614-5455-0. Юлия Вагнер (julia@b-k.ru) — директор по развитию BPM, компания «Бизнес-Консоль», Мария Сефер (maria.sefer@yandex.ru) — независимый консультант (Москва).

www.osmag.ru • 03/2016 • Открытые системы • 35

облака

Инструмент цифровой трансформации По прогнозам аналитиков IDC, в 2017 году будут лидировать компании, выбравшие цифровую трансформацию центром своей стратегии, однако главная проблема на пути ее реализации — внедрение новых облачных технологий без нарушения работы традиционных систем, что трудно сделать без специальной платформы. Ключевые слова: облака, гибридные облака, цифровая трансформация Keywords: сlouds, hybrid cloud, digital transformation, OpenStack

Анатолий Третьяков

огласно опросу, недавно проведенному аналитиками IDC, в 76% европейских компаний проекты цифровой трансформации инициируются бизнес-подразделениями, причем в 60% компаний планируют создать специальную структурную единицу, которая будет отвечать за цифровую трансформацию и за решение одной из главных задач — внедрение облачных технологий без нарушения работы уже имеющихся систем. Обычно это требует существенных затрат на полное обновление серверного парка, что, как правило, означает потерю части ранее сделанных инвестиций в оборудование и ПО. Кроме того, может оказаться, что критичные для бизнеса приложения не будут работать на новой

платформе либо их производительность упадет. Для успешного перехода к применению облаков недостаточно только технологий — необходимо иметь ясную концепцию этого перехода и платформу, позволяющую минимизировать затраты и возможные риски. Облачная платформа Fujitsu Digital Business Platform MetaArc [1] призвана помочь предприятиям пройти путь цифровой трансформации, ускорив внедрение приложений работы с Большими Данными, систем поддержки мобильности сотрудников и Интернета вещей (см. рисунок). MetaArc предоставляет необходимую для цифровой трансформации инфраструктуру и помогает интегрировать ее с уже имеющимися в компании ИТ-решениями, поддерживая модели IaaS, PaaS и SaaS. Платформа не конкурирует

36 • Открытые системы • 03/2016 • www.osmag.ru

с облачными сервисами Amazon, Google или Microsoft, а ориентирована на объединение частных корпоративных облаков с внешними ресурсами. Ядро MetaArc образовано на базе облака Fujitsu Cloud Service K5, технологий из OpenStack [2] и сервисов K5 Portal, K5 Openstack API и K5 Openstack Command Line Tool, обеспечивающих надежность, доступность и масштабирование. В среде K5 развернуто сегодня около 600 корпоративных систем, размещаемых на 13 тыс. серверов. Пользователи могут выбрать необходимые им сервисы для оптимального использования имеющихся ресурсов. Например, на базе модуля Service Catalog Manager может быть организован портал самообслуживания с привлечением доступных услуг из частных или публичных облаков. С помощью отдельных модулей можно организовать централизованную систему финансового контроля за предоставляемыми ИТ-услугами или общий мониторинг за всеми ресурсами. На данный момент в облаке K5 работают информационные системы самой компании Fujitsu (подразделения System Engineering, Software Development и Fujitsu Laboratories) и ее клиентов по всему миру. До недавнего времени это были сервисы глобальной облачной платформы Fujitsu Cloud IaaS Trusted Public S5, которая функционировала на базе модифицированного программного обеспечения Fujitsu ServerView Resource Orchestrator Cloud Edition, обеспечивающего динамическое управление ресурсами и сервисами облака. Для разработки и тестирования новых приложений, что особенно актуально для провайдеров SaaS, предлагаются публичные облака на базе ЦОД Fujitsu по

облака Бизнес-критичная (имеющаяся) система: надежная ИТ

Индустриальные сервисы

Отраслевые компоненты/сервисы/шаблоны

PaaS

Сервисы управления Web API

Общие сервисы управления

ID, учет, управление правами, резервное копирование, логи

Поддержка бизнеса и операций

RDB, обмен сообщениями, email, IDS/IPS, DNS, CDN

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

Среда разработки/ внедрения на базе CloudFoundry Разработка, создание и пакетирование конфигураций систем и функциональных модулей

IaaS

Систем. сервисы автоконфигурирования

Платформные сервисы для работы облачных приложений

Публичные облака, виртуальные частные облака, собственные облака (на площадке заказчика и вне ее)

Управление выделяемыми ИТ-ресурсами

Учет / управление заказами и т. п.

Публикация/управление Web API

Универсальные компоненты

Управление системными приложениями

Системы для нового бизнеса: быстрая ИТ

Сервисы поддержки автономной работы системы

всему миру. Для обслуживания бизнескритичных приложений развертывается виртуальное частное облако Virtual Private Hosted, а для построения облака на предприятиях — выделенная облачная платформа в их собственном ЦОД, ЦОД Fujitsu или ее партнеров. Развертывание может происходить с помощью технологий VMware, на базе решений OpenStack либо на «голом» железе (Bare Metal). Предприятиям, не имеющим собственных ЦОД, предлагается облачная платформа, для работы с которой предоставляются сервисы удаленного мониторинга и управления из глобальных центров оказания услуг Global Delivery Center. Для пользователей, предпочитающих свое частное облако, предлагаются интегрированные системы Primeflex — готовые к использованию программно-аппаратные комплексы (например, Primeflex for Red Hat OpenStack, служащий для развертывания частного облака IaaS с опцией гипермасштабируемого хранилища данных на основе пакета OpenStack Ceph и системы хранения Fujitsu Eternus CD10000) либо эталонные архитектуры, настраиваемые в соответствии с конкретными потребностями. Для управления корпоративными приложениями в мультиоблачной среде используется система Uforge от французской компании UShare Soft, вошедшей в состав Fujitsu. Данная система применяется для работы с гибридной ИТ-инфраструктурой и представляет собой пакет программ автоматизации процесса построения, миграции и развертывания приложений и систем в среде из нескольких облаков. Кроме того, гипервизор VMware был оптимизирован для использования в облаке K5, что позволяет обеспечить бесшовный перенос бизнес-критичных приложений. Возможности PaaS, которыми обладает облако K5, могут быть расширены за счет использования контейнеров VMware vSphere Integrated Containers для разработки и распространения облачных приложений и адаптации корпоративных приложений под меняющиеся требования цифрового бизнеса. Платформа MetaArc позволяет интегрировать бизнес-процессы, задействуя средства Fujitsu RunMyProcess — решения по оптимизации потоков бизнеспроцессов, поддерживаемых облачными системами, корпоративными ЦОД и мобильными системами. С помощью RunMyProcess можно создавать, внедрять и распространять специализированные корпоративные и мобильные приложе-

Глобальная сеть: обеспечение взаимодействия инфраструктур мобильных устройств, офисов и дата-центров

Сервисы MetaArc ния, соответствующие потребностям конкретного бизнеса; приложения создаются методом буксировки (drag-and-drop) из отдельных функциональных модулей, для объединения которых предлагается около 2400 коннекторов для SaaS и других приложений, имеется также интеграция с Google Apps. В России пока нет примеров применения MetArc, однако служба доходов и налогов Великобритании уже работает на этой платформе в средах IBM AIX и Linux, где также развернута среда разработки и тестирования новых приложений. В этом проекте компания Fujitsu обеспечивает доступ к облачным сервисам, в частности, по модели IaaS с помощью виртуальных контейнеров предоставляя вычислительные мощности, оперативную память и дисковую емкость. Благодаря частному облаку время развертывания новых приложений в проекте сократилось с нескольких месяцев до нескольких дней. Итальянская нефтеперерабатывающая компания TotalErg построила гибридную ИТ-инфраструктуру из развернутого в ЦОД Fujitsu частного облака, в котором выполняются основные бизнес-критичные приложения, а на виртуализованной инфраструктуре собственного ЦОД работают остальные бизнес-системы. Применение гибридной ИТ-инфраструктуры позволило сокра-

тить операционные расходы TotalErg на 30%. *** В отличие от гибридных облаков, платформа MetaArc обеспечивает бесшовную интеграцию, оркестровку и управление всей ИТ-инфраструктурой поддержки бизнеса, объединяющей как системы нового поколения, так и традиционные корпоративные решения. Единая платформа не только позволяет ускорить выполнение бизнес-процессов цифрового предприятия, но и дает возможность в рамках одной инфраструктуры разрабатывать новые приложения и обеспечивать поддержку бизнес-критичных систем. 

Литература 1. Наталья Дубова.

Найти баланс // C ompute r wor ld Ро сс и я. — 2015. — № 24. — С. 10. URL: http://www.osp.ru/ cw/2015/24/13047844 (дата обращения: 18.09.2016). 2. Дмитрий Волков, Лев Левин. Секреты успеха OpenStack // Открытые системы. СУБД. — 2015. — № 2. — С. 14–17. URL: http:// http://www.osp.ru/os/2015/02/13046272 (дата обращения: 10.09.2016). Анатолий Третьяков (anatoly.tretyakov@ts.fujitsu.com) — менеджер по маркетингу ИТ-услуг Fujitsu (Москва).

www.osmag.ru • 03/2016 • Открытые системы • 37

мир

Работа на опережение Ежедневно появляются сотни мобильных приложений, среди которых много критичных как для бизнеса, так и для жизнедеятельности общества, от надежности работы которых может буквально зависеть жизнь компаний и людей. Лаборатория HPE Mobile Center выпускает инструменты для тестирования мобильных приложений, охватывающие практически все платформы и типы устройств. Ключевые слова: Большие Данные, набор программного обеспечения HPE Mobile Center, тестирование Keywords: ALM, Big Data, BYOD, Set software HP Mobile Center, Testing

Игорь Левшин

аборатория HPE Mobile Center создана в 2015 году для разработки инструментов тестирования мобильных приложений. В многофункциональной системе тестирования HPE Mobile Center имеются средства управления физическими мобильными устройствами, эмуляции устройств и различных типов мобильных сетей, а также функции анализа Больших Данных. Все это стало возможно в том числе благодаря тому, что коллектив лаборатории входит в состав исследовательского центра компании HPE, находящегося в городке Иехуд недалеко от Тель-Авива. Центр был основан в 1996 году как лаборатория компании Mercury Interactive, вошедшей в состав HPE. Евгений Карасик, руководитель HPE Mobile Center, рассказывает об особенностях организации работы лаборатории, ее продуктах и стратегии развития, позволяющей работать на опережение потребностей рынка. С чего начиналась работа центра? Я поступил на работу в центр в 1998 году еще в бытность его исследовательской лабораторией компании Mercury Interactive. В то время там работало 60 человек, а сам городок Иехуд считался очень перспективным местом для хай-

тек-компании, и сегодня здесь работает уже около 1400 человек. В ноябре 2006 года Mercury Interactive вошла в состав HP и мы стали частью подразделения HP Software. Сегодня именно здесь создаются продукты HPE по управлению жизненным циклом приложений (Application Lifecycle Management, ALM). Имеется еще подразделение в Китае — нам надо приспосабливаться к азиатским рынкам и снижать себестоимость разработок. В Израиле рабочая сила в хай-тек-индустрии дешевле, чем в США, но дороже, чем в Китае. Разработчики из Поднебесной исправно делают свою работу, реализуя идеи, в основном приходящие из нашего офиса в Иехуде. В Израиле очень динамичный рынок труда — в стране неимоверное количество стартапов, жизнь кипит, и, чтобы соответствовать темпам, оставаясь адекватным игроком на рынке разработки ПО, каждые два-три года надо открывать новые проекты, чтобы люди могли продвигаться как по управленческому, так и по технологическому направлениям. Для поиска «свежих» кадров мы реализуем новые совместные программы, проводим встречи в вузах, стараемся привлекать людей со студенческой скамьи или отслуживших в армии. Инновационная культура в нашей компании поддерживается на уровне управления и на инженер-

ном уровне. В результате процент людей, которые уходят, несравнимо меньше, чем в Китае или Индии, примерно такой же, как в США или Западной Европе. Были ли попытки привлечения специалистов из России? У нас было несколько аутсорсинговых проектов с Россией — у российских программистов огромный потенциал, в стране имеются сильные команды разработчиков, а поскольку у нас самих треть сотрудников русскоговорящие, то работать было удобно. Но долгосрочное взаимодействие в масштабах нашей глобальной компании не сложилось — возникло много ограничений на корпоративном уровне. Тем не менее мы продолжаем рассматривать это направление с точки зрения интеграции с готовыми продуктами российского рынка. Технологические структуры в России ничуть не хуже аналогичных в мире, но структуры в таких странах, как Сингапур, Австралия или Саудовская Аравия, гораздо гибче и быстрей подхватывают новшества. А сами люди в России, к счастью, хотят что-то делать, и если им дадут себя проявить, то российские решения, безусловно, будут на мировом уровне. Желание учиться и делать что-то конкретное с новыми знаниями — отличительная особенность российского менталитета.

Инновации — основа успеха. Ведущие ИТ-игроки не могут существовать без специальных лабораторий, проводящих масштабные исследования в самых различных областях, см. например: ИТ для медицины будущего // Открытые системы.СУБД, № 05, 2014; О мэйнфреймах и не только // Открытые системы.СУБД, № 09, 2010; Лидер команды прагматиков // Открытые системы.СУБД, № 05, 2006.

38 • Открытые системы • 03/2016 • www.osmag.ru

мир Когда в центре появилось мобильное направление? Разработками для мобильного рынка мы начали заниматься давно, хотя собственно на мобильном тестировании специализируемся всего пару лет. Раньше мы ориентировались на создание платформ для разработчиков мобильных приложений, но на пике волны MDM (Mobile Device Management — «управление мобильными устройствами») и MAM (Mobile Application Management — «управление мобильными приложениями»), когда многие софтверные компании разрабатывали свои фреймворки для мобильного рынка, мы хотели создать нечто в духе SAP Fiori — платформы для портирования SAP-приложений на мобильные устройства. Но через некоторое время поняли, что наши основные клиенты не разработчики и для них приоритетная задача — именно управление жизненным циклом мобильного приложения. В то время мобильное тестирование для нас выполняла сторонняя компания. Мы решили, что займемся этим сами, и так появилось собственное решение HPE Mobile Center, развитием которого сегодня в лаборатории занимаются примерно 70 человек, включая сотрудников офиса в Шанхае. В чем особенности разработки мобильных приложений? Коли че с т во раз ли чны х моби льны х устройств сегодня колоссальное, тенденции на рынке меняются ежемесячно, и темпы здесь заметно выше, чем в других отраслях, — цикл разработки мобильного приложения от момента принятия решения о разработке до передачи приложения клиенту намного короче. Мы должны либо быстро приспосабливаться, либо действовать превентивно, и решение, которое мы предоставляем, должно быть адаптировано к таким темпам. Если многие разработчики начинают использовать платформу Cordova, мы начинаем разработки под нее, а когда Microsoft приобрела компанию Xamarin, то ускорили разработки для их технологии, чтобы поддержка приложений нашим Mobile Center началась как можно раньше. Уже сегодня, скажем, нам задают вопрос: а поддерживаете ли вы iOS 10? Да, мы поддерживаем эту ОС. Организационная структура лаборатории построена так, чтобы мы могли оперативно отвечать на все подобные вопросы. Только за последний год мы выпустили четыре основные версии HPE Mobile Center, и это достаточно высокий темп.

HPE Moblie Center

Решение HPE Mobile Center призвано объединить все процессы жизненного цикла мобильных приложений, включая тестирование и мониторинг их работы. Благодаря централизации использования мобильных устройств всех типов (физических и виртуальных, клиентских и облачных), а также интеграции с HPE ALM можно выполнять функциональное тестирование для приложений (UFT) на платформах iOS, Android и Windows, браузерах Chrome, Firefox и Internet Explorer, включая в процесс тестирования специалистов по бизнес-процессам и сотрудников, не являющихся профессионалами в ИТ. Возможны следующие виды тестирования: тестирование безопасности приложения до его развертывания, статический анализ кода и регулярно выполняемые динамичные проверки (HPE Fortify); интерактивное тестирование, особенно эффективное на ранних этапах проектирования (HPE Sprinter); непрерывное функциональное тестирование и обслуживание приложений, ориентированное на разработчиков и интегрированное в среды Microsoft Visual Studio и Eclipse (HPE LeanFT). Планирование, реализация и отслеживание выполнения проектов, построенных по принципам Agile, осуществляются с помощью HPE Agile Manager, а процесс планирования тестов, интегрированный с HPE LoadRunner и HPE StormRunner Load, осуществляется средствами HPE Performance Center. Нагрузочное тестирование, позволяющее оценить производительность всей системы, выявить и устранить проблемы приложений до пуска в работу, выполняется средствами HPE LoadRunner, а тестирование на устойчивость к экстремальным нагрузкам, позволяющее достичь нагрузки в сотни тысяч виртуальных пользователей, — с помощью инструментов HPE StormRunner Load. В системе имеются развитые средства синтетического мониторинга производительности и функционирования приложений со средствами аналитики, позволяющими отслеживать реакцию пользователей. Кроме того, существует встроенный интеллектуальный анализ отзывов пользователей, позволяющий обобщить реакцию типа «понравилось / не понравилось» (HPE AppPulse Active, HPE AppPulse Mobile, Sentiment Analysis).

Следует заметить, что у нас нет «наследия» работы в других, более консервативных отраслях, поэтому мы используем самые современные методы agile-разработки: наш цикл — всего две недели. Если работать локально, в закрытом пространстве, то можно было бы укладываться и в неделю, это естественный человеческий ритм, однако мы работаем между Израилем и Китаем, не работаем в пятницу и субботу, а они работают, как весь мир, поэтому в неделе остается четыре дня, чего слишком мало. Начинали мы с месяца, еще раньше — с двух, а за год сократили цикл до двух недель. Какие инструменты вы используете для организации работы? Для разработки мы применяем HPE Agile Manager (AGM), а ALM используем для связи со службой поддержки. Производительность тестируем с помощью HPE StormRunner, а функциональное тестирование у нас организовано на продуктах UFT и LeanFT — соответствующих модулях, входящих в решение HPE ALM. Разработчики ALM сидят этажом ниже, и нам проще решать возникающие вопросы. Кроме этого, у нас много скриптов, работающих в открытом фреймворке Appium, предназначенном для автоматизации тестирования мобильных приложений, и теперь он бесшовно интегрируется в HPE Mobile Center. Вообще говоря, никто не

дает центру указаний насчет того, какое ПО использовать, — нам предоставлена свобода выбора инструментария, но он должен быть аргументирован. Поскольку проект HPE Mobile Center находится на стадии стремительного развития, внутри HPE мы образуем некоторую экосистему — нам нужно, чтобы менеджеры по продажам и предпродажной подготовке и служба поддержки были такими, какие требуются для мира мобильных приложений, поэтому мы взяли на себя и образовательные функции, и связь с клиентом, и взаимодействие со службой поддержки, то есть функции, которые выходят за рамки стандартного НИОКР. В HPE структура поддержки совсем другая, она основывается на своих KPI, и специализированной поддержки для мобильных пользователей нет. Центр только разрабатывает ПО или предоставляет ус луги по тестированию? Мы занимаемся только разработкой, однако предоставляем сервис профессионального тестирования через подразделение HPE Professional Services либо через партнеров. У нас имеются стратегические альянсы с Sogeti, Capgemini и рядом других (всего около десятка компаний), которые приобретают у нас ПО и предоставляют сервисы клиентам. Наши клиенты — в основном клиенты HPE, и мы обычно обслуживаем

www.osmag.ru • 03/2016 • Открытые системы • 39

мир корпоративных клиентов в таких специфических областях бизнеса, как, например, банки. Однако мы не ограничиваемся только корпоративными заказчиками: имеющаяся техническая база лаборатории позволяет организовать поддержку практически всех задач. Все крупные компании пришли к выводу о необходимости мобильных приложений как для внешнего, так и для внутреннего использования. У больших компаний, например из автомобилестроительной отрасли, много приложений для своих клиентов, но гораздо больше приложений для внутреннего использования — широко поддерживается концепция BYOD. Устройства для решения корпоративных задач нужно тщательно тестировать. У нас официально зафиксировано 250 активных клиентов, и есть тенденция к росту их числа — например, за счет операторов связи, для которых очень важна тема мобильных приложений. Для них сейчас главное — контент: облака музыки и фильмов, которые существенно повышают трафик, а значит, и прибыли. Наши средства эмуляции устройств и сетей им просто необходимы. Например, один из местных провайдеров сотовой связи до недавнего времени не был клиентом HPE, но, как только разработка мобильного контента стала приоритетным направлением развития компании, они стандартизировали процесс выпуска мобильных приложений на основе HPE Mobile Center. Среди наших клиентов есть и ведущие российские операторы сотовой связи. Работа с мобильными устройствами тесно связана с виртуализацией... Мы сами не занимаемся виртуализацией устройств — имеются публично доступные специализированные инструменты, и мы с ними интегрируемся, учитывая, что у нас открытые протоколы. С виртуализацией сетей история немного другая: мы 15 лет работали с компанией Shunra Software, которая занималась эмуляцией сетей для нагрузочного тестирования, и у нас с ними были совместные проекты. В результате HPE решила их приобрести, после чего они перепрофилировались на мобильные сети, что оказалось весьма актуально — эмулировать придется немало, ведь только появились сети 4G, а уже на горизонте 5G. Но нельзя же протестировать все... Безусловно, протестировать все модели устройств невозможно, однако не так уж много популярных платформ, на которых

разрабатываются приложения: PhoneGap, Adobe AIR, Xamarin и Cordova, — позволяющих абстрагироваться от аппаратных деталей конкретной модели, а поскольку мы сами занимались когда-то разработкой мобильных приложений, нам многое известно о платформах. Другой вопрос — покрытие тестирования, однако он больше относится к аналитике оценки поведения пользователей приложений, чем к техническим вопросам. Кстати, аналитика сейчас — один из наших приоритетов, и здесь мы выходим на технологии Больших Данных. Сегодня в смартфоне 80–100 приложений, генерирующих огромные массивы данных, очень важных, например, для обратной связи, так называемой OpsDev — тех, кто поддерживает эксплуатацию (Operations) приложений, и разработчиков (Development). В области эксплуатации накопились огромные залежи сведений о реальных пользователях и об их насущных проблемах, однако они разрозненны и не структурированы. Если мы сумеем эти данные автоматически проанализировать, то сможем, передав их разработчикам и тестировщикам в виде знаний, замкнуть кольцо DevOpsDev. Работа и тех и других тогда станет более эффективной. Анализ Больших Данных — это другая область технологии... Да, мы сознательно вторгаемся в другую область. В связке OpsDev проблема не столько техническая, сколько организационная — исторически имеется «стена», отделяющая разработчиков от эксплуатационщиков. Обе эти группы сотрудников до сегодняшнего дня решали разные задачи с точки зрения бизнеса. Но если мы принесем им готовое решение с результатами обработки, завязанными на решение объективных задач бизнеса, а не просто данные со словами «вот вам 5 Тбайт данных, обрабатывайте», тогда будет гораздо проще наладить коммуникацию OpsDevOps. Это не тактическая, а стратегическая задача. Мы будем концентрироваться на тех фронтах, которые важны для мобильного рынка. Цикл OpsDevOps актуален именно для рынка мобильных приложений — он здесь намного короче, и связь между «Operations» и «Development» эффективней, чем в других индустриях. Разумеется, тут не обойтись без технологий искусственного интеллекта. У компании, например, есть сервис HPE IDOL OnDemand, использующий методы машинного обучения, который позволяет обрабатывать тексты на естественном

40 • Открытые системы • 03/2016 • www.osmag.ru

языке, применяя также методы работы с Большими Данными. Допустим, есть приложения, которые пишут логи, но они не анализируются автоматически, а мы можем их анализировать. На текущий момент этот сервис адаптирован для информации, которая находится в виртуальных магазинах мобильных приложений: мы анализируем мнения пользователей, что им нравится, а что нет (sentiment analysis, входящий в Mobile Center 2.0), но эта технология не привязана к мобильности, и мы можем применить ее в других областях. Сегодня этот сервис востребован на уровне понимания, а не как критическая необходимость для ведения бизнеса, как, например, использование продуктов HPE UFT и LeanFT для проведения ручного и автоматического тестирования. Но все стремительно меняется. Главное, что аналитика, и именно предсказательная аналитика, позволяет не только находить проблемы, но и предвидеть их. Предсказательная аналитика — одна из двух главных стратегических задач лаборатории. Какая вторая? Интернет вещей. Технически это прежде всего эмуляция сенсоров, которых сегодня производится столько видов, что физически протестировать все их просто невозможно. А мы можем смоделировать сенсоры, приспосабливая для этого те технологии, которые у нас уже есть: виртуализацию мобильных устройств и виртуализацию сетей. Поэтому следующий этап развития лаборатории — создание парка физических и виртуальных сенсоров. Используя соответствующие протоколы, мы сможем дать производителю возможность строить «умные дома» и прочие «умные» системы, не тестируя бесконечные матрицы всех возможных вариантов физических устройств. То, что Интернет вещей станет следующим технологическим витком, понимают все, но не все знают, что с этим делать. Например, в современном автомобиле несколько тысяч различных сенсоров, и их необходимо эффективно протестировать, однако не очень понятно, как это сделать. Наши клиенты уже обсуждают это с нами, что вполне естественно. Виртуализация сенсоров для Интернета вещей и предсказательная аналитика — два наших наиболее «горячих» направления, и скоро мы представим первые результаты.  Игорь Левшин (ilevshin@yandex.ru) — независимый автор (Москва).

мир

«Чудеса» Льва Королева Машинный перевод, система ПРО и первая мультипрограммная ОС — эти и другие «чудеса», воплощенные в реальность Львом Николаевичем Королевым, которому 6 сентября 2016 года должно было бы исполниться 90 лет, заложили более полувека назад основы технологической независимости страны. Ключевые слова: БЭСМ, ИТМиВТ, музей ОС Keywords: BESM, IPMCE, OS Museum

Руслан Смелянский

ся жизнь Льва Николаевича Королева была связана с развитием вычислительной техники и программирования — уже сам выбор профессии, связанной с опальной тогда кибернетикой, перспективы которой в конце 1940-х были весьма туманны, выпускником мехмата, окончившим с отличием МГУ, выглядел своего рода чудачеством (от слова «чудо»). Первым «чудом» Королева, принесшим ему международную известность, были работы совместно со Спартаком Николаевичем Разумовским и Александром Николаевичем Томилиным (1956 год) по созданию программ автоматического перевода с английского языка на русский для БЭСМ-1. Королев разработал методы и программы поиска по словарю — центральное звено комплекса перевода, а в 1960 году защитил кандидатскую диссертацию по вопросам теории машинного словаря. Томилин разрабатывал программы для сжатия двоичного кода программ автоматического перевода с английского языка на русский, чтобы уменьшить время их считывания с магнитной ленты в оперативную память машины БЭСМ-1. Малый объем оперативной памяти этой машины — 2048 39-разрядных слов — вынуждал сменять в памяти одну за другой программы комплекса, считывая их с магнитной ленты, что существенно замедляло перевод каждой фразы текста. Примерно в это же время Королевым был предложен оригинальный алгоритм символьного дифференцирования, положивший начало отечественной школы компьютерной алгебры. Следующим «чудом», определившим всю биографию Королева, стал проект ПРО Системы «А» — комплекса стратегической противоракетной обороны, который был развернут в 1955—1960 годах на специально построенном полигоне Сары-Шаган в Голодной степи. Этот системный проект значительно опередил свое время по техни-

ческим новациям и сыграл решающую роль в развитии противоракетных систем СССР. В СССР первые исследования возможности создания ПРО проводились в 1945– 1949 годах в рамках проекта «Анти-Фау»: в Академии им. Н. Е. Жуковского был разработан проект противоракетной обороны района, состоящей из РЛС дальнего обнаружения, РЛС ближнего сопровождения цели, счетно-решающего прибора и противоракеты с системой самонаведения и управляемой боевой частью. В НИИ-20 Наркомата вооружений для целей ПРО разрабатывался эскизный проект мощной РЛС «Плутон» с дальностью более 1000 км. Однако тогда проект не получил практического продолжения. Боевые возможности баллистических ракет на тот момент не представляли непосредственной угрозы — они не могли нести ядерный заряд и имели слишком низкую точность. Задача создания эффективной ПРО оказалась слишком сложной для техники того времени, не было фундаментальных исследований и надежных экспериментальных данных, которые можно было бы применить в работе. Однако после начала разработки в США баллистических ракет «Тор» и «Юпитер» дальностью 2800 км и с боеголовками мощностью 1,0–1,5 Мт, размещение которых на базах в Турции, Италии и Англии позволяло бы держать под прицелом европейскую часть СССР, ситуация изменилась. В августе 1953 года в ЦК КПСС поступило официальное обращение высшего военного руководства СССР, так называемое письмо семи маршалов, которое обсуждалось на научно-техническом совете Третьего главного управления при Совете Министров СССР (НТС Главспецмаша). Несмотря на скепсис ряда известных ученых того времени («это такая же глупость, как стрельба снарядом по снаряду», «неимоверная чушь, глупая фантазия предлагается маршалами, это просто неразрешимые ребусы и только» и т. п.), тему ПРО поддержал руководитель радио-

технического отдела № 31 КБ-1 полковник Григорий Васильевич Кисунько [1], который высказал уверенность в возможности создания уже в ближайшее время комплексов, способных обнаруживать, сопровождать и поражать баллистические ракеты. В результате 17 августа 1956 года вышло постановление Совета Министров СССР, определившее состав кооперации разработчиков системы ПРО: головной разработчик — КБ-1 (СКБ-30, Г. В. Кисунько); противоракета — МКБ «Факел» (П. Д. Грушин); РЛС дальнего обнаружения — НИИДАР (В. И. Марков); ЭВМ — ИТМ и ВТ (С. А. Лебедев); связь и передача данных — ЦНИИС (С. А. Аджемов), МНИРТИ (Ф. П. Липсман). Для координации работ при Четвертом главном управлении Министерства обороны было организовано специальное управление (М. Г. Мымрин, М. И. Ненашев), а для изготовления и монтажа технических средств были созданы новые производственные мощности. Новизной Системы «А» стала полная цифровизация: впервые в мире в качестве управляющей была применена не аналоговая, а цифровая ЭВМ, которая ранее применялась исключительно для ускорения расчетов. Преимуществом такого решения стала возможность реализации сложного алгоритма работы с минимальным вовлечением человека. Перед началом перехвата включалась РЛС дальнего обнаружения «Дунай-2» и на ЭВМ М-40, расположенной в ГКВП (Главный командный вычислительный пункт), в режиме ожидания запускалась общая боевая программа (ОБП), которая представляла собой пакет из десятка подпрограмм, решающих все задачи по управлению элементами Системы «А» и объединенных общим боевым алгоритмом: целеуказание, расчет времени и точки встречи противоракеты с целью, вывод противоракеты в точку встречи и др. Как только «Дунай-2» на дистанции 1000–1500 км обнаруживала цель, ЭВМ получала ее предварительные координаты и рассчитывала углы установки

www.osmag.ru • 03/2016 • Открытые системы • 41

мир

Г. В. Кисунько

С. А. Лебедев

В. С. Бурцев

Л. Н. Королев

Руководители проекта Система «А» узконаправленных антенн трех радиолокаторов точного наведения (РТН), а далее выполняла все операции в режиме реального времени. На дистанции около 700 км РТН обнаруживали цель, операторы по радиолокационным образам выделяли из комплексной цели (боеголовка, корпус ракеты, осколки) боеголовку и захватывали ее на автосопровождение. Три разнесенные на местности РТН определяли расстояние до цели, а ЭВМ по этим данным рассчитывала траекторию движения боеголовки. Далее ОБП проводила пролонгацию траектории цели, определяла ее точку падения, рассчитывала траекторию вывода противоракеты, разворачивала пусковую установку в нужном направлении и в нужный момент выдавала команду на ее пуск. После пуска противоракета первоначально захватывалась на автосопровождение станцией визирования противоракеты (РСВП), которая располагалась на стартовой позиции. По ее данным рассчитывались углы установки антенн радиолокаторов сопровождения противоракеты, которые располагались на площадках рядом с РТН и управляли противоракетой по принципу «трех дальностей». После того, как начиналось сопровождение радиолокаторами противоракеты на РТН и выводилась противоракета В-1000 на пролонгированную траекторию цели на встречных курсах, запускался режим точного наведения, который длился 12–14 секунд. ЭВМ рассчитывала момент и выдавала команду на подрыв боевой части. На пути цели создавалось дискообразное облако осколков, движущееся навстречу цели со скоростью противоракеты (около 1,5 км/с). Атакующая боеголовка, пролетая через облако осколков, получала повреждения и разрушалась. Управление объектами, разнесенными на десятки и даже сотни километров, надо было передать ОБП на ЭВМ М-40, которая в автоматическом режиме управляла всеми объектами и решала задачу перехвата, причем промах в точке встречи не должен

превышать 20 метров. Над созданием этой системы трудились десятки передовых научных и производственных коллективов страны. Антиракетой В-1000 Cистемы «А» 4 марта 1961 года впервые в мире был осуществлен перехват боеголовки баллистической ракеты средней дальности Р-12. Создание ОБП было поручено ИТМиВТ АН СССР, и первые элементы программы отрабатывались на БЭСМ-1 с использованием программы — имитатора команд М-40 [2]. В этой задаче трудно переоценить роль всего коллектива ИТМиВТ, выполнившего разработку управляющей машины М-40, ее изготовление на заводе ЗЭМЗ, разработку общей структуры программы управления, оснащение машины программами элементарных функций и работы с полиномами. Следует подчеркнуть, что это середина 1950-х годов, младенческий возраст машинной математики и программирования. Ясно, что величина ответственности заместителя главного конструктора по программному обеспечению Льва Королева за реализацию программы управления даже трудно осознавалась, и позднее он признавался, что только молодость и масштабность проекта отодвигали на второй план все сомнения и опасения. Возглавляемая им Лаборатория 5 ИТМиВТ, которую он называл «прислуга за все», включала три подлаборатории: подлаборатория для разработки программного обеспечения для машин, создававшихся в Лаборатории № 1 ИТМиВТ, — БЭСМ-6 и позже АС-6 (руководитель В. А. Мельников); подлаборатория (руководитель Б. А. Бабаян) для разработки программного обеспечения машин, создававшихся в Лаборатории № 2 ИТМиВТ (руководитель В. С. Бурцев); подлаборатория (руководитель Г. Г. Рябов) для создания систем автоматизации проектирования ЭВМ. Для проведения различных испытаний ОБП непрерывно модернизировалась: первоначальный вариант программы состоял из 10 тыс. команд, а через два года программа содержала уже 40 тыс. ко-

42 • Открытые системы • 03/2016 • www.osmag.ru

манд, для нее был также разработан комплекс вспомогательных программ функционального контроля системы и ее средств. В команде Королева были выпускники мехмата МГУ и МФТИ. Полигонная часть команды, на которую легла львиная доля работы по отладке программы с реальными объектами и боевыми пусками, в разные периоды насчитывала 7–12 человек вместе с прикомандированными выпускниками военных вузов. Какую черту Королева как руководителя следует подчеркнуть? Полнейшее доверие к членам команды и оптимизм в достижении поставленной цели. Но жизнь на полигоне — это не только машинный зал М-40 и окружающие помещения в здании 40-й площадки (официальной вычислительной станции и командного пункта Системы «А»). Распорядок типичного рабочего дня: подъем в 6:30, подача к месту проживания (25-метровому бараку) крытого грузовика в 7:00 и отъезд в гарнизонную столовую на завтрак, затем на том же грузовике на 40-ю площадку (примерно 10 км), далее — работа до двух часов, затем на обед опять на грузовике и обратно на площадку, работа до 21:00 или с продолжением на ночную смену. И это на фоне суровых морозов и ветров зимой и изнурительной жары в летние месяцы. Однако все это тогда не казалось утомительным — настолько захватывающей была задача. Среди участников проекта Системы «А» следует отметить Юрия Михайловича Барабошкина, Андрея Михайловича Степанова, Евгения Алексеевича Волкова, Геннадия Георгиевича Рябова и Владимира Ивановича Рыжова [3]. Отладка программы одновременно с испытаниями физических изделий чревата многими неожиданностями и неудачами. Рябов вспоминает следующее: «На одном из этапов отработки системы в так называемом режиме ЗТПР (заданная траектория противоракеты) произошло ЧП, о котором мы узнали лишь через несколько часов, хотя по приборам все было в норме и отклоне-

мир ния от заданной траектории не выходили за пределы допустимого. Работа по подготовке и самому пуску длилась несколько часов, с большими задержками по готовности объектов и линий связи (с раннего утра до вечера). Поэтому после экспрессанализа результатов работы по данным контрольно-регистрирующей аппаратуры практически все представители войсковой части покинули территорию 40-й площадки. В машинном зале осталось несколько человек из ИТМиВТ во главе с Королевым. Нам надо было еще раз “прокрутить” магнитные записи данных пуска для еще одной проверки. Прошло около двух часов, и вдруг отворяется дверь и в машинном зале появляется величественная фигура первого секретаря ЦК компартии Казахстана Динмухамеда Кунаева. Мы сразу поняли, что это связано с пуском, — оказалось, что изделие улетело слишком далеко, хотя по дальности должна была сработать самоликвидация, но она не сработала. Хорошо, что это не привело к ущербу. Но никакого разноса не было — гость стал интересоваться контролем в процессе пусков и с интересом прослушал краткую лекцию Королева. Было видно, что это общение произвело на Кунаева большое впечатление. Ну а после этого, помимо автоматической самоликвидации по дальности, в программу был внесен блок контроля выхода траектории изделия за пределы заданного конуса с выдачей в этом случае команды принудительного подрыва изделия» [3]. В качестве заместителя главного конструктора Королев принимал активное участие в разработке архитектуры и программного обеспечения ЭВМ БЭСМ-6, и большое место в этих работах занимало моделирование — отработка на моделях конструкторских решений. Вот как Томилин вспоминает события того времени: «Сергей Алексеевич Лебедев, главный конструктор БЭСМ-6, не ограничивался только постановкой задач по моделированию — он написал программу моделирования работы проектируемой машины, используя методы теории массового обслуживания. Получалось так, что ночью, когда машинного времени давали больше, я пускал на ЭВМ БЭСМ-2 в ВЦ Академии наук СССР свою “натурную” (потактную) программу моделирования работы проектируемой машины и программу Сергея Алексеевича моделирования работы той же структуры. Затем после краткого сна мы днем сравнивали полученные результаты. Все знали про программистскую деятельность Сергея Алексеевича, а Королев все время спрашивал: “Сергей Алексеевич, когда же вы сделаете ошибку в программе?”

На что Лебедев отвечал: “Это вы, программисты, делаете ошибки, а потом до ушей радуетесь, что их находите, а я пишу программы тщательно, и ошибок не будет”. Лев Николаевич заметил: “Сергей Алексеевич, этого не может быть, потому что не может быть никогда”. И наконец, это случилось — Лебедев сделал ошибку! На программе с подготовленными им исправлениями он написал ставшую потом знаменитой фразу “Лев Николаевич оказался прав. Программ без ошибок не бывает”»[3]. Следующее «чудо» случилось с Королевым в 1967 Записка С. А. Лебедева, направленная А. Н. Томилину во врегоду: под его руко- мя разработки программной модели БЭСМ-6 водством в ИТМиВТ была создана первая мультипрограммная Лев Николаевич Королев, держава, для коОС для БЭСМ-6 — «Диспетчер-68», в кото- торой вообще не стояла проблема достирой была реализована поддержка множе- жения технологической независимости, ства передовых на тот момент решений: вынуждена сегодня заниматься импортомультипрограммный режим решения за- замещением.  дач, страничная организация памяти с динамическим распределением, совмещение Литература вычислений во всех задачах с параллельной 1. Вера Карпова, Леонид Карпов. СуперЭВМ — работой внешних запоминающих устройств от задач к машине // Открытые системы. СУБД. — 2010. — № 04. — С. 58–62. URL: и устройств ввода-вывода. Программа «Диспетчер-68» стала предте- http://www.osp.ru/os/2010/04/13002418 чей многих будущих операционных сред для (дата обращения: 18.09.2016). отечественных ЭВМ и основой для ряда опе- 2. Тамара Бурцева, Леонид Карпов, Вера рационных систем БЭСМ-6 — ОС «Дубна» и Карпова. Всеволод Бурцев и суперЭВМ // ОС «Диспак», а также операционной системы Открытые системы.СУБД. — 2007. — реального времени ОС НД-70 («Новый дис- № 09. — С. 70–73. URL: http://www.osp. петчер-70» Виктора Петровича Иванникова), ru/os/2007/09/4570045 (дата обращения: имеющей развитые средства организации 18.09.2016). параллельных вычислений и обеспечения 3. Лев Николаевич Королев: Биография, работы БЭСМ-6 в составе многомашинно- воспоминания, документы // Сост. и ред. го комплекса. Вместе с Королевым лауреа- Власов В.К., Смелянский Р.Л., Томилин тами Государственной премии СССР за ра- А.Н. — М.: МАКС Пресс, 2016. — 272 с. [8 с. боты по БЭСМ-6 стали С. А. Лебедев, В. А. вкл.] ISBN 978-5-317-05. Мельников, А. А. Соколов, В. И. Смирнов, М. В. Тяпкин, В. Н. Лаут, Л. А. Зак, А. Н. Томилин, Руслан Смелянский (smel@cs.msu.su) — профессор МГУ, директор Центра приВ. Я. Семешкин и В. А. Иванов [3]. кладных исследований компьютер*** Подобных «чудес» было много в истории ных сетей (Москва). Автор благодарит нашей страны, и весьма прискорбно, что А. Н. Томилина и В. К. Власова за помощь некогда богатая на таких специалистов, как в подготовке статьи.

www.osmag.ru • 03/2016 • Открытые системы • 43

ИТ-университеты

ИСТИНА в науке и образовании Сегодня в Интернете доступны разнообразные данные о деятельности научных и образовательных организаций, представляющие интерес для подготовки и принятия управленческих решений. Однако все они, как правило, хранятся в базах с разной структурой, и для их обработки требуются системы, способные интегрировать сведения из различных источников. Одна из таких систем — система «ИСТИНА». Ключевые слова: интеграция информационных ресурсов, информационно-аналитическая система Keywords: information-analytical system, integration of information resources

Валерий Васенин, Сергей Афонин, Александр Козицын

адачи сбора, систематизации, хранения и обработки больших объемов данных с целью их использования для подготовки и принятия управленческих решений стояли перед организациями всегда. Сначала их решали с помощью информационных каталогов, затем появились базы данных и системы управления ими, прошедшие большой путь от иерархических и сетевых до реляционных и NoSQL. Однако большинство этих СУБД работают с логически связанными данными, концептуальная структура которых заранее определена и однородна. Вместе с тем в Интернете стали доступны очень большие объемы неструктурированных (аудио и видео), слабоструктурированных (тексты), а также структурированных данных, которые хранятся в базах с разными структурами. Однако возможности работы с ними только в рамках традиционной реляционной парадигмы уже не удовлетворяют современным потребностям. Во многих организациях — вузах, научно-производственных центрах, исследовательских лабораториях и т. п., а также в региональных и федеральных органах управления — востребованы информационно-аналитические системы подготовки принятия решений, действующие на основе анализа данных научно-инновационного и образовательного содержания. Такие системы должны позволять проводить оперативный анализ надежно верифицируемых персональных данных и обобщенных данных по отдельным научным

коллективам и организациям, а также данных по регионам и по России в целом для повышения объективности оценки показателей результативности или тенденций научно-педагогической деятельности. Для этого система должна предоставлять максимально точные (очищенные и верифицируемые) данные о научно-педагогической деятельности участвующих в ней персон: данные в системе должны включать сведения как библиографического, так и аннотационного характера, в том числе ссылки на другие источники. Созданная в МГУ информационно-аналитическая система, построенная на основе моделей, механизмов и инструментальных средств Интеллектуальной системы тематического исследования наукометрической информации (ИСТИНА) [1, 2], позволяет собирать данные о научной и педагогической деятельности сотрудников и верифицировать ее с учетом сведений из внешних источников (например, Web of Science и Scopus) [3]. Она помогает в работе диссертационных советов, позволяя рассчитывать рейтинги сотрудников, а также дает возможность автоматизировать проведение конкурсов на замещение вакантных должностей и получение грантов, готовить отчетные формы как по отдельным персонам, так и по организации в целом. В ядре системы (см. рисунок) реализуется поддержка единого интерфейса, средств просмотра, редактирования и удаления результатов научно-педагогической деятельности сотрудников, а также поиск похожих объектов — проводимый, в частности, для подбора сотрудников, журналов и статей. Важной частью ядра является механизм кэширования, используемый для

44 • Открытые системы • 03/2016 • www.osmag.ru

ускорения доступа к различным данным. Кроме того, ядро поддерживает функции общего назначения, такие как обеспечение безопасности и разграничение доступа к данным. Взаимодействие пользователей с сервером приложений осуществляется через веб-интерфейс. Приложения в системе разрабатываются с помощью инструментария Django, написанного на языке Python. Для хранения данных используется СУБД Oracle. Базовыми приложениями системы являются модуль организаций и модуль сотрудников. Первый включает классы и логику действий, связанную с данными на уровне организаций, — в частности, механизм управления информацией о сотрудниках, которым делегирована роль ответственных за сбор сведений о работе организации и ее отдельных подразделений. Второй модуль содержит базовые классы, относящиеся к сотрудникам, — например, их профиль и список опубликованных работ. Оба модуля связаны со всеми остальными приложениями, каждое из которых одновременно является и приложением в терминологии Django. Каждое приложение отвечает за отдельный тип научной и преподавательской деятельности сотрудников (например, публикации) или за общую сущность, связанную с таким типом (например, журналы). Это позволяет сравнительно легко добавлять в систему новые типы результатов деятельности персон. Такие функциональные возможности, как добавление, просмотр, редактирование и удаление, а также привязка результата деятельности к сотрудникам-авторам, реализованы в ядре — программисту требуется лишь настроить

ИТ-университеты HTTP-сервер

Рейтинги

Конструктор формул

СУБД

систему на конкретный тип результатов деятельности. Например, описав методы определения авторства в родительском классе, можно использовать их для любых дочерних объектов: книг, патентов, тезисов и курсов. Наиболее сложным является приложение по поиску публикаций — ему требуется производить разбор библиографических ссылок в текстовом формате. Для осуществления такого разбора был выбран модуль с открытым исходным кодом Freecite [3], который был усовершенствован с целью предоставления возможности обработки текстов на русском языке. Основным преимуществом Freecite является наличие встроенных алгоритмов машинного обучения и функций автоматической настройки на новые форматы данных. Модуль статистики содержит функции количественного анализа данных на уровне организации, подразделения и отдельного сотрудника. В нем реализован простой тематический анализ результативности сотрудников — например, получение и обработка показателей цитирования отдельных статей из Web of Science, Scopus, а также поиск статей в этих системах. Кроме того, в модуль входят механизмы расчета принятых в организации коэффициентов оценки эффективности деятельности сотрудников, которые в дальнейшем могут использоваться, например, при расчете поощрительных надбавок. Для глубокого тематического анализа данных, проводимого с использованием моделей предметных областей, построенных автоматически на основе анонсов научных конференций, а также результатов запросов к поисковым системам, таким как Bing, применяется приложение «Онтологии». Модели содержат характерные для конкретной предметной области термины, по которым выполняется классификация результатов деятельности сотрудников, а также производится подбор похожих объектов для удобной навигации по системе. Одно из главных требований к таким системам, как ИСТИНА, — удобный интерфейс конечного пользователя и механизмы верификации данных, учитывающие тот факт, что только сами ученые могут точно описать и сверить с оригиналом, если это необходимо, свои научные результаты. Это не исключает возможности использования данных, которые могут быть экспортированы и из других источников с последующей их верификацией. Наличие большого массива данных и возможности их разноплановой обработки требует эффективной процедуры оценки

Активный кэш

Ядро системы

Организации

Внешние источники (WoS, Scopus)

Сотрудники Конструктор отчетных форм

Результаты деятельности

Архитектура системы достоверности представленных данных, а также механизмов разграничения доступа к сведениям разного уровня конфиденциальности. Научно-инновационная и педагогическая деятельность ученых сегодня характеризуется более чем 20 параметрами, к которым относятся наличие публикаций, патентов и свидетельств на интеллектуальный продукт, проведение курсов лекций и семинаров, руководство дипломными работами и диссертациями и т. п. Другое важное качество системы — открытость информации. Все сведения о научной работе сотрудника доступны, что способствует повышению их достоверности [4]. Для оценки результативности деятельности научных работников предусмотрен «Конструктор формул расчета эффективности работы сотрудника», позволяющий учитывать все виды работ и активностей работника с учетом специфики того или иного подразделения (факультета, института, центра). Подготовленная с помощью такого конструктора формула может использоваться для построения таблицы с указанием для всех сотрудников полученного числа баллов за каждую работу. В системе «ИСТИНА» имеются данные о 14 тыс. ученых, преподавателей и аспирантов из МГУ, МПГУ, ИПМ РАН, РГГУ и Научного центра неврологии. На базе системы только в МГУ за три недели было проведено три конкурса по определению ученых и преподавателей, внесших наиболее весомый вклад в работу университета, хотя обычно на проведение таких конкурсов раньше уходило до полугода. Кроме того, на основе системы разработан и запущен в эксплуатацию сайт диссертационных советов, который аккумулирует всю необходимую информацию и обеспечивает сопровождение процедур, регламентируемых соответствующими нормативными положениями. Годовая отчетная кампания по научно-исследовательской работе в МГУ уже два года проводится на основе анализа данных из системы «ИСТИНА», а в бли-

жайшее время будет завершен переход на новые принципы конкурсного избрания на научные и преподавательские должности. *** Система «ИСТИНА» отличается от применяемых научной общественностью аналогов, таких как Web of Science, Scopus и Elibrary, которые ориентированы на узкую область сбора информации и аккумулируют только данные о публикациях. В некоторых системах, например, в СНИД СПбГУ (ias.spbu.ru), дополнительно собираются данные о проектах, однако система «ИСТИНА» накапливает данные практически о всех видах научной и педагогической деятельности сотрудников. 

Литература 1. Интеллектуальная система тематичес-

кого исследования научно-технической информации (ИСТИНА) / С.А. Афонин и др. Под ред. академика В. А. Садовничего. — М.: Издательство Московского университета, 2014. — 262 с. 2. Васенин В. А., Афонин С. А., Козицын А. С., Голомазов Д. Д. Система «ИСТИНА» для подготовки принятия решений на основе анализа наукометрической информации // Научный сервис в сети Интернет: Труды XVII Всероссийской научной конференции, С. 51–62. ИПМ им. М. В. Келдыша. М., 2015. 3. Васенин В. А., Голомазов Д. Д., Ганкин Г. М. Архитектура, методы и средства базовой составляющей системы управления научной информацией «ИСТИНА — Наука МГУ» // Программная инженерия. — 2014. — № 9. — С. 3–12. 4. Сергей Паринов. На пути к Открытой Науке // Открытые системы. СУБД. — 2016. — № 1. — С. 44–45. URL: http://www. osp.ru/os/2016/01/13048658 (дата обращения: 18.08.2016). Валерий Васенин (vasenin@msu.ru), Сергей Афонин (serg@msu.ru), Александр Козицын (alexanderkz@mail.ru) — сотрудники, НИИ механики МГУ им. М. В. Ломоносова (Москва).

www.osmag.ru • 03/2016 • Открытые системы • 45

библиотека

ИТ для спасателей, кибербезопасность и будущее пользовательских интерфейсов Темы майского, июньского и июльского номеров журнала Computer (IEEE Computer Society, Vol. 49, No. 5, 6, 7 2016) — применение ИТ в работе аварийно-спасательных служб, проблемы информационной безопасности в эпоху Третьей платформы и новые горизонты проектирования пользовательских интерфейсов. Ключевые слова: дизайн интерфейсов, интеллектуальные интерфейсы, информационная безопасность, чрезвычайная ситуация, Keywords: emergency, information security, intelligent interfaces, security

Александр Тыренко

айский выпуск журнала Computer посвящен применению ИТ для повышения эффективности реагирования на чрезвычайные ситуации. Бедствие может разразиться за считанные мгновения — природная или техногенная катастрофа, случайная или спровоцированная, локальная или охватывающая большую территорию. В работе аварийноспасательных служб можно задействовать широкий круг ИТ-решений, обеспечивающих интеграцию данных, аутентификацию и приватность, а также обработку естественного языка, визуализацию и прогнозное моделирование. В условиях хаоса ИТ помогают обеспечить своевременный сбор, анализ и распространение надежной информации. В статье «Информатика экстренных ситуаций: оптимизация действий в условиях чрезвычайных ситуаций» (Emergency Informatics: Using Computing to Improve Disaster Management) Робин Мерфи (Robin Murphy) описывает использование ИТ в контексте наводнения, произошедшего в Техасе 24–26 мая 2015 года. Объем данных, генерируемых в ходе бедствий подобных масштабов, колоссален, при-

чем информация, собранная из социальных СМИ, ненадежна, а одни ведомства не всегда знают о том, какие сведения есть у других, к тому же данные могут быстро устаревать. Все это делает необходимыми исследования в области фильтрации данных, обработки изображений, когнитивных вычислений, планирования и резервирования ресурсов. Авторами статьи «Оперативный анализ для приоритизации спасательных операций» (Impromptu Crisis Mapping to Prioritize Emergency Response) являются Марко Аввенути (Marco Avvenuti), Стефано Кресци (Stefano Cresci), Фабио дель Винья (Fabio Del Vigna) и Маурицио Тескони (Maurizio Tesconi). Они рассматривают задачу извлечения полезной спасателям контекстной информации из социальных сетей. Поскольку в сообщениях социальных СМИ редко указываются точные географические координаты, для составления отчетов об ущербе и пропавших без вести предлагается метод «геопарсинга» — анализа упоминаний известных мест. Авторы описывают систему, способную быстро идентифицировать и отмечать на карте регионы, пострадавшие сильнее всего. В публикации «Живая распределенная сенсорная сеть для поисково-спаса-

46 • Открытые системы • 03/2016 • www.osmag.ru

тельных операций» (A Biobotic Distributed Sensor Network for Under-Rubble Search and Rescue) Алпер Бозкурт (Alper Bozkurt), Эдгар Лобатон (Edgar Lobaton) и Михаил Сикитиу (Mihail Sichitiu) описывают гибкую систему обнаружения выживших людей и идентификации опасных мест под разрушенными зданиями. В качестве узлов беспроводной сети предлагается использовать тараканов, оснащенных соответствующей аппаратурой. Статью «Использование социальных сетей и краудсорсинга для содействия в ликвидации чрезвычайных ситуаций» (Applications of Social Networks and Crowdsourcing for Disaster Management Improvement) написали Лилия Бесалева (Liliya Besaleva) и Альфред Уивер (Alfred Weaver). Они обсуждают, каким образом социальные СМИ и другие технологии Web 2.0 могут использоваться спасателями для связи и получения жизненно важной информации; при этом учитывается, что сведения, быстро тиражируемые множеством сайтов, могут быть неверными. Описывается приложение для взаимопомощи и содействия спасателям, позволяющее передавать сведения о происходящем, проводить медицинскую самодиагностику, вести обновля-

библиотека емый список пунктов первой помощи и хранить сведения о местонахождении и физическом состоянии пользователей. Главная тема июньского номера журнала Computer — информационная безопасность. С проникновением ИКТ в жизнь людей растет сложность кибератак и повышается роль технологий безопасности, а все новые угрозы требуют новых методов защиты. За последние десять лет грандиозные прорывы в области ИКТ привели к революции в сфере мобильных устройств, облаков, аналитики и социальных сетей. Появились приложения, которые собирают, хранят и обрабатывают Большие Данные: информацию о вещах, событиях, месте, времени. Сегодня идет внедрение Интернета вещей: датчиков, приводов и встроенных компьютеров. Появились «туманные вычисления», выполняемые на периферии систем. Технологии нового поколения автоматизируют процессы во многих областях, от производства и энергетики до здравоохранения и умных городов. Вместе с тем растет значение средств безопасности и защиты гигантских объемов данных. В статье «Подводные камни настроек безопасности Android» (The Perils of Android Security Configuration) Даниэль Веччиато (Daniel Vecchiato), Марко Виэйра (Marco Vieira) и Элиане Мартинс (Eliane Martins) перечисляют распространенные ошибки конфигурирования мобильной операционной системы и дают рекомендации производителям, пользователям и исследователям по повышению защищенности устройств. Статью «Безопасность и приватность в мобильной медицине» (Privacy and Security in Mobile Health: A Research Agenda) Дэвид Котц (David Kotz), Карл Гюнтер (Carl A. Gunter), Сантош Кумар (Santosh Kumar) и Джонатан Вейнер (Jonathan Weiner) посвятили направлениям исследований в соответствующей области. Авторы отмечают, что многие задачи кибербезопасности уже решены в других отраслях, поэтому и медицине можно позаимствовать имеющиеся наработки. В статье «Как пережить кибернетический Перл-Харбор» (How to Survive a Cyber Pearl Harbor) Рональд и Терренс Луи (Ronald Loui, Terrence Loui) обсуждают стратегии защиты от крупномасштабных кибератак, проводя параллели с нападением на Перл-Харбор 7 декабря 1941 года. Отмечается стратегическая важность быстрого восстановления работоспособности основных систем, хотя бы на ограниченной мощности, а также

необходимость обучения персонала разных отделов эффективному взаимодействию после непредвиденной кибератаки. В статье «Конкурс DARPA среди Twitterботов» (The DARPA Twitter Bot Challenge) В.С. Субрахманьян (V.S. Subrahmanian) и группа авторов рассматривают крупномасштабные атаки, осуществляемые с целью повлиять на общественное мнение путем распространения с помощью ботов провокационной информации в социальных СМИ. Описывается конкурс агентства DARPA, в котором участники должны были отличить таких ботов от реальных пользователей в Twitter. Приводятся методы, задействованные командами, которые добились лучших результатов. Последняя публикация номера — «Метаморфное тестирование информационной безопасности» (Metamorphic Testing for Cybersecurity), авторами которой являются Tсун Юэ Чэнь (Tsong Yueh Chen), Фэй Чин Ко (Fei-Ching Kuo), Вэньцзюань Ма (Wenjuan Ma), Вилли Сусило (Willy Susilo), Дейв Тоуи (Dave Towey), Джеффри Воас (Jeffrey Voas) и Чжи Цюань Чжоу (Zhi Quan Zhou), — посвящена обеспечению качества ПО с точки зрения защищенности от уязвимостей. Показано, что с помощью методов метаморфного тестирования можно успешно распознавать соответствующие ошибки в коде. Как дальше пойдет развитие принципов, инструментов и методов дизайна пользовательских интерфейсов? Варианты ответа на этот вопрос дают статьи июльского номера журнала Computer. Плохо проработанный пользовательский интерфейс станет слабым местом ИТ-систем, будь то носимый гаджет, «разумная» машина или устройство Интернета вещей. В статьях номера рассматривается ряд оригинальных концепций пользовательских интерфейсов будущего. Например, в публикации «Уютные пользовательские интерфейсы» (Cuddly User Interfaces) Юта Сугиура (Yuta Sugiura), Такео Игараши (Takeo Igarashi) и Масахико Инами (Masahiko Inami) описывают мир «повсеместных вычислений», в котором компьютеры встроены в мягкие вещи: подушки, ковры и т. д. Авторы противопоставляют их традиционным «жестким» интерфейсам и предлагают способы встраивания датчиков и дисплеев в повседневные предметы быта для придания им интерактивности. В статье «Обучение домашних роботов с помощью графических интерфейсов» (Graphical Instruction for Home Robots) Дайсуке Сакамото (Daisuke Sakamoto),

Юта Сугиура (Yuta Sugiura), Масахико Инами (Masahiko Inami) и Такео Игараши (Takeo Igarashi) рассматривают вопрос управления домашними бытовыми роботами. Авторы описывают взаимодействие с негуманоидными роботами различного назначения и приходят к выводу, что обучать их различным операциям лучше всего с помощью интерфейса, основанного на графических репрезентациях домашних предметов и действий, что позволит преодолеть взаимное непонимание. В статье «Умные сервисы как результат взаимодействия с потребителем» (In Search of Coproduction: Smart Services as Reciprocal Activities) ее авторы — Джон Кэррол (John Carroll), Цзявэй Чэнь (Jiawei Chen), Чиэнь Вэнь Юань (Chien Wen Yuan) и Бенджамин Ханраан (Benjamin Hanrahan) — представляют концепцию «умных» ИТ-сервисов для повседневного использования людьми. «Интеллект» сервисов обеспечивается за счет того, что пользователи сами активно участвуют в их доработке. Статью «Программирование с образцами для пользовательских интерфейсов систем обработки больших объемов данных» (Programming with Examples to Develop Data-Intensive User Interfaces) написали Дзун Като (Jun Kato), Такео Игараши (Takeo Igarashi) и Масатака Гото (Masataka Goto). Как показывают авторы, в стандартные среды разработки надо встроить средства визуализации готовых образцов массивов информации, собранной с датчиков, что упростит создание приложений для управления роботами, распознавание жестов, обработку изображений и т. п. В статье «Разработчики — тоже пользователи: человекоориентированные методы улучшения инструментов программирования» (Programmers Are Users Too: Human-Centered Methods for Improving Programming Tools) Брэд Майерс (Brad Myers), Эндрю Ко (Andrew J. Ko), Томас ЛаТоза (Thomas LaToza) и Ен Сок Еон (Young Seok Yoon) рассуждают о применении человекоориентированных подходов на этапах анализа требований, проектирования, разработки и оценки инструментов программирования в целях повышения их удобства и эффективности. Приводятся соответствующие рекомендации для ряда схем взаимодействия человека с компьютером.  Александр Тыренко (shoorah@osp.ru) — обозреватель «Computerworld Россия» (Москва).

www.osmag.ru • 03/2016 • Открытые системы • 47

Open Systems. DBMS The journal was founded in 1993

IT for Bussiness Innovative Technology for Computer Professionals

Editorial Staff Dmitry V. Volkov, Editor-in-Chief, Senior Research Fellow, Keldysh Institute of Applied Mathematics Natalia A. Dubova, Senior Reviewer

Editorial Board Valery D. Adzhiev, PhD in Computer Science, Senior Research Lecturer, The National Centre for Computer Animation, Bournemouth University, UK Fuad T. Aleskerov, DSc in Technical Science, Professor, National Research University Higher School of Economics Mikhail M. Gorbunov-Possadov, DSc in Physics and Mathematics, Assiatant professor, Moscow State University, Keldysh Institute of Apllied Mathematics, Russia Yuri A. Zelenkov, DSc in Technical Science, Professor, Financial University,Russia Sergey D. Kuznetsov, DSc in Physics and Mathematics, Professor, Moscow State University, Russia Sergey O. Kuznetsov, DSc in Physics and Mathematics, Professor, National Research University Higher School of Economics, Russia Mikhail B. Kuzminsky, PhD of chemistry, Senior research fellow, Institute of Organic Chemistry, Russian Academy of Science Alexander I. Legalov, DSc in Technical Science, Professor, Siberian Federal University Vladimir A. Suchomlin, DSc in Technical Science, Professor, Moscow State University, Russia Pavel B. Khramtsov, PhD in Computer Sciences, Assistant professor, National Research Nuclear University MEPhI, Russia Viktor Z. Shnitman, DSc in Technical Sciences, Professor, Moscow Institute of Physics and Technology, Russia Igor G. Fiodorov, PhD, Professor, Moscow State University of Economics, Statistics and Informatics (MESI), Russia Leonid K. Eisymont, PhD of physics and mathematics, Science adviser, RSI «KVANT», Russia

2016, Volume 24, Number 3

COVER FEATURES DBMS for Big Data

8O perational NoSQL Systems: What`s New and What`s Next?

Operational NoSQL systems are relatively new in the data-management ecosystem, and there is much confusion about their capabilities and how they differ from traditional relational database systems. This summary of characteristics clearly distinguishes the two system classes and provides a glimpse into directions for future work. Jignesh M. Patel (jignesh@cs.wisc.edu), professor, University of Wisconsin.

12 Renaissance in Database Management: Navigating the Landscape of Candidate Systems

Big data requirements are motivating new database management models that can process billions of data requests per second, and established relational models are changing to keep pace. The authors provide practical tools for navigating this shifting product landscape and fnding candidate systems that best ft a data managers application needs. Venkat N. Gudivada (gudivadav15@ecu.edu), professor, Dhana Rao (raod15@ecu.edu), assistant teaching professor, East Carolina University, Vijay V. Raghavan (vijay@cacs.louisiana.edu), professor, University of Louisiana at Lafayette.

18 Graph Analysis Tools

Optimum route selection apps became common a long time ago, yet finding the shortest path is not the only practical use of the graph theory, the implementation of which has become possible thanks to special-purpose database management systems and distributed tool environments. Alexander Smirnov (Alexander.Smirnov@ Thinkbiganalytics.com), Hadoop evangelist, Teradata Think Big (Moscow); Damir Gaynanov (damir@dc.ru), chair, department of Big Data and video analytics methods, Ural Federal University (Yekaterinburg).

20 Cognitive Storage for Big Data

Storage system efficiency can be significantly improved by determining the value of data. A key concept is cognitive storage, or optimizing storage systems by better comprehending the relevance of data to user needs and preferences. Giovanni Cherubini, Jens Jelitto, Vinodh Venkatesan ({cbi, jje, ven}@zurich.ibm.com), research staff members, IBM Research Zurich.

PLATFORMS

Editorial Staff Design

Maria S. Ryzhkova

Cover Design

Denis Kirkov

Administrative Staff

President

Mikhail E. Borisov

General Manager Galina A. Gerasina

Director, IT Media Group

Pavel V. Khristov

Commercial Director

Tatiana N. Filina

Circulation: Open Systems Journal (ISSN 1028-7493) is published bi-monthly by the Open Systems Publishing. Open Systems Headquarters, Dobrolyubova pr., 3, bld.3, 127254, Moscow, Russia, 127254; voice +7 495 725-4780/84, +7 499 703-1854; fax +7 495 725-4783. Editorial: Unless otherwise stated, bylined articles, as well as product and service descriptions, reflect the author’s or firm’s opinion. Inclusion in Open Systems Journal does not necessarily constitute endorsement by the Open Systems Publishing. All submissions are subject to editing for style, clarity, and space. Permission to reprint/republish this material for commercial, advertising, or promotional purposes or for creating new collective works for resale or redistribution must be obtained from the OpenSystems Publishing. Copyright© 2016 Open Systems Publishing. All rights reserved. Issue published under the support of the Federal Agency for Press and Mass Communications.

26 Accelerator Turned CPU

The second-gen Intel Xeon Phi accelerator based on the Knights Landing architecture became available on summer 2016. The chip can be used as a general-purpose CPU, promising significant changes in the high-performance computing industry, particularly for Big Data processing infrastructures. Mikhail Kuzminskiy (kus@free.net), researcher, N.D. Zelinsky Institute of Organic Chemistry.

IT MANAGEMENT

29 Improving Business Efficiency

The reason for flaws in any system lies in the system itself, particularly in an uncoordinated operation leading to resource waste. What parts of an IT system should be synchronized with each other, and how? Anton Savvin (ASavvin@trans-ts.ru), CEO, TransTechSvyaz (Moscow).

INTERNET OF THINGS

32 In the Run-up to Industrial Internet of Things

With the Internet of Things having come from the world of everyday-use smart devices, it is the time now for Industrial internet integrating the processes for manufacturing sophisticated products. There are no two identical businesses in the world, so integration of individual components across any given digital manufacturing landscape cannot serve as a model for deploying Industrial internet: rather, a solutions development platform is needed. Vladimir Krayushkin (vkray@pts-russia.com), project manager, PTS; Marina Pirogova (PirogovaMA@mpei. ru), Irina Leshikhina (liy56@mail.ru), assistant professors, Moscow Power Engineering Institute.

INTEGRATION

34 D igital Transformation and BPM Digital technologies storm into all aspects of people’s life radically changing the way enterprises are run. Business process management, meanwhile, has acquired an additional momentum through the mandatory automation. The era of paper-based processes is over. Yuliya Wagner (julia@b-k.ru), BPM development manager, Business Console; Mariya Sefer (maria.sefer@yandex.ru), independent adviser (Moscow).

CLOUD COMPUTING

36 A Tool for Digital Transformation

IDC analysts forecast that companies choosing digital transformation as their strategic focus will be leading in 2017. The main problem hindering the changes, meanwhile, lies in implementing new cloud technologies without disrupting legacy systems, which would be hard lacking a special-purpose platform. Anatoly Tretiakov (anatoly.tretyakov@ts.fujitsu.com), IT services marketing manager, Fujitsu (Moscow).

THE WORLD

38 Testing for Success Hundreds of mobile apps are created daily, including those that are critical for business and society, as well as apps whose reliability can literally mean people’s or businesses’ life or death. The HPE Mobile Center lab offers tools for mobile app testing that support virtually all platforms and device types. Igor Levshin (ilevshin@yandex.ru), freelance writer (Moscow).

41 «Miracles» of Leo Korolyov Machine translation software, a missile defense system, and the first multi-application OS: these and other «miracles», brought to life by Leo Korolyov, who would be 90 this year, laid the foundation of USSR technology independence over half a century ago. Ruslan Smelyansky (smel@cs.msu.su), professor, Moscow State University, director, Center for Applied Computer Networks Research (Moscow).

OS ACADEMY

44 I STINA Helps Universities in Making Management Decisions There is a diversity of data available on the internet related to the operation of research and educational institutions that could be useful from the management decisions making point of view. As a rule, however, all of that data is stored in databases of disparate structures, requiring processing systems capable of integrating information from various sources. One of such systems, the ISTINA data analytics solution, is being developed at the Moscow State University. Valery Vasenin (vasenin@msu.ru), Sergey Afonin (serg@msu.ru), Alexander Kozytsin (alexanderkz@mail.ru), researchers, Mechanics Scientific Research Institute at MSU (Moscow).

Library

46 Cybersecurity, Disaster Management IT, and the Future of User Interface The May, June, and July issues of the Computer magazine (IEEE Computer Society, Vol. 49, No. 5, 6, 7 2016) focus on the use of IT to improve disaster management, cybersecurity in the Third platform era, and new horizons of user interface design. Alexander Tyrenko (shoorah@osp.ru), reviewer, Computerworld Russia (Moscow).

Источник: Daimler

Люди боятся полностью самоуправляющихся автомобилей

Источник: Quinn Dombrowski/Flickr, CC BY-SA 2.0

AltOS

Приложение распознает несвежее пиво

Источник: Solar Roadways

Рестораны против бесплатного Wi-Fi

В Миссури хотят замостить дороги солнечными батареями

СУ БД

Открытые системы

№03 2016 ISSN 1028-7493 ИТ для бизнеса — архитекторам информационных систем

www.osmag.ru

СУБД: поколение Больших данных ISSN 1028-7493

•  Инструменты анализа графов