[Hadoop_기초]Udemy course - 섹션 11-12. 마무리(현실시스템 설계하기)

94강. 다양한 시스템 소개

하둡과 직접적인 연관이 없더라도 관련된 기타 기술들에 대해 간략하게 소개하는 섹션이었다.

Impala

• cloudera 버전의 hive이다.
  
  • 따라서 cloudera를 사용하려 한다면 impala사용을 고려하는 것이 좋다.
  • impala도 오픈소스이긴 하나 cloudera에서 관리 중이다.
• hive와 동일하게 대규모 병렬처리 SQL엔진 이다.
• hive가 가지고 있는 실시간성 쿼리 성능 문제를 해결하기 위해 구글의 Dremel논문에서 영감을 받아 cloudera에서 개발함.
• hive와의 차이점
  • 쿼리를 실행하기 위해 항상 실행중이다.(hot start)
    • 반면에 hive는 쿼리를 하면 작동이 되고, 어떻게 실행할 지 알아낸 후에 계산한다.(cold start)
    • 이건 impala의 아키텍쳐 특성에 의한 것이다. 
    • 즉 하이브는 작업을 실행하려면 실질적으로 MR이 실행되고 이를 기반으로 하이브가 실행이 되는데 MR이 실행되는 시간이 오래 걸려서 느리다. 그러나 impala의 경우 내부적으로 coordinator와 자체 엔진이 있어서 바로 자체적으로 실행이 가능하다
    • presto의 구조와 유사
  • 빠른 응답을 위한 비즈니스 분석용, BI쿼리용, ad-hoc쿼리에 최적화 되어있다. 
    • 즉 인터랙티브 sql엔진으로 신속한 결과가 필요할 때 주로 impala를 사용한다.
  • MR기반으로 처리되는 hive와 달리 자체 분산 쿼리엔진을 사용한다.
    
    • impala가 고유의 분산 질의 엔진을 사용함으로써 응답시간을 최소한으로 줄이게 되는 것이다.
  • hbase나 MR같은 별도 계층을 거치지 않고 HDFS와 직접 통신한다.
• Hadoop HDFS, HBase, Amazone S3, Azure ADLS, Azure ABFS 등 다양한 저장소를 사용할 수 있으며 Hive, Hue 등과 연계하여 사용 가능하다.
  • 전용 메타스토어를 사용할 필요가 없으며, 기존 Hive 메타스토어를 사용할 수 있다.

Impala 아키텍쳐

Impalad

하둡의 데이터 노드에 설치되어 임팔라의 실행 쿼리에 대한 계획, 스케줄링, 엔진을 관리하는 코어.

분산 질의 역할을 담당하는 프로세스

 

Query Planner : Impala쿼리에 대한 실행계획을 수립

Query Coordinator : impala의 job리스트 및 스케줄링 관리

Query Exec Engine : impala의 쿼리를 최적화해서 실행하고 쿼리 결과를 제공

 

Statestored

분산 환경에 설치돼있는 impalad의 설정 정보 및 서비스를 관리. 즉 메타데이터를 유지하는 역할

 

Catalogd

Impala에서 실행된 작업들을 관리하여 필요 시 작업 이력을 제공

 

Accumulo

Hbase 같은 빅테이블기반의 분산형 키-밸류 저장소이다. -> 즉 NoSQL 데이터베이스이다. 

 

"Cell 기반으로 접근 통제"를 제공함으로써, key-value쌍 별로 자체적인 보안 라벨을 지니고 있고 이에 따른 접근을 관리할 수 있음으로 인해서 Hbase보다 더 나은 보안을 제공한다. 

 

또한 Hbase와는 달리 sever-side programming 기능을 제공한다. 

🤔 즉 서버 측에 작은 코드 한 토막이 있어 들어오는 데이터를 변환할 수 있다.

 

Redis

Memcached와 같이 캐시 서버이다. 정확히는 그 다음 세대인 기술이다.

애플리케이션에서 자주 접근하는 정보를 메모리 안에 저장하며, 메모리를 기반으로 하기때문에 속도도 빠르다.

 

Memcahced와 달리 해시 맵 등의 전체 데이터 구조를 저장한다.(memcached는 key-value데이터 저장)

이렇게 저장한 데이터를 디스크에 유지할 수도 있다. 이에 따라 지속적인 데이터 저장소로 사용할 수도 있게 된다.

 

Ignite

redis의 대안이다.

아파치 프로젝트이며, "in-memory data fabric"이다. <- 이 표현이 이해가 안감

즉 실제로는 데이터베이스에 더 가까운 기술이다. 

 

메모리 내 데이터 접근을 제공할 뿐 아니라.  ACID트랜잭션이나 SQL지원 등의 기능이 있다. 

🤔 금융 트랜잭션을 하는 어플리케이션에 적합하다. 왜?

- 빠른 트랜잭션과 atomic을 요구하는 금융 서비스용 트랜잭션에 활용하기 좋다는 것.

모든 작업이 메모리 내에서 진행되어서 굉장히 빠르다. 

-> 메모리 기반이면 데이터 유실은?

-> 기본적으로 데이터 베이스 기술이고, 디스크 저장도 가능하다. 

 

Elasticsearch

하둡생태계와 직접적인 연관은 없지만 하둡 생태계로부터 데이터를 가져오거나 내보내야 할 수도 있다.

기본적으로 "분산 문서 검색 및 분석엔진"이다.

실시간 쿼리를 다룰 수 있음으로 인해서, 검색어를 입력하는 순간 결과를 볼 수 있다.

Kibana와 함께 사용되어 대시보드를 제공해 줄수도 있다.

 

AWS Kinesis

어떻게 보면 AWS 버전의 Kafka인데, 정확하게 따지면 다르다.

Kafka는 데이터를 실시간으로 수집하여 처리하지만, 저장또한 가능하나 Kinesis는 좀 더 실시간 수집에 초점을 맞추었다.

AWS에서 정확하게 Kafka의 기능을 제공하는 서비스는 MSK라고 볼 수 있다.

 

이 외에도 AWS에는 하둡 생태계와 대응되는 다양한 기능을 제공하는 서비스가 존재한다.

 

DynamoDB는 카산드라와 대응

 

Apache NiFi

-> 해당 기술은 사실 정확히 잘 모르겠고, 공부해야할 때가 오면 추가로 정리할 예정 

 

데이터 라우팅의 방향성 그래프를 구성하는 방법이다.

즉 데이터가 처리되고 적재되는 ETL작업의 흐름을 관리하는 기술이다. 

 

특히 실시간 데이터를 처리하는 것에 매우 적합하여, 스트리밍 어플리케이션의 데이터 소스로 사용할 수 있다.

Spark Streaming이나 storm등의 스트리밍 프레임워크에서 NiFi를 입력소스로 자주 사용한다.

 

클러스터로 들어오는 데이터의 흐름을 체계화하는 수단으로 사용할 수 있다.

 

Falcon

Oozie위에서 작동하는 데이터 거버넌스 엔진이다.  Oozie에 너무 많은 워크플로가 있어서 일종의 관리자가 필요할 때 사용된다.

 

Hotonworks에 포함되어 있는 Ambari 옆에 있는 서비스 목록이다.

NiFi처럼 데이터 구조화 프로세싱을 통제하지만, 클러스터에 들어온 다음에 데이터의 흐름을 관리한다는 차이점이 있다.

 

Apache Slider

 hortonworks에 이미 설치된 서비스이다.

YARN클러스터에 분산하려는 범용 어플리케이션을 위한 도구이다. 

 

직접 작성한 어플리케이션을  Slider를 사용해서 클러스터에 배치하고 모니터하며 시간에 따라 관리 할수 있게 된다.

 

즉 yarn of yarn이다.

네이버 C3DL에 쓰인다고 한다(대박..)

C3DL을 개발할 당시의 YARN(버전 2.7.1)은 기본적으로 CPU와 메모리를 사용해서 스케줄링하기 때문에 GPU는 고려하지 않고 있었다. 따라서 YARN에서 GPU 스케줄링이 가능하도록 자체 기능을 개발했다. 

간단히 동작하는 YARN 애플리케이션을 작성할 수 있게 됐다 하더라도 에러 처리 또한 까다롭다. 분산 환경이기 때문에 언제든지 장비 장애가 발생할 수 있고, 어떤 역할을 하는 장비에 문제가 생겼는지에 따라 예외 처리가 달라진다.
C3DL 개발에는 YARN 애플리케이션을 직접 작성하지 않고  Apache Slider를 사용했다. Slider는 분산 애플리케이션(distributed application)을 쉽게 배포하고 관리할 수 있게 해주는 YARN 애플리케이션이다. Slider를 사용한다면 애플리케이션 동작 로직 구현에만 집중할 수 있다. 대부분의 예외 처리는 Slider에서 담당하므로 분산 환경에서의 애플리케이션 실행은 고려하지 않아도 되기 때문이다. 하지만 Slider를 그대로 C3DL에 사용하기에는 적합하지 않는 면이 있었다. Slider는 long-lived application에 적합하도록 설계되었지만, C3DL에서 주로 이뤄지는 작업은 배치 작업이기 때문이다. 이를 위해 Slider의 소스 코드를 수정했다. 

 

95강. 검토: 다양한 도구 결합하기

지금까지 다뤘던 기술들을 복습하며 어떻게 통합할 수 있는지에 대한 내용을 다룬 강의였다.

 

하둡 생태계에서 시작해보면, 하둡 자체를 구성하는 것은 위의 그림에서 분홍색으로 칠해진 기술들이다. 나머지는 보조적인 기술이다.

 

HDFS는 분산 파일 시스템으로써 클러스터에 걸쳐 데이터를 분산저장한다.

YARN은 리소스 관리자이다. / 이와 같은 역할을 하지만 하둡생태계 외부에서 동작하는 Mesos도 있다,

MR은 분산 저장된 데이터를 처리하는 기술로서 Mapper로 데이터를 변환하고 Reducer로 데이터를 집계한다.

Hive는 HDFS에 저장된 데이터에  SQL 작업이 가능하도록 해주는 엔진이다.

Pig는 Hive와 같은 수준에 머무르며 고유 언어 Pig Latin을 사용해 고수준 스크립팅 인터페이스를 제공한다.

TEZ는 MR의 대안으로 DAG기반으로 더 빠른 속도를 제공한다.

Spark는 메모리 기반의 데이터 처리 엔진이다.

Hbase는 HDFS위에 구축된 NoSQL데이터베이스를 제공한다.

-> 외에도 하둡 생태계 외부에 있는 MySQL, Cassandra, MongoDB 등의 데이터 스토리지가 존재한다.

데이터 수집에 있어서 RDS에서 배치작업으로는 Sqoop / 실시간 스트리밍으로는 kafka와 Flume이 있다.

클러스터를 관리하는 Zookeeper와 데이터 처리 작업의 스케줄을 관리하는 Oozie가 있다.

 

+) Apache Strom / Flink / Ambari 등이 존재

 

96강. 요구사항 이해하기

즉 지금까지 공부하고 이전 강의(95강)에서 복습한 여러 기술들을 실제로 결합하여 사용하는 실제 사례들에 대해 정리해보는 강의이다.

실질적으로 정답처럼 확실한 하나의 아키텍쳐가 있는 것은 아니고 여러 예시들을 바탕으로 실제 상황에 맞게 변형해서 적용할 수 있다.

 

문제를 해결하기 위해 여러 기술들을 결합하여 활용하는 방법을 고안해내기 위해서는 "최종 사용자의 관점"에서 문제에 접근해야 한다.

본능적으로 시스템의 요구사항에 대해 사전에 형성된 개념을 충족할 기술을 먼저 고르려고 하지만, 최종 결과에 무엇이 필요한 지부터 시작해 거꾸로 작업하는 것을 권장한다.

 

• 최종 사용자가 어떤 접근 패턴을 보일 것인가를 예상하기
  • 가령 즉각적으로 계산할 필요가 없지만 굉장히 큰 범위의 분석쿼리인지,
  • 아니면 많은 사람들이 접속하는 대형 웹사이트에서 대량의 작은 쿼리들이 신속하게 계산되어야 하는지 
  • 가용성이 중요한가? 주식거래 시스템처럼 일관성도 필요한가?
  • 얼마나 큰 데이터를 가지고 있는가? -> 분산 컴퓨팅이 필요할수도
• "간단함"이 또 다른 처리 원칙이다.
  • 요구를 충족하는 가장 간단한 솔루션 선택하기
• 리소스 고려 -> 인적, 인프라적 리소스
  • 필요한 최소한의 인프라 고민
• 데이터 유지 정책 고려
  • 영구적으로 보관? 일정기간 어떻게 보관?
• 보안 요구 사항 고려
• 서비스 응답 속도 고려
  • 즉 데이터 요청 작업에 대한 응답이 얼마나 빨라야 하는가?
• 데이터가 얼마나 빨리 처리되어야 하는가? -> 실시간? 배치?
• 어느정도 기간동안의 사용을 고려 -> 그러나 너무 복잡하게는 하지 않기
  • 한번 구축한 것은 변경하기 어려우므로
• 장기적으로 데이터를 어디에 저장할 것인가?

 

97강. 샘플 어플리케이션: 웹 서버 로그를 사용하고 베스트 셀러 추적하기

95~96강에서 이야기한 바를 토대로 샘플 서비스를 구축해보기.

전자 상거래 웹사이트에서 인기 상품을 추적하는 시스템을 설계한다고 할 때, 대량의 분산 문제를 이해하고 접근하는 방식으로 고민해보기

 

우선 고객의 요구사항부터 고민하고 작업하며 무엇을 제공해야 하는 지를 생각하기.

 

• 최종 사용자가 많을 것이고 이에 따라 쿼리작업도 매초마다 대량으로 발생할 것이다
• 따라서 빨라야하고 페이지 지연도 최소화해야한다.
• 따라서 분산 NoSQL데이터베이스를 고려할 수 있다.
  • 이건 아마도 특정 카테고리/주제를 기준으로 Join과 같이 복잡한 연산을 최소화하고 한 번에 바로 데이터를 조회하기 위해서?
• 데이터에 대한 접근 패턴은 간단하다 : 카테고리에서 현재 가장 인기있는 N개의 상품
• 바로바로 업데이트되는 것은 중요하지 않지만 너무 느려도 좋지 않으니 1시간 업데이트
  • 이 말인 즉슨 데이터 일관성은 크게 중요하지 않음.
• 그러나 서비스 자체의 다운에 대비한 고가용성이 중요함.
  • 조회될 데이터자체는 크지 않지만 작업이 자주 발생하여 트래픽이 많기 때문에 이 과정을 분산해야 하며
  • 이에 따라 가용성/파티션 저항성(분산)을 우선시하는 cassandra를 고려해볼 수 있다.

🤔 이제는 cassandra와 소통하여 데이터를 제공하는 기술을 고민해야 하고 Spark를 고려할 수 있다.
==> 다른 데이터베이스를 선택했다면 storm/flink  고려가능

• spark streaming으로 데이터를 실시간 처리한다면 스트리밍 수집 기술로 kafka or flume을 고려할 수 있다
  • HDFS위에 구축한다면 Flume을 좀 더 고려해볼 수 있다.
  • 그러나 spark , cassandra는 하둡 생태계 외에서도 동작하므로 flume을 꼭 고려하지 않아도 된다. 
• 개인 식별 정보때문에 보안 또한 꼼꼼하게 고려하기
  • 데이터의 개인정보를 어떻게 보호?
  • 개인 식별 정보자체를 제거할 수도 있다.

 

예시를 하나 들자면 아래의 구조로 웹사이트 내의 구매 데이터를 처리해서 각 카테고리의 인기상품을 파악할 수 있다.

 

만약 해당 데이터를 활용한 분석 작업이 필요하다면, 이 데이터를  cassandra 뿐 아니라 HDFS에도 저장해서 hive같은 도구를 사용할 수도 있다. 혹은 cassandra위에 분석쿼리를 실행할 수도 있다.(Drill이나 presto)

 

98강. 샘플 어플리케이션: 웹사이트에 추천영화 제공하기

이번 강의에서는 또 하나의 샘플로, 추천영화를 제공하는 서비스를 설계했다.

이 또한 기본적으로 최종 사용자의 관점에서 먼저 생각해야 한다.

 

• 온라인 시스템을 다루기 때문에 굉장히 큰 웹 사이트는 가용성과 파티션 저항성이 중요하다. 수많은 사람들이 시스템에 접근하기 때문에 데이터 전송을 분산해야 한다. 따라서 일관성이 중요하지 않다면 Cassandra를 선택할 수 있다.
  • 그러나 점차 여러 요소들을 고려하다보면 다른 데이터베이스를 선택하게 될 수도 있다.
• cassandra에서 어떻게 추천영화를 가지고 올 수 있을까?
  • 여기서는 머신러닝이 필요하게 된다.
  • Spark의 MLLib을 사용하여 ALS라는 내장된 기능을 사용해서 개별 추천영화를 제공할 수도 있고, Flink의 머신러닝 라이브러리를 사용할 수도 있다.
• 사용자에게 데이터의 최신 버전을 제공하는 타임라인에 대해서도 고민해야 한다.
  • 즉 영화 추천에 새 평점이 반영하는데 얼마나 걸려야 할까?
  • 고객의 관점에서 생각한다면, 고객은 자신의 평가가 바로 반영된 영화 추천을 보고 싶을 것이다. 
  • 이를 위해 추천영화를 계산하는 방식은 아래와 같다.

• 모든 유저에 대한 추천 영화를 미리 연산하는 것은 리소스 낭비가 심하고 적절한 시기에 정보를 제공해 줄 수 없다.
• 또는 미리 유사한 영화들끼리 함께 저장해 두고, 추천영화를 계산해야할 때 미리 저장한 것을 바탕으로 유사한 영화를 추천해 줄 수 있다. : item-based collaborative filtering
• 또한 유저의 지난 행동을 바탕으로 A를 좋아하는 사람은 B와 C를 좋아할 거라는 것을 예측할 수 있다.
• 고객의 최신 행동 데이터를 가져와서 별도의 데이터베이스에 있는 비슷한 영화를 참조할 수 있다. 이를 바탕으로 해당 고객이 과거에 좋아했던 영화와 비슷한 영화의 목록을 가져와 이미 시청한 영화를 제거하면 추천 목록이 된다.
  • 즉 서로 비슷한 영화의 정보를 가끔 업데이트하는 용도의 시스템이 필요하다.
  • 그리고 이 시스템은 평점 데이터와 행동 데이터에 빠르게 접근할 수 있어야 한다.
  • 서비스의 중간 레이어를 구성해서 별도의 시스템에 있는 모든 정보를 종합하여 새 추천을 만들어야 한다.

 

즉 예시를 하나 들자면 영화 추천 서비스에 대해서 아래와 같은 설계가 가능하다.

• 우선 어플리케이션을 사용하는 유저들의 행동데이터를 저장한다
  • 유저들이 개별 영화를 평가할 때마다 flume을 사용해서 데이터를 가져온다
  • 그리고 이러한 스트리밍 데이터를 분석처리한다 : spark streaming
• 이렇게 처리된 행동 데이터를 HBase에 저장한다.
  • 앞에서는 cassandra를 이야기했는데 데이터 양이 그렇게 많지 않다면 HBase만으로도 충분하다
  • 또한 하둡클러스터를 사용하고 있고 하둡 생태계 내의 기술들을 여러개 사용할 예정이라면 HBase가 좀 더 활용도가 높다
• 저장된 평점 데이터를 기반으로 spark와 Oozie를 통해 배치작업을 실행한다
  • 사용자의 평점 행동 데이터를 기반으로 이와 유사한 영화를 찾아내는 것이다.
  • 이를 통해 HBase의 별도 테이블에 일정 배치간격으로 영화 유사성을 저장한다. 
• 이렇게 저장된 행동 데이터와 영화 유사성 데이터를 기반으로 영화 추천서비스에 데이터를 제공할 수 있다. 
  • 위의 구조에서 Recs service이다.

❗️ 기술의 수가 적을 수록 시스템을 유지하고 구축하는 사람이 직관적으로 이해할 수 있다.

 

99~100강. [연습&해설] 하루에 한 번 웹 세션을 보고하는 시스템 설계하기

요구사항

• 대규모 웹사이트 구축
• 몇몇 관리자는 일별 총 세션에 대한 그래프를 원할 수도 있다.
• 이미 존재하는 솔루션은 고려하지 않는다.
  • 데이터를 외부에 노출하는 것이 꺼려질 경우/ 확장성이나 비용을 고려할 경우 한계가 있다.
• 하루에 한 번 전날의 웹 사이트 활동을 기반으로 보고서를 만든다.
• 세션은 주어진 IP리스트로부터의 트래픽으로 정의한다.
  • 슬라이드 윈도는 한시간이다. 
• 기존에 사용하던 웹 로그에는 세션 데이터가 없다고 가정
• 해당 데이터는 분석용으로만 즉 내부적으로만 활용된다.
  • 즉 고객은 내부 관리자이다. 
  • 이말은 대규모 트래픽/트랜잭션 지연/가용성에 대한 중요성이 떨어진다.

해설(예시)

• 고객의 요구사항을 가장 먼저 요구하기
  • 대량의 트랜잭션/ 낮은 대기시간/고가용성은 고려하지 않아도 된다.
  • 따라서 선택의 폭이 넓다 -> 간단함에 집중
• kafka로 스트리밍 데이터 수집하여 spark streaming의 슬라이딩 윈도우로 스트리밍 데이터 분석
  • kafka 자체에 저장되는 데이터가 다른 분석에 활용될 수도 있으므로 flume보다는 kafka
• HDFS에 저장하고 Hive 쿼리 엔진을 기반으로 필요한 데이터를 집계한다.
  • MySQL이 아니라 Hive를 사용한 이유는 데이터의 확장성을 고려한 것.
• 이에 대한 스케줄링는 Oozie로 한다.

 

Reference

• sql on hadoop 분석 도구인 hive VS impala
• impala에 대해
• apache ignite개념 정리