데이터 엔지니어 업무 초보자가 궁금한 점 질문드립니다..

선생님 안녕하세요! 덕분에 Airflow에 대해 깊이 있게 공부하고 있습니다! 감사합니다.

다름이 아니라 Airflow를 잘 쓰고자 하는 마음에 질문드립니다!

제가 지금 구축해야하는 환경이 Google Cloud 기반에서 DataLake와 Warehouse를 구축 해야 하는 상황에서 Airflow 강의를 참고해 도입 예정에 있습니다. 사 내 인프라 팀은 잘 갖춰져 있으나 데이터팀은 아직 미약한 상태에요..

구글링 해서 살펴보았을 때 Airflow의 전처리의 대부분이 BigQuery의 SQL을 통해

원하는 데이터를 가져와 전처리하는 로직으로 구성되어 있는거 같더라구요.

저는 Pandas라는 라이브러리가 익숙한 것도 있고 SQL 쿼리로 관리하기보다

Pandas 코드로 관리하고자하는 마음에 Airflow와 Pandas의 조합은 어떻게 쓰면 좋다라거나 참고 블로그에 대해 알고싶고 또 선생님 조언을 들어보고 싶습니다 ㅠㅠ

아직 Airflow를 완전히 이해하지 못했지만 걱정되는 점은

Pandas 사용 시 데이터를 읽었을 때 인메모리에 많은 양의 데이터가 올라가

주의하지 않으면 구축하려는 Cloud Composer의 스펙이 오버될거 같은 느낌이 들어서요..

또 다른 궁금한 점은 전처리 구간이 많을 수록 BigQuery에 저장하면서 불러들이는 식으로 작업하시는 지도 궁금합니다!! 장애 발생 시 어떤 구간에서 발생했으며 Retry 시 저장하면서 가야 정확한 에러 구간에 대해 모니터링이 가능해보여서요..

마지막으로.. dags를 관리하는 아키텍쳐? 방안에 대해서 유행하거나 픽스된 방법론이 있는 지도 궁금해요

백엔드의 디자인패턴과 유사한..

질문이 많죠.. 백엔드하다 데이터 엔지니어 업무가 처음이다 보니 궁금한게 많네요..

다시 정리를 하면 질문은 아래와 같습니다. 긴 글 읽어주셔서 감사합니다 ( _ _ )

Airflow와 Pandas 조합을 사용하고자 할 때 선생님의 조언이 궁금합니다.
전처리 구간 마다 생기는 View Table이 데이터 양이 많을 때 저장하는 지 궁금합니다.
git에서 dags를 관리하는 방법론이 궁금합니다.

안녕하세요 권설민님!

저도 Datalake 구축시 빅쿼리를 기반으로 Airflow를 사용했던 적이 있습니다. GCP를 사용하신다니 반갑네요 ^^

질문에 답변하자면,

Airflow와 pandas 조합은 개인적으로 비추천합니다.

pandas 가 소규모 데이터에서는 큰 문제없이 동작하는데 데이터 규모가 커지면 CPU를 많이 먹습니다. pandas 아키텍처상 병렬처리도 불가능하구요. 그리고 아키텍처 관점에서도 비추천합니다.

Airflow 는 ETL 툴이라 부르기보다는 오케스트레이션 툴이라 불립니다.
즉 Airflow의 워커가 직접 CPU/MEMORY 와 같은 자원을 소모하며 작업을 처리하기 보다는 다른 도구에 작업을 지시하고 관리하는 것에 더 부합하기 때문입니다. 따라서 전처리가 필요하다면 Dataproc 또는 빅쿼리와 같은 도구를 사용하는것이 좋습니다.
그리고 이 문제는 워크플로우의 관리 문제에 앞서서, 데이터레이크의 데이터 흐름을 어떻게 관리할 것이냐에 대한 거버넌스 문제이기도 합니다. (제 생각에 이런 거버넌스를 먼저 확정하는 것이 좋을 듯 합니다)

데이터레이크는 그 정의에 따라 정형/비정형 데이터를 원천 그대로의 모습으로 한 곳에 모아두는 것입니다. 물론 원천 그대로만 두지는 않고 활용을 위해 가공이 필요하지요. 일반적으로 GCS 에 저장해두고, SQL 처리도구로 빅쿼리를 사용하는게 가장 일반적인 모습인것 같습니다. (AWS라면 S3에 저장해두고 glue 로 처리하는 형태)
따라서 설민님께서 고민하시는 파이프라인은 크게 두 가지로 구분할 수 있는데

1) 원천 데이터를 가져와 Airflow가 pandas 로 만들어 메모리상에서 처리 후 GCS에 저장한다.
2) 원천 데이터를 가져와 GCS에 저장해두고 빅쿼리로 처리한다.

어떤게 더 나아 보이나요?
1)은 흔히 과거 DW가 유행하던 시절 ETL 도구가 처리하는 방식입니다. Extract 후 Transformation 하고 마지막에 Load 하는 방식이지요.
2)는 datalake 개념이 도입되면서 ELT 라는 이름으로 처리하는 방식입니다.
Extract 후 일단 GCS에 Load하고 필요시 가공(Transformation)하는 것이죠.

- 데이터 수집이 몇 개가 아니라 향후 수천개로 늘어난다면 어떤게 더 나을 것 같나요?
- 만약 수집한 데이터에 문제가 있어서 제대로 전처리가 되지 않았고, 원인을 파악해야 한다면 어떤 방법이 더 나을까요?
- 수집한 데이터가 수십GB 이상에 달해 처리에 오래 걸린다면 어떤 방법이 더 나을까요?
- 만약 원천 그대로의 데이터가 필요한 상황이 온다면 어떻게 할까요?

위 4가지 케이스 모두 Airflow가 직접 pandas로 처리하기보다 GCS에 저장 후 빅쿼리로 처리하는게 더 나은 방법입니다.
일반적으로 물리테이블을 만들어서 처리합니다.

빅쿼리도 대용량 테이블을 view를 이용해서 굴비엮듯 다단계로 구성해서 한번에 처리하려고 하다보면 메모리 부족 에러가 뜨기도 합니다. 가급적 물리 테이블을 이용해서 구간별로 처리하는 걸 권장합니다. 이 방법이 중간에 에러로 멈췄을 때 어디서 에러가 발생했는지 추적하기도 좋습니다.

장애 발생 시 어떤 구간에서 발생했으며 Retry 시 저장하면서 가야 정확한 에러 구간에 대해 모니터링이 가능해보여서요..
이건 전처리 도구에 어떤 툴을 활용해도 에러 구간 확인은 가능할 것 같습니다. 꼭 이것 때문에 빅쿼리를 써야하는건 아닐것 같아요.
이건 정답이 있는지는 저도 모르겠습니다 ^^
저는 일반적으로 DB를 별도로 만들어 dag에 필요한 내용을 작성해 놓으면 DB를 읽어 dag이 생성되도록 구성하기를 선호합니다. 이 방법은 DB에 내용을 작성하는 방법만 알면 표준화된 DAG 관리가 가능하다는 것이 가장 큰 장점입니다. 뿐만 아니라 DAG 과 task의 구성, DAG간의 선후행 관계 등을 DB쿼리를 통해 한번에 파악/관리할 수 있다는 것도 큰 장점이지요.
단점은 개발자가 Airflow의 고급 기능들을 자유자재로 활용하기가 어렵다는 점입니다. 저는 SI 프로젝트를 주로 하므로 실력차이가 서로 다른 개발자 분들이 와서 개발해도 어느정도 표준화된 DAG 구성을 만들게끔 하고자 이 방법을 주로 사용합니다. 그리고 이렇게 하면 git으로 DAG 관리를 하는게 아니라 DB로 관리를 하게되어 git 표준하고는 상관이 없어집니다.

혹시 git 브랜치 전략같은게 궁금하시다면 DAG과 관련해서도 feature 브랜치, hotfix 브랜치 등과 같은 전략을 통해 관리할 수 있습니다. 신규 DAG을 만든다면 issue 등록 후 feature 브랜치를 따서 DAG 내용 작성하는 것도 가능하구요. 파이프라인에 문제가 있어 DAG 수정을 해야한다면 hotfix 브랜치를 따서 수정하는 것도 좋구요. 하지만 브랜치 전략이라는게 그렇지만 꼭 이런 브랜치 전략을 따를 필요는 없습니다. 마찬가지로 git을 이용 방법도 정답이 없는 문제라 프로젝트 상황을 봐야합니다.

마지막으로.. 빅쿼리는 사용해보시면 장단점이 꽤 분명합니다.
장점은 엄청 빠릅니다. 대규모 데이터도 금방 처리가 되구요.
단점은 RDB와는 달리 인덱스나 PK설정이 안됩니다. 그리고 파티션 설정을 잘해야 비용/성능이 잘 나온다는 것입니다. 그리고 처리한 데이터양을 기준으로 비용이 청구되어서 비용도 생각보다 많이 나오기도 합니다. 그래서 빅쿼리 사용을 권장하긴 하는데 공부를 좀 하셔야 잘 사용하실 수 있을거에요.

아무튼 데이터 엔지니어로써 고민이 많으신듯 합니다. ^^
누군가 설계해놓은 걸 이행하는 것보다 이런 고민을 직접 많이 하시는게 엄청 도움이 많이 됩니다. 앞으로 더욱 성장하실 것 같네요. 화이팅입니다!

인프런 커뮤니티 질문&답변