Дякую за статтю , цікава інформація.
В мене склалось враження, що описані підходи найбільше підходять до сервісів на Джаві. Чи є якісь приклади подібних патернів/ архітектур іншими мовами програмування.

П. С.
Місцями помітні залишки машинного перекладу з рос. мови — «услуга», неузгодження закінчень деяких слів тощо. Редактору варто більше уваги приділяти вичитуванню матеріалів

Я правильно понимаю, что Вы находясь физически в Украине (и не покидая территорию страны за всё время действия предложения от Револют), просто указали в приложении страну в ЕС и приложение пропустило Ваш запрос?

Из чего следует такой вопрос:
Можно ли расценивать подобные действия как ввод заведомо ложных данных в систему Револют и какие возможны последствия для таких «псевдо-беженцев»?

Интересный алгоритм, спасибо за статью.

Как Вы уже упомянули даже для малых n — количество перестановок огромно. Какие есть варианты параллелизации данного алгоритма? Могут ли подобные вычисления выполняться несколькими ядрами/ компьютерами независимо? Какой необходимый оверхед на синхронизацию потоков/процессов , если применить многопоточность,

Датабрикс — замечательный инструмент, пусть и крепко завязанный на свою экосистему. Умолчим о финансовой стороне вопроса- говорят подписка стоит немало у ребят. Датабрикс нельзя развернуть у себя локально, только кластер. Когда кластер поднят — начинаются вопросы конфигурирации типа default parallelism, shuffle repartition, dbs secret scope и тучи других флажков, которые могут производительность как вверх так и вниз увести.

Ну джавовские стек трейсы читать при ошибках- все ещё тяжеловато.

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

Ну и дашборд состояния кластера в Даске просто огонь.

Сергей,
спасибо большое за статью. Сейчас как раз разбираюсь с данным фреймворком и рад что не один такой — по моим наблюдениям он только набирает популярность.

Из нюансов, которые я бы хотел добавить про Dask:
1) Чистый пайтон — это прям ми-ми-ми как по мне, особенно если сравнивать с альтернативами на Скала и Спарке (привет Датабрикс из коробки на AWS и Azure)
2) С другой стороны тот же Спарк в моем конкретном случае показывает себя как более надежный и отказоустойчивый инструмент, который намного лучше работает с памятью. Worker killed out of Memory это про Даск.
3) Вы правильно использовали persist() после индексации датафреймов, но совершенно ничего про это не упомянули — крайне важно в ключевых точках обработки данных записывать их в кластер ( как бы имитируя то, что делает спарк со своими RDD) , иначе каждый раз ваш граф будет вычисляться (и индексироваться например) заново.

Из проблемных мест Даска:
1) Партицирование — по умолчанию это либо каждый индивидуальный файл при чтении или одна единственная партиция при вызове compute() на клиенте, что с легкостью может съесть всю память на клиенте
2) Каждая партиция — это объект пандас, и насколько я могу судить, эти объекты тоже нормально так места в памяти занимают, ощущение будто при вычитывании 1 Гб из паркетов — получаем датафрейм размером 2-3 Гб;
3) Группировка больших датафреймов по небольшому количеству значений тоже с легкостью создаёт огромные партиции и съедает память на отдельно взятом воркере — об этом даже отдельная статья/видео есть от Saturn Cloud.
4) Join операции — к сожалению Даск не поддерживает мульти-Индексы и если , например, нужно объединить датафреймы по двум колонкам ( идентификатор и например отметка по времени), то приходиться создавать отдельную колонку с конкатенацией этих значений. Кстати даск может и обычный df.join() делать, но к сожалению только по индексу.

Из полезных материалов стоит упомянуть блоги Coiled.io и Saturn Cloud — обе компании предоставляют услуги по настройке и использованию кластеров с Даском. Метью Роклин из первой компании ведёт свой канал на ютубе — можно много полезного почерпнуть.
Также есть просто невероятно полезная книжка от Jesse C. Daniel по Даску — очень хорошо структурирована, наглядные примеры и интересные кейсы.

Ну и как сказал Руслан: вставки кода стоить перепроверить — очень много «очепяток» в тексте. Например  <blockquote>batch_cize != batch_size</blockquote>, pd / read_csv и

add_DF,shape [0]

Кстати для доступа к shape [0] — разве не нужно вызвать компьют?

П.С.
Изобилие англицизмов не добавляет читабельности статье, но это мое скромное имхо .

А вообще пишите ещё — тема интересная и я считаю важная.

А что на счёт ФП в Scala и прочей биг дате?

Я прошу прощения, а агрегатные функции это ж Numpy? Разве Дзен не говорит нам быть «as explicit as possible »? И ещё- в самом pandas вроде есть сумма и среднее ? Что по вашему мнению сложнее в освоении Numpy или Pandas?

Последнее из прочитанного — SQL antipatterns от Билла Карвина. Ещё очень рекомендую книги издательства No Starch Press, много авторов пишут легко и с ненапряжённым юмором. В принципе 2-3 книги в год в среднем получается читать.

Книги как-то поприятнее идут видосов с ютуба, опять же если хорошая книга — читать одно удовольствие...

Ребята оцифровали какую-то методичку по расчёту выбросов... в принципе это хорошо, но не тянет на rocket science;
Что-то похожее лет 7-8 назад писали в Softengi (могу ошибаться).
Усреднённые показатели и коэффициенты, взятые для сторон третьего мира особенно, — вызывают сомнение. Пластиковая тара, производимая в Киевской области, по выбросам может сильно отличатся от такой же тары в Швеции.
Ну и самое главное что мне не нравится в таких расчетах — всё пересчитывается на СО2, хотя некоторые особо опасные выбросы следует отслеживать отдельно как по мне.
И последнее — если есть 2 одинаковых производства (та же пластиковая тара например), только одно очень много выбросов в воздух создаёт, а второе — стоков в водные источники, то какое же из них наносит больше вреда окружающей среде?

Пайка, сборка — всё без перчаток, захламлённые рабочие места... вероятно с другими процессами тоже есть нюансы в плане ОТ и ПБ.

Ну у меня только 5 лет в монтаже оборудования для пищепрома — но каждый раз на каждом новом объекте как в новом сезоне с новыми сценаристами

Мне интересно, что ответил бы прораб / бригадир с 26 годами опыта на стройке 26-летнему парню из офиса про «много работал и повидал многое». Про ИТР вообще молчу.
Ребят, очень круто что вы придумали такой продукт и сами его продвигаете, но СНИП, ДБН и ряд других требований, упомянутых выше, — это необходимый минимум и обязательное условие работы в правовом поле, а не блажь злых троллей с форума.
Надеюсь эти комментарии помогут вам найти и исправить существующие упущения и избежать возможных проблем в будущем. Удачи вам!
П.С.
Наверняка вы не единственные, кто предлагает подобные услуги в Одессе/Украине.... как теоретические конкуренты решают подобные вопросы?