이번 포스팅에서는 AWS Glue의 Crawler에 대해 실습한 내용을 정리해보려고 한다.
데이터에 대한 트랜스폼 (CSV-JSON, JSON-PARQUET) 실습을 했는데, 쌓여있는 데이터를 크롤링을 통해서 glue에 있는 data catalog에 등록하는 작업을 실습해보고, 이렇게 Data Catelog에 쌓인 metadata를 분석하기 위해서 Atena를 사용해서 조회해보는 것 까지 실습해본다.

AWS Glue 데이터베이스 추가

테스트용 데이터베이스를 AWS Glue 하위의 데이터베이스에서 추가해준다.

데이터베이스 내의 테이블이 초기 생성에서는 비어있는 상태인데, 크롤러 추가 버튼과 함께, 크롤러를 통해 DB내의 테이블을 생성할 수 있음을 알 수 있다.

이번 포스팅에서는 AWS Glue라는 서비스에 대해서 배웠던 내용을 정리하려고 한다. 메타 데이터를 관리할 수 있는 서비스인데, 최근에 여러 회사에서 governance에 대한 관심과 여러 tool들이 많이 나오고 있고, data에 대한 정의(metadata)에 대해서 관심이 높아지고 있다.

이전에 데이터파이프라인에 대해서 가장 처음 전체적인 흐름에 대해서 배웠을때, 데이터 수집과 전처리의 중간 지점에 있는 관련 AWS 서비스에 Glue라는 서비스가 있다고 배웠는데, AWS Pipeline의 복잡해짐에 따라서 관리 및 운영이 어려워지고, 이러한 문제를 개선하기 위해서 등장한 친구라고 간단하게 배웠었다.
AWS Glue에는 파이프라인의 기본적인 서비스들이 추가가 되어있고, 가장 비용 효율적으로 잘 활용되고 있는 부분이 메타 스토어 정보가 포함되어있는 부분인데, meta store의 정보에는 데이터 위치, 포멧, 버전의 변경사항등에 대한 정보를 포함하고 있다고 한다.

(2022/04/27 업데이트)

Glue의 가장 큰 특징은 서버리스로, 설정하거나 관리할 별도의 인프라가 없다는 것이다. 그리고 메타 데이터만으로 ETL작업이 가능하기 때문에 원본 데이터의 변경 및 변경 데이터의 저장을 위한 별도의 저장소가 필요가 없다.
(왜 데이터 파이프라인이 복잡해졌을때 Glue라는 서비스가 유용한지 이해가 잘 안됐었는데, 원본 데이터의 사용없이 메타 데이터만으로 ETL작업이 가능하다는 점에서 Glue라는 서비스는 별도의 파이프라인을 통하지 않고 메타 데이터만으로 분석이 가능하도록 해주는 아주 유용한 친구라는 것을 다시 개념정리를 하면서 알게 되었다.)
스케쥴링 기능으로 주기적인 작업을 실행하고 자동화할 수 있으며, 북마크 기능으로 작업상태를 저장하여 중단된 시점부터 작업 재개하는 것이 가능하고 작업에 대한 모니터링 또한 지원을 한다.

이번 포스팅에서는 Amazon EMR(정확히는 EMR내의 Zeppelin의 Spark Interpreter를 통해서)에서 가공한 데이터를 내보낼 target에 대한 준비가 끝났기 때문에 이제 다시 Amazon EMR에서 어떻게 전처리한 데이터를 target 지정을 해서 내보내는지에 대해서 알아보도록 하겠다.
뭔가 데이터 파이프라인 구축은 정말 말 그대로 구성할 파이프를 각 각 만들어놓고, 특정 파이프의 output을 다음 공정의 파이프의 input으로 넣어주는 과정을 만드는 것 같다는 느낌에 재미있는 것 같다. 물론 각 파이프를 구성하고 전체적인 파이프라인 구성도를 생각해내는 것은 아직도 연습이 많이 많이 필요하지만, 그래도 이런 흥미를 붙였다는 것에 앞으로의 공부에 있어 좋은 원동력이 될 것 같다.
자 그럼 이제 본격적으로 Amazon RDS에 Spark로 가공한 데이터를 넣어주는 처리를 해보도록 하자.

이번 포스팅에서는 저번 시간에 이어서 Zeppelin을 사용해서 데이터를 처리실습을 한 내용을 정리해볼 것이다.
Zeppelin은 Interpreter로, 다양한 Interpreter를 제공해준다고 했는데, Spark도 그 중에 하나로 포함이 되어있다. 그래서 이전 시간에 실습했던 것처럼 s3 bucket에 있는 csv format의 파일을 spark.read에 여러 option을 붙여서 DataFrame 객체로써 저장을 할 수 있었다.

이 Apache Zeppelin에서 DataFrame을 조작해보면서 느낀점은 이전에 해봤던 Pandas의 DataFrame 조작과 매우 비슷한 부분이 많다는 것이다. Spark로 만든 DataFrame 변수로는 View Table을 정의할 수 있는데, 이 임시로 정의한 View Table을 활용해서 SQL query를 실행시킬 수도 있다.

그리고 DataFrame format의 데이터를 JSON format의 데이터로 S3 bucket에 저장을 할 수 있으며, S3에 저장된 JSON format의 데이터를 spark.read.json()으로 다시 DataFrame 형식으로 불러올 수 있다.

이정도의 내용을 저번 시간에 간단하게 실습을 해보았다.

이번 포스팅에서는 Zeppelin을 사용해서 데이터를 처리실습을 한 내용을 정리해볼 것이다.

Zeppelin 메뉴 구성

Zeppelin 페이지를 보면, Job 메뉴를 통해서는 실행되고 있는 좌표들을 모니터링할 수 있다. 그리고 Interpreters 메뉴를 통해서는 다른 Interpreter를 추가할 수도 있으며, Angular, File, Flink, Kotlin, R, Python, Spark 등에 대한 Interpreter를 default로 지원해주고 있음을 확인할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

val csvDF = spark.read
  // 첫 번째 row가 header인 경우,
  .option("header", "true")
  // delimiter가 comma로 구분된 경우,
  .option("delimiter", ",")
  // schema를 구성을 할 때 알지 못하는 데이터의 경우에는 문자열로 정의한다.
  // 전체 데이터를 읽고 숫자 데이터만 있는 경우에는 Integer로, 문자만 있는 경우, String만 정의한다.
  // 단, 파일이 큰 경우에는 전체를 다 읽어야 되기 때문에 이 부분을 고려해서 작업을 진행해야된다.
  .option("inferSchema","true")
  .csv("s3://[s3-name]/[...]/[filename].csv")

csvDF.show // 파일 확인하기

csvDF.printSchema // DataFrame Schema 출력/확인

오늘은 데이터파이프라인 1일차부터 11일차까지 학습했던 내용들은 종합적으로 복습하면서 앞으로 개인적으로 진행하게 될 세미 프로젝트는 어떤 방향으로 진행을 하게 될 것인지에 대해서 구상을 해보았다. (참고로 개인프로젝트를 채워넣을 개인 포트폴리오 웹 사이트를 아주 심플하게 만들었다. 뭔가 좋은 동기부여가 될 것 같아 하나 하나씩 채워가기 위해서 만들었는데, 확실히 좋은 동기부여가 되는 것 같긴하다)

아직은 총 11차 중에 2일분 밖에 복습을 진행하지 못했다. 하지만, 2일차까지 내용을 천천히 되새기면서 정리를 해보니 정말 주옥같은 내용들이 많았고, 내가 새로운 개념들을 배워가다가 잊고 있었던 부분들도 있었다. 앞으로 남은 복습분량들도 충분히 시간을 투자해서 진행할 계획이다.

이번 포스팅에서는 이전 시간에 이론적인 부분을 학습한 EMR을 직접 실행해보고 모니터링해보면서 학습한 부분에 대해 포스팅해보려고 한다.

EMR 서비스

처음 EMR 서비스 대시보드에는 아무것도 보이지 않지만, 기본적으로 보이는 클러스터 history 정보의 경우에는 default로 두 달 정도 보여주며, optional하게 노출 기간의 변경이 가능하다.

저렴하게 EMR 서비스 이용

• 고급 옵션으로 이동
  • EMR은 관리형 클러스터이기 때문에 여러가지 소프트웨어를 옵션으로 설치할 수 있다.
    (emr-6.x : Docker/Kubernetes를 같이 실행할 수 있는 환경을 지원)
• 소프트웨어 선택
  • Hadoop, Ganglia, Hive, Zeppelin, Spark, Pig 선택
  • cf. Zippelin : 웹 환경에서 Spark에 여러가지 command를 통해서 job을 던진다.
  • cf. Livy : 어플리케이션 간에 Spark에 job을 던질때 사용되는 것이 Livy이다.
  • AWS Glue catalog setting
    • Glue는 S3에 저장된 정보의 meta정보를 테이블 형태로 관리하는 것을 말한다.
• 클러스터 생성
• 하드웨어 구성
  • Networking
    • VPC : 하나의 건물로 이해 / subnet은 각 층으로 이해 (스팟을 제공하는 subnet이 따로 있는 경우가 있기 때문에 확인 필요)
  • Cluster Nodes and Instance
    • Instance type : spark 자체는 메모리 기반 데이터를 분석하는 툴이다. 따라서 메로리에 좀 더 최적화된 인스턴스 타입을 선택한다. (r-> ram -> memory 기반의 인스턴스, c -> computing, g -> gpu, i -> disk 최적화(데이터 분석시에도 고려되면 좋음))