이번 포스팅에서는 말로만 들어왔던 ElasticSearch에 대해서 학습한 내용에 대해서 정리하고, 실습한 내용을 정리해보려고 한다.

실습내용

이전에 실습으로 EC2 인스턴스 3개를 두고, Producer에서 Logstash를 통해서 Twitter의 로그를 가져다가 Kafka(이하 메시지 큐)에 쌓았다가 Consumer로 넘겨주는 흐름으로해서 실습한 적이 있었다.
이번 실습에서는 Amazon S3에 있는 데이터 정보를 LogStash(EC2)에서 뽑아서 Amazon OpenSearch Service(ElasticSearch)로 넘겨주고, 이를 Kibana라는 시각화 툴로 시각화까지 시켜주는 부분까지 실습을 해보려고 한다.

(Amazon S3 ->(Logstash(EC2))->Amazon OpenSearch Service -> Kibana)

Amazon Kinesis Firehose -> Amazon OpenSearch Service(ElasticSearch)로 Direct로 데이터를 넣어줄 수 있다.

Read More

이번 포스팅에서는 Presto와 Athena에 이어서 Tableau에 대해서 정리를 해보려고 한다.

최근 학습한 내용에 있어서, 데이터 전처리 및 시각화하는데 사용되는 서비스들이 많이 등장하였는데, 가장 최근에 배웠던 Presto와 Athena, 그리고 Tableau 이 세 개의 기술에 대해서 다시 한 번 전체적으로 개념을 잡고 Tableau를 실습한 내용을 정리하려고 한다.

Presto / Athena / Tableau

우선 Presto -> Athena -> Tableau 순으로 살펴보면,

Presto는 짧은 시간의 임시 데이터 분석에 최적화된 Open source로, 분산 SQL query engine으로, 이종 데이터간의 JOIN을 지원한다.

Athena는 Presto와 같이 SQL query를 실행시킬 수 있고, Serverless이다.
단, Presto와는 다르게 RDS 데이터와 JOIN(이종 데이터간의 JOIN)은 지원하지 않는다.하지만, 분석할때에는 Presto가 좋다고 하더라도 항상 구동시켜놓기에는 Presto는 부담이 있기 때문에 Serverless인 Athena를 Tableau와 연동해서 시각화를 하는 것도 좋다.

자 앞서 살펴보았던 Presto와 Athena는 둘 다 SQL Query engine으로, 데이터를 SQL Query로 분석할 수 있다는 공통점이 있었지만, 이종 데이터간의 JOIN을 할 수 있기도(Presto) 없기도한(Athena) 차이가 있었다.

Tableau

그럼 Tableau는 무엇인가? Tableau는 BI(Business intelligence) 툴로, 뭔가 어려워 보이는 툴이지만, 사람들이 데이터를 보고 이해할수 있도록 돕는다.는 경영철학을 가지고 만들어진 소프트웨어이다.
이 BI 소프트웨어는 3명의 스탠포드 대학 출신의 Christian, Chris, Pat이 설립한 Tableau 기업에서 만든 소프트웨어로, Pat과 Chris가 데이터 베이스에 저장되어있는 데이터의 이해를 돕고자 추친된 프로젝트에 참여하여 당시 가장 상용화된 BI 소프트웨어를 사용하였는데, 박사출신인 본인들이 사용하기에도 너무 어렵게 느껴져서 이 부분에 문제점을 자각하게 되면서 만든것이 바로 이 Tableau라는 BI 툴이다.

당시 후발주자로 BI 업계에 들어왔지만, 빠른 속도로 시장을 장악하였으며, 현재 BI 소프트웨어 업계에서 부동의 1위를 차지하고 있다.
BI(Business Intelligence) : 책, 저널, 문서, 이미지, 메일, 파일, 기타 비즈니스 소스를 포함한 내/외부 시스템에서 많은 양의 비정형 데이터를 수집하고 처리하는 어플리케이션 소프트웨어 형식이다. 주로 쿼리를 통해 정보를 찾기 위해 데이터를 수집하는 방법을 제공한다. 대시보드 및 데이터 시각화를 만들 수 있도록 분석할 데이터를 준비하는데 도움이 된다.

자 이렇게 Presto와 Athena는 데이터 분석툴이고, Tableau는 BI 툴이라는 정리가 되었다.
이제 본격적으로 Presto와 Tableau를 연동해서 Dashboard를 구성해보는 실습을 해보자.

Read More

이번 포스팅에서는 수집한 데이터를 전처리 및 저장한 뒤에 gold 데이터를 활용하여 분석 및 시각화하는 실습을 하는 부분에 대해서 정리를 해보려고 한다.
분석하기 편한 데이터 형태로 데이터를 변환한 다음에 해당 데이터를 시각화 작업을 통해서 분석작업을 한다.
Presto는 HDFS와 S3를 비롯한 여러 데이터 소스의 처리를 할 수 있는 분산 SQL query engine이다.
Presto는 Data Visualization Tool과 연동을 해서 작업을 할 수도 있다.

[핵심]

• Presto를 사용해서 S3에 저장되어있는 Hive Table Data를 BI툴에 제공할 수 있다.
• Presto와 Tableau를 연동하여 Dashboard를 구성할 수 있다.
• Near Realtime 분석툴 ElasticSearch를 활용할 수 있다.

분석 및 시각화 전체 흐름

EMR 내의 Spark을 통해서 정제된 데이터가 S3에 저장되고, 기본적으로 AWS에서 서비스를 운영하면 전반적인 데이터가 S3에 저장이 된다. 그리고 S3에 저장된 데이터에 대한 metadata 정보는 metastore인 AWS Glue에 저장이 된다. (순환구조)

분석가분들은 Glue에 저장된 meta정보를 기반으로 데이터 분석을 시작한다.
분석을 할때에는 EMR내의 Presto cluster(cluster이기 때문에 복수 개의 노드에 거쳐서 iterative하게 분석이 가능)나 Athena(serverless 분석툴)를 사용해서 진행한다. (Presto와 Athena 둘 다 SQL 분석 지원)
Tableau, Elastic search에서 가장 많이 사용하고 있는 Kibana를 통해서 시각화를 해 줄 수 있다.

Read More

이번 포스팅에서는 RDD 객체를 DataFrame Dataset으로 convert하고, Spark SQL로 데이터를 전처리한 실습내용에 대해서 정리해보려고 한다.

RDD => DataFrame

RDD를 DataFrame으로 변경함으로써 Spark SQL을 통해 데이터를 쉽게 가공할 수 있다.
아래는 샘플 코드로, RDD데이터를 spark.createDataFrame을 통해서 DataFrame으로 convert하고, convert된 DataFrame 객체를 활용해서 Spark SQL을 활용해서 groupBy, avg, count, join, orderBy, take, 등을 수행한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

from pyspark.sql import SparkSession
from pyspark.sql import Row
from pysql.sql import functions

# Convert RDD to DataFrame
df = spark.createDataFrame([RDD DATA])

# movieID 기준으로 grouping하고, rating에 대한 평균값 column을 표시한다.
averageRatings = df.groupBy("movieID").avg("rating")

# 각 movieID에 대해서 rating을 count한다.
counts = df.groupBy("movieID").count()

# movieID, avg(rating), count 세 개의 column을 join한다.
averagesAndCounts = counts.join(averageRatings, "movieID")

# top 10 results를 출력한다.
topTen = averagesAndCounts.orderBy("avg(rating)").take(10)

# Stop the session
spark.stop()

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

AWS Glue 데이터베이스 추가

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

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

Read More

이제 데이터 엔지니어와 관련된 학습을 한지 한 달 정도 된 것 같다.
한 달하고도 하루 전쯤인 3월 25일에 데이터 엔지니어로 입사를 하려면 어떤 것을 준비해야되는지, 조건에 대해서 조사를하고 리스트업을 해서 공부방향을 잡았었다. 물론 지금도 지식이 많이 부족하지만, 그때는 뭔가 배경지식도 없었고, 뭔가 추상적이고 범접하기 어려운 분야라고만 생각을 해서, 우선 필요한 배경지식을 최대한 쌓아보자는 생각으로 지금까지 달려왔던 것 같다.
그렇다고해서 단순히 수동적으로 학습을 했다는 이야기는 아니다. 능동적으로 관련 문제들도 인터넷에서 찾아서 풀어보고, 손코딩도 해보고 블로깅을 해보면서 공부했던 내용도 정리를 해보고, 정리했던 내용을 다시 보면서 복습도 했다.
그런데 지금 한 달이 된 이 시점에서 학습하는 방법에서의 변화가 필요하다는 것을 느꼈다.

이제는 어느정도 학습을 하면서 데이터 엔지니어 분야와 관련된 기초적인 지식을 조금 쌓았기 때문에 이제는 수동적인 학습의 비율을 줄이고, 좀 더 능동적으로 내가 여지까지 학습했던 내용에 대해 다시 꺼내보는 연습을 하면서 앞으로의 학습을 진행하는 것이 좋을 것 같다는 생각이 들었다. (능동적인 학습에는 포트폴리오 준비를 위한 준비도 포함이 되어있다)

가끔은 수동적으로 인터넷에서 제공되는 강의 콘텐츠만을 보고 반복하면서 학습을 하다가 나도 모르게 안다고 착각하는 부분이 생기게 되는 것 같다.
막상 배운 내용을 설명해보려고 하거나 몇 일 뒤에 세부 내용에 대해서 써보려고 하면 아는 것은 써도 안다고 생각했던 중요한 내용은 쓸 수 없는 경우가 많았다.
이러한 익숙함과 배움을 착각하지 않기 위해 이제부터는 수동적으로 학습하는 방법을 적게 배치하고 앞으로 두 달동안은 능동적인 학습방법의 비율을 높여서 학습을 진행하려고 한다. 그래야 나중에 면접에 가서도 좀 더 자신있게 내가 학습한 내용에 대해서 대답을 하고 정리해서 말할 수 있을 것 같다.

Read More

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

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

(2022/04/27 업데이트)

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

Read More

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

Read More

이번 포스팅은 Spark에 대해서 정리를 해보려고 한다. 데이터 파이프라인 실습에서 이미 Spark interpreter를 사용해서 데이터 전처리를 하고 있다. 그런데 아직 정확히 Spark에 대한 개념적 정의가 되지 않았기 때문에 이 부분에 대해서 정리를 하고 넘어가려고 한다.

Spark ?

Spark는 거대한 양의 데이터를 합리적인 방법으로 처리하고, 더 나아가 ML이나 Graph 분석 그리고 Data streaming 등의 멋진 기능을 포함하고 있는 친구이다.
이전에 데이터 파이프라인 구축 실습에서 데이터 batch 처리(ETL)나 실시간 스트리밍 데이터를 처리할때도 모두 이 Spark라는 친구를 사용한다고 했으니, 정말 대단한 친구임에는 틀림이 없다.
이처럼 Spark의 역량과 속도는 엄청나며, Java나 Scala, Python과 같은 실제 프로그래밍 언어를 사용해서 스크립트를 작성할 수 있는 유연성을 제공하고, 복잡한 데이터를 조작이나 변형, 분석할 수 있는 능력자이다.

Read More

이번 포스팅에서는 앞서 배운 Pig Latin script 작성방법을 기반으로 Ambari를 통해서 Hadoop 클러스터에서 Pig script를 실행해보고 결과값을 확인해볼 것이다.

Ambari에서의 Pig script 실행

Hadoop stack을 사용해서 Pig Latin script를 실행해보았다.
결과는 Ambari에서 결과, Logs에 대한 기록, 작성한 Script Details 정보를 각 카테고리별로 분류해서 확인할 수 있었다.

Read More