Amazon redshift: объемная вставка против COPYing из s3

У меня есть кластер красных смещений, который я использую для некоторых аналитических приложений. У меня есть входящие данные, которые я хотел бы добавить в таблицу clicks. Допустим, у меня есть ~ 10 новых "кликов", которые я хочу хранить каждую секунду. Если возможно, я бы хотел, чтобы мои данные были доступны как можно скорее в режиме красного смещения.

Из того, что я понимаю, из-за столбчатого хранилища производительность вставки плохая, поэтому вставлять ее нужно партиями. Мой рабочий процесс заключается в том, чтобы хранить клики в Redis, и каждую минуту я вставляю ~ 600 кликов из Redis в красное смещение в виде пакета.

У меня есть два способа вставить партию кликов в красное смещение:

Я провел несколько тестов (это было сделано для таблицы clicks с уже 2 миллионами строк):

             | multi-row insert stragegy |       S3 Copy strategy    |
             |---------------------------+---------------------------+
             |       insert query        | upload to s3 | COPY query |
-------------+---------------------------+--------------+------------+
1 record     |           0.25s           |     0.20s    |   0.50s    |
1k records   |           0.30s           |     0.20s    |   0.50s    |
10k records  |           1.90s           |     1.29s    |   0.70s    |
100k records |           9.10s           |     7.70s    |   1.50s    |

Как вы можете видеть, с точки зрения производительности, похоже, я ничего не получаю, сначала скопировав данные в s3. Время upload + copy равно времени insert.

Вопросы:

Каковы преимущества и недостатки каждого подхода? Какова лучшая практика? Я что-то пропустил?

И дополнительный вопрос: возможно ли для красного смещения COPY данные из s3 автоматически через манифест? Я имею в виду КОПИРОВАНИЕ данных, как только новые файлы .csv добавляются в s3? Док здесь и здесь. Или я должен сам создать фонового работника для запуска команд COPY?

Мой быстрый анализ:

В документации о согласованности нет упоминания о загрузке данных через многорядные вставки. Похоже, что предпочтительным способом является COPY с s3 с уникальными объектными ключами (каждый .csv на s3 имеет свое уникальное имя)...

  • S3 Copy strategy:
    • ПРОФИ: похоже на хорошую практику из документов.
    • CONS: больше работы (мне нужно управлять ведрами и манифестами и cron, который запускает команды COPY...)
  • Multi-row insert strategy
    • ПРОФИ: Меньше работы. Я могу вызвать запрос insert из моего кода приложения
    • Минусы: не похоже на стандартный способ импорта данных. Я что-то пропустил?

Ответы

Ответ 1

Redshift - это аналитическая БД, и она оптимизирована, чтобы вы могли запрашивать миллионы и миллиарды записей. Он также оптимизирован для быстрого доступа к этим записям в Redshift с помощью команды COPY.

Конструкция команды COPY предназначена для параллельной загрузки нескольких файлов в несколько узлов кластера. Например, если у вас есть 5 небольших кластеров node (dw2.xl), вы можете копировать данные в 10 раз быстрее, если у вас есть несколько файлов (например, 20). Существует баланс между количеством файлов и количеством записей в каждом файле, так как каждый файл имеет небольшие накладные расходы.

Это должно привести к балансу между частотой COPY, например, каждые 5 или 15 минут, а не каждые 30 секунд, а также размером и количеством файлов событий.

Еще один момент для рассмотрения - 2 типа узлов Redshift, которые у вас есть: SSD (dw2.xl и dw2.8xl) и магнитные (dx1.xl и dw1.8xl). SSD быстрее с точки зрения проглатывания. Поскольку вы ищете очень свежие данные, вы, вероятно, предпочитаете работать с SSD-устройствами, которые, как правило, дешевле для менее 500 ГБ сжатых данных. Если со временем у вас будет более 500 ГБ сжатых данных, вы можете рассмотреть возможность запуска двух разных кластеров, один для "горячих" данных на SSD с данными прошлой недели или месяца, а другой для "холодных" данных на магнитных дисках со всеми ваши исторические данные.

Наконец, вам действительно не нужно загружать данные в S3, что является основной частью вашего времени приема пищи. Вы можете скопировать данные непосредственно с ваших серверов с помощью опции SSH COPY. Подробнее об этом здесь: http://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-remote-hosts.html

Если вы можете разделить очереди Redis на несколько серверов или, по крайней мере, несколько очередей с разными файлами журналов, вы, вероятно, получите очень хорошую скорость чтения в секунду.

Другим шаблоном, который вы, возможно, захотите рассмотреть, чтобы разрешить почти аналитику в реальном времени, является использование Amazon Kinesis, потоковой службы. Он позволяет запускать аналитику данных в задержке секунд и в то же время подготавливать данные для копирования в Redshift более оптимизированным способом.

Ответ 2

S3 копия работает быстрее в случае больших нагрузок данных. когда вы скажете, что тысячи миллионов записей нужно загрузить в redshift, тогда s3 upload + copy будет работать быстрее, чем вставлять запросы.

Копия S3 работает в параллельном режиме.

Когда вы создаете таблицу и вставляете ее, существует ограничение на размер партии. Максимальный размер для одного SQL - 16 МБ. Поэтому вам нужно позаботиться о размере пакета SQL (зависит от размера каждого запроса на вставку)

Копия S3 автоматически применяет кодировку (сжатие) для вашей таблицы. Когда вы создаете таблицу и выполняете пробную загрузку с использованием копии, вы можете увидеть, как автоматически применяется сжатие.

Но если вы используете команду insert для начала, вы заметите, что не было применено сжатие, что в некоторых случаях приведет к большему количеству места для таблицы в красном смещении и медленном времени обработки запросов.

Если вы хотите использовать команды вставки, тогда создайте таблицу, в которой каждый столбец применяет кодировки для экономии места и более быстрого времени отклика.

Ответ 3

Возможно, стоит выполнить микрозадачу при выполнении массовых загрузок в Redshift. Эта статья заслуживает того, чтобы ее можно было прочитать, так как она также содержит другие методы, которые следует соблюдать для лучшей производительности комманды COPY.

http://blogs.aws.amazon.com/bigdata/post/Tx2ANLN1PGELDJU/Best-Practices-for-Micro-Batch-Loading-on-Amazon-Redshift

Ответ 4

Результаты моего теста немного отличаются. Я загружал файл CSV в Redshift с рабочего стола ОС Windows.

  • Строка вставки была самой медленной.
  • Многорядная вставка была в 5 раз быстрее, чем вставка строк.
  • S3 + COPY была в 3 раза быстрее, чем многорядная вставка.

Что поспособствовало ускорению объемной вставки S3 + COPY.

  • Тот факт, что вам не нужно анализировать оператор вставки из строки CSV.
  • Поток был сжат перед многочастной загрузкой на S3.
  • Команда COPY была чрезвычайно быстрой.

Я собрал все свои выводы в один скрипт Python CSV_Loader_For_Redshift

Ответ 5

Как вы можете видеть в результатах загрузки в RedShift indipendent review, команда COPY - это, безусловно, путь.