Study English 23.08.13 Tuning Spark 번역4

Spark Documentation 문서 번역을 한 번 해보려고 한다.

눈가락번역기의 번역 상태가 많이 좋지 않으니 양해 바람.

 

번역 대상 문서 : https://spark.apache.org/docs/latest/tuning.html

 

Other Considerations
다른 고려할 튜닝 방법들

Level of Parallelism
병렬성 수준

Clusters will not be fully utilized unless you set the level of parallelism for each operation high enough.
각 작업의 병렬성 수준을 충분히 높게 설정하지 않는다면, 클러스터는 전체가 활용되지 않을 것이다.
Spark automatically sets the number of “map” tasks to run on each file according to its size (though you can control it through optional parameters to SparkContext.textFile, etc),

Spark 는 각 파일의 크기에 따라 자동으로 map 태스크의 수를 설정한다. (사용자가 SparkContext.textFile 파라미터를 설정하여 컨트롤 할 수 있음)

and for distributed “reduce” operations, such as groupByKey and reduceByKey, it uses the largest parent RDD’s number of partitions.

분산 reduce 작업들, 예를 들어 groupByKey, reduceByKey 들은, 가장 큰 상위 RDD 의 파티션 수를 사용한다.

You can pass the level of parallelism as a second argument (see the spark.PairRDDFunctions documentation), or set the config property spark.default.parallelism to change the default.

두 번째 아규먼트(spark.PairRDDFuntions 문서 확인) 로 병렬성 수준을 설정할 수 있다.

혹은 spark.default.parallelism 옵션을 설정하여 default 값을 바꿀 수 있다.

In general, we recommend 2-3 tasks per CPU core in your cluster.
일반적으로, 클러스터에서 CPU 당 두 세개의 태스크를 실행하는 병렬성 수준을 설정하도록 권장한다.

Parallel Listing on Input Paths
인풋이 많을 때 Parallel Listing

Sometimes you may also need to increase directory listing parallelism when job input has large number of directories,

때때로 job input 이 대량의 디렉터리를 갖는다면, 디렉터리 listing parallelism 을 증가할 필요가 있다.

otherwise the process could take a very long time, especially when against object store like S3.

그렇지 않으면 프로세스는 굉장히 오래 걸릴 것이다. 특히 입력값이 s3 같은 저장소에 있다면 더욱.

If your job works on RDD with Hadoop input formats (e.g., via SparkContext.sequenceFile), the parallelism is controlled via spark.hadoop.mapreduce.input.fileinputformat.list-status.num-threads (currently default is 1).

만약 job 이 Hadoop input 포맷(예를 들어 SparkContext.sequenceFile)으로 된 RDD 로 작업하고 있다면, 병렬성은 spark.hadoop.mapreduce.input.fileinputformat.list-status.num-threads 을 통해 조절된다.(현재 기본 1)

For Spark SQL with file-based data sources, you can tune spark.sql.sources.parallelPartitionDiscovery.threshold and spark.sql.sources.parallelPartitionDiscovery.parallelism to improve listing parallelism.

file 기반의 데이터 소스로 작업하는 Spark SQL의 경우, spark.sql.sources.parallelPartitionDiscovery.threshold and spark.sql.sources.parallelPartitionDiscovery.parallelism 옵션값을 listing 병렬성을 개선하도록 설정하라.....

Please refer to Spark SQL performance tuning guide for more details.
더 자세한 사항은 이 문서에 있다.

Memory Usage of Reduce Tasks
Reduce Task 의 메모리 사용률

Sometimes, you will get an OutOfMemoryError not because your RDDs don’t fit in memory, but because the working set of one of your tasks, such as one of the reduce tasks in groupByKey, was too large.

때때로, RDD 크기가 memory 에 딱 맞지 않음에도 불구하고 OOM 에러를 볼 수 있다.

이것은 task(예를 들어 groupByKey 를 실행하는 reduce task) 중 하나의 워킹셋이 너무 크기 때문에 발생한 것이다.

Spark’s shuffle operations (sortByKey, groupByKey, reduceByKey, join, etc) build a hash table within each task to perform the grouping, which can often be large.

Spark 의 셔플 동작들은, 그룹핑을 수행하기 위해 각 task 내부적으로 hash table 을 구성하는 데, 그것이 종종 커질 수 있다.

The simplest fix here is to increase the level of parallelism, so that each task’s input set is smaller.

이 이슈를 해결할 가장 간단한 방법은 병렬성 수준을 높여 각 task 의 input set 크기를 줄이는 것이다.

Spark can efficiently support tasks as short as 200 ms, because it reuses one executor JVM across many tasks and it has a low task launching cost,

Spark 는 200ms 만큼 짧게 동작하는 task 들도 효율적으로 서포트 할 수 있는데,

이는 전체 task 에 걸쳐 하나의 executor JVM이 재사용되고 그것이 적은 task 실행 비용을 갖기 때문에 가능하다.

so you can safely increase the level of parallelism to more than the number of cores in your clusters.
따라서 클러스터 내 코어 수 보다 병렬성 수준을 크게 올려도 안전하다.

Broadcasting Large Variables
큰 변수들 브로드캐스트하기

Using the broadcast functionality available in SparkContext can greatly reduce the size of each serialized task, and the cost of launching a job over a cluster.

SparkContext 에서 사용 가능한 브로드캐스트 함수를 사용하는 것은 각 직렬화 task 수를 확연히 줄일 수 있고, 클러스터 위에 실행되는 job 의 비용도 줄일 수 있다.

If your tasks use any large object from the driver program inside of them (e.g. a static lookup table), consider turning it into a broadcast variable.

만약 task들이 task 내부적으로 driver 프로그램으로부터 온 큰 객체를 사용한다면 브로드캐스트 변수를 사용하여 튜닝하는 것을 고려하라.

Spark prints the serialized size of each task on the master, so you can look at that to decide whether your tasks are too large;

Spark 는 동작하는 각 task의 직렬화된 크기를 마스터에 출력하는데, 이걸 보고 task 가 너무 큰지 아닌지 결정할 수 있다. 

in general, tasks larger than about 20 KiB are probably worth optimizing.
일반적으로, 20kb 보다 큰 task 들은 최적화 해볼 만 하다.

Data Locality
데이터 지역성

Data locality can have a major impact on the performance of Spark jobs.

데이터 지역성은 Spark job 성능에 영향을 주는 주요 요인이다.

If data and the code that operates on it are together, then computation tends to be fast.

데이터와 코드가 함께 존재한다면, 계산은 굉장히 빠르다.

But if code and data are separated, one must move to the other.

그러나 코드와 데이터가 나뉘어져 있다면, 계산을 위해서 둘 중 하나가 움직여야 한다.

Typically, it is faster to ship serialized code from place to place than a chunk of data because code size is much smaller than data.

일반적으로, 데이터 자체를 옮기는 것 보다 직렬화 된 코드를 다른 곳으로 옮기는 것이 더 빠른데, 왜냐하면 코드의 사이즈가 데이터보다 더 작기 때문.

Spark builds its scheduling around this general principle of data locality.

Spark 는 데이터 지역성 원칙에 기반하여 자신의 스케줄링 계획을 세운다.

Data locality is how close data is to the code processing it.

데이터 지역성은 데이터와 데이터를 처리하는 코드가 얼마가 가까운지에 대한 것이다.

There are several levels of locality based on the data’s current location.

현재 데이터 위치에 기반한 지역성 수준이 몇 가지 있다. 

In order from closest to farthest:

가장 가까운 곳에서부터 가장 먼 곳 순으로:

• PROCESS_LOCAL : data is in the same JVM as the running code. This is the best locality possible.
  PROCESS_LOCAL : 데이터와 실행 코드가 같은 JVM 안에 있다. 이것은 실현가능한 최고의 지역성이다.
• NODE_LOCAL : data is on the same node.
  NODE_LOCAL : 데이터는 같은 노드에 있다.
  Examples might be in HDFS on the same node, or in another executor on the same node.
  예제는 같은 노드 위의 HDFS 안에 있거나, 같은 노드 위 다른 executor 에 있다.
  This is a little slower than PROCESS_LOCAL because the data has to travel between processes.
  이것은 PROCESS_LOCAL 보다 살짝 더 느린데, 왜냐면 데이터가 process들 사이를 이동해야 하기 때문이다.
• NO_PREF : data is accessed equally quickly from anywhere and has no locality preference.
  NO_PREF : 데이터는 어느 곳에서든 동일하게 빠르게 접근 가능한 곳에 있다. 이 경우 지역성 특성은 없다.
• RACK_LOCAL : data is on the same rack of servers.
  RACK_LOCAL : 데이터는 서버의 같은 rack 에 있다.
  Data is on a different server on the same rack so needs to be sent over the network, typically through a single switch.
  데이터가 같은 랙의 다른 서버에 존재해서, 네트워크를 통해 전송될 필요가 있다. 일반적으로 싱글 스위치를 통해 전송된다.
• ANY : data is elsewhere on the network and not in the same rack.
  ANY : data 가 같은 랙이 아니지만 네트워크로는 연결된 어느 곳에 있다.

Spark prefers to schedule all tasks at the best locality level, but this is not always possible.
Spark 는 모든 task 들이 가장 최선의 지역성 수준으로 스케줄링 되길 선호하지만, 항상 그것을 만족하지는 않는다.
In situations where there is no unprocessed data on any idle executor, Spark switches to lower locality levels.

어느 놀고있는 executor 위에 처리되지 않은 데이터가 없는 상황에서, Spark 는 지역성 수준을 낮추도록 전환한다. 

There are two options:

두 가지 옵션이 있다.

a) wait until a busy CPU frees up to start a task on data on the same server, or

a) 바쁜 CPU 가, 같은 서버 위의 데이터로 task 를 시작할 수 있을 때까지 기다린다 혹은

b) immediately start a new task in a farther away place that requires moving data there.

b) 더 멀리 떨어진 곳에 데이터를 이동시키고 즉시 새로운 task 를 시작한다.

What Spark typically does is wait a bit in the hopes that a busy CPU frees up.

Spark 가 주로 선택하는 것은 바쁜 CPU 가 자유로워질 때 까지 기다리는 것이다.

Once that timeout expires, it starts moving the data from far away to the free CPU.

타입아웃이 만료되면, Spark 는 가용한 CPU 가 있는 더 먼 곳으로부터 데이터를 옮기기 시작한다.

The wait timeout for fallback between each level can be configured individually or all together in one parameter;

각 지역성 수준 간 fallback 을 위한 wait 타임아웃은 독립적으로 혹은 하나의 파라미터로 모두 함께 설정 가능하다.

see the spark.locality parameters on the configuration page for details.

자세한 사항은 configuration 페이지에 있는 spark.locality 파라미터 확인.

You should increase these settings if your tasks are long and see poor locality, but the default usually works well.
만약 task 가 너무 오래 걸리거나 지역성이 처참하다면, 이 세팅값들을 올려야 한다. 하지만 기본값으로도 충분히 잘 동작 할 것이다.

 

Summary
정리

This has been a short guide to point out the main concerns you should know about when tuning a Spark application – most importantly, data serialization and memory tuning.

이것은 사용자가 Spark application 을 튜닝할 때 알아야 할 주요 요인들을 설명하는 짧은 가이드이다.

가장 중요한 것은 데이터 직렬화와 메모리 튜닝이다.

For most programs, switching to Kryo serialization and persisting data in serialized form will solve most common performance issues.

대부분의 프로그램에서 Kryo 직렬화 사용과, 캐싱할 때 직렬화하는 것은 대부분의 성능 이슈를 해결해 줄 것이다.