Skip to content
RiverCore
Ставка Oracle на Lakehouse: 63% компаний не готовы к AI
Oracle AI Lakehousedata federationautonomous data warehouseOracle AI Lakehouse data federation strategyenterprise AI data management readiness

Ставка Oracle на Lakehouse: 63% компаний не готовы к AI

25 сен 20268 мин. чтенияSarah Chen

Шестьдесят три процента организаций либо не имеют надлежащих практик управления данными для AI, либо не знают, есть ли они у них. Эта единственная цифра Gartner, на которую ссылается Oracle в рамках запуска Autonomous AI Lakehouse, — ключевая. Она переосмысляет продукт не как обновление хранилища, а как ставку на то, что большинство предприятий никогда не консолидируют свои данные на одной платформе, и что побеждающая архитектура — та, которая делает запросы сквозь хаос, а не пытается его устранить.

Переименование Autonomous Data Warehouse в Autonomous AI Lakehouse — это ответ Oracle второго поколения на Snowflake и Databricks. Интересно предположение в основе: сначала совместимость, потом миграция — или никогда.

Цифры

Начнём с того, что реально заявляется. Как сообщает Oracle Blogs от 24 сентября, AI Lakehouse поддерживает три отправные точки: модернизация локального хранилища Oracle, расширение Autonomous Database или подключение данных Oracle к данным, хранящимся в других местах. Два из трёх путей явно предполагают, что клиент не консолидирует данные. Это значительный сдвиг позиции по сравнению со стандартным предложением хранилищ последнего десятилетия, которое сводилось к «перенесите всё сюда».

Цифра 63% от Gartner — это якорь. Читайте внимательно: там не говорится, что у 63% компаний плохие практики работы с данными для AI. Там говорится, что 63% либо не имеют таких практик, либо не знают, есть ли они у них. Категория «не знают» — более показательная половина, поскольку подразумевает отсутствие инструментов управления и отслеживания происхождения данных для самооценки. Именно этот пробел призван закрыть AI Data Catalog с его архитектурой каталога каталогов, связывающей метаданные из AWS Glue, Databricks Unity Catalog и Snowflake Horizon Catalog в единое представление.

На стороне запросов источник называет два функции производительности с различными ролями. Lake Cache хранит часто используемые внешние данные локально в AI Lakehouse. Data Lake Accelerator временно добавляет вычислительные мощности для масштабных сканирований внешних данных в объектном хранилище и освобождает ресурсы по завершении запроса. Это два разных типа задач: кэш — для повторных небольших чтений, ускоритель — для пиковых сканирований. Единственный раскрытый кейс клиента — SKY Brazil, который сообщил об улучшении скорости запросов к внешним данным в объектном хранилище в ходе раннего тестирования и использовал масштабирование по требованию для контроля затрат.

Источник не раскрывает величину улучшения SKY Brazil, а это важно, поскольку «улучшение» в данной категории может означать от 1,2x до 100x. Без процента, набора бенчмарков или базового движка для сравнения это — отзыв, а не бенчмарк. Полезный ориентир: если Data Lake Accelerator конкурентоспособен с ведущими движками для внешних таблиц на рабочих нагрузках типа TPC-DS поверх Iceberg, Oracle должна опубликовать конкретные коэффициенты в течение двух кварталов. Если этого не произойдёт, предполагайте однозначный прирост на холодных сканированиях.

Что действительно нового

Отбросим маркетинг — в этом релизе по сравнению с прежней позицией Autonomous Data Warehouse действительно три новых аспекта.

Первый — нативная поддержка Apache Iceberg. Сейчас это обязательный минимум, но включение этой функции сигнализирует о том, что Oracle признала: война форматов открытых таблиц окончена, и Iceberg победил. Для команд, уже стандартизированных на Iceberg через Databricks или Snowflake, это означает, что Oracle перестаёт быть изолированным островом данных. Поддерживает ли реализация Iceberg от Oracle полную спецификацию — включая скрытое партиционирование, граничные случаи эволюции схемы и семантику путешествий во времени — в источнике не раскрывается. Это первое, что инженерные команды должны проверить в POC.

Второй — паттерн каталога каталогов. Вместо попытки заменить Unity Catalog или Horizon Oracle федерирует их. Это архитектурно разумно и политически умно. Это также признаёт, что Oracle не станет основным каталогом для современной команды данных, уже работающей с Databricks. Ставка заключается в том, что предприятиям с тяжёлыми требованиями к управлению нужен суперкаталог над платформенными каталогами, и Oracle хочет стать этим слоем.

Третий — питч конвергентного движка переосмысляется для эпохи AI. Источник описывает реляционные, JSON, граф, пространственные, векторные и XML-данные на общей основе, использующей единый менеджер транзакций, оптимизатор и контроль доступа. Векторная составляющая — это то, что ново по сравнению с предыдущим поколением. AI Vector Search находит релевантную информацию на основе смысла, а не точного совпадения ключевых слов, а Select AI переводит вопросы на естественном языке в SQL. Ни то, ни другое не уникально для Oracle в 2026 году. Уникальным может быть запуск этого на той же поверхности управления, что и OLTP-данные, без отдельной векторной базы данных.

Deep Data Security, применяющий политики доступа непосредственно в базе данных и распространяющий их на AI-агентов, действующих от имени пользователя, — это то, за чем стоит следить. Контроль доступа в масштабе агента — это место, где большинство стеков сейчас скреплены «изолентой». Если Oracle может применять его на уровне базы данных, а не в коде приложений, это реальное преимущество для регулируемых отраслей.

Что уже учтено командами данных

Большинство опытных инженеров по данным уже ожидали федерации и поддержки Iceberg. Этот поезд ушёл, когда Snowflake добавил таблицы Iceberg, а Databricks взял обязательство по Unity Catalog OSS. Появление Oracle с теми же возможностями в конце 2026 года — не лидерский шаг, а оборонительный. Рынок это уже учёл.

Также уже учтено: перевод естественного языка в SQL. Select AI — это компетентный обязательный минимум, а не дифференциатор. Каждый вендор хранилищ выпустил что-то подобное в той или иной форме. Интересный вопрос — точность на сложных джойнах через федерированные источники, что источник не бенчмаркирует.

Что ещё не учтено и что может иметь реальное значение — это ставка на каталог каталогов. Преобладающее предположение в современном стеке данных состоит в том, что семантический слой dbt, Unity Catalog или Horizon будут служить корнем управления для своих платформ, а лёгкие межплатформенные инструменты обеспечат федерацию. Oracle утверждает, что над всеми ними нужен более тяжёлый слой управления. Если регулируемые отрасли согласятся, это реальный захват территории. Если нет — AI Data Catalog станет ещё одним метаданным-силосом в комнате, уже полной ими.

Другой недооценённый аспект — поведение Data Lake Accelerator по освобождению ресурсов по завершении запроса. Эфемерные пиковые вычисления для масштабных сканирований — это то, что большинство команд реально хотят от lakehouse: платить за сканирование, а не за постоянный кластер. Отражает ли ценовая модель Oracle это обещание — открытый вопрос. Экономику на уровне запроса из источника мы не знаем.

Взгляд от противного

Консенсусная оценка этого анонса — «Oracle нагоняет». Я бы предложил более интересную интерпретацию: Oracle тихо перепозиционируется вокруг тезиса, который большинство вендоров отвергают: предприятия никогда полностью не модернизируются.

Snowflake и Databricks построили свой бизнес на противоположной предпосылке — что клиенты будут постепенно мигрировать рабочие нагрузки на их платформу, пока устаревшее наследие не иссякнет. Oracle теперь продаёт CIO, который просмотрел счета за три года миграции, увидел, что локальное хранилище Oracle всё ещё ведёт главную книгу, и решил, что миграция не завершится в это десятилетие. Для такого покупателя «расширьте то, что есть, и федерируйте остальное» — более честный питч, чем «перенос за 18 месяцев».

Контрарный риск состоит в том, что эта позиция превращается в самоисполняющуюся стагнацию. Федерация архитектурно элегантна и операционно сложна. Межкаталоговое отслеживание происхождения, межмоторная оптимизация запросов и последовательная семантика безопасности между AWS Glue, Unity и Horizon — нерешённые задачи в масштабе. Если AI Lakehouse поставит маркетинг, но не операционную глубину, клиенты получат худшее из обоих миров: lakehouse, обещающий унифицированную аналитику, но всё равно заставляющий инженеров работать с тремя каталогами и четырьмя движками запросов. Этот сценарий провала более вероятен, чем признаёт вендор.

Вопросы без ответов

Несколько ориентиров, за которыми стоит следить. Источник упоминает Autonomous Data Guard, обеспечивающий автоматическое переключение при сбое, и отмечает, что подходящие развёртывания AI Lakehouse получат SLA на уровне 99-с-чем-то процентов, при этом точная цифра обрезана в тексте источника. Это существенный пропуск. Разница между 99,9%, 99,95% и 99,99% — примерно порядок величины в допустимом простое за год, и корпоративные покупатели рассчитывают контракты исходя из этой цифры. До публикации полного SLA от Oracle предполагайте консервативный минимум.

Мы также не знаем цену пиковых вычислений Data Lake Accelerator, точность Select AI на федерированных запросах, охватывающих три каталога, или конкурентоспособность AI Vector Search на векторных наборах миллиардного масштаба по сравнению со специализированными векторными базами данных. Каждый из этих вопросов можно прояснить в рамках двухнедельного POC. Если Oracle уверена, ждите опубликованных бенчмарков к Q1 2027. Если они не появятся к середине 2027 года, тихий ответ — цифры не впечатляют.

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

  • Цифра 63% — это и есть реальный питч. Oracle нацелена на большинство предприятий, признающих, что они не готовы к AI на стороне данных, и продаёт федерацию как короткий путь.
  • Два из трёх стартовых сценариев не предполагают миграции. Это значимый сдвиг позиции, ставящий Oracle в прямую конкуренцию с философией «расширяй, а не заменяй», а не с питчем о консолидации.
  • Каталог каталогов — дифференциатор, за которым нужно следить. Объединение AWS Glue, Unity Catalog и Horizon в один уровень управления — либо захват территории, либо ещё один силос. Это зависит от операционной глубины, которую Oracle публично ещё не продемонстрировала.
  • Отзыву SKY Brazil не хватает цифр. «Улучшение скорости запросов» без коэффициента или базового показателя — это данные, а не бенчмарк. Требуйте конкретики в любом POC.
  • Обрезанная цифра SLA и отсутствующие ценовые детали — красные флаги. Следите за тем, опубликует ли Oracle полный SLA, цену пиковых вычислений и бенчмарки точности Select AI в течение двух кварталов. Молчание после середины 2027 года — само по себе ответ.

Часто задаваемые вопросы

В: Что такое Oracle Autonomous AI Lakehouse и чем он отличается от Autonomous Data Warehouse?

AI Lakehouse — это следующее поколение Autonomous Data Warehouse, добавляющее нативную поддержку Apache Iceberg, AI Data Catalog, федерирующий внешние каталоги, а также такие функции, как Select AI, AI Vector Search, Lake Cache и Data Lake Accelerator. Ключевое отличие — явная поддержка аналитики и AI как на данных Oracle, так и на сторонних данных, без предположения о консолидации.

В: Как Oracle AI Data Catalog соотносится с Databricks Unity Catalog и Snowflake Horizon?

Вместо прямой конкуренции Oracle AI Data Catalog использует архитектуру каталога каталогов для объединения метаданных из AWS Glue, Databricks Unity Catalog и Snowflake Horizon Catalog в общее представление. Эти платформенные каталоги продолжают обслуживать свои среды, тогда как Oracle располагается над ними в роли уровня управления. Открытый вопрос — захотят ли предприятия ещё одного слоя поверх существующих каталогов.

В: В чём разница между Lake Cache и Data Lake Accelerator в AI Lakehouse?

Lake Cache хранит часто используемые внешние данные локально в AI Lakehouse, что улучшает производительность для повторных запросов к одним и тем же внешним таблицам. Data Lake Accelerator временно добавляет вычислительные мощности для масштабных сканирований внешних данных в объектном хранилище и освобождает эти ресурсы по завершении запроса. Кэш обрабатывает горячие повторные чтения, ускоритель — пиковые сканирования.

SC
Sarah Chen
RiverCore Analyst · Dublin, Ireland
ПОДЕЛИТЬСЯ
// ПОХОЖИЕ СТАТЬИ
ГлавнаяРешенияПроектыО насКонтакт
Новости06
Дублин, Ирландия · ЕСGMT+1
LinkedIn
🇷🇺RU▾