데이터 파이프라인 구축 시 고려사항 체크리스트!

다수의 회사에 다수의 데이터 파이프라인을 구축하는 프로젝트에 참여해본 경험을 바탕으로 초반에 고려하지 않으면 후반에 힘들어질 사항들을 정리해보고자 한다. 

 

보통 우리를 통해서 파이프라인을 구축하는 회사는 내부에 데이터 인력이 없거나 데이터에 대한 정의가 통일적이지 않은 경우가 많기 때문에 생각보다 더 깊은 곳에서 부터의 변화가 필요하다고 느꼈다. 이런 회사들이 가장 먼저 고려해야할 점들은 무엇이 있을까?

 

1. 가장 중요하지만 꽤나 어려운 : 데이터 현황 제대로 파악하기

당연히 되어있지 않냐고? 절대 놉.

테이블명이나 컬럼명 등의 네이밍룰이 잘 정의되어 있는건 바라지도 않는다. 어디에서 와서 어디로 가는지(리니지) 또한 요구하지 않는다. 없을걸 아니까.. 그저 전체 테이블, 전체 컬럼 현황이 필요하고 이 중 분석팀/BI팀에서 사용할 테이블은 어떤건지, 데이터 플랫폼으로 이관할 대상 테이블이 몇개인지에 대한 파악이 잘 되어야한다.

 

또, 대상 테이블들에 대한 현업의 요구사항을 조사하여 배치성인지 실시간성 인지에 대한 정의를 해 두어야한다. 이 과정은 여러 팀의 협업을 필요로 하기 때문에 생각보다 더 오래 걸리는 작업이 될 수 있다.

 

추가적으로는 파티션을 걸만한 컬럼이 있는지, 업데이트 방식이 어떻게 되는지(전체적재/증분적재 결정)을 파악하면 더욱 효과적으로 계획을 세울 수 있다.

이관 방식과 이관 대상 테이블의 갯수에 따라서 프로젝트의 목표 시간이 결정되기 때문에 중요한 문제이다.

 

2. 춘추전국시대에서 나에게 맞는 솔루션 선택하기

나는 보통 솔루션이 다 선택된 이후에 플젝에 들어갔지만 어떤 솔루션으로 갈 지 결정하는건 매우매우매우 중요하다.

왜냐면 솔루션이 왕도는 아니라 모든 기능을 만족스럽게 제공해주진 않거든.

부족한 기능이 있을때마다 다른 솔루션을 기웃거린다면 혼란스럽기만 하다.

하나만 딱 정해놓고 소위 조져야지만 플젝을 성공적으로 마무리하기 편하다고 생각한다.

 

안되는 기능은 오히려 추가 개발로서 되게 할 수 있는데(시간은 들겠지만) 워낙 다양한 솔루션이 많으니까 그럼 이건 어때? 하면서 딴 쪽으로 고개를 돌리다보면 플젝이 힘들어진다. 

 

AWS의 서비스들을 생각해봐도 마찬가지이다. aws 서비스를 골라서 사용하는 일은 블록 조각을 쌓아서 블록 모양을 만드는 일로 비유되지않나? 데이터 파이프라인도 마찬가지이다. 이 솔루션들이 훨씬 넓게 퍼져있어서 정보 취합에 품이 더 들긴한다.

 

또, 솔루션 선택은 자유여행이 아닌 패키지 여행이라고 생각하면 편하다. 많이들 착각하는 포인트라고 느끼는데.. 솔루션이 제공하는 기능과 성능은 한계가 있기 때문에 자유여행처럼 원하는 대로 바꿔가며 진행할 수 없다. 오히려 패키지 여행처럼 여행사가 짜준 코스가 맘에 들든 안들든, 밥이 맛있든 없든, 내가 피곤하든 안하든 그냥 따라야한다. 

 

솔루션을 선택할 때 고려하면 좋을 사항은 아래와 같다.

 

  1. 운영 인력의 수준

하둡(요즘은 신규구축은 잘 없지만)을 예시로 들자면 하둡 에코시스템의 복잡성을 이해하고 운영할 수 있는 인력이 있다? 그러면 그냥 개발자로 돌리면 된다. 하지만 그런 인력이 없다? 그럼 Cloudera같은 솔루션을 사용하면 된다. 

또, 우리가 구축을 해주어도 추후에 운영은 직접해야하는데 운영 인력이 복잡한 아키텍처에는 면역이 없다면? 기능이 조금 부족해도 솔루션을 사용하는게 좋다. 요구사항이 꽤나 구체적이었고 현업도 잘 아는거같다면? 요구사항에 맞는 추가 개발을 통해 만족시킨 후 인수인계를 잘 하면 된다.

 

  2. 솔루션의 유명세

유명세 무시못함. 커뮤니티가 활발할수록 case open 했을 때 대처가 빠를수록 파이프라인 구축이 수월해진다.

내가 보기엔 좋아보이는데 사용자가 너무 적어서 커뮤니티가 활발하지 못하다? 이 말은 문제가 있을 때 검색되는게 없다는거예요..

 

  3. Data Source와의 호환성

DataSource 가 무엇인지 따라서 아예 사용할 수 없는 솔루션도 있다.

Sqoop과 같은 배치성 솔루션은 RDB 대상이 아니면 연결이 어렵다. 1에서 파악한 데이터 소스를 기반으로 전부 다 지원하는지 확인하는 절차가 필요하다. 나중엔 꼭 명단에 없던 테이블 가지고 와서 or 이미 있던 테이블인데 연결이 지원되는지 파악을 안 해 두어서 문제가 발생하곤 했다. 

지원하지 않는 source라면 우회해서라도 연결할 수 있는 방법이 있는지 파악해두면 좋다.

 

  4. 실시간처리 vs 배치 처리

이건 아예 솔루션의 종류가 달라지기 때문에 둘다 쓸지 아니면 둘 중에 어떤 방향으로 갈 지 결정해야한다.

당연히 실시간성이 좋기야 하겠지만, 관리/운영 측면에서는 장애 발생에 대응하기 비교적 힘들기에 무작정 전체 테이블 실시간 고! 라고 외칠 수는 없는 노릇이다. 요구사항에 맞게 테이블을 분류하고 그에 맞는 솔루션을 선택해야한다.

 

  5. 비용

진짜 클라우드 쓰면 백퍼. 비싸다고 느낌. 진짜로. 영업말 다 믿으면 안됩니다..

 

 

3. 나중에 꽤나 골치아파 지는 기타 고려사항

원천에 대한 정보 : 추가 연결에 예민한 원천이 많다. SAP같은 경우는 연결 당 라이센스가 추가로 필요한걸로 안다. 이럴 경우엔 어떻게 처리해야할지에 대한 논의도 필요하다. 또, 원천이 몇시에 한가해서 대왕으로 끌어와도 좋을지 알고 있으면 굿.

개인정보 데이터 : 클라우드에 올린다면 추후에 개인정보는 무.조.건 문제가 된다. 이에 대한 논의는 사.전.에. 되어있을 수록 좋다.

 

---

고생했던 부분들을 생각나는 대로 작성해보았는데 누군가에게 도움이 되면 좋겠다. 이 외에도 수만가지 고려사항이 있지만 중요하면서도 놓치기 쉬운 포인트들만 골랐다고 생각하면 된다. 모든 회사들의 파이프라인이 아름다워지길!