Самый большой Redshift Cluster может быть 128 нод. Я работаю с таким кластером. 128 Node типа dc2.8xlarge. Это максимально возможное кол-во нод и одновременно недостаток Redshift. 326 ТБ данных (с компрессией это в 2 раза больше данных). И этого нам не хватает. То есть вроде как облако, где можно кликнуть и удвоить мощность, а вроде и уже нельзя. Но это не главная проблема хранилище данных. Главная проблема это кол-во одновременных запросов. (concurrency). То есть кластер может одновременно обрабатывать 15-20 запросов, остальные в очередь. Есть также Work Load Manager (это можно для каждого пользователя настраивать правила, сколько может быть одновременных запросов и при каких условиях убивать плохие запросы). Самая дорогая операция - это копирование данных между нодами (data distribution), именно поэтому единственное что важно знать в аналитических хранилищах - это правила распределения данных и варианты (Distribution style, sorty key), чтобы снизить нагрузку на копирование ТБ данных по сети.

У меня была задача, пересчитать метрика за 2018 и 2019 года. Я не могу это выполнить одним запросом, так как если я запущу запрос, где данных больше 1 недели, WLM его убьет. В итоге у меня 1 запрос - это 1 день. Значит надо где-то 600 раз запустить один и тот же джоб. То есть можно это сделать programmatically. Вот когда нам нужно знать Python. Сделать цикл, который будет запускать джоб (ее API). Недолго думая, я запустил все это дело с параметром 1000 параллельных запросов. И я сделал это несколько раз.

Я не знал несколько деталей, сколько одновременных запросов может обрабатывать Redshift от этого пользователя (оказалось 3), сколько обычно Redshift обрабатывает запросов (оказалос 1500-1800). В результате выстроилась очередь в 3500 запросов и несколько дней.

Ситуация мне напомнила книгу "Продавец Обуви" - "Вас запоминают не за правила, которым вы следуете, а за правила, которые вы нарушаете". В целом, это проблема дизайна, то есть когда строили хранилище, не знали, что с ним будет дальше. И это уже второй Redshift, который переживает сложные времена. Другая команда, имела похожие проблемы, в итоге они заменили все на Озеро Данных (S3+Athena). Но главный challenge для озера данных и big data платформ, это GDPR, то есть как удалить клиента, если он лежит в каком-то Parquet файле.