Поскольку Amazon Redshift оптимизирован для чтения, а не для записи, как я могу управлять процедурой медленно меняющегося измерения с помощью инструмента ETL, в моем случае Pentaho Data Integration?
Поскольку инструмент ETL будет выполнять обновления/вставки (поиск/обновление измерений) построчно, производительность будет крайне низкой.
Кто-нибудь уже прошел через эту проблему?
Обновления в Redshift медленные, потому что обновление — это последовательность операций, выполняемых в транзакции:
И все это должно быть скоординировано между узлами.
Обновление одной строки может занять до тех пор, пока не будет обновлено 1000 строк. Что еще хуже, так как обновления очень длинные и требуют блокировки записи, они блокируют запросы на долгое время, что значительно влияет на общую производительность системы.
Есть 3 способа сделать это быстрее (все из опыта):
Избегайте обновлений.
Если у вас есть условие, позволяющее отличить новые строки от старых, просто добавьте новые в таблицу и измените свои запросы с этим условием. Вы будете удивлены, увидев, что Redshift работает быстрее — хотя каждый запрос может стать немного сложнее, поскольку нет обновлений, которые перегружают систему, эти запросы могут выполняться быстрее (убедитесь, что ключи dist указаны правильно).
Например, условие максимальной временной метки для бизнес-ключа выполняется очень быстро (особенно если бизнес-ключ является удаленным ключом — все это будет выполняться параллельно).
Это предпочтительное решение.
Выполняйте обновления пакетно.
Если ваше обновление применимо к ряду строк, обновите их все сразу с условием where. Партии по 1000 штук работают хорошо, хотя ваш пробег может отличаться.
Создайте таблицу, в которой вы храните «новые» строки, а затем выполните обновление с помощью объединения после того, как эта таблица будет иметь размер не менее 1000 строк.
Dimension Lookup/Update, вероятно, подойдет. - person Brian.D.Myers schedule 19.05.2016