⚡ Kotobotov ⚡

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

Ну если разобраться что мы подразумеваем под Интернетом Вещей - разные датчики, устройства которые объедены через интернет. Обычно подразумевается что у тебя например в каждом доме есть какой-то датчик, или это устройство, и каждый такой датчик например генерирует ежесекундно данные.
Одно устройство может генерировать хоть мегабайт данных в день (иногда и гигабайт в день), и таких устройств может быть хоть миллиард -> это гигантское количество данных которые тебе нужно обрабатывать и на этом предоставлять какой-то сервис.
Это и есть биг дата (объем данных которые никак не обработать мощностями отдельного компьютера).
Как такой объем данных связан с машинным обучением?
Когда ты работаешь с системой, у которой например есть 2-3 параметра, например поступление топлива в котел и температура котла -> ты можешь в ручную запрограммировать модель управления температурой в зависимости от подачи топлива и управлять такой системой. Когда у тебя есть 20 параметров ты можешь набрать собрать несколько ученых и построить сложную модель с формулами из 20 переменных. Но когда у тебя число переменных параметров насчитывает тысячи штук, нет никаких возможностей что-то понять и как-то разобраться.
Тебе очень сложно выявить зависимости и схемы поведения в сетях из миллиарда устройств. Чтоб понять как лучше управлять такими сетями и используется машинное обучение.

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

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

1. Учись решать задачи, которые перед Data Engineer ставят.
2. Вроде нету, а если и есть вам туда гарантированно не светит попасть.

проблема с эффективность использования ресурсов в питоне
тк это динамически типизированный язык.
Джава / скала - статически типизированный языки.
При статической типизации ниже гибкость, но выше эффективность работы с данными, при динамической наоборот.
Скала позволяет сочетать в себе плюсы динамической типизации (благодаря автоматическому выводу типов), и сохранять высокую эффективность работы.
Есть еще и другие детали, например если говорить за SPARK -> который на скала реализован, зная скала, ты уже знаешь спарк, тк там практически такойже апи для работы с коллекциями, все что тебе нужно для того чтоб твой код работал на спарк кластере, заменить название коллекции которую ты обрабатываешь с например Array[MyClass] на RDD[MyClass], и грубо говоря - весь твой код без изменений будет обрабатываться на спарк кластере, само собой такого нет и не будет в питоне, там тебе нужно будет осваивать дополнительный апи.

хех людей даже с очень большим опытом работы за границей + большим пластом научных работ не берут. Реальность такова, что у нас практически нет никакой биг даты, и такие специалисты не нужны, те вакансии что висят, это так маркетинг, можете не обращать на них внимание, так же как и сам термин.
работайте со стартапами, разрабатывайте свои продукты и будет вам занятость.
P.S.
НО в целом сфера набирает популярность, спрос растет (устойчивый тренд), особенно в крупных федеральных компаниях.

никакого вытеснения нету, питону не по силам вытеснить java, из анализа данных, дела обстоят совсем наоборот, для высокоскоростной работы, и для манипулирования данными в памяти, используют именно статически типизированные языки очень популярны java/scala.
всякие питоны и js используют только для прототипирования, быстрой проверки идей.
К томуже зарубежом питон -> это основной язык используемый при обучении студентов программированию (HE "программистких" специальностей) как более простой для обучения язык, плюс удобно работать используя RELP ( https://ru.wikipedia.org/wiki/REPL ).
На динамически типизированных языках писать что-то простенькое гараздо проще. И поэтому так много всяких студенческих поделок на питоне для обработки данных.
Но нужно учитывать что использование динамически типизированных языков, для реально крупных проектов убийственно, как с точки зрения разработки и откладки, так и с точки зрения производительности.
Для прототипирования , для контрошек по математике питон это отличное решение, для реального бизнес проекта не стоит даже заморачиваться.
кстати для любителей собрать что-то быстро на коленке в 9й java будет идти jshell с relp https://blogs.oracle.com/java/entry/jshell_and_rel...

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

да всё верно, читаем -> обрабатываем.
но большинство алгоритмов классических, которые мы обычно используем для обработки данных (например сортировки) имеют класс "оффлайн" алгоритмов -> где для получения ответа нужно сразу все данные предоставить, чего иногда сделать просто не возможно.
посмотрите класс онлайн алгоритмов, и потоковой обработки данных.
например тут www.cs.dartmouth.edu/~ac/Teach/CS85-Fall09/Notes/l...
ну либо попытаться использовать потоковые фреймворки типа spark.
для обработки логов конечно проще и быстрее написать свои алгоритмы, чем spark колхозить.