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