Проблема Традиційних Таблиць Даних

1. Відсутність атомарності (часткові записи)

Уявіть, що ваш кластер знаходиться на півдорозі до запису 50 000 нових записів про діаманти у файл, коли раптово вимикається електроенергія або виникає збій мережі.

Результат: Ви отримуєте «пошкоджений» файл. Половина даних присутня, половина відсутня, і ваш аналіз тепер назавжди неправильний. Традиційні файли не мають правила «все або нічого».

2. Відсутність контролю схеми

У традиційному підході ніщо не заважає користувачу випадково завантажити запис про діамант, де «Price» є текстом (наприклад, «Expensive»), а не числом.

Результат: Наступного разу, коли ви спробуєте виконати суму або середнє, весь ваш конвеєр зламається, оскільки «математика» не може обробити текст. Сирі файли — це «тихі збої» — вони приймають некоректні дані без скарг.

3. Проблема "Двох кухарів" (Конкурентність)

Що відбувається, якщо два різних дата-інженери намагаються оновити таблицю Diamonds в одну й ту ж секунду?

Результат: Зміни однієї людини, ймовірно, перезапишуть зміни іншої, або файл стане заблокованим і непридатним для використання. Традиційні файлові системи не призначені для одночасного читання та запису даних кількома користувачами.

4. Відсутність кнопки "Скасувати"

Якщо випадково виконати команду, яка видаляє всі діаманти з огранюванням "Premium" з вашого набору даних, ці дані буде втрачено. У стандартній файловій системі немає вбудованої "історії" або кнопки "скасувати", щоб побачити, як виглядала таблиця п’ять хвилин тому.

Еволюція: Чому нам потрібен Delta Lake

Саме через ці проблеми компанії переходять від Data Lakes (просто папки з файлами) до Lakehouse.

Щоб вирішити ці питання, Databricks створив Delta Lake. Він додає до ваших файлів "журнал транзакцій" — діє як досвідчений бухгалтер, який:

• Відстежує кожну зміну;
• Гарантує, що некоректні дані не потраплять у систему;
• Дозволяє "подорожувати у часі" до попередніх версій у разі помилки.