Комментарии 8
Отличная статья. На недавнем форуме SAS в Москве слышал об этой теме, очень интересно.
Я правильно понимаю, что интернет банк использует аналитические данные SAS? Может быть и SAS BI тоже?
Я правильно понимаю, что интернет банк использует аналитические данные SAS? Может быть и SAS BI тоже?
При практическом применении DIS множество трансформаций кажутся жутко неудобными (кроме милейших Extract и SQL Join). Вечно так и подрывает накодить User-written Code.
Скажите, а Вы используете LSF, если у Вас бывает такое, что один и тот же процесс запускают несколько пользователей?
Скажите, а Вы используете LSF, если у Вас бывает такое, что один и тот же процесс запускают несколько пользователей?
Еще Append и Lookup вполне юзабельны. А так да, без User Written Code не обойтись.
LSF не используем, у нас самописный планировщик. На prod'е пользователи процессы не запускают — все автоматизировано, так что один и тот же процесс несколькими пользователями не запускается. Ну а в случае каких-то проблем, чинит обычно кто-то один, так что проблем не возникает.
LSF не используем, у нас самописный планировщик. На prod'е пользователи процессы не запускают — все автоматизировано, так что один и тот же процесс несколькими пользователями не запускается. Ну а в случае каких-то проблем, чинит обычно кто-то один, так что проблем не возникает.
>Передача данных из Greenplum в SAS всегда идет через master node и ограничена скоростью работы драйвера
На самом деле, в Greenplum есть Writable External Tables, то есть выгружать данные из Greenplum можно с той же скоростью, что и загружать. Вопрос в том, что SAS/Access for Greenplum пока не умеет их использовать, но обертку написать вполне можно
На самом деле, в Greenplum есть Writable External Tables, то есть выгружать данные из Greenplum можно с той же скоростью, что и загружать. Вопрос в том, что SAS/Access for Greenplum пока не умеет их использовать, но обертку написать вполне можно
По факту скорость выгрузки во writable external table существенно меньше скорости загрузки. (Множество сегментов могут параллельно записывать данные, а один ETL хост с такой скоростью принимать их не может). Возможно, использование большого числа gpfdist улучшило бы ситуацию, но есть подозрение, что полученный выигрыш все равно бы съела загрузка из текстовых файлов в SAS.
Если gpfdist смотрит на RAM-диск и Greenplum подключен по 10GbE, то использование writable external table даст скорость записи в 10Gbit/sec, реально около 1100 MB/sec. Дальше задача SAS по чтению результата из delimited-файла, но в итоге среднюю скорость в ~200MB/sec получить можно
Использование большего числа gpfdist должно подкрепляться архитектурой сети, иначе будут те же 10 Gbit/sec, хоть 1 gpfdist, хоть 10
Использование большего числа gpfdist должно подкрепляться архитектурой сети, иначе будут те же 10 Gbit/sec, хоть 1 gpfdist, хоть 10
У нас как раз gpfdist смотрит на RAM-диск и ETL-хост подключен в interconnect сеть Greenplum по 10GbE. Но вот скорость выгрузки в текстовый файл при этом составляет ~ 30MB/s. Есть правда одно но — ETL-хост у нас виртуальный. Но это все же не должно давать падение скорости на порядок. Ваши данные о скорости — это из личного опыта?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интегрируем SAS и Greenplum