10장: 일괄 처리

[LOG-INFO]

끄적끄적

• 시스템 종류
  • Service (Online System)
  • Request & Response: 클라이언트로부터 요청이 오면 바로 처리하고 응답해줌
  • 응답시간(Latency), 가용성(Reliability)이 주요 지표
  • Batch (Offline System)
  • 보통 매우 큰 입력 데이터를 한 번에 처리함
  • 보통 수분~수시간~수일 이 걸리기 때문에, 클라이언트가 응답을 기다리진 않음
  • 처리량(throughput)이 주요 지표
  • Stream (Near-Realtime system)
  • Consume & Produce: Input에 대해 처리를 함. 필요하면 producing도 함
• Unix의 Pipeline은 God
  • 인터페이스의 중요성 ++

  • DB에서도 표준 인터페이스가 잘 되어있으면 마이그레이션 쉬울텐데,,, 각 벤더 입장에선 해줄 이유가 없을라나

  • CDC가 어댑터 역할을 해주기는 하지만...

• 이번 장은 거의 하둡, 맵리듀스 공부..!
  • 예전엔 맵리듀스가 굉장히 대단한건 줄 알았는데, 그냥 매핑과 리듀싱을 해주는 간단한 모델이었음
  • 병렬성은 정말 뛰어난 듯
  • 현 직장 첫 임무가 Cassandra A -> Cassandra B 마이그레이션이었는데, 기존 계획은 Spring Batch를 통해 insert 하는거였음
  • 데이터가 너무 많아서 너무 오래 걸릴 것으로 예상. 테이블당 최소 몇 개월. 기한이 정해져있었기 때문에 단축해야했음
  • Spark를 이용해서 executor 늘려서 테이블당 최대 하루만에 마이그레이션 (Spark와 Mapreduce는 다르지만, 여러 노드가 나눠서 작업한다는 점은 같아서 생각남)
    • 다행히 spark-cassandra-connector 라는걸 제공해줘서 훨씬 간단히 작업할 수 있었음

• 뭔 놈의 조인이 이렇게 많지.... ㅠ 읽다가 지침

  • reduce-side join
  • skewed-join
  • shared-join
  • map-side join
  • broadcast hash join
  • partitioned hash join (=bucketed map join (in hive)
  • map-side merge join

[MinJunKweon]

p386. 지금은 맵리듀스의 중요성이 떨어지고 있지만

• Google은 2014년에 더이상 Map-Reduce를 사용하지 않는다고 발표
• Map-Reduce는 너무 일반화된 데이터 흐름 엔진이기 때문
• MapReduce가 이룬 것은 분산 처리로 데이터 플랫폼을 구축할 수 있다고 인식을 변화시켰다는 것
• 스토리지와 컴퓨팅이 점진적으로 확장 가능하고,
• 이기종 워크로드를 잘 지원하며,
• 비싼 머신보다 저렴한 머신에서는 결함이 더 자주 발생하지만, 이에 대해 강력한 내결함성을 가졌다는 것,
• 등등
• 구글은 MapReduce 대신 Cloud DataFlow 라는 걸 쓰기 시작했음 (2014년)

유닉스 철학

1. 각 프로그램이 한 가지 일만 하도록 작성하라
   • 새 작업을 하려면 기존 프로그램을 고쳐 새로운 기능을 추가해 프로그램을 복잡하게 만들기보다는 새로운 프로그램을 작성하라.
2. 모든 프로그램의 출력은 아직 알려지지 않은 다른 프로그램의 입력으로 쓰일 수 있다고 생각하라.
   • 불필요한 정보로 출력이 너저분해서는 안 된다.
   • 입력 형식으로 엄격하게 열을 맞춘다거나 이진 형태를 사용하지마라. 대화형 입력을 고집하지 마라.
3. 소프트웨어를 빠르게 써볼 수 있게 설계하고 구축하라.
4. 프로그래밍 작업을 줄이려면 미숙한 도움보단 도구를 사용하라
   • 도구를 빌드하기 위해 한참 둘러가야 하고 게다가 사용 후 바로 버린다고 할지라도 도구를 써라

p392. 동일한 데이터 모델인 데이터베이스 간에도 한쪽에서 다른 쪽으로 데이터를 옮기는 게 쉽지 않다. => 마이그레이션은 상당히 흔한 유즈케이스인데 왜일까? DB는 상업용으로 판매되는 케이스가 많기 때문에 자사 제품 이탈율을 줄이기 위해서?

p393. 프로그램의 출력을 파이프를 이용해 네트워크와 연결하지는 못한다. => netcat이나 curl를 사용할 수 있음. BSD 소켓 API는 in-out File Descriptor를 1개로 쓴다. (보통은 input / output 각각 1개씩 사용)

유닉스 도구가 성공적인 이유

• 유닉스 명령에 들어가는 입력 파일은 일반적으로 불변으로 처리됨 (사이드 이펙트 X)
• 파이프라인을 중단하고 파이프를 통해 less로 보내 원하는 형태로 출력이 나오는지 확인 가능 (디버깅 용이)
• 출력을 파일로 남기고, 다음단계의 입력으로 쓸 수 있음 (중간부터 재시작 가능)

Reducer는 병합하는 용도로 사용하기 위해서는 Mapper보다 메모리 가용량이 훨씬 커야하지 않나?

배치 프로세스의 출력을 웹 애플리케이션이 질의하는 DB로 보내는 방법이 있을까?

• 매퍼와 리듀서 내에서 DB 클라이언트 라이브러리를 사용해 DB에 직접 적재하는 방식
  • 단점1) 성능이 매우 안좋음
  • 단점2) DB I/O 과부하가 일어나 성능이 나빠질 수 있음. (장애 발생 가능)
  • 단점3) exactly once를 보장할 수 없음. 맵리듀스는 재시도가 가능한 설계
• 대안) 결과를 데이터 파일로 생성해서 DB에 bulk로 적재하는 방식
  • e.g.) Voldmort, Terrapin, ElephantDB, HBase Bulk Loading 등

[minkukjo]

끄적끄적

• 시스템은 크게 세 가지 유형으로 나뉜다.
  • 온라인 -> 서버 애플리케이션
  • 오프라인 -> 배치 애플리케이션
  • 준실시간 -> 스트림 ( 카프카, Rabbit MQ )
• 맵-리듀서.. 카프카? 라는 생각이 들었는데, 카프카처럼 다른 머신에서 동작하는건 아니고, 같은 HDFS 위에서 동작하는 기술이라는 것을 알게 되었다.
• 결국 분산 처리를 위한 구조로 가장 이상적인 구조는 맵리듀스라는 생각이 들었음
• 특정 유저의 활동 이벤트를 읽어서 매 번 DB에 질의하는 비용은 비싸다.
  • DB는 계속 변하므로 비결정적이고, DB 과부하가 걸리기 쉬운 구조다.
  • 이를 효율적으로 하기 위해 같은 저장소에다가 사본 데이터를 몰아두면 같은 HDFS상에 존재하므로 맵리듀스를 사용해 연관된 레코드를 같은 장소로 모아 효율적으로 처리가 가능해진다고 한다.
• 핫키 문제처럼 이러한 맵리듀서를 활용해 특정 키를 같은 장소에 모으는 방식은 쏠림 문제를 야기할 수 있다.
• 하이브같은 경우는 이러한 경우 쏠린 테이블을 명시적으로 지정하고 나머지 데이터는 별도 파일에 저장해버린다. (실제로 네이버 카페에서 중고나라를 이런식으로 처리하고 있다고 들었습니다.)
• 결국 맵 리듀스는 중간 상태를 계속 저장하므로 다른 머신에서 태스크를 읽어와서 실행할 수 있으므로 내결함성을 보장하고 있다고 한다.
• 읽으면 읽을 수록 저자의 기술적 깊이에 감탄하게 된다. 이 책이 한 명의 엔지니어의 손에 쓰여졌다는 사실이 믿기지 않을 정도로.

[HaeUlNam]

• 유닉스 인터페이스 - 파일 디스크립터, stdin, stdout
• Hadoop HDFS(Hadoop Distributed File System)
• Hadoop MapReduce 작업
  1. 입력 파일을 읽고, 레코드로 쪼갠다
  2. 각 입력 레코드마다 Mapper 함수를 호출해 키와 값을 추출
     1. Mapper는 입력 레코드로부터 키와 값을 추출하는 작업
  3. 키를 기준으로 키-값 쌓을 모두 정렬
  4. 정렬된 키-값 쌍 전체를 대상으로 Reduce 함수를 호출
     1. Reduce는 출력 레코드를 생산한다
• 그룹화: MapReduce로 그룹화하는 가장 간단한 방법은 Mapper가 Key-Value 값을 생성할 때 그룹화할 대상을 키로 하는 것
• HotSpot을 다루기 위해서 핫 키를 여러 리듀서에 퍼뜨려서 처리하도록 하는 방식을 사용한다. e.g. Pig에 있는 Skewed Join