데이터 엔지지니어링에서 가장 중요한 파트를 뽑으라면 아마 ETL 단계가 아닐까 싶습니다. 모든 분석의 결과값에 사용되는 데이터들이 ETL 및 ELT 과정을 통해 DW 내에 적재되기 때문입니다. 

최근 ETL에서 ELT로 거의 바뀌는 추세라고는 하지만 여전히 ETL을 사용하는 곳들이 많고 제가 다니고 있는 조직에서도 ETL 패턴을 유지하고 있기 때문에 효율성과 비용, 확장성을 고려해서 각자 회사 상황에 맞는 방식을 선택하는 것이 현명한 선택이라는 생각이 듭니다. 

이번에 ETL 개편 자료 조사를 하면서 무작정 새로운 것들을 도입하는 것보단 뿌리부터 데이터 히스토리를 파악해서 가장 효율적인 방법을 찾아나가는 게 중요하다고 생각되어 제가 조사했던 ETL과 ELT의 차이점 및 어떤 상황에 해당 패턴을 사용하는 게 맞는 것인지를 작성해 보려고 합니다. 물론 모든 과정에 정답은 없습니다. 각자 상황에 맞게 프로세스를 꾸려나가는 것이 데이터 엔지니어의 숙명인 듯합니다.... ㅜㅜ  

1) ETL

Extract, Transform, Load의 약자로 

데이터를 원천에서 가져오는 추출(Extract), 추출한 데이터를 원하는 형태로 가공하는 변환(Transform), 변환 후 타겟 목적지까지 저장하는 적재(Load)의 흐름으로 진행됩니다. 

불필요한 데이터를 추출하지 않고 원하는 데이터만 선택적으로 추출해서 저장소를 효율적으로 다룰 수 있다는 장점이 있습니다.  워낙에 보편화된 기술이고 관련한 기술자들이 많기 때문에 이런 형식을 다룰 수 있는 엔지니어분들이 많다는 것도 하나의 장점이 될 수 있겠습니다.

하지만 이 과정을 통해서 뭘 얻고자 하느냐? 결국 우리가 원하는 건 정제되고 시각화된 리포트들입니다.

예를 들어 매일 아침마다 매장별일매출을 확인한다던지, 판매량을 본다던지 일 배치로 매일매일 확인해야 하는 데이터들을 새벽마다 대용량의 데이터를 변환시켜 처리하려면 운영상의 난이도가 올라가고 관리가 빡세다는 단점이 있습니다.

또한 이미 해당 리포트에 맞게 테이블을 만들어 적재를 해 놓았으니 리포트를 사용하는 팀에서 다른 형식으로 데이터를 뽑아달라는 요청이 왔을 때 그 형태에 맞게 또 다른 테이블을 생성해서 적재를 진행해야 한다는 게 가장 크리티컬한 단점이 아닐까 싶습니다. 

저희 부서 같은 경우는 아직 ETL 형식을 사용하고 있어 마스터 테이블이라는 개념을 빌려 모든 경우의 수를 다 조합할 수 있는 원천 데이터들을 조인해서 모든 데이터가 담긴 ODS 테이블을 만들어 두었습니다. 뭐 이런 식으로도 방법을 만들 수는 있겠지만 컬럼이 200 개정도가 넘어가는 불상사가... ^^; 그 테이블을 바라보고 결국 다른 팩트 테이블을 설계해야 하는데 유지보수 측면으로도 영 이게 맞는 건지 썩 마음에 들진 않습니다. 하지만 더 효율적이고 괜찮은 방법이 생각나지 않아요 ㅠㅠㅠ 클라우드 dw를 도입할 수 있는 환경도 아니라.. 도입한다고 해도 비용 관리를 혼자 다 해야 한다는 부담감이.. 어흑 

ETL에 사용되는 툴은 다음과 같습니다.

• 인포매티카 PowerCenter 
• Pentaho ETL
• FiveTran, Stitch Data
• Airflow 
• 다른 클라우드 서비스 (AWS Glue, etc ...)

파이브트란이나 스티치 같은 경우에는 CDC도 지원을 해 주고 SaaS형 솔루션이기 때문에 꽤나 비용이 비싼 것으로 보였습니다. ETL한 행수 별로 월 비용처리를 한다거나 그랬던 것 같고 인포매티카는 사용해보진 않았지만 한국 지사 철수로 아마 지금 당장 도입은 안 되는 걸로 알고 있습니다 ㅎ 펜타호도 마찬가지로 네이버 클라우드 기준 제일 싼 게 월 250 이더라구요. 물론 무료 버전인 CE 버전도 있습니다만 간단한 처리를 하기엔 좋지만 오류가 났을 때의 단점이 좀 있어서 상황에 맞는 스케줄러나 프레임워크를 도입하는 것이 좋겠습니다. 

2) ELT 

Extract, Load, Transform 의 약자로 

ETL과 다르게 변환의 순서가 다릅니다.  데이터를 추출한 다음 바로 적재를 하고, 후에 변환을 하는 시스템입니다. 거의 클라우드 DW가 등장을 하면서부터 ELT의 방식이 점점 늘어나는 추세가 된 것 같습니다.

AWS로 예를 들자면 원천 데이터를 S3에 적재한 후 glue로 S3를 읽어 들여 RDB의 테이블 형태로 만들어 (glue 데이터 카탈로그의 기능) Athena 혹은 RedShift에 Load 해서 아테나와 레드시프트 안에서 Transform을 하는 방식의 시스템인 것입니다. 

이러한 방식의 장점은 데이터 변환이 DW 안에서 이루어지기 때문에 변환되어서 적재가 되는 과정에 오류가 생겨서 적재가 되지 않거나 네트워크가 끊겨서 멈췄다거나 하는 그런 걱정이 하나도 없을 수가 있고, 원본 데이터를 모두 가지고 있기 때문에 필요할 때마다 빠르게 바로 가져다 원하는 형태의 분석 데이터를 만들 수 있습니다. 

클라우드 DW들을 사용해 본 적이 없어서 잘 모르겠는데, 로드된 데이터 자체가 일단 원천 데이터인데 혹시 그 원천 데이터에서 데이터 오류가 발생하였다면? 그때의 오류를 어떻게 해결하고 데이터 품질 관리는 어떻게 진행해야 할지는 잘 감이 안 잡히긴 하네요...... 원천에서부터 오류가 난다면 그건 데이터 엔지니어링에서 해결할 수 없는 부분이긴 하지만 그 부분은 제외하고 분석에 활용을 하는 건지...... 는 갑자기 궁금해진 부분이네요. 

• 그렇다면 언제 ELT를 사용해야 하는지? 
  • 대용량, 다양한 데이터를 보유했을 때 -> ELT는 정형 데이터와 비정형 데이터를 모두 아우를 수 있습니다. 
  • 빠르게 처리해야 할 때 -> 스트리밍 데이터를 필요로 할 때 ELT로 처리하는 것이 효율적일 수 있습니다. 
  • 어떻게 분석해야 할지는 모르겠는데 일단 데이터 저장은 필요해! -> 저장 스토리지 비용이 쿼리 한번 돌리는 것보다 싸기 때문에 오히려 먼저 적재해놓고 나중에 분석하는 게 더 효율적이라고 판단할 수도 있겠네요.. 

ELT에서 살펴봐야 할 프레임워크 및 클라우드 DW, 옵션들은 다음과 같습니다.

• AWS RedShift
• AWS Athena
• Snowflake
• GCP BigQuery
• Apache Hive
• Apache Presto
• Apache Iceberg
• Apache Spark 

레드시프트는 다들 비용이 부담이 돼서 거의 아테나로 넘어가는 걸 권장한다고 어디서 들은 것 같은데...... 둘 다 사용을 해보질 않았으니 저는 첨언할 게 없네요 ㅠ 개인적으로 데이터 엔지니어링 쪽은 GCP가 정말 효율적으로 잘 사용할 수 있을 것 같은데 저희 회사는 또 AWS 서버 기반이라 빅쿼리 도입한다고 하면 설득도 전에 이미 문전박대가 되지 않을까 싶네요.. 

클라우드 DW가 우리 조직에게 필요한가를 생각해 봤을 때 저는 이 정도의 질문을 스스로에게 남겼습니다 

• 현재 조직의 리소스가 어떻게 되는가? 
  • RDS Oracle 계약으로 사용 중 -> DW도 오라클에 단독 dw 서버 만들어 적재 중 
  • ETL에 드는 비용은 없음. 펜타호 무료 버전 사용 중. 하지만 DB의 과부하, 트래픽 비용, 원인을 찾을 수 없는 디비락 ㅜ, 시간소요, 네트워크 전송 실패 문제로 어떻게든 툴을 바꾸거나 데이터 파이프라인 개선이 필요한 상황 
  • 이미 나가고 있을 돈은 다 나가고 있다. 도입을 하면 추가 비용만 발생할 텐데 여기서 비용으로 승부를 볼 수 있을까? 
  • BI 툴도 라이센스 계약으로 사용 중이라 ETL과 DW단만 지지고 볶으면 된다. 

=> 원천데이터를 ODS에 적재하는 부분을 감소시키자. 현재 RDS의 용량을 원천데이터에서 ODS로 그대로 복사해서 사용하고 있기 때문에 이 과정을 S3에 저장시키고 (비용 감소) Athena로 분석 테이블들을 생성시키면 일도 간편해지고 관리에도 용이할 것으로 보임

정도로 결론을 내렸지만 어떻게 진정성 있게 설득을 할지가 지금 현재 저의 고민인 것 같습니다. 그래도 글을 쓰면서도 조금 정리가 되긴 되어서 스스로에게도 도움이 되긴 했네요. 

관련 자료를 찾아 보다 사례를 통한 아키텍처가 있어 참고해 보면 좋을 것 같아 첨부합니다.  

https://azureplatform.tistory.com/18

ERP 시스템의 고객사별 매출 데이터를 BI 보고서로 만들고자 할 때 

ETL 사용 시)

1. 시각화 보고서를 개발하기 위한 데이터 모델 설계 

2. 고객 및 매출 관련 데이터를 가져와 설계한 모델에 맞춰 가공한 뒤 로드 

3. 로드한 데이터로 실제 모델링 진행 후 시각화 보고서 개발 

** 고려사항

1) 보고서 내용이 바뀌거나 추가되면 데이터를 그에 맞춰 다시 가공하고 다시 로드해야 함. 가공 단계부터 다시 시작해야 됨

2) 실제 보고서를 만들 때, 가공해서 로드한 모든 데이터를 사용하지 않게 될 수도 있음. 낭비된 비용 발생

3) 가공 전 데이터에 접근하여 다른 가공을 해봐야 하는 상황이 생길 수 있음. 이 경우, 가공 전 데이터를 원본에서부터 다시 끌고 와야 함. ==> 여기서 그 원본 데이터가 어디에 있는지부터 또 찾아야 함. 그리고 ETL 작업을 다시 하고 원천 데이터 가져오는 ETL, 가져와서 가공하는 ETL을 또 만들어야 됨

ELT 사용 시) 

1. 시각화 보고서를 개발하기 위한 데이터 모델 설계

2. 고객 및 매출 관련 데이터를 가져와 우선 전부 로드 

3. 1에서 설계한 모델에 맞춰 로드된 데이터 중 필요한 데이터만 가져와 가공 

4. 가공한 데이터로 실제 모델링 및 시각화 보고서 개발 진행 

** 고려사항

1) 보고서 내용이 바뀌거나 추가되면 로드된 데이터 내에서부터 가공하면 됨. 로드 이전에 가공하는 게 아니라 로드 후 가공이라 비용과 시간이 줄어듦.

2) 실제 보고서를 만들 때, 로드되어 있는 데이터 중 필요한 데이터만 가져와 모델링 및 시각화를 진행함. 낭비되는 비용이 발생하지 않음.

3) 가공 전 데이터에 접근하여 다른 가공을 해봐야 하는 상황이 생길 수 있음. 이 경우 이미 로드되어 있는 데이터만 확인하면 됨.

그렇다면 내가 지금 ODS에 원천에서 들고 올 수 있는 데이터 다 들고 와서 200개 컬럼이 들어있는 테이블은 과연 불필요한 낭비 비용인 ETL인 것인가 우선 고객 매출 관련 데이터를 전부 로드한 ELT인 것인가...... 갑자기 또 의문점이 들었네요. RDS가 비싸니까 낭비라고 보면 되는 걸까요? 스토리지 비용으로? 그렇다면 그 스토리지를 없애고 S3로 간다면 비용이 절약되는 건지? 또 고민이 시작되었습니다... 클라우드 DW만 아니다 뿐이지 일단 모두 다 로드해서 적재해놓긴 했는데 실시간 쿼리 분석이 안 된다는 점에서 패착이 있긴 하지만 또 실시간 분석 리포트를 진행하고 있는 건 아니라... ELT로 가게 된다면 실시간 리포트로 확인할 수 있다는 점에서 확장성이 있기는 하네요. 

어찌됐든 상황에 따른 최대한의 좋은 방안은 설계한 사람이 생각하기 나름인 것 같습니다. 

확실히 현업 관련 사례를 보면서 차이점을 보니 어떤 상황에서 비용을 더 아낄 수 있고 운영하기에도 용이한지 한눈에 파악이 되는 것 같습니다. 같은 고민을 하시는 분들이 있다면 조금이나마 도움이 되셨으면 좋겠습니다. 

레퍼런스

https://azureplatform.tistory.com/18

https://dining-developer.tistory.com/50

대용량 데이터를 전송할 때 사용하는 여러가지 방법이 있는데 그 중 하나가  Message Queue를 이용한 방법이 있습니다. 

요즘 카프카가 대세다, 대용량 데이터를 처리하는 방법 등등 이런 헤드라인으로 시선을 사로잡는 광고들이 많이 보였습니다. (이미 현업에서도 많이 사용 중이지만...) 저도 데이터를 만지는 사람으로써 이런 기술들에 대한 니즈가 있긴 하지만 당장에 내 상황에 필요한 기술인지 아닌지에 대해 판단도 못 하겠고, 왜 MQ나, Kafka 같은 것들을 도입하여 사용하는지 어떤 상황에 맞게 쓰는 게 맞는지 근본적인 의문을 풀어보고자 이 글을 작성하게 되었습니다. 이 글은 제가 공부하면서 정리하고 적어 보는 거니 완전히 믿으시면 안 됩니다....! (밑밥깔기)

Message Queue란 무엇인가? 

참고글 https://earlybird.kr/1489
메세지 큐의 정의에 대해 찾아 보다가 이런 블로그를 찾게 되었는데 정말 가려운 곳을 긁어주는 글이었습니다. 십 년 전 글이지만 저와 똑같은 의문점을 가지고 글을 작성하셨더라구요..! 
 저도 학교 수업이나 정처기 공부했을 때 IPC(Inter-process communication)를 들어보았었는데 이때 OS에서 관리되는 이벤트들이 메세지큐를 통해서 관리된다고 알고 있었어서 처음에는 그런 느낌의 메세지큐를 말하는 건가? 싶었는데 개념은 비슷하지만 그걸 뜻한 건 아니었었네요.

여기서 말하는 Queue도 우리가 알고 있는 그 큐가 맞습니다. FIFO 패턴을 따라서 데이터가 큐에 들어가게 되면, 먼저 들어간 순서대로 제거가 됩니다. 

Message Queue는 분산 시스템에서 데이터를 비동기적으로 전송하고 처리하는 데에 사용되는 시스템입니다. 
아키텍처는 다음과 같습니다.

1. Producer(생성자): 데이터나 이벤트를 생성하고, 메세지 큐로 보내는 역할
2. Comsumer(소비자): 메세지 큐에서 메세지를 가져와서 처리하는 역할 
3. Message Broker: 
   3-1. Queue가 정의되어 있는 third-party software
   3-2. 다양한 유형의 메세지를 다른 Queue로 라우팅하기 위한 규칙도 제공한다
   3-3. Producer와 Consumer 간의 중간 역할

--> 여기서 헷갈리면 안 되는 게, 메세지 큐는 데이터 구조로서 메세지를 보관하는 방법인 것이고 메세지 브로커는 큐를 관리하는 별도의 구성요소라고 이해하면 됩니다. 

 왜 Message Queue를 사용할까? 

대용량 데이터 같은 경우 일반적인 서버단에서 그냥 처리를 하게 되면 
1. 오래 걸리고 (속도)
2. 중간에 과부하가 걸려 터질 수도 있고 (트래픽 문제)
3. 안정적이지 않아 데이터가 제대로 넘어가지 않을 수 있고. (신뢰성)
4. 또한 유지보수도 힘들 수 있습니다. (확장성)

메세지큐의 통신 과정을 보게 되면 생성자가 소비자에게 직접 데이터를 받으라고 요청하는 것이 아니라, 생성자가 중간 큐 단에 xml이나 json 형식으로 데이터를 전달하게 되면 소비자는 큐로부터 요청 데이터를 받아서 처리를 하게 됩니다. 그래서 만약 소비자가 큐에서 데이터를 받을 수 없는 상황이라면 해당 데이터는 큐에 계속 남아있게 되는 것이죠. 그렇게 해서 소비자 서버가 다시 안정화가 되었을 때 큐에 요청을 해서 처리를 할 수 있게 됩니다. 

여기서 조금 더 자세하게 이야기하자면 소비자가 죽어버리는 상황에서 볼 수 있는 것이 DLQ 인데요. Dead-Letter Queue는 하나 이상의 Source Queue가 성공적으로 컨슘되지 못한 메시지들을 재전송하기 위해 사용하는 별도의 큐입니다. DLQ에 쌓인 메시지들을 보면 왜 이 메시지들이 소비자에 의해 처리되지 못했는지를 알 수 있어서 서버가 죽더라도 DLQ를 확인해 보면 이게 잘 들어갔는지 에러가 났는지 확인해 볼 수 있어요. 

각자 메세지 큐를 통해 구현하고자 하는 상황들이 다르겠지만, 공통적인 키워드는 
1. 비동기 통신을 원할 때
2. 분산 환경에서 데이터를 안전하게 전달하고 싶을 때
3. 보낸 사람과 받는 사람이 분리되어 있을 때
가 아닐까 싶네요..... 

실제 Message Queue의 사용 사례는 어떤 것이 있을까? 
 - 주문, 재고 업데이트, 배송 등의 서비스 흐름을 관리하고 싶을 때 
 - SNS 알림 관리 
 - 실시간 채팅 
 - 게임에서 유저들끼리 매칭을 진행할 때
 - 티켓팅할 때 대기인원수 표시하는 것도 아마도 메세지 큐....?!를 이용한 것 같네요 

Message Queue의 종류

MQ의 종류로는 여러가지가 있는데 ActiveMQ, RabbitMQ, Kafka, AWS MQ, AWS SQS  등이 있습니다. 위에서도 말했다시피 각각의 시스템마다 사용할 때 더 효율적인 상황이 존재합니다. 각각의 특성들만 간단히 정리해 보고 다음 글에서는 크게 ActiveMQ와 Kafka를 직접 설치해 보고 구현을 해 보려고 합니다.

ActiveMQ

- 기업 사용 사례에 최적화된 메세지 브로커입니다. 
- Java Message Service(JMS) 표준을 기반으로 한 큐 기반 모델을 사용합니다.

주요 특징: 다양한 프로토콜 지원(AMQP,MQTT,STOMP), 유연한 메세지 지속성 옵션, 고급 기능 제공
메세지 우선 순위, 일정관리, 재전송 정책 등을 통해 메세지 처리 및 전달을 더 세밀하게 제어할 수 있습니다.

Kafka

- 확장성이 뛰어나고 내결함성이 있는 메세지 브로커 역할을 하는 오픈 소스 분산 스트리밍 플랫폼
- LinkedIn에서 개발하였으며, 높은 처리량의 실시간 데이터 스트리밍을 처리하는 데에 적합합니다.

--> 시스템에서 이벤트를 추출하는 Kafka 기반 솔루션 
주요 특징: 로그 기반 저장, 수평 확장성, 이벤트에 실시간으로 반응함, 스트리밍 처리 지원 
대규모 데이터 볼륨을 처리하고, 실시간 데이터 변환 및 분석이 가능합니다. 

RabbitMQ

 AMQP(Advanced Message Queuing Protocol)을 지원하는 오픈 소스 메세지 큐 시스템
- 다양한 메시징 패턴 및 기능을 제공합니다.

주요 특징: 다양한 프로그래밍 언어 지원, 클러스터링 및 고가용성 지원
지점 간 pub-sub 같은 다양한 메시징 패턴을 지원하므로, 유연하고 확장 가능한 통신 아키텍처가 가능합니다.
메세지 안정성과 전달을 보장하면서 복잡한 워크플로우 개발을 단순화 할 수 있습니다.

AWS SQS

AWS에서 사용되는 완전 관리형 MOM(Message Oriented Middleware)입니다. 
여러 가용영역에 걸친 메시지를 저장하므로 높은 신뢰성과 수백만 메세지를 발송하고 수신할 수 있는 확장성과 처리 능력이 있습니다. 

 Queue에 메세지 PUT, GET에 대한 초당 처리량 제한이 없어서 거의 무제한에 가까운 처리량을 보여줍니다.
- 메세지 순서에 대한 보장이 없습니다. 즉, 느슨한 FIFO 구조를 가지고 있습니다. (무조건 선입선출이 아님)
- 적어도 한번은 메세지 전달이 보장되나 2회 이상 동일한 메세지가 전달될 수 있습니다. 이는 가용성을 위해 메시지가 여러 서버에 저장어 일부 서버가 사용할 수 없는 경우 메시지가 삭제되지 않고 다시 메시지를 수신할 수 있도록 설계되어져 있기 때문입니다. 그러므로 어플리케이션 설계시 멱등성을 보장할 수 있도록 설계되어야 합니다. 

메세지 큐에 대해 조사를 나름대로 했는데 큐 종류들을 보니까 정말로 적재적소에 맞게 사용을 잘해야겠다는 생각이 드네요.. 직접 구현을 해 보고 상황에 맞게 데이터 전송을 진행해 봐야 좀 더 감이 잡힐 것 같습니다. ㅎㅎ 개념만 정리한 글이라 피드백이 있을지 모르겠지만 피드백은 언제나 환영입니다! 부족한 글 봐 주셔서 감사합니다... 🙇‍♀️

9/7~9/14 

1단원 

나온 질문들 

질문1. 데이터 수집은 벌크(bulk)형데이터, 스트리밍(Streaming)형 데이터로 구분되는데 스트리밍형 데이터 수집을 할때 Message Queue를 쓰는 Kafka 를 쓰거나, Spark Streaming을 쓰는 기업으로 구분되는것같은데 두개의 차이는 무엇일까요??
카프카는 실제로 데이터를 저장하는 것은 아니고, 데이터를 저장을 하는데 데이터 발생하는 주기가 너무 짧은데 저장할 수 없을 경우에는 큐에 쏘아놓고, 큐에 저장하는 게 카프카가 하는 일이고 (초당 데이터가 너무 빨리 발생할 때 큐에 저장할 때) 카프카는 데이터나 형변환을 할 수 있음. 중간 단위의 처리도 가능하기 때문에 데이터가 유실이 되지 않아야 할 때 많이 씀. 

주 목적은 데이터 유실을 막고 큐 형태로 저장을 할 때 사용함. 

카프카에 클러스터 형태를 구축해서 양쪽에서 빼나갈 때 중복으로 나가지만 않게 처리를 하고, 카프카 노드가 하나 날아가면 데이터를 뽑아갈 수 있게 처리를 함 

스파크는 인메모리 데이터 기반이 아니다 보니 너무 느려서 스트리밍이 빨리 저장하기 위해 나온 거 

판다스나 넘파이는 로컬에서 하는 게 훨씬 빠르고, 하둡에 적재를 했다면 스파크나 임팔라 같은 솔루션이나 태블로나 제플린 같은 거에 올려서 사용하는 게 나을 수도 있음 

질문2. 대부분의 빅데이터환경은 분산환경을 목표로 구축한 경우가 대다수인것같은데, 데이터분석을 할때 주로 쓰는 Pandas, Numpy를 분산환경에서 적용할수는 없을까요??

질문 1. rdb 형태든, 시계열 데이터든, nosql 형태의 데이터들같은 바로 분석에 쓸 수 없는 원자료 형태의 데이터 소스들을 데이터 레이크에 보존한다고 이해했습니다 -> 여기서 데이터 레이크는 하둡 안 시스템에 저장을 해 놓는 건가요?
하둡을 실제로 구동해 보는 작업을 해 보면 명확히 이해할 것 같은데, 하둡 안에 데이터를 저장할 때는 데이터 노드에 담긴다고 하더라구요 이건 데이터 형태에 관계 없이 데이터 노드에 때려박아놓고 필요한 것만 꺼내는 형식이라고 이해했는데 맞게 이해한 건지 궁금합니다

네임 노드와 데이터 노드로 구분이 됨

데이터는 로컬에 저장이 됨 

하둡 hdfs라는 소프트웨어가 돌고 있음 

자기 로컬 하드디스크에 저장을 해 놓고 그걸 솔루션에 접속을 해 놓으면 클러스터 내에 

노드가 이백개 삼백개 잇는데 RDD 형태로 만들고 있다가 데싸가 실행을 했을 때 메모리에 올려서 그걸 

질문 2. 책을 읽어 보면서 데이터 분석을 하기 위해서는 data frame의 형태와 같은 스프레드 형태로 변환해야 할 것 샅다는 생각이 들었습니다. (26쪽 참고) nosql 같은 경우는 json, key-value 형태로 이루어져 있는데 이를 데이터레이크(분산스토리지)에서 데이터 마트에 분석용 데이터로 적재 or 가공할 때 사용하는 것이 바로 spark 프레임워크인 건가요? 

질문 3. 여기까지 제가 이해한 게 맞다면 nosql 데이터도 결국 스프레드 형태와 같은 정형화된 행렬 구조로 변환을 해야 분석이 가능하다라고 이해를 했는데 제가 이해한 게 맞을까요?

이미지 파일 같은 비정형 데이터를 hdfs에 저장을 해놓고

1. 1장을 읽어본 결과 데이터 처리 구조는 데이터의 용도에 따라서 달라지는 것 같습니다. 

현업에 계신분들은 어떤 데이터 처리 구조를 사용하고 계신가요? 

저는 스몰 데이터를 처리하고 있으며 전형적인 ETL 구조를 사용하고 있습니다. 

크롤링후 원본 데이터 DB 적제, 전처리 (파싱), 적제 하는 구조를 사용하고 있습니다. 

다른 분들은 어떤 구조를 사용하시는지 궁금합니다.
저 같은 경우는 원자료 자체도 RDB 형태이고, 적재해야 하는 DW도 RDB 형태이기 때문에 날짜 정도만 파싱을 하고 나머지는 컬럼만 바꾸어서 ETL을 진행하고 있습니다. 그렇다 보니 고도의 기술이 필요하지 않아 nifi 로 SQL 문 정도만 모니터링할 수 있도록 자동화 툴만 만들어놓은 상태입니다~~

2. BI 툴을 사용하는 이유는 조작이 간편하기 때문인가요? 

저자가 언급했듯이 pandas로 핸들링이 가능한 데이터라면 BI를 사용하지 않고 
matplotlib으로도 충분히 시각화가 가능할 것 같습니다. 
BI를 사용하는 장점으로 자동화와 핸들링이 쉽다는 것 외에 큰 장점이 없어 보입니다. 

BI를 사용하시는 분들의 코멘트 부탁드립니다. 🙂 
데이터 시각화를 어느 용도에 사용할 건지에 따라 다를 것 같습니다. 단순 보고서 용도나 시각화 작업 후 분석 용도로만 본다면 matplotlib로만으로도 간단하게 보겠지만, 모니터링 용도 혹은 실시간 데이터 서비스로 차트를 보여 줘야 하는 경우들은 자동화가 가능한 BI툴이 관리적 측면에서도 가장 좋지 않을까 싶습니다. 일단 기본적으로 사용할 수 있는 시각화 옵션들이 많다는 것에 큰 장점이 있는 것 같고, 인터렉션 같은 기능들을 제공해 주기 때문에 쓰는 이유가 가장 크지 않나 싶습니다. 또한 BI 툴들이 시각화만 제공해주는 것이 아니라 공유 서비스나 공동 작업, 협업을 할 수 있는 기능들도 있기 때문에 BI 툴을 도입함으로써 다른 일에 더 집중할 수 있게 해 주는 효과가 있지 않을까 싶습니다 ㅎ 

3. 저자가 23 페이지에서 프로그래밍언어를 사용하는 것은 개발자의 영역이라고 언급하고 있습니다.

현업에 계신분들은 실제로 프로그래밍 언어를 사용하지 않으시나요? 
저는 EDA는 pandas를 사용하고 있으나 데이터 전처리 작업은 python과 AWS로 처리하고 있습니다. 

다른분들은 어떻게 작업을 하고 계신지 궁금하네요 ㅎㅎ

많이 사용합니다! 다만 SQL 안에서 처리할 수 있는 건 SQL 안에서 처리할 수 있도록 하고 되도록이면 코드까지 가지 않으려고 합니다. 데이터 전처리가 필요한 작업이라면 배치 프로그램을 따로 만들어서 적용하고 있습니다. 

1. 데이터 마트/데이터 웨어하우스/ 데이터 레이크 를 명확히 구분해서 설명해주실 수 있는 분이 계신지 궁금하구요
++ 다시 읽어보니 데이터가 적으면 하둡까진 사용안해도 데이터웨어하우스만으로 충분하고, 많으면 하둡으로 모아서 한번 집계해서 데이터웨어하우스에 저장한다가 맞나요 ?p7 

데이터웨어하우스는 대량의 데이터를 장기 보존하는 것에 최적화 되어 있음. 데이터 소스에 보존된 것은 원시 데이터고 이것을 ETL 프로세스를 통해 데이터웨어 하우스에 저장하는 것임. 그래서 이 데이터웨어하우스는 업무에 있어서 중요한 데이터 처리에 사용되기 때문에 아무때나 함부로 사용해 시스템에 과부하를 초래하면 안 된다. 따라서 데이터 분석과 같은 목적에 사용하는 경우네는 데이터 웨어하우스에서 필요한 데이터만을 추출하여 '데이터 마트'를 구축하는 것임. 

데이터레이크의 경우에는 데이터 웨어 하우스에 넣을 수 없는 (정형화 되지 않은 텍스트 파일, 바이너리 데이터 등) 데이터를 저장하는 장소이다. 우선 데이터를 저장해 놓고, 나중에 테이블을 설계하는 것이 빅데이터의 정의다. 

모든 데이터를 원래의 형태로 축적해두고 나중에 그것을 필요에 따라 가공하는 구조가 필요하기 때문에 빅데이터의 세계에서는 여러곳에서 데이터가 흘러들어오는 '데이터를 축적하는 호수'에 비유해 데이터의 축적 장소를 데이터 레이크라고 한다. 

구체적으로는 임의의 데이터를 저장할 수 있는 분산 스토리지가 데이터 레이크로 이용됨. 형식은 자유지만 csv나 json 등의 범용적인 형식이 사용됨. 

원자료에서 DW로 바로 적재하는 시스템은 DW에 과부하가 일어날 수 있기 때문에 추천하는 방법은 아니라고 합니다.  스몰 데이터는 적당히 모아서 하나의 큰 파일로 만들어 분산 스토리지에 저장하고,  빅 데이터 같은 경우는 적당한 크기로 분할해서 DW로 보낸다고 합니다  
https://dianakang.tistory.com/40
2. 시계열 데이터를 현업에서 쓰고계신분 있는지 궁금해요, 많이 낯서네요

시계열 데이터 같은 경우는 주변에서도 많이 사용하고 있는데, 시간이나 날짜 같은 일정한 간격으로 쭉 나열되어 있는 데이터들을 시계열이라고 하기 때문에 현업에서도 많이 쓰고 있습니다. 저희 회사 같은 경우는 환자들의 방문 날짜들을 시계열로 풀거나 어떠한 검사 결과를 날짜 별로 가공해서 그래프를 보여주는 형태로도 시각화를 진행하고 있습니다.

질문1. 책 내용 중에 멀티 코어에 의한 대규모 병렬처리인 mpp 기술을 소개하면서 “mpp 데이터 베이스”와 “대화형 쿼리엔진”에 대해 비교하던데 이 둘의 차이에 대해 명확히 개념 정립이 되지 않습니다. 추가적으로 “인메모리 데이터베이스”라는 것도 나오던데 각각의 db에 대한 설명 부탁드리겠습니다. 

기존의 RDB와 MPP는 행 지향, 열 지향으로 다름

하이브와 프레스토와 같이 대규모 배치처리할 때 / 작은 쿼리 대화형 

데이터 양이 증가하면서 매번 집계와 분석에 대한 시간이 늘어가고 있음

이로 인해 대기 시간이 길어짐에 따라 하고 있던 집계나 분석 작업에 병목이 발생하게 됨 이 문제는 작업의 효율성을 비롯하여 다양한 문제를 일으킨다.

그러나 보통 데이터 수집 단계에서는 이런 부분을 고려하지 않기 때문에 3계층으로 구성을 하게 됨. 

Data Lake -> Data Mart -> Visualization (BI Tools)

대화형 쿼리 엔진은 태블로나 아파치 재플린이 그런 형태를 가지고 있음. 웹페이지인 프로트엔드에 접속을 해서 쿼리를 치면 주피터에 실행하는 것처럼 차트 뷰를 띄워주는 거

인메모리 데이터베이스와는 구분해야 함 reids impla spark 메모리에만 데이터를 저장함 자바의 jvm처럼 고속처리 key -value 데이터베이스를 구축해줌 

transform이 위치에 따라 비용이 다름 

입출력할 때 소모되는 메모리에 자원 소모량 때문에 메모리에 임시적으로 올려놓고 작업을 빨리빨리 하기 위해서 사용을 하는 건지?

디스크 io는 무조건 발생함. 근데 그걸 메모리에 올려놓고 하면 성능이 그나마 나으니까 그렇게 한 것임

해결

1. 모든 데이터를 메모리에 적재 

- 가장 간단한 방법임. 그런데 데이터가 만약 5~ 10기가 정도의 작은 데이터 양이라면 RDB를 Data Mart로 활용하는 것이 낫지만, 메모리가 부족해지면 성능이 급격히 저하된다는 단점이 있다 

2. 압축과 분산

- 고속화를 사용되는 기법

데이터를 가능한 작게 압축하고 그것을 여러개의 디스크에 분산시켜 데이터 로드의 지연을 줄임

이런 분산된 데이터를 읽으려면 멀티코어를 활용해 디스크 I/O를 병렬처리하는 것이 효과적임

이런 아키텍쳐를 MPP(Massive Parallel Processing) 이라고 함

MPP는 데이터 집계에 최적화 되어 있고, DW와 데이터 분석용 DB에서 특히 많이 사용됨

AWS RedShift와 빅쿼리가 MPP를 지원하고 있음 

3. 열지향 데이터베이스 접근 

빅데이터로 취급되는 데이터들은 대부분 디스크 상에 있음. 

MPP 데이터 베이스 vs 대화형 쿼리 엔진

MPP 데이터 베이스: 데이터 집계에 최적화된 데이터 베이스. 

질문2. 좀 뻘한 질문일 수도 있지만 개인적으로 좀 궁금해서 질문드립니다. ETL과 ELT가 있는데 여기서 Transform 하는 데에 비용이 많이 들어가다 보니 요즘의 경우 일단 Load를 하고 Transform 하는 ELT를 선호 한다고 들었습니다. 그런데 Load를 먼저 했다고 하지만 결국에는 Transform을 거쳐야 할텐데 그럼 그 사이에서 일부 데이터를 정제하는 일련의 작업이 추가되어야 하는 것일까요??

https://pearlluck.tistory.com/650

1.nosql에 관해 여러 종류가 소개 되었더라구요.
공통적으로 읽고 쓰는 효율을 위해 사용하는것 같은데, rdb와 달리 실 사용시 고려해야 하는 부분들이 있다면 어떤 부분들이 있을지 궁금합니다.
rdb 같은 경우는 관계형 데이터베이스이기 때문에 정규화가 매우 중요한 작업이지만, nosql 같은 경우는 관계형이 아니라 수직적인 구조이기 때문에 rdb를 설계하듯이 설계하면 안 된다는 점이 있음. 

nosql은 디비를 만들고 나서는 인덱스를 할 수가 없어서 설계를 잘해야 한다 프론트엔드에 표시될 것으로 설계를 하면 됨 nosql의 솔루션에 따라서 어떻게 분산배치할 건지 생각하면 됨 

2.수집시 앞단에 앱/웹에서 데이터를 수집하는 방법은 어떤식으로 구성 되어있는지 궁금합니다.

1. 하둡은 '다수'의 컴퓨터에서 데이터를 분산 처리하기 위한 시스템이라 하였는데, 개인 컴퓨터(노트북 등) 같은 환경에서 하둡을 사용하여 데이터를 처리했다면 이 경우에는 분산 처리를 진행했다고 보기 힘든 것인가요?

하둡 자체가 다수의 컴퓨터에서 데이터를 받아들여 저장하는 공간이기 때문에 개인 컴퓨터에 하둡을 설치했다면 그건 하둡이 있는 서버가 개인 컴퓨터일 뿐 들어오는 데이터들은 여러 곳에서 들어올 것이기 때문에 분산 처리를 이미 하고 있을 것 같습니당 

https://discord.com/channels/1015585569247612928/1019572598847320064/1019589980361850910

2. 데이터 레이크. 데이터 마트는 주로 어떤 툴?시스템?에 데이터들을 저장하나요? 그리고 이것들이 보통 하나의 큰 데이터베이스 안에서 다루는지, 여러 개의 데이터베이스로 나뉘어 다루는지 궁금합니다.

https://discord.com/channels/1015585569247612928/1019572598847320064/1019591113406955560

https://discord.com/channels/1015585569247612928/1019572598847320064/1019591211578830910

1. 데이터 레이크에 타입에 상관없이 데이터를 담아두지만 대부분의 경우는 CSV나 JSON 등의 범용적인 형식을 담아둔다는데 혹시 현업에 데이터 레이크를 사용할 때 이외의 타입을 사용하시는 경우가 있는지가 궁금합니다.
해당 질문에 대해 찾아 보니 S3에 데이터를 저장할 때 parquet 데이터 형식이 있다고 합니다. 데이터 레이크를 s3로 사용하시는 분들은 파케이 형식으로 저장할 것 같습니다.

음성데이터는 block, 이미지는 매트릭스 형태로 저장. 

사실 꺼냈을 때 제일 편한 형태로 저장하는 것이 베스트다 csv나 json으로 저장하는 경우는 진짜 거의 없음

실제로 데이터 저장할 때는 속도 적고 인덱싱 잘 되는 형태로 저장하는 것이 좋음. 

2. 파케이 파일을 데이터 프레임으로 읽어들일때 아파치 애로우를 사용하면 더 빠르다는 이야기를 들은적이 있습니다.
혹시 데이터 프레임으로 읽어들일때 아파치 애로우를 활용해 CSV를 파케이로 변환 후 읽는 작업을 해보신 경험들이 있으신지 궁금합니다.

파케이: 데이터를 저장하는 방식 중 하나로 하둡 생태계에서 많이 사용되는 파일 포맷임.

아파치 애로우 같은 경우는 메모리 상에서 컬럼 구조로 데이터를 구성할 수 있고, 해당 데이터를 사용할 수 있는 라이브러리를 제공함. Arrow 포맷은 CPU 캐시 로컬리티 특성을 극대화 하 루 ㅅ있고, SIMD 명령어 같이 인텔 CPU를 벡터화해서 활용할 수 있는 기능을 제공함. 

사실상 판다스랑 애로우는 메모리 소모량은 같지만 애로우는 파케이 형식만 지원하고 있기 때문에 csv 보다는 월등히 높은 저장 속도를 보인다고 함. 

오버헤드가 걸림 

파케이는 바이너리 파일이고 얘를 컬럼으로 저장하면 장점은 데이터 프레임을 한꺼번에 맞추면 1번노드에서 1열 다 가져오고 2번 노드에서 2열 다 가져오고 가까운애한테 저장되는 장점이 있음 hdfs가 블록사이즈로 저장되는데 그게 가까운 곳에 저장되기 때문에 금방 가져올 수 있음

근데 단점은 1행부터 2행까지만 불러오고 싶은데 컬럼와이즈로 되어 있는데 로우와이즈로 읽어오고 싶다. 같은 경우가 생기면 설계에 대해서 생각을 많이 해 봐야 함 

필요한 만큼 저장하게 됨 ㅋㅋ 

하둡, 스파크 공부 방법...

데이터 저장되는 게 궁금한 건지, 사용해 보고 싶은 건지

1. 로컬에 개발 형태의 하둡 hdfs랑 스파크 올려서 혼자 해 보는 거 

2. aws에서 프리티어 인스턴스 몇 개 붙여서 잠깐 올렷다 내리기 

3. 회사에 좋은 서버 있으면 도커 컨테이너 붙여서 사용해 보기 

설치하면서 중요 포인트 확인해 보고 설치되면 데이터 넣어 보기 

airflow는 파이썬으로 동작한다. 

airflow 설치 

데이터 파이프라인을 dag라고 부른다 - ETL을 파이썬 코딩으로 구현된 코드 

그 DAG는 task의 집합임. 

airflow는 하나의 서버로 구성되지만 job의 수가 늘어나면 서버를 더 세팅해야 함. 다수의 서버로 airflow 클러스터를 운영할 수 있음. 

airflow 클러스터 형태로 구성이 된 airflow를 쓰고 싶으면 클라우드 서버를 쓰는 것이 낫다. 

서버가 많으면 많을 수록 그 위에서 돌릴 수 있는 dag가 많아지는 것임. 

이 서버가 무슨 이슈로 안 돌아가면 airflow를 쓸 수 없어서 문제가 있을 수 있다. 

내부 DB 필요함 -> history 기록용 

sqlite에 dag 정보를 기록함 < 이걸 쓰면 개발하기 힘들고 보통 postgresql나 mysql 설치해서 씀 

Airflow 데이터 파이프라인을 생각해 보면 

1. 어떤 데이터 소스에 연결할 것인가 

2. 어떤 destination에 저장할 것인가 

3rd party services 와 연동하는 것이 쉽다. airflow 2.0 을 사용 중 

airflow에는 다섯 가지의 컴포넌트가 있다. 

1. Web Server

2. Scheduler : 몇 시 몇 분에 실행되어야 한다. 1시간에 한 번씩 실행해야 한다. 일요일에 실행되어야 한다 등 

3. Workder: DAG 가 실행이 된다: DAG에 포함되어 있는 Task들을 실행하는 것이 Worker다. 

4. Database (Sqlite가 기본으로 설치됨) : 성능이 좋은 postgresql나 mysql 설치하는 것이 좋다. 

5. Queue (멀티 노드 구성인 경우에만 사용됨) 

노드가 하나일 경우에는 worker, scheduler, webserver가 한 군데에 저장됨. 

데이터가 작을 때는 서버 한 대로 충분하다 

worker는 falsk로 구현되어 있음. 

Scale up: 서버를 더 좋은 사양으로 바꾸는 것 

Scale out: workder node 추가 

노드가 많으면 많을 수록 DAG를 사용하기 쉬움 

DAG?

데이터 파이프라인. ETL 

다수의 task 

directed acyclic graph 

airflow는 루프를 도는 사이클은 지원하지 않음 단방향으로 감 

task의 집함

Task

: 데이터의 오퍼레이터

postgres query, hive query, S3 Read/Write, Spark Job, Shell Script 

굉장히 범용적인 오퍼레이터들이 많고, 그걸 갖다 쓰면 된다. 

서포트도 좋음 

t1, t2, t3 라는 Task가 있고 t1이 끝나는 순간 t2, t3 두 개의 task 가 동시에 실행되도록 DAG를 짤 수 있다. 

Airflow의 장단점

ETL 관리하고, 작성을 생산성 있게 만드려고 만들어진 툴임

데이터 엔지니어들한테는 좋은 기능들임

대신에 러닝커브가 좀 있다. 

클러스터 노드로 들어가게 되면 관리하기가 힘들기 때문에 클라우드를 써야 함 

디버깅하고 개발하기 힘든 부분이 있음 

from airflow import DAG

DAG가 실패하면 연락하는 메일. 실패하면 다시 실행할 건지 유무도 있음 

중요한 파라미터들이 좀 있음. 

DAG object 만들어야 함 

test_dag = DAG(

"dag_v1", # DAG name 

# schedule (same as cronjob)

shcedule_interval="0 9  ***",

# 매일 아홉 시 0분에 시작한다. 

# 0 * *** 면 매일 0시에 시작한다는 뜻임 

# 특정 달, 특정일, 특정 요일에 쓸 수 있음 

# 0, 30 9 * * * 매일 30분마다 ETL

# 앞에 DAG가 끝나면 트리거를 줄 수 있음 앞의 데이터가 뭘 받아야 실행되면 upstream 모듈이 끝나면 나를 트리거 해라 라는 식으로 부를 수 있음. 

#timezone을 서울로 바꿔야 함 

Operators Creation Example 

t1이 끝나면 t2, t3가 동시에 작동되게 하고 싶음 

t1 >> t2

t1 >> t3 

bashoperator 

 이 태스크가 실행이 되면 리눅스 커맨드 라인에서 실행되게 함 

  task 라는 것은 오퍼레이터를 써서 코드를 만드는 것임 

t1 >> [t2, t3]

t2.set_upstream(t1)

t3.set_upstream(t2)

start = DummyOperator (아무의미도 없음. 시작 끝 구분하려고 그러는 거) 

start >> t1 >> end

start >> t2 >> end 

start >> [t1, t2] >> end

데이터 파이프라인을 만들 때 고려할 점 

이상과 현실간의 괴리 

데이터 파이프라인은 많은 이유로 실패함

- 버그, 데이터 소스상의 이슈, 데이터 파이프라인들간의 의존도에 이해도 부족

데이터 파이프라인의 수가 늘어나면 유지보수 비용이 기하급수적으로 늘어남 

가장 좋은 방법

(1)

가능하면 데이터가 작을 경우 매번 통채로 복사해서 테이블 만들기 (Full Refresh)

Incremental update만 가능하다면, 대상 데이터소스가 갖춰야 할 몇 가지 조건이 있음 (바뀐 부분만 업데이트하기)

- 데이터 소스가 프로덕션 데이터베이스 테이블이라면 다음 필드가 필요함

• created (데이터 업데이트 관점에서 필요하지는 않음) 
• modified
• deleted 

데이터 소스가 API라면 특정 날짜를 기준으로 새로 생성되거나 업데이트된 레코드들을 읽어올 수 있어야 함 

(2)

 멱등성(Idempotency)

동일한 입력데이터로 파이프라인을 한 번 실행하나 백 번 실행하나 내용이 동일해야 한다 

백 번 실행하면 중복이 백 개가 생기는지. 

input이 같은데 output이 다르면 안 된다. 

(3)

실패한 데이터 파이프라인을 재실행이 쉬어야 함 

과거 데이터를 다시 채우는 과정(Backfill)이 쉬어야 함 - 이미 읽어온 데이터가 있는데 포맷 데이터건 뭐건 다시 읽어오는 거 

Airflow는 이 부분(특히 backfill)에 강점을 갖고 있음 

• DAG의 catchup 파라미터가 True가 되어야 하고 start_Date end_date이 적절하게 설정되어야 함 
• 대상 테이블이 incremental update가 되는 경우에만 의미가 있음 
  • execution_date 파라미터를 사용해서 업데이트되는 날짜 혹은 시간을 알아내게 코드를 작성해야 함 
    • 현재 시간을 기준으로 업데이트 대상을 선택하는 것은 안티 패턴. 

(4) 

데이터 파이프라인의 수가 늘어나면 뭐가 필요한지 뭐가 안 필요한지 버리는 데이터가 뭔지 분석하는 게 중요함 

주기적으로 안 쓰는 데이터 파이프라인, 대쉬보드를 클린업하는 작업이 필요함 

(5)

데이터 파이프라인 사고시마다 사고 리포트 쓰기 

중요 데이터 파이프라인의 입력과 출력을 체크하기 

• 아주 간단하게 입력 레코드의 수와 출력 레코드의 수가 몇 개인지 체크하는 것부터 시작 
• 써머리 테이블을 만들어내고 primary key 가 존재한다면 Primary key uniqueness가 보장되는지 체크하는 것이 필요함
• 중복 레코드 체크 

Daily Incremental Update를 구현해야 한다면? 

• 하루에 한 번씩 돌면서 update하는 거. full refresh 하면 편한데 아닐 경우
• 2020년 11월 7일부터 매일매일 하루치 데이터를 읽어온다고 가정해 보자 
• 이 경우 언제부터 해당 ETL이 동작해야 하나?
  • 2020년 11월 8일 
• 2020년 11월일날 동작하지만 읽어와야하는 데이터의 날짜는?
  • 2020년 11월 7일
  • Airflow의 start_date는 시작 날짜라기 보다는 읽어 와야 하는 날짜임 (incremental update 잡인 경우) 

Incremental하게 1년치 데이터를 Backfill 해야한다면?

• 어떻게 ETL을 구현해놓으면 이런 일이 편해질까?
• 해결방법 1
  • 기존 ETL 코드를 조금 수정해서 지난 1년치 데이터에 대해 돌린다
  • 실수하기 쉽고 수정하는데 시간이 걸림
• 해결방법 2 
  • 시스템적으로 이걸 쉽게 해주는 방법을 구현한다
  • 날짜를 지정해주면 그 기간에 대한 데이터를 다시 읽어온다
    • Airflow의 접근방식
      • 모든 DAG 실행에는 “execution_date” 이 지정되어 있음
      • execution_date으로  채워야하는 날짜와 시간이 넘어옴
      • 이를 바탕으로 데이터를 갱신하도록 코드를 작성해야함

execution_date를 결정하게 코드를 짜면 좋다.