k
файлик с 3к строк
а если хотим что-то переиспользовать в другом файлике потом?
а если хотим что-то переиспользовать в другом файлике потом?
Size: a a a
2022 January 27
BM
это пока не надо реюзать код между джобами. или зависимости сторонные
A
ipynb-py-convert
k
да он шутит же
ЕГ
Берёшь пишешь фреймворк на питоне
k
правда? 😳😳
ЕГ
Весь етл максимум строчек 200
ЕГ
Это упороться надо
ЕГ
Никакого чтения и записи, это всё во фреймворке, начиная с создания сессии
Только код бизнес-логики
Только код бизнес-логики
ЕГ
В идеале вообще на эскуэле, но датафреймы покомпактнее обычно
k
т. е. ваш фреймворк брал бизнес логику, и собирал 1 файлик с инпутами, аутпутами, и бизнес-логикой?
ЕГ
Не собирал один файлик
А импортировал бизнес-функцию из файлика и с нужными параметрами, со считанными датафреймами запускал
А импортировал бизнес-функцию из файлика и с нужными параметрами, со считанными датафреймами запускал
ЕГ
Принимал от неё результат и записывал куда надо
ЕГ
По конфигу
k
ну, на одном из проектов у нас это все разрослось, и в какойпто момент мы начали собирать путон wheel и раскатывать его по кластеру при запуске. а spark-submit py файлик был очень маленький: стартовал сессию и бросал ее в основной скрипт, в котором импорты из N других скриптов wheel-а
k
получилось тестабельно, и структура какая-никакая присутствовала, хелперы, коннекторы..
ЕГ
Да, в артифактори по тэгу заливался архив
k
какое-то время жили без артефактори, с зипом. но в нем тоже модули были. правда, зависимости в отдельном месте писать нужно было. такое. но работало
ЕГ
Ну у меня была суть именно в том, что для решения бизнес-задачи пишешь 0 лишнего кода, только бизнес-логику
ЕГ
Никаких импортов не надо, кроме спарк-функций, получаешь спарк-сессию и датафреймы готовые и работаешь