imhamburger 님의 블로그

데이터엔지니어 부트캠프 - 첫번째 팀프로젝트 (8/2~8/6) 1일차 본문

데이터엔지니어 부트캠프

데이터엔지니어 부트캠프 - 첫번째 팀프로젝트 (8/2~8/6) 1일차

imhamburger 2024. 8. 4. 01:55

7월 한달동안 배운 내용들이 참 많다. 터미널을 다루는 것부터 vim, bash, 깃&깃허브, pyenv, pdm, Airflow, sql, pandas 등..

초기엔 vim과 깃&깃허브 다루는 것에 집중하였다면 지금은 간단한 기능도 만들고 배포하고 써보고하는 등 간단한 것이지만 무언가를 만들 수 있다는게 조금은 신기하다. 그리고 실제로 만들어야 하는... 팀프로젝트가 시작되었다.

 

8월 2일 금요일부터 첫 팀프로젝트를 시작하였다. 프로젝트를 완성하는데 주어진 시간은 3일이다.

팀구성은 3인 1조인데 우리의 팀이름은 "play gogo" 로 정했다. (이유는 딱히 없다..)

 

팀프로젝트 과제는 영화 박스오피스 데이터 수집 / 처리 / 보관 및 활용이었고 필수적으로 해야하는 건 다음과 같다.

  • 영화 박스오피스 데이터 수집 / 처리 / 보관 및 활용에 대하여 각각 단계에 파이썬 프로그램을 package(PIP설치) 단위로 개발
  • 개발 package를 airflow 적용 및 운영

전체적인 진행계획은 다음과 같다.

  • 영화 박스오피스 데이터 수집 / 처리 / 보관 그리고 에어플로우 운영 총 4개의 깃헙 레포 생성
  • 데이터 파이프라인 구현 (Airflow)
  • 데이터 수집에 관한 파이썬 기능 구현 (import requests, partition_cols, parquet)
  • 데이터 처리를 위한 파이썬 기능 구현 (import pandas)
  • 데이터 보관을 위한 파이썬 기능 구현 (parquet)
  • 에어플로우에 기능 적용 및 운영
  • README.md 작성 및 피피티 1장 

우리는 프로젝트를 바로 시작하기 전에 아이스브레이킹으로 간단한 기능을 구현하기로 했다.

아이스브레이킹 구현은 에어플로우에 아스키아트로 변환된 그림이 출력되는 것이다.

 

 

제 1 장: pdm install 할 때 패키지 이름이 아닌 깃헙주소로 설치하자.

 

아이스브레이킹 기능을 각자 3명이서 만들고 서로의 것을 설치하여 만든 기능에 더하는 작업을 하였다.

내가 만든 패키지 이름은 "transform"이었고 다른 팀원분들이 만든 패키지명은 각각 "Extract" , "Load" 였다. 

pip install git+{깃허브 HTTPS url}@{BRANCH_NAME}

 

 PIP설치는 위 코드로 진행하였으며, 가상환경에서 설치하여 테스트를 진행해야 했기에 pdm install도 해줘야 했다.

그래서 당연히 pdm install {패키지명} 을 입력하여 설치하였다.

 

근데 여기서 문제가 발생하였다.

 

근데 뭔가 엄청나게 많은 용량의 패키지들이 설치되길래 뭐지? 싶었다. 설치가 다 되고 pdm add 도 해주었다. 그리고 나의 소스코드 안에 팀원분이 만든 기능의 함수도 import 하고 추가해주었다.

그리고 실행을 하니 NotFoundName 오류가 났다. 잘 설치하고 세팅해주었는데 왜 자꾸 찾을 수 없다고 뜨는건지... 삭제하고 재설치하여도 같은 오류가 났다.

 

알고보니, 우리가 쓴 패키지명이 Pypi에도 이미 존재하는 패키지명이어서 그것이 설치된 것이다... 그니까 이상한 걸 설치한거다....

그래서 잘못 설치한 패키지를 삭제하고 다음과 같은 방법으로 설치하였다.

pdm install git+{깃허브 HTTPS url}@{BRANCH_NAME}

 

이렇게 해주니 오류없이 잘 출력되었다.

패키지를 설치할 땐 같은 이름의 패키지가 존재할 수 있으니 깃헙주소로 설치하자!

 

 

제 2 장: Git Push, Git pull 충돌

 

깃푸시와 깃풀 때문에 거의 3시간?을 고생한 것 같다. 사실 혼자할 때는 충돌이 날 것이 없기때문에 순조롭게 했던 거였고 팀프로젝트를 하면서 여럿이 진행하니 계속 충돌이 났다..

 

팀원분이 깃푸시하려 할 때 받은 에러메세지는 다음과 같다.

! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'origin'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

 

위 메세지는 이러한 상황에서 볼 수 있다.

  • 원격 브랜치에 이미 다른 사람이 푸시한 변경사항이 있는데, 이를 로컬 브랜치에 반영하지 않고 로컬 변경사항을 푸시하려고 할 때
  • 여럿이 동일한 브랜치에서 동시에 작업하고 푸시하려고 할 때

우리팀은 미리 브랜치까지 이미 다 만든 상황이었다. 그리고 main 브랜치에 작업파일을 푸시한 상태였다. 근데 미리 만들어둔 브랜치에는 당연히 메인에 있는 파일이 없으니.. 브랜치를 삭제하고 다시 메인에서 브랜치를 만들었다.

그리고 팀원분이 다시 만들어진 브랜치를 로컬에서 깃풀을 받아 작업하였고 작업 후 깃푸시를 하니 위와 같은 에러가 난 것이다.

 

아마도? main에서 브랜치를 삭제하고 다시 만들고 하는 과정이 있었고(main에서 수정된) 팀원분은 브랜치 A로 바로 checkout하여 브랜치 A에서 깃푸시를 시도하였으니 main에서도 깃풀을 한 다음 브랜치A에서도 깃풀을 하고 작업해야했던 상황인 것 같다.

 

위 충돌메세지를 해결하기 위해선,

1. 먼저 `git pull` 명령을 사용하여 원격 변경사항을 가져온다.

git pull origin main

 

그런데? 이 과정에서 충돌이 발생한다.. 그럼 충돌을 수동으로 해결해줘야 한다.

2. 충돌이 발생한 파일을 열어 충돌 부분(<<<<<<<, =======, >>>>>>>)을 찾아 수동으로 수정해준다.

 

3. 수정 후 다시 시도한다.

git add .
git commit -a #혹은 git commit -a -m "메세지입력"
git push

 

여기서 git commit -a 라는게 있다는 걸 처음알았는데,

-a 옵션은 "all"의 약자로, Git이 변경된 파일(수정되거나 삭제된 파일)을 자동으로 스테이징(stage)하여 커밋한다.

단, 새로운 파일은 포함되지 않기때문에 새로 생성된 파일은 명시적으로 git add 명령을 사용하여 스테이징해야 한다.

 

위처럼 해주니 충돌이 해결되었다. 그렇지만 앞으로 충돌을 방지하기 위해서는 작업을 시작하기 전 꼭 항상 원격 브랜치의 최신 변경 사항을 가져와야 한다는 것이다. git pull git pull...잊지말자.

 

 

제 3 장: 에어플로우.. AIRFLOW_HOME은 홈디렉토리에...

 

깃충돌을 해결하기 위해 많은 시간을 써버렸지만.. 그래도 해결은 되었으니. 에어플로우를 설치하였다. 그치만 내가 이미 가지고 있는 에어플로우가 아닌 새로 팀프로젝트를 위한 에어플로우가 필요하니 airflow가 로드할 dags 폴더를 별도로 지정해야 한다.

 

환경변수를 넣고 적용하기 위해 .zshrc 다음과 같은 코드를 입력 및 저장해줘야 한다.

export AIRFLOW_HOME=~/airflow_team
export AIRFLOW__CORE__DAGS_FOLDER=~/code/team1/movie_airflow/dags
export AIRFLOW__CORE__LOAD_EXAMPLES=False

 

1. AIRFLOW_HOME을 airflow_team이라는 폴더를 생성해 기존과 다른 곳에 지정해준다.

2. AIRFLOW__CORE__DAGS_FOLDER 는 dags폴더 경로를 지정해주는 것이므로 원하는 경로를 적어주면 된다.

3. AIRFLOW__CORE__LOAD_EXAMPLES=False는 에어플로우 실행하면 여러 샘플 dags들이 보이는데 이를 비활성화해주는 것이다. True이면 샘플 dags들이 생성되어 있다.

 

위 작업을 마쳤으면 쉘을 재실행해준다!

source ~/.zshrc #zshrc 실행

 

그리고 airflow를 완전 종료하고 다시 구동하면 끝.

 

새로운 admin 암호 확인은 다음과 같다.

$ cat ~/airflow_team/standalone_admin_password.txt

 

 

근데.. 또 여기서 문제가 발생했다.

airflow 실행은 잘 되는데 만들어놓은 dags 파일이 안보인다? 아무리 새로고침해도 안보인다...

 

이유는,

AIRFLOW_HOME 설정을 잘못해줬기 때문이다..

 

환경변수로 넣어 적용한 것이기 때문에 AIRFLOW_HOME 은 홈디렉토리에 설정을 해줘야 airflow가 잘 읽어온다.

근데 나는 설정할 때... 홈디렉토리가 아닌 팀폴더 안으로 설정을 했었다.

 

홈디렉토리로 설정해야하는 이유

 

1. 파일 및 디렉토리 접근 권한

  • 홈디렉토리는 사용자가 파일과 디렉토리를 읽고 쓸 수 있는 권한이 기본적으로 보장되는 장소이다. 시스템 디렉토리나 다른 사용자의 디렉토리와 달리, 홈디렉토리는 일반 사용자가 접근 권한 문제 없이 사용할 수 있다.

2. 데이터 구성의 일관성

  • 홈디렉토리에 Airflow 설정을 두면, Airflow의 구성 파일, 로그, DAG 파일, 데이터베이스 등이 한 곳에 모이게 되어 관리가 용이하다.
~/airflow/
|-- airflow.cfg
|-- dags/
|-- logs/
|-- plugins/

 

3. 환경 변수 표준화

  • 홈디렉토리를 사용하는 것은 많은 소프트웨어와 도구에서 권장하는 표준이다. 사용자별 설정 파일이나 데이터가 홈디렉토리에 위치하게 되어, 다른 사용자나 시스템과의 충돌을 피할 수 있다.

나는 에어플로우 dags파일도 팀폴더 안으로 설정하였으니 당연히 에어플로우의 플러그인, 로그 등도 같은 경로에 있어야한다고 생각했다. 근데 그게 아니고 여러가지 이유로 홈디렉토리에 설정해야 한다는 걸 배웠다.

 

 

팀프로젝트를 진행하면서...

 

좋은점

 

이번 협업의 가장 큰 장점은 여러 사람과 함께 일할 수 있다는 것이다. 회사에서는 혼자 일하는 것이 아니라 팀원들과 함께 일해야 하기 때문에 협업이 매우 중요하다는 것을 알고 있었다. 비록 개발 쪽 협업은 처음이었지만, 실제로 경험해보니 Git을 통해 푸시하고 풀하면서 충돌이 발생하는 상황을 다루고, 환경을 설정하는 과정에서 많은 것을 배울 수 있었다. 1일차에 눈에 보이는 성과는 없었지만, 배운 것은 아주 많았다.

또한, 팀원들과 함께 에러를 해결하는 과정에서 서로 알려주고 배우는 경험을 통해 혼자 공부할 때보다 더 많은 것을 배울 수 있었다. 이러한 점들이 협업의 큰 장점으로 다가왔다.

 

아쉬운점

 

아쉬운 점은 시간에 쫓겨 작업하다 보니 내가 알고 있는 것들도 차근차근 진행하지 못해 잘 풀리지 않았다는 것이다. 천천히 생각할 시간을 가지고 진행했다면 에러가 많이 줄어들었을 것 같다. 또한, 아이스브레이킹 기능을 만들다 보니 원래 만들어야 하는 기능을 제대로 진행하지 못했다.

1일차에 릴리즈 노트와 브랜치를 제출해야 했지만, 다양한 에러를 겪으면서 제출할 시간도 없었다. 결국, 1일차에 완성해야 할 것들을 다 완성하지 못한 점이 가장 아쉽다.

 

개선할점

 

비록 시간이 많이 주어지지는 않았지만, 서두르지 말고 차근차근 진행해야겠다고 생각했다. 시작하기 전에 역할을 정하고 무엇을 할지 계획을 세우긴 했지만, 이를 기록하지 않아 체계적이지 못했다. 따라서 앞으로는 각자 해야 할 일과 같이 해야 할 일을 명확히 나누어 기록하고 진행하는 방법을 도입해야 할 것 같다. 이를 통해 보다 체계적이고 효율적으로 작업을 진행할 수 있지 않을까....?

 

 

프로젝트 칸반보드