SPDE Engine
Олег Соловьев 4.04.2010
В SAS стандартная библиотека называется V9. Таблица в ней хранится в одном файле. SPDE Engine — это альтернативная библиотека. В ней таблица делится на несколько файлов, что позволяет хранить ее на разных дисках сервера, чтобы ускорить чтение/запись. При этом SPDE Engine не требует дополнительной лицензии SAS и входит в стандартную поставку Base SAS.
В Oracle и PostgreSQL, например, аналогичная технология называется партицированием (partitioning).
Я познакомился с SPDE на проекте по оптимизации хранилища данных. На нашем сервере было несколько дисков. На диске С: стояла операционная система и SAS. На двух дисках — D: и E: размещались библиотеки с данными. А самый быстрый диск — F: был выделен под библиотеку WORK.
Проблема в том, что чтение из таблицы происходило в один поток, с того диска на котором размещалась таблица. А второй диск при этом простаивал. Если бы таблица хранилась на двух дисках, то скорость чтения можно было бы увеличить до 2-х раз. Тогда мы и применили SPDE Engine.
Для установки SPDE библиотеки необходимо отредактировать config- и autoexec-файлы.
Config-файл
В Config-файле (например, C:Program FilesSASSAS 9.1nlsensasv9.cfg) необходимо указать каталоги, в которых будут храниться временные файлы. Эти файлы используются параллельными процессами, обрабатывающими данные в SPDE библиотеке, например:
-SPDEUTILLOC = 'F:Warehouse_projectSPDESPDEUTILLOC';
'E:Warehouse_projectSPDESPDEUTILLOC')
Согласно статье при использовании двух SPDEUTILLOC-каталогов первый каталог рекомендуется назначать на тот же диск, что и каталог для библиотеки Work.
Autoexec-файл
В autoexec-файле (например, C:Program FilesSASSAS 9.1autoexec.sas) необходимо указать оператор libname, например:
libname SPDElib spde 'C:DWHSPDE'
datapath = ('D:DWHSPDE'
'E:DWHSPDE')
asyncindex = yes;
В данном случае диск C: используется для хранения метаданных SPDE-библиотеки, а диски E: и F: –- для хранения записей таблиц. Опция «asyncindex» с параметром «yes» указывает на то, что индексы на файлах в SPDE библиотеке будут формироваться одновременно, а не последовательно, как в обычных библиотеках V9, что должно увеличить скорость создания индексов.
Рекомендации
Перенос таблицы из библиотеки V9 в SPDE, дает выигрыш в производительности только тогда, когда время, затрачиваемое на распараллеливание процессов чтения/записи значительно меньше времени обработки самой таблицы. Это условие зависит от многих факторов, но простейшая рекомендация — обратите внимание на таблицы от 3-х млн. записей.
Чем больше записей в таблице, тем быстрее она обрабатывается в SPDE-библиотеке по сравнению с V9.
Здравствуйте!
Вопрос для меня очень актуальны, касательно внедрения SPDE библиотек, есть один маленький вопрос, Вы не могли бы написать, хотя бы, приблизительные параметры сервера, на котором у Вас базировалась система SAS?
Я хочу понять для себя, какова производительность вашего железа и соответственно системы SAS на нем.
Я просто уже не знаю как бороться с таблицами в 150 гб. На базе которых строятся кубы.
Однопроцессорный сервер с 12 Гб ОЗУ. OC Windows Server 2003 EE. Каждый диск ОС: C, D, E,… - это RAID массивы емкостью несколько сотен ГБ каждый. Но на том сервере OLAP-кубов не было.
Таблица в 150 ГБ - это действительно очень много. В чем у вас основная проблема: слишком долго считаеся куб или он слишком долго возвращает данные при запросе?
Основная проблема в том, что слишком долго обновляются данные в таблицах.
При том, что SAS базируется на
Четырехпроцессорном сервере с 16 Гб ОЗУ. OC Windows Server 2003,
Разделы состоят из 3 физических устройств, разделенных на 5 виртуальных разделов, это так же RAID массивы объемы, так же очень велики.
Один из Винтов низко-скоростной, преднозначен для бэкапирования, но он не участвует в стандартных процессах.
Вот у меня и возникают проблемы, глобальные со стандартными дневными загрузками, которые предполагают собой обновление данных в таблицах размеры которых от 30 до 150 гб, на которых базируются кубы, с кубами частично проблему решили , строим отдельно ночью, а вот как ускорить обновление данных в таблицах с такими размерами, при том, что к серверу практически всегда обращаются юзера через портал данных, начиная от запросов к Олап кубам, заканчивая обычным дерганием хранимых процессов, что тоже загружает систему.
В общем ситуацию обрисовал, интересно Ваше мнение по возможным вариантам оптимизации хранилища.
Создается впечатление о не правильном распределении системных мощностей, сервер достаточно мощный , что бы осилить все операции которые на нем проводятся.
30 - 150 гб - это очень большие объемы. Это таблицы под OLAP-кубы или таблица, которые вы копируете из хранилища? Если из хранилища, то не обязательно копировать таблицы целиком - можно копировать только последние обновления и добавлять их к таблицам хранилища.
Также интересно, как вы обновляете индексы на таблицах? Пересчитваете их каждый раз заново? Есть спосбы обновления таблиц, которые позволяеют сохранять индексы, например с помощью процедуры APPEND или оператора UPDATE в DATA STEP.
Регулярно ли вы дефрагментируете диски хранилища? Чем меньше дефрагментированных файлов, тем быстрее данные читаются с диска.
На моей прежней работе пользователи имели доступ к таблицам хранилища и часто писали свой код. Порой сильно неоптимальный, например, они любили копировать таблицу в WORK (уже без индексов) и далее объединяли ее с другими таблицами, также без использования индексов.
В общем, оптимизация хранилища это исследовательский процесс “test and learn”. Нужно пробовать разные варианты и смотреть к чему они приводят.
Постараюсь скоро опубликовать свою старую статью по оптимизации хранилища, но основные принципы я уже рассказал.
Это таблицы под OLAP-кубы.
Данные таблицы НЕ перезаписываются, они абдейтятся новыми данными (дополняются)
Индексы не пересчитываются, они добавляются процедурой APPEND.
Попробую Ваш совет касательно Дефрагментации. Что касается доступа пользователей к таблицам “стратегического характера, простой юзер использует их только путем , чтения и то только через портал данных в виде кубов.
Что касается оптимизации кода, к сожалению я пока не достаточно квалифицирован дабы этим заниматься, но работаю над этим :).
Таблицы доступны только для группы разработчиков, конечно же не ве таблицы не всем девам :), мне так спокойней.
Спасибо за советы!
Александр,
есть еще нюанс - данные имеют свойство устаревать, вот у после непродолжительной борьбы за вынесение из одной таблички под кубы, данных до 2010 года, выяснилось, что эти данные никому не нужны и их просто выкинули :), правда решение было принято непросто:).
Кстати, попутно выяснилось, что если в таблице под 40 гиг с индексом по дате, попытаться удалить один день посредством PROC SQL, у сас-а конкретно рвет крышу, он начинает жрать трафик (руками обламывали после 2 террабайт) и процессорное время (мы используем Process Explorer от SysInternals, удобно контролировать пользователей, загрузку и т.п.).
И еще, в некоторых случаях, а именно, когда необходимо переписывать большие объемы неиндексированных данных под Windows (например для больших табличек из Staging Area), можно попробовать запретить обращение к системному свопу, у нас на тестовой табличке в 50 гиг, выигрыш по времени получался в 2-2.5 раза.
http://support.sas.com/resources/papers/IOthruSGIO.pdf
Так точно Андрей , за решением по данному вопросу я обращался к Вам :)),
Да и Ваши сессии САС, при попытке удалить данные PROC SQL, не однократно тем же волшебным Process Explorer рубил , используя свои Админские привилегии
Хорошо, что мы работаем вместе :))
Вот я и поработал с SPDE, все радует, кроме одного, эта гадость не поддерживает констреинты. Что впринципе может быть и проблемой в определенных случаях. Ну и Табличку просто не возьмешь одну и не сохранишь (физически), долго можно искать куски этой таблицы в директориях назначенных для такой библиотечки. В Производительности да выигрываешь, но как по мне это не так надежно как V9 движок.