[IT] 개발 영어 공부 - 빅데이터를 지탱하는 기술 5

 

 

책 '빅데이터를 지탱하는 기술' 에서 발췌한 '영어로 표현해보고 싶은 문장들' 임

- 빅데이터를 지탱하는 기술 공부 필기 : https://eyeballs.tistory.com/m/574

 

 

 

 

< 5. 빅데이터의 파이프라인 >

 

 

기업 내의 정형적인 업무 프로세스를 원활하게 진행하기 위한 구조를 ‘워크플로 관리’라고 한다.
→ The structure used to smoothly manage standardized business processes within a company is called “workflow management.”

 

‘워크플로 관리’ 기능은 다수의 업무 시스템에 내장되어 있어 매일 태스크를 관리하는 데 이용된다.
→ The “workflow management” feature is built into many business systems and is used to manage daily tasks.

 

어떤 비정상적인 일이 발생한 경우에는 사람이 개입하여 문제를 해결한다.
→ When an abnormal situation occurs, a human intervenes to resolve the issue.

 

데이터 파이프라인 실행 과정에서는 정해진 처리를 반복한다. 이때 실행되는 개별 처리를 태스크라고 부른다.
→ In data pipeline execution, predetermined processes are repeated. Each individual execution is called a task.

 

예정된 시간까지 끝내지 않으면 새로운 문제를 일으키는 태스크도 있다.
→ Some tasks can cause new problems if they are not completed by the scheduled time.

 

하나의 실패가 연쇄적으로 확대되어 결과적으로 모든 태스크를 처음부터 다시 시작해야 하므로 하루를 낭비하게 된다.
→ A single failure can cascade, ultimately requiring all tasks to be restarted from the beginning, resulting in a lost day.

 

미리 예기치 못한 오류가 발생할 가능성을 고려하여, 오류 발생 시의 대처 방법을 결정해두는 것이 중요하다.
→ It is important to anticipate potential unexpected errors in advance and define how to handle them when they occur.

 

신속하게 회복할 수 있도록 오류에 강한 워크플로를 구축하여 매일 반복되는 데이터 처리를 안정적으로 실행한다.
→ To recover quickly, a fault-tolerant workflow is built to reliably perform daily data processing.

 

통신 오류와 같이 몇 차례 반복하면 성공하는 오류가 있다.
→ Some errors, such as communication failures, may succeed if retried several times.

 

각 태스크 실행 시에 고정 파라미터가 부여되어 있다. 일별 배치 처리라면, 특정 날짜가 파라미터가 된다.
→ Each task execution is assigned fixed parameters. In daily batch processing, a specific date is used as a parameter.

 

태스크의 재시도(재실행) 간격을 5분이나 10분 정도로 두면 성공할 수 있다.
→ Setting the retry interval of a task to around 5 or 10 minutes can lead to a successful run.

 

‘백필’이란 파라미터에 포함된 날짜를 순서대로 바꿔가면서 일정 기간의 태스크를 다시 실행함을 의미한다.
→ “Backfill” refers to rerunning tasks over a specific period by changing the date parameter in sequence.

 

테스트 삼아 조금씩 백필을 실행하여 어떠한 오류가 발생하는지 혹은 발생하지 않는지 확인한다.
→ You can test backfill gradually to check whether any errors occur or not.

 

Airflow 에서는 원자성과 멱등성을 갖춘 스크립트를 작성해야 한다.
→ In Airflow, scripts must be written with atomicity and idempotency.

 

각 태스크는 원칙적으로 ‘완벽하게 성공’ 하거나 ‘완벽하게 실패’ 해야한다. ‘중간까지만 성공’하는 상황은 만들지 않아야 한다.
→ Each task should either “completely succeed” or “completely fail”—situations where it only partially succeeds must be avoided.

이 문제를 회피하는 방법 중 하나는, 각 태스크가 시스템에 변경을 가하는 동작을 한 번만 하도록 설정하는 것이다. 이를 atomic operation 이라고 부른다. 이를 통해 안정성을 높일 수 있다.
→ One way to avoid this issue is to ensure that each task performs system-changing operations only once. This is called an atomic operation, and it helps improve stability.

 

아주 작은 가능성도 만들지 않아야 하는 상황에서는, 오류의 내용을 반드시 확인하고 수동으로 처리 및 복구해야 한다.
→ In situations where even the slightest risk must be avoided, the error details must be reviewed and recovery should be handled manually.

 

‘멱등성’이란, 동일한 태스크를 여러 번 실행해도 동일한 결과를 만든다는 뜻이다. 멱등성이 갖춰진 실행을 idempotent operation 이라고 부른다.
→ Idempotency means that executing the same task multiple times produces the same result. 

An execution with this property is called an idempotent operation.

 

데이터를 덮어 쓰는 작업은 멱등성을 갖춘 작업이다. ‘치환’은 반복해도 결과가 변하지 않으므로 멱등하다고 할 수 있다.
→ Overwriting data is an idempotent operation. Since replacement yields the same result even when repeated, it can be considered idempotent.

 

멱등한 태스크를 만들기 위해선 태스크에 부여된 파라미터를 이용해 고유한 이름을 생성하고, 여러 번 실행해도 항상 치환이 실행되도록 설계하면 된다.
→ To create an idempotent task, generate a unique name using the task’s parameters and design it 

so that replacement is always executed, even if run multiple times.

 

테이블을 1일마다 혹은 1시간마다 파티션으로 분할하고, 파티션 단위로 치환하도록 한다.
→ Partition the table daily or hourly, and perform replacement at the partition level.

 

재시도 횟수를 늘림과 동시에, 조금씩 재시도 간격을 넓혀나가는 것을 지수 백오프(exponential backoff)라고 한다.
→ Increasing the number of retries while gradually expanding the interval between them is called exponential backoff.

 

재시도 간격을 1초, 2초, 4초… 로 증가시킨다. 최대 7회 반복한다.
→ Retry intervals increase as 1 second, 2 seconds, 4 seconds, and so on. This is repeated up to 7 times.

 

태스크마다 예상되는 실행 시간과 종료 예정 시간이 넘으면 통지해주는 도구도 있다.
→ There are tools that notify you when a task exceeds its expected execution or end time.

 

그 태스크가 만족하는 기준을 정한다는 의미에서 워크플로 관리에서의 SLA(Service Level Agreement)라고 부른다.
→ In workflow management, this is referred to as an SLA (Service Level Agreement), meaning the defined criteria that a task must meet.

 

태스크를 멱등으로 구성하는 것이 어렵다면, 그것을 포기하고 원자성을 지닌 태스크만으로 운용한다.
→ If it’s difficult to make a task idempotent, then you can abandon that and operate only with tasks that have atomicity.

 

이 경우, 태스크 재실행 시 데이터 중복이 발생할 수 있으므로, 자동 재시도는 반드시 무효로 하고, 오류 발생 시 수작업으로 복구한다.
→ In this case, task retries may result in data duplication, 

so automatic retries must be disabled, and recovery should be done manually in case of failure.

 

중간 테이블을 만들어 처리한 후, 마지막에 목적 테이블에 한 번에 추가하는 것이 안전하다.
→ It is safer to process data in an intermediate table first 

and then append it to the target table all at once at the end.

 

파일 복사에서 오류가 발생한다면, 파일 서버 측의 성능 한계가 원인일 수 있다.
→ If an error occurs during file copying, it may be due to performance limitations on the file server side.

 

태스크가 너무 클 경우에는 나누고, 너무 작을 경우에는 하나로 모은다. 그래서 각 태스크가 적절한 크기가 될 수 있도록 조정한다.
→ If a task is too large, split it; if it’s too small, combine it. 

Adjust each task so that it has an appropriate size.

 

초기 MapReduce 의 구현은 쓸데없는 것이 많아서 더 이상 시대에 맞지 않는 설계가 되어버렸다.
→ The early implementation of MapReduce had a lot of unnecessary components, making its design outdated for today’s needs.

 

DAG(directed acyclic graph)는 다음과 같은 성질을 갖고 있다. 노드와 노드가 화살표로 연결된다. 각 노드 연결이 순환되지 않는다.
→ A DAG (Directed Acyclic Graph) has the following properties: nodes are connected by arrows, and these connections never form cycles.

 

데이터 플로우에서는 실행해야 할 일련의 태스크를 DAG 에 의한 데이터 구조로 표현한다.
→ In data flow, a sequence of tasks to be executed is represented using a DAG data structure.

 

화살표는 태스크의 실행 순서를 의미한다.
→ The arrows represent the execution order of the tasks.

 

하나의 노드에서 처리가 끝나지 않으면 다음 처리로 진행할 수 없다.
→ If processing in one node is not completed, the next step cannot proceed.

 

양쪽 모두가 보완 관계를 갖는다.
→ Both sides complement each other.

 

스트림 처리에서는 데이터가 도달하는 것과 거의 동시에 처리가 시작된다.
→ In stream processing, processing begins almost at the same time the data arrives.

 

처리 내용은 미리 정해 둘 필요가 있으며, 과거 날짜로 거슬러 올라가 재실행하는 것은 고려하지 않는다.
→ The processing logic must be defined in advance, and reprocessing data from past dates is not considered.

 

배치 처리와 같이, 실행시에 데이터양이 정해지는 것을 유한 데이터(bounded data) 라고 한다.
→ Like in batch processing, data with a known size at execution time is called bounded data.

 

시트림 처리와 같이, 제한없이 데이터가 보내지는 것을 무한 데이터(unbounded data) 라고 한다.
→ Like in stream processing, data that is sent without limit is called unbounded data.

 

배치 처리는 데이터의 처리가 끝나면 종료되는데, 스트림 처리는 프로그램을 정지할 때까지 끝없이 계속 실행된다.
→ Batch processing ends once all data has been processed, 

whereas stream processing continues indefinitely until the program is stopped.

 

스트림 처리에서 ‘느리게 전송된 데이터를 어떻게 취급 할 것인가’는 중요 이슈이다.
→ In stream processing, how to handle late-arriving data is a critical issue.

 

집계가 종료한 후 도착한 데이터도 있으므로, 스트림 처리의 결과는 본질적으로 부정확해질 수 있다.
→ Since some data may arrive after the aggregation is completed, 

stream processing results can be inherently inaccurate.

 

람다 아키텍처의 배치 레이어에서는 모든 데이터를 장기적인 스토리지에 축적하고 여러 번 재집계 할 수 있게 한다.
→ In the batch layer of the Lambda Architecture, all data is stored in long-term storage, 

allowing it to be re-aggregated multiple times.

 

배치 처리 결과는 서빙 레이어(serving layer)를 통해서 접근한다. 서빙 레이어에 응답이 빠른 데이터베이스를 설치하여 집계 결과를 바로 추출하도록 하는 것이다. 서빙 레이어에서 얻어진 결과를 배치 뷰(batch view) 라고 한다.
→ The results of batch processing are accessed through the serving layer. 

A fast-response database is placed in the serving layer to extract the aggregated results directly. 

The results obtained from the serving layer are called the batch view.

 

스트림 처리를 위한 스피드 레이어에서 얻은 결과를 실시간 뷰(realtime view) 라고 한다. 실시간 뷰는 배치 뷰가 업데이트 될 동안까지만 이용되며, 오래된 순으로 데이터가 삭제된다.
→ The result obtained from the speed layer for stream processing is called the realtime view. 

It is used only until the batch view is updated, 

and older data is deleted in order.

 

최근 24시간의 집계 결과는 실시간 뷰를 참고하고, 그 이전 데이터는 배치 뷰를 사용한다.
→ The aggregation results from the past 24 hours are taken from the realtime view, 

while older data is retrieved from the batch view.

 

람다 아키텍처의 장점은 실시간 뷰의 결과가 나중에 배치 뷰로 치환된다는 것이다. 스트림 처리의 결과는 일시적으로만 사용되며, 정확하지 않아도 큰 문제가 없다.
→ The advantage of the Lambda architecture is that the results from the realtime view are eventually replaced by the batch view. 

Since the results of stream processing are used only temporarily, slight inaccuracies are acceptable.

 

람다 아키텍처의 단점은 나쁜 효율이다. 스피드 레이어와 배치 레이어 모두 동일한 처리를 구현하고 있어 비효율적이다.
→ The downside of the Lambda architecture is poor efficiency. 

Both the speed layer and the batch layer implement the same logic, which is inefficient.

 

카파(kappa) 아키텍처는 스피드 레이어만 남긴다. 메세지 브로커의 데이터 보관 기간을 충분히 길게 설정하여,

이슈 발생시 메세지 배송 시간을 과거로 다시 설정하여 과거 데이터를 다시 읽고 재처리한다.
→ The Kappa architecture retains only the speed layer. 

It relies on setting a long retention period in the message broker, 

so that in the event of an issue, the delivery time of messages can be reset to the past to re-read and reprocess historical data.

 

카파 아키텍처의 단점은 높은 부하이다. 백필에 의해 다시 읽어오는 대량의 과거 데이터를 높은 자원을 사용하여 처리해야 하기 때문이다.
→ The downside of the Kappa architecture is high load, as(because) backfilling requires reprocessing large volumes of historical data using significant resources.

 

프로세스 시간과 이벤트 시간의 차이가 큰 메세지를 처리하는 것을 ‘out of order’ 데이터 문제라고 불린다.
→ Handling messages with a large gap between processing time and event time is referred to as the out-of-order data problem.

 

스트림 처리에서 종종 시간을 일정 간격으로 나누어 ’윈도우(window)’를 만들고 그 안에서 데이터 집계를 한다.
→ In stream processing, time is often divided into fixed intervals called windows, 

and data is aggregated within each window.

 

과거 1시간의 이벤트 수 추이를 그래프로 만들고 싶으면, 데이터를 1분 간격인 60개의 윈도우로 나누어 각각의 윈도우로 이벤트 수를 센다.
→ If you want to graph the event trend over the past hour, divide the data into 60 one-minute windows and count the number of events in each window.

 

이벤트 시간에 의해 윈도우를 나누는 것을 ‘이벤트 시간 윈도윙(event-time windowing)’ 이라고 한다.
→ Dividing windows based on event time is called event-time windowing.

 

이벤트 시간으로 보면, 메세지가 배송된 데이터는 무작위 순으로 나열된, 즉 ‘out of order’ 상태이므로, 이것을 이벤트 시간 순서로 정렬하고, 집계한다.
→ From the perspective of event time, the delivered messages are in a random order — that is, out of order — 

so they must be sorted by event time before aggregation.

 

때문에 과거 이벤트의 상태를 보관하면서, 데이터가 도달할 때마다 해당하는 윈도우를 재집계한다.
→ Therefore, the system must retain the state of past events 

and re-aggregate the corresponding window whenever new data arrives.

 

데이터를 무한히 계속 보관할 순 없으므로 일정 시간 이상 늦게 온 데이터는 무시한다.
→ Since data cannot be stored indefinitely, data that arrives too late beyond a certain time threshold is ignored.