⚡ Kotobotov ⚡

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

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

время идет, мир меняется, а в месте с этим и потребности к продуктам, например сейчас сильно увеличилось количество фреймворков/инструментов требуемых для среднего разработчика, железо также сильно изменилось с тех времен когда разрабатывалась джава, стали массового распространены многоядерные системы, в обыденность вошли продукты которые работают на кластерах и тд. Scala - разработан чтоб упростить нарастающую сложность.
при этом Scala - это не better java, это не про ООП или ФП, это язык практикующий в первую очередь практичный/прагматичный подход, стремящийся упростить работу с фреймворками, многоядерными системами, кластерами, различными платформами (компилироваться в js, нативно компилироваться и работать без jvm, работа с видеокартами и тд).
И как любой прагматичный язык, он позволяют работать с ним таким образом, как кто-то уже привык работать, например работать как с Java.
один из примеров упрощения : типы в скала, автоматически выводятся, их не обязательно указывать, из-за чего легко можно эксперементировать с кодом и его рефакторить, все зависимости по типам будут автоматически выводится сами.
Например зная интерфейсы Scala коллекций ты автоматически знаешь интерфейсы подавляющей части существующих в экосистеме фреймворков (общие интерфейсы).
Также ты можешь код разработанный как однопоточный, перенести на многопоточную среду, а затем и на кластер, и тд.
Есть простые схемы для создания собственных элегантных домен специфичных языков (используя перегрузку операторов, неявные параметры, неявные функции, автоматическую конвертацию типов).

язык только часть гиганской экосистемы - где есть Spark, Akka, Play, Kafka, Marathon.
Это решения для анализа больших данных с высокой эффективностью на кластерах. В России конечно не так много кому это востребовано, но все же спрос есть, особенно если учитывать что альтернатив особо нету.
Хотя, если денег не жалко можно и на питончике все колхозить.

Вам нужно предоставить решение технических вопросов, техническим специалистам, которые и будут заниматься реализацией.
проще поддерживать то что тебе более понятно, а более понятные вещи - это просто привычные вещи.
Вам нужно понять кто будет поддерживать проект (Scala - не так распространена например как JS), если вам нужно найти 1-2 толковых человека для поддержки, вы это можете на любом языке сделать (в том числе и на scala).
Если вам нужны сотни человек набирать - вы конечно хрен найдете себе сотню скалистов. Хотя наверно и сотню толковых JS-ников тоже не найдете))))
Если проект будет поддерживать тотже разраб (то нужно позволить ему выбирать самостоятельно более удобный инструмент)
-------
опять же типовая практика сейчас, упаковывают часть функционала в микросервис и вообще туда не лезут, разрабатывают разные микросервисы по тем технологиям которые удобны разработчикам.
типовой срок жизни такого микросервиса 3-5 лет, потом он часто вообще выкидывается/заменяется.

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

источникДанных
  .мап(созданиеСтруктуры)
  .фильтр(текущаяЗапись => СписокТребуемыхНомеров.содержит(текущаяЗапись.телефон) 
    && текущаяЗапись.дата<>требуемыйИнтервал)

так будет работать, но очень долго, медленно и сожрет кучу ресурсов на одной машине - это не то ради чего спарк используют, спарк - это движек для распределенных вычислений. А чтоб запустить распределенные вычисления, нужно в начале создать пару "ключ"->"значение" (где ключ номер телефона, а значение все остальные данные), эти пары распределятся по узлам, где будут параллельно обрабатываться, а потом результат паралельной обработки агрегировать в один общий результат, и для этого не фильтр использовать а reduceByKey с aggregate, для паралельного сбора ключей и значений для этих ключей.

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

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

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

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