Как увеличить производительность данных?

Question

Я новичок в этой концепции и все еще учась. Я имею в общей сложности 10 ТБ json-файлов в AWS S3, 4 экземпляра (m3.xlarge) в AWS EC2 (1 мастер, 3 сотрудника). В настоящее время я использую искру с python на Apache Zeppelin.

Я читаю файлы со следующей командой;

hcData=sqlContext.read.option("inferSchema","true").json(path)

В настройках интерпретатора ZEPPELIN:

master = yarn-client 
spark.driver.memory = 10g 
spark.executor.memory = 10g 
spark.cores.max = 4 

занимает 1 минуту, чтобы прочитать 1GB примерно. Что я могу сделать больше для более эффективного чтения больших данных?

• Должен ли я делать больше по кодированию?
• Должен ли я увеличивать экземпляры?
• Должен ли я использовать другую платформу для ноутбука?

спасибо.

Answer 1

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

С 1 минуты до 1 ГБ довольно медленно. Я попробую сделать следующие шаги.

• Попробуйте явно указать схему вместо inferSchema
• Try использовать Спарк 2.0 вместо 1.6
• Проверьте соединение между S3 и EC2, в случае были некоторые расконфигурация
• Используя другой формат файла, как parquet кроме json
• Увеличение памяти исполнителя и уменьшить памяти драйвера
• Использование Scala вместо Python, althou gh в этом случае является наименее вероятной проблемой.

Answer 2

Вы можете сохраняться данные в формате паркетной после чтения JSON

hcData=sqlContext.read.option("inferSchema","true").json(path) 
hcData.write.parquet("hcDataFile.parquet") 
val hcDataDF = spark.read.parquet("hcDataFile.parquet") 

// создать временный вид на Спарк 2.0 или registerAsTemp таблицы в Спарк 1.6 и использовать SQL для дальнейшей логики

hcDataDF.createOrReplaceTempView("T_hcDataDF") 

// Это ручной способ проверки RDD (не поддерживается для DataFrames), это уменьшит RDD Lineage, что улучшит производительность.

Для выполнения, используйте Распределение Dyanamic ресурсов для искровой подать команду:

// Убедитесь, что следующим включены в кластере, в противном случае вы можете использовать эти параметры в искровой на высшем уровне команды, как --conf

• spark.dynamicAllocation.enabled=true 
• spark.dynamicAllocation.initialExecutors=5 
• spark.dynamicAllocation.minExecutors=5 
• spark.shuffle.service.enabled=true 
• yarn.nodemanager.aux-services=mapreduce_shuffle,spark_shuffle 
• yarn.nodemanager.aux-services.spark_shuffle.class 
    =org.apache.spark.network.yarn.YarnShuffleService 

// Искра подать команду

./bin/spark-submit --class package.hcDataclass \ 
--master yarn-cluster \ 
--deploy-mode cluster \ 
--driver-memory 1G \ 
--executor-memory 5G\ 
hcData*.jar 

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

Answer 3

я выступил с докладом на эту тему еще в октябре: Spark and Object Stores

По существу: использование паркет/орк, но параметры настраивают для эффективного чтения. Как только он отправится, возьмите Spark 2.0.x, построенный против Hadoop 2.8, за большую работу по ускорению, которую мы сделали, особенно работая с ORC & Паркет. Мы также добавляем множество показателей, хотя еще не вернули их обратно в искровой интерфейс.

Вывод схемы может быть медленным, если он должен работать через весь набор данных (вывод CSV делает, я не знаю о JSON). Я бы рекомендовал сделать это один раз, захватить детали схемы, а затем явно объявить ее как схему в следующий раз.