Databricks залучив $15 млрд: що таке Databricks і чому весь data-світ говорить про цю платформу

Коротко: Databricks — це хмарна Data Intelligence Platform для data engineering, аналітики, машинного навчання та AI, яка виросла з екосистеми Apache Spark і lakehouse-підходу. У січні 2025 року компанія завершила пакет фінансування на понад $15 млрд: $10 млрд Series J при оцінці $62 млрд і $5,25 млрд кредитної лінії. Відтоді Databricks продовжила стрімко зростати: у серпні 2026 року компанія закрила новий раунд на $5 млрд при оцінці $190 млрд. Платформа актуальна для дата-інженерів, аналітиків і ML/AI-спеціалістів, які працюють із великими обсягами даних у хмарі.

Вступ

Databricks уже кілька років залишається в центрі уваги data та AI-індустрії. Один із ключових етапів стався у січні 2025 року, коли компанія завершила пакет фінансування на понад $15 млрд. Важливо: це не був один венчурний раунд на $15 млрд — пакет складався з $10 млрд equity-фінансування Series J і $5,25 млрд кредитної лінії. Для data-ринку ця історія стала сигналом того, наскільки великі ставки інвестори роблять на інфраструктуру даних і AI.

Ця стаття — для тих, хто хоче зрозуміти, що таке Databricks, як вона влаштована і де вписується в реальний data stack. Ми розберемо ключові концепції — від data lakehouse і Delta Lake до Unity Catalog та AI-можливостей — і поглянемо на платформу без зайвого хайпу: де вона справді сильна, а де варто двічі подумати перед впровадженням.

Databricks знову в новинах: що сталося і чому це важливо

Фінансування Databricks: цифри і контекст

У грудні 2024 року Databricks оголосила про Series J із цільовим обсягом $10 млрд при оцінці $62 млрд, а 22 січня 2025 року повідомила про фінальне закриття раунду. Одночасно компанія закрила кредитну лінію на $5,25 млрд. У сумі це дало понад $15 млрд нового фінансування, але коректно розділяти $10 млрд equity-фінансування і $5,25 млрд боргового фінансування. Серед інвесторів Series J були, зокрема, Thrive Capital, Andreessen Horowitz, Insight Partners, QIA, Temasek, Meta та інші великі інституційні гравці.

На той момент оцінка $62 млрд була суттєвим стрибком порівняно з раундом 2023 року, коли Databricks оцінювали приблизно у $43 млрд. Але історія на цьому не зупинилася: у грудні 2025 року компанія оголосила Series L при оцінці $134 млрд, а в серпні 2026 року закрила новий стратегічний раунд на $5 млрд при оцінці $190 млрд.

Що це означає для ринку великих даних

Контекст важливий. Хвиля generative AI та корпоративних AI-застосунків різко підвищила попит на інфраструктуру, яка поєднує зберігання, обробку, governance, аналітику та роботу з ML/AI. Databricks опинилася в сильній позиції саме тому, що її платформа об’єднує ці сценарії навколо єдиного data layer та спільної моделі governance.

Якщо ви в data і ще не стикалися з Databricks безпосередньо — варто розібратися, що це і як воно працює.

Що таке Databricks — пояснення для тих, хто чує вперше

Від Apache Spark до хмарної платформи: коротка історія

Databricks заснували у 2013 році творці Apache Spark з Каліфорнійського університету в Берклі. Spark уже тоді був потужним рушієм для розподіленої обробки даних, але його production-експлуатація вимагала окремої інфраструктурної експертизи. Databricks починалася як спосіб зробити Spark зручнішим для команд, а згодом перетворилася на значно ширшу платформу для data, analytics та AI.

Початкова ідея Databricks — дати командам можливість фокусуватися на даних і моделях, а не на ручному керуванні складною distributed-інфраструктурою. Сьогодні ця ідея розширилася до Data Intelligence Platform, яка охоплює engineering, BI, governance, ML та generative AI.

З чого складається Databricks: ключові компоненти

Databricks доступний у AWS, Azure і Google Cloud. Архітектура залежить від типу workspace та compute: частина ресурсів може працювати як fully managed/serverless сервіс, а в classic-сценаріях compute і storage інтегруються з інфраструктурою хмарного акаунта клієнта. Тому коректніше говорити не про «відсутність інфраструктури», а про те, що значну частину її керування Databricks автоматизує.

Як Databricks працює на практиці

Зручна аналогія: якщо Apache Spark — це один із ключових двигунів, то Databricks — повноцінна платформа навколо нього: з керуванням compute, notebooks, SQL-аналітикою, governance, orchestration, ML/AI та оптимізаціями виконання. У 2026 році Databricks уже давно не зводиться лише до «керованого Spark».

Compute у Databricks може масштабуватися автоматично, якщо це підтримує і дозволяє вибрана конфігурація. Для serverless compute значна частина масштабування й керування виконується платформою автоматично; для classic compute параметри autoscaling та auto-termination налаштовуються окремо. Модель оплати залежить від типу compute і хмари, тому її потрібно перевіряти для конкретного сценарію.

Мови — Python, SQL, Scala, R. Можна починати з того, що вже знаєте.

Що таке data lakehouse і чим він відрізняється від data warehouse та data lake

Data lake, data warehouse — у чому різниця і де біль

Обидва підходи мають свої сильні сторони і свої проблеми.

Data lake зазвичай зберігає великі обсяги структурованих і неструктурованих даних у дешевому object storage та відкритих форматах. Це дає гнучкість, але без catalog, governance, quality checks і table format такий lake легко перетворюється на «data swamp». Водночас сучасні lake-рішення з Delta Lake, Apache Iceberg або Apache Hudi вже можуть мати транзакційність та інші можливості, яких не було в класичному data lake.

Data warehouse оптимізований для структурованої аналітики, SQL та BI-навантажень. Сильні сторони — керованість, predictable performance і зріла екосистема аналітики. Недоліки залежать від конкретної платформи: інколи це вища вартість окремих workload-ів, менша гнучкість для сирих або неструктурованих даних чи необхідність підтримувати окремий контур для ML/AI.

Типова проблема в гібридній архітектурі — дублювання даних між lake та warehouse, окремі governance-політики й складні процеси синхронізації. Lakehouse-підхід намагається скоротити цей розрив, хоча на практиці багато компаній і далі використовують кілька спеціалізованих систем одночасно.

Lakehouse: третій шлях чи маркетинговий термін?

Lakehouse — це архітектурний підхід, а не конкретний продукт. Його ідея — поєднати дешеве та відкрите зберігання в object storage з можливостями, які традиційно асоціювалися з data warehouse: транзакціями, schema enforcement, governance, SQL-аналітикою та підтримкою різних workload-ів на спільних даних.

Delta Lake як технічна основа архітектури

Delta Lake — open-source table format і storage layer поверх файлів Parquet, який додає транзакційний журнал та ACID-семантику. Це дає versioning/time travel, schema enforcement, atomic writes, підтримку merge/upsert-сценаріїв і відновлення попередніх версій таблиць.

Delta Lake не обмежується Databricks: це open-source проєкт, а Delta-таблиці можуть читатися й оброблятися різними сумісними рушіями. Водночас найглибша інтеграція та частина оптимізацій доступні саме в Databricks, тому відкритий формат не означає повної відсутності vendor-specific можливостей.

Де Databricks вписується в екосистему даних сучасного дата-інженера

Databricks у типовому data stack: ETL, аналітика, ML в одному місці

У сучасних data-командах Databricks може бути центральною платформою або одним із ключових компонентів стека поряд з Airflow, dbt, Kafka, BI-інструментами та хмарними сховищами. Крім Spark-based workloads, Databricks активно розвиває Lakeflow для ingestion/orchestration, Databricks SQL, Unity Catalog, MLflow та AI-продукти.

Типовий пайплайн виглядає так:

1. Інгестія — дані надходять із різних джерел (Kafka, API, бази даних)
2. Landing у Delta Lake — сирі дані зберігаються в bronze-шарі
3. Трансформація в Databricks — очищення, агрегація, бізнес-логіка (silver і gold шари)
4. Аналітика або ML/AI — Databricks SQL для BI, MLflow для lifecycle моделей, а Mosaic AI та нові AI-сервіси — для generative AI і agentic workloads

Databricks vs Snowflake vs BigQuery: як обирати

Тут краще порівнювати не «хто сильніший взагалі», а які workload-и, екосистема та модель операцій важливі конкретній команді:

• Snowflake — зріла cloud data platform із сильним фокусом на SQL, BI, data sharing та простий managed experience. Для команд, де основний workload — SQL-аналітика, вона часто дає коротший шлях до результату.
• BigQuery — serverless data warehouse/data platform у GCP, тісно інтегрований з екосистемою Google Cloud. Особливо логічний вибір для команд, які вже будують інфраструктуру навколо GCP і хочуть мінімізувати операційне керування compute.
• Databricks — особливо сильний там, де потрібно поєднати data engineering, streaming, data science, ML/AI та SQL-аналітику на спільній платформі. Але він не є автоматично «кращим» за Snowflake чи BigQuery: вибір залежить від workload-ів, навичок команди, governance-вимог і вартості.

Databricks дає найбільшу цінність, коли команді справді потрібна одна governance-модель і спільний data layer для engineering, analytics та AI. Водночас у багатьох enterprise-архітектурах Databricks співіснує з іншими warehouse, BI та orchestration-системами, а не повністю їх замінює.

Unity Catalog і управління даними як конкурентна перевага

Unity Catalog — центральний governance layer Databricks для data та AI assets. Він підтримує централізований контроль доступу, row- і column-level policies, аудит, discovery та lineage, а також керування не лише таблицями, а й файлами, моделями та іншими об’єктами платформи. Core Unity Catalog також був відкритий як open-source проєкт, хоча керований сервіс Databricks має додаткові platform-specific можливості. Детальніше про Unity Catalog та роботу з цим компоентом у статті “Unity Catalog в Databricks: управління даними і governance без хаосу“

Типові помилки і обмеження при роботі з Databricks

Коли Databricks — це overkill

Помилка №1: використовувати Databricks лише тому, що він «enterprise». Якщо обсяг даних невеликий, workload простий, а команді достатньо локального Python/SQL або простішого managed-сервісу, Databricks може додати зайву операційну й фінансову складність. Водночас невеликий датасет сам по собі не є аргументом проти Databricks, якщо потрібні governance, collaboration, ML/AI або інтеграція з іншими корпоративними процесами.

Помилка №2: не розуміти модель витрат. DBU (Databricks Unit) використовується для вимірювання частини споживання Databricks-сервісів, але кінцева модель billing залежить від продукту, cloud provider і типу compute. У classic compute можуть окремо оплачуватися хмарні VM/ресурси, тоді як serverless pricing організований інакше. Тому бюджети, usage monitoring і policies потрібно налаштовувати до production-навантаження, а не після першого великого рахунку.

Технічні пастки, на які натрапляють початківці

Помилка №3: ігнорувати Delta Lake там, де потрібні надійні mutable tables. Писати plain Parquet технічно можливо, але тоді ви не отримуєте транзакційний журнал Delta, ACID-семантику, time travel, schema enforcement і зручні merge/upsert-операції. Водночас plain Parquet цілком доречний для простих immutable datasets або interoperability-сценаріїв.

Помилка №4: залишати classic compute без контролю простою. Для interactive/classic compute варто налаштовувати auto-termination, autoscaling та policies. У serverless-сценаріях життєвим циклом compute значною мірою керує сама платформа, тому рекомендація «завжди вручну налаштувати автозупинку кластера» вже не універсальна.

Помилка №5: очікувати, що Databricks повністю замінить будь-який data warehouse. Databricks SQL уже є зрілим аналітичним середовищем, і для багатьох компаній Databricks справді може закривати warehouse-сценарії. Але Snowflake, BigQuery та інші платформи мають власні сильні сторони, тому архітектурний вибір краще робити за workload-ами, інтеграціями, governance та TCO, а не за принципом «одна платформа повинна замінити все».

Крива навчання залежить від ролі. Для базового SQL та serverless experience старт може бути доволі простим, але глибока робота з Spark, distributed processing, performance tuning, Unity Catalog і production pipelines вимагає додаткової експертизи. Це варто враховувати при плануванні впровадження.

FAQ: питання про Databricks

Питання: Що таке Databricks?
Відповідь: Databricks — це хмарна Data Intelligence Platform для побудови, запуску та управління data, analytics і AI-рішеннями. Вона виросла з екосистеми Apache Spark, але сьогодні включає значно більше: Delta Lake, Databricks SQL, Unity Catalog, MLflow, Lakeflow та AI-сервіси. Платформа працює в AWS, Azure і Google Cloud та підтримує Python, SQL, Scala і R.

Питання: Як почати роботу з Databricks?
Відповідь: Для навчання Databricks пропонує безкоштовний Databricks Free Edition. Він замінив старий Community Edition, який було виведено з експлуатації наприкінці 2025 року. Free Edition дає serverless workspace з обмеженими ресурсами для навчання та експериментів. Для старту достатньо базових знань Python або SQL; паралельно корисно вивчити основи Spark, Delta Lake та Unity Catalog.

Питання: Databricks vs Snowflake — що краще для аналітики?
Відповідь: Універсальної відповіді немає. Snowflake часто зручний для SQL-first та BI-сценаріїв із мінімальним операційним навантаженням. Databricks особливо привабливий, коли в одному середовищі потрібно поєднати data engineering, streaming, ML/AI та SQL-аналітику. У великих компаніях ці платформи нерідко використовують разом під різні workload-и.

Питання: Скільки коштує Databricks і чи є безкоштовна версія?
Відповідь: Для особистого навчання є Databricks Free Edition — безкоштовна версія з fair-use квотами та низкою обмежень. Для комерційного використання доступні paid plans і free trial. Вартість залежить від cloud provider, продукту та типу compute: DBU є важливою частиною тарифікації, але не завжди є єдиною складовою рахунку. Для production важливо налаштовувати budget policies, usage monitoring, autoscaling та інші cost controls.

Питання: Які помилки роблять при роботі з Databricks?
Відповідь: Типові проблеми — неправильно підібраний compute, відсутність cost controls, слабке розуміння Spark-паралелізму, використання plain Parquet там, де потрібна транзакційність Delta Lake, і надмірне очікування, що Databricks автоматично оптимізує будь-яку архітектуру. Окремо варто приділяти увагу Unity Catalog, permissions і data governance ще на початку проєкту.

Підсумок і що далі: як почати розбиратися з Databricks

Три кроки для знайомства з платформою

Databricks — зріла enterprise-платформа, яка за останні роки перетворилася з «компанії навколо Spark» на одного з ключових гравців data та AI-ринку. Пакет фінансування на понад $15 млрд у 2025 році був важливим сигналом, а подальше зростання оцінки до $190 млрд у серпні 2026 року показує, що інтерес інвесторів до data+AI infrastructure лише посилився.

Якщо хочете спробувати:

1. Зареєструйтеся в Databricks Free Edition і запустіть перший notebook або SQL-запит у serverless workspace.
2. Пройдіть безкоштовні матеріали Databricks Academy та офіційні getting-started tutorials — там є треки для data engineering, analytics, Spark, Delta Lake та ML/AI.
3. Спробуйте Delta Lake на реальному датасеті: створіть Delta table, виконайте update/merge, перевірте time travel і порівняйте поведінку з plain Parquet.

Якщо хочете системно опанувати data engineering

Знайомство через Free Edition дає відчуття платформи, але для роботи в реальних проєктах потрібна системна база. Якщо хочете опанувати data engineering з нуля — включно з такими платформами, як Databricks, хмарними пайплайнами і сучасним стеком — розгляньте спеціалізацію Analytics & Data Engineer від Data Lab.

Databricks — потужний інструмент, який дає найбільшу цінність тоді, коли команда розуміє, навіщо їй lakehouse, governance, distributed processing та AI/ML на спільному data layer. Починайте з малого, вимірюйте витрати, використовуйте Unity Catalog і Delta Lake там, де вони справді потрібні, — і тільки після цього масштабуйте платформу.