Comments 15
Delta, HUDI, Iceberg: ну да, ну да, пошли мы нафиг)
Для сравнения надо мерить производительность. Но те бенчмарки которые я видел были по какой-то причине сделаны между карбондатой на втором спарке и айсбергом на третьем. И айсберг был на единицы процентов быстрее. Если бы был бенчмарк объективнее, то я бы не был так уверен. А вообще по популярности этих продуктов можно судить по табличке от апреля 2021 года.
Одни плюсы, и что... совсем ни одного минуса?
Ну почему же нет минусов. Продукт не так широко известен, соотвественно нет такого количества документации.
Это пока не минусы. В целом странно, что он так малоизвестен, хотя старше того же худи
Вот это и странно. Как правило, если есть специализация - должны быть минусы в тех областях, на которых продукт не специализируется. А попытки сделать что-то универсальное как правило имеют минусы повсюду :) А тут... документация, хм.
Очевидным недостатком является избыточное количество операций как цпу так и ИО при простых сценариях использования.
Ну на простые сценарии Карбондата и не рассчитывается. Целевой размер скорее стремится к петабайтам. А то что ресурсоемкая, наверное соглашусь, но индексы иначе не построишь.
Не, ну сжатие и индексы - это даром не дается, очевидно. Вы же не считаете тот факт, что типичная реляционная СУБД строит/достраивает индексы при каждой операции обновления, недостатком? Это скорее фича, особенность, с учетом которой надо выбирать инструмент. Желательно чтобы эта фича отключалась, очевидно, и настраивалась.
Сжатие данных и индексы могут быть настроены под индивидуальные нужды или даже отключены. И вариантов для тонкой настройки и экспериментов предостаточно. Но так как у каждой организации свои особенности использования, то большинство стандартных настроек зачастую требуют доработки. А это в свою очередь упирается в знания и умения того, кто это будет настраивать...
Мне кажется у автора очень слабое представление о возможностях паркет.
В Паркете есть storage индексы, страничные индексы, поддержка z standard compression. Acid расширение вам даёт худы, айсберг, или дельта-лейк над паркетом.
Из моей реальной практики флинк в паркет + айсберг удавалось добиться 40.000 изменений в секунду при онлайн вставке данных.
В целом, когда выбираете формат данных нужно смотреть не на его фичи А понимать каким движком и для каких задач вы собираетесь его использовать. И какие возможности движок поддерживает на конкретном формате. А то потом выяснится что заявленная эволюция данных доступна не для всех dml операции
Полностью согласен, все отталкивается от задач. Универсальных инструментов не существует. Но ограничения есть, без них не может не быть. На текущий момент полностью поддерживается Спарк через CarbonSpark connector. А вот в частности для Presto/Trino не поддерживаются материализованные представления, так как в логике СarbonData нужо изменять план запроса, а это не работает в Presto.
Паркет устарел. Пора менять