머신러닝 시스템 설계 - Chapter 3. 데이터 엔지니어링 기초
3.1 데이터 소스
ML 시스템은 다양한 소스에서 온 데이터로 작동
소스 별 데이터마다 특성, 목적, 처리 방법 등이 다르므로 소스를 파악하면 데이터를 효율적으로 사용하는데 도움이 됨
사용자 입력 데이터 (user input data)
사용자가 명시적으로 입력하는 데이터
텍스트, 이미지, 비디오, 업로드된 파일 등이 해당
사용자가 원격으로 데이터를 입력하기 때문에 잘못된 포맷이 될 가능성이 매우 높으므로 철저한 검사와 처리가 필요 (수치가 필요한 곳에 문자 입력, 깨진 파일 등등)
사용자는 즉각적인 반응을 원하므로 빠른 처리가 필요한 경향이 있음
시스템 생성 데이터 (system-generated data)
시스템의 여러 구성 요소에서 생성된 데이터 (로그, 모델 예측 같은 시스템 출력 등)
로그는 시스템의 상태와 중요 이벤트를 기록 (메모리 사용량, 인스턴스 수, 호출된 서비스 , 대규모 배치 작업 등)
로그는 시스템에 대한 가시성을 제공해 시스템을 디버깅하고 개선하는데 활용되고 보통은 볼 필요가 없지만 사고가 났을 경우 매우 유용
시스템에서 직접 생성되므로 포맷이 잘못될 가능성이 매우 낮고 바로 처리할 필요가 없음 (사고가 났을 경우에는 매우 빠른 처리가 필요)
ML 시스템은 디버깅하기 어려우므로 일반적으로 가능한 모든 것을 기록
이런 식으로 기록하게 되면 로그의 볼륨이 매우 빠르게 증가하여 대표적인 2가지 문제를 야기함
첫 번째는 봐야 할 로그가 너무 많아 어디를 봐야하는 지 알기가 어려워지는 문제 발생
로그스태시(Logstash), 데이터독(Datadog), Logz.io 등의 서비스는 로그를 처리하고 분석해주며 ML 모델을 사용해 방대한 로그를 처리하는데 도움을 줌
두 번째는 빠르게 증가하는 로그를 저장할 방법에 관한 문제 (결국 비용에 관한 문제)
로그가 유용할 때만 저장하고 필요 없어지면 빠르게 삭제하고 로그 액세스 빈도가 낮다면 낮은 액세스 스토리지에 저장해 비용을 절약할 수 있음
또한 ML 시스템은 사용자 행동을 기록하는 데이터를 생성
대표적으로 클릭, 제안 선택, 스크롤, 확대 축소, 페이지에 머문 시간 등이 있음
이런 데이터들은 시스템 생성 데이터이지만 사용자 데이터의 일부로 간주되며 개인정보 보호 규정이 적용
내부 데이터베이스
회사의 다양한 서비스 및 엔터프라이즈 애플리케이션에서 생성된 데이터
재고, 고객 관계, 사용자를 비롯한 자산 등을 관리
서드 파티 데이터
퍼스트 파티 데이터 - 회사에서 사용자 또는 고객에 대해 이미 수집하고 있는 데이터
세컨드 파티 데이터 - 회사가 돈을 지불하고 구입한 다른 회사가 수집한 고객 데이터
서드 파티 데이터 - 직접적인 고객이 아닌 공공 데이터
기술 발전으로 매우 다양한 서드 파티 데이터를 구할 수 있게 됨
3.2 데이터 포맷
데이터는 일회성으로 사용하지 않은 이상 저장이 필요함
이 때 소스도 다양하고 액세스 패턴도 다르므로 향후 어떻게 사용될지 고려해 포맷을 선택해야 함
고려 사항 예시)
멀티모달 데이터 (이미지와 텍스트) 저장 방법
저렴하고 빠른 액세스가 가능한 저장 방법
복잡한 모델을 다른 하드웨어에서 올바르게 로드하고 실행할 수 있는 저장 방법
데이터 직렬화 (data serialization) - 데이터 구조나 객체를 저장 혹은 전송하고 나중에 재구성할 수 있는 포맷으로 변환하는 프로세스
직렬화 포맷은 매우 다양
3.2.1 JSON
JSON (JavaScript Obeject Notation) 널리 활용되는 포맷으로 자바스크립트에서 파생됐지만 언어 독립적이며 많은 프로그래밍 언어들이 JSON 생성과 파싱을 지원
사람이 읽을 수 있는 텍스트 형식으로 저장되며 키-값 (key-value) 패러다임은 단순하지만 강력
3.2.1 행 우선 포맷 vs 열 우선 포맷
csv 와 파케이는 공통적이면서도 별개의 패러다임을 가지고 있음
csv 는 행 우선 포맷으로 행의 연속 요소가 메모리에 나란히 저장
파케이는 열 우선 포맷으로 열의 연속 요소가 메모리에 나란히 저장
최근의 컴퓨터는 순차 데이터를 더 효율적으로 처리하므로 테이블이 행 우선이라면 행에 액세스하는 편이 열에 액세스하는 것보다 빠름
즉, 포맷이 행 우선이라면 데이터를 행으로 액세스할 때가 더 빠름
행 우선 포맷은 더 빠른 데이터 쓰기가 가능
데이터에 새로운 행이 계속 추가되어야 한다면 행 우선 포맷을 활용하는 것이 좋음
열 우선 포맷은 유연한 열 기반 읽기가 가능
데이터에 컬럼이 많을 때 특정 컬럼만 필요한 경우에 특히 유용
행 우선 포맷일 경우 전체를 다 읽어온 후에 특정 컬럼을 다시 필터링 하는 작업 필요
대체로 쓰기를 많이 수행할 때는 행 우선 포맷이 낫고, 열 기반 읽기를 많이 수행할 때는 열 우선 포맷이 나음
3.2.3 텍스트 포맷 vs 이진 포맷
csv, JSON 과 같은 파일은 텍스트 파일이고 파케이 등과 같은 파일은 이진 파일
이진 파일은 간결하고 (컴퓨터가 해석하기에) 텍스트 파일에 비해 공간을 절약할 수 있음
사람이 굳이 읽을 필요가 없고 잦은 입출력이 요구된다면 이진 파일이 효율적일 수 있음
3.3 데이터 모델
데이터 모델은 데이터를 표현하는 방법
자동차를 표현한다면 제조사, 모델, 연도, 색상, 가격 등으로 표현할 수도 있고
차량 소유자, 번호판, 등록된 주소지 등으로 표현할 수도 있음
데이터를 표현하는 방법은 시스템 구축 방식 뿐만 아니라 시스템이 해결하는 문제에도 큰 영향
위의 자동차 예시에서 자동차를 구매하고자 한다면 첫 번째 표현이 편하지만 경찰이 범죄자를 잡는다고 한다면 두 번째 표현이 편함
3.3.1 관계형 모델
관계형 모델에서 데이터는 관계(relation) 으로 구성되며 각 관계는 튜플의 집합
테이블은 이런 관계를 시각적으로 표현한 것으로 테이블의 각 행이 튜플을 구성
관계에는 순서가 없으므로 행의 순서나 열의 순서를 섞더라도 여전히 동일한 관계를 구성
관계형 모델을 따르는 데이터는 일반적으로 csv나 파케이 같은 포맷으로 저장됨
관계형 모델은 데이터를 정규화(normalization)하여 정규형으로 만드는 편이 좋음
하지만 정규형으로 만들고 나면 데이터가 여러 관계로 분산되어 테이블을 조인하는데 비용이 커질수도 (시간이 오래 혹은 많은 자원이 필요) 있음
데이터베이스에서 원하는 데이터를 검색하는데 사용하는 언어를 쿼리 언어(query language)라고 함
관계형 데이터베이스에서 가장 많이 사용하는 쿼리언어는 SQL
SQL의 중요한 특징은 선언적 언어라는 점
파이썬과 같은 명령형 언어처럼 작업에 필요한 단계를 모두 지정해주고 컴퓨터는 그 단계들만 실행하고 출력을 반환하는 것이 아니라 원하는 출력만 지정해주면 컴퓨터가 알아서 필요한 단계를 파악하는 방식
보통 이런 방법과 세부적인 실행 순서는 데이터베이스 시스템(DBMS)에서 결정
특히 쿼리를 실행하는 방법은 쿼리 옵티마이저가 담당
3.3.2 NoSQL
관계형 데이터 모델은 다양한 분야에서 잘 쓰이고 있지만 한계를 보이는 분야도 있음
특히 데이터가 엄격한 스키마를 따라야 하고 그 스키마를 관리하는 것이 어려움
NoSQL은 비관계형 데이터베이스를 논의하는 모임의 해시태그로 시작되었다가 점차 ‘Not only SQL’로 의미가 확대
비관계형 데이터모델의 주요 유형으로는 문서 모델과 그래프 모델이 있음
문서 모델은 데이터가 독립적인 문서로 제공되고 서로 간의 관계가 드문 유스케이스에서 유용
그래프 모델은 데이터 항목 간의 관계가 흔하며 관계가 중요한 유스케이스에서 유용
문서 모델
문서 모델은 ‘문서’라는 개념을 기반으로 구축
문서는 단일 연속 문자열로 JSON, XML, BSON(Binary JSON)으로 인코딩됨
문서 데이터베이스 내 모든 문서는 동일 포맷으로 인코딩됐다고 가정하고 각 문서마다 고유한 키가 있어 문서를 검색하는데 사용
문서 컬렉션은 관계형 데이터베이스의 테이블과 유사하며 문서는 행과 유사하고 관계를 문서 컬렉션으로 변환도 가능
하지만 문서 컬렉션이 테이블보다 훨씬 유연함
테이블에서는 모든 행이 같은 스키마를 따라야 하지만 문서 컬렉션 내에서 문서들은 스키마가 완전히 다를 수 있음 (스키마리스 schemaless 모델)
스키마리스 모델들은 데이터를 저장하는 시점에서는 스키마를 준수하지 않아도 되지만 데이터를 읽는 시점에서는 스키마를 맞추기 위한 처리 작업이 필요 (schema on read)
문서 모델은 관계형 모델보다 지역성 (locality)이 우수
관계형 모델은 정규화를 거쳐 정보가 여러 테이블에 분산되어 있지만 문서 모델에서는 관련된 정보를 하나의 문서에 저장할 수 있음
하지만 문서 간 조인은 관계형 모델에서의 테이블 조인보다 훨씬 어렵고 비효율적
문서 모델과 관계형 모델이 강점을 가지는 작업이 다르므로 적절한 고려가 필요
그래프 모델
그래프 모델은 ‘그래프’개념을 기반으로 구축
그래프는 노드(node) 와 에지(edge)로 구성되며 에지는 노드 간의 관계를 나타냄
문서 모델이 각 문서의 내용이 우선이라면 그래프 모델은 데이터 항목 간의 관계가 우선
그래프 모델은 관계를 명시적으로 모델링하므로 관계를 기반으로 검색하는 것이 빠름
그래프 데이터베이스는 관계가 명시적으로 저장되어 있으므로 특정 유형 쿼리 수행에 강점을 보임
데이터 모델에 따라 수행하기 쉬운 쿼리가 있고 어려운 쿼리가 있으므로 애플리케이션에 따라 적절한 데이터 모델을 선택하는 것이 좋음
3.3.3 정형 데이터 vs 비정형 데이터
정형 데이터는 미리 정의된 데이터 모델 (스키마)를 따름
어떤 항목을 어떤 이름과 어떤 자료형으로 최대 크기까지 지정해서 저장함
정형 데이터의 단점은 데이터를 미리 정의된 스키마에 맞춰줘야 한다는 점
특히 스키마가 변경된다면 이전에 저장된 데이터를 포함해 모든 데이터에 소급적용 해야함
비즈니스 요구사항은 시간에 따라 변하므로 많은 스키마 변경이 있을 수 밖에 없음
비정형 데이터는 스키마에 관계없는 데이터 모델
일반적으로 텍스트가 많지만 이미지, 오디오 등 다양한 유형이 될 수도 있음
비정형 데이터 일지라도 구조 추출에 도움이 되는 패턴을 가지고 있을 수 있지만 모든 행이 같은 패턴을 지니고 있지 않아도 됨
정형 데이터를 저장하는 저장소를 데이터 웨어하우스(Data warehouse)라고 하고 비정형 데이터를 저장하는 저장소를 데이터 레이크(Data lake)라고 함
데이터 레이크는 일반적으로 처리 전 원시 데이터를 저장하는데 사용하고 데이터 웨어하우스는 사용 가능한 형식으로 처리된 데이터를 저장하는데 사용
3.4 데이터 스토리지 엔진 및 처리
데이터 포맷과 모델은 데이터를 저장하고 검색하는 방법과 관련된 인터페이스를 지정
스토리지 엔진은 데이터가 시스템에 저장되고 검색되는 방식을 구현함
일반적으로 데이터베이스가 최적화되는 워크로드에는 트랜잭션 처리와 분석 처리가 있음
3.4.1 트랜잭션 처리와 분석 처리
트랜잭션(transaction)이란 데이터베이스와 연관된 모든 작업을 뜻함
트랜잭션마다 포함하는 데이터는 다르지만 처리 방식은 애플리케이션 간 유사
트랜잭션은 생성될 때 삽입되고 때때로 업데이트되며 필요가 없어지면 삭제됨
이러한 처리를 온라인 트랜잭션 처리 online transaction processing (OLAP) 라고 함
트랜잭션은 사용자가 관련되는 경우가 많으므로 빠른 처리(낮은 레이턴시)가 필요하고 가용성이 높아야 함
이런 특성을 ACID(원자성, 일관성, 격리성, 지속성) 라 함
모든 트랜잭션 데이터베이스가 반드시 ACID를 지킬 필요는 없음
트랜잭션 데이터베이스는 행 우선인 경우가 많으므로 특정 쿼리에는 효율적이지 않을 수 있음
특히 열의 집계 등과 같은 모든 행을 검색해야 하는 쿼리에 비효율적
온라인 분석 처리 online analytical processing (OLAP) 는 데이터를 다양한 관점에서 바라보는 쿼리 처리에 효율적으로 설계됨
OLTP와 OLAP 라는 용어는 세 가지 이유로 현재는 많이 사용하지 않음
- OLTP와 OLAP가 분리된 것은 기술의 한계 때문
예전에는 트랜잭션 쿼리와 분석 쿼리를 모두 효율적으로 처리하는 DBMS를 만들기 어려웠음
하지만 현재는 CockroachDB처럼 분석 쿼리를 처리하는 트랜잭션 데이터베이스도 있고 Apache Iceberg나 DuckDB처럼 트랜잭션 쿼리를 처리하는 분석 DB도 존재
- 기존 OLTP와 OLAP 패러다임은 스토리지와 처리가 밀접하게 결합
데이터 저장 방식이 곧 데이터 처리 방식이 됨
동일한 데이터를 다른 저장 방식으로 저장해 각기 다른 유형의 쿼리를 처리하기도 함
최근에는 처리와 스토리지를 분리하는 패러다임으로 발전
데이터는 동일한 위치에 저장하고 처리 레이어에서 각기 다른 유형의 쿼리에 최적화
- ‘온라인’ 이라는 용어가 너무 많은 의미를 가지게 됨
예전에는 단순히 ‘인터넷에 연결되었음’을 나타내는 말
현재는 프로덕션에 반영되어 실시간으로 입출력이 가능함을 뜻하는 말이 됨
3.4.2 ETL: Extract, Transform, Load
ETL은 데이터가 추출되어 DB나 DW에 적재되기 이전에 원하는 포맷으로 변환되는 프로세스를 뜻함
추출은 모든 데이터 소스에서 원하는 데이터를 추출하는 과정
이 과정에서 데이터가 손상되거나 포맷이 올바른지 검증하는 과정도 거침
추출은 프로세스의 첫 번째 단계이므로 이 과정이 올바르게 수행되면 이후 처리에 드는 시간이 크게 줄어듦
변환은 데이터 처리가 수행되는 프로세스의 핵심 단계
여러 소스에서 온 데이터를 정제하고 값 범위를 표준화 하는 등의 작업을 수행하는 단계
이 외에도 중복 제거, 정렬, 집계, 새로운 피처 도출 등의 작업을 포함
적재는 추출되어 변환된 데이터를 DB, DW와 같은 대상에 적재할 방법과 빈도를 결정하는 단계
최근 데이터 수집이 쉬워지면서 모든 데이터를 구조화한 상태로 유지하기 어려워짐
따라서 모든 데이터를 스키마가 필요없는 데이터 레이크에 저장한 후 나중에 처리하는 방식을 고려하기도 함
이렇게 데이터를 먼저 적재한 후 나중에 처리하는 프로세스를 ELT (Extract, Load, Transform) 라고 함
ELT 패러다임은 데이터 저장 전에 필요한 처리가 없어 신속한 저장이 가능
하지만 데이터가 늘어남에 따라 ELT는 비효율적
구조화되지 않은 데이터 레이크에서 필요한 데이터를 검색하는 것은 비효율적
또 많은 애플리케이션이 클라우드 상에서 실행되고 인프라가 표준화되어 데이터 구조도 표준화되어 미리 정의된 스키마에 넣는 편이 더 합리적
최근에는 데이터 레이크의 유연성과 데이터 웨어하우스의 관리 측면을 결합한 하이브리드 솔루션도 제공되고 있음 (Databricks, Snowflake 등)
3.5 데이터플로 모드
앞서 설명한 데이터 포맷, 모델, 저장 및 처리는 모두 단일 프로세스에 맞춘 설명
실제 프로덕션에는 여러 프로세스가 동작하므로 메모리를 공유하지 않는 프로세스 간 데이터를 전달하는 방법이 필요
데이터가 한 프로세스에서 다른 프로세스로 전달되는 것을 데이터플로(Dataflow)라고 함
데이터플로에는 세 가지 주요 모드가 존재
- 데이터베이스를 통한 데이터 전달
- 서비스를 통한 데이터 전달
REST, RPC API 등을 사용
- 실시간 전송을 통한 데이터 전달
Apache Kafka, Amazon Kinesis 등
3.5.1 데이터베이스를 통한 데이터 전달
두 프로세스 간 데이터를 전달하는 가장 쉬운 방법은 데이터베이스를 활용하는 방법
A, B 두 프로세스 간 데이터를 전달해야 한다면 A 프로세스에서는 데이터를 DB에 저장하고 B 프로세스에서는 그 데이터를 읽어오기만 하면 됨
하지만 두 프로세스가 모두 같은 DB에 접속하지 못할 수도 있음 (회사가 다르다거나 망분리 정책 등)
또 데이터가 필요한 두 프로세스 모두 준비되어 있어야 하고 DB의 입출력이 느려져 레이턴시 요구사항을 충족하지 못할 수도 있음
3.5.2 서비스를 통한 데이터 전달
서로 다른 프로세스를 연결하는 네트워크를 통해 데이터를 전달하는 방식
A 프로세스는 필요한 데이터를 지정하는 요청을 B 프로세스에 보내고 B 프로세스는 동일한 네트워크를 통해 요청된 데이터를 반환
프로세스가 요청을 통해 통신하므로 요청 기반(request-driven) 이라고 함
서비스를 데이터 전달은 서비스 지향(service-orient) 아키텍처와 밀접한 연관
서비스를 통한 데이터 전달은 서로 연결만 되면 독립적인 회사나 애플리케이션에서 운영 가능
혹은 두 서비스가 동일한 애플리케이션의 일부일 수도 있음
애플리케이션의 각 구성요소를 별도의 서비스로 구성하면 서로 독립적으로 개발하고 테스트 가능
이렇게 애플리케이션을 별도의 서비스로 구조화하는 것을 마이크로서비스아키텍처(MSA) 라고 함
네트워크를 통한 데이터 전달 방식은 REST(Representational state transfer) 와 RPC(Remote Procedure call) 이 가장 널리 사용
REST는 네트워크를 통한 요청을 위해 설계
RPC는 원격 네트워크에 대한 서비스 요청이 함수나 메소드 호출과 동일하게 보이도록 설계됨
3.5.3 실시간 전송을 통한 데이터 전달
서비스를 통한 전달은 서비스가 많아질수록 데이터 전달량이 급증
데이터 전달에 따른 병목으로 전체 시스템이 느려질 수도 있음
요청 기반 방식은 동기식으로 데이터가 올바르게 전송되고 수신될 때까지 대기
이 과정에서 한 서비스가 중단되면 연결된 (해당 데이터가 필요한) 모든 서비스가 같이 중단
서비스끼리 직접 연결되어 통신하면 매우 복잡한 연결망이 구성되고 전체 시스템에 영향
중간에 서비스 간 데이터 전달을 조정하는 브로커를 두면 각 서비스들은 브로커와만 통신하면 됨
엄밀히 따지면 DB도 브로커이지만 DB에 데이터를 쓰고 저장하는 시간이 너무 오래 걸림
따라서 메모리 내 스토리지를 사용해 데이터를 중개
이벤트 - 실시간 전송을 통해 브로드캐스트 되는 데이터 조각을
이런 아키텍처를 이벤트 기반 아키텍처(event-driven) 라고 하고 실시간 전송은 이벤트 버스
요청 기반 아키텍처는 데이터보다 로직에 더 의존하는 시스템에 적합하고 이벤트 기반 아키텍처는 데이터가 많은 시스템에서 더 잘 작동
실시간 전송의 일반적인 두 가지 유형은 pubsub 방식과 메시지 큐 방식
pubsub(publish-subscribe) 방식에서 모든 서비스는 실시간 전송으로 여러 토픽에 이벤트를 게시할 수 있으며 해당 토픽을 구독하는 모든 서비스는 토픽 내 모든 이벤트를 읽어올 수 있음
데이터를 생성하는 서비스는 어떤 서비스에서 그 데이터가 소비되는 지에는 관심 없음
리텐션 정책을 통해 특정 시간이 지나면 삭제되거나 영구 보존할 수도 있음
메시지 큐 방식은 대상 소비자가 있으며 메시지를 알맞은 소비자에게 전달하는 방식
pubsub 솔루션 예시 - Apache Kafka, Amazon Kinesis
메시지 큐 솔루션 예시 - Apache RocketMQ, RabbitMQ 등
3.6 배치 처리 vs 스트림 처리
데이터는 DB나 DW, DL에 도착하면 과거 데이터가 됨
과거 데이터는 보통 주기적으로 수행되는 배치 작업(batch) 에 의해 처리 (매일 업무 종료 후 하루 판매량 합계 등)
데이터를 배치 작업에서 처리하는 것을 배치 처리(batch processing)
배치 처리를 효율적으로 수행하기 위해 맵리듀스나 스파크 같은 분산처리 시스템이 고안됨
카프카나 키네시스같이 실시간 전송 데이터가 있으면 스트리밍 데이터가 존재
스트림 처리(stream processing) 은 스트리밍 데이터에 대한 계산을 의미
스트리밍 데이터에 대한 계산도 주기적으로 수행할 수 있지만 배치 작업에 비해 그 주기가 훨씬 짧음
스트림 처리가 제대로 수행되면 레이턴시가 짧음 (데이터를 저장하기 전에 먼저 처리하기 때문에)
보통 스트림 처리는 맵리듀스나 스파크 같은 도구를 활용할 수 없어 비효율적이라고 생각하지만 항상 그렇지는 않음
Apache Flink 와 같은 스트리밍 기술들은 뛰어난 확장성을 가지고 있고 분산 처리 (병렬 계산)이 가능
스트림 처리의 강점은 상태 유지 계산에 존재
30일 간의 평균을 계산한다고 할 때 배치 작업은 매일 30일치의 데이터가 필요하지만 스트림 처리를 하면 매일 신규 데이터만 계산하고 그 결과만 업데이트 해 중복을 방지할 수 있음
ML 에서는 자주 변경되지 않는 피처를 계산할 때 주로 배치 처리를 사용
배치 처리를 통해 추출된 피처는 배치 피처, 정적 피처(static feature) 라고 부름
스트림 처리는 빠르게 변경되는 피처를 계산할 때 사용
스트리밍 피처 혹은 동적 피처(dynamic feature) 라고 부름
실제 프로덕션에서는 정적 피처와 동적 피처가 모두 필요한 문제도 많음
스트리밍 데이터와 배치 데이터를 처리하고 둘을 결합해 ML 모델에 공급할 인프라가 필요
데이터 스트림에서 계산을 수행하려면 별도의 스트림 계산 엔진이 필요 (배치 계산 엔진인 맵리듀스와 스파크 같은)
계산이 간단한 경우에는 실시간 전송의 내장 스트림 계산을 사용하면 되지만 복잡한 경우에는 효율적인 스트림 계산 엔진이 요구됨
Apache Flink, KSQL, Spark Streaming 등과 같은 엔진이 존재하고 KSQL이 업계에서 인정받고 있음
스트림 처리가 배치 처리보다 어려운 이유는 데이터가 들어오는 비율과 속도가 다양하고 양에도 제한이 없기 때문
배치 프로세서가 스트림 처리를 하게 만들기보다 스트림 프로세서가 배치 처리를 하도록 만드는 편이 더 쉬움
3.7 정리
Uploaded by N2T