а вот пушить не надо :)

Но там ток spark sql

вот у меня есть 2 топика в Кафке, например: кликстрим и какой-нибудь справочник.
1) я создаю 2 spark structured streaming жобы, которые приземляют эти топики в "бронзовый слой"
2) я создаю 2 стриминг джобы, которые из "бронзы" доставляют изменения в "серебряные" таблицы. допустим даже с учетом SCD2 для справочника.
3) создаю 1 стриминг джобу, которая раз в час варит из серебрянных инкрементов новую партицию для "золотой" таблицы

я не хочу код каждой джобы держать в отдельном гите

Михаил из ДодоПицца показывал на последнем митапе DEorDIE подобный монореп, но там все на питон завязано.

Извини что не в тему, А можешь немного раписать что собой физически представляют таблицы в бронзе серебре и в стриминге их апдейтить?

Спасибо 🤗

но вы же в облаках сидите, смотрите сразу на Databricks DeltaLake, там важные оптимизации, без которых "печот"

а мб кто знает, есть ли либа для Avro чтобы именно в array of bytes преобразовывала pojo и обратно для java? (есть такая для скала, а apache avro почему-то только в файл так умеет, если я ничего не проглядела)

А что мешает?

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

мы просто в teamcity на писали шабловнов на kotlin dsl которые нам собирает стандартные джобы

а какая разница монорепа или нет? просто что вы не ссылаетесь на конкретные артефакты в артифактори, а тащите их из target/?

мне вообще не нужны зависимости между джобами, мне нужен единый resources с конфигами, схемами данных, SQL/DSL для трансформаций и некий sexy_framework.jar в lib

или как сейчас делают дата-инженеры?

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

Вот примерчик на jsonnet:

https://github.com/renardeinside/databricks-jobs-jsonnet

Две джобы с зависимостями друг на друга, конфигурация из одной точки

Он под DBX написан, но концепция "конфиги в одном месте" достигается как раз за счет jsonnet

Есть ли общие рекомендации, как настроить тяжелвй запрос в клаудере в hive через MR так, чтобы он по максимуму сбрасывал все промежуточное на диск и по минимуму использовал оперативку?
Т.е. чтобы дольше подождать, но чтобы он выполнился, а не вывалился по нехватке памяти?
set hive.tez.container.size=128 не оч помогло...

hive вроде и так все промежуточные файлы хранит в HDFS