ИК
Во время - в смысле до шафла или после? Таки это важно
Size: a a a
2021 September 02
KR
Но у меня при любом количестве партиций получается 32т тасков
KR
Меняется только в зависимости от входных данных
Р
Привет!
возник вопрос про dynamic allocation. сравниваю его с статическим выделением ресурсов и вижу только одни плюсы, есть ли у него недостатки ? стоит ли ему доверять ?
возник вопрос про dynamic allocation. сравниваю его с статическим выделением ресурсов и вижу только одни плюсы, есть ли у него недостатки ? стоит ли ему доверять ?
A
У важной задачи могут забрать ресурсы
AS
Не заберут, если важная задача уже захватила ресурсы
NN
Забрать могут разве что излишек, который она забрала раньше, свыше своей квоты.
AS
Проблема динамика, что он по каждому чиху начинает брать ресурсы, а отдаёт не охотно
VV
Привет! А подскажи пожалуйста еще, вы креды ко внешним системам в сенсоры пробрасываете через os.env / хардкод?
Там же оказывается все эти модные ресурсы/моды/пресеты внутри сенсоров недоступны
Там же оказывается все эти модные ресурсы/моды/пресеты внутри сенсоров недоступны
ЕГ
Есть настройки, через сколько отдавать
VN
И внутри сенсоров и внутри пайплайнов. В этом идеология - они независимы экосистемы
VN
Да, через env и свои библиотеки, подключаются в каждом пайплайне
VV
Понятненько, спасибо большое))
2021 September 07
АА
Ребят, привет! Могли бы поделиться мнением. Я отстаиваю позицию, что в DAG'ах Airflow не стоит размещать код спарк приложения, и вызывать его через PythonOperator (Планируется указывать в качестве мастера yarn на другом сервере). По моему мнению это метафорически сборка машин непосредственно на проезжей части.
Есть ли плюсы у желаемого моими "оппонентами" решения?
Есть ли плюсы у желаемого моими "оппонентами" решения?
ПФ
Это скорее в hadoopusers мне кажется
ПФ
Но вообще я не вижу тут катастрофы не считая того, что есть же Спарк сабмит оператор
АА
По моему мнению главные минусы такие:
Неконтролируемый рост размеров ДАГов, которые содержат спарк приложения.
Сложность их дальнейшей поддержки.
Повышение роли создания бэкапов для ДАГов, так как даги будут содержать логику работы приложения.
Неконтролируемый рост размеров ДАГов, которые содержат спарк приложения.
Сложность их дальнейшей поддержки.
Повышение роли создания бэкапов для ДАГов, так как даги будут содержать логику работы приложения.
ЕГ
Я за декларативные даги вообще - есть конфиг дага, есть конфиги тасков типа источник-приёмник, есть код бизнес-логики тасков, можно всё переиспользовать, легко разложить в гит и менять по необходимости, даг на лету своей либой из этого всего собирать
ЕГ
Сложность не только поддержки, но и разработки
Атомарный кусок кода бизнес-логики можно обложить автотестом, а когда он внутрь эйрфлоу дага засунут, что с ним делать? Как его отдельно запустить, не копировать же
Атомарный кусок кода бизнес-логики можно обложить автотестом, а когда он внутрь эйрфлоу дага засунут, что с ним делать? Как его отдельно запустить, не копировать же