AV
Понимаешь теперь, почему мне не нужны советы "смотри где-то там" ?
Size: a a a
2020 August 27
i
Ну это понятно. Конвертации типов должны быть настраиваемые. Табличка с конвертацией, source -> desctination, как-то так я это себе представлял.
В скульных базах еще и relations
AP
Нужно из Redshifta данные дёргать периодически. Сейчас просто через SELECT делается. Существуют ли какие-то нативные варианты? Чтобы взять и в RDS, например, что-то скопировать.
Я бы смотрел в сторону glue. Он может сделать каталог данных при помощи crawler (он поддерживает redshift через JDBC connector). Потом pyspark скрипт по расписанию и connection в RDS.
А эти данные в RDS долго хранятся? Может проще выгружать в S3 и потом использовать Athena с ODBC драйвером?
А эти данные в RDS долго хранятся? Может проще выгружать в S3 и потом использовать Athena с ODBC драйвером?
AT
Я бы смотрел в сторону glue. Он может сделать каталог данных при помощи crawler (он поддерживает redshift через JDBC connector). Потом pyspark скрипт по расписанию и connection в RDS.
А эти данные в RDS долго хранятся? Может проще выгружать в S3 и потом использовать Athena с ODBC драйвером?
А эти данные в RDS долго хранятся? Может проще выгружать в S3 и потом использовать Athena с ODBC драйвером?
если RDS PostgreSQL и периодически и не так чтобы огромный вагон данных то federated query почему бы и нет?
MV
Подскажите, а что за странное поведение на S3 бакетах - нельзя создать бакет, пишет что он есть, но по факту его нету -
MV
MV
AS
потому что имя занято
AG
Подскажите, а что за странное поведение на S3 бакетах - нельзя создать бакет, пишет что он есть, но по факту его нету -
имена s3 бакетов уникальны глобально. не только в регионе, но вообще, по всему миру. у всех пользователей.
MV
Alexey Gravanov
имена s3 бакетов уникальны глобально. не только в регионе, но вообще, по всему миру. у всех пользователей.
сорри, туплю, спасибо
странно, что development-profile-photo ещё никто не занял
странно, что development-profile-photo ещё никто не занял
AV
Я бы смотрел в сторону glue. Он может сделать каталог данных при помощи crawler (он поддерживает redshift через JDBC connector). Потом pyspark скрипт по расписанию и connection в RDS.
А эти данные в RDS долго хранятся? Может проще выгружать в S3 и потом использовать Athena с ODBC драйвером?
А эти данные в RDS долго хранятся? Может проще выгружать в S3 и потом использовать Athena с ODBC драйвером?
Данные не просто хранятся, они раздаются на чтение.
Думаю, есть ли преимущества по скорости у UNLOAD.
Думаю, есть ли преимущества по скорости у UNLOAD.
AG
сорри, туплю, спасибо
странно, что development-profile-photo ещё никто не занял
странно, что development-profile-photo ещё никто не занял
я как-то пытался временный бакет создать, кое что попробовать. обнаружил, что пара десятков вариантов, которые я попробовал в первую очередь, типа asdasd, asdasdasd, asdasd123, asdasd123456 и подобных им - заняты :)
AV
Я бы смотрел в сторону glue. Он может сделать каталог данных при помощи crawler (он поддерживает redshift через JDBC connector). Потом pyspark скрипт по расписанию и connection в RDS.
А эти данные в RDS долго хранятся? Может проще выгружать в S3 и потом использовать Athena с ODBC драйвером?
А эти данные в RDS долго хранятся? Может проще выгружать в S3 и потом использовать Athena с ODBC драйвером?
Athena чем лучше? По скорости не проигрывает разве? При частых запросах не дороже ли будет?
AP
Athena чем лучше? По скорости не проигрывает разве? При частых запросах не дороже ли будет?
Если делать выгрузку через Unload в parquet и правильно папочки проименовать, то будет гораздо быстрее.
Лучше ещё тем, что не придётся иметь базу и все из этого вытекающее. Athena умеет сохранять результаты запроса на s3 и их можно повторно использовать.
Я вчера скидывал статью как Битрикс у себя построил аналитику.
Насчёт стоимости - тут только тест + расчёт исходя из цифр, а «частые запросы» к сожалению не точная метрика.
Лучше ещё тем, что не придётся иметь базу и все из этого вытекающее. Athena умеет сохранять результаты запроса на s3 и их можно повторно использовать.
Я вчера скидывал статью как Битрикс у себя построил аналитику.
Насчёт стоимости - тут только тест + расчёт исходя из цифр, а «частые запросы» к сожалению не точная метрика.
AP
AV
Если делать выгрузку через Unload в parquet и правильно папочки проименовать, то будет гораздо быстрее.
Лучше ещё тем, что не придётся иметь базу и все из этого вытекающее. Athena умеет сохранять результаты запроса на s3 и их можно повторно использовать.
Я вчера скидывал статью как Битрикс у себя построил аналитику.
Насчёт стоимости - тут только тест + расчёт исходя из цифр, а «частые запросы» к сожалению не точная метрика.
Лучше ещё тем, что не придётся иметь базу и все из этого вытекающее. Athena умеет сохранять результаты запроса на s3 и их можно повторно использовать.
Я вчера скидывал статью как Битрикс у себя построил аналитику.
Насчёт стоимости - тут только тест + расчёт исходя из цифр, а «частые запросы» к сожалению не точная метрика.
Так мне не для аналитики.
AP
Ну это ж название )
Многие задачи ML вообще решаются статистическими алгоритмами, но это все равно называют ML
Многие задачи ML вообще решаются статистическими алгоритмами, но это все равно называют ML
AP
Athena это не база данных. Она хорошо читает данные, например экспорты из других структур. Поэтому я и задавал вопрос, про характер работы с этими данными.