책너두 (데이터 중심 애플리케이션 설계) 36일차 (~414p)

요약

• 35일차와 36일차는 정말 몇번을 읽어도 이해가 잘 안가서 다음에 좀 더 집중해서 읽어본다.
• 일괄 처리 워크플로의 출력에 대해 이해함
  • 검색 색인 구축
  • 일괄 처리의 출력으로 키-값을 저장
  • 일괄 처리 출력에 관한 철학
• 하둡과 분산 데이터베이스의 비교에 대해 이해함.
  • 저장소의 다양성
  • 처리 모델의 다양성
  • 빈번하게 발생하는 결함을 줄이는 설계

메모

일괄 처리 워크플로의 출력

• 지금까지 다양한 알고리즘을 사용해 맵리듀스 작업의 워크플로를 구현하는 것을 살펴봄.
  • 그러나 결과가 어떻게 나오고 왜 이 작업을 수행하는지에 대한 질문이 남아 있음.
• 데이터베이스 질의에서는 트랜잭션 처리(OLTP)와 분석 목적을 구별했음.
  • OLTP 질의는 소량의 레코드를 조회하는 반면, 분석 질의는 대량의 레코드를 스캔하고 그룹화, 집계 연산을 수행하여 결과를 보고서 형태로 출력함.
  • 이러한 리포트는 분석가와 관리자들이 주로 소비함.
• 일괄 처리는 트랜잭션 처리와 분석 사이에 위치함.
  • 입력 데이터셋 대부분을 스캔하는 것이 일반적이지만, 맵리듀스 작업의 워크플로는 분석 목적으로 사용하는 SQL 질의와는 다름.
  • 일괄 처리의 출력은 일반적으로 보고서 형태가 아닌, 다른 형태의 구조를 가짐.

검색 색인 구축

• 맵리듀스는 구글에서 검색 엔진에 사용할 색인을 구축하기 위해 처음 사용됨.
  • 구글이 색인을 구축하는 목적으로 맵리듀스를 더이상 사용하지 않지만, 검색 색인을 구축하는 과정을 살펴보면 맵리듀스를 이해하는 데 도움됨.
• 전문 검색 엔진인 루씬은 효율적으로 특정 키워드를 조회하여 문서 ID의 목록(포스팅 목록)을 찾는 용어 사전 파일로 작동함.
  • 일괄 처리는 정해진 문서 집합에 대한 전문 검색 색인을 구축하는 데 매우 효율적임.
  • 매퍼는 문서 집합을 파티셔닝하고, 각 리듀서는 해당 파티션에 대한 색인을 구축함.
  • 이후 색인 파일은 분산 파일 시스템에 저장됨.
• 문서 집합이 변경될 경우, 일반적인 방법은 전체 문서 집합을 대상으로 주기적으로 전체 색인 워크플로를 재수행하고, 수행이 끝나면 이전 색인 파일을 새로 생성된 색인으로 바꿈.
  • 또 다른 방법으로는 증분 색인을 구축하는 것도 가능함.
  • 이런 증분 처리 과정은 색인에 문서를 추가, 삭제, 갱신하는 데 사용되며, 루씬은 세그먼트 파일을 새로 기록하고 백그라운드에서 증분식으로 부분 파일을 병합하고 압축함.

일괄 처리의 출력으로 키-값을 저장

• 일괄 처리 작업의 출력을 키-값으로 저장하는 것은 맵리듀스를 활용한 머신러닝 시스템 및 추천 시스템 구축에 유용함.
• 이러한 출력은 주로 데이터베이스 형태로 저장되며, 웹 애플리케이션에서 질의할 수 있음.
• 하지만 일괄 처리 작업이 직접 데이터베이스 서버로 요청을 보내는 것은 좋지 않은 방법임. 그 이유는 다음과 같음.
  • 네트워크 요청으로 인한 성능 저하
  • 데이터베이스 과부하 및 질의 성능 저하
  • 외부 시스템에 드러나는 부수효과
• 훨씬 좋은 해결책은 일괄 처리 작업 내부에서 완전히 새로운 데이터베이스를 구축하고, 분산 파일 시스템의 작업 출력 디렉터리에 저장하는 방법임.
• 맵리듀스 작업 내에서 데이터베이스 파일을 구축하는 기능을 지원하는 다양한 키-값 저장소가 있다.
  • 예를 들어 볼드모트(Voldemort), 테라핀(Terrapin), 엘리펀트 DB(ElephantDB), HBase 벌크 적재(HBase bulk loading) 등이 있다.
• 데이터베이스 파일 생성은 맵리듀스의 효과적인 활용법이며, 키 추출 및 정렬 과정이 필요함.
• 키-값 저장소는 대부분 읽기 전용이기 때문에 자료 구조가 매우 단순함.
• 이러한 저장소는 원자적으로 새 파일로 전환되며, 문제가 발생하면 기존 파일로 쉽게 전환할 수 있음.

일괄 처리 출력에 관한 철학

• 일괄 처리 출력에 관한 철학에서는 유닉스 철학이 데이터 플로우를 깔끔하게 처리하며 실험을 장려함.
  • 이를 통해 프로그램 수정 및 디버깅이 쉬워짐.
  • 이와 비슷한 철학을 따르는 맵리듀스 작업은 높은 성능과 간편한 유지보수를 제공함.
    • 일괄 처리 출력에서 버그가 발생하면, 이전 버전으로 되돌리거나 출력 위치를 바꾸는 것만으로 복구가 가능함.
    • 손상을 되돌릴 수 없는 환경보다 빠른 기능 개발이 가능함.
    • 맵리듀스 프레임워크는 실패한 태스크를 자동으로 재스케줄링하고 재실행함.
    • 다양한 작업에서 동일한 파일 집합을 입력으로 사용할 수 있음.
    • 맵리듀스 작업은 로직과 연결 작업을 분리하여 코드 재사용이 가능하함.
• 유닉스와 하둡의 차이점 중 하나는 유닉스 도구가 타입이 없는 텍스트 파일을 가정하고 처리하는 반면, 하둡은 구조화된 파일 형식(예: 아브로, 파케이)을 사용하여 저수준 구문 변환 작업의 일부를 줄일 수 있음.
  • 이러한 구조화된 파일 형식은 효율적인 스키마 기반 부호화를 제공하고 시간이 지남에 따라 스키마를 발전시킬 수 있음.

하둡과 분산 데이터베이스의 비교

• 하둡과 분산 데이터베이스의 비교를 살펴보면, 하둡은 유닉스의 분산 버전과 비슷하며, HDFS 파일 시스템과 맵리듀스가 주요 구성 요소임.
  • 반면, 맵리듀스가 새로운 개념이 아니었던 대규모 병렬 처리(MPP) 데이터베이스는 과거에 이미 구현되었음.
  • ex) 감마 데이터베이스 머신, 테라데이터, 탠덤 논스톱SQL
• 두 시스템의 가장 큰 차이점은, MPP 데이터베이스는 장비 클러스터에서 분석 SQL 질의를 병렬로 수행하는 것에 초점을 두는 반면, 맵리듀스와 분산 파일 시스템의 조합은 아무 프로그램이나 실행할 수 있는 운영체제와 비슷한 속성을 제공함.
  • 이로 인해 하둡은 더 다양한 작업을 수행할 수 있는 유연성을 가진다.

저장소의 다양성

• 저장소의 다양성을 보면, 데이터베이스는 특정 모델(ex: 관계형, 문서형)을 따라 데이터를 구조화해야 하는 반면, 분산 파일시스템의 파일은 어떤 데이터 모델과 인코딩이든 기록할 수 있는 연속된 바이트일 뿐임.
  • 이로 인해 하둡은 데이터의 형태와 상관없이 HDFS에 데이터를 덤프할 수 있는 가능성을 제공함.
  • 반대로, MPP 데이터베이스를 사용하면 데이터와 질의 형태를 신중하게 선행 모델링해야 함.
• 이 아이디어는 데이터 웨어하우스의 개념과 유사하며, 원시 데이터를 수집하고 스키마 설계를 나중에 고려하는 것이 데이터 수집의 속도를 높일 수 있음.
  • 이 접근법은 스키마 온 리드(schema-on-read)라고 불림.
• 하둡은 ETL 프로세스 구현에 자주 사용되며, 트랜잭션 처리 시스템에서 데이터를 원시 형태로 분산 파일 시스템에 덤프한 후 맵리듀스 작업을 통해 데이터를 정리하고 관계형으로 변환하여 MPP 데이터웨어하우스로 옮김.
  • 이러한 디커플링은 분산 파일 시스템이 어떤 형식으로 부호화된 데이터든지 지원하기 때문에 가능함.

처리 모델의 다양성

• 처리 모델의 다양성에서, MPP 데이터베이스는 일체식 구조로서 통합된 소프트웨어 조각들을 통해 성능 최적화를 달성함.
  • 이는 SQL 질의 언어를 사용하여 다양한 질의 표현과 시맨틱을 허용함.
  • 그러나, SQL 질의만으로는 머신러닝, 추천 시스템, 이미지 분석 등의 복잡한 처리를 수행하기 어려움.
• 맵리듀스를 이용하면 엔지니어는 자신이 작성한 코드를 대용량 데이터셋에서 쉽게 실행할 수 있음.
  • 하지만, 맵리듀스는 제한적이고 성능이 떨어질 수 있어, 하둡 위에서 다양한 처리 모델이 개발됨.
• 하둡 생태계는 다양한 처리 모델을 지원하여, 동일한 클러스터 내에서 다양한 작업부하를 함께 처리할 수 있음.
  • 이로 인해 데이터로부터 가치를 끌어내기 쉽고, 새로운 처리 모델을 사용한 실험도 훨씬 쉬움.
  • 하둡 생태계는 HBase와 임팔라 같은 다양한 데이터베이스를 포함하며, 공존할 수 있고 같은 시스템으로 통합할 수 있음.

빈번하게 발생하는 결함을 줄이는 설계

• 맵리듀스와 MPP 데이터베이스의 주요 차이점은 결함 처리 방식과 메모리 및 디스크 사용 방식임.
  • 일괄 처리 작업은 온라인 시스템보다 결함에 덜 민감하며, MPP 데이터베이스는 작은 재시도 비용으로 오류를 처리할 수 있음.
  • 반면 맵리듀스는 맵 또는 리듀스 태스크의 실패를 견딜 수 있으며, 데이터를 되도록 디스크에 기록하려 함.
• 맵리듀스는 대용량 작업에 적합함.
  • 많은 데이터를 처리하고 오랜 시간 수행하는 작업의 경우, 태스크 하나가 실패할 가능성이 높음.
  • 이런 상황에서 전체 작업을 재수행하는 것은 낭비이기 때문에, 맵리듀스는 태스크 수준에서 복구를 시도함.
• 구글의 혼합 사용 데이터 센터에서는 온라인 프러덕션 서비스와 오프라인 일괄 처리 작업이 같은 장비에서 실행됨.
  • 이러한 아키텍처는 낮은 우선순위의 연산 자원을 초과 할당할 수 있게 하여, 자원 활용도를 높임.
  • 그러나 맵리듀스 작업이 낮은 우선순위로 실행될 때, 높은 우선순위 작업에 의해 자원을 회수당할 위험이 있음.
• 이러한 이유로, 맵리듀스는 자주 발생하는 태스크 종료에도 견딜 수 있도록 설계되었다.
  • 이것은 하드웨어를 신뢰할 수 없기 때문이 아니라, 프로세스를 임의로 종료할 수 있으면 연산 클러스터에서 자원 활용도를 높일 수 있기 때문임.
  • 그러나 오픈소스 클러스터 스케줄러는 선점 방식을 많이 사용하지 않는다.
  • 이에 대한 대안은 다음 절에서 논의된다.