Modern arch neznanov_2015_05_14

Архитектуры и платформы
распределённых систем
анализа данных
Незнанов Алексей Андреевич,
к.т.н., доц.
14.05.2015
© А.А. Незнанов, 2015

 Данные и информационные системы
 Архитектура «в целом»
 Парадигмы и платформы, виртуализация и конвергенция
 Анализ данных
 Архитектура систем анализа данных, включая большие
 Конкретные проектные решения и инструментальные средства
 Большие и огромные данные (не влезает , но будем учитывать)
 А совсем недавно (по меркам развития науки и техники)
случилась тихая революция и, возможно, кому-то хочется быть
в курсе…
О чём? И зачем?
© А.А. Незнанов, 2015 2

 ИС – Информационная Система
 ПО – Программное Обеспечение
 ОС – Операционная Система
 БД – База Данных
 СУБД – Система Управления Базами Данных
 САД – Система Анализа Данных
Некоторые обозначения и сокращения

 Информация
 Базовое понятие, не определяемое конструктивно без использования рекурсии
из-за проблемы герменевтического круга
 от лат. informatio – разъяснение, изложение, осведомленность
 Сведения, воспринимаемые человеком и (или) спец. устройствами как
отражение фактов материального или духовного мира в процессе
коммуникации (ГОСТ 7.0-99)
 То, что снижает неопределённость (К. Шеннон)
 Не материя и не энергия (Н. Винер)
 Свойство материи быть организованной, иметь структуру и свойства, быть
определяемой. Любая информация материальна по форме существования и
нематериальна по содержанию. Материальность формы обнаруживается
органами чувств человека, а содержание – его сознанием (Б. Коллендер)
 Пояснение
 Понятие передачи информации предполагает наличие по крайней мере трех
объектов: источника, потребителя и среды передачи
Информация в «чистом» виде – это идея и философская категория
Понятие «Информация»

 Данные [data] (здесь) – любая информация, представленная в
форме, пригодной для хранения, передачи и обработки
средствами вычислительной техники
 Информационные процессы, использующие данные, называются
обработкой данных [data processing] и изучаются информатикой
 Выделяют задачи обработки данных (следующий слайд)
 Многие задачи обработки данных ставятся в различных областях
практически идентичны и могут быть решены один раз для
последующего использования
 Например, в виде модуля программно-аппаратного комплекса
Понятие «Данные»

 Обработка данных разбивается на несколько задач:
1. Ввод/вывод – извлечение информации из внешней среды и её
формализация в виде данных или сохранение данных во внешней среде
2. Преобразование форматов – изменение способа представления данных
3. Телекоммуникации – передача данных между компонентами
распределённых информационных систем
4. Хранение – обеспечение долговременной доступности, целостности и
защищенности данных
5. Поиск данных – выполнение поисковых запросов к массивам данных
6. Переработка – существенное преобразование содержания и/или формы
данных, выполняемое на основе анализа и/или синтеза
 Данные разделяют по подходам к их обработке на:
1) числовые (параметры простых математических моделей)
2) текстовые (цепочки символов некоторого алфавита)
3) структурные (графы, описывающие структуру систем)
4) мультимедийные (аудиовизуальные и др.)
5) комплексные ()
Обработка данных

 Информационная система (ИС) [information system]
 (по законодательству РФ) – организационно упорядоченная совокупность
документов (массивов документов) и информационных технологий, в том
числе с использованием средств вычислительной техники и связи,
реализующих информационные процессы
 Система, предназначенная для хранения, обработки, поиска,
распространения, передачи и предоставления информации
  ИС работают не с информацией, а с данными в виде
документов
 Программа = Алгоритм + Данные!
 А ИС в целом?
Понятие «Информационная система»

 Артефакт (от лат. Arte – искусственный и Factus – сделанный) –
искусственно созданный с некоторой целью материальный или
нематериальный (информационный) объект
 Документ [document] – артефакт, являющийся средством
закрепления различным способом на материальном носителе
сведений о фактах, событиях, явлениях объективной
действительности и мыслительной деятельности человека
 Документы принято условно разделять на первичные (содержащие запись
фактов) и вторичные (содержащие результаты анализа этих фактов)
Артефакт и документ

 В соответствии с ГОСТ Р 51141-98 «Делопроизводство и архивное
дело. Термины и определения» документ – зафиксированная на
материальном носителе информация с реквизитами,
позволяющими ее идентифицировать, а документирование – это
запись информации на различных носителях по установленным
правилам
 Базовые правила документирования устанавливает ГОСТ Р 6.30
2003 «Унифицированные системы документации.
Унифицированная система организационно-распорядительной
документации. Требования к оформлению документов»
 Стандарт вводит 30 реквизитов
(от «подписи» до «Государственного герба Российской Федерации»)
Стандартизация документов

 Метаданные – данные, описывающие данные
 Есть ли точная граница?
 Реквизит документа – это метаданные или данные?
 Формализация метаданных
 Модели данных и форматы данных
 Пример UML (Unified Modeling Language) Metamodel & Metametamodel
 (http://www.uml-diagrams.org/uml-meta-models.html)
 Пример BPMN (Business Process Model And Notation)
 (http://modeling-languages.com/has-success-bpmn-20-killed-bpdm-business-process-definition-metamodel)
 В чём отличия «абстрактного типа данных», «[конкретного] типа
данных», «формата данных»?
Данные и метаданные

Сериализованные
структурированные данные
Esc-форматированные строки
Символьное представление
атомарных данных
Бинарные данные
Форматы данных
Конверторы
Типы данных

 Архитектура информационной системы [architecture] –
совокупность существенных решений, определяющих
 Специфику проектных решений
 Общую организацию ИС
 Выбор уровней абстракции и структурных элементов системы, а также
интерфейсов между ними
 Поведение структурных элементов в процессе взаимодействия с другими
элементами
 Архитектурный стиль, направляющий и определяющий организацию
системы, процесс абстрагирования и реализации
Архитектура (определение)

 Возможность выбора архитектуры системы появляется потому, что
всегда присутствует определённый произвол в выборе уровней
абстракций и способов декомпозиции системы
 Следует понимать, что главное свойство архитектуры сложной системы
– многоуровневость
 На самом верхнем уровне архитектуры располагается концепция (от
лат. conceptio – понимание), т. е. определённая точка зрения на
систему, руководящая идея при её исследовании или создании, ниже
обычно выделяют логическую [logical] и физическую [physical]
архитектуру
 Построение архитектуры всегда является процессом специфицирования
 Спецификация [specification] – детализированное (относительно
текущего уровня абстракции) определение чего-либо, включающее
классификацию и перечень специфических особенностей, важных
параметров и их значений
Архитектура (обсуждение)

 Открытая система (по IEEE POSIX 1003.0, 1988 г.)
 реализует открытые спецификации на форматы данных, интерфейсы и
сервисы, достаточные для того, чтобы дать возможность должным образом
разработанным системам быть переносимыми, взаимодействовать с
другими открытыми системами и взаимодействовать с пользователями в
стиле, который облегчает переход пользователей от системы к системе
 Семиуровневая модель OSI (Open Systems Interconnection) для
формализации взаимодействия открытых систем.
 Проект: 1982-1996 гг.
 Огромный вклад в концепцию современных телекоммуникаций
 Основной методологический результат – эталонная модель OSI
 Технологические результаты уже практически не используются
 Переусложнённые, трудные для реализации, использующие концепции телекоммуникаций 1980-х годов
 Сетевые интерфейсы и протоколы
 Стек TCP/IP как победитель в борьбе за существование
Открытые системы и OSI

 Джоэл Сполски сформулировал следующее утверждение:
Все нетривиальные абстракции дырявы
 (http://www.joelonsoftware.com/articles/LeakyAbstractions.html)
 Проблема «прозрачности»
 Часть закона дырявых абстракций – прозрачность некоторых
технологических решений иногда приводит к неправильной интерпретации
процессов пользователем
 Вопросы:
 Сколько уровней абстракций в современных ИС?
 Можете ли Вы сами вспомнить, мешало ли когда-либо Вам абсолютное
незнание существенных особенностей реализации пользоваться каким-либо
сервисом?
«Закон дырявых абстракций»

 Платформа [platform] – наиболее общее описание программно-
аппаратной среды, на которой разрабатывается и/или
развёртывается прикладное программное обеспечение
 Платформа специфицирует архитектуры компьютеров и сетей передачи
данных, типы ОС, СУБД и т.п.
 Часто употребляемые термины платформа разработки и платформа
развёртывания детализируют средства разработки ПО и необходимое
программное окружение готового ПО соответственно
 Часто говорят об инфраструктурной платформе, позволяющей описать
наиболее общие характеристики инструментальных средств, позволяющих
реализовать заданный класс архитектур на нескольких платформах
разработки
Платформы (определение)

Платформы (иллюстрация)
ПриложенияПриложения
Операционная система
Библиотеки
Приложение
Платформа разработки
Технологии хранения данных
Технологии коммуникации
Технологии идентификации
Платформа развёртывания
Инфраструктурная платформа
Прикладная платформа
Приложения
…

 Виртуальный
 (англ. Virtual раньше означало «действительный» в противовес
«реальному», virtue – добродетель, достоинство; ср. лат. virtus -
потенциальный, возможный, доблесть, энергия, сила, а также мнимый,
воображаемый) –
1. В сущности являющийся; возможный; воображаемый (в современном
английском)
2. Возможный в идее (Брокгауз и Ефрон)
3. Пребывающий в скрытом состоянии и могущий проявиться, случиться;
возможный (Ушаков)
4. Не имеющего физического воплощения, гипотетический
5. Представляющий интерфейс некоторой сущности, при этом ею не
являясь
 В сфере информационных технологий
Виртуализация

Уровни виртуализации
Аппаратура
Операционная система
Бизнес-логика приложения
Интерфейс с пользователем

 За:
 Экономия ресурсов в результате консолидации распределённых систем
 Эмуляция отсутствующих ресурсов, возможность использования
унаследованных ресурсов
 Изолирование потенциально опасных компонентов в виртуальном
окружении
 Улучшение управляемости
 Ускорение развёртывания и модификации прикладных платформ
 Упрощение миграции
 Против:
 Проявление во всей красе закона дырявых абстракций! Усложнение
 Снижение локальной эффективности (виртуализация вызывает накладные
расходы)
 Совместимость (не всё и не всегда поддаётся виртуализации)
Преимущества и недостатки виртуализации

 Основа архитектуры – явное разделение ролей:
 Клиент – сущность, запрашивающая некоторый сервис
 Сервер – сущность, предоставляющая сервис по запросу
 Отсюда – неизбежность рождения концепции SOA, о которой далее
 Одна и та же сущность может выступать как клиентом, так и
сервером в различных взаимодействиях
 Отсюда – неизбежность рождения многозвенных архитектур, о которых сразу после пояснений
 Классическая статья Д. С. Линтикама «Разгадка архитектуры клиент-сервер»
(http://docstore.mik.ua/press/skpress/pc_mag/7967.htm)
Архитектура клиент-сервер

Как отличить клиента от сервера
Клиент:
 Инициирует обращение к
серверу, ожидает ответа и
принимает данные
 Оперирует относительно
небольшим объёмом данных
 Обычно использует
небольшое число серверов
 Находится ближе к конечному
пользователю
 Сервер:
 Не инициирует обращений
 Ожидает запросы и
обрабатывает их
 Оперирует относительно
большим объёмом данных
 Может обслуживать большое
число клиентов
 Может удалённо управлять
зарегистрированными
клиентами (удалённое
администрирование)

 Логически
 Уровни (слои)
 Звенья
 Потоки задач
 Физически
 Источники данных
 Среднеслойные объекты
 Сервера среднего слоя
 Вершина развития –
сервера приложений
 Интерфейс с пользователем
Многозвенные архитектуры
© Microsoft

«Ранняя» ППП [WWW] (до 1994 года)
© Tim Berners-Lee

 Исходная инфраструктура:
 Язык описания данных – eXtandible Markup Language (XML)
 Язык описания запросов – Simple Object Access Protocol (SOAP)
 Язык описания служб – Web-Service Description Language (WSDL)
 Web-служба (исходно) – приложение, способное
взаимодействовать с другими приложениями в сети Интернет по
протоколу SOAP, интерфейс которого описан на языке WSDL, а в
качестве транспортного протокола используется http(s)
 Сейчас смысл расширился!
Web-службы (сервисы)

 Наиболее популярный формальный язык разметки электронных
документов
 Более 30 стандартов и куча инструментов
 (http://www.w3.org/standards/xml)
 Прямое использование в Web: XHTML
 Инерция корпоративного рынка – примеры
XML

 Протокол обмена сообщениями на
языке XML между объектами
распределённой информационной
системы
 Simple Object Access Protocol
 К настоящему моменту обычно не
расшифровывается, так как область
применения значительно расширилась
 Последняя версия – SOAP Version 1.2
(W3C Recommendation, Second Edition,
27.04.2007)
 http://www.w3.org/TR/soap
SOAP

 XML-основанный язык для описания web-служб
 http://www.w3.org/TR/2007/REC-wsdl20-20070626
 Tutorial (http://www.w3schools.com/webservices/ws_wsdl_intro.asp)
 <definitions>
<types>
// Data type definitions........
</types>
<message>
// Definition of the data being communicated....
</message>
<portType>
// Set of operations......
</portType>
<binding>
// Protocol and data format specification....
</binding>
</definitions>
WSDL

 Representational State Transfer
 Автор первого разъяснения – Рой Филдинг [Roy Fielding], 2000 г.
 Простота и понятность + отсутствие состояний
 Свойства
 Единый интерфейс [Uniform Interface]
 Отсутствие состояний [Stateless]
 Кеширование ответа [Cacheable]
 Клиент-сервер [Client-Server]
 Многоуровневая система [Layered System]
 «Код по требованию» [Code on Demand] (опционально)
 Именование ресурсов по схеме URI (URL)
 Формат JSON (json.org)
 CRUD поверх HTTP (команды put, get, post, delete)
RESTful-сервисы

 Есть стандарт
 JSON - ECMA-404 (http://json.org, http://www.ecma-
international.org/publications/files/ECMA-ST/ECMA-404.pdf)
 Есть бинарное представление для хранения и быстрой обработки
 BSON (http://bsonspec.org), UBJSON (http://ubjson.org )
 Есть человекоориентированные надстройки
 Hjson, the Human JSON (http://hjson.org)
 Есть расширения
 JSON5 (http://json5.org)
 Есть построение схем документов и валидаторы
 JSON Schema (http://json-schema.org)
 Есть аналог XPath
 JSONPath (http://goessner.net/articles/JsonPath)
 Но все навороты ещё не вошли в стандарт (это отдельные мелкие
проекты) + нет нормального аналога DOM, XSLT и XQuery!
 Хотя даже в Visual Studio 2013 sp3 встроили прекрасный редактор JSON
 + почитайте обсуждение: http://habrahabr.ru/post/248147 (  )
Сможет ли JSON заменить XML?

 SOA (Service-Oriented Architecture)
 Аутсорсинг IT-инфраструктуры организации (службы и сервисы)
 Вполне естественная архитектура для корпоративного заказчика
 Развитие архитектуры «клиент-сервер»
 С развитием технологий виртуализации становится удобной и для других применений
 По другому – Software as a Service (SaaS)
 Свойства SaaS- приложений:
 Создаются и поддерживаются сотрудниками провайдера услуг
 Изначально создаются для использования в глобальной сети (Интернет)
 Совместное использование («коммунальность»): несколько организаций пользуются
одной логической копией приложения, а разделение ресурсов происходит на уровне
бизнес-логики
 Клиенты вносят периодическую плату за использование приложений (включающую в
себя стоимость поддержки)
 SaaS-приложения заменяют использовавшиеся ранее внутриофисные приложения с
похожим функционалом
 Все значимые бизнес-процессы (регистрация клиента в системе, управление
пользователями, оплата) полностью автоматизированы
 Настройка под конкретного клиента делается путём изменения отдельных параметров (в
отличие от классических КИС), что часто не позволяет создавать крупные компоненты, а
вынуждает заниматься интеграцией мелких
Service-Oriented Architecture

 Новый ландшафт платформ развёртывания…
 SaaS, PaaS и IaaS за последние 5 лет обзавелись отлаженными
открытыми реализациями
 OpenStack как открытая платформа (http://www.openstack.org)
«Облака» – белогривые лошадки

 Microsoft Azure (http://azure.microsoft.com)
 Amazon Web Services (http://aws.amazon.com)
 Amazon Elastic Compute Cloud (EC2) (http://aws.amazon.com/ec2/)
 Google Cloud Platform (https://cloud.google.com)
 Oracle Cloud – Enterprise Cloud Computing SaaS, PaaS, IaaS
(https://cloud.oracle.com/home)
 IBM Cloud (http://www.ibm.com/cloud-computing)
 VMware vCloud Air (http://vcloud.vmware.com)
 Rackspace Managed Cloud (http://www.rackspace.com/cloud)
 SalesForce1 Platform (http://www.salesforce.com/platform/services)
 Red Hat® Enterprise Linux® OpenStack Platform
(http://www.redhat.com/en/technologies/linux-platforms/openstack-
platform)
 Отметим, что многие другие тоже предлагают OpenStack
Основные провайдеры облачных сервисов

 Интеграционные шины
 Mule ESB (www.mulesoft.org), …
 Сервисы конвергенции Web API
 APIMATIC (https://apimatic.io), MASHAPE (https://www.mashape.com), …
Интеграция приложений

MuleSoft AnyPoint API Designer (viewer)

 Ползучая технологическая революция
 Конвергенция платформ, особенно платформ развёртывания
 Всеобщая виртуализация
 Изначальная ориентация на построение распределённых систем
 Интернет как общая инфраструктура распределённых систем
 Реализация распределённых виртуализированных инфраструктурных
платформ, сблизивших разные «миры программирования»
 Непрерывный рост популярности языков склейки
 Реальный пример – склейка на языке Python web-служб на Scala (новой) и
C++ (унаследованной)
 Торжество JSON как простого, но достаточного формата
сериализации
 Посягательство на лавры XML, но не только
 «Методологические атаки» на основания «классической»
программной инженерии (упс! Отдельная тема)
Промежуточные выводы

 Всё наработанное за 90-е годы никто не отменял!
 UML по-прежнему lingua franca для аналитиков, проектировщиков и
разработчиков
 Более того, в 2014 году для OCL (Object Constraint Language) наконец предложили нормальную формальную
семантику
 Но! Повзрослели:
 Принципы SOLID
 Методы уникальной идентификации объектов и размещений [GUID + URI]
 Автоматическая сериализация [Serialization]
 Объектно-реляционное отображение [ORM – Object-Relational Mapping]
 CRUD-доступ к элементам моделей данных [Create, ]
 Развитие достаточно универсальных инфраструктурных программных
решений (фреймворков [framework]), которые программист расширяет, в
отличие от библиотек, которые он встраивает
 Основной механизм – инверсия зависимостей
 Ещё в книге «Cwalina K., Abrams B. Framework Design Guidelines: Conventions,
Idioms, and Patterns for Reusable .NET Libraries. – Addison-Wesley, 2005» фреймворк
понимается не в самом современном смысле.
Объектно-ориентированное проектирование

 Расшифровка SOLID:
 S – The Single Responsibility Principle – Принцип единственной ответственности
 O – The Open-Closed Principle – Принцип открытости-закрытости
 L – The Liskov Substitution Principle – Принцип замещения Барбары Лисков
 I – Interface Segregation Principle – Принцип разделения интерфейсов
 D – The Dependency Inversion Principle – Принцип инверсии зависимостей
 Призваны решить частые проблемы «классической» ООП-декомпозиции:
 Жесткость – изменение одной части кода затрагивает слишком много других частей
 Хрупкость – даже незначительное изменение в коде может привести к совершенно
неожиданным проблемам
 Неподвижность – никакая из частей приложения не может быть легко выделена и
повторно использована
 Принципы влекут за собой шаблоны проектирования
 Некоторые – уже давно известные, но теперь согласованные и «прочувствованные» на
уровне общей архитектуры крупных программных комплексов
 Лучшая краткая справка у Дяди Боба
(http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod)
SOLID Principles

 Существует три понятия, связанных c передачей и управлением
зависимостями, в каждом из которых есть слово «инверсия»
(inversion) или «зависимость» (dependency):
 IoC – Inversion of Control (Инверсия управления)
 Martin Fowler, Inversion of Control Containers and the Dependency Injection pattern, 2004.
 IoC Containers – специальные контейнеры для упрощения создания фреймворков
 DI – Dependency Injection (Внедрение зависимостей)
 DIP – Dependency Inversion Principle (Принцип инверсии зависимостей)
 Первое формальное упоминание: Robert Martin, The Dependency Inversion
Principle, C++ Report, 1996.
 Объяснение соответствующих шаблонов – отдельная лекция
 См. новые работы, развивающие идеи «банды четырёх» [Gang of Four]
Инверсия управления и внедрение зависимостей

 Идея – прозрачное отображение объектно-ориентированной
модели на реляционное
 В реальности – использование реляционных СУБД для
обеспечения прозрачной персистентности ОО-модели
 Mapping Objects to Relational Databases: O/R Mapping In Detail
(http://www.agiledata.org/essays/mappingObjects.html)
 Кстати, пригодился рефакторинг РСУБД (http://agiledata.org/essays/databaseRefactoring.html)
 ORM-библиотеки или слои в фреймворках
 Hibernate, QxOrm, ADO.NET Entity Framework, DataObjects, MORMot,
SQLAlchemy, …
 Популярным стало сравнение, причём оно действительно полезно, так как
производительность, надёжность и другие характеристики могут сильно
отличаться!
ORM – Object-Relational Mapping

Java Spring

 На архитектурном уровне – всё меньше и меньше…
 Для конкретных задач – конечно
 Intel каждый год выпускает компилятор Fortran !
 Функциональные языки нашли свою нишу, а их элементы
появились в других языках
 Предметно-ориентированные языки наконец «расцвели»
 См. TIOBE Index (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)
 Далее будет про R и др.
 Методологии TDD, MDD, ADD окончательно отвязались от
исходных reference implementations
А важен ли язык?

 Пока мы рассматривали общеархитектурные вопросы
Как это связано с системами анализа данных?
 Что такое анализ данных с точки зрения программиста?
 Многоэтапный (а часто – ещё и итеративный) процесс получения из сырых
данных нового знания, проходящий, возможно, на основе уже имеющегося
формализованного знания (онтологии)
Какие это влечёт архитектурные требования?
Анализ данных и все-все-все

 Поддерживаемые модели данных (реляционная, …)
 Поддерживаемые типы данных (числа, формальный текст,
неструктурированный текст, графовые модели, …)
 Обрабатываемые форматы данных и инструменты
импорта/экспорта
 Поддерживаемые языки запросов
 Методы анализа (описательная статистика, другие статистические
методы, майнинг данных, классификация, кластеризация, анализ
сетей, анализ текста на естественном языке, …)
 Формализация моделей представления знаний
 Использование априорных внутренних и внешних знаний
(онтологий)
 Масштабируемость
 Интеграция с другими системами
Критерии классификации САД

 IBM SPSS Analytics (http://www.ibm.com/software/analytics/spss)
 IBM i2 Analyst notebook
(http://www.ibm.com/software/products/en/analysts-notebook-
family)
 [free] Weka (http://sourceforge.net/projects/weka)
 [free] Orange (http://orange.biolab.si)
 [free] Инструменты рамочного проекта PyData (http://pydata.org)
 Microsoft Power BI (https://www.microsoft.com/en-us/powerbi)
 Pentaho (http://www.pentaho.com)
 А как же IBM Watson?
ПО Анализа данных

Orange (Explorative analysis and classification trees)

 По отдельным классам – очевидно
 По возможно применения при решении комплексных
«проблем реального мира»
 Сравнение программных продуктов для анализа данных:
 R, MATLAB, SciPy, MS Excel, SAS, SPSS, Stata
(http://www.mbureau.ru/blog/sravnenie-programmnyh-produktov-dlya-analiza-
dannyh-r-matlab-scipy-ms-excel-sas-spss-stata)
 1010data, Actian, Cloudera, Amazon Redshift, HP Vertica, и др.
(http://www.informationweek.com/big-data/big-data-analytics/16-top-big-data-
analytics-platforms/d/d-id/1113609)
Возможности сравнения

 Долгая история (с 1970-х годов)
 Предобработка данных для целей дальнейшего анализа имеет много
«гитик»
 Формализации этого процесса посвящено множество исследований
 ETL
 Extract, transform, load are three database functions, combined into one tool to
pull data out of one database and place it into another database
 2014 г. – понятие «Data Tiding»
 Wickham H. Tidy Data. JSS, 59 (10), 2014
(http://www.jstatsoft.org/v59/i10/paper)
 Соответствующий пакет для R, активное обсуждение идеологии
ETL – Extract-Transform-Load

 Dynamic Ontology-Driven Data Mining System
 С.О. Кузнецов, А.А. Незнанов
 Лаборатория интеллектуальных систем и структурного анализа НИУ ВШЭ
 http://cs.hse.ru/ai/issa
 Платформа интеллектуального анализа данных под управлением
онтологий
 Простота, расширяемость, воспроизводимость экспериментов,
многоуровневость представления данных и знаний, работа с
метаданными
DOD-DMS

 Ещё достаточно классическая:
Архитектура DOD-DMS 0.8

 От внешних данных – к
артефактам аналитика
 IDS накапливает данные
в виде коллекций с
метаданными
 Клиенты предоставляют
интерактивные
инструменты
Основной рабочий цикл в FCART
JSON Collection
Data Snapshot
(Multivalued Context)
Binary Context
Concept Lattice
FCART
Import/Export
Tools
Pattern Structure
Clusters
External Data Set
External Data
Query Description
Snapshot Profile &
Graph Generators
Session DB
External Data Source
SOMs
Analytic Artifacts
MongoDB
IDS Web-service
Http Request Parser
IDS Import/Export Tools
Indexing Subsystem
Communication Subsystem
Snaphot Scaling
Query

IDS Web API

 Важнейшая характеристика САД – поддерживаемые языки
запросов [query language]
 В DOD-DMS предусмотрено 3 уровня языков:
 Предобработка внешних данных (Препроцессинг)
 Языки запроса внешних данных: реляционных и структурных
 Языки манипулирования данными в промежуточном хранилище
 Язык построения многозначных контекстов (снимков [snapshot]) и графов [graph]
 Метод-ориентированные языки
 Языки шкалирования данных в Анализе формальных понятий: получение из
многозначного контекста бинарного контекста
 Языки запроса к неструктурированному тексту
 Отдельный язык – язык запросов к онтологиям
 Возможность подключения DSL (например, языка R)
Языки запросов

Клиент FCART

 Это потом...
 Но пара ссылок:
 SPARC (https://spark.apache.org)
 Databricks (https://databricks.com)
 Новые инфраструктурные платформы…
 Помните – в промежуточных выводах?
А как же BIG Data?

Примеры реализаций «вживую»

 Контакты
 Доцент департамента анализа данных и искусственного интеллекта ФКН
НИУ ВШЭ, старший научный сотрудник лаборатории интеллектуальных
систем и структурного анализа НИУ ВШЭ,
к.т.н., доц. Незнанов Алексей Андреевич
 E-Mail: aneznanov@hse.ru
The End

 Важнейшее направление – базис нового поколения баз знаний и
систем анализа медицинских данных
 Развивается во всех предметных областях – от общей
терминологии и связи базовых понятий медицины
(метаонтологии) до заболеваний, симптомов, возбудителей,
лекарственных препаратов и их компонентов, методов лечения,
геномных маркеров и т.д.
 Многие онтологии свободны и доступны для непосредственного
использования через web-сервисы или пользовательские
web-интерфейсы
 Приведём лишь несколько примеров
Онтологическое моделирование в медицине

 Unified Medical Language System (UMLS) Metathesaurus
(http://www.nlm.nih.gov/research/umls/quickstart.html)
 Интегратор источников данных, предметных онтологий и метаонтологий
 SNOMED Clinical Terms (http://www.ihtsdo.org/snomed-ct)
 Medical Subject Headings (MeSH)
(http://www.nlm.nih.gov/mesh/meshhome.html)
 MedDRA текущая версия 17.1 (http://www.meddra.org)
 HL7 Reference Information Model
(http://www.hl7.org/implement/standards/rim.cfm)
 …
 Инструменты группы Medical Ontology Research
(http://mor.nlm.nih.gov)
Базовые метаонтологии

 Болезни (Diseases) – важнейшая область онтологического
моделирования,с точки зрения классификации – класс проблем
со здоровьем, который можно выделить с точки зрения причин,
симптоматики, последствий и способов лечения
 International Classification of Diseases and Related Health Problems,
ICD – 10 пересмотр, сейчас готовится 11 пересмотр
(http://www.who.int/classifications/icd)
 ICD-O (Oncology) – 3 пересмотр
(http://www.who.int/classifications/icd/adaptations/oncology)
 Международная классификация болезней, МКБ
 Перевод ICD с некоторыми странными несоответствиями
 The Disease Ontology (http://disease-ontology.org)
 …
Классификаторы и онтологии заболеваний

 FDA Substance Registration System – Unique Ingredient Identifier
(http://fdasis.nlm.nih.gov/srs/srs.jsp)
 RxNorm – нормализованные названия лекарственных препаратов
(http://www.nlm.nih.gov/research/umls/rxnorm/index.html)
 Anatomical Therapeutic Chemical (ATC) classification system
(http://www.whocc.no/atc_ddd_methodology)
 Drug Interactions Checker (http://www.drugs.com/drug_interactions.php)
 Gene Ontology Consortium (http://geneontology.org/)
 …
Другие предметные онтологии

Modern arch neznanov_2015_05_14

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (11)

Similar to Modern arch neznanov_2015_05_14

Similar to Modern arch neznanov_2015_05_14 (20)

More from Alexey Neznanov

More from Alexey Neznanov (8)

Modern arch neznanov_2015_05_14