Современная архитектура хранилища данных: традиционное или облачное хранилище данных
Пространство хранилища данных быстро меняется. Традиционные локальные устаревшие хранилища данных по-прежнему способны интегрировать структурированные данные для бизнес-аналитики. Увеличение количества разнообразно структурированных и форматированных больших данных через облако усложняет задачи хранения данных.
Архитектура облачного хранилища данных разработана с учетом ограничений традиционных баз данных. Переход на облачное хранилище данных даст компании возможность использовать многие преимущества облака для управления данными. В этой статье мы объясним различия между традиционной и облачной архитектурами хранилищ данных и определим преимущества обеих.
Понимание традиционной локальной архитектуры хранилища данных
Есть ряд различных характеристик, присущих исключительно традиционной архитектуре хранилища данных. Эти характеристики включают различные архитектурные подходы, конструкции, модели, компоненты, процессы и роли – все это влияет на эффективность архитектуры.
Трехуровневый архитектурный подход
Подход с трехуровневой архитектурой – один из самых часто встречающихся подходов к локальному хранилищу данных. Три уровня: нижний, средний и верхний.
- Нижний уровень: нижний уровень содержит фактический сервер базы данных, используемый для удаления данных из источников происхождения.
- Средний уровень: на среднем уровне есть сервер для онлайн-аналитической обработки (OLAP), который отвечает за преобразование данных. Он может отображать многомерные данные в реляционные операции или использовать многомерную модель OLAP для операций с многомерными данными.
- Верхний уровень: верхний уровень похож на уровень пользовательского интерфейса. Он состоит из инструментов для общей аналитики хранилищ данных, таких как отчеты и интеллектуальный анализ данных.
Архитектурный дизайн: Кимбалл или Инмон
Два наиболее часто используемых подхода к проектированию хранилищ данных предложены Ральфом Кимбаллом и Биллом Инмоном. Подход Инмона считается «сверху вниз» и рассматривает хранилище как централизованное хранилище всех данных организации. После создания централизованной модели данных для этого хранилища организации могут использовать размерные витрины данных на основе этой модели. Витрины данных – это хранилища для отдельных бизнес-направлений.
Подход Кимбалла основан на методе «снизу вверх», в котором витрины данных являются основными методами хранения данных. Хранилище данных в основном представляет собой набор тех витрин данных, которые позволяют выполнять унифицированные аналитические задания, отчеты и другие необходимые процессы бизнес-аналитики.
Традиционные модели архитектуры хранилища данных
Большинство хранилищ данных полагаются на одну из трех различных моделей:
- Виртуальное хранилище данных: основано на хранилище, которое является центром активов данных организации. Оно объединяет данные из каждого направления бизнеса для легкого доступа в масштабах всей компании.
- Витрина данных: подчеркивает данные отдельных бизнес-единиц для аналитики и отчетности. Она включает в себя агрегирование данных из нескольких источников для одной области, такой как маркетинг.
- Корпоративное хранилище данных: основано на распределенном подходе, при котором доступ к различным базам данных осуществляется с помощью одного запроса, как если бы было только одно центральное хранилище.
Компоненты архитектуры локального хранилища данных
Есть несколько различных структурных компонентов, которые можно включить в традиционные локальные хранилища данных. Все хранилища данных имеют пользовательский уровень для конкретных задач анализа данных или интеллектуального анализа данных. Если источники данных (другой тип структуры) содержат в основном те же типы данных, эти источники можно ввести в структуру хранилища данных и проанализировать непосредственно через пользовательский уровень.
Структура промежуточной области необходима, когда источники данных содержат данные из разных структур, форматов и моделей данных. Здесь данные преобразуются в обобщенный структурированный формат, чтобы их можно было комплексно проанализировать на уровне пользователя. В зависимости от бизнес-сценария использования эта структура может и не понадобиться, если компании анализируют только данные схожих типов.
Промежуточная область может поддерживаться добавлением другой структуры, и витрин данных. Витрины данных полезны для хранения сводных данных по конкретному бизнес-направлению для очень конкретных запросов. Например, команды отдела продаж могут получить доступ к этой структуре данных для подробной прогнозной аналитики продаж в разных местах.
Процесс и роли, участвующие в традиционном проектировании хранилища данных
Процесс ETL (извлечение, преобразование и загрузка) для традиционного дизайна хранилища данных требует извлечения данных из источников, их промежуточной обработки с помощью сторонних инструментов ETL преобразования и перемещения данных в хранилище данных для хранения. ELT включает удаление данных из источников и размещение их в хранилищах данных, а затем применение преобразований в этом хранилище. В обоих этих подходах каждый аспект потока данных отслеживается с помощью метаданных и системных операций. Логика данных устанавливает правила для аналитики и отчетности.
На каждом этапе в мониторинге этих процессов обычно участвуют ИТ-команды. Однако специалисты по данным также могут контролировать эти шаги, особенно с хранилищами больших данных, обычно используемыми при ELT. Обе эти роли предоставляют результаты аналитики бизнес-пользователям, которые действуют в соответствии с ними.
Есть еще несколько преимуществ, связанных с использованием традиционных локальных хранилищ данных, которые хорошо подходят для интеграции похожих типов структурированных данных и обеспечения качества данных. Однако этот подход гораздо менее гибок при работе с полуструктурированными и структурированными данными. Приведение этих данных в соответствие с унифицированными моделями данных хранилищ не только занимает больше времени, но и требует больших затрат из-за необходимости использования отдельных инструментов ETL и промежуточной обработки.
Понимание архитектуры облачного хранилища данных
Архитектура облачного хранилища данных относительно нова по сравнению с устаревшими вариантами. Эта архитектура хранилища данных означает, что доступ к реальным хранилищам данных осуществляется через облако. Существует несколько вариантов облачных хранилищ данных, у каждого разная архитектура для одних и тех же преимуществ интеграции, анализа и обработки данных из разных источников. Различия между подходом к облачному хранению данных и традиционному подходу:
- Первоначальные затраты: разные компоненты, необходимые для традиционных локальных хранилищ данных, требуют довольно больших затрат на начальном этапе. Поскольку доступ к компонентам облачной архитектуры осуществляется через облако, эти расходы здесь не применимы.
- Текущие расходы. В то время как компаниям с локальными хранилищами данных, приходится иметь дело с расходами на обновление и обслуживание, облако предлагает модель с оплатой услуг по мере использования.
- Скорость: архитектура облачного хранилища данных значительно быстрее, чем локальные варианты, отчасти из-за использования ELT, что является необычным для локальных аналогов.
- Гибкость: облачные хранилища данных предназначены для учета разнообразия форматов и структур больших данных. Традиционные реляционные опции предназначены просто для интеграции данных с аналогичной структурой.
- Масштаб: эластичные ресурсы облака делают его идеальным для масштабирования, такого необходимого для больших наборов данных. Кроме того, варианты облачного хранилища данных также могут быть уменьшены по мере необходимости, что трудно сделать при других подходах.
Вот некоторые из самых заметных облачных хранилищ данных на рынке: Amazon Redshift, Google BigQuery, Snowflake и Microsoft Azure SQL Data Warehouse.
Обзор архитектуры Amazon Redshift
Redshift использует архитектуру массивно-параллельной обработки, в которой узлы хранят данные в срезах в столбчатом формате. У каждого узла есть собственное хранилище, оперативная память и вычислительная мощность. Основные типы узлов – ведущие и вычислительные узлы; первый принимает запросы и назначает их вычислительным узлам для выполнения запросов.
Поскольку вычислительные узлы могут обрабатывать данные в разных срезах одновременно, Redshift обеспечивает высокую производительность запросов. Вычислительные узлы возвращают результаты ведущим узлам, которые объединяют их для клиентских приложений. Пользователи могут напрямую подключаться к Redshift с помощью набора инструментов бизнес-аналитики, чтобы запрашивать данные прямо там, где они хранятся.
Обзор архитектуры Google BigQuery
Google BigQuery основан на безсерверной архитектуре, в которой поставщик использует разные машины для управления ресурсами. Следовательно, клиенты не участвуют в процессе управления ресурсами. Архитектура BigQuery поддерживает как традиционную загрузку данных, так и потоковую передачу данных, последняя предназначена для приема данных в режиме реального времени.
Основным архитектурным компонентом этого облачного хранилища данных является Dremel, механизм массовых параллельных запросов, способный читать сотни миллионов строк за секунды. При таком подходе данные фактически хранятся в системе управления файлами под названием Colossus, которая помещает данные в кластеры, состоящие из разных узлов. Файлы в столбчатом формате распространяются в объеме 64 мегабайта. Запросы отправляются из древовидной архитектуры между разными машинами, на которых хранятся данные, что помогает сократить время отклика.
Архитектура хранилища данных Snowflake
Архитектура Snowflake похожа на Redshift, поскольку в ней также используется кластерный и узловой подход. Основное архитектурное отличие Snowflake заключается в том, что вычислительные возможности отделены от хранилища, что дает несколько важных преимуществ. Какое преимущество основное? Место хранения меняется в зависимости от того, требуются ли пользователям вычисления в данный момент.
Если пользователю не нужны вычисления, данные распределяются по уровням (то есть перемещаются) в другую менее затратную область для хранения, поскольку эта область хранения не используется для вычисления данных. Кроме того, отделение хранилища от вычислительных ресурсов позволяет архитектуре Redshift легко масштабироваться вверх и вниз по мере необходимости, выходя далеко за пределы возможностей локальных хранилищ данных. Кроме того, компоненты для приема данных и их анализа интегрированы с компонентом хранилища.
Архитектура хранилища данных Microsoft Azure SQL
Подобно архитектуре Redshift, архитектура облачного хранилища данных Microsoft Azure основана на массово-параллельной обработке. Данные хранятся в реляционных базах данных, которые из-за этой архитектуры запускают быстрые SQL-запросы огромной сложности. Дополнительные инструменты в облачной экосистеме Azure позволяют пользователям создавать автоматизированные конвейеры для передачи, обработки и хранения данных в петабайтном масштабе.
Переход от традиционного к облачному хранилищу данных
Хотя традиционная архитектура базы данных все еще используется в работе с тесной интеграцией схожих структурированных типов данных, локальные параметры перестают работать, когда в хранимых данных появляется больше разнообразия. Кроме того, локальная архитектура требует больших затрат на создание и обслуживание, и она просто не работает со скоростью и гибкостью, которые требуются для современных наборов данных в нынешнюю эпоху больших данных.
С другой стороны, облачная архитектура хранилища данных предназначена для максимальной масштабируемости современных потребностей в интеграции данных и аналитике. Это не только дает значительные преимущества в производительности и интеграции, облачные хранилища данных намного более экономичны, масштабируемы и гибки для различных форматов данных, используемых сегодня организациями. В конечном счете, облачная архитектура хранилища данных – это наиболее эффективное использование ресурсов хранилища данных.
Организации могут оптимизировать переход от локальных вариантов к облачным хранилищам данных с помощью решений, комплексно разработанных для управления перемещением данных в облаке.
