интересный вопрос про формат данных для datalakehouse, у паркета очевидные недостатки, интересно куда пойдет Databricks в этой части - дописывать структуры для паркета рядом, или будут делать свой проприетарный формат как Firebolt

ну они уже дописывают свои структуры рядом

но свой формат тоже возможен, конечно

Антон, то что очевидно вам - не всегда очевидно простым смертным 🙂 можете раскрыть что для "очевидные недостатки паркета"? и вроде как именно доп-структуры в Delta-формате и используются - delta-log

я не про Delta манифесты, а свои форматы для разряженных данных, для continuous writes, индексы

я говорю про поддержку индексов, нормальную поддержку полуструктурированных данных, более удобный формат для последовательной записи, сортировки если нужно (чтобы мерджить или искать было быстрее) - все это можно прикрутить сбоку к паркету, но можно и свои форматы написать, это же очевидное конкурентное преимущество

мне вот интересно, если я на датабриксе сделаю vacum, что произойдет с паралелльными долгоиграющими запросами ?

кстати на бесплатном delta.io 0.6 и spark 2.4 кеш подглючивает, т.е. один сделал vacum, то другая спарк сессия делает запрос в delta таблицу может упасть пытаясь считать давно не существующие файлы, типа delta.log или удаленный вакумом паркет. т.е. acid такой, специфический.

Они упадут по FileNotFoundException, мы постоянно сталкиваемся с таким поведением.

В нашем случае есть стрим джоба которая из кафки кладет данные в дельту таблицу, и отдельная батч джоба, которая из этой таблицы делает (скажем) аггреграцию, после этого делает VACUUM & OPTIMIZE. Периодически стриминг джоба падает по этой ошибке. Мы обошли это тем, что сделали партиционирование таблицы, а вакуум и оптимайз делаем только на нужной партиции

у них есть вроде флажок защищающий от запуска вакума на данных против которых бежит запрос или джоб spark.databricks.delta.retentionDurationCheck.enabled

ага, но тогда надо будет динамически стопать стриминг, и поднимать после того как батч отработает. Чтоб этим пока не возиться,  этот параметр у нас установлен = false

ясно, спасибо

вот собсно одна из причин почему нужен формат лучше чем паркет

наверное это для optimize, а не для vacuum, vacuum просто удаляет файлы старше retention

Нужен, очень нужен лучший формат))
На самом деле так про любой софт/технологию можно сказать. Например стораджи, в которых когда нибудь будет лежать этот идеальный формат, тоже нужны получше, чем сегодняшние

конечно, так можно сказать, но мы конкретно говорили о концепции datalakehouse, и для этой концепции паркет это узкое место

нам вместо формата для максимального сжатия структурированного датасета нужен формат для хранения таблицы и вторичных структур от аналитической СУБД

Скажешь через хинт

Понимаю. Много мыслей по этому поводу. Если есть индексы, то нужны адресуемые единицы хранения данных, на которые индексы смогут указывать. Если данные изменяются, нужно разруливать превышение размера хранения, переносить часть данных, уплотнять и тому подобное. DDL, секционирование, битовые индексы, да в общем всё, что РСУБД накопили за десятилетия, хорошо будет видеть в применении к бигдате

С другой стороны, разве это не переизобретение колеса? Ora, TD, PG, GP уже есть и предлагают огромные возможности как для тех, кто готов платить, так и для тех, кто продолжает плакать и колоться))

А к паркету (и к ORC) вполне можно битовый индекс прикрутить, и пушдаунить предикаты по индексу. Но ведь уже есть сжатие по словарю, в некоторых случаях поиск по нему будет также эффективен

Ещё всегда вспоминаю формат CarbonData. Очень многое в нём было сделано, и DDL и индексы и матвью, но опыт использования скорее негативный, и слышно о формате не так много, как о том же Hudi