dbt & hive catalog: эпилог 2

Закрываю для себя идею реализации записи в паркеты через dbt через starrocks, и причиной тому 3 вещи.

Причина 1: можно увидеть на картинке. Время приведено в секундах расчета без поднятий сессий, взято для спарка из dbt spark. Один и тот же код прогоняется через датасеты разных размеров (у нам они приходят именно так, это разные дневыне отчеты от одного провайдера). И чтобы считать на спарке 10 мегабайт в течение 80 секунд - надо написать выдающийся код витрины. Уже на сотне мегабайт старрокс ушел за пределы лимитов и стал проигрывать спарку, что я попробовал победить перегонкой данных в родной формат вместо паркета (хотя казалось бы - какая разница, проблема таких долгих вычисления явно не чтение). И даже получилось отыграть скорость, но на гигабайтах и это не помогло. Запросы были переведны с диалекта спарка на диалект старрокс без оптимизаций как есть, по пути заменив только функции работы с временем и хешами. Овчинка выделки не стоит, тем более мы все равно не собираемся отказываться от спарка.

Причина 2: названная в прошлом посте - отсутствие метаданных по внешним каталогам в дбт/dbeaver/datagrip (клиентах). Тут кажется начинает стрелять в ногу как раз совместимость с mysql (но это не точно). И пока эта фича не будет реализована - со стороны людей будет много недопонимания, а со стороны сервисов много грязного кода. Причем все каталоги отлично показываются в вебке старрокса по порту 8030 :(

Причина 3: высокая сложность реализации дев и стейдж стендов. Для тестирования такого совмещенного проекта дбт надо поднимать не только старрокс, но старрокс в связке с хадупом и хмс. Не очень просто, но так или иначе нам придется это делать.

Взяли себе в беклог устранение причины 3 и пристально наблюдаем за развитием старрокс для устранения причины 2. А 1 кажется будет решена так или иначе, просто по причине текущего вектора развития старрокса как lakehouse движка. Вот такие пироги.