머릿말
주의: 해당 게시글은 회사에서 Spark 등을 사용하여, Batch Job 개발을 주로 수행하고, 타 개발자에게 Data Platform 등을 제공하는 Data Engineer인 저의 상황이 반영된 게시글입니다. 다른 도메인, 다른 기술을 사용하는 Data Engineer 분들에게는 조금 다른 내용일 수도 있습니다.
안녕하세요? 박민재입니다. 오늘은 저의 개인적인 사견이 듬뿍 담긴, 이제 2년차로 들어가는 건방진 개발자의 사견을 듬뿍 담은 글이에요. 매우 개인적인 글이기도 하고요. 어찌보면 공격을 받기 위해 쓴 글입니다. 제가 지금 딱 이런 상황이거든요.
데이터 엔지니어로 성과를 낸다는 것은 어떤 것 일까요?
데이터 엔지니어로 일한지 1년이 넘어가는 상황에서, 의미있는 성과를 내고 싶은 욕망이 생겼습니다. 그래서 자연스럽게 데이터 엔지니어, 혹은 S/W 엔지니어로 의미 있는 성과를 내기 위해서는 어떻게 해야 할지에 대한 의문으로 이어진 것 같아요.
일단 성과라는 단어의 정의에 대해서 먼저 정리 해 보겠습니다. 개발자에게 있어 성과란 무엇일까요? 크게 제 생각에는 4가지로 정리 할 수 있을 것 같아요.
- 내가 잘해서 회사가 얻은 것: 요구 사항 수행, 서비스 수익으로 직결되는 기술적 개선
- 내가 잘해서 팀이 얻은 것: 팀 전체의 기술적 발전, 고도화를 통한 개발 생산성 증가
- 내가 잘해서 동료가 얻은 것: 팀원의 성장
- 내가 잘해서 내가 얻은 것: 개인의 성장
이러한 기준을 바탕으로 한 번 데이터 엔지니어로 할 수 있는 Challenging한 일들을 한 번 나열 해 보도록 하겠습니다.
(준)실시간 데이터 제공
선정 기준: 서비스(매출) 수익으로 직결되는 기술적 개선, 기술적 발전, 성장
광고 도메인으로 예시를 들어 보도록 하겠습니다. 사용자가 앱 활성화 시간 동안, 특정 제품에 대해서 관심을 가지고 검색, 클릭, 조회 등의 이벤트를 발생 시켰다고 가정 합니다. 이 데이터가 ML 모델에 빠르게 도달 할 수록, ML을 기반으로 하는 광고 송출에 있어 더 효율적인 광고를 빠르게 서빙 할 수 있습니다.
하지만, 대용량의 데이터를 다루다 보면, 실시간으로 대용량의 데이터를 서빙 하는 것은 꽤나 기술적으로 쉽지 않은 일이라는 것을 알 수 있습니다. Data Quality 또한 최대한 보장 해 주어야 하며, 컴퓨팅 리소스는 거의 대부분의 경우에 실시간 서빙을 수행 할 수 있는 Streaming 방식 보단, 주기적으로 한꺼번에 데이터를 처리하는 Batch 방식으로 데이터를 처리 하는 것이 리소스가 덜 사용 되기 때문이에요.
그렇기 때문에, (준)실시간 데이터 제공을 위해 할 수 있는 테스크는 크게 두 가지 정도가 있을 것 같아요.
- Streaming 방식의 로직을 개선하여, 최대한 적은 리소스로 유의미한 실시간 데이터 제공하기
- Batch 방식의 주기를 감소시킨 Mini-Batch 방식으로 데이터 집계 후 제공하기
이를 수행하기 위해서는 다음과 같은 것들을 잘 고려해야 할 것입니다.
- 현재 우리가 현실적으로 사용할 수 있는 컴퓨팅 리소스는?
- Input Data는 어떤 Storage에서 오고, Output Data는 어떤 Storage에 저장 되는지? (ex: kafka, s3, hadoop)
- Hadoop에 저장을 한다면, Block Size에 맞게끔 Spark의 Partition 크기에 대한 고려를, Kafka를 사용을 한다면 Topic의 Patition 수에 대한 고려를 수행 해야 합니다.
- 우리가 데이터 제공을 함에 있어, 어떤 로직이 사용되고, 이는 내가 사용하는 연산 방식에서 문제가 되지 않는지?
- Spark와 같은 분산 컴퓨팅 프레임워크를 사용 한다면, 각 Node가 네트워크를 통해 Data를 주고 받는 Shuffle 로직이 최소화 되어야 합니다.
팀 내 Component 고도화
선정 기준: 요구사항 수행, 고도화를 통한 개발 생산성 증가, 성장
요구사항을 해결하는 것과, 개인과 팀이 기술적으로 발전 하는 것은 함께 하는 경우도 있지만, 함께 하지 않는 경우도 있습니다. 그렇기 때문에, 요구사항이 추가 되었을 때, 빠르게 개발을 할 수 있도록 개발 생산성을 증가시킬 수 있도록 코드를 작성 하는 것도 중요 할 것 같아요. 비슷한 기능들이 있거나, 재사용의 가능성이 높은 로직들을 분리 하는 것 처럼요. 다음과 같은 것들이 예시가 될 수 있을 것 같아요.
- Airflow 내의 서로 다른 DAG이 유사한 로직으로 작동하는 경우, Task Group으로 묶어서 관리 포인트를 줄인다.
- Spark Application의 Aggregation 로직 같은 경우에는, 재처리를 대비하여, Report Job과 Aggregation 로직을 분리 한다. (Jupyter Notebook 상에서 재사용하는 것을 대비)
데이터 사용자 친화적 환경 제공
선정 기준: 고도화를 통한 개발 생산성 증가, 성장
우리가 재가공한 데이터를 사용하는 유저들이 있습니다. ML 엔지니어, 백엔드 엔지니어, Data Analysist 등이 이에 속하는데요, 다른 분야의 엔지니어들은 Data Engineering에 지식이 많지 않은 경우가 대부분입니다.
우리는 데이터를 사용하는 유저들에게 조금 더 쉽고, 사용자 친화적인 환경을 제공하는 것이 중요 합니다. SQL문만 논리적으로 작성하면 뒷 단에서는 Spark Engine이든, Hive Engine이든, Flink Engine이든 어떤 엔진으로 연산을 수행 하던지에 상관 없이 논리적으로 동일한 결과를 반환하는 것 처럼 말이에요. 사용자가 쉽게 Airflow DAG을 개발 할 수 있도록 Operator를 제공 해 주거나, Data Lineage, Data Profiling 결과를 확인 할 수 있도록 Data Discovery Platform을 운영하는 것도 좋겠네요.
정리하면 다음과 같은 것들이 예시가 될 수 있겠네요.
- Iceberg와 같은 Table Format을 제공하여, 원하는 엔진에서 돌려도 동일하게 다른 엔진에서도 데이터를 조회 할 수 있도록 제공한다.
- ACID, Snapshot 기능 또한 추가적으로 제공하기.
- Datahub와 같은 Data Discovery Platform과 Great Expectations와 같은 Data Quality + Data Profiling 툴을 사용하여, 데이터 사용자에게 Insight 제공하기.
- Airflow에 지식이 부족한 엔지니어들을 위해서 고도화된 CustomOperator를 작성하여 제공 해 주기.
마치며
다음과 같이 크게 3가지 토픽으로 해 볼만한 것들을 (정확히는 제가 해볼만한...) 정리 해 보았는데요, 올해 성과를 내기 위해 위에 언급했던 목표를 잡고 나아가 볼 생각입니다. 의견을 받기 위해서 작성 한 글이니 만큼, 더 좋은 의견들이 있다면 댓글로 작성 해 주세요!
글 읽어 주셔서 감사합니다.