⚡ Kotobotov ⚡

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

>Сейчас в девятом классе, математика на уровень физ-мат лицея - твердая 4
если тебе не требуется придумывать новых алгоритмов, или там какие-то свои библиотеки писать, то твоих знаний по математике уже достаточно чтоб работать в МЛ тематике. Можно сфокусироваться на питоне и его экосистеме, всяких там МЛ библиотеках. Просто разбирай конкретные задачи, повторяй за другими.

ну вобще этим занимаются специалисты которые разрабатывают задачи для спарка.
поидее, после разработки и запуска задачи, такой специалист может зайти в спакЮИ и посмотреть распределение ресурсов, например оценив время работы у разных тасок.
Есть и другие подходы, но в любом случае этим должен заниматься тот кто задачу для спарка разрабатывает, тк просто знать что у вас не равномерно распределены ресурсы, без такого человека бессмысленно, а у этого человека и так уже есть инструменты для оценки равномерности распределения ресурсов.

как вариант - подключится к рабочему контейнеру через docker exec дополнительно указав команду export с необходимой переменной.

можно добавить дополнительный слой со спец символами в раскладку, а вызывать этот слой при нажатии на модификатор:
у вас есть модификаторы - альт, контл, шифт
типовая схема, вы нажимаете на шифт и у вас открывается дополнительный слой с Заглавными буквами, также можно сделать с любым другим модификатором, и добавить свой слой символов. Но для этого нужно создать пользоватьскую раскладку клавиатуры.

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

да
вобще терминология немного вводит в заблуждение, обычно говорят не микросервис, а микросервисная архитектура, тоесть такая архитектура сервиса при которой сервис состоит из множества независимых друг от друга узлов, которые ты можешь независимо разрабатывать и деплоить, без необходимости изменений в остальных узлах. сколько самих узлов и их размер уже не так важен.

2. дополнительная пропускная способность? - ну если только ДО БД, а дальше бд то одна, соответственно перфоманс всего приложения всё равно не изменится.

1 и 2 -> кому-то сложно, кому-то не сложно, у каждого исполнителя своя оценка что есть сложно, а что нет.
3 -> стоит это столько, сколько просит исполнитель (ни больше, ни меньше), к сложности это имеет лишь косвенное отношение (цена зависит от рыночка).

ну например можно эффективно переиспользовать и хранить структуры данных.

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

в случае с мутабельными списками - тебе нужно создать третий, копируя все элементы первого и второго, что затратно как по времени исполнения, так и по объему хранения.
если ты в мутабельной структуре попробуешь тоже ссылочками сделать новую структуру, у тебя может получится такая ситуация, что уже ПОСЛЕ создания нового списка, при изменении в исходной структуре - эти изменения появятся в твоём новом списке, как неконтролируемое изменение, которое ты не выполнял.
В итоге поскольку в иммутабельных структурах есть гарантии, что они будут не измены, то их можно переиспользовать при создании новых структур данных, мутабельные же нельзя.

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

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

обычно микросервисы нарезают так чтоб они обслуживали отдельную "тематику", которую можно было бы отдельно маштабировать и отдельно дорабатывать, от всех остальных. Пример:
микросервис который обрабатывает работу каталога (и всё что связанно с ним), отдельно микросервис который будет работать с доставкой и отправкой заказов, микросервис который работает с партнёрской программой и начислением балов лояльности, и микросервис который занимается обработкой платежей. У каждого из этих микросервисов желательно иметь свою БД, тогда они могут независимо друг от друга работать и независимо маштабироваться, только отвечая потребностям свой нагрузки - очевидно нагрузка на каталог сильно выше чем на сервис обработки платежей (например каталог может обрабатывать 10 узлов, заказы обрабатывают 3 узла а платежи 1 узел)
При использовании монолита вы масштабируете сразу все сервисы на узлы, что не так эффективно.
-------
По поводу перфоманса - при такой нарезке как описал выше, у вас крайне редко будет ситуация когда для ответа на один запрос от пользователя, нужно будет опрашивать сразу несколько сервисов, НО даже в таких ситуациях не так важна задержка между вызовами, сколько возможность масштабировать обработку этих запросов.
-------
транзакционность обычно осуществляется через SAGA паттерн.
По поводу консистентности - если ты начинаешь масштабировать систему, значит состояние размазывается по множеству разных узлов/сервисов, вся суть что эти узлы/сервисы могут независимо друг от друга работать, значит консистентность будем мешать независимой работе (тоесть производительности), если сервисы зависимы то они не маштабируются (раз один узел ожидает что-то для работы от другого узла), поэтому там предъявляются "ослабленные требования" к консистентности состояния, как правило используют eventual consistency (согласованность в конечном счете), говорят что рано или поздно типа состояние в системе будет согласованно, если не будут поступать новые данные)
ну а пока данные поступают, то состояние может быть не согласованно между узлами.

выделю два момента, который почему-то из фокуса внимания всегда уходит:
1) есть куча книг/курсов например по математике или там программированию - там всё примерно одно и тоже, отличаются ну разве что подачей материала или форматом (ну вот нравиться кому-то получать "домашку" и за это платить по 100к в месяц - пожалуйста).
2) ни одна из этих книжек сама по себе не сделает из тебя математика или программиста. Вот есть например книжка - "искусство бокса" в 3х томах - наверно глупо считать, что прочитав её вы станете профессиональным боксёром и сможете как Майк Тайсон зарабатывать за бои по миллиону долларов, но обещая такие фантазии проще продавать курсы или книжки (наивность людей просто удивляет)
П. С.
только от тебя (твоих талантов/вложенного труда) зависит станешь ты кем-то или нет и вообще без разницы какие именно курсы или книжки ты выберешь.

перед слиянием дев ветки, её можно подготавливать, делать например операцию squash

обычно есть опция перед слиянием, автоматически делать squash.

видимо ожидается маштабирование вашего сервиса.
для этого есть несколько подходов:
например подходы связанные с "реплицированием", тоесть просто дублируются базы данных, что позволяет ускорять чтение (запись из-за этого наоборот будет медленней, тк требуется синхронизация записи между копиями),
и второй подход "шардирование", когда на разных базах хранятся разные группы данных (например пользователи с 1-1000 хранятся и обрабатываются на сервере 1, с 1000 по 2000 на сервере 2 и тд).
есть и более хитрые подходы типа умных кэшей.
Также судя по пункту 4, ожидается какой-то "кэширующий слой" между вашим сервисом и сторонним источником котировок.

ну есть такая команда docker commit - которая позволяет сохранить изменения в контейнере. но думаю всё равно стоит сохранять в докер фаил все шаги необходимые для новой сборки имиджа (просто не всегда его пересобирать).
а для того чтоб автоматизировать сборку, обычно выстраивают CI/CD пайплайны, завязывая их на изменениях в репозитории. Тоесть в своём репозитории описываются дополнительно шаги по сборке контейнера, которые срабатывают каждый раз когда происходят изменения в репозитории (ну например изменения докер файла или какие-то изменения в коде проекта).
П. С.
сборка разумеется идет с нуля, но за счет того что каждая инструкция в докер файле - это отдельный слой который кэшируется, то процесс может неплохо так ускоряться.

Работаю в российской компании, очень очень редко видел, чтоб писали на английском описания комитов)
В первую очередь вы эту историю ведете для себя и для своих коллег разработчиков, поэтому лучше исходить из того как вам самим комфортнее работать.
Если команда состоит из русскоязычных, то нет смысла из себя чего-то там выдавливать на английском.
П. С.
есть инструменты которые по определенным стандартам обрабатывают коммиты, они как правило опираются на ключевые слова, например указания типа коммита (fix, feature и тд) эти типы можно расширять разумеется русскими словами, но обычно этим не занимаются, а используют преднастроеные типовые варианты.
Поэтому обычно происходит комбинация и русского и английского, где ключевые слова (например тип комита) на английском, а пояснения и описания на русском.