[ML] 머신러닝 시스템 설계 : 3장 데이터 엔지니어링 기초
ML
머신러닝 시스템 설계(Designing Machine Learning Systems) - 데이터 엔지니어링 기초 : 데이터 소스, 데이터 포맷
본 게시물은 한빛미디어의 <머신러닝 시스템 설계>를 참고하여 작성하였습니다.
<서론>
프로그래머스의 과제테스트 연습 중 연습과제에서 [실무 역량 과제] 데이터 분석 및 조작에서 json 파일로 핸들링하는 과정에서 json 파일에 있는 각 프로퍼티에 접근해서 조건에 맞는 프로퍼티*(property) 객체에 있는 값을 조건으로 확인하고 가져오는 그런 과제가 있었다.
일단 나는 pandas의 데이터프레임을 다루는 것이 훨씬 익숙해서, 판다스 모듈을 불러와서 핸들링 했는데, vs code 자체에서 모듈이 안깔려있어서, 그냥 json 자체로 핸들링했어야 했다.
사실 json이라는 게 어떻게 생겼는지는 알긴 하고, 개발하면서 json 타입으로 바꿔서 request, response는 했지만 제대로 Json이 반정형 데이터라는거 그이상 그이하는 모르고 있었는데, 옆자리 개발자가 해당 책을 추천해주면서 이 부분 공부하라고 해서 지금 하는 중임.. 고맙다 따봉 재호야
*property (프로퍼티) : 기본적으로는 어떤 값이나, 이 값이 다른 값과 연관되어 있을 때 property 라고 부름
예를 들어 문자열에는 lenght라는 property가 포함되어 있는데, 이 property는 문자열 안에 있는 문자의 양을 정수로 나타낸 값을 담고 있음
MDN(https://developer.mozilla.org/ko/docs/Glossary/property/JavaScript)
에서는 property가 데이터 구조와 연관된 속성을 나타내고, (1) 인스턴스 프로퍼티(Instance Property), (2) 정적 프로퍼티(Static Property) 두 종류로 나눠진다고 한다.
- 인스턴스 프로퍼티(Intance Property)는 특정 object 인스턴스의 특정한 데이터를 가지는 것, 정적 프로퍼티(Static Property)는 모든 object 인스턴스들에게 공유되는 데이터를 가지고 있다.
- 즉 property는 이름(string/symbol), 값(primitive, method, object reference)를 가지고 있는데, property가 object을 가지고 있다는 것은 property가 object reference를 가지고 있다는 것을 줄여 말하는 것이라고 한다.
참조 : https://blog.naver.com/magnking/220966405605
<본론>
Chapter 3. 데이터 엔지니어링 기초
- 일반적인 ML 프로젝트에서 사용하는 다양한 데이터 소스를 살펴보고 데이터 저장하는 포맷 알기
- 데이터 저장은 추후 해당 데이터를 검색(retrieval) 할 경우 필요한데,
저장된 데이터를 검색하려면 데이터 포맷뿐 아니라 데이터가 어떻게 구조화됐는지 아는 것이 중요하다. - 데이터 모델은 특정 데이터 포맷으로 저장된 데이터가 구조화되는 방식을 정의한다.
*search와 retrieval 은 '검색' 이지만 두 용어는 엄밀히 말하자면 다르다고 함
'search'는 검색 엔진에서 키워드와 관련된 정보를 찾는 프로세스고, 'retrieval'은 이미 데이터베이스나 스토리지에 저장되거나 색인된 정보에 액세스하는 프로세스임
- 데이터 모델이 실제 세계의 데이터를 표현하면, 데이터베이스는 데이터가 시스템에 저장되는 방식을 지정한다.
- 프로덕션에서는 일반적으로 데이터를 여러 프로세스 및 서비스에 걸쳐 처리한다.
- 예를 들어, 피처 엔지니어링 서비스와 예측 서비스가 있다고 할 때,
피처 엔지니어링 서비스는 원시 데이터에서 피처를 계산하고, 예측 서비스는 그 피처를 기반으로 예측값을 생성하므로 피처 엔지니어링 서비스에서 계산된 피처를 예측 서비스로 전달한다. - 이러한 프로세스 간에 데이터를 전달하는 다양한 모드가 있는데,
이러한 전달 모드에서 데이터 스토리지 엔진에서 사용하는 '과거 데이터'와 실시간 전송에 사용하는 '스트리밍 데이터' 라는 두 가지 데이터 유형이 나온다. - 각 유형들의 데이터의 처리는 '배치처리' 와 '스트림 처리' 패러다임이 필요하다.
3.1 데이터 소스
-
ML 시스템은 다양한 소스에서 온 데이터로 작동하므로, 데이터마다 특성/목적/처리방법이 다르고 데이터 소스를 파악하면 데이터를 보다 효율적으로 사용할 수 있다.
-
대표적인 데이터 소스는 사용자가 명시적으로 입력하는
사용자 입력 데이터(user input data)로 텍스트, 이미지, 비디오, 업로드된 파일이다.- 위 데이터는 사용자가 원격으로 잘못된 데이터를 입력할 수 있어 포맷이 잘못되기 쉬운데, 텍스트가 너무 길거나 짧을 수도 있고 numerical value에 텍스트를 입력할 수 도 있는데, 파일 업로드 권한을 허용하면 사용자가 잘못된 포맷으로 파일을 업로드 할 수 있으므로
user input data는 철저한 검사와 처리가 필요하다.
- 위 데이터는 사용자가 원격으로 잘못된 데이터를 입력할 수 있어 포맷이 잘못되기 쉬운데, 텍스트가 너무 길거나 짧을 수도 있고 numerical value에 텍스트를 입력할 수 도 있는데, 파일 업로드 권한을 허용하면 사용자가 잘못된 포맷으로 파일을 업로드 할 수 있으므로
-
다른 소스는
시스템 생성 데이터(system-generated data)로, 시스템의 여러 구성 요소에서 생성되며 구성 요소는 다양한 로그와 모델 예측 같은 시스템 출력이 있다.- 로그는 시스템의 상태와 중요한 이벤트(메모리 사용량/인스턴스 수/호출된 서비스/사용된 패키지)를 기록하고, 데이터 처리 및 모델 훈련을 위한 대규모 배치 작업과 관련된 다양한 작업의 결과를 기록하는데, '시스템이 어떠헥 작동하는지에 대한 가시성을 제공' 한다.
-
이외에 회사의 서비스 및 엔터프라이즈 애플리케이션에서 생성된
내부 데이터베이스로, 재고/고객 관계/자산 등을 관리하고, ML 모델에서 직접 사용되거나 ML 시스템의 다양한 구성 요소에서 사용된다. -
또한
서드 파티 데이터가 있다. 퍼스트 파티 데이터는 회사에서 사용자 또는 고객에 대해 이미 수집하고 있는 데이터, 세컨드 파티 데이터는 다른회사에서 자체 고객에 대해 수집하는 데이터로 제공받으려면 비용을 지불해야 하는 단어이다.- 서드 파티 데이터는 공공데이터를 수집한다. 서드 파티 데이터는 일반적으로 공급업체에서 처리 후 판매한다.
3.2 데이터 포맷
- 데이터는 일회성으로 사용하지 않는 이상 저장이 필요하고 이를 지속(persist) 시킨다고 하는데, 데이터는 다양한 소스에서 가져오고 액세스 패턴이 달라 저장하기가 항상 간단하지 않고 비용이 많이 들 수 도 있다.
- 데이터가 향후 어떻게 사용될지 고려해 포맷을 선택해야 한다
이 책에서는 고려해야할 질문으로
(1) 멀티모달(multimodel) 데이터, 즉 이미지와 텍스트를 모두 포함하는 데이터는 어떻게 저장할 것인지?
(2) 저렴하고 빠르게 액세스하려면 데이터를 어디에 저장해야 하는지?
(3) 복잡한 모델을 다른 하드웨어에서 올바르게 로드하고 실행하려면 어떻게 저장해야 하는지?
를 말하고 있다.
- 데이터 구조나 객체 상태를 저장 혹은 전송하고 나중에 재구성할 수 있는 포맷으로 변환하는 프로세스를
데이터 직렬화(data erialization)라고 하는데, 이러한 직렬화 포맷은 매우 다양하다.- 사람이 읽을 수 있는 human readability 인지, 텍스트인지 이진 binary인지 등의 다양한 특성을 고려 한다.
- 데이터 직렬화 포맷에는 JSON, CSV, 파케이, Avro, Protobuf, pickle 등이 있다.
JSON
- JavaScript Object Notation, 자바스크립트에서 파생됐지만 언어 독립적임
- 사람이 읽을 수 있으며 키-값 (key-value) 쌍 패러다임
- Json 파일의 데이터는 스키마에 커밋한 후 스키마를 변경하기 위해 다시 돌아가는 번거로운 작업이 필요하기도 하고, 텍스트 파일이라 저장 공간을 많이 차지한다.
행 우선 포맷 vs 열 우선 포맷
- CSV(Comma-separated values) 와 파케이의 비교
■ CSV는 행 우선으로, 행의 연속 요소가 메모리에 나란히 저장되고, 파케이는 열 우선으로 열의 연속 요소가 메모리에 나란히 저장된다.
예를 들어, 데이터셋에 샘플 1,000개가 있고, 각 샘플이 feature를 10개를 가지고 있을 때에 CSV 같은 행 우선 포맷은 샘플에 액세스(오늘 수집된 모든 샘플 액세스), 파케이 같은 열 중심 포맷은 featue에 액세스(모든 샘플의 타임스탬프에 액세스) 하는 것이 좋다.
■ 열 기반 포맷을 사용하면, 데이터가 수천개의 피처로 대용량일 때 효율적인데, 예를 들어 승차 공유(ride-sharing) 트랜잭션 데이터에 feature가 1,000개가 있고, 시간/위치/거리/가격 등 4가지 feature만을 원할 때, 열 우선 포맷은 각 피처에 해당하는 열 4개를 직접 읽지만 행 우선 포맷은 행의 크기를 모르는 경우 모든 열을 읽은 다음 네 열로 필터링한다.
행 크기를 안다고해도 캐싱을 활용할 수 없고 메모리 안에서 이동해야 하므로 느리다.
■ 그러나, 행 우선 포맷을 사용하면 더 빠른 데이터 쓰기가 가능한데, 데이터에 새로운 예제를 계속 추가해야하는 상황이면, 행 우선 포맷 파일에 쓰는 편이 빠르다.
■ 대체로 쓰기를 많이 수행하면 행 우선 포맷, 읽기를 많이 수행하면 열 우선 포맷이 낫다.
** 넘파이(Numpy) 와 판다스(Pandas)
-
판다스(Pandas)는
열 포맷 중심이다.
판다스는 '데이터프레임(DataFrame)'을 기반으로 구축 됐고, 행과 열이 있는 2차원 테이블이다.
넘파이는 행 우선인지 열 우선인지 지정할 수 있으며, ndarray가 생성될때 순서를 지정하지 않으면 기본적으로 행 우선이 된다.
텍스트 포맷 vs 이진 포맷
-
CSV와 JSON은 텍스트 파일인 반면 파케이 파일은 이진 파일임
-
텍스트 파일은 일반 텍스트 파일로 사람이 읽을 수 있지만, 이진 파일은 텍스트가 아닌 모든 파일을 지칭하며, 원시 바이트를 해석하는 방법을 알고 있는 프로그램에서 읽거나 사용하기 위한 파일임
-
이진 파이른 간결하고 텍스트 파일에 비해 공간을 절약함
예를 들어 숫자 1000000을 텍스트 파일에 저장하면 일곱 글자이고, 각 문자가 1바이트면 7바이트가 필요함. 반면에 int32로 저장하면 32비트, 즉 4바이트만 차지함 -
AWS는 파케이 포맷을 사용하기를 권장하는데, 파케이 포맷은 텍스트 포맷에 비해 언로드 속도가 최대 2개 빠르고, 아마존 S2에서 최대 6배 적은 스토리지를 사용함
3.3 데이터 모델
- 관계형 모델과 NoSQL 모델
- 관계형 모델에서 데이터는 관계 relation으로 구성되어, 각 관계는 튜플의 집합임.
관계형 모델을 따르는 데이터는 CSV나 파케이 같은 파일 포맷으로 저장됨
관계는 정규화하는 편이 좋은데, 정규화하면 데이터가 여러 관계로 분산되어, 분산된 데이터를 다시 조인할 수 있지만 테이블이 크다면 조인에 비용이 많이 든다.-NoSQL은 관계형 데이터 모델이 엄격한 스키마를 따르고 스키마 관리가 어렵다는 단점을 보완한다. 관계형 모델도 지원하면서, 비관계형 모델인 문서 모델과 그래프 모델 유형이 있다.
- 문서 모델은 단일 연속 문자열로 JSON, XML 또는 이진 형식인 BSON 인코딩된 '문서' 개념을 기반으로 구축됐다.
- 각 문서마다 고유한 키가 있어 문서를 검색하는데 사용된다.
- 문서 컬렉션은 관계형 데이터베이스의 테이블과 유사하고 문서는 행과 유사함
- 그러나 문서 컬렉션이 테이블보다 훨씬 유연함
- 테이블에서는 모든 행이 동일한 스키마를 따라야 하지만 (열 순서가 같아야 하는), 같은 컬렉션에 있는 문서 간에는 스키마가 완전히 다를 수 있다.
- 문서 모델은 스키마를 적용하지 않아 종종 스키마리스(schemaless) 모델이라고 불린다.
- 관계형 모델보다 지역성(locality)이 우수해서, 관계형의 책 정보가 책 테이블과 출판사 테이블에 분산되어 있지만 문서 모델은 책 정보를 모두 문서 하나에 저장할 수 있어 검색이 쉬워진다.
- 문서간 조인은 관계형 모델에서 테이블 간 조인을 실행할 떄보다 어렵고 덜 효율적임
예를 들어서, 25달러 미만인 책을 모두 찾으려고 할떄 모든 문서를 읽고 가격을 추출해 25달러와 비교해서 미만인 책을 반환해야 한다.
- 문서 모델과 관계형 모델은 각각 강점이 달라서, 한 데이터베이스 시스템에서 두 모델을 각기 다른 작업에 사용한다. - 관계형 모델에서 데이터는 관계 relation으로 구성되어, 각 관계는 튜플의 집합임.
■ 그래프 모델
- 그래프는 노드(node)와 엣지(edge)로 구성되고,
edge는 노드 간의 관계를 나타낸다.
- 그래프 구조로 데이터를 저장하는 데이터베이스를 그래프 데이터베이스라고 한다.
- 문서 데이터베이스에서 각 문서의 내용이 우선이면 그래프 데이터 베이스에서는 데이터 항목 간의 관계가 우선이다.
- 그래프 모델에서는 관계를 명시적으로 모델링하므로, 관계를 기반으로 데이터를 검색하는 것이 빠름
3.4 데이터 스토리지 엔진 및 처리
-
데이터 포맷과 데이터 모델은 사용자가 데이터를 저장하고 검색하는 바업과 관련된 인터페이스를 지정한다.
-
데이터베이스가 최적화되는 워크로드는 두 가지 유형이 있는데, '트랜잭션 처리'와 '분석 처리' 이다.
- 트랜잭션 처리
- 트랜잭션 : 온갖 종류의 작업
- 트랜잭션이 생성될 때 삽입되고 때때로 변경될 때 업데이트되고, 필요하지 않아지면 삭제되는 처리를 온라인 트랜잭션 처리(Online Transaction processing; OLTP)라고 한다.
- 트랜잭션은 일반적으로 ACID(Atomicity, Consistency, Isolation, Durabilit; 원자성/일관성/격리성/지속성)을 생각한다.
- 데이터를 다양한 관점에서 바라보는 쿼리에 효율적인 처리를 '온라인 분석 처리(Online Analytical processing; OLAP) 라고 한다.
- 트랜잭션 처리
-
2021년 기준 구글 트렌드에 따르면 OLTP와 OLAP는 구식 용어임.
기존의 OTP와 OLAP 패러다임은 스토리지와 처리가 밀접하게 결합되어 있어서, 데이터 저장 방식이 곧 데이터 처리 방식이었다. -
오늘날 데이터 세계에서는 데이터가 처리되고 제공되는 속도를 나타낼 때 온라인, 니어라인(nearline), 오프라인 등을 사용한다.
- 온라인 처리 : 데이터를 즉시 입력 및 출력할 수 있음
- 니어라인 : 니어-온라인(near-online) 데이터를 즉시 사용할 수 는 없지만 사람의 개입 없이 빠르게 온라인으로 만들 수 있음
- 오프라인 : 데이터를 즉시 사용할 수 없으며 온라인으로 만드는데 사람의 개입이 필요함
3.5 데이터플로 모드
- 프로덕션에서는 프로세스가 ㅏ나가 아닌 여러개라서, 메모리를 공유하지 않은 서로 다른 프로세스 간에 데이터를 전달하는 방법이 필요하다.
- 데이터가 한 프로세스에서 다른 프로세스로 전달될 때 데이터가 한 프로세스에서 다른 프로세스로 흐르는 '데이터플로'가 생긴다.
- 데이터플로에는 세 가지 주요 모드가 다.
- 데이터베이스를 통한 데이터 전달
- 서비스를 통한 데이터 전달(REST와 RPC API에서 제공하는 요청)
- 실시간 전송을 통한 데이터 전달(APACHE Kafka)
<결론>
책 내부에 판다스를 이용해서 데이터프레임에 행별로 액세스 한 것, 열별로 액세스한 것에 대한 실행속도가 나오는데, 판다스는 위에서 말한 것 처럼 데이터프레임에 열 우선 포맷이라 행 별로 액세스하면 열 별로 액세스 할 때보다 훨씬 느리다.
이걸 넘파이 배열로 변환하면 액세스 속도는 훨씬 빨라진다.
프로그래머스에서 주어졌던 customer.json 파일을 가지고 한 번 해봤는데
json이 진짜.. 확연히 빠르네 ㅋㅋ ㅅㄱ..
무조건 for문 돌리면 느려질거라고 생각했던 나의 톱밥 같은 생각이었다.
데이터 수가 적어서 유의미한 차이는 보이지 않지만,
수가 늘어나면 실행속도면에서 유의미한 차이가 나지 않을까 ?
암튼.. 열기반, 행기반 ㅇㅋㅇㅋ 알
