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

 

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

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

 

 

< 4. 벌크 형과 스트리밍 형의 데이터 수집 >

 

 

데이터는 항상 여러 디스크에 복사되기 때문에, 일부 하드웨어가 고장나더라도 데이터가 손실되진 않는다.
→ Since data is always copied across multiple disks, even if some hardware fails, the data won’t be lost.

 

계속 늘어나는 대량의 작은 파일들은 시간이 지남에 따라 성능을 저하시키는 요인이 된다.
→ A growing number of small files becomes a factor in performance degradation over time.

(degradation <-> improvement, enhancement, optimization)

 

객체 스토리지에서 소량의 데이터를 자주 읽고 쓰는 것은 적합하지 않다. 데이터양에 비례하여 네트워크 통신 오버헤드가 커지기 때문이다.
→ Object storage is not suitable for frequent read/write operations on small amounts of data, 

because the network communication overhead is high relative to the data size.

 

파일 크기가 증가하면 네트워크 전송에 시간이 걸려 예상치 못한 오류 발생률을 높인다.
→ As file size increases, network transfer takes more time, and the likelihood of unexpected errors increases.

 

거대한 데이터는 한 번에 처리하지 않고 적당히 나눠서 처리하여 문제 발생을 줄인다.
→ Massive data should be divided and processed in parts rather than all at once to reduce the risk of problems.

 

빅데이터는 단지 수집만 해서는 안 되고, 나중에 처리하기 쉽도록 준비해둬야한다.
→ Big data should not just be collected, but also prepared in a way that makes it easy to process later.

 

효율적으로 처리할 수 있는 파일이 크기는 얼마나 될까?
→ What is the optimal file size for efficient processing?

 

수집한 데이터를 가공하여 집계 효율이 좋은 분산 스토리지를 만드는 일련의 프로세스를 ’데이터 수집(data ingestion)’이라고 한다.
→ The process of refining collected data and building an aggregation-efficient distributed storage is called “data ingestion.”

 

이 둘은 기술적인 특성도, 사용되는 도구도 전혀 다르므로 그 성질을 이해한 다음에 구분해서 사용해야 한다.
→ These two differ entirely in both technical characteristics and tools used, so you must understand their nature and use them accordingly.

 

100개 파일을 전송하는데 100번 전송을 반복하고 있다면, 한 번에 모든 파일을 모아서 전송하는 것이 좋다.
→ If you’re transferring 100 files in 100 separate transfers, it’s better to combine them and send them all at once.

 

데이터양이 많을 때는 한 달 혹은 하루 단위로 전송하도록 태스크를 분해한다. 한 번의 태스크 실행이 너무 커지지 않도록 조정한다.
→ When handling large volumes of data, break tasks into monthly or daily units to prevent any single task from becoming too large.

 

문제가 발생했을 때 여러 번 데이터 전송을 재실행할 수 있다는 점이 ‘벌크 형’의 장점이다.
→ A key advantage of the “bulk” transfer type is that it allows for repeated retries when problems occur.

 

‘벌크 형’ 데이터 전송은 워크플로 관리 도구와의 궁합이 좋다.
→ Bulk-type data transfers work well with workflow management tools.

 

워크플로 관리 도구를 이용하여 과거의 데이터를 다시 가져오거나 실패한 작업을 재실행할 수 있다.
→ Workflow management tools allow you to retrieve historical data or rerun failed jobs.

 

Fluentd 는 내부에 효율적인 버퍼링 매커니즘을 갖고 있어, 일정한 시간 간격 혹은 특정 크기에 데이터를 모아서 외부로 내보낼 수 있다.
→ Fluentd has an efficient internal buffering mechanism that allows it to batch data by time intervals or size before sending it out.

 

Fluentd 는 메세지를 일방적으로 발송하는 것밖에 하지 못한다. 그래서 외부에서 Fluentd 에 요청하여 메세지를 꺼낼 수 없다.
→ Fluentd only sends messages in one direction, so you cannot pull messages from Fluentd by making external requests.

 

이 경우 서비스에서 제공되는 모바일 용의 편리한 개발 키트(SDK)를 사용하여 메세지를 보낸다.
→ In this case, messages are sent using a convenient mobile SDK provided by the service.

 

모바일 앱은 오프라인이 되는 경우도 많으므로 발생한 이벤트는 일단 SDK의 내부에 축적되고 온라인 상태가 되었을 때 모아서 보내도록 만들어져 있다.
→ Since mobile apps often go offline, events are first stored within the SDK and then sent in batches when the device is back online.

 

모바일 회선은 통신이 불안정하고 통신 오류에 따른 메세지 재전송이 여러 번 발생한다. 그래서 데이터가 중복될 가능성이 높기 때문에 특별한 중복제거 구조가 필요하다.
→ Mobile networks are unstable, and message retransmissions due to communication errors happen frequently. 

This increases the chance of duplicate data, so a dedicated deduplication mechanism is necessary.

 

‘토픽’은 메세지를 송수신하기 위한 대화방과 같은 것이다.
→ A “topic” is like a chat room for sending and receiving messages.

 

토픽에 전달된 메세지는 그 토픽을 구독중인 모든 클라이언트에 보내진다.
→ Messages sent to a topic are delivered to all clients subscribed to that topic.

 

구독자가 네트워크에서 분리된 경우, 나중에 메세지를 재전송받는 구조가 프로토콜 수준에서 구현되어 있다.
→ If a subscriber is disconnected from the network, the protocol includes mechanisms to resend messages later.

 

이렇게 역할을 분리함으로써 A 는 A의 작업에만 전념할 수 있고, 나머지 작업은 공통 시스템에 맡길 수 있다.
→ By separating roles in this way, A can focus solely on its own tasks while leaving the rest to the shared system.

 

‘스트리밍 형’의 메세지 배송은 성능과 신뢰성을 둘 다 만족하기 어렵다. 성능과 신뢰성은 트레이드오프 관계에 있다.
→ It is difficult for streaming-based message delivery to satisfy both performance and reliability, as the two are in a trade-off relationship.

 

외부에서 보내오는 메세지 양은 제어할 수 없기 때문에 급격한 데이터양 증가에 대응하는 것은 쉬운 일이 아니다.
→ Because the volume of incoming messages from external sources can’t be controlled, it’s not easy to handle sudden spikes in data.

 

만약 쓰기 성능의 한계에 의해 오류가 발생하면, 대부분의 경우 클라이언트는 메세지를 재전송하려고 한다.
→ If an error occurs due to write performance limitations, clients will usually attempt to resend the message.

 

성능적인 한계에 도달한 상황에서는 아무리 재전송해도 부하만 높아질 뿐 아무것도 해결되지 않는다.
→ Once you reach a performance limit, resending messages only increases the load without solving anything.

 

대량의 메세지를 안정적으로 받기 위해서는 빈번한 쓰기에도 견딜 수 있는 스토리지가 필요하다.
→ To reliably receive a large volume of messages, you need storage that can withstand frequent writes.

 

송신 측의 제어로 데이터를 보내는 방식을 ‘push 형’이라고 한다. 수신 측의 주도로 데이터를 가져오는 것을 ‘pull 형’이라고 한다.
→ A method where the sender controls the transmission is called “push.” 

When the receiver takes the initiative to fetch the data, it is called “pull.”

 

메세지 브로커인 Kafka 는 데이터의 쓰기 속도를 조정하기 위해 중간에 위치한 완충 부분이다.
→ Kafka, as a message broker, acts as a buffer in the middle to regulate the data write rate.

 

어떤 시스템이 100만 대의 장치에서 1분마다 100바이트의 메세지를 수신한다고 하자.
→ Suppose a system receives 100-byte messages every minute from one million devices.

 

시스템 전체가 받는 메세지는 초당 1.7만 메세지이며 데이터양은 1.66MB 이다. 데이터베이스는 초당 1.7만 번의 쓰기에 견뎌야 한다.
→ The system as a whole receives 17,000 messages per second, totaling 1.66 MB. The database must handle 17,000 writes per second.

 

코디네이터 자신도 정지될 수 있기 때문에, 코디네이터가 부재한 경우 시스템을 어떻게 운용 할 것인가 미리 합의해야한다.
→ Since the coordinator itself can go down, you need to decide in advance how to operate the system in its absence.

 

‘at least once’ 로 메세지를 받아오면 중복된 데이터를 받아올 수 있기 때문에, 애플리케이션 레벨에서 중복 제거 기능을 구현한다.
→ If you receive messages with “at least once” delivery, you may get duplicate data, so you must implement deduplication at the application level.

 

메세지의 중복을 제거하려면 해당 메세지가 과거에 받은 것인지 여부를 판정해야 한다.
→ To remove duplicate messages, you need to determine whether a message has already been received.

 

 오프셋을 이용하여 중복 제거가 가능하다. 전송해야 할 데이터에 파일명 등의 이름을 부여하고 그것을 작은 메세지에 싣어 배송한다. 그리고 각 메세지에는 파일 안의 시작 위치인 오프셋을 덧붙인다.
→ You can use offsets to deduplicate. Assign a name (such as a filename) to the data to be sent, include it in a small message, and add the starting position (offset) within the file to each message.

 

중복 메세지를 받으면 오프셋을 확인하여 같은 파일의 같은 장소에 덮어쓴다.
→ When a duplicate message is received, check the offset and overwrite the same location in the same file.

 

모든 메세지에 UUID(Universally Unique IDentifier) 같은 고유 ID 를 지정할 수 있다. 최근 1 시간 동안 받은 ID 만 기억해두고, 그보다 늦게 온 메세지의 중복은 허용한다.
→ You can assign a unique ID such as a UUID to each message. Keep only the IDs received within the last hour, and allow duplicates that arrive later.

 

원래 중복 제거란 종단 간에 실행하지 않으면 의미가 없다.
→ Deduplication is only meaningful when performed end-to-end.

 

클라이언트 상에서 메세지가 생성된 시간을 ‘event time’ 이라고 하고, 서버가 해당 메세지를 처리하는 시간을 ‘process time’ 이라고 한다.
→ The time a message is generated on the client is called “event time,”  (on the client side)

and the time the server processes the message is called “process time.”

 

데이터 분석의 대상이 되는 것은 이벤트 타임이기 때문에 이 시간의 차이가 성가신 문제를 일으킨다.
→ Since event time is the focus of data analysis, the difference between event time and process time can cause troublesome issues.

 

분산 스토리지에 메세지를 넣는 단계에서는 이벤트 타임이 아니라 프로세스 타임을 사용한다.
→ When inserting messages into distributed storage, process time is used instead of event time.

 

늦게 도착한 메세지는 과거의 이벤트 타임을 갖고 있다. 이벤트 타임을 기준으로 ’시계열 익덱스(time-series index)’를 만들어 정렬한 후 검색한다.
→ Late-arriving messages have past event times. A time-series index is built based on event time, sorted, and then used for querying.

 

조건절 푸시다운(Predicate Pushdown)이란, 데이터베이스 쿼리 최적화 기술 중 하나이다. 쿼리 실행 시 조건절을 가능한 한 늦게 적용하지 않고, 데이터 처리 초기 단계에서 가능한 한 빨리 적용하여 처리 효율을 높이는 것을 말한다. 즉, 불필요한 데이터 처리 단계를 줄여 쿼리 성능을 개선하는 방법이다.
→ Predicate pushdown is a database query optimization technique. Instead of applying query conditions late in execution, it applies them as early as possible to improve processing efficiency—reducing unnecessary steps and enhancing query performance.

 

가급적 읽어들이는 데이터의 양이 최소화되도록 데이터를 미리 정렬해둔다.
→ Data is pre-sorted to minimize the amount of data that needs to be read as much as possible.

 

데이터가 충분히 연속적으로 배치되어야 최적화 효과가 높다.
→ Optimization is most effective when the data is arranged in a sufficiently contiguous layout.

 

이벤트 타임 컬럼을 기준으로 파티셔닝한 테이블을 시계열 테이블(time-series table) 이라고 한다.
→ A table partitioned based on the event time column is called a time-series table.

 

시계열 테이블에서는 데이터가 시간 순서대로 저장되며, 데이터 검색 및 분석의 효율성을 위해 시간 정보를 기반으로 인덱싱한다.
→ In a time-series table, data is stored in chronological order and indexed based on time to enhance query and analysis efficiency.

 

더 좋은 방법은, 데이터 마트 테이블에 이벤트 타임으로 정렬된 데이터를 저장하는 것이다. 데이터 마트를 만드는 단계에서 이벤트 시간에 의한 정렬을 한다.
→ A better approach is to store data sorted by event time in the data mart table. 

The sorting by event time is done during the data mart creation stage.

 

ACID 특성은 트랜잭션 처리에 요구되는 4가지 성질을 말하며, 각각 Atomicity, Consistency, Isolation, Durability 를 의미한다. 일반적인 RDB 가 이 조건들을 충족하고 있다.
→ ACID refers to four properties required for transaction processing: Atomicity, Consistency, Isolation, and Durability. Traditional RDBs satisfy these conditions.

 

CAP 은 Consistency, Availability, Partition-tolerance 를 의미하며, 일반적으로 분산 시스템에서 CAP 에서 말하는 세 가지 성질을 동시에 만족할 수 없다.
→ CAP stands for Consistency, Availability, and Partition Tolerance

In distributed systems, it is generally not possible to satisfy all three simultaneously.

 

강한 일관성(Strong Consistency)과 최종 일관성(Eventual Consistency)은 분산 시스템에서 데이터 일관성을 보장하는 두 가지 주요 모델이다.
→ Strong consistency and eventual consistency are two major models used to ensure data consistency in distributed systems.

 

강한 일관성은 모든 읽기 작업이 가장 최근의 쓰기 연산을 반영하도록 보장한다.
→ Strong consistency guarantees that all read operations reflect the most recent write.

 

최종 일관성은 시간이 지남에 따라 모든 복제본이 결국에는 같은 값을 가지게 된다는 것을 보장한다.
→ Eventual consistency guarantees that all replicas will eventually converge to the same value over time.