экзамен

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

59. Подходы к построению хранилища данных. ETL vs. ELT.

ETL и ELT — два разных способа загрузки данных в хранилище.

ETL (Extract, Transform, Load) сначала извлекают данные из пула источников данных. Данные хранятся во временной промежуточной базе данных. Затем выполняются операции преобразования, чтобы структурировать и преобразовать данные в подходящую форму для целевой системы хранилища данных. Затем структурированные данные загружаются в хранилище и готовы к анализу.

В случае ELT (Extract, Load, Transform) данные сразу же загружаются после извлечения из исходных пулов данных.

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

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

60. Характеристика ведущих решений хранилищ данных.

IBM. Решение компании IBM называется Data Warehouse Plus. Целью компании в области разработки и поддержки систем складирования данных является обеспечение пользователя интегрированным набором программных продуктов и сервисов в рамках единой архитектуры.

IBM предлагает встроенную поддержку трех типов архитектурных решений для ХД:

•независимый киоск данных;

•взаимосвязанные киоски данных;

•глобальное ХД.

Несущая СУБД для ХД — семейство объектно-реляционных СУБД DB2. Язык манипулирования данными — SQL.

Oracle. Решения, предлагаемые компанией, преследуют две основные цели: предоставление пользователям широкого ассортимента программных продуктов самой компании и деятельность партнеров в рамках программы Warehouse Technology Initiative.

Компания Oracle не предлагает поддержку каких-либо встроенных архитектурных решений для ХД.

Несущая СУБД для ХД — семейство объектно-реляционных СУБД Oracle 11g/10g. Язык манипулирования данными — SQL. Начиная с версии 8i, диалект SQL существенно дополнен набором функций для аналитической обработки данных, вплоть до построения линейной регрессии.

Компания выпускает специальный CASE-инструментарий для проектирования ХД.

Конкурентные возможности Oracle определяются следующими факторами:

•имеется набор готовых приложений для разработки ХД, обеспечивающий полный жизненный цикл;

•компания является одним из лидеров по продажам в области анализа данных;

•совместимость с продуктами, производимыми другими компаниями.

NCR. Решение этой компании в области складирования данных ориентировано на организации, у которых имеются потребности в системах DSS (система поддержки и принятия решений) и системах OLAP. Предлагаемая архитектура называется Enterprise Information Factory (виртуальное предприятие).

Несущая СУБД для ХД — реляционная СУБД Teradata.

Конкурентным преимуществом решений компании является большой опыт применения СУБД Teradata и связанных с ней методов параллельной обработки данных.

SAS Institute. Компания считает себя поставщиком полного решения для организации ХД.

Компания предлагает методологию Rapid Data Warehousing для быстрого создания и наполнения ХД. В основу этой методологии положено:

•обеспечение доступа к данным в ХД с возможностью их извлечения из разнообразных источников данных (интероперабельность);

•преобразование и манипулирование данными в рамках 4GL (Data Step);

•наличие у компании сервера многомерных БД;

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

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

Sybase. Стратегия компании в области ХД основывается на разработанной архитектуре Warehouse WORKS.

Несущая СУБД для ХД — реляционная СУБД Sybase System 11, средство подключения к базам данных OmniCONNECT. Язык манипулирования данными — SQL и средства быстрой разработки приложений.

Компания выпускает специальный CASE-инструментарий для проектирования ХД.

Конкурентным преимуществом компании является наличие набора программных продуктов для обеспечения полного жизненного цикла разработки ХД.

61. Объектовые хранилища и традиционный подход к хранению данных (SAN, NAS).

Объектное хранилище – это технология хранения и управления данными в неструктурированном формате, называемом объектами.

Обычно, первичные данные хранятся в виде блоков и файлов в дата-центре. В частности, функции блочного хранения используются на низких уровнях, в виде блоков фиксированного размера, которые легко индексируются и находятся в системе хранения. Отсюда и название: «структурированные» данные. Обычно это устройства SAN (Storage Attached Network).

Файловая система хранения, однако, часто организуется в иерархии файлов и папок, которые существуют в системах хранения NAS (Network Attached Storage). В устройствах SAN используются протоколы iSCSI и Fibre Channel, а в файловых системах NAS используются протоколы SMB или NFS.

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

Традиционный подход к хранению данных – системы SAN (Storage Area Network) или NAS (Network attached Storage), если не рассматривать совсем простые системы DAS (Direct Attached Storage) – это, например, внешняя дисковая полка, подключенная напрямую к RAID-контроллеру сервера.

Системы хранения с блочным доступом — например, развернутые в виде сетевых (SAN) систем

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

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

Системы хранения с файловым доступом — обычно используемые как сетевое хранилище (NAS)

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

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

62. Некоторые типичные характеристики объектных систем хранения.

Объектные системы хранения совсем другое. Они основаны на «плоской» структуре с доступом к объектам через уникальные идентификаторы, что несколько похоже на то, как веб-сайты адресуются в системе доменных имен (DNS). Это отличает их от иерархической древовидной структуры файловой системы.

Некоторые типичные характеристики объектных систем хранения:

■Данные хранятся как объекты, а не в виде традиционных блоков, или файлов, состоящих из блоков

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

■Они неструктурированы по своей природе, потому что нет единого формата для хранения таких данных.

■В отличие от структуры каталогов, которая имеется в традиционных файловых системах хранения, в нем используется простой список объектов, хранящихся в «пакетах» (buckets).

■Объекты хранятся с использованием уникальных идентификаторов, а не имён файлов, что резко снижает «накладные расходы» (служебную информацию), необходимые для хранения данных.

■Объекты хранятся вместе с определёнными пользователем метаданными, что облегчает поиск объектов при масштабировании данных.

■Объекты могут иметь как терабайтные объёмы, так и быть размером в несколько килобайт, а один “пакет” может содержать миллиарды объектов.

■Разработчики приложений могут легко получить доступ к объектам, используя простые команды через интерфейсы API с помощью запросов «GET» и «PUT» без сложных структур каталогов.

63. Сравнение блочных файловых и объектных систем хранения.

Основные различия

Объекты могут иметь разные форматы и размеры, и обращаются к ним через определённый URLадрес, который построен с именем пакета (bucketname) и идентификатора (objectID) объекта.

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

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

Напротив, когда файл обновляется в объектном хранилище, весь объект можно легко помещать в пакет (bucket), не разбивая файл на блоки с фиксированными размерами. Это полное обновление делает хранение объектов идеальным для наборов данных, которые редко обновляются.

Объектное хранилище обычно выбирается для данных WORM, которые пишутся один раз, но читаются много раз (Write Once Read Many). Объектное хранилище хорошо масштабируется, поскольку может постоянно расти в соответствии с требованиями, оно построено с избыточностью, чтобы обеспечить постоянную доступность данных, снижает совокупную стоимость владения ТСО.

64. Ограничения объектных хранилищ.

Поскольку у объектного хранилища всего несколько доступных операций, появляются важные

ограничения:

●PUT создает новый объект и заполняет его данными.

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

●Когда вы создаете новый объект, хранилище возвращает его уникальный идентификатор. Обычно это UUID, у которого нет такого внутреннего значения, как у имени файла.

●GET извлекает содержимое объекта на основе идентификатора объекта (UUID).

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

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

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

65. Реализации объектных хранилищ.

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

ShellStore: простейший пример

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

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

DDN WOS

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

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

●Четкое разделение бэкенд-серверов хранения объектов и фронтенд-шлюзов. API, обеспечивающий доступ к бэкенду, прост и доступен через C ++, Python, Java и raw REST.

●Объекты хранятся на блочных устройствах без использования файлового слоя, например ext3. DDN позиционирует это как «NoFS».

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

●Доступные для поиска метаданные объектов встроены в бэкенд, поэтому вы можете не только помечать объекты, но и извлекать их на основе запросов. Это важно: в большинстве хранилищ нельзя искать объекты по метаданным.

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

●Шлюз S3 построен на основе Apache HBase.

● Шлюзы NFS масштабируются до восьми серверов. У каждого есть локальный дисковый кэш записи и глобальная согласованность с помощью функции сохранения при закрытии.

Openstack Swift

OpenStack Swift — одна из первых крупных реализаций объектного хранилища корпоративного уровня с открытым исходным кодом. Это то, что сегодня стоит за многими частными облаками. Но поскольку хранилище писали давно, в его архитектуре много неоптимальных решений:

Swift хранит объекты в блочных файловых системах, таких как ext3. И для хранения метаданных полагается на функции файловой системы, в частности xattrs.

Его внутренняя база данных сопоставлений объектов и местоположений хранится в файлах .gz, которые реплицируются на все хранилища и прокси-узлы.

Серверы контейнеров и учетных записей хранят подмножество метаданных объектов (атрибуты контейнера и учетной записи) в реплицированных базах данных sqlite.

Отсутствуют важные функции, например, кодирование со стиранием.

RedHat/Inktank Ceph

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

Объекты сопоставляются с группами размещения с помощью простой хеш-функции. Группы размещения (PG) — логические абстракции. Через хэш CRUSH они сопоставляются с демонами хранения объектов, которые владеют коллекциями физических дисков.

Группы размещения содержат собственные политики устойчивости объектов, а алгоритм CRUSH позволяет физически реплицировать объекты и географически распределять их по нескольким

OSD.

Ceph реализует политику устойчивости на стороне сервера, так что клиент, выполняющий PUT или GET объекта, общается только с одним OSD. После помещения объекта в OSD этот OSD отвечает за его репликацию в другие OSD, выполнение сегментирования, кодирования стиранием и распределения закодированных сегментов.

Scality RING — исключительно программный продукт (в отличие от DDN WOS), который работает на любом оборудовании. У него есть все стандартные шлюзовые интерфейсы (S3, NFS / CIFS и REST, называемые «коннекторами»), кодирование со стиранием и масштабируемый дизайн.

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

66. Объектное хранилище S3. Сценарии использования объектного хранилища S3.

Amazon S3 — это удобный, масштабируемый и высокопроизводительный сервис хранения данных, предоставляемый AWS.

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

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

Объектное хранилище Amazon S3 (Simple Storage Service) является одним из самых популярных и гибких облачных хранилищ данных, которые могут быть использованы для решения различных бизнес-задач и приложений. Рассмотрим несколько возможных сценариев использования S3:

1.Хранение и обработка данных.

2.Бэкап данных.

3.Хранение архивов.

4.Хранение статических сайтов.

5.Обмен файлами.

6.Анализ данных.

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