Это справедливо если у вас только одно хранилище. А также если вы не планируете никогда подкючать новые, организовывать многооблачность или мигрировать на другие хранилища.
Для проектов с очень специфичными требованиями и функциональностью, использование официальных SDK может быть оправдано. С другой стороны если проекту требуются специфические функции конкретного хранилища, то OpenDAL можно дополнить, реализовав необходимые расширения, так как есть поддержка обращения я к низкоуровневым API через методы raw, дает возможность использовать уникальные функции конкретного хранилища.
Хотя если брать тот же самый S3 то из всего списка операций поддерживаются stat, read, write, create_dir, delete, copy, list, scan, presign. И не реализованы только rename и blocking, что в принципе не выглядит какой-то проблемой.
Сжатие данных и индексы могут быть настроены под индивидуальные нужды или даже отключены. И вариантов для тонкой настройки и экспериментов предостаточно. Но так как у каждой организации свои особенности использования, то большинство стандартных настроек зачастую требуют доработки. А это в свою очередь упирается в знания и умения того, кто это будет настраивать...
Полностью согласен, все отталкивается от задач. Универсальных инструментов не существует. Но ограничения есть, без них не может не быть. На текущий момент полностью поддерживается Спарк через CarbonSpark connector. А вот в частности для Presto/Trino не поддерживаются материализованные представления, так как в логике СarbonData нужо изменять план запроса, а это не работает в Presto.
Ну на простые сценарии Карбондата и не рассчитывается. Целевой размер скорее стремится к петабайтам. А то что ресурсоемкая, наверное соглашусь, но индексы иначе не построишь.
Для сравнения надо мерить производительность. Но те бенчмарки которые я видел были по какой-то причине сделаны между карбондатой на втором спарке и айсбергом на третьем. И айсберг был на единицы процентов быстрее. Если бы был бенчмарк объективнее, то я бы не был так уверен. А вообще по популярности этих продуктов можно судить по табличке от апреля 2021 года.
Это справедливо если у вас только одно хранилище. А также если вы не планируете никогда подкючать новые, организовывать многооблачность или мигрировать на другие хранилища.
Для проектов с очень специфичными требованиями и функциональностью, использование официальных SDK может быть оправдано. С другой стороны если проекту требуются специфические функции конкретного хранилища, то OpenDAL можно дополнить, реализовав необходимые расширения, так как есть поддержка обращения я к низкоуровневым API через методы raw, дает возможность использовать уникальные функции конкретного хранилища.
Хотя если брать тот же самый S3 то из всего списка операций поддерживаются stat, read, write, create_dir, delete, copy, list, scan, presign. И не реализованы только rename и blocking, что в принципе не выглядит какой-то проблемой.
Сжатие данных и индексы могут быть настроены под индивидуальные нужды или даже отключены. И вариантов для тонкой настройки и экспериментов предостаточно. Но так как у каждой организации свои особенности использования, то большинство стандартных настроек зачастую требуют доработки. А это в свою очередь упирается в знания и умения того, кто это будет настраивать...
Полностью согласен, все отталкивается от задач. Универсальных инструментов не существует. Но ограничения есть, без них не может не быть. На текущий момент полностью поддерживается Спарк через CarbonSpark connector. А вот в частности для Presto/Trino не поддерживаются материализованные представления, так как в логике СarbonData нужо изменять план запроса, а это не работает в Presto.
Худи вырос из Убера,а Карбондата из Хуавей. Она более известна на китайском и индийском рынках
Ну на простые сценарии Карбондата и не рассчитывается. Целевой размер скорее стремится к петабайтам. А то что ресурсоемкая, наверное соглашусь, но индексы иначе не построишь.
Ну почему же нет минусов. Продукт не так широко известен, соотвественно нет такого количества документации.
Для сравнения надо мерить производительность. Но те бенчмарки которые я видел были по какой-то причине сделаны между карбондатой на втором спарке и айсбергом на третьем. И айсберг был на единицы процентов быстрее. Если бы был бенчмарк объективнее, то я бы не был так уверен. А вообще по популярности этих продуктов можно судить по табличке от апреля 2021 года.