데이터 집약적 애플리케이션 설계

11장. 스트림 처리

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

작동하는 복잡한 시스템은 항상 작동하는 단순한 시스템에서 진화한 것으로 밝혀집니다. 그 반대의 명제 또한 사실로 보입니다: 처음부터 설계된 복잡한 시스템은 결코 작동하지 않으며 작동하도록 만들 수도 없습니다.

존 갈, 체계론 (1975)

10장에서는 파일 집합을 입력으로 읽고 새로운 출력 파일 집합을 생성하는 일괄 처리 기술에 대해 설명했습니다. 출력은 파생 데이터의 한 형태, 즉 필요한 경우 배치 프로세스를 다시 실행하여 다시 만들 수 있는 데이터 세트입니다. 이 간단하지만 강력한 아이디어가 어떻게 검색 색인, 추천 시스템, 분석 등을 만드는 데 사용될 수 있는지 살펴보았습니다.

그러나 10장 내내 한 가지 큰 가정, 즉 입력이 유한한, 즉 알려진 유한한 크기이므로 배치 프로세스는 입력 읽기가 완료된 시점을 알 수 있다는 가정이 남아있었습니다. 예를 들어, MapReduce의 핵심인 정렬 작업은 출력 생성을 시작하기 전에 전체 입력을 읽어야 합니다. 가장 마지막 입력 레코드가 가장 낮은 키를 가진 레코드이므로 첫 번째 출력 레코드가 되어야 할 수도 있으므로 출력을 일찍 시작하는 것은 옵션이 될 수 없습니다.

실제로 많은 데이터는 시간이 지남에 따라 점진적으로 도착하기 때문에 한계가 없습니다. 사용자가 어제와 오늘 데이터를 생산했고 내일도 계속해서 더 많은 데이터를 생산할 것입니다. 폐업하지 않는 한, 이 프로세스는 결코 끝나지 않으므로 데이터 세트는 의미 있는 방식으로 "완전"하지 않습니다 [1]. 따라서 배치 프로세서는 데이터를 인위적으로 일정 기간의 덩어리로 나누어야 합니다(예: 매일 하루가 끝날 때 하루 분량의 데이터를 처리하거나 매시간 한 시간 분량의 데이터를 처리하는 등).

일일 배치 프로세스의 문제점은 입력의 변경 사항이 하루 후에야 출력에 반영되므로 참을성이 없는 많은 사용자에게는 너무 느리다는 것입니다. 지연을 줄이기 위해 처리를 더 자주 실행하거나(예: 매초마다 1초 분량의 데이터를 처리), 심지어는 고정된 시간 조각을 완전히 버리고 모든 이벤트가 발생하는 대로 처리하는 식으로 연속적으로 처리할 수도 있습니다. 이것이 바로 스트림 처리의 기본 개념입니다.

일반적으로 '스트림'은 시간이 지남에 따라 점진적으로 제공되는 데이터를 의미합니다. 이 개념은 Unix의 stdin 및 stdout, 프로그래밍 언어(지연 목록)[2], 파일 시스템 API(예: Java의 FileInputStream), 인터넷을 통한 오디오 및 비디오 전송 등 여러 곳에서 나타납니다.

이 장에서는지난 장에서 살펴본 배치 데이터에 대응하는 무제한적이고 점진적으로 처리되는 데이터 관리 메커니즘인 이벤트 ...