В предыдущей статье были рассмотрены аппаратные и программные способы повышения производительности хранилищ данных (DWH). Сегодня рассмотрим архитектурные способы, проектирование и администрирование.

Архитектуные способы повышения производительности

Правильная архитектура имеет ключевое значение для производительности и пропускной способности всей системы в целом. Элементами архитектуры являются все системы, вовлечённые в наполнение и использование хранилища данных, начиная от систем-источников (source system), и заканчивая отдельными витринами данных (data mart) и аналитическими приложениями (analytical application). При правильно построенной архитектуре данные максимально быстро попадают из систем, в которых они создаются, к конечным пользователям. При этом инфраструктура хранилища данных (оборудование, программное обеспечение) используется наиболее оптмальным образом (отсутствуют пики и простои). Оптимизация хранилища данных с точки зрения архитектуры может включать перенос нагрузки из узких мест в более производительные и/или недозагруженные. Например, перенос части нагрузки с ETL-серверов на СУБД хранилища данных (ELT). Или, наоборот, разгрузка СУБД хранилища данных за счёт переноса нагрузки с СУБД на серверы OLAP.

Многоуровневая архитектура. Если она пока ещё не очень многоуровневая, то можно сделать её таковой. Например, современные инструменты BI имеют многоуровневую архитектуру с возможностью кэширования (cache) практически на каждом уровне (СУБД, сервер OLAP/Reporting, web-сервер, сервер массовой рассылки). Путём включения механизмов кэширования на каждом уровне можно значительно разгрузить предыдущие уровни.

Архитектура hub-and-spoke. При такой архитектуре в хранилище данных данные только хранятся, а доступ к данным предоставляется уже на уровне специализированных зависимых витрин данных. При этом, зависимые витрины строятся на специализированных СУБД (multidimensional DBMS, columnar database).

Проведение расчётов в пакетном режиме (batch calculation).
Это очень распространённое решение проблем с производительностью - расчёты выполняются единожды в процессе или после загрузки хранилища данных. Результаты помещаются в отдельные таблицы, которые проектируются для обеспечения высокого быстродействия.

Создание “песочницы” для супер-пользователей. На любом предприятии всегда найдутся продвинутые пользователи, которые захотят выполнять очень сложные непредопределённые запросы (ad hoc query) на больших объёмах данных. Если они начинают это делать, а СУБД не имеет возможностей динамического управления нагрузкой, то лучше всего выделить таких пользователей в отдельную группу, и создать для них витрину данных на другом оборудовании, чтобы они не увеличивали значительно время отклика системы для всех пользователей.

Использование ODS в качестве промежуточного слоя для захвата данных из оперативных систем, а также для разделения смешанной нагрузки (mixed workload) между разными платформами может повысить производительность различных подсистем хранилища данных.

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

Push-технология для отчётов.Многие инструменты BI уже поддерживают рассылку отчётов по разным каналам (например, email, SMS). При этом, отчёты можно считать заранее (в моменты наименьшей загрузки хранилища) и рассылать сразу же после расчёта.

Multi-temperature data warehousing - разнесение данных с разной “температурой” (горячие - наиболее востребованные, холодные - наименее востребованные) по разным носителям. Например, “горячие” данные можно хранить на быстрых, надёжных (дорогих) дисках или в оперативной памяти, а “холодные” - на более медленных дисках или даже на магнитных лентах. Разумеется, технология должна поддерживать такое распределение данных. В идеале, это должна уметь делать СУБД хранилища данных.

Проектирование

На уровне проектирования хранилищ (DWH) и витрин данных (data mart) можно получить значительный прирост производительности.

Партиционирование данных, в частности, горизонтальное партиционирование (horizontal partitioning) является очень распространённым приёмом повышения быстродействия, способным на порядки поднять скорость выполнения запросов путём сканирования только тех партиций (partition), в которых находятся данные, удовлетворяющие критериям выборки (partition elimination). Партицирование данных также возможно в процессах ETL. Здесь речь идёт о том, чтобы разбивать большие таблицы (файлы) на несколько частей и обрабатывать их параллельно. Хорошо, если это умеет делать ваш инструмент ETL. Но, если не умеет - можно и вручную, скорее всего, это будет оправданно.

Контролируемая денормализация (denormalization), как правило, является один из приёмов для ускорения выполнения запросов. Разумеется, при этом нужно понимать, что денормализация привносит и определённые неудобства (рост объёмов данных, более сложное администрирование, вероятность несогласованных данных, сложности обновления). Весьма вероятен и обратный эффект - после денормализации скорость выполнения некоторых запросов может снизиться (например, если вы добавили новое поле в таблицу, то снизится скорость полного сканирования таблицы за счёт роста объёма данных).

Нормализация (normalization) может также повысить производительность определённых запросов за счёт того, что таблицы становятся более узкими. Другие запросы могут при этом пострадать из-за необходимости выполнения операций соединения таблиц.

Предварительное агрегирование данных на этапе загрузки данных в хранилище или витрину данных может очень существенно повысить производительность выполнения запросов. Об этом способе все знают, поэтому долго на нём останавливаться не будем (о работе с агрегатами есть целая книга - Mastering Data Warehouse Aggregates). Следует лишь упомянуть о возможности агрегатного взрыва (aggregate explosion) и необходимости строгого контроля процесса создания агрегатов для поддержания целостности данных и соответствия агрегированных данных детальным.

Сжатие данных. Если СУБД хранилища данных сама не беспокоится о сжатии данных (data compression) в таблицах, то об этом нужно позаботиться разработчику базы данных. Сжатие может довольно существенно повысить производительность за счёт уменьшения объёмов данных, хранящихся на медленных устройствах (дисках).

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

Повышение надёжности ETL. Речь идёт о проектировании ETL-процессов так, чтобы они были максимально надёжными и максимально быстро восстанавливались после сбоев. Затянувшийся ETL-процесс, который вышел за пределы предназначенного для него “окна” может надолго выбить хранилище из строя, снизив произвоидетльность системы за счёт повторного запуска ресурсоёмких процедур.

Администрирование

Создание индексов. Индексы являются общепризнанным инструментом повышения производительности запросов. Как универсальные, так и специализированные СУБД для хранилищ данных могут предлагать целый спектр индексов для ускорения запросов, имеющих аналитический характер (например, bitmap index, hash index, word index). О таких индексах необходимо помнить и уметь ими пользоваться. Следует помнить и о том, что индексы требуют сопровождения, и что использование индексов оказывает негативное влияние на скорость загрузки данных ввиду того, что при загрузке появляется необходимость в пересчёте индексов. Однако они могут и ускорить загрузку за счёт создания индексов на промежуточные таблицы, интенсивно используемые в процессе загрузки, например, справочные таблицы (lookup table). При загрузке больших объёмов данных в проиндексированные таблицы ускорить процесс загрузки может удаление индекса, загрузка данных и полное пересоздание индекса.

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

Сокращение полномочий пользователей по определённым видам запросов. Опять-таки, современные СУБД умеют “бить по рукам” пользователям, если они пытаются выполнять определённые ресурсоёмкие операции (например, декартово произведение больших таблиц или использование в одном запросе большого количества таблиц). Такими средствами необходимо пользоваться, чтобы освободить СУБД от ресурсоёмких, иногда не имеющих смысла запросов.


Для удобства отслеживания новых публикаций рекомендуем подписаться на рассылку или на канал RSS.

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