Data Warehouse Service (DWS) — это онлайн‑база данных для анализа и обработки данных, построенная на инфраструктуре и платформе облако. Она предлагает масштабируемые, готовые к использованию и полностью управляемые аналитические сервисы баз данных и совместима с синтаксисом ANSI/ISO SQL‑92, SQL‑99 и SQL:2003. Кроме того, DWS совместима с другими экосистемами баз данных, такими как PostgreSQL, Oracle, Teradata и MySQL. Это делает её конкурентоспособным вариантом для аналитики больших данных в масштабе петабайт в различных отраслях.
Логическая архитектура кластера
Figure 1 показывает логическую архитектуру кластера DWS. Для получения подробной информации об instance см. Table 1.
Figure 1 Logical cluster architecture
Name | Function | Description |
|---|---|---|
Cluster Manager (CM) | Cluster Manager. Он управляет и контролирует состояние работы функциональных блоков и физических ресурсов в распределённой системе, обеспечивая стабильность системы. | CM состоит из CM Agent, OM Monitor и CM Server.
CM Servers развертываются в парах primary/standby для обеспечения высокой доступности системы. CM Agent подключается к primary CM Server. Если primary CM Server выходит из строя, standby CM Server повышается до primary, чтобы предотвратить единую точку отказа (SPOF). |
Global Transaction Manager (GTM) | Генерирует и поддерживает глобально уникальную информацию, такую как идентификатор транзакции, снимок транзакции и метка времени. | Кластер включает только одну пару GTM: один primary GTM и один standby GTM. |
Workload Manager (WLM) | Workload Manager. Он контролирует распределение системных ресурсов, чтобы предотвратить перегрузку сервиса и сбой системы, вызванные избыточной нагрузкой. | Не требуется указывать имена хостов, на которых будут развернуты WLM, поскольку программа установки автоматически устанавливает WLM на каждый хост. |
Coordinator (CN) | CN получает запросы доступа от приложений и возвращает результаты выполнения клиенту; разбивает задачи и распределяет их между различными DN для параллельной обработки. | CN в кластере имеют эквивалентные роли и возвращают одинаковый результат для одинакового DML‑оператора. Между CN и приложениями можно добавить балансировщики нагрузки, чтобы CN были прозрачны для приложений. Если CN выходит из строя, балансировщик нагрузки автоматически подключает приложение к другому CN. Подробности см. раздел "Associating and Disassociating ELB". CN должны соединяться друг с другом в распределённой транзакционной архитектуре. Чтобы снизить большую нагрузку, вызванную избыточным количеством потоков на GTM, в кластере не следует конфигурировать более 10 CN. DWS управляет глобальной нагрузкой ресурсов в кластере с помощью Central Coordinator (CCN) для адаптивного динамического управления нагрузкой. При первом запуске кластера CM выбирает CN с наименьшим ID в качестве CCN. Если CCN выходит из строя, CM заменяет его новым. |
Datanode (DN) | DN хранит данные в режиме row-store, column-store или гибридном режиме, выполняет задачи запросов данных и возвращает результаты выполнения CNs. | В кластере имеется несколько DN. Каждый DN хранит часть данных. DWS обеспечивает высокую доступность DN: active DN, standby DN и secondary DN. Принципы работы этих трёх компонентов следующие:
Secondary DN используется исключительно в качестве резервной копии и никогда не переходит в статус active или standby при возникновении сбоев. Он экономит место, храня только данные Xlog, переданные от нового active DN, и данные, реплицированные во время отказов исходного active DN. Такой эффективный подход экономит одну треть объёма хранилища по сравнению с традиционными методами тройного резервного копирования. |
Хранилище | Функционирует как локальные ресурсы хранилища сервера для постоянного хранения данных. | - |
DN в кластере хранят данные на дисках. Figure 2 логически описывает объекты на каждом DN и взаимосвязи между ними.
- База данных управляет различными объектами данных и изолирована от других баз данных.
- Сегмент datafile хранит данные только в одной таблице. Таблица, содержащая более 1 ГБ данных, хранится в нескольких сегментах datafile.
- Таблица принадлежит только одной базе данных.
- Блок является базовой единицей управления базой данных, размер по умолчанию — 8 КБ.
Данные могут распределяться в режимах replication, round-robin или hash. Вы можете указать режим распределения при создании таблицы.
Figure 2 Logical database architecture
Физическая архитектура кластера
DWS поддерживает связанные и разъединённые архитектуры хранения‑вычислений.
В связанной архитектуре хранения‑вычислений данные хранятся на локальных дисках DNs. В разъединённой архитектуре хранения‑вычислений локальные диски DN используются только для кэширования данных и хранения метаданных, а пользовательские данные хранятся в OBS. При необходимости можно выбрать архитектуру.
Рисунок 3 Выбор архитектуры
Связанная архитектура хранения‑вычислений
DWS использует архитектуру shared‑nothing и движок массовой параллельной обработки (MPP), состоит из множества независимых логических узлов, которые не разделяют системные ресурсы, такие как CPU, память и хранилище. В такой архитектуре данные сервиса хранятся отдельно на множестве узлов. Задачи анализа данных выполняются параллельно на узлах, где находятся данные. Массовая параллельная обработка данных значительно повышает скорость отклика.
Рисунок 4 Архитектура
- Слой приложения
Инструменты загрузки данных, инструменты Extract-Transform-Load (ETL), инструменты Business Intelligence (BI) и инструменты добычи и анализа данных могут быть интегрированы с DWS через стандартные интерфейсы. DWS совместим с экосистемой PostgreSQL, а синтаксис SQL совместим с Oracle и Teradata. Приложения могут быть плавно перенесены в DWS с минимальными изменениями.
- API
Приложения могут подключаться к DWS через стандартные JDBC и ODBC.
- DWS
Кластер DWS содержит узлы одинакового флейвора в одной подсети. Эти узлы совместно предоставляют сервисы. Datanodes (DNs) в кластере хранят данные на дисках. CNs (координаторы) получают запросы доступа от клиентов и возвращают результаты выполнения. Они также разбивают и распределяют задачи между Datanodes (DNs) для параллельного выполнения.
- Автоматический бэкап данных
Снимки кластера могут автоматически бэкапиться в Object Storage Service (OBS) уровня EB, что упрощает периодический бэкап кластера в непиковые часы и обеспечивает восстановление данных после возникновения исключения кластера.
Снапшот — это полный бэкап DWS в указанный момент времени. Он фиксирует все конфигурационные данные и данные сервиса кластера в указанный момент.
- Цепочка инструментов
DWS предоставляет широкий набор инструментов, включая General Data Service (GDS) для параллельной загрузки данных, SQL editor для разработки SQL и GDS‑Kafka для миграции данных. Операции и обслуживание кластера (cluster O&M) можно мониторить в консоли.
Storage-Compute Decoupled Architecture
Новый DWS storage-compute decoupled cloud-native data warehouse предоставляет пул ресурсов, масштабное хранилище и архитектуру MPP с разъединёнными вычислениями и хранилищем. Это обеспечивает высокую эластичность, импорт и совместное использование данных в реальном времени, а также интеграцию lake warehouse.
Cloud-native data warehouse позволяет отдельно масштабировать вычислительные и дисковые ресурсы благодаря разъединённым вычислениям и хранилищу. Пользователи могут легко регулировать свои вычислительные возможности в пиковые и непиковые часы. Кроме того, хранилище может расширяться без ограничений, обеспечивая быстрый и гибкий отклик на изменения сервиса при сохранении экономичности.
Архитектура storage-compute decoupled имеет следующие преимущества:
- Lakehouse: Он упрощает обслуживание и эксплуатацию интегрированного lakehouse. Он бесшовно интегрируется с DLI, поддерживает автоматический импорт метаданных, ускоряет запросы к внешним таблицам, позволяет выполнять объединённые запросы к внутренним и внешним таблицам, а также обеспечивает чтение и запись форматов data lake, упрощая импорт данных.
- Real-time write: Он предоставляет движок хранилища H-Store, который оптимизирует запись данных в реальном времени и поддерживает высокопроизводительные пакетные записи и обновления в реальном времени.
- High elasticity: Масштабирование вычислительных ресурсов и использование хранилища по требованию могут привести к значительной экономии затрат. Исторические данные не требуется переносить в другие носители, что обеспечивает сквозной анализ данных для отраслей, таких как финансы и Интернет.
- Data sharing: Несколько загрузок совместно используют одну копию данных в реальном времени, при этом вычислительные ресурсы изолированы. Поддерживается множественная запись и чтение.
Figure 5 Storage-compute decoupled architecture
- Отличная масштабируемость
- Виртуальные склады (VWs) могут расширяться одновременно в зависимости от требований сервиса.
- Данные совместно используются несколькими VWs в реальном времени, устраняя необходимость дублирования данных.
- Multiple VWs повышают пропускную способность и параллельность, обеспечивая отличную изоляцию чтения/записи и нагрузки.
- Lakehouse
- Бесшовный гибридный запрос по data lakes и data warehouses
- При анализе data lake вы можете воспользоваться высочайшей производительностью и точным контролем data warehouses.
Сравнение архитектур Storage-Compute Coupled и Decoupled
Версия | Связанное хранилище и вычисления | Разделённое хранилище и вычисления | ||
|---|---|---|---|---|
Носитель хранения | Данные хранятся на локальных дисках вычислительных узлов. Локальные диски могут быть cloud SSDs, в зависимости от выбранного типа хранилища.
| Данные column-store хранятся в Cloud Object Storage Service (OBS). Локальные диски вычислительных узлов используются в качестве кэша запросов данных OBS. Данные row-store по‑прежнему хранятся на локальных дисках вычислительных узлов. | ||
Преимущество | Данные хранятся на локальных дисках вычислительных узлов, обеспечивая высокую производительность. | Архитектура разделяет хранилище и вычисления, обеспечивая слоистую эластичность, использование хранилища по запросу, быстрое масштабирование вычислений, неограниченную вычислительную мощность и ёмкость. Данные, хранящиеся в object storage, снижают затраты, а multiple VWs поддерживают более высокую конкурентность. Обмен данными и интеграция lakehouse. | ||