Spark — загрузка каталога с 500 г данных

#apache-spark #partitioning #zipfile

#apache-spark #разделение #zip

Вопрос:

Я довольно новичок в Spark и распределенных вычислениях. Все очень просто для загрузки файла csv или текстового файла, который может поместиться в память вашего драйвера. Но здесь у меня реальный сценарий, и мне трудно понять подход.

Я пытаюсь получить доступ к примерно 500 Г данных в S3, они состоят из Zip-файлов. поскольку это zip-файлы, я использую ZipFileInputFormat, как описано здесь . Это гарантирует, что файлы не разделяются по разделам.

Вот мой код val sc = новый SparkContext(conf)

 val inputLocation = args(0) 
val emailData = sc.newAPIHadoopFile(inputLocation, classOf[ZipFileInputFormat], classOf[Text], classOf[BytesWritable]);

val filesRDD = emailData.filter(_._1.toString().endsWith(".txt")).map( x => new String(x._2.getBytes))
  

Это нормально работает при вводе нескольких 100 МБ. но как только он пересекает лимит памяти моего кластера, я получаю проблему OutOfMemory.

как правильно подойти к этой проблеме? — должен ли я создавать RDD для каждого zip-файла и сохранять выходные данные в файл, а затем загружать все выходные данные в отдельный RDD позже? — Есть ли способ загрузить базовый каталог в контекст Spark и разделить

У меня есть HDP-кластер с 5 узлами и ведущим, каждый из которых имеет 15 ГБ памяти.

Любые ответы / указатели / ссылки высоко ценятся

Ответ №1:

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

Комментарии:

1. Я согласен, что zip-файлы не могут быть разделены, но они имеют максимальный размер 1 ГБ каждый. Я заметил, что количество создаваемых разделов и один раздел для каждого zip-файла. значит ли это, что размер раздела становится больше, чем память драйвера / исполнителя, и, следовательно, проблема?

2. Не разделяемый => Один раздел на файл. Проблемы с памятью либо превышают лимиты, либо GC.