Concurrency (конкурентность )- одна из самых важные характеристик в базе данных. Что будет, если несколько процессов будут писать в одну таблицу? Традиционные базы данных уже научились это делать, а вот с озером данных или гибридным озером данных (lake house), не так все просто. Когда несколько процессов одновременно пытаются записать данные в одну и ту же таблицу, это может привести к серьезным проблемам: - Потерянные обновления (Lost Updates): Один процесс записывает данные, а второй тут же их перезаписывает, не зная о предыдущей операции. - Несогласованные данные (Inconsistent Data): Данные могут оказаться в некорректном или неполном состоянии. - Гонки данных (Race Conditions): Результат операции зависит от того, какой из процессов завершится первым, что делает результат непредсказуемым. Традиционные реляционные базы данных, такие как PostgreSQL, MySQL и SQL Server, давно решили эту проблему. У них есть встроенные механизмы, которые гарантируют надежность транзакций по принципу ACID (Atomicity, Consistency, Isolation, Durability). Они используют: - Блокировки (Locking): Процессы временно блокируют доступ к данным, пока не завершат свою операцию. - Управление параллельным доступом с помощью версий (MVCC): Вместо блокировки база данных создает разные версии данных. Это позволяет читателям видеть старую версию, пока новый процесс записывает новую. Архитектура Data Lake и Lakehouse принципиально отличается. Они построены на распределенных файловых системах (HDFS, Amazon S3, Azure Blob Storage), которые изначально созданы для хранения огромных объемов данных, а не для поддержки транзакций. Основные проблемы: - Нет встроенной поддержки ACID: Файловые системы не поддерживают атомарные транзакции. Если запись прервется на полпути, файл может остаться поврежденным. - Работа с файлами, а не со строками: Изменение одной строки данных может потребовать перезаписи всего большого файла, что крайне неэффективно и опасно. Чтобы решить эти проблемы, появились транзакционные фреймворки, которые добавляют уровень управления транзакциями поверх озер данных. Самые известные из них: - Delta Lake - Apache Hudi - Apache Iceberg Эти фреймворки создают слой метаданных, который ведет журнал всех изменений, обеспечивая атомарность операций и изоляцию снапшотов. Это позволяет им работать с данными в озерах так же надежно, как и традиционные базы данных. В статье Can 10 Spark Writers Perform Concurrent Appends to an Iceberg Table Simultaneously? автор проверил, могут ли 10 одновременных процессов Spark успешно записывать (добавлять) данные в одну и ту же таблицу Apache Iceberg. __Тест 10 параллельных Spark‑записей (`MERGE INTO`) в разные партиции Iceberg‑таблицы на S3. __ __Проверяется, как система справляется с одновременными обновлениями: выполняется 10 Spark‑джобов, каждый таргетит отдельную партицию, и анализируются успехи и неудачи операций.__ __ Основные настройки Iceberg для надёжной параллельной записи: - `commit.retry.num-retries = 20` — попыток на случай конфликтов, - `commit.retry.min-wait-ms = 30000` — минимальная задержка между попытками, - `write.merge.isolation-level = snapshot` — слой изоляции, гарантирующий консистентность снимков. __ __Результат: несмотря на возникающие ошибки во время выполнения, автоматические ретраи и snapshot‑изоляция позволяют успешно завершить все `MERGE INTO` операции, сохранив целостность данных.__