AWS Redshift RG: Graviton приходит в аналитический стек

Платформенное решение, которое оказывается на столе CTO в этом квартале, уже не сводится к вопросу «хранилище против озера данных». Теперь речь идёт о том, на чём будет зафиксирован следующий трёхлетний аналитический контракт: на кредитах x86 Snowflake, DBU от Databricks или Arm-версии Redshift. AWS только что сделала третий вариант значительно сложнее для игнорирования — и главная причина тому — юнит-экономика.

Что произошло

На этой неделе AWS запустила Graviton-инстансы RG для Amazon Redshift, как сообщил Data Center Knowledge 15 мая. Ключевые цифры от AWS: до 2.2x быстрее производительность хранилища данных по сравнению с предыдущим поколением RA3 при снижении стоимости на 30% за vCPU. Рабочие нагрузки Apache Iceberg выполняются до 2.4x быстрее, Apache Parquet — до 1.5x быстрее, оба показателя измерены относительно RA3.

Структурное изменение важнее, чем цифры в маркетинговых слайдах. Инстансы RG объединяют запросы к хранилищу и к озеру данных в единый движок. AWS утверждает, что запросы к данным в хранилище и к форматам открытых таблиц в S3 теперь выполняются из одного вычислительного слоя — без отдельной инфраструктуры Redshift Spectrum, которая исторически тарифицировалась за каждый сканированный терабайт. Плата за сканирование на этом пути устранена.

AWS позиционирует инстансы явно для «аналитических и агентских AI-нагрузок», которым требуется низколатентный доступ к большим наборам данных. Что внутри: встроенный векторизованный движок запросов обрабатывает данные Iceberg и Parquet непосредственно на узлах кластера, а локальное кэширование NVMe держит горячие наборы данных близко к вычислительным ресурсам.

Мэтт Кимбалл, вице-президент и главный аналитик по технологиям для дата-центров в Moor Insights & Strategy, рассказал Data Center Knowledge, что «AWS решает серьёзные проблемы, актуальные для каждого предприятия: производительность, TCO и сложность». В отношении разрыва по цене и производительности он был прямолинеен: «Когда видишь цифры вроде 2.2x быстрее для нагрузок хранилища данных и 2.4x для Apache Iceberg наряду с ценой за vCPU на 30% ниже, сложно считать это инкрементальным улучшением по метрике стоимость/производительность». Кимбалл также обозначил стратегический вывод: «AWS, похоже, продвигает свой кремний вверх по стеку. Не только в инфраструктуру вроде EC2, но и в слой данных и аналитики как таковой».

Техническая анатомия

Три составляющих делают всю работу, и руководителям платформ следует понять каждую из них отдельно, поскольку у них разные жизненные циклы на дорожной карте.

Первое — кремний. Graviton — это семейство пользовательских Arm-процессоров AWS. Внедрение их под Redshift означает, что AWS владеет стеком маржи от пластины до SQL-парсера. Именно так снижение цены на 30% за vCPU сочетается с приростом производительности: AWS не перепродаёт кремний Intel или AMD на этом уровне, поэтому может устанавливать цены исходя из собственной кривой затрат, а не от поставщика. Snowflake и Databricks, работающие на чужих вычислительных ресурсах, не могут воспроизвести эту математику без пересмотра субстрата, на котором стоят. Клиенты Snowflake, изучающие модель кредитов, должны задуматься, кто поглотит ценовое преимущество Arm в следующем цикле продления.

Второе — движок. Исторически Redshift запрашивал внешние данные в S3 через Redshift Spectrum — отдельный сервис со своей инфраструктурой и тарификацией за терабайт сканирования. Архитектура RG устраняет этот промежуточный шаг. Векторизованный движок на кластере читает Iceberg и Parquet напрямую, с локальным кэшированием NVMe для рабочего набора. Это то же самое архитектурное направление, которое ClickHouse избрал несколько лет назад: векторизованное исполнение близко к хранилищу с агрессивным кэшированием. Тот факт, что AWS пришла к этому дизайну, говорит вам о том, где оседает мейнстримная облачная аналитика.

Третье — формат таблиц. Iceberg теперь является полноправным участником вычислительного пути Redshift, а не федеративным гостем. Это тихая, но значимая ставка: AWS сигнализирует, что данные клиентов будут храниться в открытых форматах в объектном хранилище, а хранилище превращается в движок запросов, который арендуется поверх него. Привязка смещается от гравитации данных к эргономике движка — а это совершенно другой разговор при продлении контракта.

Формулировка «агентский AI» — маркетинг, но субстрат реален. Агентские нагрузки генерируют пиковые, непредсказуемые паттерны чтения широких наборов данных. Плата за ТБ сканирования делала это финансово невыгодным. Её устранение меняет то, какие нагрузки экономически целесообразно выполнять в интерактивном режиме.

Кто пострадает

Начнём с очевидной цели: средний сегмент клиентской базы Snowflake. Команды, ведущие стабильные нагрузки хранилища на Snowflake с растущими амбициями в области Iceberg, — это именно тот сегмент, против которого AWS только что выставила цены. Разрыв в 30% за vCPU не выльется один к одному в снижение счёта на 30% (нагрузки несопоставимы напрямую), но даёт CFO достаточно аргументов для получения скидки при продлении или открытия параллельного POC. Недавняя Iceberg-инициатива Snowflake была призвана защитить этот фланг. Теперь ей нужно защищать его ещё и по цене.

Databricks подвержена меньшим прямым рискам, поскольку её центр тяжести — ML и Spark-нагрузки на Delta Lake, но цифры по производительности Iceberg сжимают аналитический use-case, в котором Databricks SQL конкурирует с Redshift. Ожидайте более острых переговоров по ценообразованию Photon.

Внутри корпоративных IT потери интереснее. Команды платформ данных, построившие сложную инструментарий управления затратами Spectrum-to-Redshift — маршрутизаторы запросов, оповещения о бюджете сканирования, стратегии материализованных представлений для избежания платы за ТБ, — только что увидели, как значительная часть этой работы стала легаси. Формулировка самого Кимбалла актуальна здесь: «Как руководитель корпоративных IT, я хочу сократить объём дублирования и перемещения данных». Команды, выстроившие карьеру на управлении этим дублированием и перемещением, теперь имеют меньшую поверхность для защиты.

CFO любого финтех-оператора серии B или iGaming-компании, работающей на Redshift, должен на этой неделе задать вопрос VP Engineering: как выглядит наш годовой счёт за Redshift на инстансах RG при текущей нагрузке и каковы затраты на миграцию, чтобы это выяснить? Это двухнедельный spike, а не квартальная инициатива, а ответ переформулирует бюджет платформы данных на FY27. Если VP Eng не может предоставить цифру в течение десяти рабочих дней, у организации данных есть проблема с планированием, не зависящая от AWS.

Регулируемые вертикали получают дополнительный бонус. Объединение Spectrum в основной движок сокращает количество сервисных границ, которые должны анализировать аудиторы. Меньше журналов по каждому сервису, меньше IAM-поверхностей, меньше строк в биллинге для сверки с требованиями резидентности данных. Юристы лицензируемых операторов должны тихо радоваться этому.

Руководство для команд данных

Конкретные шаги на ближайшие 30–90 дней, упорядоченные по приоритету.

Проведите бенчмарк RG на своей реальной нагрузке, а не на нагрузке AWS. Цифры 2.2x и 2.4x опубликованы вендором. Возьмите три самых дорогих повторяющихся запроса (те, на которые жалуются продакт-менеджеры) и две задачи Spectrum с наибольшей стоимостью сканирования, воспроизведите их на кластере RG, зафиксируйте как астрономическое время, так и прогнозируемые ежемесячные затраты. Эти данные станут аргументом на ближайшем продлении Snowflake или Databricks, даже если вы никогда не мигрируете.

Проведите аудит готовности к Iceberg. Если ваше озеро по-прежнему представляет собой Parquet-on-S3 с каталогом Glue и без формата таблиц, вы упускаете большую половину прироста производительности. Внедрение Iceberg теперь — это решение о закупках, а не только инженерное предпочтение. Задокументируйте путь миграции и затраты.

Пересмотрите семантический слой. Если трансформации живут в dbt против Redshift, история миграции проста — модели переносимы между хранилищами. Если они живут в специфичных для Snowflake или Databricks конструкциях, стоимость привязки только что превратилась в строку, которую стоит оцифровать.

Поговорите с командой аккаунта AWS о скидках за committed-use на RG до того, как стандартная прейскурантная цена станет базой для переговоров. Запуск новых инстансов — это окно, в котором у представителей AWS наибольшая гибкость. Это окно открыто сейчас и закроется, как только SKU станет массовым.

Наконец, о найме: настройка производительности для Arm-нативных сред — это нишевый навык, который вот-вот станет гораздо более востребованным. Пул инженеров, способных профилировать векторизованный движок запросов на Graviton и рассуждать о локальности кэша NVMe, меньше, чем пул тех, кто умеет настраивать хранилище Snowflake. Скорректируйте формулировки вакансий и вилки компенсаций до того, как рынок сделает это за вас.

Ключевые выводы

• Инстансы AWS Redshift RG заявляют о производительности хранилища до 2.2x выше и стоимости за vCPU на 30% ниже, чем RA3, с ускорением Iceberg-нагрузок до 2.4x.
• Интегрированный движок устраняет отдельную инфраструктуру Redshift Spectrum и плату за сканирование терабайт, меняя юнит-экономику запросов к озеру данных.
• Владение AWS стеком от кремния до SQL через Graviton создаёт структурное ценовое преимущество, которое Snowflake и Databricks не могут легко воспроизвести на уровне субстрата.
• Конкурентное давление сильнее всего ощущается на среднем сегменте клиентов Snowflake с амбициями в области Iceberg и на внутренних инструментах управления затратами, выстроенных вокруг модели биллинга Spectrum.
• Команды, оценивающие обязательства по аналитической платформе на FY27, должны уже сейчас выяснить, во что обойдётся их реальная нагрузка на RG, — до следующего разговора о продлении с любым действующим вендором.