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 повну специфікацію — включаючи приховане партиціонування, граничні випадки еволюції схеми та семантику time travel — у джерелі не зазначено. Це перше, що інженерні команди мають перевірити в 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 досі веде головну книгу, і вирішив, що міграція не завершиться в це десятиліття. Для такого покупця «розширюй те, що маєш, і федеруй решту» — більш чесний аргумент, ніж «lift and shift за 18 місяців».

Контраріанський ризик полягає в тому, що ця позиція стає самовиконуваною стагнацією. Федерація архітектурно елегантна й операційно складна. Крос-каталогове відстеження походження, крос-рушійна оптимізація запитів і узгоджена семантика безпеки між AWS Glue, Unity і Horizon — це невирішені проблеми в масштабі. Якщо AI Lakehouse постачає маркетинг, але не операційну глибину, клієнти отримують найгірше з обох світів: lakehouse, що обіцяє єдину аналітику, але все одно змушує інженерів думати про три каталоги та чотири рушії запитів. Цей сценарій провалу більш вірогідний, ніж визнає постачальник.

Питання без відповідей

Кілька орієнтирів, варті відстеження. Джерело посилається на Autonomous Data Guard, що забезпечує автоматичне перемикання при відмові, і згадує, що відповідні розгортання AI Lakehouse отримують SLA на рівні 99-з-чимось відсотків, причому точна цифра обрізана в тексті джерела. Це суттєве упущення. Різниця між 99,9%, 99,95% і 99,99% — приблизно на порядок більше допустимого простою на рік, і корпоративні покупці оцінюють контракти саме з урахуванням цієї цифри. Поки Oracle не опублікує повний SLA, слід виходити з консервативного мінімуму.

Також невідомі ціни на пакетні обчислення 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 року і є відповіддю.

Часті запитання

Q: Що таке 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, так і над сторонніми даними, без припущення про консолідацію.

Q: Як Oracle AI Data Catalog порівнюється з Databricks Unity Catalog і Snowflake Horizon?

Замість прямої конкуренції Oracle AI Data Catalog використовує архітектуру «каталог каталогів» для з'єднання метаданих з AWS Glue, Databricks Unity Catalog і Snowflake Horizon Catalog у спільний вигляд. Ці платформні каталоги продовжують обслуговувати свої середовища, тоді як Oracle розміщується над ними як рівень управління. Відкрите питання — чи потрібен підприємствам ще один рівень над наявними каталогами.

Q: У чому різниця між 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
🇺🇦UK▾