- •Оглавление
- •Список иллюстраций
- •Список таблиц
- •Вступительное слово компании «Юнидата»
- •Вступительное слово компании BSSG
- •Предисловие
- •Глава 1. Управление данными
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели
- •2. ОСНОВНЫЕ ПОНЯТИЯ И КОНЦЕПЦИИ
- •2.1 Данные
- •2.2 Данные и информация
- •2.3 Данные как актив организации
- •2.4 Принципы управления данными
- •2.5 Проблемы управления данными
- •2.6 Стратегия управления данными
- •3. РАМОЧНЫЕ СТРУКТУРЫ УПРАВЛЕНИЯ ДАННЫМИ
- •3.1 Модель стратегического выравнивания
- •3.2 Амстердамская информационная модель
- •3.3 Рамочная структура DAMA-DMBOK
- •3.4 Пирамида DMBOK (Айкен)
- •3.5 Дальнейшая эволюция рамочной структуры управления данными DAMA
- •4. DAMA И DMBOK
- •5. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 2. Этика обращения с данными
- •1. ВВЕДЕНИЕ
- •2. БИЗНЕС-ДРАЙВЕРЫ
- •3. ОСНОВНЫЕ ПОНЯТИЯ И КОНЦЕПЦИИ
- •3.1 Этические принципы, связанные с данными
- •3.2 Основополагающие принципы законодательства о конфиденциальности данных
- •3.3 Этические аспекты работы с данными в режиме онлайн
- •3.4 Риски, обусловленные неэтичными практиками обращения с данными
- •3.5 Формирование культуры этичного обращения с данными
- •3.6 Этика обращения с данными и руководство данными
- •4. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 3. Руководство данными
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Определение задач и функций руководства данными в организации
- •2.2 Проведение оценки готовности
- •2.3 Выявление возможностей / угроз и согласование с бизнесом
- •2.4 Создание точек взаимодействия внутри организации
- •2.5 Разработка стратегии руководства данными
- •2.6 Определение операционной рамочной структуры руководства данными
- •2.7 Выработка целей, принципов и политик
- •2.8 Поддержка проектов в области управления данными
- •2.9 Внедрение практики управления организационными изменениями
- •2.10 Внедрение практики управления проблемными вопросами
- •2.11 Оценка требований по нормативно-правовому соответствию
- •2.12 Внедрение руководства данными
- •2.13 Поддержка стандартов и процедур
- •2.14 Разработка бизнес-глоссария
- •2.15 Координация взаимодействия с архитектурными группами
- •2.16 Оказание содействия в финансовой оценке данных
- •2.17 Встраивание руководства данными в процессы
- •3. ИНСТРУМЕНТЫ И МЕТОДЫ
- •3.1 Присутствие в Сети / Веб-сайты
- •3.2 Бизнес-глоссарий
- •3.3 Инструменты для управления потоками работ
- •3.4 Инструменты для управления документами
- •3.5 Оценочная ведомость руководства данными
- •4. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •4.1 Организация и культура
- •4.2 Согласование действий и коммуникации
- •5. МЕТРИКИ
- •6. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 4. Архитектура данных
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Результаты и практики разработки архитектуры данных
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Внедрение практики разработки и сопровождения архитектуры данных
- •2.2 Интеграция с корпоративной архитектурой
- •3. ИНСТРУМЕНТЫ
- •3.1 Инструменты моделирования данных
- •3.2 Программное обеспечение для управления ИТ-активами
- •3.3 Приложения для графического проектирования
- •4. МЕТОДЫ
- •4.1 Проекции на фазы жизненного цикла
- •4.2 Четкость и ясность графических представлений
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •5.1 Оценка готовности / Оценка рисков
- •5.2 Организационные и культурные изменения
- •6. РУКОВОДСТВО АРХИТЕКТУРОЙ ДАННЫХ
- •6.1 Метрики
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 5. Моделирование и проектирование данных
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 План проведения работ по моделированию данных
- •2.2 Построение модели данных
- •2.3 Проверка и оценка качества моделей данных
- •2.4 Сопровождение моделей данных
- •3. ИНСТРУМЕНТЫ
- •3.1 Инструменты моделирования данных
- •3.2 Инструменты для отслеживания происхождения данных
- •3.3 Инструменты профилирования данных
- •3.4 Репозитории метаданных
- •3.5 Шаблоны моделей данных
- •3.6 Отраслевые модели данных
- •4. ЛУЧШИЕ ПРАКТИКИ
- •4.1 Лучшие практики в области соглашений об именовании
- •4.2 Лучшие практики проектирования баз данных
- •5. РУКОВОДСТВО МОДЕЛИРОВАНИЕМ И ПРОЕКТИРОВАНИЕМ ДАННЫХ
- •5.1 Управление качеством моделей и проектных решений
- •5.2 Метрики моделирования данных
- •6. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 6. Хранение и операции с данными
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Управление технологиями баз данных
- •2.2 Управление базами данных
- •3. ИНСТРУМЕНТЫ
- •3.1 Инструменты моделирования данных
- •3.2 Инструменты мониторинга баз данных
- •3.3 Инструменты управления конфигурацией баз данных
- •3.4 Инструменты разработки приложений
- •4. МЕТОДЫ
- •4.1 Тестирование в средах более низкого уровня
- •4.2 Стандарты именования для физической модели данных
- •4.3 Использование сценариев для внесения любых изменений
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •5.1 Оценка готовности / Оценка рисков
- •5.2 Организационные и культурные изменения
- •6. РУКОВОДСТВО ХРАНЕНИЕМ И ОПЕРАЦИЯМИ С ДАННЫМИ
- •6.1 Метрики
- •6.2 Отслеживание и учет информационных активов
- •6.3 Аудит и проверка корректности данных
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 7. Безопасность данных
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Выявление требований по безопасности данных
- •2.2 Определение политики безопасности данных
- •2.3 Определение стандартов в области безопасности данных
- •3. ИНСТРУМЕНТЫ
- •3.1 Антивирусное программное обеспечение
- •3.2 Протокол HTTPS
- •3.3 Технологии управления идентификацией
- •3.4 Системы обнаружения и предотвращения вторжений
- •3.5 Межсетевые экраны
- •3.6 Отслеживание метаданных
- •3.7 Маскировка / Шифрование данных
- •4. МЕТОДЫ
- •4.1 Использование CRUD-матриц
- •4.2 Немедленное развертывание обновлений безопасности
- •4.3 Атрибуты безопасности в метаданных
- •4.4 Метрики
- •4.5 Учет потребностей в безопасности данных в проектных требованиях
- •4.6 Эффективный поиск в массиве зашифрованных данных
- •4.7 Санитизация документов
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •5.1 Оценка готовности / Оценка рисков
- •5.2 Организационные и культурные изменения
- •5.3 Доступность информации о наборах прав пользователей
- •5.4 Обеспечение безопасности данных в условиях аутсорсинга
- •5.5 Обеспечение безопасности данных в облачных средах
- •6. РУКОВОДСТВО БЕЗОПАСНОСТЬЮ ДАННЫХ
- •6.1 Безопасность данных и корпоративная архитектура
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 8. Интеграция и интероперабельность данных
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Планирование и анализ
- •2.2 Проектирование решений по интеграции данных
- •2.3 Разработка решений по интеграции данных
- •2.4 Внедрение и мониторинг
- •3. ИНСТРУМЕНТЫ
- •3.1 Программный комплекс для преобразования данных / ETL-инструмент
- •3.2 Сервер виртуализации данных
- •3.3 Корпоративная шина данных (ESB)
- •3.4 Программный комплекс для управления бизнес-правилами
- •3.5 Инструменты моделирования данных и процессов
- •3.6 Инструменты профилирования данных
- •3.7 Репозиторий метаданных
- •4. МЕТОДЫ
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •5.1 Оценка готовности / Оценка рисков
- •5.2 Организационные и культурные изменения
- •6. РУКОВОДСТВО DII
- •6.1 Соглашения о совместном доступе к данным
- •6.2 DII и происхождение данных
- •6.3 Метрики для оценки эффективности интеграции данных
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 9. Управление документами и контентом
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Планирование управления жизненным циклом
- •2.2 Управление жизненным циклом документов и контента
- •2.3 Публикация и доставка контента
- •3. ИНСТРУМЕНТЫ
- •3.1 Системы управления корпоративным контентом
- •3.2 Инструменты поддержки совместной работы
- •3.3 Инструменты управления контролируемыми словарями и метаданными
- •3.4 Стандартные форматы разметки и обмена
- •3.5 Технологии e-discovery
- •4. МЕТОДЫ
- •4.1 Сценарий подготовки электронной доказательной базы
- •4.2 Карта данных, которые могут быть найдены и представлены
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •5.1 Оценка готовности / Оценка рисков
- •5.2 Организационные и культурные изменения
- •6. РУКОВОДСТВО УПРАВЛЕНИЕМ ДОКУМЕНТАМИ И КОНТЕНТОМ
- •6.1 Рамочные структуры руководства информацией
- •6.2 Рост объемов информации
- •6.3 Управление качеством контента
- •6.4 Метрики
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 10. Справочные и основные данные
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Работы по управлению основными данными
- •2.2 Работы по управлению справочными данными
- •3. ИНСТРУМЕНТЫ И МЕТОДЫ
- •4. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •4.1 Строгое следование архитектуре основных данных
- •4.2 Мониторинг движения данных
- •4.3 Управление изменениями справочных данных
- •4.4 Соглашения о совместном использовании данных
- •5. ОРГАНИЗАЦИОННЫЕ И КУЛЬТУРНЫЕ ИЗМЕНЕНИЯ
- •6. РУКОВОДСТВО СПРАВОЧНЫМИ И ОСНОВНЫМИ ДАННЫМИ
- •6.1 Метрики
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 11. Ведение хранилищ данных и бизнес-аналитика
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Выработка понимания требований к DW
- •2.2 Определение и сопровождение архитектуры DW/BI
- •2.3 Проектирование и разработка хранилища и витрин данных
- •2.4 Заполнение хранилища данных
- •2.5 Внедрение портфеля инструментов BI
- •2.6 Сопровождение информационных продуктов
- •3. ИНСТРУМЕНТЫ
- •3.1 Репозиторий метаданных
- •3.2 Средства интеграции данных
- •3.3 Типы инструментов BI
- •4. МЕТОДЫ
- •4.1 Прототипирование с целью уточнения требований
- •4.2 BI по принципу самообслуживания
- •4.3 Открытые для пользователей данные аудита
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •5.1 Оценка готовности / Оценка рисков
- •5.2 Дорожная карта выпуска релизов
- •5.3 Управление конфигурациями
- •5.4 Организационные и культурные изменения
- •6. РУКОВОДСТВО DW/BI
- •6.1 Обеспечение одобрения со стороны бизнеса
- •6.2 Удовлетворенность клиентов/пользователей
- •6.3 Соглашения об уровне обслуживания
- •6.4 Стратегия в области отчетности
- •6.5 Метрики
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 12. Управление метаданными
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Определение стратегии работы с метаданными
- •2.2 Выработка понимания требований к метаданным
- •2.3 Определение архитектуры метаданных
- •2.4 Создание и ведение метаданных
- •2.5 Применение метаданных в аналитике и при формировании запросов и отчетов
- •3. ИНСТРУМЕНТЫ
- •3.1 Инструменты управления репозиторием метаданных
- •4. МЕТОДЫ
- •4.1 Отслеживание происхождения и анализ влияния
- •4.2 Метаданные для обработки больших данных
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •5.1 Оценка готовности / Оценка рисков
- •5.2 Организационные и культурные изменения
- •6. РУКОВОДСТВО МЕТАДАННЫМИ
- •6.1 Механизмы контроля процессов
- •6.2 Документация, описывающая метаданные
- •6.3 Стандарты и руководства
- •6.4 Метрики
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 13. Качество данных
- •1. ВВЕДЕНИЕ
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Определение данных высокого качества
- •2.2 Определение стратегии качества данных
- •2.3 Определение критически важных данных и бизнес-правил
- •2.4 Проведение первичной оценки качества данных
- •2.5 Выявление и приоритизация потенциальных улучшений
- •2.6 Определение целей повышения качества данных
- •2.7 Разработка и внедрение операционных процедур обеспечения качества данных
- •3. ИНСТРУМЕНТЫ
- •3.1 Инструменты профилирования данных
- •3.2 Инструменты формирования запросов к данным
- •3.3 Инструменты моделирования данных и средства ETL
- •3.4 Шаблоны правил качества данных
- •3.5 Репозитории метаданных
- •4. МЕТОДЫ
- •4.1 Превентивные меры
- •4.2 Корректирующие меры
- •4.3 Программные модули проверки и аудита качества
- •4.4 Эффективные метрики качества данных
- •4.5 Статистическое управление процессами
- •4.6 Выявление и анализ корневых причин
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •5.1 Оценка готовности / Оценка рисков
- •5.2 Организационные и культурные изменения
- •6. РУКОВОДСТВО КАЧЕСТВОМ ДАННЫХ
- •6.1 Политика в области качества данных
- •6.2 Метрики
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 14. Большие данные и наука о данных
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Стратегическое планирование потребностей бизнеса в больших данных
- •2.2 Выбор источников данных
- •2.3 Определение источников и загрузка данных
- •2.4 Выработка гипотез и выбор методов
- •2.5 Предварительная интеграция / Cогласование данных для анализа
- •2.6 Исследование данных с помощью моделей
- •2.7 Внедрение и мониторинг
- •3. ИНСТРУМЕНТЫ
- •3.1 Технологии и архитектуры MPP без разделения ресурсов
- •3.2 Базы данных на основе распределенных файловых систем
- •3.3 Алгоритмы «в базе данных»
- •3.4 Облачные хранилища больших данных
- •3.5 Языки статистических вычислений и графических представлений
- •3.6 Средства визуализации данных
- •4. МЕТОДЫ
- •4.1 Аналитическое моделирование
- •4.2 Моделирование больших данных
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •5.1 Согласование со стратегией организации
- •5.2 Оценка готовности / Оценка рисков
- •5.3 Организационные и культурные изменения
- •6. РУКОВОДСТВО В ОБЛАСТИ БОЛЬШИХ ДАННЫХ И НАУКИ О ДАННЫХ
- •6.1 Управление каналами визуализации
- •6.2 Наука о данных и стандарты визуализации
- •6.3 Безопасность данных
- •6.4 Метаданные
- •6.5 Качество данных
- •6.6 Метрики
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 15. Оценка зрелости управления данными
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Планирование работ по оценке
- •2.2 Проведение оценки зрелости
- •2.3 Интерпретация результатов
- •2.4 Создание целевой программы совершенствования управления данными
- •2.5 Проведение повторных оценок зрелости
- •3. ИНСТРУМЕНТЫ
- •4. МЕТОДЫ
- •4.1 Выбор рамочной структуры DMM
- •4.2 Возможность использования рамочной структуры DAMA-DMBOK
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ DMMA
- •5.1 Оценка готовности / Оценка рисков
- •5.2 Организационные и культурные изменения
- •6. РУКОВОДСТВО УПРАВЛЕНИЕМ ЗРЕЛОСТЬЮ
- •6.1 Надзор за процессом DMMA
- •6.2 Метрики
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 16. Организация управления данными и ролевые ожидания
- •1. ВВЕДЕНИЕ
- •2. ВЫРАБОТКА ПОНИМАНИЯ СУЩЕСТВУЮЩЕЙ ОРГАНИЗАЦИОННОЙ СИСТЕМЫ И КУЛЬТУРНЫХ НОРМ
- •3. СТРУКТУРЫ ОРГАНИЗАЦИОННЫХ СИСТЕМ УПРАВЛЕНИЯ ДАННЫМИ
- •3.1 Децентрализованная операционная модель
- •3.2 Сетевая операционная модель
- •3.3 Централизованная операционная модель
- •3.4 Гибридная операционная модель
- •3.5 Федеративная операционная модель
- •3.6 Выбор оптимальной для организации операционной модели
- •3.7 Альтернативные варианты организационной системы и соображения проектирования
- •4. КРИТИЧЕСКИЕ ФАКТОРЫ УСПЕХА
- •4.1 Куратор в высшем руководстве
- •4.3 Упреждающее планирование изменений
- •4.4 Согласование позиций руководства
- •4.5 Прямая и обратная связь
- •4.6 Обеспечение заинтересованности и участия
- •4.7 Ориентировка, инструктаж и подготовка
- •4.8 Мониторинг восприятия и освоения новых методов
- •4.9 Соблюдение руководящих принципов
- •4.10 Эволюции — да! Революции — нет!
- •5. ПОСТРОЕНИЕ ОРГАНИЗАЦИОННОЙ СИСТЕМЫ УПРАВЛЕНИЯ ДАННЫМИ
- •5.1 Выявление действующих участников управления данными
- •5.2 Определение состава участников Координационного комитета
- •5.3 Выявление и анализ заинтересованных сторон
- •5.4 Привлечение заинтересованных сторон
- •6. ВЗАИМОДЕЙСТВИЕ DMO С ДРУГИМИ ОРГАНАМИ УПРАВЛЕНИЯ
- •6.1 Директор по данным
- •6.2 Руководство данными
- •6.3 Управление качеством данных
- •6.4 Корпоративная архитектура
- •6.5 Особенности управления данными, присущие глобальным организациям
- •7. РОЛИ В ОБЛАСТИ УПРАВЛЕНИЯ ДАННЫМИ
- •7.1 Организационные роли
- •7.2 Индивидуальные роли
- •8. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 17. Управление данными и управление организационными изменениями
- •1. ВВЕДЕНИЕ
- •2. ЭМПИРИЧЕСКИЕ ЗАКОНЫ ПРАКТИКИ ИЗМЕНЕНИЙ
- •3. УПРАВЛЯТЬ НЕ ИЗМЕНЕНИЯМИ, А ПРОЦЕССОМ ПЕРЕХОДА
- •4. ВОСЕМЬ ОШИБОК УПРАВЛЕНИЯ ИЗМЕНЕНИЯМИ ПО КОТТЕРУ
- •4.1 Ошибка № 1: самонадеянность
- •4.2 Ошибка № 2: неспособность создать достаточно мощную поддержку сверху
- •4.6 Ошибка № 6: пренебрежение созиданием краткосрочных побед
- •4.7 Ошибка № 7: преждевременное объявление о победе
- •4.8 Ошибка № 8: Пренебрежение закреплением перемен в корпоративной культуре
- •5. ВОСЕМЬ СТАДИЙ ПРОВЕДЕНИЯ КРУПНОЙ РЕФОРМЫ ПО КОТТЕРУ
- •5.1 Выработка всеобщего понимания ситуации и безотлагательности перемен
- •5.2 Руководящая коалиция
- •6. ФОРМУЛА ИЗМЕНЕНИЙ
- •7. ДИФФУЗИЯ ИННОВАЦИЙ И ПОДДЕРЖАНИЕ ИЗМЕНЕНИЙ
- •7.1 Главные трудности на пути распространения инноваций
- •7.2 Ключевые элементы диффузии инноваций
- •7.3 Пять стадий восприятия инновации
- •7.4 Субъективные причины неприятия или отторжения инноваций и изменений
- •8. ОБЕСПЕЧЕНИЕ ПОДДЕРЖКИ ИЗМЕНЕНИЙ
- •8.1 Острота чувства неотложности или неудовлетворенности
- •8.3 Состав руководящей коалиции
- •8.4 Объективность и осязаемость улучшений
- •9. ДОНЕСЕНИЕ ЦЕННОСТИ УПРАВЛЕНИЯ ДАННЫМИ ДО ВСЕОБЩЕГО ПОНИМАНИЯ
- •9.1 Базовые принципы коммуникаций
- •9.2 Оценка информированности и подготовка целевой аудитории
- •9.3 Задействование элементов неформального общения
- •9.4 План коммуникаций
- •9.5 Продолжение осуществления коммуникаций по завершении внедрения программы управления данными
- •10. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Выражение признательности
- •Предметный указатель
- •Именной указатель
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
||
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
|
to |
|
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
||
|
|
w |
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
||
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
|
-x cha |
|
|
|
|
||
Еще один важный бизнес-драйвер интеграции — управление затратами на поддержку. Пе ремещение данных с использованием множества технологий, каждая из которых требует специ фических навыков разработки и обслуживания, способно привести к непомерному росту стои мости поддержки. Внедрение стандартных инструментов позволяет значительно сократить по требности в обслуживании и персонале, а также повысить эффективность поиска и устранения неполадок. Снижение сложности управления интерфейсами обмена данными может сократить затраты на их обслуживание и дать возможность перераспределить ресурсы сопровождения на решение других приоритетных задач организации.
Проведение работ в области DII также помогает организации соблюдать действующие стандарты и регламенты обработки данных. DII-системы корпоративного уровня позволяют повтор но использовать коды, обеспечивающие соответствие требованиям нормативных документов, и упрощают проверку их соблюдения.
1.2 Цели и принципы
Внедрение практик и решений в области интеграции и интероперабельности данных преследует следующие цели:
своевременное предоставление требуемых данных потребителям (как пользователям, так и приложениям) в нужном им формате;
физическая или виртуальная консолидация данных в хабах;
снижение стоимости и сложности решений по управлению данными за счет разработки об щих моделей и интерфейсов;
выявление значимых событий (возможностей и угроз) и автоматический запуск процедур выдачи уведомлений и принятия мер;
поддержка функций BI, аналитики, управления основными данными и обеспечение операци онной эффективности.
Внедряя решения в области DII, организация должна руководствоваться следующими прин ципами.
При проектировании надлежит придерживаться корпоративного подхода, обеспечивающего возможность последующего расширения и масштабирования, но реализацию проводить ите рационно, методом пошагового ввода новых решений в эксплуатацию.
Должны сбалансированно учитываться локальные и корпоративные потребности в данных, а также в поддержке и сопровождении.
Следует обеспечивать ответственность бизнеса за проектирование решений и проведение других работ в области DII. Эксперты со стороны бизнеса должны привлекаться к разработ ке и модификации правил преобразования данных — как постоянно хранимых, так и вир туальных.
Интеграция и интероперабельность данных |
327 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
||
1.3 Основные понятия и концепции
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
||
1.3.1 Извлечение, преобразование и загрузка
В основе любых решений в области интеграции и интероперабельности данных лежит процесс извлечения, преобразования и загрузки (Extract, Transform, and Load, ETL). Вне зависимости от того, выполняются они физически или виртуально, в пакетном режиме или режиме реального времени, эти шаги непременно присутствуют при перемещении данных внутри или между при ложениями и организациями.
В зависимости от требований по интеграции данных процедуры ETL могут выполняться в режиме периодической (пакетной) обработки или обработки по мере доступности новых или об новленных данных (в режиме реального времени или управляемой на основе событий — event driven). Обработка данных о текущих операциях обычно проводится в режиме реального времени или в режиме, близком к реальному времени (near real-time), а данных, требуемых для анализа и отчетности, — по графику, в пакетном режиме.
Требованиями по интеграции также определяется, сохраняются или нет извлеченные и пре образованные данные физически в промежуточных структурах временного хранения (staging structures). Физическое хранение позволяет вести контрольный журнал шагов преобразований и в случае сбоя перезапускать процесс с промежуточной точки. Однако структуры временного хранения требуют дисковой памяти и времени на запись и чтение. Поэтому там, где требуется интеграция данных с минимальным запаздыванием, физического сохранения промежуточных результатов преобразования данных обычно не предусматривается.
1.3.1.1 ИЗВЛЕЧЕНИЕ
Процесс извлечения включает выбор требуемых данных и выгрузку их из источника. Извлечен ные данные сохраняются на дисковый накопитель или в оперативную память. В первом случае временное хранилище может находиться как вместе с хранилищем-источником, так и вместе с целевым хранилищем, или и с тем и с другим.
Если этот процесс выполняется в среде системы, обеспечивающей операционную деятель ность, потребность в ее ресурсах стараются минимизировать, чтобы не обделять ими текущие рабочие процессы. Часто практикуется вариант пакетной обработки сложных запросов на выбор и извлечение обновленных данных из исходного хранилища в период минимальной рабочей на грузки на систему.
1.3.1.2 ПРЕОБРАЗОВАНИЕ
Процесс преобразования переводит выбранные данные в структуру, совместимую с целевым хранилищем. Следует различать случаи преобразования данных при перемещении из исходного хранилища в целевое, копировании из исходного хранилища в несколько целевых, а также ис пользования преобразованных данных для запуска каких-либо процессов без последующего их сохранения.
328 |
Г Л А В А 8 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
||
Примеры преобразований могут включать следующее.
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
||
Изменения формата. Перекодировка данных из одного технического формата в другой — на пример, из EBCDIC в ASCII.
Изменения структуры. Внесение изменений в структуру данных — например, из ненормали зованных в нормализованные записи.
Семантическая конверсия. Преобразование данных для поддержки соответствующего се мантического представления. Пример: в исходном наборе данных допустимые значения атри бута Пол — 0, 1, 2 или 3; в целевом наборе им соответствуют текстовые значения: НЕ ИЗВЕ СТЕН, МУЖСКОЙ, ЖЕНСКИЙ или ДАННЫЕ НЕ ПРЕДОСТАВЛЕНЫ.
Дедупликация. Если правила требуют, чтобы ключевые значения или записи были уникаль ными, осуществляется сканирование целевого набора данных на предмет дублирующихся строк — и они удаляются.
Переупорядочивание. Изменение порядка элементов данных или записей в соответствии с определенным шаблоном.
Преобразование может проводиться в режимах реального времени или пакетной обработки, ре зультаты сохраняются либо физически в области временного хранения, либо виртуально в памя ти до момента готовности данных к стадии загрузки. Данные, полученные в результате стадии преобразования, должны быть готовы к интеграции с данными в целевой структуре.
Справочные
таблицы для мэппинга
|
Процесс |
|
|
|
Процесс |
|
|
|
Процесс |
|
||
|
извлечения |
|
|
|
преобразования |
|
|
|
загрузки |
|
||
|
(E) |
|
|
|
(T) |
|
|
|
(L) |
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Хранилище |
Промежуточное |
Целевое |
исходных |
временное |
хранилище |
данных |
хранилище |
данных |
Рисунок 67. Поток операций процесса ETL
Интеграция и интероперабельность данных |
329 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
||
1.3.1.3 ЗАГРУЗКА
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
||
Завершающий этап процесса ETL — физическое сохранение или представление преобразован ных данных в целевой системе. В зависимости от характера произведенных преобразований, назначения целевой системы и предполагаемого применения данных они могут или требовать дополнительной обработки для интеграции с другими данными, или же быть готовыми к исполь зованию потребителями.
1.3.1.4 ИЗВЛЕЧЕНИЕ, ЗАГРУЗКА, ПРЕОБРАЗОВАНИЕ (ELT)
Если целевая система располагает значительно большими возможностями трансформации, неже ли исходная или промежуточная прикладные системы, порядок процессов может быть изменен на ELT (Extract, Load, and Transform — извлечение, загрузка и преобразование). ELT позволяет выпол нять преобразование данных после загрузки в целевое хранилище или нередко как часть процесса загрузки. ELT также позволяет сохранять в целевой системе копию сырых (raw) данных, если они могут пригодиться в каких-то иных процессах. Такой подход широко распространен в средах обра ботки больших данных, где ELT используется для загрузки озера данных (data lake) (см. главу 14).
Справочные
таблицы
для мэппинга
|
Процесс |
|
|
|
|
Процесс |
|
|
|
Процесс |
|
||
|
извлечения |
|
|
|
|
загрузки |
|
|
|
преобразования |
|
||
|
|
|
|||||||||||
|
(E) |
|
|
|
|
(L) |
|
|
|
(T) |
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Хранилище |
Целевое |
исходных |
хранилище |
данных |
данных |
Рисунок 68. Поток операций процесса ELT
1.3.1.5 МЭППИНГ
Мэппинг (mapping), являясь синонимом преобразования, означает как процесс преобразова ния (lookup matrix) матрицы из исходной структуры в целевую, так и результат этого процесса. Мэппинг определяет источники, откуда извлекаются данные, правила идентификации данных,
330 |
Г Л А В А 8 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
||
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
|
to |
|
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
||
|
|
w |
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
||
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
|
-x cha |
|
|
|
|
||
подлежащих извлечению, целевые хранилища для загрузки и правила идентификации целевых строк, подлежащих замене (если это предполагается), а также правила преобразования или фор мулы вычислений, которые должны быть применены. Многие программные средства интеграции предлагают функции визуализации мэппинга, позволяющие разработчикам использовать графи ческий интерфейс для создания кода, реализующего преобразование.
1.3.2 Задержка
Задержка (latency) — это разница во времени между моментом, когда данные были сгенерирова ны в системе-источнике, и моментом, когда они стали доступны в целевой системе. Различные подходы к обработке данных определяют различную степень задержки. Задержка может быть высокой (при пакетной обработке), низкой (при запуске процедур переноса на основе событий) или очень низкой (при использовании синхронизации в режиме реального времени).
1.3.2.1 ПАКЕТНАЯ ОБРАБОТКА
Основной объем данных перемещается между приложениями или организациями в массивах или файлах, отправка которых выполняется по запросу пользователей либо в автоматическом режиме по запрограммированному графику. Такой вид обмена данными называется пакетным
(batch) или ETL
Пакет может включать либо полный набор данных по состоянию на момент перед отправ кой — например, балансовые ведомости, подготовленные по завершении отчетного периода, — либо выборку, которая отражает только те изменения, которые произошли за период с момента отправки предыдущего пакета, — например, изменения адресов, зарегистрированные за про шедшие сутки. В первом случае передаваемый набор данных называют «снимком» (или снапшо том snapshot), во втором — «дельтой» (delta).
В решениях, использующих пакетную интеграцию данных, обычно предполагается весьма значительная задержка обновления данных в целевой системе. Пакетную обработку полезно ис пользовать для выполнения операций с большими объемами данных за короткий выделенный отрезок времени. В больших хранилищах данных обычно используется именно этот метод даже в тех случаях, когда технически поддерживаются и альтернативные решения с меньшим време нем запаздывания.
Для ускорения обработки и сокращения задержки обновления некоторые интеграционные решения предусматривают обработку микропакетов (micro-batch) с большей частотой: напри мер, каждые пять минут, а не раз в сутки, как в большинстве стандартных решений.
Пакетная интеграция данных широко используется в целях конвертирования, миграции и ар хивирования, а также для обмена информационными массивами с хранилищами и витринами данных. Чем длительнее задержка обновления данных, тем выше риск некорректной работы ис пользующих эти данные приложений. Для минимизации подобных эффектов составляйте распи сание обмена обновлениями между приложениями с периодичностью не реже чем ежесуточно: например, по завершении рабочего дня или в ночное время следом за проведением какой-либо
Интеграция и интероперабельность данных |
331 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
||
специальной обработки данных. Во избежание передачи в корпоративные хранилища данных не полных наборов данных плановые выполнения заданий по их копированию должны быть привя заны к завершению цикла ежедневной, еженедельной или ежемесячной отчетности.
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
||
1.3.2.2 СБОР ДАННЫХ ИЗМЕНЕНИЙ
Сбор данных изменений (Change Data Capture) — метод, позволяющий уменьшить загрузку ка налов связи за счет передачи лишь тех данных, которые были изменены за определенный период. С помощью этого метода осуществляется мониторинг информационных массивов на предмет изменений (добавления, корректировки, удаления) и передача изменений («дельт») в другие мас сивы, приложения и организации — потребители данных. Данные также могут быть помечены в рамках процесса специальными идентификаторами, например флажками или временными мет ками. Сбор данных изменений может осуществляться на основе данных (data-based) или на осно ве журнала (log-based) (см. главу 6).
Известны три метода сбора данных изменений на основе данных.
Система-источник расставляет специальные элементы данных, например временные метки в рамках временного ряда, коды или флажки, которые и служат индикаторами изменений. Процесс извлечения использует правила, основанные на этих элементах, для определения строк, которые следует извлечь.
Процессы системы-источника при внесении изменений в данные добавляют соответствую щие объекты или идентификаторы в специальный список, который потом используется для определения данных, подлежащих извлечению.
Процессы системы-источника после внесения изменений копируют измененные данные в от дельный объект (в рамках выполняемой транзакции), который потом используется в ходе процесса извлечения. Этот объект не обязательно должен создаваться в среде СУБД.
Все три метода используют встроенные возможности приложения-источника, которые могут ока заться слишком затратными в отношении ресурсов и предполагают модификацию приложения.
При сборе данных изменений на основе журнала СУБД создает журнал операций с базой дан ных, который копируется и обрабатывается с целью поиска изменений, переносимых в целевую базу данных. Сложные изменения бывают трудны для переноса. В таких случаях — c целью их временного хранения и обработки — могут использоваться промежуточные структуры, схожие с исходными объектами.
1.3.2.3 РЕЖИМ, БЛИЗКИЙ К РЕАЛЬНОМУ ВРЕМЕНИ, И УПРАВЛЕНИЕ НА ОСНОВЕ СОБЫТИЙ
В большинстве решений по интеграции данных, не использующих пакетную обработку, реали зована обработка в режиме, близком к реальному времени, или управляемая на основе событий. Данные обрабатываются небольшими порциями в течение суток — либо по заданному распи санию, либо после того, как происходит событие, приводящее к изменению данных, например
332 |
Г Л А В А 8 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
||
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
|
to |
|
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
||
|
|
w |
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
||
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
|
-x cha |
|
|
|
|
||
обновление. Обработка в режиме, близком к реальному времени, осуществляется с меньшей за держкой по сравнению с пакетным режимом и часто снижает рабочую нагрузку на систему (поскольку работа распределена во времени), однако уступает по скорости решениям с синхрони зованной интеграцией данных. Решения, работающие в режиме, близком к реальному времени, обычно реализуются на базе корпоративной сервисной шины.
Информация о состоянии и зависимость между процессами должны отслеживаться процес сом загрузки приложения — получателя данных. В частности, для получения корректного резуль тата может потребоваться загрузка данных в строго определенном порядке. Например, сначала загружаются основные данные или данные измерений, и лишь после этого можно переходить к обработке транзакционных данных, которые их используют.
1.3.2.4 АСИНХРОННАЯ ОБРАБОТКА
В случае асинхронных потоков данных система-источник продолжает обработку данных, не до жидаясь подтверждения получения обновления от принимающей системы. Рассинхронизация подразумевает, что одна из двух систем (передающая или принимающая данные) может работать в автономном режиме, в то время как другая будет подключена к сети.
Асинхронная интеграция данных не препятствует продолжению выполнения процессов при ложения-источника, а также не делает его недоступным, если недоступны какие-либо из прило жений-получателей. Поскольку при асинхронной конфигурации обновления данных в целевых приложениях производятся с запаздыванием, такой тип интеграции называется интеграцией в режиме, близком к реальному времени. Задержка между обновлением данных в источнике и от ражением изменений в целевых наборах данных для такого режима обычно составляет от не скольких секунд до нескольких минут.
1.3.2.5 ОБРАБОТКА В РЕЖИМЕ РЕАЛЬНОГО ВРЕМЕНИ, СИНХРОННАЯ
В некоторых ситуациях недопустима даже малейшая рассогласованность между исходным и це левым наборами данных. В таких случаях обязательно использование решений, обеспечивающих синхронизацию данных в режиме реального времени.
В синхронных интеграционных решениях выполняющийся процесс дожидается под тверждения обновления от всех приложений или процессов-адресатов, прежде чем перейти к осуществлению следующей операции или к обработке очередной транзакции. Это означает, что решение может обработать меньше транзакций из-за простоев, вызванных ожиданием получения всех требуемых подтверждений синхронизации. Если хотя бы одно из приложений, требующих обновления данных, недоступно, приложение-источник не может завершить тран закцию. В такой ситуации данные остаются синхронизованными, но существует опасность за висимости стратегически важных приложений от второстепенных приложений с низкой сте пенью критичности.
Решения, использующие подобную архитектуру, требуют оценки того, насколько эко номически оправданным является использование дорогостоящих технических решений,
Интеграция и интероперабельность данных |
333 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
||
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
|
to |
|
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
||
|
|
w |
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
||
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
|
-x cha |
|
|
|
|
||
обеспечивающих минимальную разницу между синхронизируемыми в реальном времени набо рами данных. Синхронизацию вполне можно обеспечить средствами СУБД — например, с помо щью механизма двухфазного подтверждения транзакции, гарантирующего: либо все изменения данных в рамках бизнес-транзакции проведены успешно, либо не проведено ни одно из них. На пример, в финансовых учреждениях двухфазное подтверждение транзакций используется для того, чтобы обеспечить полную синхронизацию таблиц с данными транзакций и таблиц с балан совыми данными. При этом в большинстве прикладных программ двухфазное подтверждение не применяется. Как следствие, сохраняется небольшой риск того, что в результате неожиданного прерывания приложения один набор данных обновится, а другие — нет.
Будучи затратными по ресурсам, решения, обеспечивающие синхронизацию в режиме реаль ного времени, требуют меньше внимания к управлению состоянием баз данных, чем асинхрон ные решения, поскольку порядок обработки транзакций четко контролируется приложениями, которые обновляют данные. Однако работа в таком режиме может привести к блокировке и за держке других транзакций.
1.3.2.6 ОБРАБОТКА С НИЗКОЙ ЗАДЕРЖКОЙ ИЛИ ПОТОКОВАЯ ОБРАБОТКА
Сегодня достигнуты огромные успехи в сфере разработки решений, которые обеспечивают сверхбыструю интеграцию данных. Однако их реализация сопряжена с серьезными затратами на аппаратное и программное обеспечение. Использование столь дорогостоящих решений бывает оправданным в тех случаях, когда организации требуется сверхскоростная передача данных на большие расстояния. Потоковые данные (streaming data) «вытекают» из компьютерных систем
внепрерывном режиме по ходу событий. Потоки данных фиксируют такую информацию о собы тиях, как сведения о покупках товаров или ценных бумаг, комментарии в соцсетях или показания датчиков, отслеживающих координаты местоположения, а также значения температуры, нагруз ки и прочих характеристик.
Решения, обеспечивающие интеграцию данных с низкой задержкой, разрабатываются для поддержания максимально быстрого отклика на события. В них часто задействуются аппаратные (например, твердотельные диски) или программные (например, БД в оперативной памяти) сред ства хранения данных, избавляющие от потерь времени на запись или считывание с традицион ных жестких дисков. Обработка данных в оперативной памяти или на SSD-накопителе требует
втысячи раз меньше времени, чем операции обращения к жесткому диску.
Решения с низкой задержкой обычно используют асинхронный обмен данными, при котором транзакциям не требуется ждать подтверждения от последующих процессов, перед тем как на чать обрабатывать следующую порцию данных.
Обычно в решениях с низкой задержкой используются мощные мультипроцессорные си стемы или конфигурации с параллельной обработкой данных, обеспечивающие распределение операций по обработке входных данных по множеству процессоров, поскольку производитель ности, достигаемой на малом количестве процессоров, для решения практических задач оказы вается недостаточно.
334 |
Г Л А В А 8 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
||
1.3.3 Репликация
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
||
Некоторые приложения обеспечивают малое время отклика на обращения пользователей со всех уголков мира за счет ведения идентичных копий наборов данных во многих географически раз несенных местах. Решения с использованием репликации позволяют минимизировать влияние операций по анализу и сложных запросов на производительность среды, обеспечивающей в пер вую очередь обработку транзакций.
Такие решения предполагают синхронизацию физически распределенных копий наборов дан ных. Большинство СУБД имеют для этого специальные утилиты, обеспечивающие репликацию. Для эффективной работы таких утилит желательно, чтобы все базы данных находились под управлением СУБД, реализованных на одной технологии. Репликационные решения обычно осущест вляют мониторинг журнала изменений набора данных, а не сам набор данных. Они оказывают минимальное влияние на работу операционных приложений, поскольку не конкурируют с ними за доступ к набору данных. Обмен данными между копиями сводится лишь к передаче данных из журнала изменений. Стандартные репликационные решения обеспечивают обмен обновлениями в режиме, близком к реальному времени: задержка между проведением изменений в одном экзем пляре набора данных и проведением этих же изменений в других экземплярах минимальна.
Преимущества репликации — минимум влияния на исходный набор данных и минимум пе редаваемой информации — делают такие решения крайне привлекательными, и поэтому они ча сто используются для интеграции даже таких наборов данных, которые не удалены друг от друга на большие расстояния. Утилиты СУБД не требуют большого объема программирования, поэто му количество программных ошибок обычно невелико.
Репликационные утилиты работают оптимально, когда исходные и целевые наборы данных являются точными копиями друг друга. Если же набор-источник и целевой набор различаются, то синхронизация подвержена риску. Если исходный и целевой наборы данных не являются точ ными копиями, необходимо организовать промежуточную область для размещения и ведения точной копии набора — источника данных. Это требует дополнительного дискового простран ства и, возможно, применения дополнительных технологий баз данных.
Решения, основанные на репликации, не являются оптимальными в ситуациях, когда требу ется синхронизировать многочисленные наборы данных, в каждый из которых могут вноситься изменения. Если есть вероятность, что в разные экземпляры набора данных могут быть одно временно внесены изменения в одной и той же его части, то существует риск рассинхронизации данных. В измененную часть одного из экземпляров могут быть без предупреждения записаны изменения, внесенные в другой экземпляр. Изменения, внесенные в первый экземпляр, при этом пропадут (см. главу 6).
1.3.4 Архивирование
Данные, используемые нечасто или малоактивно, можно перенести в альтернативную структу ру или на устройство хранения, которое требует от организации меньших затрат. Для переноса данных в архив (возможно, с преобразованием) обычно используются функции ETL. Переносу
Интеграция и интероперабельность данных |
335 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
||
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
|
to |
|
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
||
|
|
w |
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
||
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
|
-x cha |
|
|
|
|
||
в архив подлежат данные приложений, выводимых из эксплуатации, а также данные действую щих систем среды эксплуатации, не использовавшиеся на протяжении длительного времени, по скольку это будет способствовать повышению операционной эффективности.
Критически важно следить за работоспособностью технологий архивирования и, в частно сти, контролировать совместимость новых технологий со старыми архивами, чтобы данные в них оставались доступными и после внедрения технологических изменений. Если новое приложение для работы с архивами не поддерживает старые форматы, это может быть сопряжено с рисками, особенно если не истек установленный законом обязательный срок хранения архивных данных (см. главу 9).
1.3.5 Корпоративный формат сообщений / Каноническая модель
Каноническая модель данных — общая модель (используемая организацией или группой, отвечаю щей за обмен данными), стандартизирующая формат, в котором осуществляется распространение данных. Она нужна, в частности, при использовании звездообразной схемы обмена данными с ин теграцией в центре (hub-and-spoke), когда системы общаются друг с другом исключительно через центральный информационный хаб. Все передаваемые данные преобразуются в общий формат сообщений, принятый в организации (каноническую модель) (см. главу 5). Использование кано нической модели ограничивает количество преобразований данных при обмене между система ми или организациями. Каждой системе достаточно реализовать преобразование данных только в каноническую модель (при передаче) или из нее (при приеме), вместо того чтобы разрабатывать отдельные средства преобразования для множества систем, с которыми осуществляется обмен.
Хотя разработка и согласование единого унифицированного формата сообщений — задача ответственная и трудоемкая, внедрение канонической модели значительно уменьшает сложность решений по обеспечению интероперабельности данных организации и тем самым существенно сокращает затраты на их поддержку. При этом следует учитывать, что создание и сопровождение канонической модели, распространяющейся на все случаи обмена данными между системами ор ганизации, предполагает проведение комплекса затратных мероприятий по реализации и под держке информационного взаимодействия по звездообразной схеме. Эти усилия можно считать оправданными лишь при необходимости обеспечения взаимодействия более трех разнородных систем. В средах, где обмениваются данными более ста прикладных систем, интеграционное ре шение на основе канонической модели является единственно возможным и незаменимым.
1.3.6 Модели взаимодействия
Модели взаимодействия описывают способы обеспечения связи между системами с целью обме на данными.
1.3.6.1 МОДЕЛЬ «ТОЧКА-ТОЧКА»
В большинстве случаев взаимодействие между системами происходит в режиме прямого обмена данными по схеме «точка-точка» (point-to-point). При небольшом количестве систем это вполне
336 |
Г Л А В А 8 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
||
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
|
to |
|
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
||
|
|
w |
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
||
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
|
-x cha |
|
|
|
|
||
рациональный подход. Однако по мере роста числа систем, обращающихся к одним и тем же источникам данных, он становится неэффективным и рискованным для организации.
Влияние на обработку данных при выполнении операций. Если системы-источники об служивают операционную деятельность, то выполнение внешних запросов отнимает ресурсы и, в целом, замедляет обработку данных при выполнении операций.
Управление интерфейсами. Количество интерфейсов обмена данными, необходимых для реализации модели «точка-точка», приблизительно равно квадрату числа систем, участвую щих в обмене (s2, где s — число систем). И все эти интерфейсы нужно сначала создать, а затем обслуживать и поддерживать. С ростом количества систем трудозатраты на эту деятельность быстро превышают трудозатраты на обслуживание и поддержку самих систем.
Возможное рассогласование данных. Проблемы такого рода возникают, когда различные си стемы используют одни и те же данные в различных вариантах представления или форматах. Использование множества интерфейсов приводит к возникновению противоречий в данных, которые тиражируются во все системы, участвующие в их обработке.
1.3.6.2 ЗВЕЗДООБРАЗНАЯ МОДЕЛЬ С ИНТЕГРАЦИЕЙ В ЦЕНТРЕ
Звездообразная модель с интеграцией в центре (hub-and-spoke) является альтернативой модели «точка-точка». Она позволяет консолидировать (физически или виртуально) данные совместно го использования в центральном хабе данных, к которому обращаются все приложения. То есть их взаимодействие друг с другом по протоколам «точка-точка» заменяется обращением к общей центральной системе, контролирующей данные. Хорошо известными примерами хабов данных являются хранилища данных (Data Warehouses), витрины данных (Data Marts), хранилища опера ционных данных (Operational Data Stores) и хабы для управления основными данными.
Центральные хабы обеспечивают единообразное и согласованное представление данных при ограниченном влиянии на производительность поставляющих их систем. Они минимизируют количество систем и операций извлечения, требующих доступа к исходным данным, миними зируя таким образом влияние на ресурсы систем-источников. Добавление в состав информаци онных систем предприятия нового приложения требует построения всего лишь одного интер фейса — обеспечивающего взаимодействие с хабом данных. Звездообразная модель становится эффективнее и дешевле модели «точка-точка» уже при относительно небольшом числе систем, а когда их счет идет на сотни и тысячи, централизация становится неизбежной.
Корпоративные сервисные шины (Enterprise Service Buses, ESB) — интеграционные реше ния, которые обеспечивают синхронизацию данных в режиме, близком к реальному времени, между многими системами. Такие решения используют понятие хаба данных, предоставляю щего стандартный формат или каноническую модель для совместного использования данных организацией.
Звездообразные модели не всегда оптимальны. Иногда они неприемлемы из-за слишком длительной задержки, иногда — из-за недостаточной производительности. Использование
Интеграция и интероперабельность данных |
337 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
||
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
|
to |
|
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
||
|
|
w |
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
||
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
|
-x cha |
|
|
|
|
||
в звездообразной архитектуре центрального хаба влечет слишком высокие накладные расходы, и при небольшом количестве систем предпочтительнее обойтись взаимодействием «точка точка». Однако преимущества хаба чаще всего перевешивают недостатки, когда требуется оперативный обмен данными между тремя и более системами. Кроме того, применение при реализации об мена данными шаблона проектирования, соответствующего звездообразной модели, уменьшает распространение и снижает количество отдельных специфических трансформаций и интегра ционных решений. Организационная поддержка деятельности по интеграции данных при этом сильно упрощается.
1.3.6.3 МОДЕЛЬ «ПУБЛИКАЦИЯ-ПОДПИСКА»
Модель публикации и подписки (publish and subscribe) предусматривает наличие систем, постав ляющих данные («издателей»), и систем, получающих эти данные («подписчиков»). Системы, по ставляющие данные, вносятся в каталог сервисов данных, а системы, которым эти данные требу ются, должны подписываться на услуги провайдера. После публикации данные автоматически рассылаются подписчикам.
При наличии множества потребителей одних и тех же наборов данных или данных в одном и том же формате подготовка этих данных (с последующим открытием доступа к ним) в цен трализованном порядке позволяет обеспечивать использование потребителями согласованных наборов данных и их регулярное своевременное обновление.
1.3.7 Понятия и концепции, используемые в архитектуре DII
1.3.7.1 СВЯЗЫВАНИЕ ПРИЛОЖЕНИЙ
Связывание (сoupling) описывает, насколько тесно две системы «переплетены» между собой. Сильно связанные (tightly coupled) системы обычно имеют синхронизованный интерфейс: то есть, отправив запрос другой системе, первая приостанавливает обработку данных до получе ния требуемого ответа. Сильная увязка рискованна: если одна система оказывается недоступной, то фактически недоступны будут обе системы, — и план обеспечения непрерывности бизнеса (business continuity plan) в отношении этих двух систем должен быть общим (см. главу 6).
Слабое связывание (loose coupling) — более предпочтительный подход к проектированию ин терфейса (там, где это возможно). При таком подходе получение ответов на запросы, обращен ные к другой системе, не является обязательным условием продолжения работы первой системы, то есть доступность каждой из слабо связанных систем не зависит от доступности другой систе мы. Слабое связывание может быть реализовано с использованием различных средств: напри мер, посредством сервисов, интерфейсов прикладного программирования (API) или очередей сообщений (см. рис. 69).
Примером шаблона проектирования для слабо связанного информационного взаимодей ствия служит сервис-ориентированная архитектура (Service-Oriented Architecture, SOA), использующая корпоративную сервисную шину.
338 |
Г Л А В А 8 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
||
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
|
to |
|
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
||
|
|
w |
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
||
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
|
-x cha |
|
|
|
|
||
Процесс A 
Процесс B
Сильное связывание
API |
|
|
Сервис |
|
|
|
API |
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
Процесс A |
|
|
|
Процесс B |
|
|
|
|
|
|
|
|
Слабое связывание
Рисунок 69. Варианты связывания приложений
Когда системы слабо связаны, замена любой из них на альтернативную теоретически даже не потребует переделки остальных систем, с которыми она взаимодействует, поскольку все точки взаимодействия четко определены.
1.3.7.3 ИНТЕГРАЦИЯ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ (EAI)
В модели интеграции корпоративных приложений (Enterprise Application Integration, EAI) про граммные модули взаимодействуют друг с другом только посредством точно определенных вызо вов функций интерфейса прикладного программирования (API). Хранилища данных используют для проведения обновлений только свои собственные программные модули, а другие программ ные средства могут получить доступ к данным хранилищ, только используя их API.
Модель EAI построена на основе объектно-ориентированного подхода, который акцентирует внимание на повторном использовании и возможности замены любого модуля без оказания ка кого-либо влияния на работу других модулей.
1.3.7.4 КОРПОРАТИВНАЯ СЕРВИСНАЯ ШИНА (ESB)
Корпоративная сервисная шина (ESB) представляет собой специальную систему, которая выпол няет функции посредника между прикладными системами, передавая сообщения от одной систе мы к другой. Приложения могут отправлять и получать сообщения или файлы, используя ESB; при этом они изолированы от других ее процессов. ESB является примером реализации подхода к построению интеграционных решений, основанного на слабом связывании. Она действует как сервис обмена данными между приложениями (см. рис. 70).
Интеграция и интероперабельность данных |
339 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
||
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
|
to |
|
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
||
|
|
w |
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
||
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
|
-x cha |
|
|
|
|
||
Менеджер Приложение 1 оркестровки Приложение 2
процессов
Корпоративная сервисная шина (ESB)
|
Приложение n |
|
|
|
Сервис n |
|
|
Сервис 1 |
|
|
|
|
|
|
|
|
|
|
|
Рисунок 70. Корпоративная сервисная шина (ESB)
1.3.7.5 СЕРВИС-ОРИЕНТИРОВАННАЯ АРХИТЕКТУРА (SOA)
Наиболее зрелые корпоративные стратегии интеграции приложений используют концепцию сервис-ориентированной архитектуры (SOA), в которой функциональность по предоставлению или обновлению данных (или другие сервисы данных) может быть представлена в виде точно определенных вызовов сервисов, используемых приложениями в процессе их взаимодействия. При таком подходе приложениям не нужно ни взаимодействовать друг с другом напрямую, ни знать что-либо о внутренней структуре и работе других приложений. SOA обеспечивает незави симость приложений и возможность замены той или иной системы в организации без необходи мости внесения существенных изменений в системы, которые с ней взаимодействуют.
Цель сервис-ориентированной архитектуры — организация строго определенного взаи модействия между отдельными независимыми программными модулями. Каждый модуль выполняет функции (часто говорят «предоставляет сервисы») в интересах других программ ных модулей или людей. Ключевым концептуальным моментом SOA является то, что предо ставляемые сервисы независимы: сервис не знает ровным счетом ничего об обращающемся к нему приложении, равно как для приложения реализация сервиса является «черным ящи ком». Сервис-ориентированная архитектура может быть реализована с помощью различных технологий, включая веб-сервисы, обмен сообщениями, RESTful API1, и т. п. Сами сервисы обычно реализуются как интерфейсы прикладного программирования (API), доступные для
1 REST (сокр. от англ. Representational State Transfer — передача состояния представления) — набор архитектурных принципов построения сервис-ориентированных приложений. RESTful — прилагательное, употребляющееся по отно шению к сервисам, которые соответствуют принципам REST. — Примеч. науч. ред
340 |
Г Л А В А 8 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
||
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
|
to |
|
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
||
|
|
w |
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
||
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
|
-x cha |
|
|
|
|
||
вызова прикладным системам или пользователям (потребителям). Регистрационная запись точно определенного API описывает доступные опции, необходимые параметры запроса и вы даваемую в ответ на обращение информацию.
Сервисы данных, обеспечивающие обработку запросов на добавление, удаление, обновление или выборку данных, регистрируются в каталоге доступных сервисов. Для достижения корпора тивных целей в части обеспечения масштабируемости информационных систем (поддержка ин теграции всех приложений организации без необоснованно высоких затрат ресурсов) и повтор ного использования (использования одних и тех же сервисов для работы с конкретным видом данных всеми потребителями данных этого вида) требуется внедрение строгой и четкой модели руководства, охватывающей разработку и регистрацию сервисов и API. Прежде чем разрабаты вать новый сервис данных, необходимо убедиться, что для обработки предполагаемых запросов нельзя использовать какой-то из уже имеющихся сервисов. Кроме того, всякий новый сервис дол жен разрабатываться с учетом как можно более широкого круга требований, чтобы помимо ре шения текущей задачи он мог впоследствии многократно использоваться и для решения других похожих задач.
1.3.7.6 ОБРАБОТКА СЛОЖНЫХ СОБЫТИЙ (CEP)
Обработкой событий (event processing) называют метод отслеживания и анализа (обработки) по токов информации (данных) о происходящем (событиях) с целью формирования заключений. Обработка сложных событий (Complex Event Processing, CEP) предполагает объединение данных из множества источников для выявления значимых событий (например, угроз или возможно стей) с целью прогнозирования поведения наблюдаемых объектов и автоматического реагиро вания в режиме реального времени (примером такой реакции является предложение потенци альным покупателям подходящих товаров). Для управления обработкой событий и определения последовательности действий задаются правила.
Организации могут использовать довольно сложные модели и алгоритмы обработки событий с целью прогнозирования поведения и/или развития событий и автоматического запуска упреждающих, встречных или ответных действий в режиме реального времени. События (например, выявление потенциальных клиентов, переходы по ссылкам, заказы, обращения в службу клиент ской поддержки и т. д.) могут происходить в рамках организации на различных ее уровнях. Кроме того, потоки событий могут включать новостные сообщения, текстовые уведомления, сообщения в соцсетях, данные с лент биржевых котировок, информацию о пробках на дорогах, прогнозы погоды и т. д. Событие может быть определено и как изменение состояния объекта наблюдения: например, по достижении заданного порогового значения времени, температуры или какой-либо иной измеримой характеристики.
Реализация технологий CEP сопряжена с некоторыми трудностями в части сбора данных. Во многих случаях частота событий такова, что нереалистично рассчитывать на возможность получения дополнительных данных, требующихся для их оперативной интерпретации. Следо вательно, для эффективной динамической обработки потоков входных данных обязательно
Интеграция и интероперабельность данных |
341 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
||
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
|
to |
|
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
||
|
|
w |
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
||
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
|
-x cha |
|
|
|
|
||
наличие в памяти приложения, реализующего CEP, шаблонных заготовок блоков данных, соот ветствующих пусковым событиям различных типов.
Поддержка CEP предполагает наличие среды, которая позволяла бы интегрировать массу раз нородных данных. Из-за колоссальных объемов и структурного разнообразия данных, обычно используемых для прогнозирования, обработка сложных событий часто бывает тесно связана с областью больших данных. Во многих случаях она требует применения технологий, обеспечи вающих сверхмалую задержку, — например, обработки входящих потоков данных в режиме ре ального времени или баз данных в оперативной памяти (см. главу 14).
1.3.7.7 ФЕДЕРАЛИЗАЦИЯ И ВИРТУАЛИЗАЦИЯ ДАННЫХ
Данные из разрозненных хранилищ могут сводиться воедино и обобщаться и без физической интеграции. Федерализация заключается в обеспечении доступа к объединению отдельных хра нилищ данных, которые могут иметь различную структуру. Виртуализация обеспечивает под держку распределенных баз данных, а также возможность доступа к множеству хранилищ разно родных данных как к единой базе данных (см. главу 6).
1.3.7.8 ДАННЫЕ КАК УСЛУГА (DAAS)
Программное обеспечение как услуга (Software-as-a-Service, SaaS) — модель поставки и лицензи рования ПО, в рамках которой приложения предоставляют сервисы, но сами они и данные фи зически находятся в ЦОДах поставщика ПО, а не приобретающей лицензию организации. Ана логичные концепции теперь используются при предоставлении доступа к различным уровням информационно-вычислительной инфраструктуры в порядке абонентского обслуживания (ИТ как услуга, платформы как услуга, базы данных как услуга и т. п.).
В частности, понятие «данные как услуга» (Data-as-a-Service, DaaS) используется для описа ния ситуации, когда поставщик предоставляет организации, купившей лицензию, данные по за просам, что избавляет последнюю от необходимости хранить и вести эти данные в собственном ЦОДе. Распространенный пример — информация о ценных бумагах и их котировках (текущих и исторических), которая предлагается к продаже фондовыми биржами.
Хотя в прямом смысле данные как услуга подразумевают лишь предоставление платного до ступа к данным различным клиентам в соответствующей отрасли, в последнее время понятие «услуга» стало всё чаще использоваться внутри организаций применительно к предоставлению доступа к корпоративным данным или сервисам данных различным функциям и системам, под держивающим операционную деятельность. Сервисные организации публикуют каталоги пред лагаемых услуг, информацию об уровнях обслуживания, расценки и т. п.
1.3.7.9 ИНТЕГРАЦИЯ НА ОСНОВЕ ОБЛАКА
Интеграция на основе облака (сloud-based integration), также известная под названием «инте грационная платформа как услуга» (Integration Platform-as-a-Service, IPaaS), — это форма ин теграции систем, предоставляемая как облачный сервис, реализующий различные варианты
342 |
Г Л А В А 8 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
||
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
|
to |
|
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
||
|
|
w |
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
||
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
|
-x cha |
|
|
|
|
||
использования (use cases) данных, процессов, сервис-ориентированной архитектуры (SOA) и интеграции приложений.
До появления облачных вычислений интеграцию можно было четко разделить на внутрен нюю (internal) и интеграцию «бизнес для бизнеса» (Business-to-Business, B2B). Внутренняя инте грация реализуется посредством развернутой на предприятии программной платформы проме жуточного слоя (middleware platform), — как правило, с использованием корпоративной сервис ной шины (ESB), обеспечивающей управление обменом данными между системами. Интеграция B2B осуществляется с помощью шлюзов EDI (Electronic Data Interchange — электронный обмен данными), а также сетей с дополнительными услугами (сетей с «добавленной стоимостью» — Value-Added Networks, VAN) или электронных торговых площадок.
С приходом SaaS-приложений сформировался спрос на интеграцию данных, которые физи чески находятся за пределами ЦОДа организации. Их объединение обеспечивается с помощью интеграции на основе облака. После появления решений такого типа многие из них были до работаны с целью использования для интеграции локальных приложений, функционирующих в организациях, а также в качестве шлюзов EDI.
Интеграционные решения на основе облака обычно реализуются как SaaS-приложения и раз вертываются в ЦОДах поставщиков услуг, а не организаций — владельцев данных, которые под лежат интеграции. Интеграция на основе облака включает взаимодействие с SaaS-приложениями с целью объединения данных с использованием SOA-сервисов (см. главу 6).
1.3.8 Стандарты обмена данными
Стандарты обмена данными задают формальные правила для определения структуры элементов данных. Стандарты такого рода разрабатываются как Международной организацией по стандар тизации (ISO), так и во многих отраслях. Спецификация обмена данными — это общая модель (используемая организацией или группой, отвечающей за обмен данными), стандартизирующая формат, в котором осуществляется распространение данных. Шаблон, применяемый для обмена, определяет структуру, в которую должна преобразовать данные каждая из взаимодействующих ор ганизаций. Необходимо осуществить мэппинг данных в соответствии со спецификацией обмена.
Хотя разработка и согласование единого для всех участников информационного взаимодей ствия формата сообщений — задача трудоемкая, но, обеспечив единообразие структуры обмена, мы значительно упрощаем обеспечение интероперабельности данных в организации, снижаем затраты на ее поддержку и предоставляем возможности для лучшего понимания данных.
В США для обмена документами и транзакционными данными между правительственными учреждениями разработана Национальная модель обмена информацией (National Information Exchange Model, NIEM). Цель ее создания — обеспечение общего однозначного понимания смыс ла данных отправителем и получателем. Соблюдение требований NIEM гарантирует четкую и не допускающую вольной трактовки интерпретацию базового набора сведений, что обеспечивает единообразие восприятия данных самыми различными сообществами и, следовательно, интер операбельность.
Интеграция и интероперабельность данных |
343 |