тема интересная (мне, по крайней мере), с удовольствием продолжу... но не сегодня 😊

Индексы есть?

Ага, худее некуда.

Вещь, конечно, довольно неоднозначная. Мы тут недавно стараниями @ora00001 научились размером файлов управлять и компактить залитое.

Но иногда с ним, конечно, просто феерия. В исходном дф запись есть, вмержил его, ошибок нет, селектишь таргет-записи нет.

А почему именно его у себя решили развернуть? И тестили ли дельту/айсберг?

Всё тестили. Дельта не вывозит такие объёмы, айсберг в принципе не умеет в мердж.

Как так? Пишут, что умеют. Я, правда, пока не тестил, вот на неделе буду. Это я про айсберг.
А дельта в каком плане не вывозит?

Не-а. Я так и не понял прикола, соль пришлось убрать. Будем страдать на монотонно возрастающем ключе, при таком раскладе каунты по этим несчастным 100 гигам минуты занимают

Где пишут? В айсберг можно делать insert/update/delete?
Дельта в разумные сроки не может вмержить нужный объём данных.

Ну вы хотспот получите. А в твоём примере key это rowkey?

Про дельту понял, т.е. для не сильно больших датасетов без дельта энжн?

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

Что такое rowkey? Составной ключ, но в конце таймстамп. Достаточно плохо, но на таких размерах и под текущий паттерны нагрузки сойдёт.

Но тоже надо помнить, наверное, что айсберг все таки заявлялся вроде как изначально как решение для больших и редко меняющихся датасетов, поэтому мне трудно пока судить о производительности всех операций, кроме селекта и джойна на больших объемах. И там ещё хватает параметров, с которыми играться можно, так что хз. Но когда и если родится строковое апи, то мб это уже будет прям интересно.

дельта в смысле опенсоурсная или датбрикс со всеми наворотами ?

А какая скорость интересует, просто для примера hudi 0.6 350млн строк, в примерно 30 секций вмерживает 2 часа 30 минут, 100 екзекуторов, 4 vcpu по 64 гб, 0.8 на данные. Индекс симпл. Ну тут явно не в коня корм, так как 4 таска из 400 по работе с индесами обрабатываются 2 часа, так как там много данных, игра с параллелизмом не проходит, хоть 1000, хоть 2000 всеравно 4 таска.

Обычная босяцкая, без кирпичей.

Ровкей это уникальный идентификатор записи в hbase.

Iceberg просто в самом начале пути, если вы не крупный айти гигант вроде Apple, Netflix, Adobe то тащить в продакшен точно не нужно ещё

Merge через copy-on-write уже есть в релизе (пока только для спарка), он подходит для батчей; реализация через merge-on-read сейчас идёт, она намного сложнее, но она подойдёт уже для микробатча; производительность сейчас не является основным приоритетом, пока задача стоит сделать корректно и масштабируемо

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

За остальные сведения - спасибо, учту в дальнейшем.