Study English 23.08.08 : Monitoring and Instrumentation 번역1

 

 

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

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

 

 

 

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

 

Monitoring and Instrumentation
모니터링과 측정

There are several ways to monitor Spark applications: web UIs, metrics, and external instrumentation.
Spark applications 를 모니터링하는 몇 가지 방법을 소개한다. WebUI, Metrics, 그리고 외부 계측.

Web Interfaces
웹 인터페이스

Every SparkContext launches a Web UI, by default on port 4040, that displays useful information about the application. This includes:
모든 SparkContext 는 WebUI 를 함께 실행한다. 기본 포트 4040이며, 다음과 같이 application 에 대한 유용한 정보를 보여준다.

• A list of scheduler stages and tasks
  stages 와 tasks 스케줄러 리스트
• A summary of RDD sizes and memory usage
  RDD 사이즈와 memory 사용률 정보
• Environmental information.
  환경 정보
• Information about the running executors
  실행중인 executors 정보

You can access this interface by simply opening http://<driver-node>:4040 in a web browser.

웹 브라우저에서 <driver-node>:4040 으로 접근하는 것으로 간단하게 해당 인터페이스에 접근 가능하다. 
If multiple SparkContexts are running on the same host, they will bind to successive ports beginning with 4040 (4041, 4042, etc).
만약 같은 호스트에 여러 SparkContext 가 동작중이라면, 4040부터 시작하는 포트 중 사용 가능한 포트에 바인딩 된다(예를 들면 4041, 4042... 등)

Note that this information is only available for the duration of the application by default.
이 정보는 오로지 application이 살아있는 동안만 활용 가능하다.
To view the web UI after the fact, set spark.eventLog.enabled to true before starting the application.

나중에라도 WebUI 를 보고 싶다면, spark application 실행 전 spark.eventLog.enabled 를 true 로 설정해야 한다.
This configures Spark to log Spark events that encode the information displayed in the UI to persisted storage.
이 설정은 WebUI 에 보여지는 Spark event 정보들을 인코드하여 영구 저장 매체에 로깅할 수 있도록 한다.

Viewing After the Fact
정보 다시 확인하는 방법

It is still possible to construct the UI of an application through Spark’s history server, provided that the application’s event logs exist.
application의 이벤트 로그가 존재한다면 Spark history server 를 통해 application 의 UI 를 다시 구성하는 것이 가능하다.

You can start the history server by executing:
다음 명령어로 history server 실행이 가능하다.

./sbin/start-history-server.sh

This creates a web interface at http://<server-url>:18080 by default, listing incomplete and completed applications and attempts.
이것은 기본 <server-url>:18080 으로 Web Interface 를 생성한다. 이것은 불완전하거나 완전한 application 과 attempts 목록을 나타낸다.

When using the file-system provider class (see spark.history.provider below), the base logging directory must be supplied in the spark.history.fs.logDirectory configuration option, and should contain sub-directories that each represents an application’s event logs.
file-system provider class (아래 spark.history.provider 참고) 를 사용할 때, 기본 로깅 디렉터리는 spark.history.fs.logDirectory configuration 옵션으로 설정되어야 하며, applications 의 이벤트 로그를 나타내는 서브 디렉터리를 포함해야 한다.

The spark jobs themselves must be configured to log events, and to log them to the same shared, writable directory.

Spark jobs 는 자체적으로 이벤트를 로깅하도록 설정되어야 하며, 쓰기 및 공유가 가능한 디렉터리에 로깅해야 한다.

For example, if the server was configured with a log directory of hdfs://namenode/shared/spark-logs, then the client-side options would be:
예를 들어, 만약 서버가 hdfs://namenode/shared/spark-logs 디렉터리에 로그를 남기도록 설정되어있다면, 
Client-side 의 옵션 역시 다음과 같이 되어야 한다.

spark.eventLog.enabled true
spark.eventLog.dir hdfs://namenode/shared/spark-logs

The history server can be configured as follows:
history server 는 다음과 같이 설정 가능하다.

Environment Variables
환경 변수들

Environment Variable 환경 변수	Meaning 의미
SPARK_DAEMON_MEMORY	Memory to allocate to the history server (default: 1g). history server 에 할당할 메모리 크기(기본 1g)
SPARK_DAEMON_JAVA_OPTS	JVM options for the history server (default: none). history server 를 위한 JVM 옵션 (기본 none)
SPARK_DAEMON_CLASSPATH	Classpath for the history server (default: none). history server 를 위한 classpath (기본 none)
SPARK_PUBLIC_DNS	The public address for the history server. history server 를 위한 public 주소. If this is not set, links to application history may use the internal address of the server, resulting in broken links (default: none). 만약 세팅되지 않는다면, application history 링크는 서버의 internal 주소를 사용 할 수 있으며, 그 링크는 깨질 수 있다(기본 none)
SPARK_HISTORY_OPTS	spark.history.* configuration options for the history server (default: none). history server 를 위한 spark.history.* 설정 옵션들 (기본 none)

Applying compaction on rolling event log files
롤링 이벤트 로그 파일들에 압축 적용하기

A long-running application (e.g. streaming) can bring a huge single event log file which may cost a lot to maintain and also requires a bunch of resource to replay per each update in Spark History Server.
streaming 처럼 오랫동안 실행되는 application 은 하나의 큰 이벤트 로그 파일을 만들 수 있는데, 이것은 유지하는 데 비용이 들 수 있고 Spark History Server 에서 각 업데이트를 재현하는 데 꽤나 큰 리소스가 들 수 있다.

Enabling spark.eventLog.rolling.enabled and spark.eventLog.rolling.maxFileSize would let you have rolling event log files instead of single huge event log file which may help some scenarios on its own, but it still doesn’t help you reducing the overall size of logs.

spark.eventLog.rolling.enabled 및 spark.eventLog.rolling.maxFileSize 옵션을 활성화해두면, 하나의 큰 이벤트 파일 생성하는 대신 롤링 이벤트 로그 파일들을 얻을 수 있고, 이는 어떤 시나리오에서는 도움이 될 수 있다(..??). 하지만, 아직 전체 로그 파일 크기를 줄이는 데 도움을 주진 않는다.

Spark History Server can apply compaction on the rolling event log files to reduce the overall size of logs, via setting the configuration spark.history.fs.eventLog.rolling.maxFilesToRetain on the Spark History Server.

Spark History Server 에서 spark.history.fs.eventLog.rolling.maxFilesToRetain 설정하여 전체 로그 사이즈를 줄이기 위해, 롤링 이벤트 로그 파일들의 압축을 적용할 수 있다. 

Details will be described below, but please note in prior that compaction is LOSSY operation.

자세한 것은 아래 더 서술하겠지만, 압축은 데이터 손실이 발생하는 작업이다.

Compaction will discard some events which will be no longer seen on UI - you may want to check which events will be discarded before enabling the option.

압축은 UI 에 더 이상 보이지 않을 이벤트들을 버릴 것이다.

해당 옵션을 활성화하기 전에, 압축에 인해 사라질 이벤트들을 보고싶을 지 모른다.

When the compaction happens, the History Server lists all the available event log files for the application, and considers the event log files having less index than the file with smallest index which will be retained as target of compaction.

압축이 이미 실행되었다면, History Server 는 application 의 모든 사용가능한 이벤트 로그 파일들을을 리스팅한다.

가장 작은 인덱스를 가진 파일을 보존 대상으로 선택하며, 해당 파일보다 인덱스가 작은 이벤트 로그 파일을 대상으로 압축을 수행한다. (아니 가장 작은 인덱스보다 인덱스가 작다는 게 말이야 방구야....)

For example, if the application A has 5 event log files and spark.history.fs.eventLog.rolling.maxFilesToRetain is set to 2, then first 3 log files will be selected to be compacted.

예를 들어, application A 가 5개의 이벤트 로그 파일들을 갖고 있고, spark.history.fs.eventLog.rolling.maxFilesToRetain 값이 2로 설정되어있다면, 첫 세 개의 로그 파일들만 압축된다.

Once it selects the target, it analyzes them to figure out which events can be excluded, and rewrites them into one compact file with discarding events which are decided to exclude.
일단 타켓이 선택되고나면, 어떤 이벤트들을 걸러낼지 분석하고, 걸러낼 것들을 걸러낸 후 남은 이벤트들을 하나의 압축 파일로 다시 쓴다.

 

The compaction tries to exclude the events which point to the outdated data.

압축은 오래된 데이터를 가리키는 이벤트를 걸러내려한다.

As of now, below describes the candidates of events to be excluded:
현재 아래 기술된 것들이 걸러낼 이벤트의 후보들이다.

• Events for the job which is finished, and related stage/tasks events
  이미 마무리된 job 이벤트 그리고 마무리된 stage/tasks 와 관련된 이벤트
• Events for the executor which is terminated
  terminated 된 executor 에 대한 이벤트
• Events for the SQL execution which is finished, and related job/stage/tasks events
  이미 마무리된 SQL exeuction 이벤트 그리고 마무리된 job/stage/tasks 와 관련된 이벤트

Once rewriting is done, original log files will be deleted, via best-effort manner.

일단 압축이 되고 나면, 원본 로그를 사라져버린다.

The History Server may not be able to delete the original log files, but it will not affect the operation of the History Server.

History Server 는 원본 로그 파일들을 삭제할 수 없지만, History Server 동작에 영향을 주지 않는다.

Please note that Spark History Server may not compact the old event log files if figures out not a lot of space would be reduced during compaction.

Spark History Server 는 압축하며 저장공간 확보에 도움이 되지 않는게 확인되면, 오래된 이벤트 로그 파일들을 압축하지 않는다.

For streaming query we normally expect compaction will run as each micro-batch will trigger one or more jobs which will be finished shortly, but compaction won’t run in many cases for batch query.

streaming query 가 실행될 때, micro-batch 로 압축이 실행될거라 기대하지만, 압축은 배치 쿼리를 위한 많은 상황에서 동작하지 않는다..

이런 문장 해석하고 있으려니 현타가 오네..

Please also note that this is a new feature introduced in Spark 3.0, and may not be completely stable.

이것은 Spark 3.0 에서 소개된 새로운 특징이며, 언제든 바뀔 수 있다.

Under some circumstances, the compaction may exclude more events than you expect, leading some UI issues on History Server for the application.

몇몇 환경 하에서, 압축은 생각한 것 보다 더 많은 이벤트들을 걸러낼 수 있으며, 이는 UI 이슈를 일으켜 History Server 의 application 정보를 보지 못하게 만들 수 있다.

Use it with caution.

조심해서 쓰세욥