Виртуальные хранилища данных доклад

Обновлено: 28.04.2024

По Вашему запросу ничего не найдено.

Рекомендуем сделать следующее:

  • Проверьте правильность написания ключевых слов.
  • Используйте синонимы введенных Вами ключевых слов, например “приложение” вместо “программное обеспечение”.
  • Попробуйте воспользоваться одним из популярных поисковых запросов ниже.
  • Начните новый поиск.

Темы в этом разделе

Хранилище данных — определение

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

Обычно хранилище данных включает в себя следующие компоненты:

    для хранения данных и управления ими;
  • решение для извлечения, загрузки и преобразования данных, которое служит для подготовки данных к анализу;
  • средства статистического анализа, отчетности и глубинного анализа данных;
  • инструменты анализа для визуализации данных и их представления для корпоративных пользователей;
  • Другие, более сложные аналитические приложения, которые генерируют полезную информацию по алгоритмам исследования данных и деятельности искусственного интеллекта (ИИ)

Преимущества хранилища данных

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

Эти уникальные преимущества доступны благодаря четырем отличительным особенностям хранилищ данных, которые описал специалист по вычислительным системам Уильям Инмон (William Inmon). Согласно данному им определению, хранилища данных имеют следующие характеристики.

  • Субъектно-ориентированность. Хранилища можно использовать для анализа данных, которые относятся к одной теме или функциональной области (например, продажи).
  • Единообразие. Хранилища данных обеспечивают целостность данных различных типов, полученных из разных источников.
  • Неизменность. Элементы данных, помещенные в хранилище данных, не подвергаются изменениям.
  • Изменения во времени. Анализ данных, помещенных в хранилище данных, предназначен для выявления изменений в закономерностях, возникающих со временем.

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

Архитектура хранилища данных

Архитектура хранилища данных зависит от потребностей компании. Наиболее распространенными типами архитектур являются следующие.

Эволюция хранилища данных — от анализа данных к ИИ и машинному обучению

Первые хранилища данных появились в конце 1980-х гг., и их задачей было обеспечить обмен данными между операционными БД (БД для поддержки бизнеса) и системами поддержки принятия решения (СППР). Первым хранилищам данных требовалось много копий. Большинство компаний использовали несколько СППР для различных потребностей. Хотя эти СППР обычно использовали одни и те же данные, процессы сбора, очистки и интеграции выполнялись для каждой из них по отдельности.

Эволюция хранилищ данных сделала их важным инструментом для постепенного наращивания бизнес-ценности для предприятия.

Этап Возможности Бизнес-преимущество
1 Транзакционная отчетность Обеспечивает реляционные сведения для создания моментальных снимков бизнес-эффективности
2 Продольные и поперечные срезы данных, специальные запросы, инструменты бизнес-аналитики Расширяет возможности для углубленного и более эффективного анализа
3 Прогнозирование эффективности в будущем (глубинный анализ данных) Обеспечивает визуализации данных и бизнес-аналитические прогнозы
4 Тактический анализ (пространственный анализ, статистика) Обеспечивает “альтернативные” сценарии для принятия решений на основе комплексного анализа
5 Хранит данные за несколько месяцев или лет Хранит данные за несколько недель или месяцев

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

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

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

Хранилища данных, витрины данных и хранилища операционных данных

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

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

Что такое облачное хранилище данных?

Облачное хранилище данных использует облако для получения и хранения данных из разрозненных источников.

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

С другой стороны, облачные хранилища данных отличаются следующими преимуществами.

  • Гибкость с разделением вычислительных ресурсов и ресурсов хранилища
  • Возможности масштабирования для потребностей в вычислении и хранении
  • Простое применение
  • Простое управление
  • Сокращение затрат

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

Что такое современное хранилище данных?

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

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

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

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

Проектирование хранилища данных

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

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

  • Специфика содержания (данные)
  • Взаимосвязи внутри групп данных и между ними
  • Системные среды обеспечения хранилища данных
  • Необходимые типы преобразования данных
  • Частота обновления данных

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

Облачные хранилища и хранилища данных

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

Зачем нужно озеро данных?

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

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

Почему среда OLTP не подходит для аналитики данных?

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

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

Хранилища данных и системы OLTP значительно отличаются друг от друга.

Хранилище данных Система OLTP
Рабочая нагрузка Поддерживает специализированные запросы и анализ данных Поддерживает только предварительно заданные операции
Изменения данных Регулярно выполняются автоматические обновления Обновления выполняют конечные пользователи с помощью специальных команд
Дизайн схемы Использует частично денормализованные схемы для улучшения эффективности Использует полностью нормализованные схемы для обеспечения целостности данных
Сканирование данных Включает от нескольких тысяч до миллионов строк Обеспечивает одновременный доступ только к нескольким записям
Исторические данные Хранит данные за несколько месяцев или лет Хранит данные за несколько недель или месяцев

Беспроблемное развертывание. Autonomous Data Warehouse

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

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

Oracle Autonomous Data Warehouse

Oracle Autonomous Data Warehouse — простое в использовании, полностью автоматизированное хранилище данных, которое обеспечивает эластичную масштабируемость, быстрое выполнение запросов и не требует администрирования. Настройка Oracle Autonomous Data Warehouse не требует много времени и усилий.

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

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

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

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


Рис. 3. Виртуальные хранилища данных

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

Появился новый источник данных? Все замечательно. Мы перепишем все наши программы с учетом особенностей этого источника.

Изменился формат данных? Прекрасно. Мы перепишем все наши программы с учетом нового формата.

Все хорошо, все при деле, надо расширять отдел программирования.

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

Может, все же есть выгода от такой архитектуры?

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

Независимые витрины данных.

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

  • Для транзакционной обработки характерно большое количество чтений и записей в базу данных. Аналитическая обработка может потребовать всего несколько обращений к БД.
  • Длина записей в OLTP обычно не превышает 1000 символов. Аналитический запрос может потребовать мегабайты данных за одно обращение для анализа.
  • Количество пользователей транзакционной системы может достигать несколько тысяч человек. Число аналитиков обычно в пределах нескольких десятков.
  • Характерными требованиями для транзакционных систем является круглосуточная бесперебойная работа 365 дней в году (24 х 365). Аналитическая обработка не выдвигает столь четко сформулированных требований к готовности аналитических комплексов, но не подготовленная в срок отчетность может привести к серьезным неприятностям, как для аналитиков, так и для предприятия.
  • Нагрузка на транзакционные системы распределяется более или менее равномерно во времени. Нагрузка на аналитические системы, как правило, максимальна в конце отчетных периодов (месяца, квартала, года).
  • Транзакционная обработка осуществляется, в основном над текущими данными. Аналитические вычисления производятся над историческими данными.
  • Данные в транзакционных системах могут обновляться, тогда, как в аналитических системах данные должны только добавляться, и попытка внесения изменений задним числом должна вызывать, по меньшей мере, настороженность.

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

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

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


Рис. 4. Независимые витрины данных

Значит, нужен единый репозиторий – хранилище данных. Но информация в витринах не согласована. Каждая витрина унаследовала от транзакционной системы свою терминологию, свою модель данных, свою нормативно-справочную информацию, в том числе, кодировку данных. Например, в одной системе дата выполнения операции может быть закодирована в российском формате ДД.ММ.ГГГГ (день, месяц, год), а в другой в американском формате ММ.ДД. ГГГГ (месяц, день, год). Значит, при слиянии данных необходимо понимать, что означает дата 06.05.2009 – это 5 июня, или 6 мая. Итак, нам нужна система извлечения, преобразования и загрузки данных.

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

Внешние системы хранения данных за свою историю сильно изменились. Гибкие магнитные диски, DVD-диски, внешние жесткие диски, USB-накопители – все эти технологии быстро совершенствовались и менялись вместе с аппаратной базой компьютеров.

На фото – интерфейс облачного хранилища Google

Пример интерфейса облачного хранилища Google

Как работает облачное хранилище

Серверы частного или публичного облака работают не как независимые системы внутри структуры облачного хранилища, а как единая группа серверов. Для этой цели дисковое пространство вместе с другими компонентами сервера (например, CPU или оперативной памятью) виртуализируется с использованием гипервизоров. Поверх гипервизора будут работать уже не физические серверы, CPU и накопители данных, а виртуальные серверы. А в них – виртуальные машины VM (Virtual Machine), которые с точки зрения функционала аналогичны физическим устройствам. Но они обладают замечательным свойством: могут адаптироваться под конкретные требования, могут быстро мигрировать между физическими серверами и даже дата-центрами.

При этом между реальным оборудованием и виртуальными функциями хранения (Virtual Storage) возникает некий уровень абстрагирования, на котором работает монитор виртуальных машин VMM (Virtual Machine Monitor), который еще называют гипервизором (Hypervisor).

На фото – назначение гипервизора

Что делает гипервизор

Гипервизоры бывают двух типов:

В обоих случаях виртуализация обеспечивает гибкость функций, легкость масштабирования и простоту изменений.

Структура облачных систем хранения

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

Для частного облачного хранилища обычно требуется соединение с сервером VPN через соответствующую корпоративную сеть (Интранет), либо с помощью услуги виртуальной частной сети VPN (Virtual Private Network) через публичный Интернет. В последнее время появилась возможность использования для этой цели технологии SD-WAN (программно-конфигурируемой глобальной сети), но пока эта технология еще не достигла стадии зрелости.

Облачные провайдеры, в своей внутренней инфраструктуре хранения, кроме обычного файлового хранилища (File Storage), могут использовать альтернативные виды форматов: блочное хранилище (Block Storage) и объектное хранилище (Object Storage).

Вне зависимости от используемого формата хранения данных (File/ Block/ Object Storage) облачные провайдеры могут использовать в физическом оборудовании либо жесткие диски HDD, либо твердотельные диски SSD. Последние характеризуются более высокой скоростью записи и считывания данных внутри инфраструктуры облачного провайдера (заметим, что могут быть задержки в сети доступа). Но они пока более дорогие, чем классические HDD.

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

Преимущества облачного хранилища

Есть много причин, по которым целесообразно организовывать хранение данных во внешнем облаке.

Прежде всего, это экономия средств на приобретение и обслуживание собственного серверного оборудования для хранения. Существует расхожее мнение, что облачные услуги ничуть не дешевле – или даже дороже, чем собственные системы хранения (on-premise).

ТСО – это общая величина целевых затрат с момента начала владения до завершения владения, а также полного объема затрат, связанных с владением.

На фото – последствия аварии в собственном ЦОД

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

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

Другие преимущества облачного хранения:

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

Недостатки облачного хранилища

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

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

Кроме того, есть и другие недостатки.

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

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

Компромисс – гибридное облако

Прямые и скрытые затраты

Прямые и скрытые затраты

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

Гибридное облако, как это видно из самого названия, объединяет в себе плюсы публичного облака (Public Cloud) и частного облака (Private Cloud).

Заметим, что частное облако – это термин, по поводу которого в среде ИТ-специалистов идут незатихающие споры: есть ли такое понятие – частное облако? Или это просто хранилище данных в корпоративной системе.

Будем считать, что если при хранении данных в корпоративной системе (on-premise) используются технологии виртуализации, то такое решение можно с полным правом называть частным облаком. Если же это просто NAS на базе RAID, то это не облако, а корпоративное файловое хранилище.

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

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

Таким образом, решение гибридного облака сочетает в себе преимущества как частного, так и публичного облака, и может обеспечить такие преимущества, как:

Современные гиперконвергентные системы, например, HPE Simplivity, Dell EMC VxRail, Cisco Hyperflex изначально содержат в себе сервисы, позволяющие разворачивать гибридные облака для решения корпоративных задач. Более подробно об этом расскажем в следующих статьях.

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

Рисунок 2. Структура СППР с физическим ХД

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

Достоинства виртуального ХД:

· минимизация объема хранимых данных;

· работа с текущими, актуальными данными.

Недостатки виртуального ХД:

· более высокое, по сравнению с физическим ХД время обработки запросов;

· необходимость постоянной доступности всех OLTP-источников;

· снижение быстродействия OLTP-систем;

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

Проблематика построения хранилищ данных

Основная проблематика при создании ХД заключается в следующем:

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

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

3. организация многоуровневых справочников метаданных. Конечным пользователям СППР необходимы метаданные, описывающие структуру хранящихся в ХД данных, а также инструменты их визуализации;

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

Витрины данных

Сокращение затрат на проектирование и разработку ХД может быть достигнуто путем создания витрин данных (ВД). ВД – это упрощенный вариант ХД, содержащий только тематически объединенные данные (Рисунок 3).

Рисунок 3. Структура СППР с самостоятельными ВД

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

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

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

Рисунок 4. Структура СППР с ХД и ВД

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

Недостатки заключаются в избыточности, так как данные хранятся и в ХД, и в ВД, а также дополнительные затраты на разработку СППР с ХД и ВД.

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

Рисунок 2. Структура СППР с физическим ХД

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

Достоинства виртуального ХД:

· минимизация объема хранимых данных;

· работа с текущими, актуальными данными.

Недостатки виртуального ХД:

· более высокое, по сравнению с физическим ХД время обработки запросов;

· необходимость постоянной доступности всех OLTP-источников;

· снижение быстродействия OLTP-систем;

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

Проблематика построения хранилищ данных

Основная проблематика при создании ХД заключается в следующем:

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

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

3. организация многоуровневых справочников метаданных. Конечным пользователям СППР необходимы метаданные, описывающие структуру хранящихся в ХД данных, а также инструменты их визуализации;

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

Витрины данных

Сокращение затрат на проектирование и разработку ХД может быть достигнуто путем создания витрин данных (ВД). ВД – это упрощенный вариант ХД, содержащий только тематически объединенные данные (Рисунок 3).

Рисунок 3. Структура СППР с самостоятельными ВД

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

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

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

Рисунок 4. Структура СППР с ХД и ВД

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

Недостатки заключаются в избыточности, так как данные хранятся и в ХД, и в ВД, а также дополнительные затраты на разработку СППР с ХД и ВД.

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

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


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


Общие условия выбора системы дренажа: Система дренажа выбирается в зависимости от характера защищаемого.

Читайте также: