⚡ Kotobotov ⚡

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

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

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

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

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

fabric8.io
и никаких забот по выстраиванию пайплайнов

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

данные из внешних источников грузятся в датаСеты (специальный интерфес над RDD) - поэтому вы там не увидели parallelize, вместо этого используется метод toDF или toDS.
в любом случае спарк работает только с RDD и только паралельно/распределенно (используя или нет дополнительные интерфейсы)