- Поведение блока HDFS
Я попытаюсь на примере выделить различия в разделении блоков в зависимости от размера файла. В HDFS у вас есть:
Splittable FileA size 1GB
dfs.block.size=67108864(~64MB)
задание MapRed для этого файла:
16 splits and in turn 16 mappers.
Давайте посмотрим на этот сценарий со сжатым (не разделяемым) файлом:
Non-Splittable FileA.gzip size 1GB
dfs.block.size=67108864(~64MB)
Задание MapRed для этого файла:
16 Blocks will converge on 1 mapper.
Лучше заранее избегать этой ситуации, поскольку это означает, что средство отслеживания задач должно будет получить 16 блоков данных, большинство из которых не будут локальными для средства отслеживания задач.
искровое чтение разделяемого файла HDFS:
sc.textFile не начинает никакого чтения. Он просто определяет резидентную структуру данных драйвера, которую можно использовать для дальнейшей обработки.
Только после вызова действия в RDD Spark создаст стратегию для выполнения всех необходимых преобразований (включая read), а затем вернуть результат.
Если есть действие, вызываемое для запуска последовательности, и ваше следующее преобразование после чтения должно отображаться, то Spark потребуется прочитать небольшой фрагмент строк файла (в соответствии со стратегией разделения, основанной на количестве ядер), а затем немедленно начните отображать его, пока он не вернет результат драйверу, или перемешайте перед следующей последовательностью преобразований.
Если ваша стратегия разделения (defaultMinPartitions), похоже, забивает рабочих, потому что представление java вашего раздела (InputSplit в терминах HDFS) больше, чем доступная память исполнителя, тогда вам нужно указать количество разделов для чтения в качестве второго параметр в textFile. Вы можете рассчитать идеальное количество разделов, разделив размер файла на размер целевого раздела (с учетом увеличения объема памяти). Простая проверка возможности чтения файла:
sc.textFile(file, numPartitions)
.count()