AWS Redshift RG: Graviton виходить на арену аналітики

Платформне рішення, яке цього кварталу потрапляє на стіл CTO, вже не зводиться до вибору між «warehouse та lakehouse». Питання тепер у тому, чи буде наступне трирічне зобов'язання з аналітики написане на x86-кредитах Snowflake, DBU Databricks або на Redshift з Arm-процесором. AWS щойно зробила третій варіант значно важчим для ігнорування, і причина — в юніт-економіці.

Що сталося

Цього тижня AWS запустила RG-інстанси на базі Graviton для Amazon Redshift, як повідомив Data Center Knowledge 15 травня. Заявлені показники від AWS: до 2,2 рази швидша продуктивність сховища даних порівняно з попереднім поколінням RA3, при цьому вартість за vCPU нижча на 30%. Робочі навантаження Apache Iceberg виконуються до 2,4 рази швидше, Apache Parquet — до 1,5 рази швидше, обидва показники виміряні відносно RA3.

Структурні зміни важливіші за бенчмарк-слайди. RG-інстанси об'єднують запити до warehouse та data lake в єдиний рушій. AWS заявляє, що запити до даних у warehouse та до відкритих табличних форматів на S3 тепер виконуються з одного обчислювального рівня — без окремої інфраструктури Redshift Spectrum, яка раніше тарифікувалася за кожен відсканований терабайт. Ці плати за сканування тут зникають.

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

Метт Кімбол, віцепрезидент та головний аналітик з технологій дата-центрів у Moor Insights & Strategy, заявив Data Center Knowledge, що «AWS вирішує серйозні проблеми, які хвилюють кожне підприємство: продуктивність, TCO і складність». Щодо різниці у ціні та продуктивності він висловився прямо: «Дивлячись на цифри — у 2,2 рази швидше для warehouse-навантажень і у 2,4 рази для Apache Iceberg разом із на 30% нижчою ціною за vCPU — важко вважати це лише поступовим покращенням у метриці вартість/продуктивність». Кімбол також виділив стратегічний аспект: «AWS, схоже, просуває свій кремній вище по стеку. Не лише в інфраструктуру на зразок EC2, а й безпосередньо в рівень даних та аналітики».

Технічна анатомія

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

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

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

По-третє, табличний формат. Iceberg тепер є повноцінним елементом обчислювального шляху Redshift, а не федеративним гостем. Це тихе, але значуще позиціонування: AWS сигналізує, що дані клієнтів зберігатимуться у відкритих форматах на об'єктному сховищі, а warehouse стає рушієм запитів, який ви орендуєте поверх нього. Прив'язка зміщується від гравітації даних до ергономіки рушія — це зовсім інші переговори при поновленні контракту.

Формулювання «агентний AI» — це маркетинг, але субстрат реальний. Агентні навантаження генерують нерівномірні, непередбачувані патерни читання широких наборів даних. Плата за терабайт сканування робила це фінансово непривабливим. Її усунення змінює те, які навантаження економічно доцільно виконувати в інтерактивному режимі.

Хто постраждає

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

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

Усередині корпоративного IT збитки цікавіші. Команди платформ даних, які побудували складний інструментарій управління витратами від Spectrum до Redshift — маршрутизатори запитів, сповіщення про бюджет сканування, стратегії матеріалізованих представлень для уникнення плати за терабайт — щойно побачили, як частина цієї роботи стала легасі. Формулювання самого Кімбала актуальне тут: «Як лідер корпоративного IT, я хочу скоротити обсяг дублювання та переміщення даних». Команди, які побудували кар'єру на управлінні цим дублюванням і переміщенням, тепер мають меншу площину для захисту.

CFO будь-якого fintech на стадії series-B або iGaming-оператора, що використовує Redshift, цього тижня має запитати VP Engineering: як виглядає наш річний рахунок за Redshift на RG-інстансах при поточному навантаженні, і скільки коштуватиме міграція, щоб це з'ясувати? Це дворижневий спайк, а не ініціатива на квартал, і відповідь переформатує бюджет платформи даних на FY27. Якщо VP Engineering не зможе надати цифру протягом десяти робочих днів, data-організація має проблему з плануванням незалежно від AWS.

Регульовані вертикалі отримують додаткову перевагу. Об'єднання Spectrum у ядро рушія зменшує кількість сервісних меж, про які аудиторам потрібно міркувати. Менше логів окремих сервісів, менше IAM-поверхонь, менше рядків у рахунках для звірки з вимогами щодо резидентності даних. GC ліцензованих операторів повинні вітати це — тихо.

Дорожня карта для data-команд

Конкретні кроки на наступні 30–90 днів, упорядковані за пріоритетністю.

Запустіть бенчмарк RG на вашому реальному навантаженні, а не на бенчмарках AWS. Цифри 2,2x та 2,4x — опубліковані постачальником. Візьміть три найдорожчих регулярних запити (ті, на які скаржаться продакт-менеджери) та два Spectrum-завдання з найвищими витратами на сканування, відтворіть їх на RG-кластері, зафіксуйте і час виконання, і прогнозовані щомісячні витрати. Ці дані — ваш аргумент на наступних переговорах із Snowflake або Databricks, навіть якщо ви ніколи не мігруєте.

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

Перегляньте свій семантичний рівень. Якщо трансформації живуть у dbt проти Redshift, шлях міграції простий — моделі портативні між warehouse. Якщо вони живуть у конструкціях, специфічних для Snowflake або Databricks, вартість прив'язки щойно стала рядком, який варто кількісно оцінити.

Поговоріть зі своєю командою облікових записів AWS щодо знижок за зобов'язаннями на RG до того, як стандартний прайс стане вихідним рівнем для переговорів. Запуски нових інстансів — це вікно, коли представники AWS мають найбільшу гнучкість. Це вікно відкрите зараз і закриється, як тільки SKU стане мейнстрімним.

Нарешті, щодо найму: налаштування продуктивності для Arm-native є нішевою навичкою, яка незабаром матиме більше значення. Пул інженерів, які можуть профілювати векторизований рушій запитів на Graviton і міркувати про локальність кешу NVMe, менший за пул тих, хто може налаштовувати warehouse Snowflake. Відповідно скоригуйте формулювання JD та діапазони компенсацій, поки ринок не зробив це за вас.

Ключові висновки

• AWS Redshift RG-інстанси заявляють до 2,2 рази швидшу продуктивність warehouse та на 30% нижчу вартість за vCPU порівняно з RA3, а навантаження Iceberg — до 2,4 рази швидше.
• Інтегрований рушій усуває окрему інфраструктуру Redshift Spectrum та плату за сканування терабайтів, змінюючи юніт-економіку запитів до озера даних.
• Контроль AWS над стеком від кремнію до SQL через Graviton є структурною ціновою перевагою, яку Snowflake та Databricks не можуть легко відтворити на рівні субстрату.
• Конкурентний тиск найбільш відчутний для середньоринкових акаунтів Snowflake з амбіціями щодо Iceberg та для внутрішнього інструментарію управління витратами, побудованого навколо моделі тарифікації Spectrum.
• Команди, що оцінюють зобов'язання щодо аналітичної платформи на FY27, вже зараз мають запитати, скільки коштуватимуть їхні реальні навантаження на RG — до наступних переговорів із будь-яким чинним постачальником.